[Snort-users] CodeRed infection / Possible bug in 1.9 DB calls?

bthaler at ...2720... bthaler at ...2720...
Wed Jan 22 07:58:02 EST 2003


I'm going out of my mind trying to figure this one out.  I posted a similar
question to snort-sigs, but nobody had a real solution.

I was using Snort-1.8x with no problems whatsoever.  I have the following
two rules to detect local CodeRed infections:
alert tcp $HOME_NET any -> any 80 (msg:"*** LOCAL CODERED INFECTION ***";
content:"/cmd.exe"; nocase;)
alert tcp $HOME_NET any -> any 80 (msg:"*** LOCAL CODERED INFECTION ***";
content:"/root.exe"; nocase;)

These rules never triggered because all of my servers have been patched ages
ago.  So far so good.

A couple of days ago, I decided to upgrade Snort to 1.9 and I'm suddenly
seeing a few alerts triggered by these rules.  Not many, but there shouldn't
be even one, unless it's a false positive.

I've written my own front-end to Snort, and when I look at the payloads of
packets that tripped these rules, they don't make any sense to me.  Here's
an example of what I'm seeing:

<!---- begin payload ---->
GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
HTTP/1.0
Host: www
Connnection: close

P/1.1
Accept: */*
Referer:
http://content.transhosting.com/melodious/cgi-bin/imageFolio.cgi?direct=Vide
o_Clips_For_Download/Transgender/Barbie-Kate/Part_01
Accept-Language: en-gb
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: content.transhosting.com
Connection: Keep-Alive
Cookie: setup=chris at ...8056...
Authorization: Basic Y2hGET /files/main/clubinfo.html HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword, */*
Referer: http://www.wheelers.homestead.com/files/main/wheelers.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
Host: www.wheelers.homestead.com
Connection: Keep-Alive
Cookie: phsViewerID
<!---- end payload ---->

Now, I'm no packet monkey, but it seems to me that this is actually more
than one packet payload, and not a single packet.  The first part "GET
/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" should trip the
rule as expected, but only if the packet originates in $HOME_NET.  I've
scanned every machine here (a /19 BTW) for CodeRed, V2, and Nimda, and all
machines are clean.  We're blocking spoofing at the edge router, so it can't
be a spoof either.

Most of the machines that the rules claim are infected are servers.  They
wouldn't be sending packets with "HTTP Get" commands in them.  A couple of
times it was a workstation, but the user denies having visited at least one
of the sites listed in the payload.  The packet above was supposedly
generated by my workstation.  I most definitely did not visit
"transhosting.com", but I did visit "homestead.com".  The site
"transhosting.com" is actually one of the servers we host, so packets
destined for this domain would be seen on our network.

I thought this was a problem with my custom Front-End, but I just installed
Acid, and it reports exactly the same payload for the same packets.

It then occurred to me that this may be a problem with the new
"conversation" feature.  I suspect that this is either incorrectly
identifying conversations, or something else in Snort is combining packets
together like this.  Frag/Stream maybe?  Or it could be simply the way the
packets are written to the database?  I'm really not sure where to look
next.  What do you all think?

It just seems weird that these rules started tripping for several machines
immediately after I upgraded to Snort-1.9.









Sincerely,

Brad Thaler





More information about the Snort-users mailing list