An introduction to LFI (Local File Inclusion) can be found here. This article will explain how LFI could lead to shell access by poisoning the web server log files.

Web server log files
If a web application is vulnerable to Local File Inclusion, the next step is trying to find out where the web server log files are stored. Generally the log files on Linux systems are stored in /var/log/, but are dependent on the Linux distribution and the type of web server that is used:

[icon_list]

[icon icon_name=” icon-file”] /var/log/nginx/access.log [/icon]
[icon icon_name=” icon-file”] /var/log/apache2/access.log [/icon]
[icon icon_name=” icon-file”] /var/log/httpd-access [/icon]
[icon icon_name=” icon-file”] /var/log/httpd/access_log [/icon]

[/icon_list]

An example of loading the log files in a vulnerable web application:

Once the attacker found the proper log file, it will be displayed in the browser. The web server, among other things, will write all user-agent strings to its log file and this is how the web server logs are going to be poisoned and this is how LFI could lead to shell access.

Poisoning the web server log file(s)
As the web server will log the user-agent strings, the user-agent string in the attackers browser should be changed. There are a few addons for both Firefox and Chrome that allow you to change the user-agent string.

User Agent Switcher

 

 

 

 

 

 

 

 

In the user agent switcher, a new user agent can be created as displayed in the screenshot. Some payloads that could be used in the user agent string:

Please note that this may not always work and highly depends on how PHP is configured. When PHP is properly hardened, the functions ‘exec’ and ‘system’ are disabled, in this case the attack won’t be successful. However, with default installations of PHP the first payload seems to be always successful.

Once the user agent string has been modified to one of the two payloads as displayed above, the page of the victim is reloaded and our payload is stored in the log file.

The next step is to reload the page that allows the attacker to display the log file due to the LFI vulnerability. This step will execute the payload which is now stored in the web server log file.

The payload
The payload will execute the Linux command ‘wget’ to retrieve the file c99.txt. The -O option tells the system to store the ‘c99.txt’ to ‘shell.php’. If the attack was successful, the file ‘shell.php’ should now available available in the same location where the LFI vulnerable file is located.

On older systems, the same attack could be done using the file ‘/proc/self/environ’, thus without using the log files. However, on newer systems the file ‘/proc/self/environ’ is set to read only for the user ‘root’ and because of that no longer can’t be used in this attack.

Counter measurements
First things first, the application should always be the first step to prevent Local File Inclusions, which is described here. However, as a defence in depth, the following items should be considered:

1. Harden PHP, especially disable the commands ‘exec’ and ‘system’, these are considered dangerous and should be avoided.

2. Rename ‘wget’ to something only you as a system administrator know.

Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Email this to someonePin on Pinterest0Share on Reddit0Digg thisShare on Tumblr0Share on Yummly0Share on StumbleUpon0Flattr the author