Thoughts on Log4Shell
On December 9th, the open disclosure of Log4j vulnerability, known as Log4Shell (CVE-2021-44228), sent shockwaves through the infosec community. Most researchers consider is to be one of the worst cyberthreats in recent years. With a severity score of 10 out of 10 (CVSS v3.1), this remote code execution (RCE) vulnerability enables malicious actors to execute arbitrary code that could allow them to take over a targeted system from anywhere in the world.
Amazon, Apple, Cloudflare, Google, Tencent, Twitter and almost every company that uses Java were vulnerable targets at some point. Further expanding its attack surface, Log4Shell also affects the embedded systems and various electronic control units (ECUs) in connected cars. This includes charging stations, in-vehicle infotainment (IVI), and remote keyless entry (RKE) systems, among others. In a research published last week, Trend Micro security researcher Sébastien Dudek discussed just how Log4j vulnerabilities also affect the automotive industry.
The vulnerability was privately disclosed to the Apache Software Foundation by Chen Zhaojun of Alibaba Cloud's security team on November 24, 2021, but it remained unnoticed until its public disclosure on December 9, 2021. The exploitation process involves an attacker sending a malicious payload through user-supplied input, such as an HTTP header or any data logged by the application. The application then logs the user-supplied input using Log4j, which interprets the malicious payload and performs a JNDI lookup to connect to a malicious LDAP server. The malicious LDAP server responds with instructions to load and execute a remote Java class file, leading to full system compromise.
The ease of exploitation and the ubiquity of Log4j made it a prime target for attackers, leading to a surge in exploitation attempts. The most effective remediation for Log4Shell is to upgrade Log4j to version 2.16 or later. However, for organizations that cannot upgrade immediately, applying patches or following mitigation guidelines provided by security organizations like CISA can help reduce the risk.
Having personally experienced the Log4j vulnerability, I can attest how fucked up it can be. The event idled the entire backup architecture, which was predominantly based on Solaris and Dell systems. We tested a PoC on one of the vulnerable machines and gained root access, thus giving us the control over backup archives, tools, and log files. The entire containment and remediation process will surely take several months to manage, involving identification and patching of all affected systems.