On Thursday (December 9th), a 0-day exploit in the popular Java logging library log4j (version 2) was discovered that results in Remote Code Execution (RCE) by logging a certain string.
Given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe. This exploit is also known as "Log4Shell".
The 0-day was tweeted along with a POC posted on GitHub. It has now been published as CVE-2021-44228.
More resources are available at https://log4shell.com/
Impact
Many services are vulnerable to this exploit including cloud services (Steam, Apple iCloud); apps like Minecraft, Apache Struts; and any software that embedded Log4J as logging package.
Affected Apache Log4j Versions
From the initial investigation, almost all version of log4j v2.0 till v2.14.1 are vulnerable. And version 1 of log4j is vulnerable too.
How the exploit works
- A server with a vulnerable log4j version installed/embedded.
- An endpoint with any protocol (HTTP, TCP) that allows attacker to send the exploit string.
- A log statement that logs out the string from the requester.
- Outgoing connection to a malicious LDAP and RMI server.
This means, by limiting outgoing connection, we can prevent loading the exploit and mitigating the vulnerability. However, it is not possible to just block specific ports, LDAP (389/tcp) and RMI (1099/tcp/udp). The attacker can hosts the exploit payload at any arbitrary ports.
It might be possible with application layer firewall inspection to restrict the outgoing protocols, ie LDAP and RMI should be blocked.
Alternatively, one might deploy a HTTP proxy and restrict outgoing traffic thru the proxy only since LDAP and RMI do not work over a HTTP proxy.