# New windows worm in apache logs?

## Boohbah

I've been seeing quite a few of these lately in my apache logs:

```

xx.xxx.xx.xx - -  [01/Apr/2004:16:34:58 -0800] "SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\x02

[snip]

\x90\x90\x90\x90\x90\x90\x90\x90" 414 335 "-" "-"

```

A very long search string that looks like it's crafted to exploit a MS IIS server, i assume. The reason i'm asking is because this just started showing up today, and from several different IPs. Does anyone know of a new worm out there in the wild? Obviously i'm not worried since my server returns a 414: Request URI too long, but i'm curious. Any thoughts?

----------

## pioto

same thing showing in my logs... starting... 10am today, EST.... tempted to list their ip addresses...  :Twisted Evil: 

if a bunch of ppl get together and whois 'em and find them to be the same isp... we can do that easily enough... 

basically, though, i get this format of listing in my logs:

```
xxx.xxx.xxx.xxx - - [27/Mar/2004:03:42:29 -0500] "SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1 [snip] \x90\x90\x90" 414 390 "-" "-"
```

so, seems like a definite hack...

the strings are all different lengths, but follow this basic pattern:

an opening \x90 followed by repeating \x02\xb1\x02\xb1 ... then about half way through, becomes \x90\x90 ... till the end. seems to be sending a long string of hex to the server... anyone able to shed some light on this?

----------

## malloc

That seems to be a stack overflow exploit.

They are "common" in *nix. I have a few of these in my logs too mine are coming from 81.x.x.x all of them, i think they're from the same subnet wich means that either they're the attackers or their servers have been the first to be infected.

Edited:

I'm guessing it might have something to do with this..

 *Quote:*   

> 
> 
> 2. Apache fails to filter terminal escape sequences from error logs 
> 
>  that begin with the ASCII (0x1B) sequence and are followed by a 
> ...

 

----------

## pioto

so.... i guess this means that viewing our logs could put us at risk? hrm... very sneaky / evil... if you know a tool for figuring out what that *would* do if it worked, i'd like to know...   :Wink: 

----------

## clar77

