Log4j vulnerability – detecting and protecting against the exploit with Elastic Security
Log4j is a very popular Apache open source logging library used in many applications and 3rd party software. In December 2021 a vulnerability was made public.
We’ve simulated this vulnerability for demonstration purposes only, but it also illustrates how easy it is to run this log4j exploit.
If you haven’t patched up your system yet, we recommend you do it ASAP or ask for our help!
Log4j is a very popular Apache open source logging library used in many applications and 3rd party software. In December 2021 a vulnerability was made public. If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software.
Assuming the vulnerability was not discovered or made public, how would Elastic Security handle this? We went ahead to show the capabilities of Elastic Security, as an answer to this question in this blogpost.
We created a VM running Linux mint. On this host Elastic Endpoint Protection was installed. A docker container was set up in which an LDAP webserver was running, that was not patched to solve the Log4j vulnerability.
The web page hosted by the server was accessible via localhost as well as its IP address.
For the attacker, a Linux Kali VM was set up. Via reverse shell, this VM tried to gain access to the target system. This was achieved by sending code through the website's login page which log4j would execute, this code would give access to the Linux machine which will be listening on the port specified, effectively creating a reverse shell.
The screenshot demonstrates this. On the right you see the login page hosted on the Linux mint machine and on the left side, the kali Linux machines terminal listening to any incoming connection attempts using netcat. With the connection established we effectively became the root user. Demonstrated by the ‘whoami’ command returning root.
The following step will be converting the Simple Shells to Fully Interactive TTYs. A Python pty module was used, which made it possible to run commands such as ‘su’. This made it possible to create new users with more rights and provided a true ssh shell from the target machine. From here on it was possible to enable ssh and fully connect to the target.
To deliver the payload to the target system, a simple python web server was hosted on the attacking kali VM.
Via the fully-functioning reverse shell, the malware was downloaded on the target using wget specifying the link to the website (on the attacking machine).
What do we see in Elastic?
What happened with the downloaded file, we will keep for last!
Elastic stores all data which allows alerting on suspicious events and inspection of the security incidents, also this one, in more detail.
The illustration shows the “path to download”.
The detailed information in elastic shows that a file was downloaded via a root ssh connection. This is especially suspicious as a root login via ssh is disabled by default. This alerts the security analysts to investigate and take action.
The detailed information shows that the attacker’s machine could still make ‘malicious’ connections to the target. In this situation, Elastic Endpoint Protection allows to isolate the attacked host to avoid further spread of the infection. Isolating the attached machine provides time to find the root cause, the log4j vulnerability in this example, and to deploy the final solution (log4j patching).
But finally, what happened with the downloaded file?
Immediately after the file was downloaded to the target system, the Elastic Endpoint Security stopped the malware from executing, which means no harm was done. So that’s great news!
