From web app LFI to shell spawn

Web application LFI (Local File Inclusion) vulnerabilities are regularly underestimated both by penetration testers and developers. Despite the main threat of exposing critical system information contained at core files (such as “/etc/passwd“, “/boot.ini” and “/etc/issue“), LFI vulnerabilities may cause bigger problems to the victim server. Based on the source code that introduces a LFI vulnerability and under certain server configuration scenarios, the attacker may be able to run server side code and establish a reverse connection or a pseudo-shell over HTTP with the victim server. During the rest of the article an LFI vulnerability on a known E-Commerce CMS will be examined in a try to execute server side code and spawn a reverse shell.

It is a common feature for web applications to implement file inclusion functionalities in order to dynamically change website’s content presented to users. The arguments to those file inclusion functions are regularly specified by the user under specially crafted parameters. LFI vulnerabilities are created due to improper input sanitization/validation for those user specified parameters.

File inclusion functions are implemented using either include (or require) directives or any of the available file handle functions (fread, file_get_contents etc.). In case of file handle functions there aren’t many things to do because every imported file is processed as string. Although if an include directive is used, it is possible to execute server side code contained in the imported file. For more details about PHP import directives, you can referrer to include and require PHP manuals.

The real challenge now is to find a way to store server side code into a file that is readable from the web service running user (www-data, wwwrun etc). This is not an easy task and might be even impossible under some server configuration setups.

In this article two main methods are examined: 1) Web log poison and 2) World readable file upload (via anonymous FTP).

For the article purposes a Debian pwnbox VM has been established implementing a vulnerable version of the osCSS2 E-Commerce CMS. The target web application was a random selection from the exploit-db archive. The vulnerable osCSS2 version and the LFI vulnerability details are available here. The CMS is written in PHP and is served from a running Apache web service. Consequently the following analysis focus on PHP + Apache system setup.

1) Web log poison

Web log poison technique is effective when web service’s log files are readable by the user that PHP (or any other server side code) is running. Usually sysadmins choose the performance optimized (and easy to implement) way to run PHP as an Apache module. Consequently PHP is running under Apache user. Usually the default Apache setups limit the access to web logs only to root and administrator users and groups making the logs unaccessible for the web service user. Although, there exist many shared host services and misconfigured systems that serve readable web logs.

To confirm that web logs are readable, the target server must be initially enumerated in order to locate the correct paths. In this case study the target system is known to be a Debian setup, so the web log paths are known too. For verification purposes GET requests can be executed to confirm read access.

Many of you might wonder at this point why web logs are so important in LFI exploitation. The answer is pretty clear. Web logs’ content is defined mainly by the user interaction with the server. Web logs store user information, such as source IP, requested web path, refer URL, user agent, cookies etc. Let’s take for example the user agent field which stores information about the user’s broswer and system. If the attacker changes the default string used by the broswing application to a valid PHP code, this code will be stored in the Apache access log. Then by including the access log using the LFI vulnerability the PHP code is executed at the server side.

In the following example the curl tool is used to poison the logs with PHP code (just calling the phpinfo() function). Instead of curl you can use famous plugins/addons for your web broswer or a third proxy tool (such as ZAP or Burp).

Knowing now how server side code can be executed, a PHP system function can used to call external programs and spawn the reverse shell.

2) File upload via anonymous FTP

During the target enumeration phase, service scanning has revealed a running ProFTPD service at port 21 allowing anonymous FTP logins with file upload permissions. By digging into application’s packages and default configurations, pentesters can gather useful information about possible system setups. Following this approach and with some experiments the store path for the uploaded files can be discovered. For the following case study, the anonymous file upload path is ‘/home/ftp‘.

Initially the file containing the PHP code for the reverse connection is uploaded to the target server.

After successfully enumerating the path for the anonymous FTP uploads, the ‘backdoor.php‘ file is included spawning the reverse shell.

The above two methods are a small sample of the available techniques for storing tiny server side code chunks to readable files in the remote server. After detail enumeration of the target system, penetration testers can discover various other possible store points such as log files from third applications.

The system and service enumeration process is vital for the attacks success. Penetration testers must carefully search for various existing protection directives/configurations (such as PHP open_basedir config) that might block such an attack.

DISCLAIMER:I’m not responsible with what you do with this info. This information is for educational purposes only.

A. Bechtsoudis