Re: Defending Networks Against DNS Rebinding AttacksThe Famous Brett Watson – Aug 09, 2007 6:34 PM PST
The problem here is one of authorisation. As the zone administrator of a domain name, I have the ability to make DNS records in my zone refer to any valid resource, whether or not that resource has anything to do with me. Herein lies the problem. The actual party responsible for the resource in question—usually a host—has no say in the matter. DNS records point in one direction—from the name to the resource—and do so without restriction.
What's missing is the ability of a host to repudiate an identity ascribed to it—to authorise the use of the name (or not). A client looks up "foo.attacker.com" and finds its IP address: it must then be possible for the host at that IP address to somehow repudiate or affirm that identity before the client interacts further.
We already have an infrastructure in place to do this: reverse DNS lookups under the "in-addr.arpa" space. A very quick fix that could be applied to this security problem would be to verify the host name by seeking the corresponding "PTR" record in "in-addr.arpa" space. The attacker would then need to compromise the appropriate section of "in-addr.arpa" space before the attack could work.
This is not a new concept. Every host is supposed to be fully resolvable in reverse using this technique already, but the practice is widely neglected (in some regions more so than others). Maintenance of this address space is, I think, seen as broadly inconvenient and unnecessary. This kind of attack demonstrates why it is necessary, and security almost invariably entails some inconvenience.
The problem here is one of authorisation. As the zone administrator of a domain name, I have the ability to make DNS records in my zone refer to any valid resource, whether or not that resource has anything to do with me. Herein lies the problem. The actual party responsible for the resource in question—usually a host—has no say in the matter. DNS records point in one direction—from the name to the resource—and do so without restriction.
What's missing is the ability of a host to repudiate an identity ascribed to it—to authorise the use of the name (or not). A client looks up "foo.attacker.com" and finds its IP address: it must then be possible for the host at that IP address to somehow repudiate or affirm that identity before the client interacts further.
We already have an infrastructure in place to do this: reverse DNS lookups under the "in-addr.arpa" space. A very quick fix that could be applied to this security problem would be to verify the host name by seeking the corresponding "PTR" record in "in-addr.arpa" space. The attacker would then need to compromise the appropriate section of "in-addr.arpa" space before the attack could work.
This is not a new concept. Every host is supposed to be fully resolvable in reverse using this technique already, but the practice is widely neglected (in some regions more so than others). Maintenance of this address space is, I think, seen as broadly inconvenient and unnecessary. This kind of attack demonstrates why it is necessary, and security almost invariably entails some inconvenience.