Two Weeks into Log4J vulnerability – What’s the Takeaway for OT Networks?

Yair Attar, Co-founder and CTO, OTORIO

The dust has settled a bit on the Log4j vulnerabilities, also known as CVE-2021-45046 (DOS), CVE-2021-45105 (DOS) and CVE-2021-44228 (Remote code execution vulnerability) and CVE-2021-45046 (DOS).

Useful Tips for Mitigating Log4J

Today, almost two weeks after its December 9 announcement and a month or so since its discovery, we’ve got a handle on what it affects (nearly a third of all web serversa third of all web servers in the world, by one reckoning) and what the dangers are (more than 3,700,000 hacking attempts using the vulnerability as of December 17, according to Check Point).

That said, we also have a better idea of what exactly hackers are doing with the vulnerability and its variants, and are beginning to get an idea of how to defend against Log4j-based attacks. Below, I’ll lay out some concrete steps you can take today to help protect your OT network. 

But first, how does this vulnerability affect OT networks, in general? 

The Log4j OT Network Challenge

A key challenge with Log4j – as compared with previous supply chain attacks like SolarWinds - is that at this stage it's hard to identify exactly what's affected.

The vulnerability was found in a library that is used widely in many products – meaning it has the potential to affect multiple systems in any given network. In the coming days and weeks, machine builders, system manufacturers and application providers will start sharing exactly which of their systems are affected, releasing patches that will fix the vulnerability, and providing detailed mitigation plans.

Until this happens, here are four concrete steps you can take today.

Four Log4j Mitigation Steps 

1. Fast hardening - Block IOCs (Indication of Compromise) in perimeter solutions like Firewalls, IDS, IPS, WAFs, etc.). You can see an example of Microsoft’s IoC list here. it is important to make sure that your WAFs are automatically updated and loaded with log4j detection and prevention updates (It does not guarantee exploit prevention as it is based on behavior and signatures).
2. Identification – 
1. Reduce your overall global attack surface by scanning with a tool like OTORIO’s ReconOT – which automatically and passively conducts OT-IoT-IT reconnaissance to discover assets as they are exposed by a potential attacker. Recently we armed reconOT with non intrusive capability of detecting applications that might be vulnerable to log4j
2. Use your asset/software inventory to identify known applications that were published as vulnerable to log4j - It is recommended to follow https://github.com/cisagov/log4j-affected-db#software-list as it contains a maintained vulnerable software list. OTORIO’s technology (both RAM² and spOT) can support you easily in this process.
3. Scanning packages – with tools like CERTCC’s tool (published by cisa) could be also useful, both for linux and windows if there isn’t another SBOM tool in place.
3. Mitigation and patching – Upgrading to the latest log4j version  - https://logging.apache.org/log4j/2.x/download.html If patching is not possibe isolate the relevant system as much as possible. When talking about OT assets, make sure to verify the steps above with the vendor of the system.
4. Monitoring –

1. Detection of exploitation attempts on Linux hosts by searching log4j jndi logs:
   sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/
2. Snort rules for IDS/IPS systems - https://rules.emergingthreatspro.com/open/
3. Search and Block IOCs of known attackers that are exploiting systems in the wild:
   -https://s3.amazonaws.com/talos-intelligence-site/production/document_files/files/000/095/702/original/IOCs_20211217.txt?1639778427 
   -https://s3.amazonaws.com/talos-intelligence-site/production/document_files/files/000/095/701/original/IOCs_20211216.txt?1639690764
   -https://s3.amazonaws.com/talos-intelligence-site/production/document_files/files/000/095/700/original/Dec1521IOCs.txt?1639683730
4. If you have EDR on DMZ assets, monitor for suspicious curl, wget, or related commands

Additionally, organizations are urged to review and monitor the Apache Log4j Security Vulnerabilities webpage for updates and mitigation guidance and work closely with their providers and suppliers to monitor any updates on affected systems. 

Nothing is bulletproof, of course - but all of the above could help. You will find additional information in a recent Incident Response Tip published by Dor Yardeni, OTORIO’s Director of Cybersecurity Services.

How Else Can OTORIO Help?

OTORIO clients can configure their RAM² to integrates with various data sources such as EDR, FW, WAF, and OTORIO’s proprietary tools. The broader the coverage, the more chances to detect log4j exploitation attempts. 

Also, OTORIO’s spOT platform can provide automated risk assessment – helping harden your machines against any threat. In just hours, spOT creates a fully-updated OT, IT and IIOT asset inventory - including components, assemblies, complete machines, network segments, firewall configurations, connectivity between devices, protocols and more. For any factory, production floor, energy or infrastructure facility - spOT leverages multiple data sources to automatically assesses risk per OT asset, process or entire site and measures overall cybersecurity posture.