[aklug] Re: DNS Exploit

From: Jenkinson, John P (SAIC) <John.Jenkinson@bp.com>
Date: Wed Jul 09 2008 - 16:43:45 AKDT

i think it's the protocol that's vulnerable.=20
the DNS protocol is old 16-bit request id good when=20
machines were 16-bit or smaller.=20
reminder
dns query is udp (save for large responses using tcp)
the source port is usually 53, can use other ports in more
recent implementations BUT the response needs to reappear on the
source request port.
so you either don't have a DNS server (utilize your ISPs or other)
                which places you at their mercy
or you "patch" yours. patching is now known to incur a performance
penalty,
render zone alarm problems, etc.
BUT your upstrean DNS server can still be vulnerable and pass you the
"poisioned" dns response from their cache.
so in theory a bad person can monitor traffic, capture the request ID
and
port, respond with a response that steers your bank transaction to their
site
instead of your banks. they just have to beat the real response

bottom line (imho) the ends are still vulnerable if the patch is applied
in the middle.
ie its more of a client issue than media reports to date might indicate.

-----Original Message-----
From: aklug-bounce@aklug.org [mailto:aklug-bounce@aklug.org] On Behalf
Of Leif Sawyer
Sent: Wednesday, July 09, 2008 4:31 PM
To: aklug
Subject: [aklug] Re: DNS Exploit

 1) Check to see if you're vulnerable using the website
     www.doxpara.com

 2) If you are, you can upgrade to the latest bind patch level
     from ISC.
or
 3) you can wait until your vender issues a patch.

 4) You can enable DNSSEC on your server. This really will
     mitigate the entire issue.

