bugtraq - Re: phpBB Worm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 23 Dec 2004 13:59:00 +0100
From: Anders Henke <anders@...lund.de>
To: Raymond Dijkxhoorn <raymond@...location.net>
Cc: Shannon Lee <shannon@...hostworks.net>, bugtraq@...urityfocus.com
Subject: Re: phpBB Worm

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