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!

The severity of a vulnerability is complex but comes down to two main things: how easy is the vulnerability to hit and how widespread is the vulnerability. DNS, the phonebook of the internet, is used for essentially everything on a device. Finding a vulnerability in DNS is a MAJOR deal, as it is on all Windows devices and is trivial to hit.

The ability to trigger the bug required setting up a malicious DNS server that pertained to a particular domain. So, by clicking on a website, the DNS server that we point to does not know the IP. So, it forwards the request to something that does. Now, when this domain is looked up in the future, it will by default go to the domain.

The vulnerability is actually pretty straight forward... By sending a very large SIG response an integer underflow vulnerability occurred on the RR_AllocateEx parameter. This integer overflow occurs because it expects a maximum size of 16 bits, which results in the code using only part of a register (cx instead of rcx). What can we do with this?

Later on, the data is copied into a dynamic buffer via a memcpy. This results in a heap-based buffer overflow!

However, this was not trivial to trigger... UDP DNS requests have a limit of 512 bytes. So, the team read into the DNS specification and found a way to trigger this integer underflow after several tricks, including DNS compression, to smuggle in a large enough size.

To make this exploitable in the browser, they had to smuggle a DNS request within an HTTP POST request. By abusing several obscure features of DNS, this is again possible.

For the purposes of exploitation, it is important to know that the binary is compiled with CFG (Control flow Guard). This makes the exploitation harder, but not impossible. Without CFG, this would have been trivial to exploit.

With CFG on, they needed an information leak and an arbitrary write-what-where bug. The leak was done by corrupting some metadata on a DNS resource entry. Then, when a query was made back to the DNS server, the memory addresses were recoverable.

For the write-what-where primitive, they choose to corrupt the metadata associated with a free-list heap chunk. This allowed them to control the next location for where a heap chunk was going to be allocated at. If this location was in their control, this created an arbitrary write-what-where primitive.

To bypass CFG, they corrupted a stack return address, instead of a vtable entry or something else.

Overall, they overcame many hurdles! From the tiny case where the actual vulnerability was hit at to the DNS smuggling, they overcame quite a bit. Amazing research and write up (as usual) from Checkpoint Research.