Instantly Detect Log4j Vulnerabilities on AWS, Azure and Google Cloud

Update as of December 28, 2021: A new remote code execution (RCE) flaw has been discovered in Log4j 2.17.0, tracked as CVE-2021-44832. The vulnerability could potentially allow RCE using the JDBC Appender if the attacker is able to control the Log4j logging configuration file. The new CVE-2021-44832 is rated ‘Moderate’ in severity with a CVSS score of 6.6. Although potentially serious, this CVE is rated much lower than the original RCE vulnerability, CVE-2021-44228, which is rated ‘Critical’ with a CVSS score of 10.0. The latest Apache patch Log4j 2.17.1 will remediate CVE-2021-44832. See the updated remediation table below.

The Orca Security platform has been updated and detects all Log4j vulnerabilities CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832. Our research team is continuing to monitor the Log4j vulnerabilities and will update our platform accordingly and inform you of any new developments as they arise.

• 

  Discover Your Log4j2 Vulnerabilities In Minutes

  Scan your entire AWS, Azure, and Google Cloud environments for Log4Shell vulnerabilities with Orca Security’s free, no obligation risk assessment.

Log4j Two Weeks In: New Data to Help You Benchmark

Update as of December 23, 2021: Feeling behind in your Log4j patching efforts? You’re not alone. Even with 100% visibility into all vulnerable cloud assets, it takes time to patch. 

75% of our customers still have a least one running asset that’s affected by Log4j (CVE-2021-44228, CVE-2021-4104, CVE-2021-45046, CVE-2021-45105)

And after analyzing a representative sample of tens of thousands of Log4j alerts, only 1 in 5 have been addressed and moved to a closed state. It’s been hard for defenders to keep up as aftershock CVEs have followed the original CVE-2021-44228. Here’s where we stand two weeks in on Log4j alerts:

• As mentioned above, only 1 in 5 (20%) of Log4j alerts have been addressed and moved to a closed state
• 29% of Log4j vulnerabilities are on internet-facing assets
• 27% of Log4j vulnerabilities have lateral movement risk
• 12% of Log4j vulnerabilities are on assets that contain personal information
• 6% of Log4j vulnerabilities are on assets running an unsupported OS
• 1% of Log4j vulnerabilities are on assets containing malware

Obviously, you need to patch everything, but based on the data above it might make sense to prioritize internet-facing assets as well as those containing personal information.

Update as of December 18, 2021: Another vulnerability in Log4j was discovered today: CVE-2021-45105 with a CVSS score of 7.5. It allows DOS (Denial of Service) in non-default configurations, and affects Log4j up to version 2.16.0. As with CVE-2021-45046, it is much less severe than the original CVE-2021-44228. If you haven’t updated your environment to Log4j 2.15.0 or 2.16.0 yet, updating to Log4j 2.17.0 is your safest bet. See the updated remediation table below.

The Orca Security platform has been updated and detects all three Log4j vulnerabilities CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105.

Update as of December 17, 2021: If you’ve updated to Log4j version 2.15.0, you may not be out of the woods yet. This fix for CVE-2021-44228 unfortunately includes another vulnerability; CVE-2021-45046. The new vulnerability was found on December 14th and was originally considered very low (CVSS score of 3.7), however it has now been upgraded to a score of 9.0 because, in certain non-default scenarios, it can be used for remote code execution (RCE). To patch the CVE 2021-45046, you must upgrade to Log4j 2.16.0, which disables JNDI by default and removes support for message lookups.

It is important to emphasize that CVE-2021-45056 is much less severe than CVE-2021-44228 – and at this point can be considered similar to other vulnerabilities found on a weekly basis. Just because both vulnerabilities allow remote code execution in log4j, does not mean that they are similar in severity. The Orca Security Platform has already been able to detect CVE-2021-45056 for two days. It was classified in the platform as “informational,” but according to new guidance we have now upgraded it to “hazardous”.

