The widely used open source library Apache Log4j, which is used in many software packages to log application messages, contains a critical zero day vulnerability (CVE-2021-44228). The vulnerability named Log4Shell is trivially exploitable and can have far-reaching consequences: According to CERT.at, the complete compromise of the affected system is possible.[1]

Wide scans for vulnerable systems and active exploitation of the Log4j vulnerability

Not only is a proof-of-concept for exploiting the vulnerability publicly available. Sample scripts that randomly scan systems for this vulnerability are also circulating. While these are not suitable for providing security about the vulnerability of one’s own systems, they do help criminals find suitable victim systems.

Log4Shell could have an impact on all applications accessible from the internet that use Log4j to log user requests. Accordingly, the BSI (German Federal Office for Information Security) has assigned the highest warning level for an extremely critical IT threat situation. The BSI also confirms broad scanning activities for vulnerable systems as well as compromises with crypto miners, through botnets as well as the reloading of Cobalt Strike beacons.[2] Researchers also observed attempts to infect systems with Khonsari, a new ransomware family.[3] However, by accessing confidential data, criminals can also exploit the gap without the use of malware.

Measures and options to prevent exploitation of the vulnerability

The BSI generally recommends shutting down affected systems that are not absolutely necessary and segmenting networks to isolate vulnerable systems. For critical systems, attack patterns on WAF (Web Application Firewalls), IPS (Intrusion Prevention Systems) and proxies should be rejected immediately or HTTP headers that are not needed should be set to static values. Admins should block all outgoing connections that are not essential, and log and record all connections for possible later incident response measures. It is advisable to check and, if necessary, reduce the rights allocation of affected services, disconnect connections to other systems and monitor hosts for anomalies.

A remedy for Log4Shell should be a patch to Log4j version 2.16. Previous versions solved the problem. Previous versions solved the problem only inadequately or were themselves affected by security flaws.[4]

For updates on security measures, please follow the post on CERT.at: https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek

The national CERT of the Netherlands (NCSC-NL) has also published a list of countermeasures: https://github.com/NCSC-NL/log4shell/tree/main/mitigation.

Also, the following presentation by the national CERT of Switzerland outlines available defensive measures.

Source: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Risk considerations when securing industrial facilities against security breaches

Regardless of the acute threat situation, industrial plants should never be accessible from outside and should be protected from access from the Internet with two DMZs (demilitarised zones). A common mistake here is that VLANs are not correctly protected via cluster firewalls, so that disconnected areas can be accessed again. A dedicated perimeter DMZ and an IT/OT DMZ provide a remedy.

System failures have more far-reaching consequences in OT than in IT, which is why a separate risk assessment of the recommended measures – system hardening, shutting down functions affected by the vulnerability or patching the affected systems, etc. – is essential. Mitigation with substitute measures, ideally combined with strict regulation of access options via the OfficeNet, can also be a viable path.

A well-maintained, up-to-date hardware and software inventory, including the libraries used, helps a great deal in assessing the risks posed by zero-day vulnerabilities. For up-to-date information on vulnerabilities and patches, we recommend active cooperation with system integrators and hardware manufacturers.

Software solutions and security services for preventive and acute measures

Generally, it is important to note that it is not sufficient to update Log4j via the software management of operating systems if a software has integrated the library into its own delivery files or if a vulnerable Java application is in use. Vendor updates need to be installed immediately.

IKARUS and Nozomi Networks services are not affected by the Log4j vulnerability. IKARUS supports you in securing your IT systems with the intrusion detection systems from FireEye. FireEye products are not affected or already patched.

FireEye NX detects attempts to exploit the vulnerability and prevents them in IPS mode. FireEye Helix also already has its own set of rules to detect exploit attempts in indexed logs. FireEye HX can be used for hunting compromised systems. Corresponding OpenIOC files are available for FireEye customers via the Customer Portal.

Especially for the OT sector, IKARUS enables complete network monitoring (cf. IDS/IPS) and anomaly detection with the technologies of Nozomi Networks. Nozomi Guardian Threat Intelligence already had an upgrade to detect and defend against Log4Shell attacks [5]. For a detailed vulnerability analysis and more information on predictable attacks, see the Nozomi blog post Critical Log4Shell (Apache Log4j) Zero-Day Attack Analysis.

Contact us now at +43 1 58995-500 or sales@ikarus.at for cyber-attack defence and professional incident response management!

Reading recommendations:

IKARUS 24/7 incident.reponse: Emergency plan for security incidents in IT, OT or IoT environments.

Sources: