I've always been a proponent of having just the most secure site that you can possibly make. And as such, I always take precautions to make sure of that and also, because I am just one man, things are going to happen. I track as many anomalies as I can, I ensure that all passwords are hashed, and if need be I block traffic coming from suspicious nodes, things that I think everyone should be doing to better secure their sites. But just recently, none of that mattered. No amount of secure code or configuration can fully protect your digital environment on a shared hosting server. Let me correct that phrase, on a Windows Shared Hosting environment.
My Hacked Server
Just recently a shared server that I use was compromised, and because the issue was on the server itself, and not in my code, there was very little that I could do to protect my website. Where the entry point is, is still a mystery to everyone on that server, but it could have definitely been any one of the 500 websites running on that server. Hundreds of websites. Somehow, the attacker was able to upload a script to each website in that server. Either through stolen server credentials, or possibly through some security configuration problem that allowed files to be written to multiple site directories. And that's one of the bigger problems with using shared servers. Not only are you limited in the number of server resources at your disposal, but you're also susceptible to any security flaws either in the overall system or in one of the hundreds of websites on that server. If a website gets DDOS'd, then so will you.
And because I took the opportunity to learn something about a hacked server, I tried to figure out exactly what happened, and the results are for sure educational, aggravating, and hopefully make for a good read.
The Hack - Backdoor
Based on my research on this attack, which essentially generated 2 classic ASP files to my server that did various things, which I'll go into further down below, the main cause was a backdoor created by a Chinese hacker that has been circulating the web for some time now. More than likely, most larger companies caught wind of that and took the proper steps to make sure they weren't affected.
Only a few of my websites were written using an older framework. And by older, I mean about 8 years old. But because I'm too lazy to take the time to update them, I left them as is. Unfortunately for me, those websites were configured to run classic ASP scripts. The remaining sites were not, and as such, the malicious bot wasn't injected into the directory. Lesson learned, always keep your frameworks updated.
Taking A Look At This Script
Getting hacked is a terrible thing and makes you feel uneasy and unsafe. Just like getting your identity stolen. But it also gives you an opportunity to learn a thing or two about the whole process. So I saved a copy of the ASP file over to my local for a quick peek, deleting the one on my server at the same time of course. And while I won't be showing that file, I'll talk about it for a bit, and about what it was doing when getting called.
It wasn't a very complex script by any means, and because it was a classic ASP exploit, the generated files were somewhat limited in what they could do. Needless to say what they did still wasn't very desirable. This particular bot file essentially hijacked all traffic coming from search engines, so if you landed on the page directly, you wouldn't notice a thing, and then it either redirected the user to their own page, of which I have not yet clicked on, and which I won't, or it rendered that host page directly on your server. Again, what that file does, no idea.
The only reason that I was to detect the hack was due to a mistake by the hacker. They updated the web.config file, in another attempt to redirect traffic to their website. The problem was that they updated the web.config with malformed content, and thus broke my website. Then in searching for the reason, I stumbled upon this most elaborate break-in.
The Safety Is Out Of My Hands
In the end, I informed the hosting company that their server was compromised, either due to a single site on the entire server, or probably some security misconfiguration. Raytheon offers a web security suite to companies for exactly this particular attack, which I linked the hosting company too. Unfortunately, but expectedly, I received a message from them a week later stating that I should "inspect my web pages more securely", whatever that means. More than likely, the support team didn't bother to even look at the issue, and they pasted a generic response. It's sad to see technology companies taking such a lax approach to security.
It's hard to complain though when I'm paying 6$ a month for the service. As much as I'd like to, you really do get what you pay for when it comes to shared hosting. But what I hope the take away is, is that regardless of how secure your website may be, if you're on a shared server there will always be a chance, that all your hard work will be left out in the open for any malicious person with the time on their hands to uncover.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date
Sign up for my FREE newsletter. Get informed of the latest happenings in the programming world.