January 2003 - Test - lists.nanog.org

Re: Banc of America Article
by Steven M. Bellovin 26 Jan '03

26 Jan '03

In message <Pine.LNX.4.44.0301260529320.29298-100000(a)www.everquick.net>, "E.B. Dreger" writes: > >AR> Date: Sun, 26 Jan 2003 00:22:02 -0500 (Eastern Standard Time) >AR> From: Alex Rubenstein > > >AR> Agreed. And, even if it is super encrypted, who cares? Enough >AR> CPU and time will take care of that. > >Articles about "1000 years to crack using brute force" are a bit >disconcerting if someone has access to 10,000x compromised hosts. >While we're on the subject: root certificates, anybody? > >Each worm seems to prove the availability of CPU and time. This is practical against, say, DES, with its 56-bit keys. In fact, it's been done; see http://www.virusbtn.com/resources/viruses/indepth/opaserv.xml for an example. But the fact that DES is insecure has been known for years; it doesn't take a worm to underscore that point. Let's look at AES or 3DES instead. Suppose there are 1,000,000,000 infected hosts. Let's further assume that each one can check a single key in .1 nanoseconds. (That's a gross exageration, I might add, for a general-purpose machine -- and we're not talking about 1,000,000,000 NSA code-crackers being infected.) AES uses 128-bit keys; there are therefore 340282366920938463463374607431768211456 possibilities. Call it 3*10^38. Divide that by 10^9 hosts, and 10^10 tries per second per host. That gives us 3*10^19 tries per second. There are ~10^5 seconds/day, and 3*10^2 seconds/year, meaning that it would take 10^12 years for this scenario. 3DES? Well, 3DES may be using 112-bit keys, so we can cut the time by 2^16. Call that 10^5 -- so we'll only have to wait 10^7 years for a single result.... Yes, with enough CPU and enough time, it's possible to crack modern ciphers by brute force. But "enough" is quite a large number. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

2 1

RE: Worm / UDP1434
by Freedman David 26 Jan '03

26 Jan '03

This is exactly what we had to do, we couldn't even get to the boxes, I had a NOC engineer go and console them out of band and run a "sh port util" to find out whom the offenders were, before disabling their ports. Extreme were unhelpful, suggesting that we apply the ACL (advisory released ~6 hours after we had done it!) which really made no difference. As for multicast, I'd made sure that all VLANs had IGMP,IGMP SNOOPING and IPMC FORAWRDING disabled, but it made no real difference.... Dave. -----Original Message----- From: sjk To: andy(a)tigerteam.net Cc: neil(a)DOMINO.ORG; David.Freedman(a)netscalibur.co.uk; nanog(a)nanog.org Sent: 1/26/03 5:18 AM Subject: Re: Worm / UDP1434 This is true -- the acls don't reduce the tBGTask or the tNetTask -- nor does disabling ip forwarding on the vlan. We have around ten of these, and they were hit particularly hard today. You actually have to shut down the offening hosts to set the switches right. --sjk On 25 Jan, Andy Walden wrote: > > > On Sat, 25 Jan 2003, Neil J. McRae wrote: > >> >> > >> > Anybody here on list using Extreme products >> > (Summit/Alpine/Blackdiamond)? They sure don't like this traffic one >> > bit. It causes them to not only drop traffic, but spew out every >> > available error message under the sun... >> > >> > Extreme are apparently assembling an "advisory TAC" on this, from >> > our point of view, since we use the devices to do l3 aggregation >> > (for colo and such) we've used an ACL to try and combat the >> > offending traffic, but its not doing much good..... >> >> Do you have MCAST enabled on these switches? I'd guess this >> is what is causing issues on the extreme boxes. > > > I think the architecture is flow-based, ie, the first packet of each > flow hits the CPU. This is probably causing the high CPU utilization. > The flow would still hit the CPU even with a ACL and then probably be > written to the ASIC with a null location. > > andy > -- > PGP Key Available at http://www.tigerteam.net/andy/pgp ________________________________ Do not taunt Happy Fun Ball. sjk(a)sleepycatz.com -- Email Disclaimer can be viewed at: http://www.netscalibur.co.uk/email.html --

1 0

DOS?
by Christopher J. Wolff 26 Jan '03

26 Jan '03

Greetings, It looks like all hell is breaking loose on some of the nations backbones. http://www.internethealthreport.com The port counters on my AT&T DS3 were reading in the 250 megabit range, that is a DS3, mind you. Any source IP's I can add to the circular file would be appreciated. Any ranges I find I'll echo back to the list. Regards, Christopher J. Wolff, VP CIO Broadband Laboratories, Inc. http://www.bblabs.com

11 16

double postings
by Jeffrey Meltzer 26 Jan '03

26 Jan '03

anyone else getting postings (at least) twice? someone else told me they were seeing the same thing. Anyone from Merit at the wheel? Jeff -- Jeffrey Meltzer ICS/VillageWorld 631-218-0700 x100

3 2

13,000 Bank of America ATM's taken out by virus.
by Christopher J. Wolff 26 Jan '03

26 Jan '03

