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!

Many vulnerabilities, both classes of them and individual instances of them, are missed by hackers. It's easy to stay in the comfort zone and look for the standard bugs over and over again. There's a big problem with this though: over years and years of an application existing, more and more niche security lay dormant ready to be discovered. This presentation goes through James Kettle's perspective on hunting security issues that others miss. He is the perfect person to publish this research!

One reason is a highly visible defense. In the web browser, this may be X-Frame headers, for instance. In the case of James Kettle, they wrote a proof of concept for a side-channel leakage that required the X-Frame to not be there; Mozilla said this is impossible because the header was not there. James didn't see the defense so they tried the PoC and it worked. It turned out that a bug in FireFox allowed for this to be possible. What's the takeaway? Write PoCs without considering the defenses and figure them out later. Modern applications are too complicated to fully understand by simply reading the code.

A lot of times, it's a vulnerability fad. A good recent example of this HTTP Smuggling. Vulnerability classes get popular, many of the bugs get found and then it floats into obscurity until the cycle happens again. The advice here is to review old research and techniques and apply them to today's applications.

But, there's a catch... techniques get corrupted over time. HTTP Request Smuggling was originally a desync between proxies. Over time, it become the ability to bypass WAFs and that was it. James recommends to go to the original source of the research. It will have the most complete amount of information and give you information that was lost over time.

The next reason is around fear of failure. Again, an example of this is around HTTP Smuggling. Either the technique isn't feasible, it's too complicated, it's not there... etc. James says to just go ahead and try it! If it's super new or super old, then there's likely a lot of good bugs to find with it.

Another reason is the invisible link. This is either application-specific or context-specific knowledge. For instance, a website that uses a custom authorization scheme. Unfortunately, this is inconvenient and time-consuming. However, it is essential to find great bugs!

The author thinks that automation can help find better bugs as well. Not full automation - fuzzing specific inputs. Scan for interesting input not bugs. Use the scanner as a lead for issues not as the issue itself. This helps go from a huge attack surface to finding the juicy bits. James calls this curiosity-powered hacking. Test a hypothesis, ask questions and iterate.

To do this effectively, make the questions cheap to ask. The longer you spend on something, the more sure you should be. The next advice is eliminate noise and be specific with the questions you're asking. Finally, do non-default things.

The end of the presentation has the best advice: make it your own. If you do the same thing that everyone else does then you'll be crowded by noise and not do well. There's no winning formula; there are only different formulas. Great talk!