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. |

| 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> |
|---|---|---|
| ||
| Previous by Date: | [VulnWatch] Oracle ISQLPlus file access vulnerability (#NISR2122004E), NGSSoftware Insight Security Research |
|---|---|
| Next by Date: | [USN-50-1] CUPS vulnerabilities, Martin Pitt |
| Previous by Thread: | Re: phpBB Worm, William Geoghegan |
| Next by Thread: | RE: phpBB Worm, Paul Kurczaba |
| Indexes: | [Date] [Thread] [Top] [All Lists] |