BIND 8 Transaction ID Generation Algorithm Lets Remote Users Conduct DNS Cache Poisoning Attacks
SecurityTracker Alert ID: 1018615|
SecurityTracker URL: http://securitytracker.com/id/1018615
(Links to External Site)
Updated: Sep 14 2007|
Original Entry Date: Aug 28 2007
Modification of user information|
Fix Available: Yes Vendor Confirmed: Yes Exploit Included: Yes |
A vulnerability was reported in BIND 8. A remote user can conduct DNS cache poisoning attacks.|
A remote user can poison the cache of any BIND 8 server conducting caching due to a weakness in the transaction ID generation algorithm. A remote user can observe a few consecutive transaction ID values from the target DNS server to predict the next value.
The exploit method is different from that of the BIND 9 DNS cache poisoning attacks.
The vendor was notified on July 26, 2007.
The original advisory is available at:
Amit Klein of Trusteer reported this vulnerability.
A remote user can poison the cache of the target DNS caching server.|
The vendor notes that BIND 8 has reached end-of-life status and that users should upgrade to BIND 9.|
As an interim fix, the vendor has issued patch "P1" for BIND 8.4.7.
Vendor URL: www.isc.org (Links to External Site)
|Underlying OS: Linux (Any), UNIX (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: BIND 8 EOL and BIND 8 DNS Cache Poisoning (Amit Klein, Trusteer)|
BIND 8 EOL and BIND 8 DNS Cache Poisoning
Note: this is a different attack from BIND 9 DNS cache poisoning.
I discovered a new weakness in BIND 8 DNS server which enables "DNS
Forgery Pharming". An attacker can remotely poison the cache of any
BIND 8 caching DNS server and force users who use this DNS server to
reach fraudulent websites each time they try to access real websites.
BIND 8 is still a very popular DNS server nowadays thus this attack
applies to a big part of Internet users.
The concept of DNS cache poisoning was discussed many times before.
However, this attack was considered impractical for the leading
industrial DNS servers due to the transaction ID mechanism that DNS
servers implement today. The transaction ID is supposed to be a
secure, random number that the attacker must guess in order to poison
the DNS cache. There are 65,536 combinations which make enumeration
impractical in the current network conditions.
I've recently found a weakness in the transaction ID generation
algorithm of BIND 8 (both for USE_POOL and for SHUFFLE_ONLY algorithm
variants). By observing a few consecutive transaction IDs from the
same DNS server an attacker can predict its next value. BIND 9's new
algorithm is similar to BIND 8's USE_POOL algorithm (but somewhat
stronger). For BIND 9, a theoretic attack was demonstrated (requires
too many guesses at this stage, but possibly may be improved in the
This weakness can be turned into a mass attack in the following way:
(1) the attacker lures a single user that uses the target DNS server
to click on a link. No further action other than clicking the link is
required (2) by clicking the link the user starts a chain reaction
that eventually poisons the DNS server's cache (subject to some
standard conditions) and associates fraudulent IP addresses with real
website domains. (3) All users that use this DNS server will now reach
the fraudulent website each time they try to reach the real website.
The attack only works when the BIND server is relatively "fresh", i.e.
that it didn't process a lot of queries since it was started (see the
paper for full details).
The algorithms for predicting the transaction ID were coded in Perl
and were demonstrated to work well (and fast!).
The algorithms, as well as the paper, are available Trusteer's website:
Full paper: http://www.trusteer.com/docs/bind8dns.html
ISC were informed on July 26th,
ISC has now declared BIND 8 EOL and recommends upgrade to BIND 9.4.1-P1
Alternative Interim solution: Install patch "P1" for BIND 8.4.7
Versions are available on http://www.isc.org/