Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Check the Apache logs for Nimda worm attacks Network
I realize that readers might be getting tired of the pipe-related tricks, but here's a quick one that may be of use to anyone running a webserver from OSX. As you realize, the Net is in for yet another round of annoyance with the introduction of the nimda worm. Like its CodeRed predecessors, it primarily targets Microsoft IIS servers, not Apache which is installed by default with OSX. While Apache is immune to this PARTICULAR attack**, it is still affected by the fact that an infected Windows system will launch hundreds of attempts to find other vulnerable systems, thereby creating a denial-of-service situation across the Internet.

Anyhow, if you do serve HTTP from your OSX box, here's a quick way to check if a nimda-infected system has contacted yours:
grep -i "_vti_bin" /var/log/httpd/access_log* | cut -f 1 -d ' ' | sort | uniq
to show all the unique IPs of infected systems. Or you could add:
| wc -l
to the end of the above command to just see the total number of different attempts made.

** A gentle reminder that choosing the Mac as our platform doesn't inherently make us more secure from net attacks and exploits -- it's just the fact that more people are using Windows at this time, so that's where most of the blackhats turn their attention towards.
    •    
  • Currently 2.00 / 5
  You rated: 2 / 5 (2 votes cast)
 
[5,696 views]  

Check the Apache logs for Nimda worm attacks | 13 comments | Create New Account
Click here to return to the 'Check the Apache logs for Nimda worm attacks' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
OS X 1.2v3
Authored by: Loh-Q on Sep 20, '01 04:05:39AM

Do you have version that will work pn an OS X 1.2v3 server?

Cheers
Bobbi



