[unisog] DNS security advisory

Morrow Long morrow.long at yale.edu
Tue Jul 8 20:21:03 GMT 2008


This is not spam.  This is a real.

See isc.sans.org :	

	http://isc.sans.org/diary.html?storyid=4684

Morrow

On Jul 8, 2008, at 4:11 PM, Alan Clegg wrote:

> Spam detection software, running on the system "iceman11.giac.net",  
> has
> identified this incoming email as possible spam.  The original message
> has been attached to this so you can view it (if it isn't spam) or  
> label
> similar future email.  If you have any questions, see
> noc at sans.org for details.
>
> Content preview:  -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 CERT  
> VU#800113
>   DNS Cache Poisoning Issue ISC characterization: Query Port  
> Randomization
>  for BIND 9 ANYONE RUNNING BIND AS A CACHING RESOLVER IS AFFECTED.  
> [...]
>
> Content analysis details:   (5.9 points, 5.0 required)
>
> pts rule name              description
> ---- ----------------------  
> --------------------------------------------------
> 0.0 BAYES_50               BODY: Bayesian spam probability is 40 to  
> 60%
>                            [score: 0.5000]
> 5.9 AWL                    AWL: From: address is in the auto white- 
> list
>
>
>
> From: Alan Clegg <alan at clegg.com>
> Date: July 8, 2008 4:11:02 PM EDT
> To: UNIversity Security Operations Group <unisog at lists.dshield.org>
> Subject: DNS security advisory
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> CERT VU#800113 DNS Cache Poisoning Issue
> ISC characterization: Query Port Randomization for BIND 9
>
> ANYONE RUNNING BIND AS A CACHING RESOLVER IS AFFECTED.
>
> Severity: High
>
> No known exploits to-date
>
> DNSSEC is the only solution.  Available versions of BIND that provide
> increased resilience:
>
> BIND 9.5.0-P1
> BIND 9.4.2-P1
> BIND 9.3.5-P1
>
> BIND 9.5.1b1
> BIND 9.4.3b2
>
> Note:  BIND8 is also vulnerable, but it has reached end-of-life and is
> no longer supported by ISC.
>
> Description:
>
> Thanks to recent work by Dan Kaminsky of IOActive, ISC has become  
> aware
> of a potential attack exploiting weaknesses in the DNS protocol  
> itself.
> (Full details of the vulnerability will be explained by Kaminsky at
> the Black Hat conference on August 7th.)  The weakness is inherent to
> the DNS protocol and not specific to any single implementation.  The  
> DNS
> protocol uses the Query ID field to match incoming responses to
> previously sent queries.  The Query ID field is only 16 bits, which
> makes it an easy target to exploit in the particular spoofing scenario
> described by Kaminsky.
>
> Immediate action required:
>
> IF YOU ARE RUNNING BIND AS A CACHING RESOLVER YOU NEED TO TAKE ACTION.
>
> DNSSEC is the only definitive solution for this issue.  Understanding
> that immediate DNSSEC deployment is not a realistic expectation, ISC  
> is
> releasing patched versions of BIND that improve its resilience against
> this attack.
>
> The method used in the patches and beta releases makes it harder to
> spoof answers to a resolver by expanding the range of UDP ports from
> which queries are sent by the nameserver, thereby increasing the
> variability of parameters in outgoing queries.
>
> WE URGE YOU TO INSTALL EITHER THE PATCHES (9.5.0-P1, 9.4.2-P1, 9.3.5- 
> P1)
> OR THE BETA RELEASES (9.5.1B1, 9.4.3B2) IMMEDIATELY.
>
> The patches will have a noticeable impact on the performance of BIND
> caching resolvers with query rates at or above 10,000 queries per
> second.  The beta releases include optimized code that will reduce the
> impact in performance to non-significant levels.
>
> DNS administrators who operate these servers behind port-restricted
> firewalls are encouraged to review their firewall policies to allow  
> this
> protocol-compliant behavior.  Restricting the possible use of various
> UDP ports, for instance at the firewalls, in outgoing queries and the
> corresponding replies will result in decreased security for the DNS  
> service.
>
> Again, DNSSEC is the definitive solution to this type of attack.  ISC
> strongly encourages DNS administrators to deploy DNSSEC as soon as
> possible to fully address this problem.  DNS domain owners that want
> their data to be protected against spoofing to the end-user must sign
> their zones.  ISP and Enterprise DNS administrators who provide  
> caching
> recursive nameservers to their users should enable DNSSEC validation.
>
> DNSSEC Lookaside Validation (DLV), offered by ISC and others, is  
> another
> DNSSEC deployment option.
>
> Additional Assistance and resources available from ISC:
>
> BIND 9 software support - http://www.isc.org/sw/support/
>
> Managed caching resolvers:  Through September 30, 2008, ISC support
> customers have the option of forwarding their recursive servers  
> queries
> to caching resolvers deployed on ISC's SNS production network while  
> the
> required software upgrades are performed on their own networks.  For
> additional information on this option, please open a ticket in your
> support queue with the subject line including "forwarder service."
>
> ISC DLV:  https://secure.isc.org/ops/dlv/
>
> DNSSEC tools & presentations:
>
> http://www.isc.org/training/syllabus_intro_advanced.php
> http://www.isc.org/sw/bind/docs/dnssec.html
> http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf
> http://www.ripe.net/training/dns/index.html
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIc8nWcKpYUrUDCYcRAl0dAJ95w4MB67Cp8phd+ddRLnt6vpnVSACgm5nE
> FcdU0pmFgv65nosA3dmOwdU=
> =gsx/
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sans.org/pipermail/unisog/attachments/20080708/efd5e1d4/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3207 bytes
Desc: not available
Url : http://lists.sans.org/pipermail/unisog/attachments/20080708/efd5e1d4/attachment-0001.bin 


More information about the unisog mailing list