Log4Shell: Information Security Teams Served Coal for Christmas

By now you’ve probably heard of Log4Shell, Log4j or LogJam – more formally known as CVE-2021-44228.

Let’s be clear. Log4Shell is a global cybersecurity pandemic with an impact that can only be speculated at this point. It will most likely alter the landscape of many organizations.

Log4Shell is a Remote Code Execution vulnerability with the Open Source Apache Log4j framework that is part of the Apache Logging Project. This is the most widely used logging framework on millions of systems worldwide and many governments have rated the risk a 10 out of 10, or “red” level risk of the highest severity.
 

To put this event into laymen’s terms:  If 95% of all garage doors installed from 2016-2021 could be opened from any Internet Web Browser…from anywhere around the world… This is the significance of Log4shell.

Apache released a patch for this vulnerability on December 6th, 2021.  The first proof of concept (PoC) was uploaded on Github on December 9th.

Let’s dive in.

The Java log4j framework is open sourced and embedded in billions/unknown numbers of solutions globally. Meaning, you might not control or have the ability to update the embedded solution until the vendor provides you with an update. 

Beyond this lack of control and ability to update the solution manually, visibility into whether you have log4j installed or in place with your solutions comes with its own set of challenges. You will need to scan your environment and actively search for it’s presence and use. 

Remediation steps are also dynamic and still evolving.  In some cases, the remediation required, isn’t always straight forward or easily accomplished without the right resources and architectures. 

Quentin Rhoads-Herrera goes into more detail about what makes this remediation difficult in his comments to CyberWire, “Organizations using the open source logging utility should first start with identifying internet facing assets that might be using the vulnerable version of Log4J and quickly patch and implement the recommended work arounds. The reason to do both is we are already seeing researchers attempting to bypass the patch so with both the patch and mitigation in place the company should be able to mitigate the risk.

“From that point on the company should work on doing the same steps for any other application leveraging Log4j. They should also identify vendor software that might be impacted and confirm with those vendors when a upgrade will be available. Finally, all companies should be updating their defensive technologies such as Web Application Firewalls in an effort to identify and block potential malicious actors trying to abuse the Log4j vulnerability.”

What should I do first?

We asked our team what first steps any customer should take. Their response was:

• Discover what is vulnerable  — this is a bigger task than it might seem.  Use scanning and tools that are becoming available to help.  
• Update as possible — if you are in the midst of a change freeze, start the paperwork now.  You need to get updates rolling as soon as they are available.
• Create and leverage hunting and analytic rules for your organization to continue to monitor
• Contact CRITICALSTART

How can CRITICALSTART help?

Security tools and solutions are good, but we make them better. Cybersecurity is what we do and there are two relevant points why we feel we are better in this exact situation than other services or vendor tools on their own.

1. We triage every alert. Not just critical alerts. All of them. When we are talking about Log4Shell, it is important to realize that we are very much just seeing the attacker’s proof of concepts. They are testing the waters and will be evolving over time. This is why all events — regardless of vendor specified severity, are important to evaluate in a context that makes sense from the overall security perspective.  
2. Our response and remediation meantime. We have contractually commit to resolving your alerts in under 60 minutes. Our Trusted Behavior Registry allows us to know and tailor events to your organization that are expected and known. This also allows us to quickly identify the unknown and work towards resolution. Combined with our unification and contextualization of alerts, we can identify and remediate within minutes.

With regards to the recent 0Day activity or any new exploit, our Cyber Threat Intelligence (CTI) team investigates and shares any relevant details with our Detection Engineering team. The DE team is responsible for the creation of any behavioral detections that make sense based on the intelligence provided assuming there isn’t already covered for those activities via existing detections. The focus on behavioral detections generally keeps us out of “signature chasing” which has really been the instinct in security since the antivirus/intrusion detection days of the 90s and 2000s. By focusing on behaviors, we don’t have to build fresh detections for every 0day or new exploit that hits the news because we already have enough coverage across various attacker techniques that they will hit our radar regardless of detecting whatever specific exploit they used. 

To be clear, this doesn’t mean we ignore things like the vulnerability tracked as CVE-2021-44228. Our team is actively analyzing and building new detections where we know we can improve coverage based on attacker playbooks, behaviors, TTPs, etc. In some cases, we even build parallel detections with tactical indicators – specific IPs, domains, or hashes – for redundancy and to ensure that we have our customers protected. Once the analysis of the code for the vulnerability tracked as CVE-2021-44228 is complete, and the Detection Engineering team receives our assessment, we can provide you with a list of all of the CS detections that monitor for the associated behavior patterns this behavior sequence, as well as any experimental detections we are building based on the known behaviors along with a description of each detection.

Given the above context, CS custom detections have been created and implemented across all customer environments with the applicable toolset in relation to the active log4j exploit.

Resources

As this threat rapidly evolves, we will continue to research and provide resources to mitigate the risk presented by this vulnerability.

• @SwitHak‘s Github list:  BlueTeam CheatSheet * Log4Shell* | Last updated: 2021-12-15 0016 UTC · GitHub
• Microsoft’s Response to CVE-2021-44228 Apache Log4j 2 – Microsoft Security Response Center
• Log4Shell – Detecting Log4j Vulnerability (CVE-2021-44228) Continued | Splunk
• Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild (bitdefender.com)
• Hunting for Log4j CVE-20210-44228 (Log4Shell) Exploit Activity – Palo Alto Networks Blog
• CVE-2021-44228: Staying Secure – Apache Log4j Vulnerability – SentinelOne
• log4j – Overview (tutorialspoint.com)
• Splunk: 
  •  https://www.splunk.com/en_us/blog/security/log-jammin-log4j-2-rce.html
  • https://www.splunk.com/en_us/blog/bulletins/splunk-security-advisory-for-apache-log4j-cve-2021-44228.html
• DEVO:
  • https://www.devo.com/detection-of-log4shell-vulnerability-and-exploitation-with-devo/
  • https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• MS Sentinel: 
  • https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
  • https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/