[aklug] DNS cache poisoning

From: Jenkinson, John P (SAIC) <John.Jenkinson@bp.com>
Date: Wed Jul 23 2008 - 10:28:41 AKDT

=20
seems the exploit to the DNS cache poisoning vulnerability that the
researcher
was so careful to protect until a very well coordinated effort by
vendors to
patch (mitigation not elimination patch)release has been leaked by
someone who was
briefed on the exploit in confidence. the leakers claim the leak was a
blog post
being prepared for release after the scheduled black hat talk Aug 7.
anyway
some news here from the internet storm center
http://isc.sans.org/diary.html?storyid=3D4765
remember the patch just mitigates by making the transaction ID more
random.=20
the cryptographic space is still quite small at 16 bits.
also be aware that checkpoint firewalls re-order the nice new random
source
udp port numbers to nice sequential ones. making the attack trivial.
the above article shows how to check your queries after they leave your
network.
a more detailed write up on the alleged specifics of the vulnerability
are here:
http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html
a web cast with Cricket Liu and Dan Kaminsky (the researcher who
discovered this
vulnerability) is here:
http://www.snpnet.com/customer_pub/Infoblox/DNSJuly2008/index.html

a possible means for an attack might involve:
having a site with a web server and a dns authoritive server for a trash
domain
the user is lured to the web site by phishing or similar
the web site has 65000+ subdomain DNS lookups for the domain it is
authority for
and a tag to lookup yourbank.com. the dns query requests are all
captured. the replies=20
are not given back immediately so the outstanding request ids and udp
source ports are
tied up, thus reducing the possible cryptographic space. the attacker
knows you have
a dns lookup for yourbank.com as they have planted one. if your dns
entry in your local
dns cache has had its time to live expire and the attacker can more
easily quess the
request id and source upd port number from the info they have from your
dns patterns
from that evil site visit and can beat the reply back to your machine
with the reply
your resolver with cache the bad info. now when you browse to
yourbank.com you'll go
instead to the evil site's copy of to a proxy they control that sends
you to yourbank
after routing thru their web proxy. then they can capture login info
like username and=20
password. then some of the enhanced features of banks like image
verification will still
work. also any cookies, hidden element fields and such will also be
valid.

so=20
suggest running the dig and/or nslookup commands given in the internet
storm center=20
        article.=20
        patch as soon as possible if you've not already
        realize the patching is a mitigation not elimination measure
        use browser helper objects, plugins, addons that do dns
consistency
        checks.
        use a virtual machine for financial transactions with one
window/tab
        open
        be careful out ther.
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Jul 23 10:29:11 2008

This archive was generated by hypermail 2.1.8 : Wed Jul 23 2008 - 10:29:12 AKDT