Home>
Log4J vulnerability: internet on red alert
Log4J vulnerability: internet on red alert
SECURITY INSIGHTS | 14 January 2022
The “Log4Shell” vulnerability (CVE-2021-44228) in the Java Log4J logging library, reported on November 24, 2021, by Chen Zhaojun of the Alibaba Cloud Security Team, is considered one of the most far-reaching vulnerabilities in the history of the internet. Shortly after the vulnerability became known, the German Federal Office for Information Security (BSI) spoke of an “extremely critical threat situation” and issued the highest warning level: Red.
On January 12, 2022, the BSI downgraded the IT threat level for Log4Shell to “yellow.” However, this does not mean the all-clear has been sounded: The government agency still recommends “increased monitoring of anomalies.” Companies should continue to check whether all products in use are protected against exploitation of the vulnerability.
What makes Log4Shell so dangerous?
The vulnerability in Log4J poses an immense risk because the open source library, which has been available since 2001, is used in countless applications. In many cases, it is almost impossible for companies to identify all of the programs in which the library is implemented. This makes patching the flaw even more difficult.
Attackers are currently scouring the internet for vulnerable systems and specifically exploiting the flaw in Log4J to inject malicious code onto web servers and connected systems without detection. The possible consequences range from data loss and extortion attempts to service outages and the compromise of entire corporate networks.
How to protect yourself from Log4J-based attacks
Immediately apply security updates to Log4J and affected products – You can identify vulnerable software by checking against a list of affected products provided by CISA. You should also update the firmware of embedded systems and networked devices (e.g., webcams, IoT devices, etc.) as soon as possible. For Log4J itself, updates are available depending on the Java version used (caution: some non-Java systems also use Log4J!):
Java 6: Log4J 2.3.2
Java 7: Log4J 2.12.4
Java 8 and higher: Log4J 2.17.1
Internally identify web services that use Log4J – To do this, the BSI recommends a fully automatable, Python-based scanner called log4j-scan. It is particularly useful for identifying internet and intranet applications developed in-house that are vulnerable to the Log4Shell threat. File scans on the systems can identify the two Java archives log4j-api-2.XX.X.jar and log4j-core-2.XX.X.jar.
Check existing services and restrict outgoing connections – Servers should only be allowed to initiate outgoing connections when absolutely necessary. The following services should be included on your blocklist because they are often exploited for attacks: DNS, IIOP, LDAP, LDAPS, RMI.
Secure servers using WAF and block Log4J scanning attempts by bots – Myra offers custom rule sets developed for its Hyperscale WAF to transparently detect Log4J exploits on your systems and block access to vulnerable servers. This will give you valuable time to patch your systems and scrub compromised web servers. Bot Management allows you to control scan bots even more effectively and prevent attackers from automatically scanning your systems for Log4J vulnerabilities.
Implement multi-factor authentication (MFA) across the board – The use of MFA for internal logins significantly slows down attackers and should therefore always be set up.
Improve logging – XFF (X-Forwarded-For) in particular should be enabled on all firewalls, load balancers, web proxies, and WAFs to consistently log the attacker IP. This is so you won’t lose any information that you may need to establish an overall context of the attack attempt.