A new zero-day vulnerability was discovered in Apache's popular Log4j logging service. Millions of Java programs use Log4j, a popular open-source logging application. "Log4Shell" is the name given to the underlying "improper input validation" flaw (CVE-2021-44228). By compelling a susceptible software to log a specified string of characters, it can be used to enable remote code execution on a compromised machine. There are a variety of ways to do this because apps log many different types of events.
The utility has been upgraded to version 2.15.0, which is currently accessible. However, locating instances of Log4j throughout their whole environment, especially if they are hidden in dependencies, may be difficult for security teams.
Recommended priority actions by the National Cyber Security Center:
1. Install the latest updates immediately wherever Log4j is known to be used This should be the first priority for all UK organisations using software that is known to include Log4j. The Log4j library is frequently used in software and the links below provide a non-exhaustive list of vulnerable products:
If your specific product is not listed, you can use the instructions provided below in Priority Action 2 to try and determine if Log4j is present. If your product is listed, please follow vendor advice on updating the software or applying mitigations. You should also keep refreshing the list in case a new product has been added. If your product is not listed and is vulnerable, you can request it be added to the list. Where a vendor has not provided an update to a product, the vulnerability can be mitigated in previous releases of Log4j (2.10 and later) by setting system property "log4j2.formatMsgNoLookups" to "true" or removing the JndiLookup class from the classpath.
Organisations should routinely run vulnerability scanning across their networks, to detect when updates are available.
2. Discover unknown instances of Log4j within your organisation To support the first priority action above, you also should now determine if Log4j is installed elsewhere. Java applications can include all the dependent libraries within their installation. A file system search for log4j can be undertaken. This should include searching inside EAR, JAR and WAR files. For example: find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null If a dependency or package manager is used, this can be searched. For example: dpkg -l | grep log4j
There could be multiple copies of Log4j present, each copy will need to be updated or mitigated.
3. Deploy protective network monitoring/blocking The following recommendations should be taken to improve network monitoring and blocking:
Organisations using Web Application Firewalls (WAFs) should ensure rules are available to protect against this vulnerability. These could include blocking URLs containing strings like “jndi:ldap”. It should be noted that variants of the exploit string may bypass current WAF rules. This means WAFs should not be relied on as the only control.
Organisations that understand normal outbound connections from their servers may wish to ensure they’re blocking unexpected outbound connections (particularly LDAP, LDAPS and RMI, however exploits may work over arbitrary ports). Putting in place blocks without understanding necessary outbound connections may prevent exploitation, but may also cause services to fail to work if they require outbound connections.