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

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

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

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?

I have timestamps for the IPs I had on my list I posted a link to. If
you need them, contact me directly.

John

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

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