SecureStack adds AWS service detection to Project Discovery Nuclei

SecureStack adds AWS service detection to Project Discovery Nuclei

SecureStack and Project Discovery partner to help bring AWS service detection to Nuclei!

 

 

We are super pumped to announce our new partnership with Projectdiscovery.io!

SecureStack has developed a new Nuclei template for AWS service detection. This allows you to use Nuclei to identify AWS services that an application is using.

Founder and CEO Paul McCarty says “This Nuclei template started out as a set of internal functionality in the SecureStack platform, but over the last year we realized that it’s important for people who use open source tools like Nuclei to have this visibility as well, so we ported our detection into Nuclei templates.”

securestack-and-nuclei

Identify 10 different services in AWS applications

This new template will quickly scan a target and identify what AWS services are being used via standard HTTP requests.  The AWS services that this new template identifies include Cloudfront, EC2, AppSync, ELB, Codebuild, DynamoDB, S3, API Gateway, KMS, WAF, and Xray.

aws-services-detected

Use Cases

The template is designed for the security and engineering teams protecting the cloud environment

  1. Visibility into your AWS services – know which AWS services are part of different application environments.
  2. Identify the underlying services operating your WAF and CDN providers – If you are using Cloudflare, Akamai, Imperva or other similar services, you often don’t know what cloud services are being used as the WAF obfuscates service information
  3. Understand and safeguard your AWS environment – you know what’s exposed to the internet and what’s not, so you stay one step ahead of potential threats and minimize the risk of security breaches
  4. Bug bounty researchers and penetration testers –  This template lets you quickly scan large numbers of assets for AWS services for in-scope bounty programs.

PJ Metz from Projectdiscovery.io says “Paul’s template is extremely valuable in reconnaissance while working on a bounty or pentesting; knowing your attack surface is probably the most important step since you can’t protect/attack what you don’t know exists.

You can check it out as part of the latest Nuclei template release at https://github.com/projectdiscovery/nuclei-templates

 

 

 

Easily scan a large number of assets and detect AWS services

aws-detect

 

About SecureStack

At SecureStack, our mission is to provide a fully integrated platform that enables engineering and security teams to collaborate seamlessly. This partnership with Projectdiscovery.io is the next step towards this goal.

Take your AWS security to new heights by downloading our Nuclei at https://github.com/projectdiscovery/nuclei. Nuclei will automatically download the latest templates, including the new aws-detect.yaml template.

Stay tuned for more updates as we grow the vulnerability detection capabilities of the SecureStack platform.

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

 

SecureStack Sign Up

SecureStack Sign Up

One of the unique things about SecureStack is that its used by people who come from different backgrounds and roles, not just developers.  Sure, we have a lot of users who are software engineers, but we also have security researchers, appsec teams, SOC analysts, CISO’s, pentesters and bug bounty kids using our platform.

Sign up for a free trial of SecureStack by clicking on the “Try for Free” button or follow the link below. Your free trial will come with 20 monthly analyses, and support all of our scanning technologies:  web, cloud, code and secrets.

You can sign up for a free account here: https://app.securestack.com/auth/register

complete-security-coverage-startups

Complete security coverage across the whole SDLC

The SecureStack platform offers an integrated suite of security tools that work together and all report to the same dashboard.  One unified view and one subscription to pay.  Easy.

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

 

Confluence-Aggedon!  Atlassian Confluence plagued by two CVSS 10 CVEs!

Confluence-Aggedon! Atlassian Confluence plagued by two CVSS 10 CVEs!

Two critical severity CVE’s were announced in October for the popular collaboration platform Atlassian Confluence. The first bug, CVE-2023-22515 was announced on October 4th, and classified as a CVSS 10! CISA published a CyberSecurity Advisory on October 5th which was quickly followed by a similar advisory from the ACSC here in Australia.

Quickly after that, Atlassian updated the CVE to say that this zero-day was being actively exploited in the wild by a nation state actor. You can read Atlassian’s advisory here: https://confluence.atlassian.com/security/cve-2023-22515-privilege-escalation-vulnerability-in-confluence-data-center-and-server-1295682276.html

Additionally, you can read CISA’s advisory here: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-289a and the ACSC advisory here: https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/multiple-vulnerabilities-atlassian-confluence-data-center-and-server

 

What services are affected?

