Local File Inclusion vs Arbitrary File Access

Notes for this blog have been lingering for over three years now. In the daily grind to aggregate vulnerabilities, the time to write about them gets put on the back burner frequently. Rest assured, this is not a new issue by any means.

Back in the day, we had traversal attacks that allowed an attacker to ‘traverse’ outside an intended directory to access a file or directory that was not intended. The most basic example of this known to most is a web application traversal attack such as:

http://%5Btarget%5D/myapp/jericho.php?file=../../../../../../etc/passwd

Making this request would direct the script to traverse outside the web server document root (DOCROOT) to access the system password file (/etc/passwd). For years, these attacks were simply known as “directory traversal” attacks. For limited traversals, CVSSv2 scoring would be 5.0 and look like (AV:N/AC:L/Au:N/C:P/I:N/A:N). If the application is running with full privileges and could access any file on the system, it would score a 7.8 and look like (AV:N/AC:L/Au:N/C:C/I:N/A:N). Note that such an attack only allows an attacker to read the contents of the file, not write to it or execute it as a script. To help distinguish this, such attacks are usually qualified to “traversal arbitrary file access”.

Local File Inclusion (LFI) attacks go back to around 2003 and often exhibit the same trait as directory traversal attacks, as outlined above. Like the traversal, the attack typically involves a relative (e.g. ../../) or absolute path (e.g. &file=/path/to/file) to call a specific file on the system. The difference is in how the application handles the request. Instead of displaying the contents of the file like above, it will include the file as if it is an executable script. This means that arbitrary code, but limited to what is already on the file system, will be executed with the same privileges as the web application and/or web server. Using a combination of real-world common issues, this can be leveraged into full arbitrary remote code execution. For example, if you can access an incoming directory via FTP to write your own .php file, the local file inclusion vulnerability can be used to call that custom code and execute it.

Visually, these two vulnerabilities may look identical:

http://%5Btarget%5D/myapp/jericho.php?file=../../../../tmp/shell.php

http://%5Btarget%5D/myapp/jericho.php?file=../../../../tmp/shell.php

Despite appearances, these are two very different attacks. If the first is a traversal arbitrary file access issue, the contents of shell.php will be displayed. If the second is a traversal local file inclusion, the contents of shell.php will be processed as PHP code and executed.

Even with this simple concept, more and more researchers are unable to make this distinction. Arbitrary file access and local file inclusion are not only getting blended together, but traversals that allow for file manipulation (e.g. append, delete, overwrite) or even file enumeration (e.g. determine existence of file only) are also getting lumped in.

Wrong:

Specto Local File Inclusion by H4ckCity Security Team gives a PoC of:

http://SERVER/index.php?page=/etc/passwd

This is clearly not a local file inclusion as the file being included is the standard text file containing password information. Instead, they show an absolute path file disclosure.

OneFileCMS v.1.1.5 Local File Inclusion Vulnerability by mr.pr0n gives a PoC of:

http://TARGET/onefilecms/onefilecms.php?f=../../../../etc/passwd

Again, calling a text file, this time via a standard directory traversal. If this is really a LFI, then the PoC does not show it.

Pollen CMS 0.6 File Disclosure by MizoZ gives a PoC of:

http://SERVER/%5Bpath%5D/core/lib/readimage.php?image=%5BLFI%5D

First, this is a bit suspicious as the parameter ‘image’ implies it will handle images such as JPG or PNG. Second, the [LFI] string doesn’t show if it is an absolute path or traversal. How could the researcher find it without knowing this? Third, and most important, their disclaimer:

The script only verifies the existence of the given file.

Sorry, not even close to a LFI.

About these ads

5 responses

  1. Wrong idea…. Vulnerability type is defined from what we can get OR from what we are exploiting ? You are defining two different names for same script (vulnerable to include any local file i.e raw passwd or php executable) , based upon their result inclusion.

    1. No, there is a distinct difference. It isn’t being “included” (in the code execution process) if it is /etc/passwd. If these researchers are confident it is LFI, they should show a PoC that demonstrates it. Any time they show a text file with no code in the PoC, it only shows arbitrary file access.

  2. Pollen CMS 0.6 File Disclosure, the title says it’s not a local file inclusion

    1. The title says ‘file disclosure’, the POC says “LFI” in it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 4,759 other followers

%d bloggers like this: