How HTTP/2 Concurrency Turns Timing Attacks into Reliable Exploits

TLDR: James Kettle’s latest research at Black Hat 2024 demonstrates how to eliminate network jitter using HTTP/2 concurrency, making timing attacks viable against remote targets. By using a single-packet attack technique, researchers can now reliably detect hidden parameters, blind server-side injections, and bypass reverse proxy configurations. This methodology shifts timing analysis from a theoretical curiosity to a practical, high-accuracy tool for your next engagement.

Timing attacks have long been the "black sheep" of web security research. We all know the theory: measure the response time, correlate it with a secret, and extract data. In practice, however, network jitter usually buries the signal, leaving us with noisy, unreliable data that rarely leads to a valid bug bounty submission. Most of us have spent hours staring at histograms that look like random static, only to give up and move on to more fruitful attack vectors.

That changed this week. The research presented at Black Hat 2024 proves that the primary obstacle to timing attacks—network jitter—is effectively dead if you understand how to manipulate HTTP/2 concurrency.

Eliminating the Noise with HTTP/2

The core breakthrough here is the realization that network jitter is not an immutable law of the internet. It is a byproduct of how we send requests. By using HTTP/2 features, specifically the ability to multiplex multiple requests over a single connection, you can force a server to process your payloads in a way that minimizes the impact of the network path.

The speaker introduced the "single-packet attack" technique. Instead of sending requests one by one and hoping the network conditions remain stable, you package fragments of multiple requests into a single TCP packet. Because the server receives these fragments simultaneously, the network latency is effectively neutralized for the entire batch. The server processes the requests at the same time, and the response time delta becomes a clean, high-fidelity signal rather than a noisy mess.

Practical Application: Hidden Parameter Discovery

If you are a bug bounty hunter, you know that hidden parameters are often where the most critical vulnerabilities hide. Developers frequently leave debug parameters or administrative endpoints enabled in production, assuming that because they aren't documented, they aren't reachable.

Using Param Miner, you can now automate the discovery of these parameters with unprecedented speed. The technique involves sending batches of potential parameter names and observing the response time. If a specific parameter name triggers a different code path—even if the response body remains identical—the timing difference will reveal it.

For example, if you suspect an endpoint supports a parameter like exec, you can test it by sending:

GET /api/endpoint?exec=test HTTP/2
Host: target.com

If the server processes this request differently than a non-existent parameter, the timing analysis will flag it. This is not just about finding parameters; it is about mapping the internal logic of the application without ever seeing a single error message.

Bypassing Reverse Proxies and WAFs

Perhaps the most impressive part of this research is the ability to bypass Reverse Proxy security rules. Many organizations rely on front-end proxies to filter traffic, but these proxies often have different parsing logic than the back-end application.

By using the timing analysis techniques described, you can identify when a proxy is performing host header validation or filtering specific characters. If you can identify a discrepancy in how the proxy and the back-end handle a request, you can craft a payload that the proxy ignores but the back-end executes.

The live demo showed a bypass of a web application firewall that was blocking specific SQL injection payloads. By using the timing signal to confirm that the back-end was indeed receiving and processing the payload despite the WAF’s interference, the researcher was able to confirm the vulnerability. This is a game-changer for testing environments where you suspect a WAF is masking your results.

Defensive Considerations

For the blue teams reading this, the takeaway is simple: do not rely on the assumption that your WAF or proxy is a perfect shield. If an attacker can measure the time it takes for your server to process a request, they can infer information about your internal logic.

To mitigate this, you must ensure that your application’s response time is consistent regardless of the input. This is notoriously difficult to implement, but at a minimum, you should avoid "wildcard" routing in your reverse proxies and ensure that your error handling does not leak timing information. If your application takes longer to process a valid parameter than an invalid one, you are leaking information that can be used to map your attack surface.

What to Do Next

The era of ignoring timing attacks because they are "too noisy" is over. The tools are already available in Burp Suite and the Turbo Intruder extension.

If you want to test these techniques, start by looking for endpoints that perform heavy processing, such as those that interact with databases or perform complex data transformations. Use the single-packet attack to establish a baseline and then start fuzzing for parameters or headers that cause even a microsecond of delay. The murmurs are there, and for the first time, we have the tools to actually listen to them.