> -----Original Message-----
> From: aklug-bounce@aklug.org [mailto:aklug-bounce@aklug.org]=3D20
> On Behalf Of barsalou
> Sent: Wednesday, July 09, 2008 4:25 PM
> To: jonr@destar.net
> Cc: aklug
> Subject: [aklug] Re: DNS Exploit
>=3D20
> Jon,
>=3D20
> Practically speaking, what can most folks do about this? =3D20
> What are =3D3D20 some of the steps that you have taken to=3D20
> mitigate this for yourself?
>=3D20
> Mike B.
>=3D20
> Quoting Jon Reynolds <jonr@destar.net>:
>=3D20
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > National Cyber Alert System
> >
> > Technical Cyber Security Alert TA08-190B
> >
> >
> > Multiple DNS implementations vulnerable to cache poisoning
> >
> > Original release date: July 08, 2008
> > Last revised: --
> > Source: US-CERT
> >
> >
> > Systems Affected
> >
> > Systems implementing:
> > * Caching DNS resolvers
> > * DNS stub resolvers
> >
> > Affected systems include both client and server=3D20
> systems, and any other
> > networked systems that include this functionality.
> >
> >
> > Overview
> >
> > Deficiencies in the DNS protocol and common DNS
implementations=3D20
> > facilitate
> > DNS cache poisoning attacks. Effective attack=3D20
> techniques against these
> > vulnerabilities have been demonstrated.
> >
> >
> > I. Description
> >
> > DNS cache poisoning (sometimes referred to as cache=3D20
> pollution) is=3D20
> > an attack
> > technique that allows an attacker to introduce forged DNS=3D20
> > information into
> > the cache of a caching nameserver. The general concept has
been=3D20
> > known for
> > some time, and a number of inherent deficiencies in the DNS=3D20
> > protocol a=3D3D
> nd
> > defects in common DNS implementations that facilitate DNS
cache=3D20
> > poisoning
> > have previously been identified and described in public=3D20
> literature.
> > Examples
> > of these vulnerabilities can be found in Vulnerability=3D20
> Note VU#800113.
> >
> > Recent research into these and other related=3D20
> vulnerabilities has=3D20
> > produced
> > extremely effective exploitation methods to achieve=3D20
> cache poisoning.
> > Tools
> > and techniques have been developed that can reliably poison =
a=3D20
> > domain of the
> > attacker's choosing on most current implementations.=3D20
> As a result, the
> > consensus of DNS software implementers is to=3D20
> implement source port
> > randomization in their resolvers as a mitigation.
> >
> > US-CERT is tracking this issue as VU#800113. This=3D20
> reference number
> > corresponds to CVE-2008-1447.
> >
> >
> > II. Impact
> >
> > An attacker with the ability to conduct a successful cache=3D20
> > poisoning attack
> > can cause a nameserver's clients to contact the incorrect,
and=3D20
> > possibl=3D3D
> y
> > malicious, hosts for particular services. Consequently, web=3D20
> > traffic, email,
> > and other important network data can be redirected to =
systems=3D20
> > under th=3D3D
> e
> > attacker's control.
> >
> >
> > III. Solution
> >
> > Apply a patch from your vendor
> >
> > Patches have been released by a number of vendors to
implement=3D20
> > source port
> > randomization in the nameserver. This change=3D20
> significantly reduces the
> > practicality of cache poisoning attacks. Please see the
Systems=3D20
> > Affect=3D3D
> ed
> > section of Vulnerability Note VU#800113 for additional=3D20
> details for=3D20
> > specific
> > vendors.
> >
> > As mentioned above, stub resolvers are also vulnerable to
these=3D20
> > attack=3D3D
> s.
> > Stub resolvers that will issue queries in response to
attacker=3D20
> > behavior, and
> > may receive packets from an attacker, should be=3D20
> patched. System
> > administrators should be alert for patches to client
operating=3D20
> > systems that
> > implement port randomization in the stub resolver.
> >
> > Workarounds
> >
> > Restrict access
> > Administrators, particularly those who are unable to apply =
a=3D20
> > patch, ca=3D3D
> n
> > limit exposure to this vulnerability by restricting=3D20
> sources that=3D20
> > can ask for
> > recursion. Note that restricting access will still=3D20
> allow attackers=3D20
> > wit=3D3D
> h
> > access to authorized hosts to exploit this vulnerability.
> >
> > Filter traffic at network perimeters
> > Because the ability to spoof IP addresses is necessary=3D20
> to conduct=3D20
> > thes=3D3D
> e
> > attacks, administrators should take care to filter spoofed=3D20
> > addresses at the
> > network perimeter. IETF Request for Comments (RFC)=3D20
> documents RFC=3D20
> > 2827, RFC
> > 3704, and RFC 3013 describe best current practices (BCPs) =
for=3D20
> > implementing
> > this defense. It is important to understand your network's=3D20
> > configuration and
> > service requirements before deciding what changes are=3D20
> appropriate.
> >
> > Run a local DNS cache
> > In lieu of strong port randomization characteristics in a
stub=3D20
> > resolve=3D3D
> r,
> > administrators can protect their systems by using local
caching=3D20
> > full-service
> > resolvers, both on the client systems and on servers that =
are=3D20
> > topologically
> > close on the network to the client systems. This=3D20
> should be done in
> > conjunction with the network segmentation and filtering=3D20
> strategies=3D20
> > mentioned
> > above.
> >
> > Disable recursion
> > Disable recursion on any nameserver responding to DNS=3D20
> requests made by
> > untrusted systems.
> >
> > Implement source port randomization
> > Vendors that implement DNS software are encouraged to=3D20
> review IETF=3D20
> > Internet
> > Draft, "Measures for making DNS more resilient against =
forged=3D20
> > answers," for
> > additional information about implementing mitigations in
their=3D20
> > product=3D3D
> s.
> > This document is a work in progress and may change prior to
its=3D20
> > publication
> > as an RFC, if it is approved.
> >
> >
> > IV. References
> >
> > * US-CERT Vulnerability Note VU#800113 -
> > <http://www.kb.cert.org/vuls/id/800113>
> > * US-CERT Vulnerability Note VU#484649 -
> > <http://www.kb.cert.org/vuls/id/484649>
> > * US-CERT Vulnerability Note VU#252735 -
> > <http://www.kb.cert.org/vuls/id/252735>
> > * US-CERT Vulnerability Note VU#927905 -
> > <http://www.kb.cert.org/vuls/id/927905>
> > * US-CERT Vulnerability Note VU#457875 -
> > <http://www.kb.cert.org/vuls/id/457875>
> > * Internet Draft: Measures for making DNS more=3D20
> resilient against=3D20
> > forged
> > answers -
> > =3D20
> <http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience>
> > * RFC 3833 - <http://tools.ietf.org/html/rfc3833>
> > * RFC 2827 - <http://tools.ietf.org/html/rfc2827>
> > * RFC 3704 - <http://tools.ietf.org/html/rfc3704>
> > * RFC 3013 - <http://tools.ietf.org/html/rfc3013>
> > * Microsoft Security Bulletin MS08-037 -
> > =3D20
> <http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx>
> > * Internet Systems Consortium BIND =3D20
> Vulnerabilities -
> > <http://www.isc.org/sw/bind/bind-security.php>
> >
> > =3D20
> ____________________________________________________________________
> >
> > US-CERT thanks Dan Kaminsky of IOActive and Paul Vixie=3D20
> of Internet=3D20
> > Systems
> > Consortium (ISC) for notifying us about this problem and =
for=3D20
> > helping us to
> > construct this advisory.
> > =3D20
> ____________________________________________________________________
> >
> > The most recent version of this document can be found at:
> >
> > <http://www.us-cert.gov/cas/techalerts/TA08-190B.html>
> > =3D20
> ____________________________________________________________________
> >
> > Feedback can be directed to US-CERT Technical Staff. Please send
> > email to <cert@cert.org> with "TA08-190B Feedback=3D20
> VU#800113" in the
> > subject.
> > =3D20
> ____________________________________________________________________
> >
> > For instructions on subscribing to or unsubscribing from this
> > mailing list, visit <http://www.us-cert.gov/cas/signup.html>.
> > =3D20
> ____________________________________________________________________
> >
> > Produced 2008 by US-CERT, a government organization.
> >
> > Terms of use:
> >
> > <http://www.us-cert.gov/legal.html>
> > =3D20
> ____________________________________________________________________
> >
> >
> > Revision History
> >
> > July 8, 2008: Initial release
> > ---------
> > To unsubscribe, send email to <aklug-request@aklug.org> with=3D20
> > 'unsubscribe' in the message body.
> >
>=3D20
>=3D20
>=3D20
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>=3D20
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org> with=3D20
> 'unsubscribe' in the message body.
>=3D20
>=3D20
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Jul 9 16:44:03 2008

This archive was generated by hypermail 2.1.8 : Wed Jul 09 2008 - 16:44:03 AKDT