same thing here, this morning :(

----------

## vega

Same thing here since March, 02. I have more than 100 entries in my logs but only for the default server. No entries were found in virtual servers logs.

All "attackers" (if you can say that) are identified as they're using "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" but the connections come from several different IP numbers.

And the file searched is always /default.ida (followed by a HUGE and dirty query string)

It seems like some Windows machines out there are infected by some kind of worm and scanning every single IP address they find.

Anyone has more info on this?

----------

## Chris W

Vega, Google is your friend:

The Site Wizard: What is default.ida? Defending Your Site From the Code Red II Worm

Apache week: Code Red requests for /default.ida

The OP's SEARCH log entries look like an attempt to exploit an IIS WebDAV.

Analysis of the ntdll.dll WebDAV Exploitor something similar.

----------

## Boohbah

 *vega wrote:*   

> 
> 
> And the file searched is always /default.ida (followed by a HUGE and dirty query string)
> 
> 

 

I have seen this for a long time and it's a known worm. This search string i'm seeing in my logs now since April 1st is different.

----------

## Boohbah

 *Chris W wrote:*   

> 
> 
> The OP's SEARCH log entries look like an attempt to exploit an IIS WebDAV.
> 
> Analysis of the ntdll.dll WebDAV Exploitor something similar.

 

Ahh yes, it looks very similar to that.

----------

## Immortal Q

Is there any way we can filter these from out Apache logs?  Something besides ReallyQuiet to keep Webalizer from whining?

----------

## tomk

 *Immortal Q wrote:*   

> Is there any way we can filter these from out Apache logs?

 

I use pglogd, which pipes your apache logs to postgresql. You can then set up different tables. There is a main log_entries table where all the logs go, but I've made a table which removes all the attacks and local requests. The view for my different domains use the later table to get it's results.

I'm currently writing an ebuild and init script for pglogd which should be ready in the next couple of days.

----------

## DozePih

 *Immortal Q wrote:*   

> Is there any way we can filter these from out Apache logs?  Something besides ReallyQuiet to keep Webalizer from whining?

 

I really would like that since my logs are filled with like ~20-30MB of crap each day. I've tried

```

SetEnvIf Request_URI "^/\\x90" attacks

CustomLog logs/access_log common env=!attacks

```

But my access_log is still flooded.

----------

## dreamer

i created this to block the infected ip's. If you run this script every 30 minutes or so, it will make a huge difference in your logs.

You may find the filtering rules too agresive ( they are  :Wink:  ) but they work for me. By commenting the filterrule that looks into error_log  it's a lot less aggresive. If you do this you have to add some new lines grepping for "x90" and "default.ida" to catch those worms.

have fun!

----------

## gnac

WOOHOO!

I found it!

First of all, the default.ida is a different exploit then the "SEARCH" exploit given by the original poster.  The first is nimba or some sort, the second tries to exploit a WebDav weakness.  I show how to filter both below so they don't go into your logs, and also, if you so desire, log the exploit attempts to a second "attack_log".

Originally I was trying to filter out the webdav exploits by adding things like

```
SetEnvIf Request_URI "\\x90" ATTACK

SetEnvIf Request_URI "x90" ATTACK

SetEnvIf Request_URI x90 ATTACK

SetEnvIf Request_URI "\\xb1" ATTACK

SetEnvIfNoCase Request_Method "SEARCH" ATTACK
```

 to my commonapache2.conf file with no luck.

I finally found the answer at  this site

It turns out that apache does not recognize the SEARCH method since its not a valid method.  However, like alice in wonderland, if it doesn't work small, try big.

Instead of filtering out the "SEARCH" methods, allow the others, GET, POST, HEAD:

```
SetEnvIf Request_Method "GET" good

SetEnvIf Request_Method "POST" good

SetEnvIf Request_Method "HEAD" good
```

As my non-italian speaking grandma would say, "viola" (misplelling intentional).

of course don't forget your 

```
CustomLog /var/log/apache2/attack_log combined env!=good

CustomLog /var/log/apache2/access_log combined env=good
```

BTW, is it possible to do something like 

```
 CustomLog /var/log/apache2/attack_log combined env=ATTACK env!=good

CustomLog /var/log/apache2/access_log combined env=!ATTACK env=good
```

So that I can keep my 

```

SetEnvIfNoCase Request_URI (.*)cmd\.exe ATTACK

SetEnvIfNoCase Request_URI (.*)root\.exe ATTACK

SetEnvIfNoCase Request_URI \.ida(.*)$ ATTACK

```

 directives.  (These filter out the default.ida and other windows hacks).  Yes I know I could simply use !ATTACK instead of good, but I'm just curious about multiple conditions for the setenvif directive.

Alternatively, does the ordering of the directives matter?  For instance if I put the !ATTACK directives first, and then a later directive determines that its is an ATTACK, will it overide the first.  eg:

```

SetEnvIf Request_Method "GET" !ATTACK

SetEnvIf Request_Method "POST" !ATTACK

SetEnvIf Request_Method "HEAD" !ATTACK

SetEnvIfNoCase Request_URI (.*)cmd\.exe ATTACK

SetEnvIfNoCase Request_URI (.*)root\.exe ATTACK

SetEnvIfNoCase Request_URI \.ida(.*)$ ATTACK

CustomLog /var/log/apache2/attack_log combined env=ATTACK

CustomLog /var/log/apache2/access_log combined env=!ATTACK
```

EDIT: also, if you add the line "Deny from env=ATTACK"  to your <Directory /> section of commonapache2.conf, it should block the attacker from getting anything.

```
<Directory />

  Options -All -Multiviews

  AllowOverride None

  <IfModule mod_access.c>

    Order deny,allow

    Deny from all

  </IfModule>

  Deny from env=ATTACK

</Directory>
```

----------

## gnac

Okay, I think I answered my question, NO, you cannot expect env variables to be set in any sort of precedence.  Here is the content of my commonapache.conf file which filters and blocks the log clogging "SEARCH" requests and a couple of other MS targeted attacks:

```

# make sure the requesters are using a "good" method, i.e not "SEARCH"

SetEnvIf Request_Method "GET"  good

SetEnvIf Request_Method "POST" good

SetEnvIf Request_Method "HEAD" good

# check for known attacks on "good" request methods"

SetEnvIfNoCase Request_URI (.*)cmd\.exe ATTACK

SetEnvIfNoCase Request_URI (.*)root\.exe ATTACK

SetEnvIfNoCase Request_URI \.ida(.*)$ ATTACK

# Custom logs to route attacks to a separate log

CustomLog /var/log/apache2/access_log combined env=good

CustomLog /var/log/apache2/attack_log combined env=ATTACK

CustomLog /var/log/apache2/attack_log combined env=!good

# set the root to deny ATTACKs and not good requests

<Directory />

#whatever else you have here

  Deny from env=ATTACK

  Deny from env=!good

</Directory>

```

Let me know if I am missing something.

----------

