Fails to detect Log4Shell vulnerability

[CountMurphy]

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.

[xristos8574]

I totally agree with that, happens to me as well. The only thing I can see is the DNS query from Wireshark, which makes the plug-in kinda not useful if I have to capture all the traffic aswell.

[dnet]

That's interesting, since it's one of the things we tested it with during the development. What version(s) of this plugin have you tried? Which collaborator server have you used (own vs. PortSwigger one)?

[dnet]

Also, which version of Burp were you testing on and what OS did that Burp ran on?

[dnet]

@xristos8574 explicitly stated seeing DNS traffic, which sounds promising, however, I'd like to ask the others (@CountMurphy and @wynnchel) whether you saw DNS traffic. If not, the first thing to check is whether the insertion point was selected by Burp for scanning at all. Use Logger++ (or in case of plain HTTP, just Wireshark) to see if there were any payloads containing the string jndi sent in the vulnerable header (X-Api-Version:).

I could trigger it for example (see screenshot below) by selecting the value of this header in Intruder, clicking Add § and selecting Scan defined insertion points in the context menu. I guess a similar effect could be reached by enabling HTTP headers as insertion points.

Since this is an active scan check just like any other, if the scanner doesn't even detect the vulnerable input as an insertion point, there's nothing the plugin itself can do. So first, please check whether the payload even reaches the target. If that happens and a DNS request comes out yet the plugin doesn't report the vulnerability within 60 seconds (it polls collaborator every minute), I'd be happy to help debugging that.

[xristos8574]

f Burp were you testing on and w

I am running it on: Burp Suite Professional v2021.10.3, Kali Linux 2021.3 Also, I observed that I have to add the port number for the scan to run successfully. Here is the output of the vulnerable app once scanned: And here is my Wireshark capture

P.S. there was no instruction in you repository for a server/collaborator as you mentioned

[v-p-b]

@xristos8574 The screenshot you posted shows (last line) that your base query doesn't include the vulnerable parameter (see @dnet's answer above), and it's also not present anywhere in the pcap.

[xristos8574]

@xristos8574 explicitly stated seeing DNS traffic, which sounds promising, however, I'd like to ask the others (@CountMurphy and @wynnchel) whether you saw DNS traffic. If not, the first thing to check is whether the insertion point was selected by Burp for scanning at all. Use Logger++ (or in case of plain HTTP, just Wireshark) to see if there were any payloads containing the string jndi sent in the vulnerable header (X-Api-Version:).

I could trigger it for example (see screenshot below) by selecting the value of this header in Intruder, clicking Add § and selecting Scan defined insertion points in the context menu. I guess a similar effect could be reached by enabling HTTP headers as insertion points.

Since this is an active scan check just like any other, if the scanner doesn't even detect the vulnerable input as an insertion point, there's nothing the plugin itself can do. So first, please check whether the payload even reaches the target. If that happens and a DNS request comes out yet the plugin doesn't report the vulnerability within 60 seconds (it polls collaborator every minute), I'd be happy to help debugging that.

Thank you @dnet for your reply, I have followed your instructions and I was able to capture everything. I can confirm now that the payload is sent, captured, and can see a DNS. What I had to do to get it "working" (I put it like that because Burpsuite still does not detect it) was:

1.) From the intruder, create this request: 2.) Then right-click and choose Scan defined insertion points 3.) Import the extensions-only, and run the scan 4.) From the Wireshark capture, I could see two requests with the X-Api-Version being "a" as I added it and another two packets with the correct payload. 5.) The payload requests were not visible through BurpSuite, and when they were sent, the scanner froze and also the vulnerable-app 6.) In the end, the vulnerable app displayed the correct output but with multiple lines of errors as shown here, which I believe @christophetd can assist us.

Therefore, BurpSuite did not capture the vulnerability and no issue was created if you can help me debugging that :) Moreover, this way of running the scanner (through the intruder) is there an option for multiple IPs to scan ?

P.S. @v-p-b thank you for your help as well.

[v-p-b]

The exceptions you are seeing in the vulnerable app are normal and show that the payload reaches the target. Can you confirm with Wireshark that your target sent out the DNS beacon as the result of the trigger?

[pawel16151]

@xristos8574 What do you add in payload tab?

[xristos8574]

The exceptions you are seeing in the vulnerable app are normal and show that the payload reaches the target. Can you confirm with Wireshark that your target sent out the DNS beacon as the result of the trigger?

I don't touch it at all, assuming that the scanning will take over which kinda does at some point...

[xristos8574]

The exceptions you are seeing in the vulnerable app are normal and show that the payload reaches the target. Can you confirm with Wireshark that your target sent out the DNS beacon as the result of the trigger?

Can't confirm that, but feel free to check the second PCAP I added here

[dnet]

The exceptions you are seeing in the vulnerable app are normal and show that the payload reaches the target. Can you confirm with Wireshark that your target sent out the DNS beacon as the result of the trigger?

Can't confirm that

If you can't see any DNS beacons making it from the target/victim to the Collaborator, nor this nor Active Scan++ will detect Log4Shell, as they both depend on Collaborator being able to receive these. Once you have confirmation, we'll have something to debug.

[xristos8574]

The exceptions you are seeing in the vulnerable app are normal and show that the payload reaches the target. Can you confirm with Wireshark that your target sent out the DNS beacon as the result of the trigger?

Can't confirm that

If you can't see any DNS beacons making it from the target/victim to the Collaborator, nor this nor Active Scan++ will detect Log4Shell, as they both depend on Collaborator being able to receive these. Once you have confirmation, we'll have something to debug.

Sorry for misunderstanding, I can see this from the capture I have attached before: Which you can see it calls the collaborator, but from the scanning machine.

[v-p-b]

First of all, you should really learn better how your tools work.

These are not the DNS requests you are looking for. As the requested name shows, this is the polling: where Burp asks the Collaborator if anyone interacted with it, but not the interaction itself.

Based on the screenshot, this is the only DNS traffic, meaning that the vulnapp didn't manage to call out, so it's impossible to detect something went wrong based on Collaborator data.

Are you sure you are capturing the right interface? Docker networking can be tricky.

[azzarin]

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.

I have the same experience.

[v-p-b]

Since the members of this issue failed to provide any meaningful information about any possible bugs in the extension, I'm closing it. Future bug reports, submitted according to the available issue template are welcome.