What is the Log4Shell Vulnerability?
Log4j is a logging library written in Java and the vulnerability, CVE-2021-44228, also commonly known as Log4Shell, allows a remote actor to send a crafted HTTP packet to servers or other software suite exposed to the internet, running the version below Log4j 2.15.0.
First discovered on 8 December 2021 and made more widely known on 9 December, a major remote code execution vulnerability in Apache's Log4j technology was disclosed which affects software products and applications that use the Apache Log4j library. The vulnerability allows remote users to compromise the systems running this service by sending a specially crafted HTTP packet to web servers running this library.
Its key characteristics are:
- Ease of exploitation: What makes CVE-2021-44228 especially dangerous is how easy it is to exploit. Someone who is an inexperienced hacker can successfully execute this attack simply by sending a single request that forces a log entry to be written. This will then enable the attacker to upload their own code into the application.
- The prolific use of Apache Web Servers and the Log4j library: This library is used in millions of websites, applications, and platforms, including a wide range of Apache products. It is also used in gaming platforms such as Minecraft.
- Proof of concept code exists now and proactive scanning has started already: The issue was discovered on 9 December and active scanning for this vulnerability started almost immediately. Vulnerability scanning tools have been updated to detect this issue and security products and tools themselves are being patched (where fixes are available).
How was the Log4Shell Vulnerability discovered?
Widespread scanning has begun with exploitation initially focussed on coin-mining activity (Kinsing malware), but this is likely due to the initial focus on Minecraft server exploitation. Further exploitation has been associated with the deployment of botnet malware such as Mirai and Tsunami. However, Log4j has a near-ubiquitous presence in almost all major Java-based enterprise apps and servers.
Can you detect someone trying to exploit the Log4Shell Vulnerability?
Users can detect traffic attempting to exploit the software by monitoring packet captures or web server logs by looking at the string '{jndi:ldap://}' which is required to initiate the exploit. Most commonly this is in the User-Agent field, but may be found elsewhere if other protocols are used to initiate the traffic. This has been validated by POC code published to GitHub.
Note that this is only one potential exploitation of the vulnerability which uses JNDI lookup. There are other schemes that allow lookup as well, including:
- {web:http://…} which you can use for SSRF
- {env:…} which you can use to extract environment variables out of the server, .e.g AWS keys
What happens next now the Log4Shell Vulnerability has been uncovered?
With a score of 10/10 on the CVSSv3 severity scale, Log4Shell is as serious as it gets in terms of security flaws, being both remotely exploitable and requiring little technical skill to execute.
Industry commentary have compared it to potentially having the same level of impact as the Heartbleed and ShellShock vulnerabilities. Initial noise associated to Log4j is likely to be mass-scanning by security researchers and tentative reconnaissance from threat actors who are both looking to assess the scale and impact of the vulnerability in the operating landscape.
Remediation activity focussed on Log4j is likely to take a few weeks as vendors that have built capability on the underlying technology look to push out patches in the coming weeks. Couple this with the usual seasonal pressures on IT departments and threat actors will look to take advantage of those that do not prioritise appropriate patching.
What should you do to protect against the Log4Shell Vulnerability?
Assess your estate: Quickly understand your affected products. Review your asset database and vendors’ products immediately for use of Apache Log4j. Recognise that vulnerability scanners may not detect or pick up all cases where this library is in use.
Test and validate: Use vulnerability management tools to help scan your environment and follow up with penetration testing activity to validate the exploitability of systems if unsure.
Monitor and detect: It will take time for you to understand where in your environment you are affected, so start to look for evidence of attacks and exploitation as soon as you can. Use a WAF to protect your public-facing systems and block/alert of activity related to this vulnerability and the use of scripts.
Apply Fixes/Remediation: As soon as they become available apply the fixes and remediation actions from the relevant vendors. Upgrade to Log4j version 2.15.0, or apply their appropriate vendor recommended mitigations immediately. You should also update your Java instance to the latest version.
In response to the Log4Shell vulnerability, LRQA have updated our Penetration Testing methodology to specifically test for this vulnerability. We have helped a number of our clients mitigate against this critical risk issue on their external and internal estate. If you would like LRQA to carry out a Penetration Test to ensure your estate and systems are not susceptible to this vulnerability, please contact us.