Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

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!