The latest malware to make the headlines is really interesting to me. It’s a ransomware worm called Petya. Ransomware is particularly interesting to me as a DBA, because DBAs are responsible for keeping data safe, and ransomware is specifically designed to destroy your data. I’m not a security expert, and I don’t even pretend I am–but security is something we should all be interested in.
Petya worms its way across networks, encrypting files both locally and on network shares. It infects other computers. What happens if one of those servers is a database server. Do you have backups? Sure, they’re on….a network share? Did that network share get pwned?
First off–no, I’m not. I have a personal story that I’ll write about soon. But let’s think of a worst-case scenario:
Everyone makes mistakes. Perhaps you opened an attachment you shouldn’t have. Or maybe you were the victim of a phishing attempt. Maybe it was a malicious, well-formed spear-phishing attack. However it happened, your machine is Patient Zero, and you are logged in. Do you have access to the network shares holding your backups? Do you have access to your database servers? Are you logged into your desktop using the same credentials as you use to access those shares/servers? If you use different credentials, did you save the password on your RDP connection?
Back to the headlines
Major multi-national companies are being slammed by this ransomware this week. Maersk (a conglomerate with $47 billion USD revenue) had a worldwide IT shutdown that brought employee desktops to a hault. WPP (a $15 billion USD marketing company on the FTSE 100) had to remove entire offices from their network to prevent the spread. These aren’t the only victims–there are many companies that have been hit by Petya.
I don’t know any of the details or specifics of how these companies were affected (or infected), but they are major companies that surely have their IT act together. Right?
What is Petya, anyway?
If these big multinational conglomerates are being hit, this is probably some zero-day exploit that caught them by surprise. The Microsoft Malware Protection Center blog has a great post about Petya. (At this point, I want to reiterate: I’m not security expert. )Once one machine is infected (perhaps via phishing), it worms its way across the network. That’s where things get interesting. How does it spread?
- EternalBlue/EternalRomance – ShadowBrokers released info on these exploits on April 14, and Microsoft issued patches on March 14….over three months ago. These are the same exact exploits that WannaCry used. Are all of your servers patched? Is there red tape tying up your patches?
- Credential dumping – Petya steals credentials from currently-logged-in sessions. There’s an assumption that if there are multiple logged in users, those same users might be logged in to other machines. How many servers are you logged in to? How many other DBAs are logged into those servers?
- Credential theft –Petya looks in the credential store for generic & RDP/Terminal Services credentials. Saved terminal services credentials are a goldmine, because you’re probably admin on that remote server. The credential theft is then exploited by using those credentials to access other devices and spread to those devices. Have you ever clicked the “Allow me to save credentials” button for a server you RDP into all the time?
If you follow best practices, you’ve got some protection against all three of those attack vectors:
- Patch, patch, patch – Always install Windows Updates. Even with lag for testing & approval, these SMB patches are three months old, and super high profile. Everyone should have them installed.
- Log out of servers when you’re done – Instead of just closing your RDP window & leaving your session active, you should log out. Better yet, don’t log into those servers in the first place. Use SSMS, PowerShell, and other management tools from your desktop instead of logging into servers.
- Don’t save credentials – Store complex passwords in a proper password vault (and don’t trust apps or the OS to do it for you). Type (or copy/paste from your vault) your password instead.
And let’s talk about other best practices that you may or may not be following:
- The credentials you use on your desktop shouldn’t be Admin on all your servers.
- Don’t use Admin credentials unless you need to.
- Avoid password reuse. Is your Gmail password also your work password? If it is, please change them both.
- Get your backups off-site, and on a different network. If your backups are in a different data center, but still accessible via an SMB share, ransomware like Petya and WannaCry could kill all your backups. Throwing a backups into Azure or AWS is cheap and easy.
Rules are meant to be broken
Best practices are just rules. Everyone knows rules are meant to be broken. Sometimes best practices are silly, or require extra work. That extra work might be worth it. Those rules exist for a reason. You need to understand why the rule exists before you break. There are loads of cases where best practices won’t be a good fit for you–and it’s OK to not follow them. Just make sure that your reason is based in reality, and you’ve got a good reason to do it. “It’s hard” is not a good reason.
A separate admin account might slow you down in an emergency…by 30 seconds? Does 30 seconds matter? Installing the latest Windows Updates quickly might mean your organization needs to test faster. Testing faster might mean you miss things. The faster patch cadence might mean a patch causes some other unintended outage of an application. Would your business rather have an application be offline for a day while you roll back a Windows Update, or would your business rather have their data disappear into the ether when it’s encrypted by malware?