I don’t know about you, but I’ve always been frustrated when reading articles about DNS Server Attacks and they never explain exactly how they work. It’s obvious that such a thing would be a point of extreme interest to an attacker, but how do they do it???
I interviewed Ben Tucker, XenApp Developer on the Guardian Security Team, to finally understand this thing. Ben worked previously in the Gaming Industry creating and securing slot machines, communications protocols, and distributed systems.
Here is a picture of Ben:
Q: What is DNS?
A: DNS is a computer protocol that translates human-understandable web names, such as google.com, into IP addresses. It’s basically a telephone book that answers requests from a client to get them to the web site they want. A DNS server answers requests and forms them into IP addresses so connections can be made. A DNS server might talk with other servers until an authoritative answer is received.
Q: What are the basic vulnerabilities of this technology?
A: The client computer does not authenticate that the server providing IP addresses is really the right DNS server. Therefore, the client has no verification that they are talking to the right DNS server, or a malicious entity, such as evil.com.
This vulnerability has been around for twenty five years. To complicate this further, DNS is a layered protocol. A client in one layer might be the server from another layer. So, this vulnerability pervades computers that lack trusted and authenticated communications.
Q: What has been done to fix this long-known vulnerability?
A: When DNS was designed the security landscape was far more subdued than it is now. Different ways to exploit the lack of authentication have been found over time. Likewise, a series of mitigations have been implemented. Until the last decade, transaction IDs were ascending and predictable. Six years ago, a related implementation error led to an attack on the DNS protocol using the mathematics of the Birthday Paradox. Overall, DNS has been a fertile ground for exploitation.
Q: So the problem was solved?
A: No. The recent DNS debacle involves forcing large numbers of fake DNS replies to a caching resolver while simultaneously controlling a client computer’s requests. Having a client repeatedly look for a DNS server gives the attacker more of a chance to improperly present evil.com as an authoritative DNS server. Once the attacker beats the proper server with a response, then bankofamerica.com may look and feel correct to the user, but that user would be giving logon credentials to another entity entirely.
Q: Why has this been in the news lately?
First he uncovered a platform agnostic exploit that poisons a DNS cache within seconds. Then, before releasing this exploit to the public, he worked with major vendors including Citrix to provide patches mitigating the problem. Kaminsky’s mitigation randomizes the protocol’s source port as well as the transaction ID. Now, the random transaction ID’s are associated with random source ports, creating a more difficult problem for attackers in these race attacks.
Q: How can Citrix help with this problem?
A: We have two KB articles that may be helpful. Please see:
Vulnerability in Access Gateway Standard and Advanced Edition Appliance firmware could result in DNS Cache Poisoning (CTX118183)Vulnerability in NetScaler and Access Gateway Enterprise Edition could result in DNS Cache Poisoning (CTX117991)
Q: Does HTTPS help at all?
A: Yes. HTTPS ensures that traffic is encrypted end-to-end. With HTTPS, browsers can more easily notify users if the site being contacted doesn’t match the intended site, if the certificate has expired, or if the certificate doesn’t have a clear chain of trust to a known Certificate Authority.
Another suggestion for customers is to consider using an Intrusion Detection System (IDS) from a security vendor or reputable security source. This should be setup to guard corporate DNS server’s from attacks.