Does this mean that BofA ATM's are SQL based or that BofA is running ATM traffic through some kind of internet VPN? Perhaps they just plug the ATM's into any connection and pass cleartext transactions over the internet? This is very suspicious, IMHO. http://www.washingtonpost.com/wp-dyn/articles/A43267-2003Jan25.html Regards, Christopher J. Wolff, VP CIO Broadband Laboratories, Inc. http://www.bblabs.com

5 4

Re: Level3 routing issues?
by matthew＠eeph.com 26 Jan '03

26 Jan '03

> I've seen various references to this worm firing off and saturating > networks worldwide within 1 minute... if *that* isn't scary, I don't know > what is. It shows that someone, with the right tools and enough vulnerable > servers can take out a good portion of the Internet in seconds. And how > can we predict *every* possible issue and block it? The good news with this worm was that the ports it used had low real utility for inter-provider traffic. Compare and contrast to Code Red, where "block TCP port 80" isn't such a great way to slow down the worm if you have any customers who like to use "the web" A combination of the speed at which this spread and a port nobody wants to block will undoubtedly happen in the future, and be ugly, both. Matthew Kaufman matthew(a)eeph.com (home) mkaufman(a)dsl.net (work)

1 0

Does the Worm have another Payload besides 1434 Floods?
by Stewart, William C (Bill), SALES 26 Jan '03

26 Jan '03

So the worm is sending out tons of UDP1434 packets that let it break into MS-SQL servers and reproduce, and that's certainly annoying because of the traffic floods. But is it carrying anything else that will do more damage, or anything that leaves it a security hole to be exploited later? It would be really annoying if machines that aren't cleaned up later reformat themselves or hang out waiting for further instructions. Also, several people have commented that restarting their MS-SQL servers stops the problem. Does it just stop the flooding, but leave code there, or does the worm strictly live in transitory data space that's really gone after a restart. Several people have talked about bursts of ICMP or 6667 traffic, and those are probably unrelated, but maybe not. (What? More than one cracker on the net or more than one program that chokes when overloaded? Who'd'a' thunk it!)

3 2

Re: Tracing where it started
by Daniel Senie 26 Jan '03

26 Jan '03

At 05:52 PM 1/25/2003, you wrote: >Our first (this is EST): > >Jan 25 00:29:44 external.firewall1.oct.nac.net firewalld[109]: deny in >eth0 404 udp 20 114 61.103.121.140 66.246.x.x 3546 14 >34 (default) > >61.103.121.140 = a host somewhere on GBLX Our first ones came from: 1. L(3) space, swip'd out to an outfit in Florida 2. Sprint space, swip'd out to an outfit in Indiana 3. repeat of #1 4. Korea 5. Korea All times are EST and UTC, and locked to a stratum 1 time source. Any researcher who needs the full logs need only ask. Our firewalling didn't permit any of this in. Jan 25 00:29:42 gatei46 214: Jan 25 05:29:41 UTC: %SEC-6-IPACCESSLOGP: list 101 denied udp 63.209.100.22(1253) -> 208.254.46.93(1434), 1 packet Jan 25 00:29:49 gatei46 215: Jan 25 05:29:48 UTC: %SEC-6-IPACCESSLOGP: list 101 denied udp 208.14.240.150(4315) -> 208.254.46.3(1434), 1 packet Jan 25 00:29:52 gatei46 216: Jan 25 05:29:51 UTC: %SEC-6-IPACCESSLOGP: list 101 denied udp 63.209.100.22(1253) -> 208.254.46.150(1434), 1 packet Jan 25 00:30:01 gatei46 217: Jan 25 05:30:00 UTC: %SEC-6-IPACCESSLOGP: list 101 denied udp 218.234.13.22(4762) -> 208.254.46.62(1434), 1 packet Jan 25 00:30:03 gatei46 218: Jan 25 05:30:02 UTC: %SEC-6-IPACCESSLOGP: list 101 denied udp 211.172.232.82(3830) -> 208.254.47.188(1434), 1 packet

1 0

Re: New worm / port 1434?
by lost＠l-w.net 26 Jan '03

26 Jan '03

This one seemed to be particularly nasty as it was generating traffic to multicast addresses too. It caused a nice flood on the switched ethernet segment I had a vulnerable box on. (And took out a router in the process. Great fun.) William Astle finger lost(a)l-w.net for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?

5 7

RE: Does the Worm have another Payload besides 1434 Floods?
by Danny 26 Jan '03

26 Jan '03

|>All disassembly analasis made shows that it is a simplistic worm designed |>to |>break in, execute, and start sending itself out. No system damage or host |>embedding has been detected. The writer of the worm had no intentions of |>causing permanent damage. |> For now, seeing how effective this worm was how long do you think its going to take before there are many, many variations on this worm that *DO* have malicious code and backdoor the machine in a way that will survive a reboot. |>> |>It's really gone after a restart. |> For now :) Cheers Danny Network Security Engineer Drexel University Digital ID Print: 874f 1b77 470f 0b10 126e d8d2 c3a3 d52a 24ab 73c3 PGP Print: C6AD B205 E3C6 38AB 0164 6604 66F5 CCFC F4ED F1E0 PGP Key: http://akasha.irt.drexel.edu/danny.asc

1 0