Painless Security

DNS Forgery attacks have been in the news recently in a big way: a story in the New York Times said that details of a new DNS attack will be released this week. The basic idea is that it is possible to trick a recursive name server into believing that responses provided by an attacker should be believed instead of responses provided by the real authoritative DNS server. The recursive name server passes this poisoned data along to its clients who use the information to translate names to addresses and for other DNS functions. As the Wikipedia article points out, a particularly effective target for DNS Forgery are authority records in DNS responses. I.E., if the attacker can overwrite the DNS records that specify what name servers should be consulted for a particular domain, then the attacker can capture all future DNS queries for that domain. For example, if an attacker mounted a forgery against Comcast’s name
servers targeting yahoo.com, then the attacker could control what computers all Comcast customers connect to for any yahoo.com names. The details to be released this week are expected to show how such an attack can be mounted in a number of seconds with high reliability; patches are available although there is ongoing discussion about how effective the patches are. It is quite clear that the patches do not fix the problem at a fundamental level: they are believed to make it much less likely that such an attack can be mounted or to increase the time that the attack will take.

Obviously, this attack is of concern for the global Internet. However the Kerberos community should pay particular attention. As we all know, RFC 4120 states that insecure mapping services such as DNS without DNSSec MUST NOT be used to map user input into authentication names. However, as discussed in The Role of Kerberos in Modern Information Systems, non-Microsoft Kerberos implementations use DNS to map names entered by the user into names that are used within Kerberos. So, consider an attacker that mounts a forgery and is able to modify all DNS responses for example.com. If this attacker can take over a single system registered with example.com’s Kerberos (or learn the Kerberos key of such a system), then they can defeat Kerberos security when authenticating to any system in that Kerberos infrastructure provided that the client uses DNS. There are some core
Kerberos
services such as password changing and the KDC itself that never use DNS in this way. Microsoft implementations also do not depend on this use of DNS. However other implementations tend to use DNS even for relatively sensitive operations such as Ssh used for administrative access to a server. In other words, an easy attack that can be mounted against DNS in a number of seconds is a huge problem for Kerberos. Administrators of Kerberos infrastructure need to insure that DNS server patches are applied in their environments. Hopefully these patches will make the attack hard enough to mount that we have some time to put together a better long-term solution.

We’ve known that this use of DNS is problematic for a long time. We even have better solutions: storing aliases of hosts in KDC databases. I’ve never seen a good solution though to figure out how to get from where we are today to a secure configuration. If you don’t provide a transition strategy, then you will find it difficult to convince users to give up the mode that works in favor of the more secure mode. However at last Tuesday’s Kerberos Working Group meeting, Apple’s Love Hörnquist Åstrand proposed a solution that I think will work. Love proposed that the client learn from the KDC whether a realm supports KDC aliases and has its database properly populated. If the KDC indicates aliases are available, then the client does not use DNS for mapping. The essential bit I had missed before is that this is a realm-by-realm transition. If my client is going to talk to a particular KDC, the question I care about is whether that KDC supports aliases. I had thought you needed some sort of global
transition in the past. Adopting Love’s proposal will take work, especially surrounding APIs such as krb5_sname_to_princ, but doing this work seems critical.

This entry was posted on Tuesday, August 5th, 2008 at 1:41 pm by hartmans and is filed under Kerberos. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.