In light of the Log4Shell (CVE-2021-44228) vulnerability, the InfoSec community rapidly coalesced to release information and tools to help mitigate and contain the issue. We were very appreciative of all the work that went into the existing tools and scanners to help detect this vulnerability. Dealing with the fallout has left everyone, us included, scrambling and frustrated while trying to determine which tool and just how to use them in their environment. You may have encountered similar frustrations (or worse, a false sense of security) using some of the many scanners out there. Unfortunately, many of these tools were reporting false negatives, as we detected vulnerable endpoints through manual testing that other scanners had overlooked. Incomplete and uncertain results are unacceptable, and for this reason we decided to roll our own tools.
The first is Log4Broke, an intentionally vulnerable site that can be used to test against for the various forms of exploitation of this vulnerability. This was necessary for us when building our scanner to ensure that we could detect all the ways a malicious actor might leverage the Log4Shell vulnerability. We determined that most injection would occur at query parameters, body parameters, form inputs, and headers. As a result, we designed a simple spring-boot java web application vulnerable to some of these attacks for general testing of our tools and for third-party tool validation. You can run Log4Broke in your own environment to test your current scanners, but be aware that this is an intentionally vulnerable site and should be used with caution at your own risk. We strongly recommend to not leave it running or exposed to the internet. We will host this site publicly for a bit at log4broke.govanguard.com for community testing and research.
The second is Log4JShell Scanner. Our goal when building this was accurate detection of all ways a malicious actor could practically exploit this vulnerability. As a result, we built a tool that automatically enumerates as many of these as possible while also accepting specific details about a given endpoint and its parameters. These inputs are then used to pragmatically inject a canary payload into the endpoint. A hit on the payload means that it is vulnerable. As we tested the alpha, we determined that unauthenticated scanning might find the most obvious vulnerabilities, however, most web apps and APIs have endpoints and methods that are inaccessible from that context. It is common for developers to engage in the bad practices of foregoing common sense input validation, input sanitization, input deserialization checks, and sloppy logging of user supplied inputs. This is especially true for authenticated endpoints where there can be a false sense of security around the authority and validity of the user-supplied inputs. Consequently, we decided to add flags to pass headers to perform the most common forms of header-based authentication. This turned out to be extremely fruitful in testing. That said, this is not an automated scanner and will not help you to discover all vulnerable endpoints. Ideally, inputs for the tool should cover as many endpoints as possible and include as many known methods and query parameters (with bogus values) as possible. Some reliable sources of this data include Postman collections and OpenAPI/Swagger collections, one of which all well-maintained web applications and web APIs should already have on hand.
We have released these tools to the public under GPLv3 to help the community discover vulnerable pages and endpoints for rapid damage control. We will update these tools as any new details on this vulnerability come to light.
CTO - GoVanguard