The Sin Explained

Lets take a look at how DNS works and then do just a little ad-hoc threat modeling. The client wants to find some serverwell call it www.example.com. The client then sends a request to its DNS server for the IP address (or addresses) of www.example.com. Its importnt to note that DNS runs over the UDP protocol, and you dont even have the slight protections built into the TCP protocol to protect you. The DNS server then takes the request and sees if it has an answer. It could have an answer if it is the authoritative name server for example.com, or it could have a cached answer if someone recently requested resolution of the same name . If it doesnt have the answer, it will ask one of the root servers where to find the authoritative name server for example.com (which might involve another request to the .com server if example.com isnt cached), and then send yet another request to it; and then example.coms name server would reply with the correct result. Fortunately, redundancy is built into the DNS system with multiple servers at every level, which helps protect against nonmalicious failures. Still, there are lots of steps here, and lots of places for things to go wrong due to malicious attackers .

First, how will you know whether your name server really replied? You have a few pieces of information to work withyou sent the request to a specific IP address from a specific port on your system. Next , you know whose name you asked to be resolved. If everything is going well, one would think that if you asked for www.example.com, and got an answer for evilattackers.example.org, youd discard the reply. One of the last pieces of information is a 16-bit request IDin the original design, this number was really meant to keep multiple applications on the same system from interfering with each other, not provide security.

Lets look at each of these pieces of information and see what goes wrong. The first would be the address of the real name server. This is relatively easy for attackers to find out, especially if theyre located on the same network as youit is almost certain they have the same DNS server as you. A second way is to provoke your system into doing a lookup for an IP address served by a DNS server they control. You might think this would be a hard precondition to meet, but given the security record of some implementations of DNS servers, the prospect of an attacker-controlled name server is, unfortunately , likely. So lets assume the attacker knows the IP address of your DNS server. You might think that your client would insist that the reply must come from the same IP address the request was sent to. But the unfortunate reality is that sometimes replies do not come from the same IP address under normal conditions and some resolvers wont insist on the reply IP address being the same as the request IP address.

Next, the reply has to go back to the same source port the request came from. In theory, theres 64K worth of these, but in reality, there is not. On most operating systems, dynamic ports are assigned from a fairly limited rangeWindows systems normally use port numbers from 1024 to 5000, and now youre down to 12 bits of range to search instead of 16. To make matters worse , the ports normally start at 1024 and work their way up incrementally. So now lets assume that the attacker can guess the source port fairly easily.

You also have the request ID to work with, but on many implementations this also increments monotonically, so it isnt hard to guess either. If the attacker is on the same subnet as the client, there are fairly trivial attacks, even on switched networks where the attacker can see the request and will know all of the information needed to spoof a reply.

You then might think that if we asked for the IP address of one system, and got a reply with the address of another unrelated system that our resolver would just ignore this unsolicited information. Very unfortunately, youd be wrong in many cases. Worse yet, if we ask for the IP address of one system and get an answer for another system along with the IP address of what we asked for, you might think the client would again ignore the extraneous information. The cold reality is that the client may not.

By now, youre probably wondering how the Internet manages to function at all, and wondering how it gets worse. The next problem is that every DNS response has a cache timeguess who controls the length of time well believe the result? The reply packet contains this information in the TTL, or time-to-live, field, and the clients normally just believe it.

Next, you might ask just how the DNS server knows it is getting replies from the authoritative name server for the request. The DNS server is then acting as a client, and it is subject to all of the same attacks the client would be vulnerable to. There is a little good news heremost DNS servers are more particular about checking for the consistency of replies, and you shouldnt find a current DNS server that is vulnerable to piggy - backed replies.

You may have heard of DNSSEC , or secure DNS , and think that maybe it could be around the corner and solve our problems. Its been due to solve all our problems for about the last ten years , so please forgive us if were skeptical. For an excellent discussion of the problem, see www.watersprings.org/pub/id/draft-ietf-dnsext-dns-threats-07.txt. A pertinent quote from the abstract:

Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade , the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified.

What else can go wrong? Lets consider that most clients these days use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address, the IP addresses of their DNS servers, and often to notify the DNS server of their names . DHCP makes DNS look positively secure by comparison. We wont bother you with the details; just remember that the name of a client system really ought to be taken as a hint and isnt reliable information.

As you can see, attacking name service resolution isnt especially difficult, but it isnt completely trivial. If you have a low asset value, you may not want to worry about it, but if your assets are worth protecting, then one assumption that must be built into your design is that DNS is unreliable and cannot be trusted. Your clients could get pointed at rogue servers, and attempts to identify client systems using DNS are, likewise, unreliable.

Sinful Applications

The classic example of bad application design is the remote shell, or rsh, server. rsh depends on a .rhosts file being kept in a typically known place on the server, and it contains information about which systems well accept commands from. The system is meant to allow system-to-system processing, and so it doesnt really care about the user on the other end, just that the request originates from a reserved port (1-1023), and is from a system that the server trusts. Theres an amazing number of attacks against rsh, and almost no one uses it any longer. rsh was the service that Kevin Mitnick used to launch an attack against Tsutmu Shimomura. The story is documented in the book Takedown: The Pursuit and Capture of Kevin Mitnick, Americas Most Wanted Computer Outlaw-By the Man Who Did It by Tsutmu Shimomura and John Markoff (Warner Books, 1996). Mitnick used a weakness in the TCP protocol to launch his attack, but it is worth noting that the easier path to accomplish the same objective is to simply corrupt DNS responses.

Another example is Microsofts Terminal Services. The protocol was built without taking into account the possibility of a malicious server, and the cryptography used to transmit the data is subject to man-in-the-middle (MITM) attacks by a server capable of becoming a proxy between the client system and the intended server. IPSec is suggested as a mitigation for the problem, and you can read about it in Knowledge Base article 816521, found at http://support.microsoft.com/default.aspx?scid=kb;en-us;816521.

We wont name names, but there has also been expensive, commercial backup software that enables you to get a copy of anything on the hard drive, or even worse, replace anything on the hard drive if you can convince the client that your name is the same as the backup server. That application was built a few years ago, and with any luck, theyve gotten better.

Related Sins

A related sin is using the name of something to make decisions. Names are subject to canonicalization problems, and they are tricky to get right. For example, www.example.com and www.example.com. (notice the trailing .) are really the same thing. The reason for the trailing period is that people generally like to access local systems with a single name, and if that fails, they use the DNS suffix search list. So if you tried to find server foo, and your search suffix was example.org, the request would go out for foo.example.org. If someone sends out a request for foo.example.org., then the trailing period tells the resolver that this is a fully qualified domain name (FQDN) and not to append anything in the search list. As a side note, this wont happen with current operating systems, but several years ago, Microsofts resolver would walk all the way down the names in the DNS suffix search list, so if foo.example.org wasnt found, it would try foo.org. This can lead to people being accidentally pointed at entirely the wrong server.

Yet another problem is using cryptography that doesnt correctly handle MITM attacks well, or not using cryptography when you should. Well spend more time on that in the Redemption Steps section.



19 Deadly Sins of Software Security. Programming Flaws and How to Fix Them
Writing Secure Code
ISBN: 71626751
EAN: 2147483647
Year: 2003
Pages: 239

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net