procmail
[Top] [All Lists]

Re: Nimda virus filter testing

2001-09-21 13:22:41
On 09/20/01 01:19 PM, Sean Straw / PSE sat at the `puter and typed:

deal with the 404 and error logs.  I really just need to learn perl
and to strengthen my Apache skills.

See below - no perl necessary since you indicate you have PHP on the 
machine already.

Yes, but I also run with mod_perl, so the handler is invoked and kept
resident.  I don't know how the php will be handled in this case, but
the perl is quite fast.

One of these days, I'm gonna have to pick thru the advantages and
disadvantages of each.  I definitely want to learn both, though.

Apache::CodeRed is a module that is invoked directly via a handler.
Sounds like I need to look into it and consider hacking it, since this is 
pretty much along the lines of what I was considering doing for Nimda (with 
the exception that I plan to send notices to IP block owners and also 
submit the offending IP address to a firewall, which will SHARPLY drop the 
attacks).

Yes, I like this idea too.  I have a 'bad guys' list on my firewall
that is always in flux.  I'd like to set up some kind of scheme that
will allow me to dynamically add to it and reset the rules.

I've fetched the CodeRed module, but it looks like I'll have to do some 
significant rewriting to make it operate as a PHP module.

Yes, but if you have Perl installed, and mod_perl in your server, you
only need a couple support modules and you're up.  If you handle it thru
mod_perl, the module stays in memory and doesn't have to be
reloaded/recompiled, etc.  It's ready to go when the request comes in.
This has to be faster than loading and parsing any file.
 
However, it looks like you can probably hack it to do what you need for 
nimda - mostly that's a function of the httpd.conf lines to invoke it, and 
changing the text of the message which it sends (plus changing the name of 
the database it uses to track infected hosts, so that you're not mixing 
codered and nimda hosts).  Sadly, I can't contribute to that hack at this 
time - I've got other work to catch up on...

Ditto.  Of course, it's probably just some pattern matching and a
little context that needs work, so maybe I'll try it next weekend
(long weekend and the travel plans got canceled).

Agreed.  I actually considered hacking the CodeRed module to make it
send a shutdown command if the system went unrepaired for too long.

Yea, that is the funny thing here - the specific exploit means that remote 
sites could send things like this in their own defence.  If you try hitting 
an attacking site with the various URLs it hit yours with (which are 
conveniently sitting in your logs), you'll end up finding some which that 
site responds with - i.e. the exploit is still there even though the server 
is already infected.

I had gone through this process in an attempt to determine if there was 
something I might be able to return to an attacking system that would say 
"gosh, this system is already a zombie in your army, and I'm working 
dilligently at spreading the worm - you can go look for someone else to 
infect".  Of course, this would only be returned in response to the 
specific inquiries that the worm sends.

idea, actually.  Certainly cut the internet load by a great deal.

Yes, not only reducing your own traffic, but also helping keep the spread 
in check by taking another infected host out of the loop so that it not 
only isn't hitting you, but isn't FINDING AND INFECTING more susceptible 
hosts.

Yes!  My point exactly.  I still don't know how to make use of it
though.

But this worm also spreads thru the MSIE browser, right?  I wonder how
it affects the browser.  If it sets it making the same random
requests, then maybe it could be detected and a redirect or javascript
popup could be used to let the unwary user know they are infected.

Since Nimda hit, I am seeing far less of these.  I wonder how the two
interact?

As I understand it, CodeRed II left some backdoor which Nimda can use to 
gain access.  I doubt they interract so much as perhaps Nimda might end up 
taking over (such as latching into the same buffer space or something, 
thereby overwriting the hook for CodeRed).

This was my guess too.


(in your httpd.conf:)
RewriteEngine on
RewriteRule (default\.ida|cmd\.exe|root\.exe|Admin\.dll) 
/local_path_to_file/iisworm.php

That rewriterule and the line following are ONE line

(iisworm.php:)
<?PHP   // iisworm.php
         header("HTTP/1.0 200 OK");
         header("Content-Type: text/plain");
         header("Connection: close");
?>vermicelli!

So this looks like an intelligent redirect that works with a regexp
string.  Pretty cool.  However, since the Perl handler treats the
request directly, I think it might be less load on the system.  Not
that CodeRed is killing anyone so much these days.
 
The same php file is easily modified to return a specific 404 error, or 
even a redirect, which is something I tried (along with also returning a 
file containing the HTML code with the javascript in it, in case the worm 
scans the buffer looking for a code fragment), but this unfortunatley 
didn't result in any change in the attack.  I had hoped that the worm might 
_follow_ the redirect and look there, which posed not only a way to get the 
attack to cease against your own site, but to direct it back at some other 
server, say extracted from a list of previous servers exhibiting that they 
were ALREADY infected, thereby hopefully compounding the traffic at 
infected sites and causing the infected servers to choke. 127.0.0.1 was 
also an option ("attack thyself, knave!")

I like that last one!

Hmm.  I wonder what has to be sent back to shut them down.  I would
think it should be possible to send another message that would wind up
in the logfile that could alert the admin that the server was shut
down because they were spreading the worm.  Something that would show
up as a 404 maybe?

Since I run PHP as an installed module, rather than an invoked handler, the 
above PHP file is processed much quicker and with less overhead than a perl 
script doing the same thing.

I run PHP the same way.  I see no reason to do CGI invocation when an
installable module is so easy - and obviously much faster.

Regards
Lou
-- 
Louis LeBlanc       leblanc(_at_)acadia(_dot_)ne(_dot_)mediaone(_dot_)net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net                 Ô¿Ô¬

aphorism, n.:
  A concise, clever statement.
afterism, n.:
  A concise, clever statement you don't think of until too late.
    -- James Alexander Thom

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>