If you have anything hosted on the ‘net, I’m sure you can appreciate that’s a pretty bad scanario for most personal sites. On sites that sell things, use credit cards or have usernames and passwords, it’s not just bad, it’s scary.
So, what do you do when someone else 0wnz your site?
First, clean out the closet.
There’s two main methods of attack; the highly skilled, custom attack, and the the “script kiddie” attack.
The first consists of people trying to actively break software by sending it more data than it can handle (known as a “buffer overflow” attack), sending it bad or malformed data or injecting invalid instructions (which could manifest in an application crash or databases being wiped). As mentioned, these are generally found by highly skilled people that are capable of leaving little or no trace of their actions. Depending on their motives, the exploit found will either be used to break into things, or be reported to the vendor so we can all benefit from the security fixes.
The second type of attack requires less skill, and usually involves pre-packaged exploitation tools created by the first kind of attack. These exploit kits are usually easy to spot as you will see a number of invalid requests in rapid succession in your application logs, trying to get a webserver to do something stupid (like trying to run the Windows command shell on a Unix/Apache webserver).
In either case, preservation of the environment is important if you can learn from it later. Back it up and put it somewhere safe where it can do no damage, such as within a virtual machine or a development server physically disconnected from the rest of the network.
Second, nuke the entire site from orbit. It’s the only way to be sure.
Yup – you don’t really have a choice here. You need to consider the entirety of the site compromised and nuke it. Nuke it all.
PHP files, .Net code, html, images, you name it.
You can’t trust any of it.
Third, we can rebuild it. We have the technology.
Now, this is where it gets interesting.
If you’re using a content management system of some sort (of which, most e-commerce and blogging software fits in nicely), “rebuilding” a site is pretty simple as most of the site’s content and configuration live inside a database.
Rebuilding involves deploying the latest version of all web software, plugins and utilities, freshly downloaded from the vendor or open source project’s site, and using a new, blank database; the catch to this is you will need to migrate over the content by hand. To speed things up, you could dump the old database, sanitise it’s contents, and reload to the new location or reload a database dump from before the site compromise occurred (assuming you can nail that down when that happened). Migrating and sanitising the database does require some skill and knowledge of how the application uses the database; if you don’t know, now’s the time to find make friends with a friendly DBA or group that provides support (commercial or otherwise) for your chosen content management system application.
Note that the break in I described at the top ended up with content being injected via the CMS’ template files; redeploying and re-customising a fresh copy of your template may be a good idea if you’re not familiar with looking through them for strange web requests.
I mentioned nuking the images (and other data-type files, like MP3′s and Word docs); again, if you have a backup from before the compromise, you should be able to use that to help get you back up and running quicker. If not, the images and the like are probably ok to reuse, however I would recommend virus scanning them as there are exploits in the wild capable of infecting a machine by viewing an image file. Again, with good backups, you can make it easier.
It’s hard and it takes a lot of work to properly clean up a site. It is the only safe manner to bring it back up, though.
Fourth, those passwords are no longer yours. Get yourself some new ones.
Someone else likely knows your password.
They can do things you probably don’t want them doing.
Now you have to think of a bunch of long, good, solid, random passwords start changing any password related to the site as well as anywhere else where you use the same username/password.
Again, it’s the only way to be sure.
Finally, try to make it so it doesn’t happen again.
Work on the least bit principle – if you don’t need a feature, don’t install it.
Work on the least privilege principle – disable permissions until you break the app, then slowly grant more until it works again. 1
Service accounts and sudo are great – service accounts mean you can create application-specific accounts with massive nasty passwords; sudo means you almost never need to know ‘em for day-to-day maintenance.
Look into an automated configuration control / file verification system, or hand rolling some form of md5/sha1 digesting of files to look for files that have changed that you don’t know about.
… the Interwebs are a scary place. Do you know where your backups are?
- Ideally, you’d start off with no permissions, but that can take time; make you you budget extra time to do it properly. Remember, most applications don’t need write access to their whole tree; applying write access to their “uploads” directory may be enough. [↩]