July 2003 - Test - lists.nanog.org

Update to completewhois.com whois tool & website. Hijacked IP blocks List
by william＠elan.net 21 Jul '03

21 Jul '03

I have recently made available new version of completewhois tool and website. There are many new features in the whois engine (see below about that). As far as website of expected interest to NANOG community is the results of investigations into number of hijacked ip blocks (done by me and others in cooperation on hijacked mailing list) - the list of hijacked ip blocks and investigation files (to find and notify proper ip block owner) are available at http://www.completewhois.com/hijacked/ And as far as new features in whois engine, these are: 1. A fully developed website with (hopefully user-friendly) GUI interface http://www.completewhois.com/ 2. An even more complex whois engine with large set of options that can be used by those doing direct queries from unix server (for list of options see http://www.completewhois.com/help.htm) 3. Ability do combined searches, for example do both whois on domain and also have engine do whois on all ips of nameservers for the domain or whois on ip and reverse dns domain for the as well as combine results with dns (3 types of dns queries), radb, etc. 4. Ability to SAVE results for later retrieval (that means query results are saved in our the database and you can quickly access it or have the url reference from the website). This is usefull to preserve whois record in case it may change in the future. 5. CGI now allow direct reference as URL (supports GET paramters), i.e. http://www.completewhois.com/cgi-bin/whois.cgi?query=nanog.org&options=dns 6. Larger set of supported top level domains - around 150 (but this is work currently in progress as all domain settings are being reviewed). 7. Whois on .COM/.NET/.ORG domains have ip of nameserver resolved as part of whois query - both whois in crsnic and dns lookups are used (option can control which is used and how). In the future, this will be supported for number of other domains as well. 8. As always engine maintains best ip whois functionality and follows a lot of refererals to other more specific whois databases run by isps and country nics (announced last week by ARIN "ReferralServer" field is by now supported too). 9. Support for IPv6 should now be working (requires explicit option enable_ip6=on and its still early beta and bit buggy) both for ip whois and for dns, including domain nameservers. Direct IPv6 whois access is in development and will probably be available in September. So now feel free to check this all out and beta test it and send your comments offline to comments(a)completewhois.com. As always this is free tool with no commercial interruptions of any kind :) -- William Leibzon Elan Networks william(a)elan.net

3 2

Warning Someone is using your company name to defraud users: Fw: Transaction #: 34-355-268-52430
by John Palmer (NANOG Acct) 20 Jul '03

20 Jul '03

Got this in my mailbox this afternoon - The URL goes to swiftSpay.com, not swiftpay.com. You're probably aware of this scam - if not, now you know. John P. ----- Original Message ----- From: transfers(a)swiftspay.com To: info(a)adns.net Sent: Sunday, July 20, 2003 2:49 PM Subject: Transaction #: 34-355-268-52430 This is confirmation message for transfer of $1974.50 USD by E-mail from: ********************************************************************* SwiftPay User ID: goldxchangers(a)consultant.com Transaction #: 34-355-268-52430 Ref. #: 04100927 ********************************************************************* To claim your money and confirm the transaction please, follow the link below: http://www.swiftpay.com/transID?=34-355-268-52430±04100927f=US The money will appear in your SwiftPay account balance once you confirm the transaction and then you can withraw the balance to your bank account which you added during the registration process. If you are not an existing member of SwiftPay.com you can signup right now. The registration process is very simple and it takes less than 5 minutes. Swiftpay`s intuitive interface makes sending and receiving money over the web as easy as one two three. Simply logon at Swiftpay.com and select which Swiftpay service you wish to avail of, whether it's to fund your account, send money to friends family or businesses, request money or check your account details. With everything you need available at the click of a mouse, paying with Swiftpay couldn't be easier. Don't forget, we value our commitment to Customer Service at Swiftpay - should you have any queries, please don't hesitate to contact us and we'll do our best to answer your query as soon as possible. Kind Regards, Swiftpay Billing Dept. SwiftPay -The E-Cash solution that brings online shopping closer to home ********************************************************************* SWIFTPAY.COM SECURITY REMINDERS Protect Your Username and Password and NEVER Reveal it to Third Parties! ********************************************************************* WARNING! If you are not the intended recipient, please inform the sender immediately by E-mail and delete this message and all copies from your system.

1 0

draft-savola-bcp38-multihoming-update-nn.txt
by Fred Baker 20 Jul '03

20 Jul '03

Pekka and I have been discussing the impact of ingress filters on multihomed networks - which may be ISPs or edge networks, and may have an arbitrary number of upstream ISPs. We wonder what your thoughts might be regarding http://www.ietf.org/internet-drafts/draft-savola-bcp38-multihoming-update-0…. With your concurrence, we would like to recommend it for BCP status, as an update to BCP 38. Our questions are at two levels: philosophical and at the detail level. If you have significant comments calling for a change of text, it would help us if you proposed text.

2 1

Patching for Cisco vulnerability
by Irwin Lazar 20 Jul '03

20 Jul '03

Just out of curiosity, are folks just applying the Cisco patch or do you go through some sort of testing/validation process to ensure that the patch doesn't cause any other problems? Given typical change management procedures how long is taking you to get clearance to apply the patch? I'm trying here to gauge the length of time before this vulnerability is closed out. irwin

15 22

RE: Working vulnerability? (Cisco exploit)
by Ben Buxton 19 Jul '03

19 Jul '03

