A serious flaw in the Log4j framework enables cybercriminals to gain access to vulnerable systems by injecting a single malicious code. This vulnerability is known as Log4J, a free logging library distributed by the Apache Software Foundation.
Java is used in a vast array of contemporary digital products, including web servers, cloud solutions, and applications – making all of these products vulnerable to hacking through the Log4Shell vulnerability.
In other words, your Linux machine is also vulnerable.
A Wall Street Journal report states that researchers identified over ten million Log4Shell attacks every hour when the vulnerability was first made public. Many organizations are unaware that there is such a vulnerability and that they may be attacked.
But you can protect yourself from getting hacked by taking some simple steps. In this post, break down the vulnerability’s details and walk you through how you can protect your Linux system against Log4Shell.
Log4Shell Background
On 9th December 2021, an Alibaba Cloud Security Team researcher released a zero-day Remote Code Execution exploit straight to Twitter. The exploit targeted the popular Log4J framework, specifically the 2.x branch of the framework, called Log4J2.
While many question the ethics of releasing such a dangerous exploit to the public, Alibaba’s Cloud Security Team reported the vulnerability to Apache on 24th November.
The MITRE Corporation, a non-profit based in the US, assigned the vulnerability the Common Vulnerabilities and Exposures ID CVE-2021-44228. However, the security flaw has been dubbed “Log4Shell” by researchers.
As mentioned earlier, Log4Shell has been massively exploited by hackers worldwide since 9th December 2021. With weaponized PoCs available all over the internet, untrained malicious actors also took advantage of the fact that most systems remain vulnerable.
The mass exploitation of the vulnerability received wide coverage in the media. Since then, Apache has patched the vulnerability four times, of which two patches had security vulnerabilities. The vulnerabilities introduced in these updates were given unique CVE IDs.
How the Log4Shell Attack Works
The flaw in the framework enables hackers to inject code into a target network remotely and gain full control over it. But before we break down the sequence of the attack, let’s understand how loggers work.
Servers use logger libraries such as Log4j to circumvent archiving of information after it is collected. If some actions are required in response to specific log data, or if the logged data is actively analyzed, Java developers use libraries such as Log4j to parse the data before it is archived.
In other words, any business that uses the vulnerable Log4j library risks giving away complete control of their backend systems to hackers.
The problem is that the logger executes code based on input, and the vulnerability enables hackers to manipulate input data. In this way, the logger can be forced to execute malicious code.
Here’s a technical explanation of this:
When a specially-written string is passed to the vulnerable logger, it will connect to an LDAP server, download the code in its directory, and execute it.
Hackers can create malicious LDAP servers with code that can take over any server on which it is executed and send the APIs/databases/applications the string that points to this malicious code.
What Makes Log4Shell a Critical Vulnerability?
Security researchers worldwide consider the Log4Shell vulnerability one of the worst security flaws in the history of technology. The Apache Software Foundation gave the vulnerability a CVSS score of 10 (out of 10) – the highest possible score indicating the flaw’s severity.
A CVSS 10 score is rarely given to flaws, but CVE-2021-44228 is an exception since attackers can easily exploit it. The sentiment that it is the worst security flaw to have existed so far is supported by the following two factors:
#1 It is Tremendously Easy to Exploit
To exploit this security flaw, all a malicious actor needs to do is insert a string into a common log event, and then they can inject a payload into the system.
Inserting this string doesn’t require much technical skill, which explains the millions and millions of attacks researchers recorded every hour in the aftermath of the exploit’s release.
More terrifyingly, the average Joe can find a multitude of exploits on GitHub and other public sources and attack unsuspecting users.
#2 It Can Impact Any Java Software
Log4j is one of the most popular Java logging libraries, which means the vulnerability can impact all the software that uses Java. Java is used on billions of machines across the globe, making it difficult to quantify the number of systems affected by this vulnerability.
Ordinary citizens forget that everything from their internet routers to the Amazon and Twitter servers they access every day could be hacked due to this security flaw.
Moreover, while phones don’t directly run Java, they could also be vulnerable to this flaw. The backend systems of phones typically interact with the Log4j library using APIs. In other words, an attacker could send a malicious string to an iPhone, inject it into its backend, and comprise the phone.
But the worst part is that software having the Log4Shell vulnerability does not need to be connected to the internet to be exploited. Malicious strings could, in theory, permeate backend software, even if the web application connected to the internet does not use Java.
In other words, if you’re a developer and none of your web apps or backend software use the vulnerable versions of Log4j, the third-party vendors you work with may be using them. This exposes your ecosystem to the risk of a third-party breach.
The simplicity of the vulnerability and the huge variety of attack vector options has made Log4Shell the preferred exploit for cybercriminals.
Check Point, a security firm, detected over 60 variations of the original hack in the first 24 hours of the vulnerability becoming public. One can only imagine the number of exploits available to hackers today.
How to Scan Your Apache Server for the Vulnerability
The easiest way to detect whether any remote endpoint is vulnerable to Log4Shell exploits is to trigger a DNS query. As mentioned in the breakdown of the exploit, the server will try to retrieve some remote code.
Since the vulnerability impacts nearly every online business, it’s no surprise that several free and paid tools are available for admins to test their servers for the vulnerability.
One of the free scanners that you can use is the Log4j-RCE-Scanner. It allows you to scan your machine for the RCE flaw on Apache Log4j at multiple addresses.
Installing the Log4j-RCE-Scanner on Linux
You cannot use the scanner before installing its dependencies, which are curl and httpx.
Installing curl is simple on Debian- and Ubuntu-based machines. All you have to do is run the following command:
|
sudo apt install curl |
If you’re on Arch Linux, you can use the following command:
|
sudo pacman -Sy curl |
And if you’re on Fedora or CentOS, running this command will install curl:
|
sudo yum install curl |
After installing curl, you can install httpx with these commands:
|
git clone https://github.com/projectdiscovery/httpx |
Finally, you can clone the repository of the Log4J-RCE-Scanner tool with this command:
There are two more steps to complete the installation. Firstly, you must access the new directory you have created:
|
cd Log4j-RCE-Scanner/ |
Then, you can give the bash script of the scanner tool the necessary permissions for execution:
|
chmod +x log4j-rce-scanner.sh |
Using the Scanner
You can get to the fun part when the scanner is installed: using the tool to check for vulnerabilities. To get access to the help section of the script, run this command:
|
bash log4j-rce-scanner.sh -h |
Of course, you can skip the above step if you like and get straight to scanning your Apache server for Log4Shell:
|
bash log4j-rce-scanner.sh -d [domain] -b [Burp collaborator] |
Bear in mind that you can use the -b and -d switches to specify your Burp collaborator and domain, respectively. If the scanner indicates that your domain is vulnerable, the DNS callbacks having the name of the vulnerable domain are sent to the Burp collaborator.
You can also use the -l switch to specify a list of domains.
Scanning Linux Servers with a Python Scanner
If you do not want to use a bash script tool and would rather use a Python script, you can use the log4-scanner developed by the CISA of the United States. You must begin by cloning the repository:
|
git clone https://github.com/cisagov/log4j-scanner/ |
Next, you need to access the directory with the simple cd command:
|
cd log4j-scanner/log4-scanner/ |
Remember to install the necessary dependencies with the pip3 command that works using Python:
|
pip3 install -r requirements.txt |
Finally, you are ready to use the scanner. To scan a single URL, use the -u switch, like so:
|
python3 log4j-scan.py -u example.com |
If you want to scan a list of URLs, use the -l flag, like so:
|
python3 log4j-scan.py -l list.txt |
To access help pages integrated into the script, you can use the -h switch, like so:
|
python3 log4j-scan.py -h |
How to Protect Your Linux System Against Log4Shell
Since the vulnerability is still quite recent, attackers continue to try using it to attack machines. It’s important to remember that the CVSS score of 10 makes Log4Shell a highly critical security flaw.
There are a few different ways of protecting your machine against Log4Shell exploits:
#1 Update Your Apache Configuration
A fixed version of the Log4j library was made available early in 2022, but many libraries have not patched the vulnerability. To ensure you’re not one of them, you must use the quickest and most effective way to protect yourself – update all instances of your Log4j library to the latest version.
Per reports by Apache, CVE-2021-45105 is fixed from Log4j version 2.17.1. Installing the latest version of the library will protect you from future attacks, but it will not remediate any damage that may have been caused before the update.
Since the security flaw is ubiquitous, it’s best to assume that your machine and ecosystem have already been hacked and initiate a data breach incident response.
Even if a business does not use the Apache logger, it’s best to assume a data breach since a zero-day attack can compromise the entire ecosystem.
Besides initiating incident response and adopting a breach mentality, businesses need to review all server logs for indicators of compromise.
With the fair warnings out of the way, let’s get into how to install the latest version of Apache on your Linux machine.
You can check the current version of Apache on your server in many different ways. You could approach this via GUIs by visiting the administration panel – this could be cPanel or WebHost Manager.
Alternatively, you can run the httpd command with a -v switch, like so:
|
httpd -v |
If you’re using an Ubuntu or a Debian system, you can update your Apache configuration to the latest version using this command:
|
sudo apt update && sudo apt upgrade apache2 |
If you’re on CentOS, you can run this simple command to update your Apache configuration:
|
sudo yum install httpd |
#2 Disable JNDI
A flaw in the JNDI Lookup plugin is the root cause of the Log4j vulnerability. The plugin facilitates code execution using the data it finds in the log, and this is the data that can be manipulated with ease since the logger accepts the data without any verification.
Once a malicious string is injected into the logger, the logger will consider that the operations indicated by the string are a part of the original codebase and execute it instantly.
Recently, security researchers found that the plugin has always permitted sending unparsed information to the Log4j library. This critical flaw has been in the plugin since its first release in 2013!
You can protect yourself by disabling the JndiLookup class since the logger will then not be able to take any actions based on the data in the log.
The good news is that JNDI has been disabled by default in Apache configurations since Log4j version 2.16.0. Updating to the latest version should suffice.
However, if you do not want to update, you can secure your machine by removing the JndiLookup class.
#3 Update Your Firewalls
Update all of your firewalls and intrusion prevention systems with the latest rules and signatures. Patching your protection systems could block or filter LDAP and RMI traffic attempting to connect with malicious LDAP servers.
#4 Use Multi-Factor Authentication
Implementing strict VPN policies and using multi-factor authentication can make further exploitation difficult for attackers if they gain network access through Log4Shell exploits.
Frequently Asked Questions
#1 Which versions of Apache Log4j are vulnerable to Log4Shell?
All versions of the library below version 2.1.7.1 are vulnerable. Although version 2.15.0 fixed most of the exploitable elements, 2.1.7.1 completely fixed the vulnerability.
#2 Is a Burp Collaborator utility a must-have to receive DNS callbacks having vulnerable domain names?
The developer of the Log4j-RCE-Scanner tool states that the Burp Collaborator is used alongside the script to receive the DNS callbacks. However, Linux users can also use an Interact.sh address.
