Current version compared with version Wed Nov 17 12:41:29 GMT 2004...
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
+ 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
+ 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).
+ 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
+ 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
+ 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).
+ 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 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
+ 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.
...
The following is the old page content
|