buschermannat_private wrote: > on sunday our apache logs the thing below: > > 62.193.140.34 - - [09/Sep/2001:08:08:04 +0200] > "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ---cut--- > > followed by a lot more 'X' and the typical encoded strings. > on 13:28 +0200 i get the exactly same 'request' again. > > 1. there is no GET-request for anything, so apache said '400' aka 'bad > request' > 2. less 'X' have been used than in an normal attempt. there were only 192 > instead of 223, which i think > is the 'standard' amount. These types of corrupted CodeRed "samples" have already been discussed here and in other fora several times. In short, many ISPs seem to be running "stealth" web proxies, wehreby they intercept outgoing HTTP requests from their clients and redirect them through a proxy (presumably to gain bandwidth effeciencies through associated caching?). As proxies will (in fact, must) this causes the request to be altered by the insertion of extra parameters at the end of the HTTP GET request (so the proxy knows who to send the returned page to if it is not in the local cache. In the simple case, a CodeRed GET request passing through such a proxy is simply "extended", with the extra parameters inserted after the "HTTP/1.0" string or after one of the parameters that CodeRed includes after that. Such "samples" are fundamentally broken because the overflow offset is unaffected by the change to the GET parameters, but the code the overflow is supposed to jumpt to moves because of the insertion of the extra parameter(s). However, life is not always so perfect and it seems many of the proxies popularly used for these purposes have, themselves, buffer- length issues. Some may not even be able to handle the full 3818 byte length of the CodeRed request, but commonly what we see is 3818 byte requests that have extra HTTP GET parameters (as described above) inserted but then the request is truncated *from the front*. Thus, you see something like you describe, with the actuall HTTP command and the first part of the overflow string removed. > the site seems to be a kind of search portal for parents and kids and looks > like under > construction. it's running IIS 5 on w2k according to netcraft. > i mailed the admin-c of the net and am awaiting an answer, but nevertheless > i thought the list > could shed some light on where this thing might come from. > a crippled worm? Nope. That machine is running a perfectly valid and functional copy of CodeRed. At least some of the machines it will target (those its stealth proxy brokers requests for) will receive corrupted copies of that worm, which are, of course, non-viable. > a bored user? > spoofing? > ...? Nope -- the above is very common. Probably about 10-15% of the traffic being captured by my port 80 honeypot is of precisely this nature. However, if you are using simple IDS rules to detect CodeRed you probably are not capturing enough data to get the full picture. -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854 ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Sep 10 2001 - 15:38:31 PDT