Thankfully, this CVE-2023-22515 only affected Confluence Server and Data Center products, and not the cloud SaaS versions of Confluence. Moreover, it only affected versions 8.0.x to 8.5.3. This limited the scope significantly, but because of the type of product that Confluence is, there are a LOT of large organizations that run Confluence as a self-hosted server. And many of them, unfortunately, are not used to patching Confluence routinely. This is where the problem lies.

Then, last week another Confluence bug was announced. Initially, it was “only” a 9.1, but here’s the important part:  This new bug affected EVERY version of Confluence ever released!   This CVE 2023-22518, affected Data Center and Server products only, like the first bug, but the number of Confluence versions affected was MUCH larger. All versions of Confluence from 1.x to 8.5.3 were affected. This meant that many of the larger organizations that weren’t vulnerable to the first vulnerability because they hadn’t updated from version 7.x, were in fact vulnerable to this second bug.

Then on November 7th, 2023, Atlassian upgraded CVE-2023-22518 to a CVSS 10!  Turns out that 22518 is more similar to 22515 than initially though and allows you to create administrator accounts in a similar way.  There are multiple POCs in the wild that appear to work, and Atlassian has detected that this bug has been packaged into ransomware.

This means there are now TWO CVSS 10 bugs we have to address.

 

Why is this such a big deal?

Confluence, Jira, and other developer focused tools have a long history of being available outside of the VPN perimeter. This is often because the devs involved want to be able to use these tools when working from home, or via their own laptops. Because of this, even self-hosted servers like Confluence, Jira and Bitbucket can be really juicy targets to malicious actors because these servers host really sensitive intellectual property, and are often poorly defended.

 

How did SecureStack get involved?

SecureStack maintains a set of deception services pretending to be developer focused tools like Confluence. This allows us to gain insight into new attacks and trends against these hosted services. Over the last two years we’ve used this data to help us build better defenses and new detections for attack types. These detections are built into our platform and we make these available to any paying customers.

Over the last several weeks SecureStack saw a noted increase in the amount of traffic related to scanning for public facing Confluence servers, and the types of attacks were new. They were targeting specific endpoints and routes within Confluence. Based on user agent data we could see that much of this scanning was probably automated.

Sure enough, a quick search of GitHub showed there were multiple projects and POCs for CVE-2023-22515.   Project Discovery quickly built a Nuclei template which went live on October 10th: https://github.com/projectdiscovery/nuclei-templates/commit/0471ab31c7ef32000f45a5d2f59b18311f39dfeb

 

Quick legal disclaimer

The purpose of this blog post is to help us understand how widespread these vulnerabilities are.  Exploiting these vulnerabilities and server products is illegal.   The data I reference here is based on public websites and the data is collected using simple HTTP requests (GETs) and responses looking for things like headers, meta tags and body content.

Now with that out of the way, let’s dig into this…

 

How big is the collective attack surface these two CVEs?

Well, let’s start with collecting some data around public facing Confluence servers. There are two steps to this:

First, find targets!  Second, test what versions of Confluence they are running. For the first part, let’s use Shodan and SecurityTrails as they both can give us a large number of Confluence servers quickly.

The Shodan CLI is probably the best way to collect data for this kind of project. Shodan allows you to use data in the HTML or headers to search by. Here’s a CLI command that will collect a list of Confluence servers globally:

shodan search –fields ip_str,hostnames http.component:”atlassian confluence”

When you are doing research like this, especially where you are trying to quantify how prevalent something is on the internet, you have to make sure you don’t just trust things at face value. What do I mean by this? One thing to keep in mind about Shodan is that if you search for a technology like I did above with the http.component:"atlassian confluence" it will say that there are more than 21k Confluence servers on the internet, like it does in the image to the right.

But the reality is that Shodan displays results in a way that makes the number of results look much larger than it really is.

shodan-search-results-confluence

How can you identify what’s “real” data from Shodan?

Shodan is an amazing platform and I use it almost every day, however it’s important to know how it categorizes and displays data to really understand whether to trust its data. For example, because it focuses on ports as a primary key:value primitive it groups “results” by ports rather than by IP which is not obvious to you when you use the web UI.  If you scan a single IP or domain name and then download or search the results, Shodan displays ports as individual “results”.  Said a different way, one IP address will have multiple “results” in Shodan.

All you have to do to prove this point is to sort by unique IP addresses and hostnames in the Shodan data and you’ll see the real numbers:

confluence-files-sort

SecurityTrails data can help build out your dataset

In addition, to the data you get from Shodan, it can help to search DNS records for keywords related to your target.  SecurityTrails is comprised of a static list of historical DNS entries and as such you need to sort and test for relevancy.

