A friend of mine got hacked recently. Some charming person managed to upload a rogue file to his server and replaced some of the software executables he produces with versions containing trojans and viruses.

It seems there's not a lot of information available that describes just what is possible from an uploaded file vulnerability. So I grabbed a copy of 'c99madshell', which is one of the more popular scripts used by script kiddies, and had a look at what it can do. Here's what I found...

Lots of websites allow people to upload files. Images are probably most common, be they to photo sites, or avatar images as part of a profile, or whatever. Some business sites allow uploads of reports or spreadsheets or other documents mobile employees need to share. Such files need to be treated with care by the server; they should be examined to ensure they are what they say they are - a JPG file should contain an image for example - and they shouldn't be allowed to have a filename extension that will have the webserver treat them in a special way.

The big worry for file upload scenarios is that the file uploaded ends up inside the website document tree with a file extension that will have the webserver execute it as a script. That is, someone uploads a PHP, ASP, Perl, or whatever file, then requests it back. If the server treats this file as a script it can execute, the attacker has a method of doing "stuff" on the server.

What sort of "stuff"? How much damage can a single script do? Let's have a look.

c99madshell is a single PHP script, which you can find if you Google for it. I'm not going to provide a link here, nor actively encourage anyone to go and download and run it. It arrives as a zipped and base64 encoded stream, and contains a wrapper to unpack itself when it gets called. In fact, there are 10 levels of zip/base64 wrapping the actual script, a precaution presumably made by the writer to prevent the script being spotted by malware detection software.

To make the script active, its user - the system attacker - just needs to copy it somewhere where the webserver will serve it. An innocent user's public_html directory will do nicely. Once the attacker has found a way of getting into such a place he just needs to point his web browser at it. The server will run it and send its output to the attacker's browser. The output of the c99madshell script is a remarkably well featured control panel which the attacker can use to control the server the script is running on. Have a look at this screenshot:

You have to remember as you read this that PHP is a full featured scripting language which provides access to files, sockets, databases and all other system level resources. At the top of the screen we see evidence of this: the script has retrieved some information about the server system it's running on such as the host's server software and OS, the current working directory and the user the server software is running as. This being a SUSE box, my apache process is running as the 'wwwrun' user. This is an important point. This script is running as the 'wwwrun' user and is therefore able to do anything that user is allowed to do on the box. Given that my PHP Safe Mode is turned off (4th line down) that means it can run processes, view and change files, and all sorts of other things.

Below the header information we see a file browser, shown in the screen shot as viewing my MyPictures directory. There's a toolbar across the top, which provides the familiar Home, Back and Forwards commands (plus some others I'll get to in a moment), and below that there's the directory listing. Clicking on any directory in that list navigates through the directory structure exactly as you'd expect, and clicking on a file allows the user - an attacker remember - to examine the file's contents:

...or indeed edit it:

The script can navigate anywhere the 'wwwrun' user is allowed to go on the system. There's no chroot here, so navigation targets would include the /etc directory, the web server root files (and therefore all the web application source files), all the regular user's home directories, and so on. If the 'wwwrun' user can see the files, so now can the attacker. All with a point and click interface!

As well as a nice remote file browser, there are all sorts of other features available. The next one along on the toolbar is the Search feature:

This allows the attacker to find files on the system containing certain words. Passwords, credit card numbers, email addresses, and so on. It's like a wrapper around grep/xargs, but internally to the script it's implemented in pure PHP.

The tools feature is interesting:

I'm not entirely sure what this is meant to do, and it doesn't actually do anything because the script tries to go and download some extra code from a website that has been closed down. But it talks of opening ports, connections and data pipes. Sounds like it's opening a direct socket connection to the world...

The Proc table is a lot simpler:

This just shows the attacker the machine's process table. Note the Kill button on each line though - an attacker could still do some damage here.

I'm not sure what the FTP Brute forcer is up to. It seems to be an automated method of attempting to brute force the password of an FTP server. I don't run FTP so I wasn't able to investigate too far. The Sec page is another set of server information, including server hardware info and the /etc/passwd file (which for this screenshot I allowed to scroll off the bottom of the page!):

Then we get to the data manipulation stuff. Only MySQL is supported, but if that's the DB you use, the attacker will find support is good! The interface allows the attacker to see the databases on your server, then choose one and have a look at it:

Again, it's all point and click. Note the sub-menu across the top - there's whole lot more functionality in here than I can cover in this article. If the feature your attacker needs isn't in the c99madshell interface he can always resort to entering his own SQL queries:

Of course, the DB server will require a password, but that's not going to thwart anyone. Ultimately in any web application the web server will need access to the database and therefore will have the password stored somewhere. Remember that nice file browser I described above? The 'wwwrun' process will have access to the web application source files (otherwise it wouldn't be able to run them), and the DB password will be in there somewhere. The attacker will just need to find it (and he has that Search facility remember!).

The last item of interest on the c99madshell toolbar is the PHP code evaluator:

This is a useful little box where the attacker can write a bit of PHP code and have it executed there and then.

No shortage of features in this tool, then, but there's more. In the bottom half of the main screen there are a number of entry boxes that allow quick and easy execution of common tasks an attacker might want to do. The first one, for example, allows for the entry and execution of a regular Linux command:

For this example I just ran a 'ps' command, but I suspect a real attacker would be a lot more imaginative.

Next to that there's an option menu that contains a whole set of command tasks:

It'd be a shame for our attacker to have to find all the user's shell history files himself wouldn't it?

There's other stuff here too, including the ever useful file upload command. Obviously files can only be uploaded to areas where the 'wwwrun' user has write access, but since that likely includes lots of useful places, it's not that much of a restriction. Besides, given the power of a tool like c99madshell, it would be reasonably easy to grab a pre-written Linux root escalation exploit, upload it to /tmp, then run it. If the kernel hasn't been patched, the box is then owned... Which all brings me back to my friend's hacked server...

I suspect what happened was that the attacker Googled for the tell tale signs of an old, vulnerable version of the forum software package my friend used and had forgotten to update. Once my friend's website was identified, a pre-written exploit for the vulnerability was used to upload something like c99madshell to his server. From there it was trivial to grab a copy of his executable file, infect it, then upload it back to the server.

So what can a website admin do to mitigate use of such a tool? By far the most effective precaution is to ensure that anything uploaded is put out of the web server's document tree until it's been sanitised. If the sanitisation process is automated, it needs to be bulletproof. The easiest way to ensure that is for it to default to rejecting everything, and only allow things it is absolutely sure are safe.

Additionally you might ensure the the web server document directories and their contents are owned by a user other than the one the web server runs as. The server needs read permissions to those directories and file, but not write permissions. This prevents the files being modified (at least without additional privilege escalation).

Generally though, once this sort of malware is on your server, you've got a problem. So keep your software up to date and have audits done on the code you produce in house.