Detecting delayed responses/timeouts?

[v-p-b]

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?

[dnet]

It could work, especially on firewalled hosts in an internal network. First of all, I'd recommend more tests to see how Burp's makeHttpRequest handles timeouts. The next step would entail outlining an algorithm. Some thoughts regarding this:

• Active scanners get the original request and response, but not metadata such as response time. This could be mitigated by sending the baseline request again and measuring it ourselves.
• To avoid false positives, maybe it would be a good idea to send a similar but inert payload, such as replacing jndi with jxxi and checking whether that causes deviation from the jndi version (such as both cause timeout -> false positive).
• If timeouts are handled uncomfortably in Burp, we might need to do it like the fallback mechanism in doActiveScan: store some information before sending the request and remove or overwrite it after receiving a response, with a thread monitoring this list and triggering issue creation if an entry is left in the "before request" state for more than a certain amount of time.

[dnet]

And of course, there's still the option to do response analysis like Backslash Powered Scanner does; just because DNS-based detection fits so damn well for this vulnerability, it doesn't mean that we have to forget all the other older methods. :)

[v-p-b]

Just an implementation hint: I tested time-based tests with Freddy, and it seems that even requests that timeout in burp get reported, contradicting my theory that scanner threads are terminated on timeout. The relevant code from Freddy is here:

https://github.com/PortSwigger/freddy-deserialization-bug-finder/blob/master/src/nb/freddy/modules/FreddyModuleBase.java#L847