Web Hosters are ideal Targets for Crypto-Ransom Attacks
Managed.com - previously known as PowerDnn - just got hit by a ransomware attack by REvil. According to sources they should have paid half a million USD in Crypo-Currency!
In these blog series I want to explain what that means and give you some best practices to protect yourself.
Please note that I don't know exactly how the attack on Managed.com ran, nor do I have websites hosted there that allow me to get more information from them. But I will assume they will try to cover up as much as possible - both for security and legal reasons, so we'll probably never know exactly what happened there.
The Business Side of a Ransom Cyber Attack
The idea behind every ransom is simple: Take away something important, and claim to only give it back if the real owner pays up. In terms of Website Hosting this means an attacker finds a way to do damage to a server system which the owner cannot usually fix without a big loss. So what's the big loss that would make people want to pay?
- Often restoring the system costs more than paying the ransom.
- Restoring the system would mean a downtime that is so long, that the business damage is huge. Managed.com and many of its customers were down for a few days - this is a hosters nightmare scenario. Within this time, you can easily lose half of your customers and maybe even have to pay damages if you have some guarantees in your contracts / SLAs. Managed claims a 99.999 Available Datacenter Update - this can get very expensive.
- Maybe restoring the system is almost impossible. Well crafted attacks often have more tricks up their sleeve.
- And maybe after the restore, you still cannot be sure it happens again...
How do these Cyber-Attacks Cripple the Servers?
The technical vector is to get a program to run on the web server with high privileges. And high doesn't mean Dnn-Super-User high, because that could only damage one website, I mean high like Windows-Server-Admin.
Once a program can run with these permissions, everything is possible. A simple attack would then encrypt the server and demand the ransom. But more advanced attacks would remain hidden, scan the internal network for more loopholes and gradually get more access until it can hijack the entire infrastructure.
I would guess that this is what happened with Managed.com.
Why is a Restore be Almost Impossible?
Attackers are usually very bright, and they have more experience in figuring this out than the hoster that just got hit. Here are some newer tricks making a clean restore almost impossible:
- Many attackers breach the system at some point in time and then wait. For a very long time. Maybe even six months or more, so that there is no recent log of the breach, making it difficult for the hoster to figure out how the attacker actually got in.
- The encryption mechanisms used are military-grade - there is no way to figure out the key yourself.
- Modern attacks often also target common backup infrastructure or Plesk dashboards. This means that often they have also scraped passwords and possibly made the backups unusable, unless you pay the ransom!
Yes, a DNN Hosting be Hijacked like this!
Any website today builds upon a stack of technologies - each one may have some loopholes in certain versions. DNN relies on Windows, IIS, .net Framework, JavaScript, HTTP and a lot more. Mabye there's also a Plesk and a Firewall involved, each piece of which again relies on a complex stack of technologies.
If a certain version of these components had a security issue this usually doesn't matter if everything else is rock-solid. But often a combination of such issues will suddenly open up something unexpected.
Let me give you an example of how a DNN hosting could be hijacked when combining a classic security loophole in .net and some bad configuration:
- Imagine the DNN site is running in IIS, and the person who set it up had difficulties, so they took a short-cut and just gave IIS a user identity that can easily access stuff. Let's assume it's not an server-admin-account, but something that can read/write most files on the system.
- Now imagine that we're running a DNN which has a security vulnerability that let's you upload files...
- ...combined with a .net bug, which let's you give the uploader a relative path - like "../../../../../windows/system32/..." - I think you can see where this is going...
- Now the attacker could just drop a file in the right place...
- ...and during the next system restart the code can take over the system.
This is just an example, but it shows a very real attack mechanism. We've actually tested this ourselves and were able to upload files outside of the website folder when IIS was using stupid user identities.
Why is Nobody Talking About Crypto-Attacks?
Most people that were hit by such an attack are afraid to talk about it publicly, because it could damage their reputation. In addition, many are afraid to publish best-practices, because it could give attackers hints how their system is set up (making them more vulnerable), and if the recommendations turn out to be stupid, it would again embarass the person publishing it. So people prefer to stay quiet.
Note that I've had a lot of discussions with other DNN professionals incl. people that were hit by ransomware, and many think it's a bad idea to publish hosting-recommendations, but I believe that the attackers learn much more quickly than we do, and are already 5 steps ahead. The only way we can keep is is to share our insights.
I'm going out on a limb here to give you some tips. My goal is that we as a community can publish rock-solid best-practices to get this done, and then provide a checklist for everybody to just do it right.
Tip #1: Never put Web-Files on Drive C?
As mentioned previously, many attacks rely on a combination of loopholes and mis-configurations. So a foundation of rock-solid hosting is: Don't be Stupid. And never assume, that any single part will be safe forever.
So the very foundation of the hosting must assume that other parts will fail. So anything you configure in IIS and Windows must assume that .net and DNN will have security holes, and still guarantee that Drive C ist never affected by anything that was uploaded.
One of the first things you must do at all cost is ensure that nothing runs on drive C. This sounds weird as a security recommendation, but hear me out. There are quite a lot of tricks to push files into a folder outside of the the website folder. They all rely on mechanisms giving a relative path like "../../../Program Files/..." but these tricks cannot change the drive the file will be stored in.
In certain scenarios (older versions, certain plugins etc.) this can also be done in DNN. And I'm convinced that even future version of DNN could be vulnerable, based on factors I cannot disclose. But simply ensuring that all the website files are on a different drive will prevent a whole plethora of possible attacks based on this trick. Please do this!
There are two ways of doing this, the simplest is to have a drive D or P or W or whatever and your risk profile drops dramatically. Another way is to put the web files on another server and using "//servername/share/website..." paths. This is how WebFarm setups are done.
Share Your Tips!
This was my first tip in this series, and I'll add some more in the days to come. Please also leave your tips below. I'll try to evaluate them and publish them, to then create a checklist with everything combined.
Love from the 2sxc team,
iJungleboy