hping wiki



Salvatore Sanfilippo, 17Nov2004:

DNS forgery is an attack based on the weak authentication of DNS packets. The DNS protocol is a request-reply protocol, this is how it works: the client wants to resolve the name www.foobar.com. It sends a DNS request to the DNS server (usually the one of the internet provider he is using, if it's a private user with DSL or in dialup). The request is an UDP packet with source IP the one of the client, destination IP the DNS server, the name and type of the request (the IP address for the name www.foobar.com in the example), and a 16-bit ID, that in the best implementations of DNS resolution libraries should not be "guessable". Also there is a source and destination UDP port. The destination port is of course 53, while the source should be mostly unguessable (again, in the ideal implementation of a DNS resolver).

The DNS server receives such a request, and replies with a similar UDP packet copying the ID in the reply, so that the requester can check if the two 16-bit IDs match. Of course the reply is sent to the same UDP port the client used as source port for the request.

Because the UDP protocol has no built-in authentication of packets, it's trivial to send spoofed packets, so the idea of the DNS forgery attack is to send a fake DNS reply with a matching source IP, destination port, request ID, but with an attacker manipulated information inside, so that this fake reply may be processed by the client before the real reply is received form the real DNS server. This way, the attacker may force a given client that is trying to resolve www.foobar.com, to connect to a different IP address (for POP3, SSH, HTTP, and any other protocol where DNS resolution is involved).

What the attacker needs to guess in order to make a successful attack?
  • The request ID, a 16 bit number.
  • The destination port, a 16 bit number.
  • The DNS server IP address (easy to guess)
  • The requested information (easy to guess in some case, for example email clients ask for resolution of the POP3 server name often)
  • The time of the request (easy to guess if there are requests made often by the client. Some times it's possible to trigger a query in some way)


If the DNS resolver implementation the client is using is not perfect, the request ID, and the destination PORT may not require a real 16-bit search, for example many resolvers don't use a random source port, but just the one assigned by the operating system (usually a port with a low value, expecially if the system uptime is not high). Also the ID may be just sequential. So the attack in the pratice may be feasible, but there are not very good tools around to perform such an attack.
 
Edit this page Upload file Page history - Page last update: Wed Nov 24 02:04:21 GMT 2004 by 68.194.48.16 | Your address: 54.162.10.211 | Admin