Apache Log4j (Log4j) is a popular open source Apache logging platform. However, the Log4j logger is not exclusively used in Apache web servers and is built into other software, including non-Apache software. A Log4j vulnerability (referred to as “Log4Shell”) was openly disclosed in early December with a proof-of-concept code that allowed attackers to remotely gain access to systems. On Tuesday, a second Log4j vulnerability was identified. The vulnerabilities rely on information getting logged that would have the Log4j logger send a request to an attacker’s machine, which would allow the attacker to gain full control over systems. The Log4j vulnerabilities can also reach systems that are not internet facing if the systems receive logs from internet-facing systems.
Can Sikich scan for Log4j vulnerabilities from the internet?
Unfortunately, due to the nature of the Log4j vulnerabilities, we are finding that any scans from the internet, and really any scans that are not authenticated, are unreliable at detecting the vulnerabilities.
This is because Log4j itself is not a listening service; it is a component of other applications. The way Sikich’s external vulnerability management tool and other currently available remote/unauthenticated Log4j scan tools work is by sending a Log4j payload as part of a variety of HTTP requests and then monitoring for new traffic, such as DNS or LDAP queries, coming from a vulnerable server to the scanner, showing that the server launched the Log4j payload. However, there are a great number of application and network configurations that would prevent this scan approach from working, even on a vulnerable system.
How do I detect Log4j vulnerabilities on my systems?
The best approach is to use a software inventory tool, patch management tool, or internal vulnerability scan tool that logs in to each system to take an inventory of installed software and compare that inventory against the growing lists of software known to have Log4j vulnerabilities.
What applications are vulnerable?
The following links include information from organizations that are working to consolidate lists of vulnerable software.
- https://github.com/NCSC-NL/log4shell
- https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Are there other steps I can take to protect my environment?
- A web application firewall (WAF) configured to block Log4j payloads coming into web servers can help protect against attacks.
- A default-deny firewall configuration for egress traffic, especially traffic out of any DMZ, can help protect from attacks, as most Log4j payloads involve making callbacks to the threat actor’s systems.
- Next-generation endpoint detection and response (EDR) systems, such as SentinelOne, Cylance and CrowdStrike, can detect malicious behaviors that may be indicators of an attack in progress.
Have any questions about Log4j vulnerabilities and how to protect your organization’s environment? Please contact our cybersecurity experts at any time.
