Sobigf + BGP
I was reading some PDF files on BGP along with Routing TCP/IP v2, and I found myself pondering what a nasty damn worm it would be if someone were to do something using winpcap in conjucting with the worm/virus, and I was a bit confused, disturbed, lost. So I drew up a quick question complete with ascii which can be viewed at politrix.org/segment/brat.txt for those who get a distorted diagram... Apologies beforehand if this post seems a bit odd, but I did not see anything similar to a networking 'vuln'dev', and besides I wouldn't think that any one here would do something malicious with any idea that actually worked for the worse. - brat.txt I was thinking about the recent polymorphic Sobigf worm/virus and wondered about the following hypothetical scenario... Sorry about this ASCIIgram, I didn't want to look for Visio nor any other graphic program to do this in, strictly terms to keep it gritty... So here goes. Attacker scripts Sobigf variant with a virii/worm generator, and uses pcap (packet capture) under Windows to have his worm send out predefined packets. Let's say he created what I call a 'BRAT' BGP Router Attack Tool. Now this tool isn't something major it simply sends out two types of packets aimed at routers running BGP. They're both Notification Messages: = Packet 1 = BGP NM ERROR CODE 2 SUBCODE 2 | Packer 2 = BGP NM ERROR CODE 6 | = Now we have the hosts' information: www.targetednap.net (4 if's) 192.168.1.1 192.168.4.1 10.10.1.1 10.10.5.1 VIC's nap.maefi.com Link 1 nsp.maefee.com Link 2 nap.maefo.com Link 3 nsp.maefum.com Link 4 Link 1 Link 2 \ / - | | | Targetednap.net | | | - / \ Link 3Link 4 Script kiddiot sets up his worm/virii to send packets as Targetednap to all VIC's as Targetednap via spoofing using WinPCAP. Given the rate of connections that were mentioned for SoBigf, what could happen say if route dampening were used between the routers. Would penalties keep adding up making the connection intolerable because of latency, would it ignore it. Or what could happen say if worm was smart enough to send NLRI's of something like $targetvalue=0 Wouldn't this knock off connections between BR's/ABR's, etc. Are there any flags one can take to prevent this from occurring. Keep in mind that packet creation is not difficult. My guess would be, even if someone didn't get all fancy with the packets being sent, a couple of million packets sent with say a: ping -l 25000 $VIC as $TARGETEDNAP would be enough to cause some massive latency, maybe even disconnect a backbone perhaps? Anyone care to share links on security on this level if any are available = J. Oquendo rsvp: segment ... antioffline . com PGP Fingerprint 39A7 24C6 A9A0 6C67 96CA 0302 F1D3 2420 851E E3D0 http://www.politrix.org http://www.antioffline.com = -- __ Sign-up for your own personalized E-mail at Mail.com http://www.mail.com/?sr=signup CareerBuilder.com has over 400,000 jobs. Be smarter about your job search http://corp.mail.com/careers
Re: W32/Sobig-F - Halflife correlation ???
Hi I popped onto #nanog on efnet last night reporting UDP 'Gaming' Traffic hitting our services from those 20 boxes and got laughed at for suggesting game traffic, i'm glad someone else noticed it too! We run lots of Game Servers in the UK and most of the CS ones were getting traffic from those 20 boxes (blocked with an ACL) - i'll have to check through my netflow logs for more details. Also, Stephen J. Wilcox saw traffic destined for his CS Servers. They were trying to hit servers in multiple subnets, all on ports 270XX. Best Regards Darren Smith Game Digital Ltd - Original Message - From: Robert Blayzor [EMAIL PROTECTED] To: Matthew E. Martini [EMAIL PROTECTED]; North American Network Operators Group [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 3:05 AM Subject: Re: W32/Sobig-F - Halflife correlation ??? On 8/22/03 8:50 PM, Matt Martini [EMAIL PROTECTED] wrote: I've scanned my Netflow logs for activity associated with the 20 machines that SoBig was targeting and I found some very curious activity. If what you claim is correct, this could be very bad. The virus is already there on many infected machines, it just needs a way to communicate with other infected hosts to coordinate it's bidding. IRC has been a weak link for viruses as they can usually be tracked and stopped in a short order, however with gaming machines, it may be a little bit harder. Maybe there are no master servers. Maybe it doesn't need one. Perhaps it just uses a network like Game Spy to find public Halflife (or other gaming servers) to get the viruses to link together. Infected boxes would the communicate on random Halflife servers all over the net. (there are thousands of them). Maybe the clients don't find the masters, maybe the masters find the clients. Maybe the list of 20 servers was just a decoy of sorts. It would be nearly impossible to track the source of who is controlling the infected boxes. Clever... -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 If I had it all to do over again, I'd spell creat with an e. - Kernighan
Re: W32/Sobig-F - Halflife correlation ???
On 8/23/03 7:17 AM, Darren Smith [EMAIL PROTECTED] wrote: They were trying to hit servers in multiple subnets, all on ports 270XX. I'm not sure on this. Lots of gaming servers use the 270XX UDP range. Quake3, HL, etc. It may be possible it's just probing for other HL servers running on different ports. A lot of these games also use the same gaming engine for the network and graphics abilities, so it's possible HL may not be the only game server in the mix, it may be any game that uses the HL engine. I know there are several out there, Counterstrike being one of them. So if it's not looking for a HL only exploit, I'd bet it's trying to get the infected machines to link up and communicate via the network of gaming servers. This could be very bad because there could be virtually no way to stop this other than taking down the Game Spy type networks so the computers can't find each other. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Oh my God, Space Aliens!! Don't eat me, I have a wife and kids! Eat them! -- Homer J. Simpson
Re: Sobigf + BGP
J. Oquendo [EMAIL PROTECTED] writes: Apologies beforehand if this post seems a bit odd, but I did not see anything similar to a networking 'vuln'dev', and besides I wouldn't think that any one here would do something malicious with any idea that actually worked for the worse. This is very naive. ---rob (feeling like rbush this morning)
Re: W32/Sobig-F - Halflife correlation ???
Hi Just a quick look at my syslog file, where MOO is the name of my ACL. fgrep MOO /var/log/cisco/router.log | grep 27015 -c 2383 fgrep MOO /var/log/cisco/router.log | grep 27016 -c 459 fgrep MOO /var/log/cisco/router.log | grep 27017 -c 210 fgrep MOO /var/log/cisco/router.log | grep 27018 -c 59 As you can see most of them were on 27015, these logs were from just one of my transit interfaces. Best Regards Darren Smith - Original Message - From: Robert Blayzor [EMAIL PROTECTED] To: North American Network Operators Group [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 1:05 PM Subject: Re: W32/Sobig-F - Halflife correlation ??? On 8/23/03 7:17 AM, Darren Smith [EMAIL PROTECTED] wrote: They were trying to hit servers in multiple subnets, all on ports 270XX. I'm not sure on this. Lots of gaming servers use the 270XX UDP range. Quake3, HL, etc. It may be possible it's just probing for other HL servers running on different ports. A lot of these games also use the same gaming engine for the network and graphics abilities, so it's possible HL may not be the only game server in the mix, it may be any game that uses the HL engine. I know there are several out there, Counterstrike being one of them. So if it's not looking for a HL only exploit, I'd bet it's trying to get the infected machines to link up and communicate via the network of gaming servers. This could be very bad because there could be virtually no way to stop this other than taking down the Game Spy type networks so the computers can't find each other. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Oh my God, Space Aliens!! Don't eat me, I have a wife and kids! Eat them! -- Homer J. Simpson
FW: TNT issues workaround
I seem to be having the same or similar problems with my Cisco boxes also , they either reboot or the pris hang , users get busy's but no one is logged in at all , when I do a show isdn status it shows b channels in use but no one on, the only way to fix is reboot the box , and it seems to be timed , everyday at 1400 and 2200 hours , since Monday anybody body heard of ciscos acting funny this week? John Lord([EMAIL PROTECTED]) It Manager AllTurbo Internet Services Inc 410-213-9388 Office www.allturbo.com -Original Message- From: Brian Wallingford [mailto:[EMAIL PROTECTED] Sent: Saturday, August 23, 2003 1:41 AM To: [EMAIL PROTECTED] Subject: TNT issues workaround I haven't seen specific details posted here, so: Like many others, we've had a few TNTs online for years without hiccups or reboots until this week. Beginning late Sunday, we saw seemingly random blade reboots, and total system crashes. Errors ranged from memory leaks to infinite loops on the controller blade, but all blades were susceptible. HDLC2 blades seemed to be particularly vulnerable. We saw boxes that had been rock-solid for very long periods suddenly rebooting at periods ranging from 20 minutes to 4 hours, with no obvious cause (i.e., nothing more specific than the above). Border and core filtering of icmp echo * did little good. On the suggestion of some folks on another list, and against my better judgment, we disabled route caching in order to free up additional memory (though memory did not appear fragmented). This stabilized all involved boxes, and surprisingly, did not result in significant degradation of end user performance. Granted, it's not a true fix, but it may get you a few extra Z's at night. hth, brian
RTT/delay presentation from Defcon
All, I put a small talk on at this years Defcon, discussing some of the rtt work I've been doing. For those interested in the topic, I've placed an mp3 of the presentation and my slides here: http://144.92.40.150/~xam/misc/dc-11/dc11-talk.htm http://144.92.40.150/~xam/misc/dc-11/020.MP3 Enjoy, --Tk
Re: FW: TNT issues workaround
On Saturday, Aug 23, 2003, at 18:31 Europe/Dublin, John Lord wrote: I seem to be having the same or similar problems with my Cisco boxes also , they either reboot or the pris hang , users get busy's but no one is logged in at all , when I do a show isdn status it shows b channels in use but no one on, the only way to fix is reboot the box , and it seems to be timed , everyday at 1400 and 2200 hours , since Monday anybody body heard of ciscos acting funny this week? Perhaps your fast switching route cache is filling up memory. If you're willing to risk it enable CEF on all interfaces. R.
Moving quickly in network design
http://www.washingtonpost.com/wp-dyn/articles/A34422-2003Aug22_2.html Jonathan Zittrain, a Harvard Law assistant professor. Now one person really can change the world. But that's also what's terrifying. When hackers three decades ago found they could get free calls on pay phones using a toy whistle that mimicked the phone's network signals, they exploited the system's vulnerabilities in much the same manner as today's viruses, Zittrain said. Phone firms, though, were able to quickly change their network design. But the Internet is fundamentally a different type of technology. Actually it took the telephone system over 30 years to convert from multi-frequency (per-trunk) singaling to common channel interoffice signaling. The signaling standard has gone through a few versions and is now known as SS7. SS7 security isn't all its cracked up to be. The Bell System lucked out because they had started development in the 1960's of new signaling methods not because of security, but because of money. Busy signals were tying up half the long distance lines in the US, and in the old days Ma Bell didn't get paid for busy signals. The business case for developing CCIS was primarly driven by more efficient (ie. more paid calls) use of the network, not security. By the time Capt'n Crunch found his 2600Hz whistle in the early 1970's, Ma Bell could move quickly (i.e. it still took several more years) because it had spent a decade already working on CCIS.
Re: FW: TNT issues workaround
On Sat, 23 Aug 2003, Ross Chandler wrote: I seem to be having the same or similar problems with my Cisco boxes also , they either reboot or the pris hang , users get busy's but no one is logged in at all , when I do a show isdn status it shows b channels in use but no one on, the only way to fix is reboot the box , and it seems to be timed , everyday at 1400 and 2200 hours , since Monday anybody body heard of ciscos acting funny this week? Perhaps your fast switching route cache is filling up memory. If you're willing to risk it enable CEF on all interfaces. Some of the older cisco access-servers don't even support CEF. The cisco failures seem to be memory starvation/fragmentation issues caused by out of control route-cache growth caused by the nachi worm's attempt to ping so many different hosts so quickly while looking for systems to spread to. You can work around the issue by: a) using policy routing to pass all dialup traffic through a route-map that sends 92 byte echo/echo-reply packets to null0. b) blocking all echo/echo-reply coming in from dial-up users (i.e. apply an input acl to your virtual-template and/or group-async interfaces). c) disabling route caching on the egress interface of the access server. I'm doing a mix of a (on the access-servers that this works on) and b where a doesn't work...and tested c this morning and found it appears to work. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
