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
> 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
[ reply ]