Slashdot Mirror
Code Redux
I don't understand why Symantec classifies a "remote root" exploit as only "medium" damage. Code Red [?] is hitting cable modem networks especially hard, as the new variants scan "nearby" IP's in preference to random ones, which has apparently caused enough damage and network congestion that AT&T's residential broadband division (MediaOne) has cut off port 80 across their network to try and halt the spread of the worm, or so several submitters reported. Newsforge has a story about various reactions to the worm, and reader nettdata sent in an interesting story about the worm becoming the main course at a dinner of security specialists.
Code Red will only slurp down 12868 bytes.
Don't do it - the 'net has enough stress on it with 5.9 million IIS running hosts trying to infect everything in site without you transmitting a bunch of zeroes.
Yes, so I had similiar thoughts, but Daniel Lawson taught me better. (Thanks Daniel BTW.)
It's all the arp requests from all the Code Red
probes for non-existant IP addresses.
tcpdump -i eth0 -n
(or whatever your external ethernet interface is).
I was seeing 2000/minute ARP requests on Monday,
don't know what it is now...
I tried it out. This is what appeared in the log.
/scripts/root.exe?/c+dir+c:\ HTTP/1.0" 404 286 "-" "-"
/NULL.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX=X HTTP/1.1" 404 284 "-" "-"
- 216.201.108.18 - - [08/Aug/2001:19:29:45 +1200] "GET
- 216.201.108.18 - - [08/Aug/2001:19:29:46 +1200] "GET / HTTP/1.0" 200 1948 "-"
"-"
210.zz.zz.zz 216.201.108.18 - - [08/Aug/2001:19:29:46 +1200] "GET
- 216.201.108.18 - - [08/Aug/2001:19:29:48 +1200] "GET / HTTP/1.0" 200 1948 "-"
"-"
(I've snipped by IP BTW.)
It looks like it is testing for:
* Code Red 3 backdoor (found on all good Windows 2000 systems)
* A web server
* The ida overflow
* A web server (again)
..has DEFINITELY shut off inbound port 80 traffic to some (if not all) of their cable modem infrastructure. I am in Massachusetts, and I'm cut off. The roadrunner.* newsgroups are boiling over this, and there's been NO official release from AT&T, although their customer support reps readily admit that 80 is off and will remain off, presumably indefinitely. I am bullshit about this, but have nowhere to go. DSL is collapsing while AT&T is getting bigger. Behold the fruit of two monopolies: AT&T and Microsoft.
You can block incoming and outgoing http connections separately. eg. if a SYN packet is going from an outside address to an inside address, and the port number is 80, block it. But don't block anything else.
I recieved an email today from road runner (aka time warner cable) regarding the "VIRUS ALERT. YOUR IMMEDIATE ACTION IS REQUIRED". For the intrigued, here's the letter:
------
VIRUS ALERT. YOUR IMMEDIATE ACTION IS REQUIRED.
Dear Road Runner Subscriber:
Road Runner, like many other ISPs and indeed the entire Internet, has today experienced an attack on its network which is apparently attributeable to the Code Red virus. It is possible that this virus has infected the PC's of Road Runner's subscribers using the Microsoft Windows NT or Microsoft Windows 2000 operating systems. Infected PC's may continue to flood the Internet and Road Runner's network with virus generated messages (even without your being aware of it).
Road Runner is working to alert all of its subscribers to this problem and to instruct them on where to find and install the patch necessary to eliminate the virus. In the meantime, Road Runner subscribers may experience slow network response, flashing connectivity lights on the cable modem, and other symptoms (such as unusual port scan log activity or increased firewall activity) while Road Runner and the Internet community work to control the impact of this virus.
IF YOUR PC IS RUNNING WINDOWS 2000 OR WINDOWS NT, PLEASE IMMEDIATELY DOWNLOAD THE CODE RED PATCH FROM MICROSOFT'S WEBSITE (www.microsoft.com/security) AND RESTART YOUR PC.
IF YOUR PC IS RUNNING WINDOWS 98, WINDOWS 95, OR WINDOWS ME, OR IF YOUR ARE A MACINTOSH USER, NO ACTION IS REQUIRED ON YOUR PART.
We ask for your patience while Road Runner continues to work with the Internet community to address this virus. Thank you. Road Runner Security
P.S. Please, do not reply to this message
--------
Well, gee, if the whole "internet community" is at work at resolving the issue, I can rest easy. But then again, they only say no to worry if you're running Windows 95, 98, ME or MacOS. Well, I'm running Linux and NetBSD, so I guess I should be worried, eh?
--
#nohup cat
To specify more specifically for the people misunderstanding this poorly worded post, port 80 is not completely block. Only the _INCOMING_ connections to port 80 are block, so only people running webservers are infected. Because I currently run a webserver using Apache under Linux on my MediaOne cable modem, I am currently on hold on the MediaOne tech-support line attempting to get port 80 unblocked.
@Home's AUP specifically says "no servers". Also, they've always blocked port 137, so the tools are already installed. Yet they still haven't blocked port 80, even though each IP is getting hit approximately every other minute.
or the worm has a sleeping behaviour pattern. Please review the following message from the Securityfocus Incidents Archive (the message was sent 30 minutes ago)
Our webservers have also been getting requests for default.ida stuff. I have written a couple of short scripts to block them on the firewall. The scripts are avaialable at http://www.ispman.org/blockcodered
Depends. If you are on a modem, you will see an occasional SYN packet with a destination port 80. If you are on a cable modem or shared segment that is accessible to the Internet, you will see a lot of ARP requests for nonexistant machines along with the SYN packets. If it hits a machine with a web server on it, you will see the mailicious URL (its payload) sent to the host.
Yes - check the athome.* newsgroups for more details...
Basically the new, "improved", Code Red is scanning close-by IP addresses, thus trying to find machines that may not even exist, or which are turned off at the moment. In this case, the @home gateway sends an ARP broadcast packet trying to find the IP address in question. This broadcast traffic causes the "activity" light to blink constantly... In my area, there is no performance degradation, though (yet).
Lol.
/scripts/shell.exe works too.
It isnt difficult to self test. Get your IP with winipcfg then type this in a browser:
http:///scripts/root.exe?/c+dir
if you download a directory listing, you're infected. Ohohoho. Practically all win2k users i know are infected. how amusing.
You may also find
Weevil.
ghaa.
However, I've heard about a new Code Red variant that spoofs ARP packets, overflowing the ARP table in Win98/ME and causing machines to freeze. AFAIK, it doesn't affect other operating systems. It doesn't seem very common either.
BTW, ARP packets are not IP packets, so you can't stop them with iptables/ipchains or any IP firewall, and they won't appear in your logs. Use a sniffer like Ethereal if you want to see what's going on.
6 of our machines at work got infected over the weekend. I was under the impression that our web guy had been keeping them up-to-date, but 5 were inside our NAT (infected by the 1 that was outside). I was under the impression that the ones inside the NAT would be ok. Bad assumption.
The bandwidth it used was so bad that it completely wiped out our ability to get out via HTTP. We could ping, get and send mail, but we couldn't browse at all. I had innoculated my home machine, and it wasn't until this morning, when we received a notice from our ISP accusing of massive port scanning of port 80 that I made the connection. I went around the office and, even after 5 of the 6 machines were innoculated, we still couldn't get out via HTTP. It wasn't until the 6th was innoculated that we could get out.
Our line is a 768/512 DSL (I believe those are the numbers), and it amazes me that a single machine infected could cause so much trouble. This is pretty disturbing.
I ran a test on the 1597 unique hosts that have attempted to infect my web server recently.
321- 20.1% - "Under Construction" default blank page
0- 00.0% - "too busy"
1093- 69.4% - cannot connect
183- 11.4% - some web page
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
From: http://help.broadband.att.com/subagreelease.jsp
(b) FTP/HTTP Service Setup. Customer should be aware that when using the Service to access the Internet or any other online network or service, there are certain applications, such as FTP (File Transfer Protocol) server or HTTP (Hyper Text Transfer Protocol) server, which may be used to allow other Service users and Internet users to gain access to Customer's computer. If Customer chooses to run such applications, Customer should take the appropriate security measures. Neither AT&T nor @Home Network shall have any liability whatsoever for any claims, losses, actions, damages, suits or proceedings resulting from, arising out of or otherwise relating to the use of such applications by Customer, including without limitation, damages resulting from others accessing Customer's computer.
And the actual AUP page doesn't mention it at all: http://help.broadband.att.com/faq.jsp?content_id=7 2&category_id=34
Free Mac Mini
Slashdot is currently fucking up my submissions, claiming junk character posts, duplicate posts 22000 hours ago and what not. Sorry if this appears twice somewhere...
:) Things would have been so much easier if this was indeede remote root.
On to what I wanted to say:
While the executable is called root.exe, it's far from a remote root.
"Unfortunately" (well, if you want to do anything with root.exe at least), recent IIS versions are running as some IIS user with very few privileges. It did use to run as "system" (meaning - more power than the administrator), but it doesn't anymore.
My attempts at shutting down machines attacking my Apache box by running various "net stop" commands etc. were futile. The IIS user simply doesn't have the privileges to shut down the system.
I suspect one could create the equivalent of a fork bomb in a very minimal executable - then write the executable to the remote machine in a number of HTTP requests, and finally get the attacker to stop simply by executing the fork bomb.
But I haven't gotten around to trying this just yet
I had to modify them for my modem, as docsDev appears in the "experimental" group, rather than the proper location. Install all 4 files in your mibs directory, and you should be able to deal with any modem.
On my modem, the raw OID is ".1.3.6.1.3.83.1.6.4.1.2.1". The proper OID is ".1.3.6.1.2.1.69.1.6.4.1.2.1" (the last digit changes of course). If one doesn't work, try the other. From now on, I'll just post the OID that works for my modem, you may need to modify it.
The integer value ".1.3.6.1.3.83.1.6.3.0" controls the default action, with 2 being "accept". If your ISP was using a drop-by-default policy, removing the firewall rules would disable your internet connection (so snmpset it to "2" first). But I don't think any ISP firewalls that strictly.
The 1.3.6.1.3.83.1.2.1.[x].[rulenum] table controls SNMP access. If you know how to read an MIB, you can use this to change access settings (i.e. set community strings, or restrict by IP). To find your community strings, if they are not the default strings, you can download your modems config file through TFTP. Sniff some DHCP requests to find the server's address, and the filename. You might need to set your IP to one in the 10.x.x.x block while downloading the file (you can also get a copy of your modems firmware this way).
For anyone who thinks this info might help you uncap your modem - you're wrong. I've tried modifying every value related to speed limits, including adding new QOS tables. Nothing works (well, maybe if you hack the firmware, and convince your modem to take your "updated" version...). It's the most well-protected setting in the modem. However, you can READ the cap settings - so when you're ISP says "we're 100x faster than a 56k modem", you'll have proof they are lying. 2048 kbit isn't even 100x faster than a 28.8 modem...
You can also use MRTG to graph your modems bandwidth usage, which is pretty interesting. And you can graph things like the signal-to-noise ratio, transmit/receive power levels, error rates, etc.