July 2008 - Test - lists.nanog.org

Multiple DNS implementations vulnerable to cache poisoning
by Buhrmaster, Gary 25 Jul '08

25 Jul '08

Multiple DNS implementations vulnerable to cache poisoning: http://www.kb.cert.org/vuls/id/800113 (A widely coordinated vendor announcement. As always, check with your vendor(s) for patch status.) Gary

33 53

Re: Exploit for DNS Cache Poisoning - RELEASED
by Paul Ferguson 25 Jul '08

25 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Robert D. Scott" <robert(a)ufl.edu> wrote: >Now, there is an exploit for it. > >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt Now also (mirrored) here: http://www.milw0rm.com/exploits/6122 ...and probably a slew of other places, too. ;-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIh9qmq1pz9mNUZTMRAuXEAJ0cmn10Rz4Z0RG5LfseroFFvLbUmgCgipoV rLDjjPCo+7w7+aV8udRK7fc= =n1cC -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

3 3

[OT] 2008 Infrastructure Security Survey
by Danny McPherson 24 Jul '08

24 Jul '08

Folks, The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL: <https://www.tcb.net/survey/index.php?sid=19672&lang=en> I've added many questions this time from past participants of the survey, this should be evidenced throughout. Thanks to all those that reviewed and provided questions explicitly for this edition. The survey response window will be ~2 weeks. We hope to make the results available by the end of September at the latest. Also, please recall that NO personally (or organizationally) identifiable information will be shared in any manner. The 2007 edition of the survey is available here: <http://www.tcb.net/wisp07.pdf> Or on the Arbor web site (reg required): <http://www.arbornetworks.com/report> Thanks in advance for your participation! -danny

1 0

Issues with testing tests (DNS randomization checks)
by Sean Donelan 24 Jul '08

24 Jul '08

There are several threads about various DNS testing tools sometimes reporting ISPs have or have not "patched/changed" their DNS servers. This particular thread collects several of the issues in regards to the Comcast DNS servers, but the same issues with the testing sites is applicable to anyone testing other DNS servers. http://www.dslreports.com/forum/r20839639-DNS-Comcast-and-the-DNS-Server-fl…

1 0

2nd Exploit for DNS Cache Poisoning - RELEASED
by Tuc at T-B-O-H.NET 24 Jul '08

24 Jul '08

Hi, Not sure if anyone has seen yet, but there is a 2nd exploit being circulated. I just picked it up on metasploits SVN trunk.... The first was called "baliwicked_host", and the description was : This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit caches a single malicious host entry into the target nameserver by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and due to the additional hostname entry being within bailiwick constraints of the original request the malicious host entry will get cached. The new one is called "baliwicked_domain" and its described as : This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target domains nameserver entries in a vulnerable DNS cache server. This attack works by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and the nameserver entries for the target domain will be replaced by the server specified in the NEWDNS option of this exploit. Tuc/TBOH

2 1

Re: 2nd Exploit for DNS Cache Poisoning - RELEASED
by Paul Ferguson 24 Jul '08

24 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Tuc at T-B-O-H.NET" <ml(a)t-b-o-h.net> wrote: >Not sure if anyone has seen yet, but there is a 2nd >exploit being circulated. I just picked it up on metasploits >SVN trunk.... I haven't seen that one yet, but I just ran across this: http://www.milw0rm.com/exploits/6123 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIiNBFq1pz9mNUZTMRAozhAKD+IkD/HGywNFttPI6ilKreNGP0UQCeKZ98 u76UOCvKXD9+zvdlSR8S/oc= =N5am -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

RE: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?
by Justin M. Streiner 24 Jul '08

24 Jul '08

On Thu, 24 Jul 2008, Scott Berkman wrote: > Is it just me or is the test page below down now? > > Or maybe some poisoned the NS record for dns-oarc.net and sent it to > nowhere to stop testing! (J/K since I can get to the rest of the page > fine). Might be the Slashdot effect, in a manner of speaking, since the NANOG community is quite large. jms

1 0

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?
by Rubens Kuhl Jr. 24 Jul '08

24 Jul '08

Some broadband providers here in .br seems to be blocking access to the dns-oarc.net test zone (but not to the portal site); most thought it was intended behavior by those providers (hiding instead of patching), but you are right, someone might have corrupted the test zone itself, which aleviates the pressure on the provider to patch it which in turn keeps the exploits working for more time. Rubens On Thu, Jul 24, 2008 at 3:45 PM, Scott Berkman <scott.berkman(a)reignmaker.net> wrote: > Is it just me or is the test page below down now? > > Or maybe some poisoned the NS record for dns-oarc.net and sent it to > nowhere to stop testing! (J/K since I can get to the rest of the page > fine). > > -Scott > > -----Original Message----- > From: Ken A [mailto:ka@pacific.net] > Sent: Thursday, July 24, 2008 2:40 PM > To: Steve Tornio > Cc: nanog(a)merit.edu > Subject: Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally > leaked? > > Steve Tornio wrote: >> >> On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote: >> >>>> xpara.com tests to lock up my iPhone, or I would use that checker to >>>> verify the iPhone DNS. Anyone have a link to a decent test that I >>>> could run on the iPhone? >>> >>> Give this one a try: >>> >>> http://entropy.dns-oarc.net/test/ >>> >> >> In this test, my iPhone reports: >> >> 209.183.33.23 Source Port Randomness: GREAT >> 209.183.33.23 Transaction ID Randomness: GREAT >> >> I encourage anyone else concerned with their providers to actually test >> them instead of taking anyone's word for it. >> >> Steve >> > > on AT&T you might want to run it more than once.. Mine shows POOR 1 out > of 5 times. :-( > Hope they finish patching sooooon! > Ken > > -- > Ken Anderson > Pacific.Net > > > >

1 0

Independent Testing for Network Hardware
by Brian Knoll (TT) 24 Jul '08

24 Jul '08

Can anyone recommend a reliable independent testing company that tests network hardware performance? We are considering buying testing hardware (right now we are looking at Spirent TestCenter) and I wanted to see if there were other options... Brian Knoll

5 6

SBCglobal routing loop.
by Logan Rawlins 24 Jul '08

24 Jul '08

Anyone from sbcglobal out there? i'm seeing a routing loop. Please contact me off list thanks. sourceip: 69.16.137.66 tracert 75.58.215.133 Tracing route to adsl-75-58-215-133.dsl.hstntx.sbcglobal.net [75.58.215.133] over a maximum of 30 hops: 1 2 ms <1 ms <1 ms 192.168.113.1 2 1 ms 2 ms 2 ms 69.16.137.66 3 1 ms 2 ms 2 ms e-2-21-1000m.core-04.phx2.puregig.net [69.16.128 .110] 4 2 ms 2 ms 5 ms v303.ar1.ph.hwng.net [69.16.128.137] 5 1 ms 1 ms 2 ms ve1011.r2.ph.hwng.net [69.16.190.161] 6 11 ms 20 ms 11 ms 2-1.r1.la.hwng.net [69.16.191.37] 7 12 ms 11 ms 11 ms vl101.ar1.lax1.us.nlayer.net [69.31.127.29] 8 11 ms 11 ms 11 ms ae0-60.cr1.lax1.us.nlayer.net [69.31.127.165] 9 11 ms 11 ms 11 ms ex1-g12-0.eqlaca.sbcglobal.net [69.31.127.50] 10 11 ms 11 ms 11 ms 151.164.188.139 11 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 12 11 ms 11 ms 11 ms 151.164.188.139 13 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 14 14 ms 11 ms 11 ms 151.164.188.139 15 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 16 11 ms 11 ms 11 ms 151.164.188.139 17 11 ms 12 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 18 11 ms 11 ms 11 ms 151.164.188.139 19 12 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 20 12 ms 11 ms 11 ms 151.164.188.139 21 11 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 22 11 ms 11 ms 11 ms 151.164.188.139 23 14 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 24 11 ms 11 ms 11 ms 151.164.188.139 25 11 ms 11 ms 16 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 26 14 ms 11 ms 12 ms 151.164.188.139 27 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 28 12 ms 11 ms 11 ms 151.164.188.139 29 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 30 11 ms 11 ms 11 ms 151.164.188.139 Trace complete.

12 12