• 

  Discover Your Log4j2 Vulnerabilities In Minutes

  Scan your entire AWS, Azure, and Google Cloud environments for Log4Shell vulnerabilities with Orca Security’s free, no obligation risk assessment.

Additional details on CVE-2021-45046

On December 10th, Log4j version 2.15.0 was released to fix CVE-2021-44228 and included two major changes:

• It restricted LDAP access via JNDI to only allow localhost LDAP access, preventing the way CVE-2021-44228 was exploited.
• It changed the default setting to not perform lookups (i.e. formatMsgNoLookups = true)

On December 14th, researchers discovered that it’s still possible to bypass the JNDI LDAP restrictions and identified a new related vulnerability: CVE-2021-45046. As stated above, even though the vulnerability’s CVSS score has now been increased to 9.0, CVE-2021-45046 is much more difficult to exploit than CVE-2021-44228: This latest vulnerability requires an attacker to control the log message as well as other parts of the logger to perform RCE making it less easy to be exploited.

Original Post
On Thursday, a serious zero-day vulnerability was discovered in Apache Log4j2, a ubiquitous logging tool included in almost every Java application. The vulnerability has been named Log4Shell and has received the CVE-2021-44228 identifier. The danger of this vulnerability is severe, since Log4j2 is a commonly used library, the vulnerability is easy to exploit, and it allows unauthenticated remote code execution (RCE) which can lead to total server control.

The good news is that the Apache Foundation released an emergency update for the Log4j vulnerability on Friday, so this vulnerability can now be fixed by updating to Apache Log4j 2.15.0 or higher. If for some reason you cannot upgrade Log4j, Apache also offers other mitigation steps. Since you can be certain that hackers are now actively scanning the Internet for vulnerable systems that have not been patched yet, it is critical to find every instance of CVE-2021-44228 in your cloud applications before potential attackers do.

How Orca Helps Customers Find Log4j Vulnerabilities Within Their Cloud Applications

At Orca Security, we acted within hours to update our cloud security and compliance platform to identify CVE-2021-44228 within all cloud applications and workloads on AWS, Azure, Google Cloud, and Kubernetes. In fact, Orca has already discovered tens of thousands of vulnerable workloads as of Monday. Furthermore, we can determine which applications pose the greatest risk to your business by detecting possible lateral movement risk and the presence of sensitive data (PII).

Orca Security detects the Log4j2 vulnerability in cloud applications

Orca Security not only detects direct installations of the Log4j packages, but also applications that bundle Log4j within them. To detect Log4j vulnerabilities, Orca searches for the log4j-core jar file. To detect Log4j mitigations and remediations, Orca looks for the classpath org/apache/logging/log4j/core/lookup/JndiLookup.class and for CVE-2021-45105, we inspect the configuration files.

In addition, even before we updated our platform, our customers had the ability to discover all their cloud assets with Log4j 2.x installed by using our intuitive query engine, which enabled them to immediately triage the issue, for instance by blocking Internet access.

Is the Orca Security platform affected by Log4j?

The Orca platform is not affected by the Log4j vulnerability. We do not use Log4j directly anywhere in our components and the AWS managed services we use have already actively been patched.

Get 100% visibility in minutes with Orca Security

As opposed to agent-based solutions that cover less than 50% of cloud assets due to cumbersome and partial deployments, Orca’s platform is agentless and instantly scans each and every cloud asset, providing 100% visibility. Especially with a serious issue such as the Log4j vulnerability, it is critical that your cloud security solution provides complete coverage and does not miss a single asset. In addition, it should be able to find vulnerabilities fast and effortlessly. Now is not the time to have to figure out which assets need agents installed and how to scan cloud resources that do not support agents.

If you currently do not scan workloads in your public cloud or use an agent-based cloud security solution, we highly recommend that you take advantage of Orca Security’s free risk assessment. Within minutes, our platform will be able to tell you exactly which of your assets are affected by the Log4Shell vulnerability so that you can take immediate action.