So for Confluence, some good keywords are: confluence, support, wiki, jira, knowledgebase, kb, etc

Here are some recent results from the free version of securitytrails.com for “confluence”:

securitytrails-data

 

Project Discovery Tools can help

Sorting through historical DNS data can take work, but you need to sort and test for relevancy.  I would suggest you leverage the Project Discovery dnsx and httpx tools for this.

You can find those projects here:

https://github.com/projectdiscovery/dnsx

https://github.com/projectdiscovery/httpx

projectdiscovery-logo

 

How do we identify if Confluence is present and is vulnerable?

Both CVE-2023-22515 and 22518 only affect Confluence data center and server products, so all Atlassian Cloud instances are not affected.  If you don’t know which version you are using, typically Atlassian Cloud uses an atlassian.net URL to login.

Once you have refined your target list, you need to identify what version of Confluence they’re running.  The CVE advisories list the specific versions that are affected by each of the vulnerabilities.  Finding the version of Confluence is relatively easy to do because Atlassian has added several metadata tags to their products which you can test for.

The “confluence-base-url” is a meta tag added to Confluence to clarify the hostname it is using.  This is helpful in figuring out what the DNS name is if you find just the IP address on Shodan.  This is the authoratative test to determine that the service is Confluence.

<meta id=”confluence-base-url” name=”confluence-base-url” content=”https://confluence.example.com.au”>

The “ajs-version-number” tag is added to most Atlassian products and should be used as an authoratative source of the version number if “confluence-base-url” is also present.  Otherwise you might get results from Jira, Bamboo, or Bitbucket servers.

 
<meta name=”ajs-version-number” content=”7.13.7″> <meta name=”ajs-build-number” content=”8703″>

 

The “ajs-base-url” tag is added to most Atlassian products and should be checked only be used to determine the hostname if “confluence-base-url” isn’t available or wrong.

<meta name=”ajs-base-url” content=”https://confluence.example.com.au”>

 

Automating this with Nuclei

One simple way to detect the Confluence version and hostname is to simply grep the output of curl commands or equivalent.  I initially did this by writing a  bash script with a for loop to iterate through targets and grep for the metatags.  But I needed this to be more scalable, and I typically use ProjectDiscovery Nuclei for this kind of thing.

Instead of grepping the HTML for those metatags, I added the automatic detection of the appropriate metatags to a popular Nuclei template to find both the hostname and the Confluence version.  You can see the latest version of the template with my updates here:

https://github.com/projectdiscovery/nuclei-templates/blob/main/http/technologies/confluence-detect.yaml

nuclei-templates-github-card

 

Let’s use Elasticsearch to help us understand the data

Once you have the hostnames and Confluence versions data you can send the data to your data solution of choice. I tend to use Elasticsearch and ELK as I’ve been working with it for years.

 

ELK stands for “Elasticsearch, Logstash and Kibana” which are three flagship products from Elastic that work together.  Logstash takes inbound data and manipulates it.  Elasticsearch is the search engine based on Lucene where the data actually goes and is indexed.  Kibana is the web UI frontend for Elasticsearch.  You make dashboards in Kibana, not Elasticsearch even though its really common for people to say “Elasticsearch dashboard”.

Nuclei has a nice reporting feature that will send Nuclei output directly to Elasticsearch without setting up a complicated Logstash transformation pipeline.

elk-stack-logo

 

My Confluence Dashboard

This dashboard isn’t complicated and really only cares about three things:  IP address, hostname, and Confluence version number.  All of my analysis relies on those three things.  If I know the version number and the hostname I use the IP address to verify this is a unique host.  This idea of a unique hosts is really important and is more complicated than it might seem but I’ll spare you the details now.

 

confluence-dashboard-1

In this image, you can see there are 3323 unique hosts in this dataset.   The bar graph on the left represents how many of each vulnerable version of Confluence is in the data set.  On the right bar graph, are the secure, patched versions of Confluence.  Clearly, there are a lot less of the latter than there are of the former.

We landed on this number of 3323 servers by sorting all records by unique IP address rather than hostname.  There are a lot more hostnames in the dataset than IPs.

 

total-confluence-hosts

 

In the above image we can see that there are more than 18,000 records in the dataset in total.  This includes results from Shodan for ports attached to the same IP address and using this number would slant our data in the wrong direction.   So today we’ll be focusing on the 3300+ unique hostnames.

 

