11-19, 10:30–11:00 (Europe/Vienna), Urania Dachsaal
What does the DNS have in common with an iceberg? Both are hiding invisible dangers! Beneath an iceberg there is... hiding even more ice, however, beneath the DNS there are hiding unexpected vulnerabilities!
If you want to resolve a name via DNS, there are multiple open DNS resolvers all across the Internet. A very commonly used open DNS resolver is Google’s resolver with the IP address 184.108.40.206. However, not every system is using such an open resolver. Hosting providers, ISPs or alike are often using resolvers that are not directly accessible from the Internet. These are the so called “closed” resolvers.
In my previous research “Forgot password? Taking over user accounts Kaminsky style” I have unearthed critical vulnerabilities in DNS resolvers of web applications, but I haven’t shared a second thought about the fact that these web applications were most likely using closed resolvers. So, this time I took a look at the root of the problem!
In this talk, we’ll take a look at how we can indirectly access these closed resolvers from the Internet. Furthermore, I’ll introduce open-source tools and methods to discover vulnerabilities in them. How we can attack these closed resolvers and potentially compromise thousands of systems, will lastly be shown in a proof-of-concept exploit.
- Introduction, explanation of DNS cache poisoning, and the core problem of this research
- The talk starts off with a short introduction and a brief refresher on DNS cache poisoning and its consequences.
- As a transition from DNS cache poisoning and it’s consequences, I’ll give a short summary of my previous DNS research (https://sec-consult.com/blog/detail/forgot-password-taking-over-user-accounts-kaminsky-style/). This shows, how I identified DNS vulnerabilities in web applications and how this would’ve allowed me to take over user accounts via DNS cache poisoning.
- Out of the 146 analyzed web applications, DNS resolvers of two web applications were especially insecure, since they allowed trivial Kaminsky attacks. The resolvers used by these two web applications were identified to be most likely closed (not directly accessible from the Internet).
- This sparked the question about the security of closed DNS resolvers.
- Analysis of closed DNS resolvers
- Firstly, I’m showing how closed resolvers can be indirectly accessed from the Internet via various means and which method we picked to scan around 7000 domains on the Internet.
- Furthermore, I’m showcasing the required open-source “DNS analysis server” (successor of https://github.com/The-Login/DNS-Reset-Checker). As well, I’m explaining the test process of how to find vulnerabilities in closed resolvers.
- After that, we explore the first example of a vulnerable closed DNS resolver and combine it with a short detour to Kaminsky attacks. This ensures a general understanding of off-path DNS cache poisoning attacks and why the discovered resolver is vulnerable.
- We then go into an in-depth analysis of how we can find all the systems/domains that are using the vulnerable closed resolver. This shows how thousands of domains are linked to vulnerable resolvers due to being managed by one hosting provider or ISP. Here I’m using a hosting provider for “cloud and security” as well as an e-mail provider as examples.
- Then, I’ll reveal the results of an Internet scan of roughly 7000 domains. Even though “only” 25 DNS resolvers were found to be vulnerable, thousands of systems are affected.
- I next explain the possible attack vectors to exploit systems using these vulnerable resolvers. This ranges from simple spam protection bypasses (spoofing SPF, DKIM and DMARC) to complete system takeovers.
- In the conclusion of the talk I'll cover some key takeaways and why the DNS is still a hot topic!
Timo Longin is a security consultant at SEC Consult at day and a security researcher at night. Aside from everyday security assessments, he publishes blog posts and security tools, holds talks at conferences and universities, and, most importantly, has a passion for CTFs. His main focus is on web applications; however, infrastructure and hardware are not safe from him either. As a well-rounded offensive security researcher, he tries to find forgotten and new attack vectors that make the unthinkable possible!