Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Bugtraq
[Top] [All Lists]

Re: phpBB Worm

Subject: Re: phpBB Worm
Date: Thu, 23 Dec 2004 13:59:00 +0100
On Dec 21st, Raymond Dijkxhoorn wrote:
If you cannot fix it (virtual servers) fast for all your clients you could 
also try with something like this:

        RewriteEngine On
        RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR]
        RewriteCond %{QUERY_STRING} ^(.*)esystem(.*)
        RewriteRule ^.*$                                -               [F]

We had some vhosts where this worked just fine. On our systems we didnt 
see any valid request with echr and esystem, just be gentle with it, it 
works for me, it could work for you ;)

This assumes you're seeing GET-requests, but there are other ways 
(e.g. POST) to exploit such code.

GET-requests are so kind as they do show up in full in the web servers
access-log and as such, they do document the full exploit code.
E.g. just the accesslogs do provide enough information for site owner and 
administrator to find out what's exactly broken and enables them to
perform detailed analysis on even previously unknown exploits as well
as reject such malicous code within a mod_rewrite-RewriteRule.

Today, most such exploits are sent using HTTP-GET, but there's a fairly
low expense for exploit code coders to run these exploits using HTTP-POST.
We're lucky that most exploit code coders haven't chosen the struggle to
properly encode their exploit-code HTTP-POST-requests, but still keep
in mind that a 'plain' Apache cannot filter the payload from HTTP-POST
other than rejecting =any= POST-request to 'specific' files like 
viewtopic.php, which obviously will sooner or later break some application.

I've already had a single case where a 'common' insecurity like 
'include($some_user_supplied_data)' has been exploited using HTTP-POST,
so for the administrators out there, it might be a good idea to test and 
implement mod_security on web servers. 
As far as I known, the POST-payload analysis of mod_security is currently
one of the very few ways to audit and stop potentially malicious 
HTTP-POST-data from reaching your web server's CGIs.


Regards,

Anders
-- 
Schlund + Partner AG              Security and System Administration
Brauerstrasse 48                  v://49.721.91374.50
D-76135 Karlsruhe                 f://49.721.91374.225

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