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.
| | |