The issues with Log4j continue to pile up, and researchers have now discovered that remote code execution is possible when exploiting the latest vulnerability in version 2.15.0.
That flaw (CVE-2021-45046), which was disclosed on Tuesday, was originally classified as a denial-of-service bug, but later in the week researchers at Praetorian discovered that it was possible to use the bug to steal sensitive data from vulnerable machines, too. Now, the situation has become even more serious, as the Apache Software Foundation has confirmed that the flaw can be used for remote code execution in some limited, specific circumstances. The RCE is only known to work on macOS at this time.
“It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on macOS but no other tested environments,” the Apache advisory says.
The newer vulnerability affects version 2.0-beta9 through 2.15.0, except for version 2.12.2.
Apache is recommending that organizations update to version 2.16.0 of Log4j as soon as possible. If that’s not a possibility right now, organizations should remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. Apache has also updated the mitigations for the original Log4j flaw (CVE-2021-44228), because some of the original mitigation strategies were not effective in all cases.
“This vector significantly expands the attack surface."
“Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1,” Apache said.
“The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.”
In fact, researchers at Blumira discovered a new attack vector that enables an attacker to exploit the Log4j CVE-2021-44228 vulnerability by using a JavaScript WebSocket connection. WebSockets are used for a variety of purposes, including sending alerts from websites to browsers.
“This newly-discovered attack vector means that anyone with a vulnerable Log4j version on their machine or local private network can browse a website and potentially trigger the vulnerability. At this point, there is no proof of active exploitation,” Matthew Warner of Blumira said in a post.
“This vector significantly expands the attack surface and can impact services even running as localhost which were not exposed to any network.”