[ Reply to This | # ]
OS X 1.2v3
Authored by: victory on Sep 20, '01 09:46:52PM
Sorry, I don't know anything about OSX server. But until someone smarter comes along, here's something you might try. The command sequence shown is actually fairly generic and probably the only thing keeping it from working is that OSX server might keep it's weblogs in a different location than OSX workstation. If you're not sure where that is, try:
sudo find / -name "access_log*" -print
(You'll be asked for your admin p/w) to search your system for the access logs. If you find them, use whatever path is shown in place of /var/log/access_log* as described in the hint. This assumes OSX server is running Apache(?).

[ Reply to This | # ]
Help! Script to Remove Code* log entries
Authored by: Anonymous on Sep 20, '01 09:43:37PM

Rather than count hits, could someone please post an example of a script to remove all codered* and new worm related log entries from my apache logs. I've played around with grep and diff to little avail.

If someone could let me know how to do this I would be very grateful.

Y



[ Reply to This | # ]
Help! Script to Remove Code* log entries
Authored by: sharumpe on Sep 21, '01 04:49:51PM

The problem with doing something like this is that you have to run it as root or some other use with permissions on the log files. Probably the easiest way would be like this:

egrep -v "(default.ida|(cmd|root).exe)" /var/logs/httpd/access_log > /var/logs/httpd/new_access_log

This filters codered and nimda traces from your logs and leaves the 'new' log in new_access_log. If you want to have a LOT of fun (grin) you can edit your /etc/httpd/httpd.conf file like so:

(look for)
CustomLog "/var/log/httpd/access_log" common

(replace with)
CustomLog "| egrep -v '(default.ida|(cmd|root).exe)' >> /var/logs/httpd/access_log"

This does the filtering on-the-fly. Please note that this is not guaranteed to work exactly as typed here - this is from memory and has not been tested. But the concept is there. :)

Mr. Sharumpe



[ Reply to This | # ]
Help! Script to Remove Code* log entries
Authored by: sharumpe on Sep 21, '01 04:56:53PM

Oops - that (replace with) should read:

CustomLog "|/usr/bin/egrep -v '(default.ida|(cmd|root).exe)' >> /var/log/httpd/access_log" common

Mr. Sharumpe



[ Reply to This | # ]
Help! Script to Remove Code* log entries
Authored by: Anonymous on Sep 22, '01 08:01:16PM

Thanks for the egrep commands, they work great. I couldn't get the Apache conf log to work however. Apache starts but the access_log no longer functions (I use Apache 1.3.20). I'm not sure why. It's ok though, this way I log everything and have cron run a log cleaner script to get rid of all the entries I dont want to see in my stats. This has made the analog/report magic stats page much more useful! Thanks again.

Y



[ Reply to This | # ]
how aobut redirecting them ...
Authored by: moyashi on Sep 21, '01 09:31:57AM

This isn't my code, I found it on a forum I visit ...

# trap CodeRed and send them away!
<Location /default.ida>
RewriteEngine On
RewriteRule /default.ida http://www.microsoft.com/ [L]
</Location>
# trap exploits of code-red compromized systems.
<Files "*.exe">
RewriteEngine On
RewriteRule . http://www.microsoft.com/ [L]
</Files>

The only thing is that I'm not sure if you'll be the referring agent or not. Then again I wonder If they'll notice if a mac sent it to them ;-)

This is definately not a nice thing to do but I'm sick and tired of all this already ... 1 hit per 3-6 seconds. I don't even want to leave my connection going when I'm working on my site -- through apache on my own desktop ...

I did try BrickHouse ... but I'm tired of trying to figure out a configuration that won't slow my connection speed ... and give me all kinds of problems visiting some sites.

Once, again this isn't my code and it's not really a nice thing to do ... period! But someone trying to hack your machine isn't nice either!

informational and personal enjoyment purposes ONLY !!!



[ Reply to This | # ]
how about redirecting them ...
Authored by: Toby Thain on Sep 27, '01 09:57:37AM
Good idea, but it can be accomplished more simply with the Redirect directive (see the Apache 1.3 documentation):
Redirect gone /default.ida
RedirectMatch gone .*c;.exe$
# or
Redirect permanent /default.ida http://www.microsoft.com/
RedirectMatch permanent .*c;.exe$ http://www.microsoft.com/
# as you prefer
I've decided on a different approach with my web server, which has many VirtualHost sites - set up a dummy VirtualHost as the default (first) server which will be a catch-all for requests to the server's numeric IP, and block all accesses to it. (All other VirtualHosts continue to serve requests normally.)

[ Reply to This | # ]
how about redirecting them ...(to themself)
Authored by: johnww2 on Jul 20, '02 04:39:12AM

I copied and pasted this bit suggested above into my httpd.conf on my linux box, and replaced "www.microsoft.com" with "localhost". I tested it from my Mac OS X machine and it redirects hits on /default.ida to my Mac OS X's webserver, so I'd say it works.

This will have the effect of causing the infected machine to redirect to itself, and is perhaps better than getting involved with redirection at the evil empire.

Here's the modified version:

RewriteEngine On 
RewriteRule /default.ida http://localhost/ [L]         

# trap exploits of code-red compromized systems. 

RewriteEngine On 
RewriteRule . http://localhost/ [L]         


[ Reply to This | # ]
Total count of hits?
Authored by: Anonymous on Sep 22, '01 03:10:18AM
I was poking around on my access_log, and I noticed that "_vti_bin" was not the only crud that Nimda requests from your machine. I saw stuff containing "default.ida", "cmd.exe" and "root.exe" so I modified the mentioned script to (hopefully) show every single hit that Nimda had on your machine. Here it is:
egrep -i "(_vti_bin|default.ida|cmd.exe|root.exe)" /var/log/httpd/access_log* | cut -f 1 -d ' ' | sort | wc -l
Let me know if this is showing a correct number, or is totally whacked. On my machine which is running 10 about 3 to 4 hours a day, it's had 3459 hits from Nimda. -THX

[ Reply to This | # ]
Ooops!
Authored by: Anonymous on Sep 22, '01 03:28:49AM
Whoops, I messed up part of this, but I don't think it affects the final count much much. All the lines that contain "_vti_bin" also contain "cmd.exe", so I'll leave "_vti_bin" out of this, however the count is still the same. I also talked to a friend, who says this will also show the amount of Code Red hits also, because they exploit some of the same vulnerabilities. Here's the new command:
egrep -i "(default.ida|cmd.exe|root.exe)" /var/log/httpd/access_log* | cut -f 1 -d ' ' | sort | wc -l
-THX

[ Reply to This | # ]
Total count of hits?
Authored by: Darkshadow on Sep 22, '01 07:53:53AM
I wrote a CGI perl script that will tell you the addresses, number of hits, number of unique hits, and total number of requests from the Nimda worm. It's based on the grep code from here. Just drop it into your CGI-Executables directory and access it to look at the hits. Note that this works with your access_log, so if you filtered out the hits, it won't tell you the correct number. You can grab the script here: newworm.pl

[ Reply to This | # ]
Logging Nimda/Codered/Virii attacks in separate logs
Authored by: valmont on Nov 03, '01 06:35:00PM

I posted a how-to on my first slashdot journal entry at:

http://slashdot.org/journal.pl?op=display&uid=3573&id=1405

i've also worked on a set of shell scripts that would interact with a potential perl module described in that post, which can also be used as standalone, which basically leverages the codered/nimda backdoors to make some significant attempts to harmlessly and not too intrusively "warn" the infected hosts. It also creates a list of unique hosts as they hit you. It's kinda ugly though.



[ Reply to This | # ]