Quite unfortunately, one way that my company sometimes acquires new clients is after a hack when the client has searched out web developers or was recommended to us, badly in need of assistance.
Fixing web hacks is never fun. I mean, technically, it’s very interesting work, for sure. But, try telling a client that his or her site has been hacked and it’s going to cost quite a bit to return it to functionality, with no absolute guarantee that it can’t happen again, with the primary benefit of spending all of that money being that the site functions once again (i.e., no improvements), and with the potential for even more costs if the source of the hack is an important component of the site that needs to be replaced with something else.
How Hacking Happens (Usually)
Before we discuss fixing things, let’s try to understand how it happens in the first place. We can remove malicious files and/or repair hacked files or databases. But figuring out how the hackers got access in the first place is key to avoiding repeat visits from these people. Some of the ways sites can become vulnerable include:
- Outdated CMS installs. When Wordpress or Joomla releases even small updates, they publish a list of issues addressed in those updates. Quite often, if you read the notes, new releases include security-related patches. So, if you’re not current, you are likely hosting a site with a security vulnerability. As such, it’s paramount that you keep your site updated to the extent that you can. Put some thought into this earlier rather than later: How will you update your site? Do you need a development server to test updates on prior to updating production? Who will handle these? Will you always update right away or wait a while? What other extensions are you running that may be affected by an update, and how does that inform your strategy for updating? Are you aware of “core hacks” to your CMS install? All of these things (and more) need to be considered. But, if you’re running an old version, just know that there are usually ways hackers can determine what version you’re running; it’s not like you can just keep quiet and hope no one knows you’re not up to date.
- Vulnerable extensions. When you run Joomla or Wordpress or anything, you usually will build on top of that base system with whatever your site needs, right? Well, those things go out of date, too. Over time, people find security holes in them, and these become the target (aka the attack vector or means of access to the server). Similar to the description above, these things are fairly easily found by hackers. Personally, these are the types of hacks I find most. Usually, the extension has some exploit that allows a user to get an executable file (such as a PHP file) onto your server in a location that can be found and executed. Once this happens, the server is basically totally under the control of the hacker. Imagine that for a moment: If someone can place ONE php file on your server, then he or she can control effectively your entire server and database. The examples I’ve seen are pure evil, ranging from little scripts that connect to the DB and setup a site administrator to huge suites of tools packed into a single PHP file, all there to inflict crazy amounts of damage to a site.
- Vulnerable code. This is similar to the above, only the vulnerability is in a custom-coded feature rather than a formal extension. For example, say you have a form on your site with no incoming data validations. You could be vulnerable to SQL injection, file upload potential (as described above), or other types of exploits. I say other because there are some really high-tech types of vulnerabilities out there.
- Vulnerable server and security configurations. There are many ways to tighten up security to ward off would-be hackers and those sniffing around your server who shouldn’t be. For example, most CMSs have a distinct address for the administrative login. Trust me: Consultants laugh a little when clients provide the URL for the admin login page. We know it already, and so do the hackers out there — the latter being not so great. So, you can do things rather easily like lock that page down using add-on software tools. Get these tools onto your site! (They do more than the single example I’ve shared here.)
- Junk in the trunk. This is related to the previous item. What I see often (especially on sites developed by people still learning) are multiple instances of entire web sites cluttering a server. Quite often I see multiple CMSs installed on the same server, sites with huge directories of various backed-up files (including executables), and more. Here’s the thing: If any of that old code has vulnerabilities, then your server is still vulnerable. For example, if you have some PHP code in an old backup directory — say, code that allows a PHP file to be uploaded somehow — then that is one potential way into your server, which could in turn render the entire server vulnerable. See below for some examples of this.
- People formerly associated with your site who still technically have server access. For people with older sites, some of which have seen many developers come and go, the number of people with server and back-end access might be more than you think. Now, true, most developers wouldn’t dare hack a site. But, let’s just say that, for security purposes, it’s really a best practice to limit access to those who really need it. Even if you hire a consultant for a temporary fix to something, lock him or her out afterward! The next two items on the list will illustrate this problem, as well.
- Bad password policies. This one is such a big deal… I can’t tell you how many clients send me a site login that looks like: “Username — admin, Password — password.” I also get a lot of “p4ssw0rd” and “pa$$w0rd” and so forth. All of these seem clever, but aren’t. Hackers know about these little tricks. In fact, they have means of guessing and brute-force testing vast permutations that include all of the common types of passwords in use by a majority of people. So, don’t use “dog” or “cat” or your kid’s name, or your birth year, or add “123” to the end, or any of the usual things. (Read this article: Your Clever Password Tricks Aren’t Protecting You From Today’s Hackers for a longer analysis and suggestions for improving your passwords.)
- Someone’s email got hacked. This is another reason to (1) delete accounts and prevent access for old consultants and others with access to things, and (2) manage your passwords better. Part of that latter item is to NEVER send out passwords and usernames via email. Instead, send them via other means — over the phone, maybe via text, or my own favorite is via a utility site like dead drop. This way, there is no record of the username / password in your email or your contact’s, should either ever be compromised.
The above items cover most of the ways in which the hacking has occurred (if you’ve been hacked). But, if so, what now? Okay, that’s a little complicated, too. To make it easier, I’m breaking it into two possibilities.
The DIY Approach
If your site is hacked and you want to fix it yourself, the best way is to seek out a service that allows you to scan your site’s files. For sites based on open-source CMSs like Wordpress or Joomla, you’re in a bit of luck because the official versions of files all contain the exact same code from site to site. So, finding hacks is a matter of getting software to scan your site’s CMS code (often these are the files that are have been hacked) and then compare what’s there with what should be there. From there, you would obtain copies of the correct code and replace your corrupted code. Keep in mind, of course, that unless you block the vector (the way in), it could easily happen again. So, seek out a service that seems to know not only your CMS but also many of the most common plugins and extensions.
Most of these scan services will also employ additional searches throughout your file structure for (1) known hacks / exploits, (2) code that seems suspicious, and/or (3) various keywords or phrases associated with known hacks out there.
The Consultant Approach
This approach is generally the same as described above in the DIY section, only you’re hiring a consultant to do this for you. It really all depends on how comfortable you are with reviewing code, changing it where necessary, and navigating / changing files on your server.
In the end, there are other ways to be hacked than I’ve shared here, although the above broadly covers most cases. If your site becomes the target of someone capable and determined enough, it can become a battle to keep them away from your server
In any case, I would end this with two recommendations.
- First, review the bulleted list above and employ policies to avoid any of those circumstances that can create a vulnerability on your server.
- Second, be proactive about this stuff. While you might feel that you’ve got everything well covered, be sure to regularly backup your web site (and, store that backup off-site). It’s better to always backup and never need it than the reverse situation.