This post appears to have triggered a maelstrom in both security and hacker communities. Before Apache made the necessary update, a tweet was posted on December 9 th, insinuating that abusing JNDI Lookup in Log4j can lead to remote code execution. In response, Apache published a release candidate on December 6th to address this vulnerability, which Alibaba’s Cloud Security team found insufficient. On November 24 th, Alibaba’s Cloud Security Team reported a critical vulnerability in Log4j to The Apache Software Foundation. It is also worthy of a mention that Minecraft was the canary in the coalmine highlighting the problem, as it was one of the first servers to be attacked. According to Cloudflare, the exploit was found as early as December 1 st, nine days before the patch release. Interestingly, the initial exploit leveraging CVE-2021-44228 appears to have been created before the patch was released. This forms the basis of several exploitation attempts currently seen in the wild, whereby insecure JNDI lookups potentially allow an unauthenticated, remote attacker to execute arbitrary code. The Log4j framework provides an interface with the JNDI (Java Naming and Directory Interface), which allows a connection to an external directory service such as LDAP (Lightweight Directory Access Protocol). An attacker simply needs to get the app to log a special string to successfully exploit this vulnerability. Millions of applications, such as iCloud, Steam, and Minecraft, use Log4j for logging. The ubiquitous nature of Log4j is part of what makes CVE-2021-44228 so dangerous. Often, a dependency on Log4j will be two to three layers deep (a dependency of a dependency). Log4j is an extensible, Java-based logging framework widely used by applications and services around the globe (CISA list of related software). Impact: Remote attackers gain control of the vulnerable systems Impacted Users: Any organization that uses vulnerable version of Log4j This blog describes what you need to know about the Apache Log4j vulnerabilities, including details, campaigns associated with Log4j, and an alleged “wormable” Mirai malware variant.Īffected Platforms: Any application and service that uses vulnerable version of Log4j2 Various chatter on OSINT channels has discussed whether this is a "worm." On December 19 th, a "wormable" variant of the Mirai IoT malware incorporating exploit code for CVE-2021-44228 was discovered. This fix was released in response to a newly discovered vulnerability that makes Log4j susceptible to a Denial-of-Service attack (DoS). On December 18 th, a third Log4J vulnerability was discovered ( CVE-2021-45105 - Apache Log4j2 does not always protect against infinite recursion in lookup evaluation). This promoted Apache to update the advisory and upgrade the CVSS score for this vulnerability to 9.0. Things went from bad to worse on December 16 th due to the discovery of information leaks and the remote code execution nature of the vulnerability. It was initially identified as a Denial-of-Service (DoS) vulnerability with a CVSS score of 3.7 and moderate severity. On December 14 th, the Apache Software Foundation revealed a second Log4j vulnerability ( CVE-2021-45046). This has earned the vulnerability a CVSS score of 10 – the maximum. Officially labeled CVE-2021-44228, but colloquially known as “Log4Shell”, this vulnerability is both trivial to exploit and allows for full remote code execution on a target system. Beginning December 9 th, most of the internet-connected world was forced to reckon with a critical new vulnerability discovered in the Apache Log4j framework deployed in countless servers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |