Code Red on dial-in ppp
You may have received the following from codered@securityfocus.com This mail is from the ARIS Analyzer Service (Attack Registry and Intelligence Service) from SecurityFocus. It has come to our attention that your system(s), listed below have been identified as being compromised by the Code Red Worm. The Code Red Worm is rapidly spreading across the Internet, compromising vulnerable Windows NT IIS servers. The addresses identified as belonging to you are as follows: [ dynamic dial-in ip ] [ dynamic dial-in ip ] [snip] This makes me think that the worm is capable to infect not only dedicated web servers, but also dial-in customers running ppp that happen to be online when the attack occurs. NetSide is an all Sun sparc shop and we don't have any Windows based machines, but I can see this worm being alive and spreading for a long time if dial-in users are affected. Unfortunately, they don't provide a date and time stamp, so identifying the actual user is not possible. I can provide web server log extracts to whomever collects/analyzes such information (John O., sorry but you're bouncing my email - get rid of MAPS). --Mitch NetSide
I'm not sure I see why a POTS PPP link, or some other slow(er) on demand link might stop CodeRed. The first-pass payload is under 4096 bytes including framing, not exactly something you need a lot of low-latency bandwidth to push through. :-/ -J On Sat, 21 Jul 2001, Mitch Halmu wrote:
You may have received the following from codered@securityfocus.com
This mail is from the ARIS Analyzer Service (Attack Registry and Intelligence Service) from SecurityFocus. It has come to our attention that your system(s), listed below have been identified as being compromised by the Code Red Worm. The Code Red Worm is rapidly spreading across the Internet, compromising vulnerable Windows NT IIS servers.
The addresses identified as belonging to you are as follows:
[ dynamic dial-in ip ] [ dynamic dial-in ip ]
[snip]
This makes me think that the worm is capable to infect not only dedicated web servers, but also dial-in customers running ppp that happen to be online when the attack occurs. NetSide is an all Sun sparc shop and we don't have any Windows based machines, but I can see this worm being alive and spreading for a long time if dial-in users are affected.
Unfortunately, they don't provide a date and time stamp, so identifying the actual user is not possible. I can provide web server log extracts to whomever collects/analyzes such information (John O., sorry but you're bouncing my email - get rid of MAPS).
--Mitch NetSide
Jason A. Mills phyxis@rottweiler.org ---------------------------------------------- "La morale est la faiblesse de la cervelle." Arthur Rimbaud --- Une Saison en Enfer
On Sat, 21 Jul 2001, Jason A. Mills wrote:
I'm not sure I see why a POTS PPP link, or some other slow(er) on demand link might stop CodeRed. The first-pass payload is under 4096 bytes including framing, not exactly something you need a lot of low-latency bandwidth to push through. :-/
-J
The problem I described is that the Windows machines in question are not necessarily dedicated web servers, but can be regular dial-in users. Normally, such users don't run a web server over dial-up, yet they seem to be vulnerable if the attack occurs while they're connected. No relation to the connection bandwidth was implied. --Mitch NetSide
On Sat, 21 Jul 2001, Mitch Halmu wrote:
On Sat, 21 Jul 2001, Jason A. Mills wrote:
I'm not sure I see why a POTS PPP link, or some other slow(er) on demand link might stop CodeRed. The first-pass payload is under 4096 bytes including framing, not exactly something you need a lot of low-latency bandwidth to push through. :-/
The problem I described is that the Windows machines in question are not necessarily dedicated web servers, but can be regular dial-in users. Normally, such users don't run a web server over dial-up, yet they seem to be vulnerable if the attack occurs while they're connected. No relation to the connection bandwidth was implied.
Have you port scanned said users? You might be suprised how many dialup users are running httpd. And smtpd. And pop3d. And named. And, of course, an IRC bot...all usually on their windoze machines, because, like, they're really advanced users, see? Hint: These are often the same users you have to nag about continuous connections. James Smallacombe PlantageNet, Inc. CEO and Janitor up@3.am http://3.am =========================================================================
The problem I described is that the Windows machines in question are not necessarily dedicated web servers, but can be regular dial-in users. Normally, such users don't run a web server over dial-up, yet they seem to be vulnerable if the attack occurs while they're connected. No relation to the connection bandwidth was implied.
Yes, we have noticed a few dialups that are infected. So, it has happened. Damon -- "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." --Doug Gwyn
Once upon a time, Jason A. Mills <phyxis@rottweiler.org> said:
I'm not sure I see why a POTS PPP link, or some other slow(er) on demand link might stop CodeRed. The first-pass payload is under 4096 bytes including framing, not exactly something you need a lot of low-latency bandwidth to push through. :-/
I don't think the issue is bandwidth. The issue is that the reports being sent out say such-and-such IP is infected without giving a time stamp (I got one of the reports as well). Without the time of the attack, the IP address is absolutely useless, as a hundred users may have had that IP in the last couple of days. In my case, out of two dozen hosts reported, all but two were dialup or DSL IPs, making the report mostly worthless without times. I don't mean to criticize, because obviously some folks put in a lot of effort, and it is useful information (especially if you don't have dialup hosts). Just in my case (at least), it wasn't much help. Interesting to note that the one host from our IP space that hit one of our servers was NOT in the report I received. We had over 21,000 hosts try this on our (Unix/Apache) web servers. Is someone collecting logs to generate reports? -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Sat, Jul 21, 2001 at 01:09:06PM -0500, Chris Adams wrote:
I don't think the issue is bandwidth. The issue is that the reports being sent out say such-and-such IP is infected without giving a time stamp (I got one of the reports as well). Without the time of the attack, the IP address is absolutely useless, as a hundred users may have had that IP in the last couple of days.
I have timestamps for the IPs I had on my list I posted a link to. If you need them, contact me directly. John
On Sat, 21 Jul 2001, Chris Adams wrote: |+Interesting to note that the one host from our IP space that hit one of |+our servers was NOT in the report I received. We had over 21,000 hosts |+try this on our (Unix/Apache) web servers. Is someone collecting logs |+to generate reports? Weird but Ive been scanning our Apache logs and have yet to see any attempts for this yet. Snort has reported 414 alerts w/ regards to Code Red in about a 12 hour period, but none of the destinations are where are web server sits, just all in our DSL range. Keith
Date: Sat, 21 Jul 2001 10:40:47 -0400 (EDT) From: Mitch Halmu <mitch@netside.net> To: nanog@merit.edu Subject: Code Red on dial-in ppp
You may have received the following from codered@securityfocus.com
[ snip ] One of our clients received said message noting that CR might be on their Watchguard firewall -- which has no service listening on port 80. Here's what I think happened: * CodeRed infects IP addr 1.2.3.4 (some valid public IP) * IP addr 1.2.3.4 is bound as secondary, with RFC1918 as primary * Said server is behind NAT-providing firewall * When infected server contacts the outside world, it uses the private IP, which the firewall then masquerades. This client has several NT boxen behind their firewallo so who knows which the culprit is -- or are. Just an FYI that will hopefully help others who encounter similar situations. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ---------------------------------------------------------------------------
participants (8)
-
Chris Adams -
Damon M. Conway -
E.B. Dreger -
Jason A. Mills -
John Kristoff -
Keith Woodworth -
Mitch Halmu -
up＠3.am