Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
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 '13 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 '13 at 14:08
    
I think modified .htaccess code can make images executable. –  user961627 May 15 '13 at 15:13
add comment

3 Answers

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.

share|improve this answer
    
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 '13 at 9:21
    
If you are using Apache you should start with modsecurity.org –  Lucas Kauffman May 14 '13 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 '13 at 9:25
1  
+1 for Ripley Doctrine. –  anaximander May 14 '13 at 12:08
    
@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 '13 at 12:51
show 12 more comments
  • 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
share|improve this answer
    
could you please recommend a "web application firewall"? I'm aware of general system firewalls, but web application firewall? –  user961627 May 14 '13 at 9:21
3  
mod_security for Apache is pretty decent. –  Polynomial May 14 '13 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 '13 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 '13 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 '13 at 15:45
show 1 more comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.