Log4j vulnerability is one of the biggest topics recently. A zero-day vulnerability affecting widely used software component that is being actively exposed in the wild. What could be worse. Almost every big company having many different external and internal systems, is affected. Before it is not too late and the vulnerability is not exploited by external actor, it is crucial to perform Log4j scanning and find out if software that you use is vulnerable.
For those of you that are not working with Java, this component might be unheard of. But you probably know Apache – one of the most famous webservers. And the Log4j is an Apache logging library that is used in many products.
Many different widely used products are using the log4j library. So it is scary to realize that there are dozens of widely adopted products that are vulnerable. Even thought official patches were released for many of them, not everyone had updated their systems.
Vulnerability has a CVE number assigned – CVE-2021-44228.
How serious is this vulnerability?
Vulnerability has a CVSS 10.0 rating (out of 10), so it is pretty dangerous and is a critical vulnerability. All Log4j2 versions prior to 2.15.0 are vulnerable to remote code execution.
As many different actors are scanning the net and searching for affected systems, it is crucial to utilize log4j scanner to find out if you are vulnerable. And if so, to take the needed actions.
Log4j Scanning
As this is a very serious vulnerability, that lets the attackers execute code remotely, you should take it seriously. Keep in mind that if you are using software that has the Log4j component, it might be affected, and a malicious actor could take over your system.
If the scanner had not validated that the system is vulnerable, it does not mean that it is safe. It should still be updated. Exploitation depends on the JVM used and the configuration, so it might not be that easy to exploit it. But if a malicious hacker manages to do it, the consequences could be dangerous.
Let’s get to the point – you can use FullHunt Log4j scanning tool to assess your system. You can download it from the GitHub repository:
git clone https://github.com/fullhunt/log4j-scan
After that cd into project’s directory (cd log4j-scan) and install the needed dependencies:
pip3 install -r requirements.txt
If everything worked out, you should be able to run the script:
python3 log4j-scan.py
These are the arguments you can use:
usage: log4j-scan.py [-h] [-u URL] [-l USEDLIST] [--request-type REQUEST_TYPE]
[--headers-file HEADERS_FILE] [--run-all-tests]
[--exclude-user-agent-fuzzing] [--wait-time WAIT_TIME] [--waf-bypass]
[--dns-callback-provider DNS_CALLBACK_PROVIDER]
[--custom-dns-callback-host CUSTOM_DNS_CALLBACK_HOST]
optional arguments:
-h, --help show this help message and exit
-u URL, --url URL Check a single URL.
-l USEDLIST, --list USEDLIST
Check a list of URLs.
--request-type REQUEST_TYPE
Request Type: (get, post) - [Default: get].
--headers-file HEADERS_FILE
Headers fuzzing list - [default: headers.txt].
--run-all-tests Run all available tests on each URL.
--exclude-user-agent-fuzzing
Exclude User-Agent header from fuzzing - useful to bypass weak checks on
User-Agents.
--wait-time WAIT_TIME
Wait time after all URLs are processed (in seconds) - [Default: 5].
--waf-bypass Extend scans with WAF bypass payloads.
--dns-callback-provider DNS_CALLBACK_PROVIDER
DNS Callback provider (Options: dnslog.cn, interact.sh) - [Default:
interact.sh].
--custom-dns-callback-host CUSTOM_DNS_CALLBACK_HOST
Custom DNS Callback Host.
To scan one target, you can simply run the script with this command:
python3 log4j-scan.py -u http://IP_ADDRESS
As you can see, the target was not vulnerable, so “Targets does not seem to be vulnerable” message was displayed. If the target was vulnerable, the message would state accordingly.
If you want to scan a list of IP addresses, that are in text file, and run all tests, you can start the scan like this:
python3 log4j-scan.py -l IPs.txt --run-all-tests
How does the Log4j exploit work?
Before diving into the Log4j exploit specifics, we must understand how does the component work. It is a logging component that logs requests that a client sends to the server. And the problem occurs when the client modifies his requests and adds a specific payload, that is being executed on the server.
And the main problem is that Log4j JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.
This can be exploited in the following way:
- Attacker modifies the request and adds the JNDI lookup in a header, sends the request to the server.
- Server logs the request with a malicious payload
- Log4j interpolates the payload and qeuries the malicious LDAP server
- LDAP server passes the information where the malicious Java class is
- Server downloads the malicious code and executes it
From the application perspective, you can prevent this from happening during different stages of the attack (refer to the image above).
My System is Vulnerable to Log4j Vulnerability! Now What?
In case you detected that your system is vulnerable to Log4J vulnerability, that is also known ass Log4shell, or LogJam, there are a few things you should do:
- You should upgrade the software that uses this logging library immediately.
- If you can’t upgrade it, or vendor does not released the fix yet, you should restrict access to the system. Of course, this might not be the way to go if business operations requires it to be public. But if it is possible, it is advised to restrict access from the external network until the software will be upgraded
- Another countermeasure if updating is not possible, is to configure WAF to block the attack. However, keep in mind that some of the PoCs that can be found around the internet, have WAF bypass functionality. So this might not be the perfect solution
- Set the log4j2.formatMsgNoLookups property, or LOG4J_FORMAT_MSG_NO_LOOKUPS env variable to True, to disable the lookup functionality
While Log4j scanning is just a first step, make sure you patched the software before malicious hackers find out.
Highly passionate about cyber security (penetration testing, bug bounty hunting, cybersecurity in general), and blogging. I am experienced in vulnerability assessments, penetration testing, various security audits, had worked with various clients, most of them were in finance sector.
CompTIA Security+, CEH, CEH Practical, CEH Master, and OSCP certified.