PHP injection attacks have become increasingly popular lately. If you look at your web server logs I’m pretty sure that you will find dozens of requests for PHP injection, usually by bots that are simply trying some well known (and less known) vulnerabilities.

One of our readers, Blake, managed to capture some interesting attempts to exploit various PHP injection vulnerabilities on his web site, thanks to installation of mod_security. Contrary to popular PHP injection attempts, where the attacker tries to exploit a variable to get the PHP interpreter to retrieve a remote PHP script, Blake noticed that the attacker tried to exploit a vulnerability in a PHP script through POST request. The attacker submitted a malicious PHP script (with other data) hoping that the PHP interpreter will execute it – this vulnerability also exist, although not that common. Here is what the attack looked like in log files:

POST http://www.<hostname>.<somewhere>/calendar/admin/record_company.php/password_forgotten.php?action=insert HTTP/1.1
User-Agent: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/133.7 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4
Host: www.<hostname>.<somewhere>
Connection: Close
Content-Type: multipart/form-data; boundary=---------------------------phpsploit
Content-Length: 46266

The POST request contained, besides data needed by the main script, an (of course) obfuscated PHP script that the attacker tried to execute. The deobfuscation part is shown in the picture below where I beautified it a bit and cut the long eval string.

Now, the interesting part is that the script uses the User-Agent field as the deobfuscation key. If you carefully check the User-Agent shown in above you will see that, while it looks legitimate, it in fact isn’t – the combination of versions is not legitimate.

But that’s not all – the injected PHP script contains multiple eval() calls of which every one uses a different deobfuscation key. This allows the attacker to test only parts of the script and never reveal it’s true side unless the attack works – the part that I was able to deobfuscate is shown below and it just tries to connect to a well known (public and legitimate) IRC server. Very clever, especially if we know that PHP will nicely eat any “garbage” that it can’t parse so the attacker doesn’t have to worry about only one eval() call working.

This attack demonstrated how important it is to use all available protection layers – not only Blake’s scripts where not vulnerable, but he also ran mod_security which successfully blocked this attack and he was checking his logs, something that a lot of administrators underestimate.

What do your logs look like? If you find similar attacks or something else that looks interesting, let us know through our contact form available here.

--
Bojan
INFIGO IS