When the Log4j vulnerability emerged on December 9th 2021, it was classified as a moderate risk by the Apache Logging Security team. The response from the open source community was swift and Apache released Log4j 2.15.0 for Java 8 users on December 10, 2021 to address the CVE-2021-44228 vulnerability. Rightly, the urgency was placed on security teams to identify if the software was embedded somewhere in their infrastructure or wider interconnected ecosystem.
Now a severe vulnerability, deadlines to patch/update software against emerging threats keep coming. The CyberSecurity & Infrastructure Security Agency (CISA) put a deadline of Christmas Eve for its Federal agencies to mitigate internet and non-internet-facing federal information systems. Regardless, the threat continues to unravel. Five CVEs Linked to Log4j have been addressed by Apache in less than a month with additional vulnerabilities CVE-2021-45046, CVE-2021-4104, found on December 14; CVE-2021-42550, found on December 16; CVE-2021-45105, found on December 17; and CVE-2021-44832, found on December 28.
The Federal Trade Commission (FTC) has since threatened companies with “legal action” over unpatched Log4j, saying: “When vulnerabilities are discovered and exploited, it risks a loss or breach of personal information, financial loss, and other irreversible harms. The duty to take reasonable steps to mitigate known software vulnerabilities implicates laws.”
The first company to have discovered and reported the Log4J vulnerability is Alibaba Cloud. It is now facing a backlash from the Chinese government for not informing the national Ministry of Industry and Information Technology in a timely manner, having instead first reported the vulnerability to Apache.
What is Log4j and who is affected by the vulnerability?
Almost every bit of software you use will keep records of error messages and other important events, known as logs, that help applications run smoothly, determine what’s happening, and help with the debugging process when errors occur.
Log4j is a Java library for logging this information in enterprise applications, which includes custom applications, networks, and many cloud computing services. It is an open-source logging package and one of the most commonly used ones in the world.
Due to its popularity, the flaw now affects millions of pieces of software, running on millions of machines with which many systems interact. This includes a large percentage of the Java programs developed in the last decade for both server and client applications. It is useful to note, Censornet does not use these.
How are hackers exploiting it?
Attackers can exploit the vulnerability by abusing a Log4j feature that allows users to specify custom code for log message formatting. Third-party servers are then able to submit software code that can perform all kinds of actions on the targeted machines including crypto mining, establishing remote shells, mass-scanning and red-team activity.
Attackers can also use Cobalt Strike to steal passwords and logins, to perform lateral movement extracting data from compromised systems or form botnets as leverage. There are also cases of state-backed Chinese and Iranian hackers having already exploited the flaw, presumably for cyberespionage.
What’s the best line of defense?
Affected users should focus, when possible, on these four actions:
- Upgrade to the latest software as soon as possible. This not only includes the newest version of Log4j, but also all your software to reduce the risk of being compromised.
- Even if you apply the latest version / patch there is still a chance of having been compromised already which brings us to the next two points.
- Scan your network to keep an eye out for suspicious activity and also preemptively scan your code for potential vulnerabilities. Authenticated scanners can be used to identify these Log4j vulnerabilities, with the ones with the greatest exposure most likely being internet-facing.
- Set up alerts for probes or attacks on devices running Log4j, and more specifically install a web application firewall (WAF) with rules to focus on Log4j.
It is important to keep in mind that there is no instant-fix to the Log4j vulnerability so we need to remain alert in the long-term.
Understanding the seriousness of the Log4j vulnerability in the long-term
The Log4j vulnerability could be an issue for years. This is due to the challenge of finding Log4j as most software that depends on it does so indirectly. The way it is implemented and developed means it could be inserted somewhere down the supply chain. With so much software having various vendors and products, it can be almost impossible to know the extent of exposure when the vulnerability is so deep in a dependency chain.
The seriousness of the Log4j vulnerability is probably going to get worse before it gets better, with an increasing amount and complexity of attacks. Whilst the vulnerability has mostly been exploited for crypto mining to date, more sophisticated actors are coming. More disruptive attacks such as extortion, ransomware and cyberespionage are just around the corner.
