Knowing how the vulnerability is exploited it was easy to perform some simple regex searches in the NIDS alert databases and web log servers in order to obtain data for my analysis. Input has been gathered from production web servers and NIDS sensors running on the academic network infrastructure at work. The analysis processed evidence data from the past three months (1st January 2012 – 28th March 2012).

The first stage was to enumerate the RFI URL paths involved in the exploitation attempts from infected hosts. Full URL list is available at the download section in the end of the post.

Continuing the analysis, the URL list was accessed by a crawling script in order to separate alive and dead links. The original Timthumb script makes a GET request to the given URL with empty User-Agent and Referrer URL header fields. To avoid any protection settings in the malicious server hosts, the crawl script uses the curl tool with the correct arguments simulating the exact same behavior of the Timthumb script. The script has been run from a honeypot node and the output is as following:

So 8 out of 28 URLs are still active containing Timthumb exploitation PHP code. For further inspection the PHP source codes have been downloaded locally. Blackhats behind the PHP sources have used known obfuscation methods (rot13, gunzip, base64 etc) to hide their code. Some of them made some really insane choices by looping obfuscation functions for even 50 times. Consequently some obfuscation unroll scripts have been written to reveal the original PHP code.

The following 5 web shells have been identified:

1. ANASKI PHP BOT Script  (1 hits)
2. r57 { KingDefacer 2.0.20 re-coded } (1 hits)
3. c99 { s4l1ty re-coded } (1 hits)
4. E-ZiNe Shell (2 hits)
5. Unknown (3 hits)

What surprised me was the functionality and appearance details in almost all the discovered web shells, resulting in big noise at various system and network logs. None of the web shells care to operate in a stealth way exposing itself instantly to a decent sysadmin who monitors the web server appropriately.

Conclusions

The analysis revealed 28% alive bot activity with ~3.000 exploit attempts regarding the Timthumb vulnerability from January 1st 2012 to March 28th 2012 in the academic network. Numbers indicate that after 8 months (vulnerability disclosured at August 3rd 2011) botnet operators are still seeking for vulnerable WordPress installations. Such a number possibly indicates that there are still many vulnerable setups out there.

Download Evidence

Be very careful while processing the following data as it might harm your systems if not used properly. Run your tests in virtual machines or sandbox environments and do not hit the malicious URL from critical source IP addresses.

• Timthumb RFI URL list – md5sum:b3712f4dbb3436b9dee91d447b46ad01
• Gathered web shells – md5sum:497bb086749ddcec355886fe1888d0fe

PS: Local authority CERT has been informed about the occurred incidents.
PS2: Regularly updated list with all the gathered RFI URLs from monitor sensors is available here.

A. Bechtsoudis

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