6

Due to a vulnerability in how PHP was installed (Shared VPS with PHP installed as an Apache module instead of CGI) and hence how OSCommerce was configured (with security of 777 on certain directories), I found a number of PHP scripts on a friends webserver which had been loaded by hackers. The actual code was hidden using several layers of encryption. They had a PHP file with a huge string assigned to a variable $str. Then they used the following line to decrypt the string into malicious PHP code and attempted to run it by visiting the page. The statement used to decrypt the encoded string was eval(gzinflate(str_rot13(base64_decode($str))));

They can't run the code from this directory now because there's a .htaccess file preventing the execution of scripts from that folder which was put in place since we discovered the system had been compromised, this is a temporary fix but probably not the best one.

I ran this script on a linux vm running on my Mac while altering the statement above to echo(gzinflate(str_rot13(base64_decode($str)))); so that I could see the source code. I've put it up on pastebin for the interest of people here.

Pastebin of source for hacked page

From what I can gather, this seems to be a pretty sophisticated script which tries all sorts of tricks to gain access to your server but I'm not familiar enough with PHP to identify all the vulnerabilities this might attempt to exploit. What checks should I perform on my system if I can assume they managed to run this at some point in the past?

AviD
  • 72,138
  • 22
  • 136
  • 218
conorgriffin
  • 185
  • 7

3 Answers3

12

What was uploaded is a popular shell script - a common post exploitation method. The one you got seems like it is of the C99 variety.

In short, its a script that gives the attacker a control panel to your server, so that he can execute commands, download and install malicious things, find files with passwords, further infect the system, launch other attacks and other.

OsCommerce recently had a very severe RFI vulnerability allowing exactly these things to be uploaded, and that is probably how you got it - there are automated tools looking for the vulnerability and exploiting it.

Your system is no longer safe: The attacker might have downloaded rootkits or he may have created a second backdoor on your machine so deleteting the file won't suffice.

The ideal solution is to perform a full wipe and restore anything you want from backups - that is, if you trust your backups are clean.

If you can't do that, you have to do a full investigation of the server, but you can never be sure.

As for you question: There's no point enumerating the different attacks the script contains, as it provides basically a command line to your server and the attacker could run any command he wants or download any tools he needs. It just has some preconfigured functionality for his convenience.

john
  • 10,968
  • 1
  • 36
  • 43
5

Well worth looking at this question - What to do after suspected intrusion as there are a range of important issues depending on what you have on your server.

Unless you are an experienced professional, the single safest thing you can do is wipe the server and reinstall from clean install disks/source, and then reload data from backups after checking that they were made before the intrusion.

This is because the attacker could have escalated beyond just the commands you see in the sourcecode to pretty much do anything if they managed to gain root access, and the tools you have to spot intrusion may not pick up a cleverly implemented root kit.

If you have more time/expertise you could run it on a Virtual Machine in a restricted environment (to prevent it attacking anything else) and watch to see what it does. You will want extensive logging both on the VM and the network to help you identify activities. This is often much more effort than it is worth, unless you do it for your day job, and many organisations just go for the 'nuke from orbit' approach and assume everything may have been compromised.

Community
  • 1
Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
1

Actually the types of code that is being executed in those types of shell code are more akin to file managers and there is little you can do to prevent their execution rather, you could try to prevent certain file types from being installed into image directories for example.

The point is to protect your site from allowing malicious code to be uploaded in the first place rather than prevent the execution of said files 'once' they are uploaded.

Out of date versions of osCommerce and its variants have known weaknesses in the admin login sequence which allow attackers to bypass the login authentication by merely appending the login.php to the end of any admin file: www.yoursite.com/admin/administrators.php/login.php for example will allow an attacker to see the contents of the administrators.php page.

This will allow an attacker full access to the osCommerce file manager and limited file editors within the admin section, and hence the shell code you found on your friends site.

There are two code changes that need to be made to the osCommerce code to actually patch this issue: 1/ patch admin login

2/ patch the $PHP_SELF code

It is also best to add htpasswd basic authentication to your admin directory as well.

Taipo
  • 189
  • 4