It's released and it works - I have verified it in a lab here. BB > -----Original Message----- > From: Ken Yeo [mailto:kenyeo@on-linecorp.com] > Sent: Friday, July 18, 2003 3:24 PM > To: nanog(a)merit.edu > Subject: Working vulnerability? (Cisco exploit) > > > > Is this true: > > http://www.eweek.com/article2/0,3959,1196496,00.asp > > **there is a working exploit for this vulnerability but that > it has not been > released yet.** > > >

6 6

qmail smtp-auth bug allows open relay
by John Brown 19 Jul '03

19 Jul '03

seems that there are installs of the smtp-auth patch to qmail that accept anything as a user name and password and thus allow you to connect. http://marc.theaimsgroup.com/?l=qmail&m=105452174430616&w=2 is one URL that talks about this. There has been an increase is what appears to be qmail based open-relays over the last 5 days. Each of these servers pass the normal suite of open-relay tests. Spammers are scanning for SMTP-AUTH and STARTTLS based mail servers that may be misconfigured. Then using them to send out their trash. Some early docs on setting up qmail based smtp-auth systems had the config infor incorrect. This leads to /usr/bin/true being used as the password checker. :( >From an operational perspective, I suspect we will see more SMTP scans The basic test (see URL above) should get incorporated into various open-relay testing scripts. cheers john brown chagres technologies, inc

6 7

RE: Working vulnerability? (Cisco exploit)
by Ben Buxton 19 Jul '03

19 Jul '03

Yep its all a bit weird, I guess people are not too knowledgeable about it. For starters the original explit wont work very well out of the box for most script kiddies (random source addresses -> killed by anti-spoofing), and a single packet to a vulnerable box isnt enough (need to fill the queue slots). More of an annoyance really - most of the outages as a result are going to be from people upgrading boxes, not victims of attack. BB > -----Original Message----- > From: jlewis(a)lewis.org [mailto:jlewis@lewis.org] > > On Fri, 18 Jul 2003, Ben Buxton wrote: > > > It's released and it works - I have verified it in a lab here. > > And others are trying it in the field now. I setup the recommended > transit ACLs yesterday. Starting at 9:25am EDT this morning, > those ACLs > started getting hits. What doesn't make sense to me is > according to the > advisory, the packets have to be destined for the router to > crash it (not > just passed through it), but people are attacking seemingly > random IPs, > including ones in a new ARIN block that have not yet been > assigned/used > for anything. What do they think they're attacking? > > ---------------------------------------------------------------------- > Jon Lewis *jlewis(a)lewis.org*| I route > System Administrator | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > >

4 3

Cisco Vulnerability Testing Results
by Jason Frisvold 19 Jul '03

19 Jul '03

Hi all, First post.. I hope this is ok ... We tested the Cisco vulnerability and I wanted to share our results with you ... The attack code we used is the same code that was posted to the Full Disclosure list. Compiled on a Redhat Linux 6.2 machine. Testing scenario is this : Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 First attack was to the 2514, ran the program as thus : ./sc 192.168.0.1 1 This produced unexpected results. Cisco indicated that the vulnerability was on the interface specified in the packets. However, after running this, it was actually the INPUT interface that the input queue increased on. In our test, this was Ethernet0, not Ethernet1 as expected. Next attach was to the 2501 : ./sc 192.168.0.2 2 This produced expected results. Input queue did increase on the 2501. Next we tried a pass-through attack : ./sc 192.168.0.2 0 ./sc 192.168.0.2 1 No interfaces on either Cisco were affected. It seems that pass-through attacks are not possible. The attack *must* terminate on an IP on one of the router interfaces. An additional test to both routers using a high TTL value was also run. No interfaces were affected. This is in-line with Cisco's posting. Code was then upgraded on the 2514 to 12.0.27 (non-vulnerable) .. Tests were run again. This time, the 2514 was not affected by any tests. The 2501 was still vulnerable. I will be testing ACL's in a moment, but I wanted to get these results out and see if they were on-par with any testing anyone else has done. -- --------------------------- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz(a)corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]

5 7

Re: Working vulnerability? (Cisco exploit)
by Paul Vixie 19 Jul '03

19 Jul '03

> >I'd estimate than less than a tenth of a percent (that's 0.1%) of > >edge paths use RPF, even though BCP38 states the case clearly and the > >technology makes it easy > "Makes it easy" if you live in an Internet with a number of routes > significantly less than the limit imposed for having stable RPF > enabled on your devices, or have devices without bugs in RPF checking > when said limit is spotted vaguely across the horizon. since those are two very common beliefs about BCP38 deployment, i'm going to leave it to barry to repost his standard answers to them, once he's gotten some sleep. > I dont seem to be in either of those places. (Although I have not > sacrificed a router in the last upgrade version or two to see if things > have improved.) please do, and please post your results, as an example to others.

1 0

Cisco vulnerability on smaller catalyst switches
by Chris Griffin 19 Jul '03

19 Jul '03

As part of our vulnerability tests, we have been unable to confirm that the smaller catalyst switches running IOS but without L3 capability are vulnerable. They don't seem to react in a negative way to the same attacks that lock up the other devices we have tested. Has anyone else been able to verify this one way or the other? -- Chris Griffin cgriffin(a)ufl.edu Network Engineer - CCNP Phone: (352) 392-2061 OIT - Network Services Fax: (352) 392-9440 University of Florida Gainesville, FL 32611

2 1