, , , , , , , , , , , ,

Admittedly I haven’t worked much with PHP beyond debugging large applications and configuration several years ago, but I’m hoping to outline some ways flaws are exploited to get malcode installed on a hosting platform.
This type of vulnerability I’m describing here allows PHP code to be uploaded to a server when it’s not supposed to be, and the code – which could be anything from a remote shell to a malware installer – would be executed alongside whatever platform is hosting the legit content. This kind of exploit is very common, and personally I’ve seen it happen most often to outdated versions of WordPress and its plugins. It also happened to the Python wiki not so long ago.

Uploading the Malcode
The simplest example of the vulnerability type discussed here is an online form for posting messages, pictures and other content without checking the input. If the code is purely functional, without extra stuff for input validation, it will allow practically anything. If a user manages to upload a .htaccess file to the target directory with ‘Options +ExecCGI‘ and ‘SetHandler cgi-script‘ entries added, the malicious code will execute, and the sysadmin wouldn’t know it’s there without using ‘ls -a‘, or routinely scanning through server logs for signs of this.
Thankfully common platforms are now developed in such a way as to sanitise text input and accept only certain file types.

But there are also ways around the basic checks, the most commonly known is to append another file extension, for example uploading ‘.htaccess’ as ‘textfile.txt’, or ‘script.php’ as ‘script.php.gif‘ to get the file accepted as a GIF. With older versions of IIS and ASP (c. 2009), this was possible by adding something like ‘;.jpg‘ after a malicious ASP page’s filename. From here it’s a matter of telling the server to execute the ‘GIF’ as a PHP script by adding ‘AddType application/x-httpd-php .gif‘ to .htaccess.

What if the platform detects the ‘GIF’ as a script? As it happens, there’s a place to hide code within an image – the comment field in the file’s metadata. This particular trick seems a fairly recent one, the earliest report I’ve found dating to 2007. It’s much harder to spot, and has the added bonus that users will download the image alongside everything else the browser needs to reconstruct the page.
We also need to add a halt_compiler(); function so the interpreter is only executing the commands in the file header and not the entire file.

The above is only a broad description of a vulnerability type that could be exploited any number of ways. The lesson for us here is developing reasonably secure code is tricky, and might not be optional where contracts, deadlines and budgets are involved. We must either anticipate all conceivable ways it could be exploited, or release the software and patch the code as needed over time. We might eventually end up with more validation and failsafes in a real-world program than functional code. It’s a constant cycle of exploit, patching and testing, and we’re all beta testers in a sense.

There’s a reason why web shells have become a huge problem – sites are a perfect vector for malware, especially if large numbers of people can be directed to them through dodgy emails.
The malware (like a banking Trojan!) would install itself on the client’s computer on visiting the site, perhaps through the browser’s Java plugin. This is the basic methodology I’ve seen in recent months:
* Acquire or develop malware.
* Set up C&C servers.
* Find sites with a common vulnerability.
* Get the web server to host/execute the file.
* Direct victims to the server directory hosting the malware
* Wait for the malware to install itself on the victim’s computer, and steal whatever data.