If you’ve made it past the title, you already know what we’re talking about, and I hope you don’t stop here because you’re afraid of just another technical brain dump of how bad Log4j (aka Log4shell) actually is. What I think will be more impactful for our readers is to provide you with information on:
- What’s affected,
- How to find it,
- How to prevent or mitigate it,
- How to detect whether someone has attempted to impact your network and/or systems by exploiting this newly found vulnerability.
You’ve likely read in other articles and blogs that attackers are full speed ahead, running scans for purposes of identifying vulnerable applications which would allow them to facilitate a remote code execution. As it stands today, this vulnerability is being leveraged to deploy ransomware campaigns and I suspect these problems will only increase in the days ahead.
Before I get into the details, please know that if your team doesn’t have the time, bandwidth, or technical knowledge to implement these recommendations, Avalon Cyber can assist. Just contact us and we can discuss next steps.
Now, on with information about Log4j and how to protect your network.
What is Log4j and What Could Happen?
Developers use the Log4j framework to record user activity and behavior on applications for purposes of technical analysis. The Log4j vulnerability (CVE-2021-44228 and CVE-2021-45046) enables attackers to execute code remotely, which will allow them to install additional toolkits, crypto miners, malware and in some cases even ransomware. The software is distributed free of charge by the nonprofit Apache, has been downloaded millions of times, and is among the most widely used tools to collect information across corporate networks, systems, and applications. Apache's
Log4j application is used by numerous technology providers and while this may be the first time you're hearing about it, a vulnerable version of the application may be running on your home or business systems.
What Version is Affected?
The versions identified as affected at this time is version 2.15.0 and below.
Detecting Vulnerable Code
Vulnerability scanners, such as Tenable Nessus, now have plugins that can scan a host (laptop, desktop, server, network device) and attempt to validate if a vulnerability exists. If you don’t have an enterprise tool in-house that allows you to identify vulnerabilities within your environment, you may want to consider a few open-source tools that could give you some visibility into your vulnerability landscape. Here are a few examples:
- Fullhunt – Log4j-scan
- Lunasec – log4shell-scanner
- Fox-it – log4j-finder
- Logpresso – Logpresso – Scanner
- Hillu – Local-log4j-vuln-scanner
Please note that, while helpful, running a vulnerability scanner against a web application may not be a thorough enough check to ensure that your application is secure.
Huntress has provided a free resource to determine whether your applications are vulnerable to Log4j. This is a rudimentary test, and a negative test does not guarantee that your application is not vulnerable to Log4j. An authenticated web application penetration test may truly be required to determine if the application itself is vulnerable.
Prevent and Mitigate the Vulnerability
The best way to prevent a successful exploit as of December 16, 2021, is to upgrade the vulnerable versions of Log4j to version 2.16.0 or apply the vendor patches. However, some vendors do not have patches ready for installation and therefore have provided step-by-step instructions on how to mitigate the vulnerability from their application.
There are also several other tactics that can be performed:
- Enable:
-
- For Log4j versions 2.10 to 2.14, set the log4j2.formatMsgNoLookups system property to true on both client and server-side components (NOTE: As of December 14, 2021, it has been found that this flag is ineffective at stopping remote code execution in some situations – CVE-2021-45046)
This can be done in multiple ways:
- Pass the below argument as an agreement when you invoke java:
- Set the following environment variable:
- Or set this argument using the JVM arguments environment variable:
If applying patches or making configuration changes is not possible, below are a few basic recommendations to limit your exposure:
- Isolate affected hosts into their own restricted DMZ or VLAN
- Block all outbound network connections from servers or limit outbound network connections to trusted hosts and ports
- Ensure any endpoint or network security signatures are looking for Log4j exploitation behavior
- Monitor networks and servers closely for suspicious or unexpected behavior
- Use a web application firewall (WAF) with specific rules that detect and thwart log4j exploit attempts
Any changes made to production systems should be retested to ensure the vulnerability has been successfully remediated.
Here's an infographic that describes the anatomy of the attack process:
Image credit: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
Detecting Indicators of Attack or Compromises on Endpoints and Networks
As mentioned previously, attackers are actively taking steps to identify systems and applications that are vulnerable to Log4j.
If you have an EDR product already in place within your environment, there are a ton of resources available to you for purposes of conducting IOA hunts across all your systems. Your EDR solution may also offer continuous vulnerability identification, which will help you quickly locate vulnerabilities that require remediation.
If you don’t have a tool or a managed security service provider who can perform those types of hunts, there are some free tools that can be leveraged to determine if any of the logs you have possess any evidence to suggest your hosts were under attack:
Once a host has been compromised, the host will begin communicating with the attacker’s command and control infrastructure for purposes of furthering their campaign. Your NetFlow and firewall log data will be invaluable resources for purposes of investigating your network further.
We recommend the following resources to help direct your network hunting activities:
- Known Callback Domains: https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8
- Suricata Rules for Success Log4Shell Exploitation:
https://gist.github.com/fox-srt/c8d2fa991e8bb2be1446bad18f010fcb#file-log4shell-success-rules - Curated Intelligence Trust Group IOCs: https://github.com/curated-intel/Log4Shell-IOCs
Additional Resources:
- NCC Group Intel Feed: https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
- CrowdStrike Guidance:
https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/ - Microsoft Guidance:
https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