So, how bad is it?  

 

CVE-2023-22515

At first glance, when looking at the extent of the CVE-2023-22515 exposure, it doesn’t look too bad.  Only 144 servers out of 3323 are vulnerable.  This is 4.3% which as I said…. isn’t bad.

The exposure to this CVE is muted as this affects a limited set of Confluence servers (8.0.0-8.5.2).  As we often find with enterprise and government users, their slow approach to upgrading in this case saves their collective bacon.  If you don’t upgrade to Confluence 8, then you can’t be vulnerable to a bug that only affects version 8, right?

Well, stop laughing big guys because I have some bad news for you…

 

cve-2023-22515-exposure-stats

CVE-2023-22518

For all you orgs that thought you got away from this one, you are wrong.  CVE-2023-22518 affects almost every single version of Confluence and since its been upgraded to a CVSS 10 and we know more about this bug, this is gonna be THE bug of 2023.  The attack is trivially easy to deploy, and the attack surface is large, with a majority of Confluence data center and server products on the internet vulnerable to it.

The data is not good.  Of the 3323 unique public-facing Confluence servers we identified, 61.6% of them were vulnerable to CVE-2023-22518.  More than 2000 servers are affected.  

cve-2023-22518-exposure-stats

 

What has the impact been so far?

Active exploits of CVE-2023-22518 are happening in the wild.  Rapid7 is seeing this bug being used in multiple ways.  You can read their report here: https://www.rapid7.com/blog/post/2023/11/06/etr-rapid7-observed-exploitation-of-atlassian-confluence-cve-2023-22518/

Atlassian reported that some of their customers are seeing CVE-2023-22518 being used to deploy ransomware.  Soon after that Red Canary reported that they’ve seen this vulnerability used to deploy the Cerber ransomware strain.  You can read Red Canary’s report here:  https://redcanary.com/blog/confluence-exploit-ransomware/

We are also hearing from several of our partners that they are seeing widespread use of this vulnerability in different attack scenarios including ransomware, destructive attacks and other avenues.

 

So, what’s next?  Where do we go from here?!

Well, the first thing is for CISA to add CVE-2023-22518 to the KEV list.  Aha, I just checked and CISA has now done as of this evening.   Good start.

Second, if you know that you have a hosted Confluence server you might wanna go check the version number, and then immediately check if any new users have been created.  Also, look for the installation of new plugins as several threat actors have been installing malicious Confluence plugins.

Third, Greynoise is tracking several actors who are targeting CVE-2023-22518.  You can see their data and download a list of IPs and add them to your deny list:  https://viz.greynoise.io/tag/atlassian-confluence-server-authentication-bypass-attempt?days=10

Finally, if you need help determining if your org is exposed to these two critical bugs, feel free to reach out to the SecureStack team:  hello [at] securestack.com or you can use the chat function in the lower right corner of this page.

Good luck and happy hunting people!

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

 

SecureStack Community Edition Is Free!

SecureStack Community Edition Is Free!

One of the unique things about SecureStack is that its used by people who come from different backgrounds and roles, not just developers.  Sure, we have a lot of users who are software engineers, but we also have security researchers, appsec teams, SOC analysts, CISO’s, pentesters and bug bounty kids using our platform.

We want to encourage this dynamic community, so we are excited to announce that as of June 1, 2023 we will offer a completely free version of our platform.  We call this “SecureStack Community Edition” because that’s exactly who this was designed for:  our community.  It will come with 20 monthly analyses, and support all of our scanning technologies:  web, cloud, code and secrets.

You can sign up for a free account here: https://app.securestack.com/auth/register

complete-security-coverage-startups

Complete security coverage across the whole SDLC

The SecureStack platform offers an integrated suite of security tools that work together and all report to the same dashboard.  One unified view and one subscription to pay.  Easy.

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

 

Software Supply Chain Security

Software Supply Chain Security

Software supply chain attacks have grown exponentially over the last three years:  malicious packages, package manager corruption, continuous delivery pipeline attacks, dependency confusion, zero days in open-source software and more.  This is driving many organizations to look for better visibility across their software supply chain. 

Let’s dive in a bit to see why the problem is growing and some potential solutions.

Application complexity is increasing

The reality is that modern applications are complex and dynamic, and therefore hard to secure. They use programming languages that run entirely in the browser, they talk directly to their dependencies on the internet and they use technologies like containers, serverless and public cloud. All of these bring their own challenges, so we need visibility into all these other application components and dependencies as well. What third-party APIs and public cloud components is it using? Is it using an identity provider like Auth0 or Cognito? What infrastructure is required to make the app run? All of these things need to be understood to really be able to better represent what is in an application and how to secure it.

