There has been a lot of talk in the media these last few weeks about Log4Shell, the Log4j vulnerability. Even if you don’t work in security or IT, you may have seen some of the news reports on the vulnerability, or viewed one of the many memes posted on social media portraying Log4Shell as a sneaky character creeping up on unsuspecting IT helpdesk workers as they get ready to (literally) unplug for the holidays.
But what exactly is this vulnerability, and who does it affect?
Log4Shell Explained
Log4j is a logging framework based on Java which is incorporated into Apache web servers all over the world. Log4j, like all software distributed by the Apache Software Foundation, is open-source. The Foundation states that it was distributed via a mirror system for many years, and then more recently, delivery has been switched to a content delivery network (CDN), which sends it directly to users and developers. It’s also delivered directly to organizations, who will then ship it to consumers and corporations as part of their projects, products, or services.
Put simply, Log4j is a piece of software which is used globally, and it is as ubiquitous in its use as the screws that hold together an everyday product, such as a table or a chair. The resultant product could then be sold and wind up anywhere – from a dorm room to a board room. Therein lies the problem.
Who Discovered the Log4j Vulnerability?
On the afternoon of Nov. 24, during the U.S. Thanksgiving holiday, Alibaba security engineer Chen Zhaojun found and privately disclosed to the Apache Software Foundation details of an easy-to-exploit remote code execution hole in the Log4j 2.x utility, specifically versions 2.14.1 and earlier.
“I want to report a security bug,” wrote Zhaojun, a member of Alibaba Group Holding Ltd.’s cloud-security team in China, adding “the vulnerability has a major impact.” As it turned out, that was no exaggeration.
The National Vulnerability Database maintained by NIST (National Institute of Standards and Technology) reported the vulnerability (CVE-2021-44228) on Dec. 10, stating in its advisory: “Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.”
How Many People Are Affected by the Log4j Vulnerability?
The Apache Software Foundation stated in a blog released on Dec. 14 that it would not even hazard a guess as to how large the impact of this vulnerability may be: “We know that Log4j is included in a number of ASF projects, other open source projects, and a number of products and services. But beyond that any numbers would merely be speculation and most likely wrong by a wide margin.”
The problem the IT world faces now, with many IT teams and security operations center (SOC) personnel already on holiday leave, is that the Log4j library is used by so many Apache framework services. Fixing it globally would be like telling everyone who owns a certain brand of car to personally check whether a potentially flawed engine part was lurking somewhere under the hood, then asking them to replace it themselves. Apache users don’t have the option of taking their servers to the dealership for a parts recall, if we continue with that particular analogy.
Long story short, a vulnerable application component, like Log4j, creates a complex security risk that is not universally fixable through a single update. Many businesses are still scrambling to issue their own in-house patches to prevent Log4j vulnerability exploits.
How is CVE-2021-44228 Exploited?
For those unfamiliar, exploiting the Log4j flaw is a simple matter of the attacker sending specially crafted text to a vulnerable application. Sending a particular sequence of characters instructs the Log4j library to fetch JAVA code from a remote server – throwing the (back)door to targeted systems wide open for attackers.
This is what makes the vulnerability so critical. The relative ease of the exploit means that even a novice attacker could take remote control of systems – ranging from Internet of Things (IoT) devices, to critical enterprise-connected systems – and perform actions as simple (and creepy) as spying on their next-door neighbor through their home security cameras, to wreaking national or even international havoc via mass infrastructural sabotage. Such an attacker doesn’t need a background in software engineering, they simply need to write (or copy) a line of code to gain access to the device of their choice.
Another major problem facing most organizations is knowing which applications use Log4j and how deeply embedded the library is in their products. A simple standalone application using the Log4j library may be easy to fix. However, consider the complexities of fixing an application built upon others, like a house of cards, where the vulnerable library is six levels deep in the dependency chain.
Fixing a deeply embedded security flaw can be a monumental task, even for those organizations who are well-equipped and aware of the problem. Unfortunately, Log4j is such a popular library that many businesses may be using affected products without realizing that they are susceptible to attack.
What Does a Log4Shell Attack Look Like?
Attackers are now working around the clock to take advantage of the vulnerability as fast as they can, before organizations realize they are affected. The level of activity suggests a gold-rush mentality, seizing the opportunity to subvert applications into performing remote code executions (RCEs). Often the goal is to gain an initial foothold from which they can indulge in further activities such as intellectual property (IP) theft, cryptomining, ransomware deployment, DDoS attacks, or all of the above.
Achieving success, from the attacker’s perspective, involves loading and then executing malware in the target environment. Even basic malware can perform a wide range of malicious activity on the victim’s device, from stealing banking credentials, to locking up systems and demanding a ransom to decrypt them, or exfiltrating treasure-troves of highly confidential information, such as that held by medical, financial, or governmental systems.
Security researchers have found that threat actors initiated mass scanning activity hours after the vulnerability was first publicly reported. Initially, the first attacks were exploratory in nature and were mostly focused on cryptomining. As of Dec. 9, active and widespread exploitation of the Log4j vulnerability had been identified in the wild by many external sources.
Microsoft has since confirmed nation-state activity from threat actors in China, Iran, North Korea, and Turkey. In addition, researchers at SecurityScorecard claim to have seen nation-state activity from Russia, along with evidence of the presence of Dovorub malware, a toolkit linked to APT28.
With each passing day, new reports are disclosing the distribution of malware families via the Log4j vulnerability, as threat actors perform ongoing attempts to exploit the vulnerability. For example, on Dec. 12, Check Point, a provider of cybersecurity solutions to government and corporate enterprises, said that it was seeing around 100 exploit attempts every minute, going into further detail in a blog post. The company also identified over 2.8 million attempts to exploit Log4j, stating that 46% of cyberattacks were from known threat actor groups.
Jim Simpson, director of threat intelligence at BlackBerry, said, "As we've seen time and again, state threat actors thrive in the noise, where attack efficacy is high, and attribution hampered by muddy water. This is prime real estate for them to move in and do their thing."
Cyberthreat actors are growing bolder as the month wears on, hoping to catch corporations and other targets before they can patch their systems. For example, on Dec. 13, BitDifender observed attackers deploying new Khonsari ransomware, the Orcus remote access Trojan (RAT), and XMRig (Monero CPU miner), among other malware. XMRig is especially hazardous for businesses of all sizes, as it essentially turns infected devices into cryptocurrency-mining botnet drones.
On Dec. 17, AdvIntel reported the Conti ransomware group was actively exploiting the Log4j vulnerability to target VMware vCenter networks. Most recently, on Dec. 20, a Bleeping Computer article discussed the discovery of the Dridex banking Trojan executing post-exploitation.
U.S. Federal Response
The Cybersecurity and Infrastructure Security Agency (CISA) has since created a leadership group within the Joint Cyber Defense Collaborative to address the Log4j vulnerability. CVE-2021-44228 has also been added to CISA's catalog of known exploited vulnerabilities. CISA Director Jen Easterly issued her first binding operational directive (BOD), instructing federal civilian agencies to "drive urgent and prioritized remediation" for actively exploitable vulnerabilities.
“Every day, our adversaries are using known vulnerabilities to target federal agencies,” said Easterly, in a CISA press release issued on Nov. 3. “As the operational lead for federal cybersecurity, we are using our directive authority to drive cybersecurity efforts toward mitigation of those specific vulnerabilities that we know to be actively used by malicious cyber actors. The Directive lays out clear requirements for federal civilian agencies to take immediate action to improve their vulnerability management practices.”
Easterly continues, “While this Directive applies to federal civilian agencies, we know that organizations across the country, including critical infrastructure entities, are targeted using these same vulnerabilities. It is therefore critical that every organization adopt this Directive and prioritize mitigation of vulnerabilities listed in CISA’s public catalog.”
Mitigation
Many major industrial and consumer firms have launched internal probes to figure out whether their consumer products include Log4j. If found, this opens up the potentially disastrous scenario where the industrial world – including those designated as critical infrastructure – could be subjected to cyberattacks, data theft, ransomware, extortion, double extortion, and so on.
There is hope on the horizon, however. The Apache Software Foundation, authors of the vulnerable Log4j library, issued security patches on Dec. 14 and 18. The following simple mitigation info is provided by the Logging.apache website: “Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).”
Dozens of vendors have also released security updates and patches. IT management tool provider N-able has deployed patches in its RMM and risk intelligence products. Automated patch-management software vendor ConnectWise also released updates on its Perch cloud service due to potentially vulnerable third-party components.
The National Vulnerability Database provides this reassuring message on its entry for CVE-2021-44228: “From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0, this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.”
How BlackBerry Can Help Stop Log4j Post-Exploitation Attempts
A vulnerable software component is not malware, which makes the existence of the Log4j vulnerability “invisible” to legacy security products focused on detecting known malicious files by using virus signatures to detect intruding malware or ransomware.
However, more advanced security solutions like BlackBerry® Protect and BlackBerry® Optics detect payloads and attempted attack techniques delivered by an exploitation of a vulnerability, and blocks them from executing. Over the years, BlackBerry has tested a vast amount of ransomware and coin miners against our products, which our platform has successfully detected and blocked from execution. BlackBerry products use highly trained artificial intelligence (AI) models that use machine learning to detect suspicious activity and behavior in the intended victim’s environment – even when no malware is present.
Implementing a Zero Trust framework is another highly effective way to repel cyberattacks that do not rely on malware. As many researchers have noted, many apps relying on the Log4j library probably do not have filesystem permissions. This simple denial of permissions may be sufficient to prevent Log4j from being leveraged for ransomware attacks. Zero Trust environments extend these protections to every application, device, and user, by enforcing least-privilege access policies across the board.
While the Log4j vulnerability is still active and unpatched, many attackers will ultimately try to exploit the flaw in order to load malicious files onto compromised systems. These malicious payloads, which are files, can be detected and stopped by BlackBerry Protect, an endpoint protection system that is powered by Cylance® AI. BlackBerry Protect is trained to identify both known and zero-day malware – and stop it before it executes.
As threat actors mull over opportunities, especially during the holidays when organizational processes slow down and staffing is minimal, Log4Shell may just be the gift attackers have been hoping for. In the meantime, BlackBerry will remain ever-vigilant, and will share new information on this threat as it becomes available.
BlackBerry Assistance
Regardless of your existing relationship with BlackBerry, the BlackBerry Incident Response team can work with organizations of any size and across any vertical, to evaluate and enhance their endpoint security posture and proactively maintain the security, integrity, and resilience of their network infrastructure.
For emergency assistance, please email us at DLIR@blackberry.com, or use our contact form.
Federal Assistance
The FBI would like organizations to contact them if they think they have been compromised by Log4j. The FBI Statement on Log4j Vulnerability states: “If you feel your systems have been compromised as a result of the Log4j vulnerability or are seeking remediation, we encourage you to employ all recommended mitigations and follow guidance from CISA. If you think your organization has been compromised as a result of the Log4j vulnerability, visit fbi.gov/log4j to report to the FBI. Please include as much information as possible to assist the FBI and CISA in determining prioritization for victim outreach.”
Organizations can additionally submit complaints through the Internet Crime Complaint Center (IC3). The FBI or CISA may reach out for additional information.
Resources:
https://logging.apache.org/log4j/2.x/security.html
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://blogs.apache.org/foundation/entry/apache-log4j-cves
https://logging.apache.org/log4j/2.x/download.html
https://github.com/cisagov/log4j-affected-db
https://www.n-able.com/security-and-privacy/apache-log4j-vulnerability
https://www.connectwise.com/company/trust/advisories
https://securityscorecard.com/blog/log4j-active-exploitation-from-nation-state-actors-findings
https://www.cybersecuritydive.com/news/CISA-vulnerability-patch-directive-CVE-catalog/609393/
https://blogs.blackberry.com/en/2019/08/inside-the-apt28-dll-backdoor-blitz
https://cyber.dhs.gov/bod/22-01/
https://www.theregister.com/2021/12/13/log4j_rce_latest/
https://blogs.blackberry.com/en/2019/10/malicious-payloads-hiding-beneath-the-wav
https://www.fbi.gov/news/pressrel/press-releases/fbi-statement-on-log4j-vulnerability
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
https://www.cisa.gov/uscert/ncas/alerts/aa21-356a
