Over the weekend, my wife got a phone call from her parents telling her that her web site wasn’t working. When asked for clarification, her parents said that “Google has a big warning sign up where your site used to be.” Most of you already know what was going on: my wife’s site had been hacked. She called me to see what I could do to (cough) fix the problem.
What she didn’t know was that site hacks, while extremely common, aren’t necessarily easy to fix. Especially by me! For each hack, there are multiple phases of activity, each of which can be achieved via literally thousands of possible methods. Keeping track of them all is a job for which specialized technicians train their whole professional lives — so I hung up the phone and stuck my head into our Director of Network Compliance’s office.
“Hey, Mike,” I said. “I think my wife’s web site has been hacked.”
I was a bit disappointed by Mike’s I’m-not-surprised reaction — then again, he sees this stuff hundreds of times a day. But he was kind enough to spend a few minutes with me, explaining what might have happened, and how it fit in with well-understood patterns in hacking.
My wife’s site is a simple one — she’s a jazz singer, and it’s not much more than an interactive calling card, with a few photos, some audio files, and an out-of-date schedule of appearances. It took Mike all of two minutes to find out what had happened.
In my wife’s case, most of the pages in the site had been altered with the insertion of “iframe” HTML code, a very common exploit. A layman’s explanation of what iframe does is: it loads a second web page along with your primary page, sort of like the “picture-in-picture” feature of some televisions. In this case, the iframe page was being loaded with a visibility setting set to “invisible” — so though it was there, people surfing through the site weren’t seeing it. But the unwanted site was loading each time someone visited her site, and it was doing whatever it was designed to do, in the background.
Unfortunately, the site the iframe code was loading was defunct by the time we found it, so we don’t really know what it was originally trying to do. It could have been fairly benign, building black-hat search engine traffic numbers. On the other hand, it could have launched a mercilessly destructive cybervandal app; or it could have been designed to leave a keylogging app on visitors’ computers (in order to track and eventually steal, their passwords) — the list of things that the site being loaded in the iframe could have been doing was nearly endless.
Because Mike is a nice guy, and because this particular hack was pretty simple, he spent a few minutes removing all the offending code. When he was done, we sat down to talk about what had likely happened.
The first question I had was an obvious one: how did this code get in there? I had a hard time figuring out how somebody could get into a password-protected server on what I know is a totally secure network. Mike’s answer helped clarify things for me: “99.99 percent of the time, nobody hacks into your web site by gaining control of your server. Instead, they hack straight into your web site through a vulnerability in the code or by stealing your control panel password from somewhere else. In your wife’s case, the PC she used to build the site might have gotten hacked or infected by a virus; the hackers might have gotten in through long-outdated PC or website software, or poorly designed plug-ins; she might have logged into her site while connected to an unsecured wireless network, or while using a friend’s hacked PC — or somebody could have just been looking over her shoulder. Once they got her password, it was easy. ”
Thinking back, I remembered my wife complaining about her work laptop being infected with a virus, back in November of last year. Mike figured out that the last time the iframe code had been added was in May of 2013, but… could the two things still be related, despite the dates being so far apart?
Mike confirmed they could. In all likelihood, the site was probably being abused over and over again, with multiple exploits between 2012 and 2013. We decided to look through her bandwidth logs to confirm this theory. My wife said she hadn’t made any updates to her site since June of 2011, so there should have been no FTP activity after that point. But there was. In February, March and May, 2013, somebody had repeatedly accessed her site via FTP, and the graphs proved it. Creepy.
So: my wife’s site had been hacked. Her password was compromised, probably back in November, and the last exploit (seemingly one of many) took place a few months ago. What should we do now?
The very first thing we did was immediately change my wife’s control panel password. Doing so is absolutely your first order of business if you get hacked. We didn’t just change it to an easily memorable (and therefore hackable) replacement. Instead, we made sure the new password reflected proper security guidelines. Here are some guidelines we followed:
- Don’t use a variant of the same password, a password you’ve used before, or a password you’re using for something else. If our banking password had been the same as the one my wife used to administer her site, we could’ve been in a world of trouble. Different passwords for different sites. And that doesn’t mean “passwordinternet” and “passwordbank”!
- Change your passwords regularly. If my wife had followed this simple rule, the access the hackers gained in November of last year might have been worthless shortly thereafter.
- Use a crazy, nonsensical string of characters, numbers and punctuation marks — upper and lower case — for your passwords. Goodbye, “jazz2011,” hello “gHHiTz2*676_4iUDesw&^kk”!
- If the idea of having to remember, and periodically change, 30 different crazy passwords makes your head explode, sign up for a password storage system. Many ServInt techs swear by 1password and lastpass. We signed up for 1password, and we love it.
Once the immediate cause for the site’s appropriation was addressed, I turned my attention to the issue of actually fixing my wife’s broken site. The malware had to be removed — but how? I was lucky, the damage was minimal (only a handful of files has been modified), and I had a friend who could find and remove the malicious code for me. For most everybody else, professional help is required.
This is an important point: web hosting companies don’t assume responsibility for fixing security breaches on individual web sites. They simply can’t. They happen far too often, and with literally millions (at some companies, billions) of sites at risk of exposure, offering personalized malware removal services is just not possible. But that doesn’t necessarily mean you have to hire a malware expert when disaster strikes. Automated malware detection and removal services do exist, and ServInt offers one of the best: StopTheHacker.
What “STH” does is basically what Mike did for me, at the push of a button — but, very importantly, it also a.) brings site design vulnerabilities to your attention so you can help prevent a hack; and b.) notifies you immediately if your site ends up on a Google blacklist — so you don’t have to count on your in-laws (or angry customers) being the first to know. I don’t have the space here to go into all of STH’s many features in detail, but you’ll find much more here. If you are a ServInt customer, I cannot urge you strongly enough to go get your free (yes, free, for one domain) STH account and start putting it to use. Visit your ServInt customer portal for more details or to sign up.
So what’s next on the to-do list after you’ve been hacked? Well, if for whatever reason you can’t fix the hack, your next best option is to simply restore your site from a back-up. And — this is critically important — don’t count on your host having a backup copy that will get you out of this jam. My wife’s experience shows why. In her case, her site was most recently hacked in May. ServInt, like most hosting companies, routinely keeps multiple copies of its customers’ sites — but they are almost never more than a month or two old. So if we had tried to restore from a backup, we would have been restoring a hacked site! Takeaway: supplement your host’s backups by keeping a set of your own as well, and keep a selection of them from various points in time.
One thing you might consider if you have a site that doesn’t require frequent content updates: turn off FTP. Turn it on only when you need it. Once hackers have acquired your password, they use your server’s FTP service to upload bad stuff.
Next up: if you’re running old versions of applications like WordPress, Joomla or other common content management systems, update them to the most current versions. The same goes for plug-ins, add-ons, widgets, themes, components and modules, which are more likely to be the vector for the exploit.
The servers on which your site is housed, and the data center where those servers live, are backed up by some of the most “Mission Impossible”-grade security you can imagine. In the physical world, your site’s weakest security link is the computer you use to manage it. So keep it clean and virus-free. Personal computing hardware hygiene is an entirely different topic, but there are countless web sites out there that can help you with best practices.
Okay — you’re using cryptic passwords, and you’re changing them often. You’ve either fixed or restored your site from a pre-hack backup. Your software is up to date, and you’re not swapping USB thumb drives with strangers anymore. Congratulations! This makes you far less likely to fall victim to a hack. Remember, however, that none of these steps make your site completely impregnable. Identity thieves, spammers, and other nefarious characters are always on the lookout for new ways to gain access to your site, from the technically miraculous to the downright mundane. By following these best practices, however, you stand a much better chance of staying one step ahead of the bad guys.
Photo by Dennis Skley