SBOMs can help address software supply chain risks

One way to address the risks inherent to the complex applications we are building is to use “Software Bill of Materials” also known simply as “SBOM”.  At its simplest, a SBOM is a list of all the different component parts of an application. This typically includes several types of information about each component: Its name, who supplied the component, what license it uses, the version number, any known vulnerabilities, and a list of all the component’s dependencies.

Most SBOM tools that exist right now, focus on showing customers some of the open-source libraries that they are using in their applications.  Moreover, most SBOMs are stand-alone JSON documents and by themselves don’t provide much value.  Even worse, many SBOMs are created once and then never updated so they quickly become out of sync with the actual application they are supposed to describe.

sbom-lifecycle-arrow

What’s in the SBOM lifecycle?

Most SBOM advocates believe that SBOMs should be automatically created during deployment, and should be as descriptive of the actual application as possible.  To do this, organizations need to have a process that identifies applications, creates SBOMs and then makes them available for the business to gain value from.  We believe the best way to do that is to create a SBOM lifecycle policy.

There are five stages in the SBOM lifecycle: Asset discovery, application data analysis, SBOM creation, SBOM storage and SBOM searchability.

Let’s go through each of these stages one at a time.

Asset discovery

You can’t onboard what you don’t know about. This stage is all about helping the customer find the applications they need to ultimately provide an SBOM for, which hopefully, is all of them.  Most companies only know about 50% of their public-facing application names.  The other 50%?  Well, that’s the problem. Finding assets with domain names like app.niftybank.org and api.niftybank.org seem obvious but how do you find the less obvious apps? 

asset-discovery

Existing asset discovery or attack surface mapping tools can help find assets but what do you do with the list that these tools have generated?  Most of those tools don’t have any SBOM functionality, so how do you get the list of assets into your SBOM creation pipeline?  It’s better if your solution can find your assets, show them to you and allow them to create a SBOM from that same workflow.

Application data analysis

In this stage, the data that is needed to create an SBOM is collected about the target application. Historically, SBOMs got this info from package manifest files, but now, that’s typically not enough.  Modern SBOMs are able to incorporate data from cloud providers, third-party services and SaaS solutions in addition to source code.

SBOM creation

In this stage, the actual SBOM file is created and will include all the relevant application data.  Typically, you will want this to happen every time your engineering teams deploy a new version of the application.  After all, if you aren’t building a SBOM every time you deploy a new version, is your SBOM going to match the state of your production app?  The only thing worse than no SBOM, is a *wrong* SBOM.

sbom-data-analysis

SBOM storage

SBOMs need to be stored somewhere centrally and protected with a rich authorization layer.  This centralized storage can be an S3 bucket or other secure managed file server, but make sure that they’re stored in an encrypted manner! Otherwise, you might run afoul of compliance requirements!

sbom-cloud-storage

SBOM searchability

Finally, customers need to be able to search across some or all of their SBOMs. Ultimately, all the steps before this one led to enabling this functionality.  This searchability is the most important aspect of the SBOM process because this is the central source of truth. This is how you look up vulnerable software in your environment and find which applications to tackle.

search-sbom

Imagine if you had this functionality back in December 2021 when the Log4j zero-day dropped!  Wouldn’t it have been nice to go to a central place you could go and say “hey, tell me all the places that Log4j is being used and what versions they are!”

Tying it all together

Building a complete SBOM lifecycle can be a challenge, but in the end, the value that it provides to organizations is enormous.  Simply having the ability to quickly find all the software and application components in your estate of apps is huge.   But even better, being able to query that data for vulnerable components could save organizations millions of dollars in lost productivity.  

comprehensive-sbom-securestack

Native SBOM lifecycle

You can build your own SBOM lifecycle or alternatively, SecureStack automates the whole process from end to end.  Our platform delivers all stages of the SBOM lifecycle in a fully integrated solution that is incredibly easy to onboard. Our platform provides an end-to-end SBOM solution that helps organizations address software supply chain risks holistically.  We find all your application assets, automate the creation of your SBOMs, store them for you in a secure central repository, and make them searchable.

Our role-based access control means you can give your security and engineering teams access to those pieces of the SBOM lifecycle that they need.

 

 

 

See how it works!

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!