11

So our website was hacked, and these are the things that were done:

  1. Some entries in the database were changed. I don't know if this was via SQL injection, or direct database access (only root is allowed to make database changes, is it possible to emulate root or obtain its password?) or through the CMS of the website. My guess is that it was through the CMS.

  2. The code of the index page was changed to some dramatic declaration of hacking success on the part of the hacker.

I just got a free scan done from Qualys (https://freescan.qualys.com/freescan-front/module/freescan/#scan_report?id=39003&) which says that SSL Server Allows Anonymous Authentication Vulnerability. This is probably true because whenever I log in to FTP, it tells me that some certificate isn't valid, but I always just ignore and hit "Continue". I'm using a VPS (not shared) account on my hosting company's server.

What are the first things I should look to fix?

Edit #1

I just found some weird files added on the server, including a "wso.php" which appeared to be accessing cookies and other things with system passwords. Then in the public_html folder I found a new folder I hadn't seen before, called sym, and when i opened it, lo and behold it had a folder called root which was basically a recursive clone of my entire root folder, and next to it an .htaccess which said the following:

 Options all 
 DirectoryIndex Sux.html 
 AddType text/plain .php 
 AddHandler server-parsed .php 
 AddType text/plain .html 
 AddHandler txt .html 
 Require None 
 Satisfy Any

I have a few questions -

  • Does that give any more hints on what kind of attack this was?
  • Are these "evil" .htaccess contents?
  • One of the files was boy.php.jpg. Given that one of the site's forms allows users to upload images, stores their file paths, and then through a DB-backed CMS accesses those uploaded images, could this have been a SQL injection where a malicious file dressed as an image was uploaded and then accessed as regular page content?

My company's annoyed by the hack but I have to admit I'm a tad excited about this mystery! (a total newbie at security as you can probably tell)

Edit #2

Yet another update. I discovered this page: http://dealshop.cc/a7a/

What is this and any idea how it works? My website is one of the ones listed, so maybe the shell was "uploaded" as a jpg file?

Edit #3

For some reason it didn't occur to me to mention this earlier, but my MySQL database has been hacked - when I browse tables through phpMyAdmin, some of the ID columns of some tables are full of lines like cat /etc/pwd and +response.write(9062801*9462776)+. Does this mean that the entry point was definitely a SQL injection?

3
  • One of the files was boy.php.jpg. Given that one of the site's forms allows users to upload images I think that pretty much answers it.
    – Alex
    May 14, 2013 at 15:59
  • @Alex I don't understand how a .php.jpg file can cause vulnerabilities. The system should recognize such file as .jpg?
    – owls
    May 15, 2013 at 14:08
  • I think modified .htaccess code can make images executable.
    – user961627
    May 15, 2013 at 15:13

3 Answers 3

13
  • Get a known clean version of your site and identify the differences between the known good code the and current (hacked) production code. Study how the changes may have been made and repair.
  • Update the passwords.
  • Fix the FTP certificate issue - consider using 2 factor authentication.
  • Find a way to scan your code for vulnerabilities - peer review or automated analysis.
  • Enable logging so if this happens again you have log files. If you already have decent logging, look at the files accessed and see if there's injection via the URL.
  • Consider using a web application firewall.
  • Tell your legal department, the police, partners, customers if you believe their data to have been stolen or compromised
5
  • could you please recommend a "web application firewall"? I'm aware of general system firewalls, but web application firewall?
    – user961627
    May 14, 2013 at 9:21
  • 3
    mod_security for Apache is pretty decent.
    – Polynomial
    May 14, 2013 at 9:41
  • +1 for modsecurity / there are plenty available. The main thing is to pre-empt issues by coding securely as much as possible.
    – AndyMac
    May 14, 2013 at 10:01
  • i just editted the question, i found some horrible mutations on my file system. i don't think this could just be a sql injection.
    – user961627
    May 14, 2013 at 15:12
  • 1
    Here's a howTo for the wso.php shell hack : youtube.com/watch?v=gkoWtHZDV3M and for the follow on attack: securitygeeks.net/2012/08/symlink-tutorial.html
    – AndyMac
    May 14, 2013 at 15:45
12

If the only user on the database that can change records is root and your CMS uses the root user to perform queries then you have a problem. Your root user should never be used by a website.

  • Get a limited user which can only access the tables and records he needs to access restricted with the right permissions. If he doesn't need delete or update, then don't give that access. This is known as the least privilege principle:

In information security, computer science, and other fields, the principle of least privilege (also known as the principle of minimal privilege or the principle of least authority) requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user or a program depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.

  • Also check that anonymous users are not allowed to log into your FTP server, make sure you change your ftp configuration. To prevent clear text communications, avoid TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA, as these two cipher suites have 0 Symmetric Key Strength.
  • Also get a remote syslog server so you can at least see the requests made and find out what happened.
  • Get a webapplication firewall
  • Install a HIDS on your server like OSSEC which will block users and alert you when an attempt to break into your server was discovered.
  • Might want to file a formal complaint with the Police.

And most importantly:

Nuke it from orbit, it's the only way to be sure: restore your machine from a backup, it's been compromized it cannot be trusted anymore.

16
  • Thanks. Like the answer above, you too recommended a web application firewall. Could you please recommend a few if you know of any? I'm aware of general system firewalls, but web application firewall?
    – user961627
    May 14, 2013 at 9:21
  • If you are using Apache you should start with modsecurity.org May 14, 2013 at 9:24
  • @user961627 Imperva offer a WAF which is quite effective in my testing, Trustwave (SpiderLabs) offers ModSecurity. Both of them are fairly good. See here for more: owasp.org/index.php/Web_Application_Firewall
    – NULLZ
    May 14, 2013 at 9:25
  • @D3C4FF thanks - I'm looking into ModSecurity - but their support is $2000! do you u have any idea as to whether it's worth buying the rules ($200) without the support? is it cryptic or a standard kind of thing that could be set up by a professional web developer? Is it hard to get by without support?
    – user961627
    May 14, 2013 at 12:51
  • @user961627 there's also CloudFlare which acts as a WAF and also assists in mitigating DDoS attacks, worth checking out. As for ModSecurity, there are plenty of resources online about it, but you get what you pay for, if its a business critical app and it goes down, there's no guarantee someone online can/will help, likewise, if you deploy a complex solution and run into trouble it may be an issue. Plenty of doco available here: github.com/SpiderLabs/ModSecurity/wiki/…
    – NULLZ
    May 14, 2013 at 12:54
5

This is most likely a PHP LFI (Local File Inclusion) attack. The .php.jpg "photo" actually contains valid PHP code that is then parsed by some other script on your site which is vulnerable to LFI.

The other files you found were dropped post-exploitation after the LFI vulnerability was exploited.

You can post the boy.php.jpg for further analysis. Host it somewhere else in it's raw form when posting a link to it as this site may modify images posted and the attack strings are probably in EXIF data which may get stripped.

Recommend auditing your .PHP code and PHP deployment configuration for vulnerabilities. While a "web application firewall" is a good measure, it does not replace the need to audit your code for security flaws.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .