Full Report
James Kettle starts off with a graph of attacks they've done vs. attacks they're read about. At the top of it is 1,300ms that he's seen and 5ns for things they haven't seen. They were curious how far these timing attacks could be taken for this research on real black box targets. The timing of a request has many points where the timing can change: latency, jitter, internal latency, internal jitter and processing delay. In 2020, Timeless Timing Attacks showed that the jitter could be avoided by using HTTP/2 to send requests concurrently to measure differences. Sadly, the first request is still slightly faster but this can be fixed with an arbitrary timing delay on the first one to match the second. From previous research of the single packet attack, they decided to implement this method with timing attacks - send MOST of the data for a packet at the beginning then a small amount right at the end. The problem is that some servers will parse the request as soon as the header frames have been received and the data/header frames can't be interleaved. Server side noise is a major problem too. There's caching, server specific things and much more to worry about. To maximize signal and reduce noise, take the slower code path. For instance, use multiple headers with the same prefix. He claims that ORMs and GraphQL are great target for timing expansion techniques. After putting this together, they had a machine. But, it was too powerful! Now, you can find soooo many timing differences that you may misunderstand what you're seeing. For instance, the author thought they had found a hidden parameter with exec. In reality, the WAF was doing extra parsing on this parameter. Now what? They did some parameter discovery and they tried out server side injection issues that were being handled. They found a fully blind SQL injection, but it was a dup; in retrospect, they say that super powerful injection attacks don't need timing issues. Many of the things they found were for recon gather than exploitation though. They ended up using this to discover Nginx misconfigurations for the host header leading to scoped SSRF. Additionally, they used it to bypass firewall restrictions. Finally, sending user controlled headers to a backend where the proxy would change it or est it themslves. Overall, I think this is a step in the right direction for exploitation. However, detecting tiny changes for a password reset token still doesn't seem to be possible, sadly. Kettle's understanding of HTTP is bonkers at this point!
Analysis Summary
# Research: Smashing the State Machine: The True Potential of Black-Box Timing Attacks
## Metadata
- **Authors:** James Kettle
- **Institution:** PortSwigger Web Security
- **Publication:** Black Hat / DEF CON / PortSwigger Research
- **Date:** August 2023 (Reflecting the timeline of the "Single Packet Attack" evolution)
## Abstract
This research explores the limits of remote timing attacks on black-box targets. By refining "Timeless Timing" techniques and integrating them with "Single Packet Attack" methodologies, the research demonstrates how to eliminate network jitter to detect microsecond-level processing differences. The study moves beyond theoretical nanosecond measurements to practical exploitation of server-side misconfigurations, parameter discovery, and logic bypasses.
## Research Objective
The research aims to determine how far timing attacks can be pushed against real-world, black-box targets. Specifically, it seeks to overcome the traditional barriers of network latency and jitter to identify subtle server-side processing variations that reveal hidden infrastructure, internal logic, or vulnerabilities.
## Methodology
### Approach
1. **Jitter Elimination:** Leveraging HTTP/2 protocol features to send concurrent requests, ensuring they arrive at the server simultaneously to negate network-induced noise.
2. **Single-Packet Timing:** Implementing a "Last-Byte Sync" approach where the bulk of multiple requests is sent, held, and then completed with a single TCP packet to trigger near-simultaneous processing.
3. **Timing Expansion:** Intentionally triggering slower code paths (e.g., using multiple headers with the same prefix) to amplify the "signal" of a timing difference against the "noise" of server-side background processes.
### Dataset/Environment
- Real-world black-box targets (Bug Bounty programs).
- Testing against various web servers (Nginx), WAFs, and backend architectures (ORMs, GraphQL).
### Tools & Technologies
- **HTTP/2 & HTTP/3:** For concurrent request multiplexing.
- **Turbo Intruder / Burp Suite:** Custom extensions to facilitate the Single Packet Attack.
- **Network Analysis:** Measuring differences between 1,300ms (standard) down to microsecond/nanosecond scales.
## Key Findings
### Primary Results
1. **Reconnaissance Superiority:** Timing attacks are highly effective for discovering hidden parameters and internal infrastructure that do not produce visible functional changes.
2. **Infrastructure Revelation:** Successfully identified Nginx Host header misconfigurations leading to scoped SSRF and firewall bypasses.
3. **False Positive Paradox:** The methodology is so sensitive that it often detects "noise" from security middleware (like WAFs) rather than the application logic itself.
### Supporting Evidence
- Identification of a blind SQL injection via timing (later confirmed as a duplicate).
- Detection of WAF-specific processing delays when specific keywords (e.g., `exec`) were used in parameters.
### Novel Contributions
- **Adaptive Delays:** Adding an arbitrary timing delay to the first request in a concurrent pair to perfectly match the processing start time of the second.
- **Timing Expansion:** The concept of using specific inputs to force the server into more complex processing cycles to make timing differences easier to measure.
## Technical Details
The core innovation is the refinement of the **Single Packet Attack**. By sending the majority of an HTTP/2 request but withholding the final frame, the attacker can "prime" the server. When the final frames for multiple requests are sent in a single TCP packet, the server's kernel receives them at the exact same time. This bypasses all network jitter. However, the research notes a "first-request bias" where the first request processed by the server is often slightly faster; this is mitigated by adding a calibrated delay to the initial request to align it with subsequent ones.
## Practical Implications
### For Security Practitioners
- Timing attacks are now a viable tool for **Parameter Discovery** and **Hidden Surface Mapping**.
- Practitioners should look for timing differences when testing ORMs and GraphQL endpoints, as these often exhibit measurable processing variations.
### For Defenders
- Generic timing protections (like adding random delays) may be ineffective against differential timeless timing attacks.
- Focus on hardening internal routing; many timing-discovered vulnerabilities resulted from how proxies and load balancers handled specific headers.
### For Researchers
- There is a significant gap between detecting "any" timing difference and detecting "exploit-specific" differences (like a single character in a password reset token).
## Limitations
- **Server-Side Noise:** While network jitter is eliminated, internal server noise (caching, thread scheduling) remains a hurdle.
- **Protocol Constraints:** Some servers parse headers immediately upon receipt, preventing the "withholding" of data required for the Single Packet Attack.
- **Complexity:** Distinguishing between an application-level vulnerability and a WAF-level processing delay is extremely difficult.
## Comparison to Prior Work
This research builds directly on **Timeless Timing Attacks (2020)**. While the 2020 research proved the theory using HTTP/2, Kettle’s work applies the **Single Packet Attack** (introduced in 2023 for Race Conditions) to the timing domain, making it practical for black-box exploitation rather than just local or theoretical environments.
## Real-world Applications
- **Bypassing Firewalls:** Identifying which headers are processed by a proxy vs. the backend.
- **SSRF Discovery:** Using timing to see if a Host header change causes the server to attempt an internal connection.
- **Parameter Brute-forcing:** Finding hidden debug or administrative parameters.
## Future Work
- Developing more robust methods to filter WAF/Proxy noise from Application-level signals.
- Investigating if sub-microsecond timing can eventually be used for high-entropy data extraction (like tokens).
## References
- *Timeless Timing Attacks* (Van Goethem & Joosen, 2020)
- *Smashing the State Machine* (Kettle, 2023)
- PortSwigger Research: `https://portswigger.net/research`