Log4Shell, a Global Pandemic for Computers

Home / Threat Intelligence bulletins / Log4Shell, a Global Pandemic for Computers

Overview

By now you’ll have heard of CVE-2021-44228, the critical vulnerability in Log4j, a logging framework used in many commercial and open source products.

Exploitation can allow an unauthenticated remote attacker to execute code on the device by injecting a malicious string into any field that ends up getting parsed by the library.
For a web app, that could be the URL, the User-Agent or a number of other HTTP headers which could get logged (Swiss GovCERT have a good explanation here).
In other applications it might be SMTP headers, connection strings, usernames, etc. There’s a lot of potential attack vectors: so, it’s not a single vulnerability, but a series of vulns in thousands of places.

Impact

Exploitation was seen in-the-wild in the first days of December, according to Cloudflare and Cisco.
Initially, most of the malicious network traffic identified was indiscriminate scanning; threat actors (and Threat Intelligence companies) were connecting to every available internet facing server with the JNDI injection strings in various places in hopes of triggering the bug. Initial payloads were cryptocurrency miners looking to extract a quick financial return using server processing resources.

As they’ve had time to work on their approach, attacks have started to become more targeted against known vulnerable applications. WebShells and Cobalt Strike payloads belonging to Ransomware linked Initial Access Brokers (IABs) have been reported: these would grant a foothold to allow further exploitation. The sheer numbers of vulnerable networks would mean that human malware operators would have a lot of results to go through and the time to follow-up may be high. Microsoft’s Threat Intelligence Centre (MSTIC) also reports state backed actors using the vulnerability including APT groups from China, Iran, North Korea, and Turkey.

Threat researchers at Cado and Bitdefender have each published analysis of some of the payloads that are being seen at the moment. Rapid7 have published their own analysis with some Proof of Concept code which shows some different ways the exploit can be performed.

Affected Products

The vulnerable functionality appeared in v2.0-beta9 (from 2013) of the library and the first patch for the issue was v2.15, however, workarounds were found and we’re advising customers to update to Log4j 2.16.0 in their own apps. This version completely removes message lookups. Versions before 2.0 do not have CVE-2021-44228 but does have other critical vulnerabilities.

Log4j is a very commonly used package which is bundled in many other projects and getting those updated depends on the vendor response. Vendors have been rushing out patches over the weekend and it can be hard to keep track of them all.
CISA have made a list of affected (and unaffected) products which is very helpful for triaging exploitation attempts.

Our own internal tools and Clarity are not written in Java and we’ve tested our environments with no sign of vulnerability.

Detection

The bug only affects Java libraries, so web apps written in other languages are mostly safe. The exception is where data from the web app gets passed on to a vulnerable component of another application.

Some open-source detections have been published which look for malicious connection strings in server access logs. This isn’t really an effective detection as there will be a lot of untargeted attempts logged and it can overwhelm responders. Our approach is to focus on devices known to be vulnerable and to look for outgoing connections, indicative of successful exploitation.

Vuln scanning can be used to detect known exploit vectors but there remains some risk as attack complexity grows and new ways of targeting the library become known. Canary Tokens can also be used to find attack vectors or vulnerable fields which can be used to trigger the exploit. Attackers have also been observed using interact.sh to do the same thing.

Thinkst Canary users can generate test tokens from their console. These can be used with curl or wget commands for testing injection into HTTP headers. In the examples below replace <token> with the unique string generated and <target> with the your application’s URL.

curl.exe -H “Referer: $\{jndi:ldap://x$\{hostName\}.L4J.<token>.canarytokens.com/a\}” -H “User-Agent: $\{jndi:ldap://x$\{hostName\}.L4J.<token>.canarytokens.com/a\}” -X GET https://<target>

Further testing of the application itself is also possible. The full string can be entered into any field within the application. To ensure you can identify which application is vulnerable you should generate a different token for each test. Thinkst are also providing a free service for non-customers to generate tokens that can be configured to report the outcome by email.

Microsoft Defender can detect malicious payloads associated with this threat and is available for Windows and Linux servers. Guidance from MSTIC goes into some detail about how Defender, Defender for Endpoint, Defender for Cloud, and Microsoft Sentinel can help.

On Windows, this command will search for applications using the vulnerable component:

gci ‘C:\’ -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_} | select -exp Path

For Linux servers, these commands can also be used to detect the use of the log4j library:

ps aux | egrep ‘[l]og4j
find / -iname “log4j*”
lsof | grep log4j

and find the places that running applications write logs:

lsof | grep ‘\.log’

Prevention

For network-based threats, having a security device in place such as a WAF, or IDS/IPS can prevent attack traffic from making it through to the application. Make sure to update the ruleset if not managed directly by the vendor. For high-risk applications it can be worth making sure the firewall is set to block threats and not just alert. The downside to this is that legitimate traffic can also be blocked in some cases and tuning is required to make sure you get it right. Some firewalls let you set block/detect on a per rule basis.

Microsoft also published this advice for mitigating the risk to applications where patches are not available.

In case the Log4j 2 vulnerable component cannot be updated, Log4J 2 versions 2.10 to 2.14.1 support the parameter log4j2.formatMsgNoLookups to be set to ‘true’, to disable the vulnerable feature. Ensure this parameter is configured in the startup scripts of the Java Virtual Machine:
-D log4j2.formatMsgNoLookups=true
Alternatively, customers using Log4j 2.10 to 2.14.1 may set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to force this change.
Kubernetes administrators may use “kubectl set env” to set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to apply the mitigation across Kubernetes clusters where the Java applications are running Log4j 2.10 to 2.14.1, effectively reflecting on all pods and containers automatically.
For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class