Security pitfall: Reverse DNS lookups

Posted by Tom Colvin (CTO), 12 Dec 2011
Why it's important to confirm the results of a reverse DNS lookup by performing a forward lookup.

Many web applications have the facility to limit services based on domain name. Conseal for example can prevent access to a USB device by users outside of a given domain.

In general a user's domain name is obtained by performing a reverse DNS lookup on the client's IP address. This is a very simple case of asking the DNS server associated with the IP for its associated hostname. This can return, for example, host1234.consealsecurity.com. The domain name is then obtained from the latter part of this (ie, consealsecurity.com).

However, relying on this information is naïve. More importantly it breaks the first principle of security: know where your information is coming from. Reverse DNS information comes from the IP address' owner, and is entirely separate from the domain information. It is not authoritative, and does not guarantee that a user is part of the domain they claim to be.

So for example my broadband provider allows me to set my own reverse DNS address. I could easily set it to, say, aaa.microsoft.com in order to pass myself off as a Microsoft employee.

What is the solution?
The solution is simply to check the results of every reverse lookup by performing a forward lookup. For example, if a reverse lookup on a user's IP gives aaa.microsoft.com, then this must be confirmed by looking up aaa.microsoft.com. If this does not give the user's original IP address as one of the return values (forward lookups can return more than one address) then it simply should not be trusted.

You would be surprised how often developers fall into this trap - and it is so easy for hackers to exploit.

0 comments:

Post a Comment