For security professionals, 2021 will conclude with them racing to respond to one of the most grave internet vulnerabilities in recent memory. The Log4Shell vulnerability, an input-validation flaw in the omnipresent Apache logging library Log4j and disclosed by the open-source company on Thursday, exposes “the world’s most popular applications and services” to remote code execution.
Despite an update now available, companies worldwide are already under mass bombardment by attackers exploiting the vulnerability with everything from crypto-mining to ransomware to credential theft (including with variants that may be able to evade newly introduced protections) . Administrators of thousands of government websites, for example, have chosen to pre-emptively shut them down rather than face an exploit, and the sheer number of systems impacted globally virtually guarantees that businesses and users will face torment from this bug for many years to come.
The Log4j library is embedded in almost every Internet service or application we are familiar with, including Twitter, Amazon, Microsoft, Minecraft and more. At present most of the attacks focus on the use of a cryptocurrency mining at the expense of the victims, however under the auspices of the noise more advanced attackers may act aggressively against quality targets.
Reality check: the #log4shell vulnerability is a more serious risk to Internet security than EternalBlue was in 2017.
— Jake Williams (@MalwareJake) December 13, 2021
To help your security operations team detect and respond to this threat, the Siemplify team has prepared a FAQ:
Log4j version 2 is a Java library that provides advanced logging capabilities for Java applications. It is an (open-source) Apache product and thus has been implemented in a majority of applications that utilize Java. The first version of Log4j was released Jan. 8, 2001.
What impact can successful exploitation of the vulnerability cause?
Dec. 1-2: Both Cisco and Cloudflare reported cases of the exploit in the wild, starting mostly with the Microsoft-owned Minecraft video game.
Dec. 3-9: Researchers apparently privately share information about the vulnerability with Log4j developers before it is publicly known.
Dec. 10-11: Computer emergency teams worldwide confirm that a proof-of-concept of Log4j 2 exploit was released on GitHub. Meanwhile, various vendors rush to provide guidance and patches, while botnets such as Mirai begin to utilize the vulnerability. The Siemplify Security Operations Platform begins to assist in the automation of detection, hunting and remediation of the threat.
Ongoing: A massive rise in scans for the vulnerability means the associated risk is rising at an alarming rate.
In this blog post, we describe how Recon’s SOC quickly built a playbook within our Siemplify SOAR platform that takes advantage of the intelligence GreyNoise is providing to continually hunt for Log4j attackers in our customers’ environments. This rapid and tactical precaution freed up our time to take care of everything else that this disaster requires.
Our goal was simple: take advantage of the valuable intelligence GreyNoise was providing about the growing list of attackers found exploiting the Log4j vulnerability. We wanted to search our SIEM for any evidence of these IP addresses in our customers’ environments. However, it wouldn’t be enough to do this once: it had to happen continuously as GreyNoise updated their intelligence. We also wanted to continue searching for historical events, so just building alerts for future events from these IP addresses would also be insufficient…
By automating what can and should be automated, our analysts are free to apply themselves toward the more important challenges this complex problem requires, like threat hunting, securing our customers’ environments, and responding to incidents.
The largest challenge of dealing with the vulnerability is the sheer amount of attack surface. So many applications, Servers and other devices use Log4j that a full inventory will take most organizations quite a lot of resources to compile.
If #log4j has taught us anything, it’s that asset tracking is especially important for when shit hits the fan.
Can’t security well without asset tracking
— Tom McCheese (@Wookiee__) December 14, 2021
The most important patching targets will be internet-facing assets. Next an organization should think about how an adversary will move laterally in its environment. Remember, they could get in through, for instance, a traditional phishing attack and then exploit Log4j.
This week the internet has learned—once again—that asset management is the center of security.
It’s hard to patch what you can’t find.
— ᴅᴀɴɪᴇʟ ᴍɪᴇssʟᴇʀ (@DanielMiessler) December 10, 2021
But it is not as simple as “just patch.” Most organizations face both organizational hurdles and monetary barriers to fix all possibly affected systems, especially during the holiday season.
Automation will play a huge role in dealing with the crisis. The above-mentioned Recon playbook enables organizations to review logs for both past, present and future exploitation with little to no analyst intervention.
In true collective fashion, the security community is uniting to share intelligence about the threat, including efforts such as this:
Following in the footsteps of many others, I’ve decided to collect intel on log4shell and share it. I’ve deployed a few honeypots with ModSecurity yesterday and the data is streaming into an @elastic cluster. https://t.co/pbsSRPLzgA
— James (@jamesspi) December 14, 2021
In addition, you can map the threat to the MITRE ATT&CK framework:
|T1595.002: Active Scanning: Vulnerability||Adversaries may scan victims for vulnerabilities that can be used during targeting.|
|T1588.006: Obtain Capabilities: Vulnerabilities||Adversaries may use POC of given vulnerabilities instead of developing in-house tools|
|T1190: Exploit Public-Facing Application||Adversaries may use a known exploit on applications with public internet traffic.|
|T1203: Exploitation for Client Execution||Exploit of code vulnerabilities leading to command execution on a remote system.|
Siemplify’s stack technology is not based on Java, and our core product is not affected by this vulnerability. There are, however, a few third-party components, such as Tableau, that we work with that might be impacted. We are conducting a complete investigation and will share more details as we progress.
(This blog post will be updated as more information becomes available.)
UPDATE DEC. 20, 2021: Many organizations are still reporting to be in the process of completely identifying which assets are vulnerable to the original exploit. Vendors, in particular, are having trouble both patching their own environments and providing automated patch solutions for customers. Despite the problems caused by these events, it is essential that security teams keep and a watchful eye on more common attack vectors that many adversaries will surely be hoping evade the noise of the crisis and upcoming holidays.
UPDATE DEC. 21, 2021: A third vulnerability, which allows for denial-of-service, has been discovered. Log4j must now be updated to the newest version 2.17.
Dan Kaplan is director of content at Siemplify. Solutions Engineer Ivan Ninichuck and Product Marketing Director Kristen Cooper contributed to this post.