Thread by @SophosLabs

#Log4Shell Hell: anatomy of an exploit outbreak

A vulnerability in a widely-used Java logging component is exposing untold numbers of organizations to potential remote code attacks and information exposure...

1/16

On December 9, a severe remote code vulnerability was revealed in Apache’s Log4J , a very common logging system used by developers of web and server applications based on Java and other programming languages. 2/16

The vulnerability affects a broad range of services and applications on servers, making it extremely dangerous—and the latest updates for those server applications urgent. 3/16

The vulnerability makes it possible for any attacker who can inject text into log messages or log message parameters into server logs that load code from a remote server; The targeted server then executes that code via calls to the Java Naming and Directory Interface (JNDI). 4/16

JNDI interfaces with a number of network services, including the Lightweight Directory Access Protocol (LDAP), Domain Name Service (DNS), Java’s Remote Interface (RMI), and the Common Object Request Broker (CORBA). 5/16

@Sophos has seen efforts to exploit LDAP, DNS and RMI, using a URL tagged to those services redirected to an external server.

Sophos is already detecting malicious cryptominer operations attempting to leverage the vulnerability, and... 6/16

...there are credible reports from other sources that several automated botnets (such as Mirai, Tsunami, and Kinsing) have begun to exploit it as well. Other types of attacks – and payloads – are likely to rapidly follow. 7/16

While there are steps server operators can take to mitigate the vulnerability, the best fix is to upgrade to the patched version (Log4j 2.15.0.) But, rolling out an upgrade may not be that simple—especially if organizations don’t know where it’s been deployed as a component. 8/16

Similar critical JNDI injection vulnerabilities have been found in other Java server components in the past, including one in the Internet Inter-ORB Protocol (IIOP) implementation of Oracle’s WebLogic Server (CVE-2020-2551). 9/16

The widespread use of Log4J in commercial and open-source software connected to the Internet—web and mobile application servers, email servers (including Apache’s Java-based JAMES email server), and cloud services—makes this a difficult vulnerability to track down & patch. 10/16

Sophos has already detected hundreds of thousands of attempts since December 9 to remotely execute code using this vulnerability, and log searches by other organizations (including Cloudflare) suggest the vulnerability may have been openly exploited for weeks. 11/16

The instances detected by Sophos have been mostly scans for the vulnerability, exploit tests, and attempts to install coin miners.

We have also seen attempts to extract information from services, including Amazon Web Services keys and other private data. 12/16

👉 Detection and correction

Resolving the Log4J vulnerability requires defense in depth. Organizations should deploy rules to block exploit traffic from all internet-facing services (Sophos IPS currently blocks traffic matching known Log4J exploit signatures). 13/16

Long-term protection will require identifying and updating instances of Log4J or mitigating the issue by changing settings in Log4J... 14/16

... (either through XML or YAML configuration files in the root of Log4J’s path settings, or programmatically). That may require code changes in products where Log4J is embedded. 15/16

SophosLabs would like to acknowledge the contributions of Fraser Howard, Hardik Shah, @GaborSzappanos, and Mukesh Kumar for their contributions to this report.

See all the details from @thepacketrat...

news.sophos.com/en-us/2021/12/…

16/16