Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I read the following statement in a security blog

using the same source port over and over again for dns queries instead of randomizing them is a vulnerability for dns poisoning

Could somebody elaborate on how this is a vulnerability and how it could possibly be exploited?

share|improve this question
    
Just to add to the answers, here is a link that lists the port ranges used by Windows Server 2008: technet.microsoft.com/en-us/library/dd197515%28v=ws.10%29.aspx –  wondersz1 Mar 4 '13 at 13:18
add comment

2 Answers

up vote 8 down vote accepted

Since DNS usually runs over UDP, response packets can be readily spoofed. UDP packets are identified by the combination of source and destination IP address and source and destination port numbers.

The classic DNS poisoning attack is to send a DNS server a query which you think will cause the server to do a recursive lookup, and then blast away at the server with spoofed response packets for the secondary request you expect the server to make. If you get the right IP/port combinations and transaction ID and your answer arrives first, your faked answer could be accepted and inserted into the cache.

Well, we know the source and destination IP address ahead of time, and we know that DNS runs on port 53, so that's one of the port numbers. Assuming DNS queries get sent FROM port 53 as well as being sent TO port 53, then we've got all 4. Then all we have to worry about is the transaction ID, which is a 16-bit number. That means each packet we send has a 1 in 65K chance of striking gold. We could easily spam out several thousand packets in just a second or so, which gives us a decent chance of poisoning the server's cache. If we push out 10K response packets before the "real" response comes in, that gives us about a 1 in 6 chance overall of success. And if it fails, we just wait for expiry and try again.

But, if the server uses a random outbound port number on recursive lookup queries, then that adds another 16 bits worth of material that we have to guess right for our response to be accepted. So that's a total of 32-bits, or about 4 billion possibilities. That means that our odds for each packet go from 1 in 65,536 to 1 in 4,294,967,296, which becomes a bit prohibitive.

So while you can't be 100% certain that a response isn't spoofed, the odds are weighted much more in the favor of the defender if he randomizes his source ports for his secondary lookups; enough so to dissuade most attackers from investing the resources to try the attack.

share|improve this answer
    
Do you see any problem if an end-client - not a DNS server sends dns queries over the same port over and over again? –  DaTaBomB May 24 '12 at 10:33
    
the same principle applies, but it's a lower-value target and more difficult to orchestrate. But still theoretically possible. –  tylerl May 24 '12 at 17:34
add comment

There are a lot of factors which play an important role in DNS poisoning but most probably the main one is timing. Using the same source port over and over again gives the attacker a huge time boost advantage, as he already knows the port he needs to send his queries to. If an attacker, with a rogue DNS server is able to reply to your request in a faster manner than the actual DNS server, he can redirect your query (let's say www.example.com) to an IP address controlled by him. If he has setup an identical website to www.example.com, you wouldn't notice any difference between the two.

That's why, as a prevention and mitigation technique, DNS requests will have random source ports. This and other mechanisms (use of cryptographically-secure random numbers for selecting both the source port and the 16-bit cryptographic nonce) greatly reduce the probability of successful DNS poisoning and other DNS attacks.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.