Differences for page DNS forgery -- hping network security tool

hping wiki

Differences for page DNS forgery

Current version compared with version Wed Nov 17 12:39:06 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
+ 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 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
+ 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).
...
request.

- Because the [UDP] protocol has no built-in authentication of packets, it's trivial to
+ 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 POP, SSH,
- WEB, and any other protocol where DNS resolution is involved).
+ 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 following is the old page content

[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 POP, SSH,
WEB, 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.