In the United States, we got lucky, very lucky, that a malware researcher known only as @MalwareTechBlog on Twitter found the “kill switch” domain in the code of the WannaCry ransomware. Had he not found and purchased this domain, effectively neutering the ransomware, I believe that the incident could have been much worse. It was already quite bad around the world with estimates of over 200,000 systems infected including many healthcare providers in the United Kingdom.
The WannaCry incident has created a lot of buzz about ransomware right now, and in particular, there is still a significant row going on in the media, boardrooms, coffee shops, and just about everywhere else. I suppose my best bet would be just to let the media handle this one and not try and discuss it. But, I can’t resist the deeper discussion that this incident brings to the surface. This incident is indicative of a much more profound and hard to fix issue, one that affects far too many organizations worldwide.
Brief Overview of WannaCry
This blog is not meant to be a technical or all-inclusive breakdown of the WannaCry Ransomware, just a refresher. I am confident that anyone reading this has at least some knowledge of what happened in the second week of May 2017. But, just to ensure we are all on the same page: a group of criminals released a new strain of malware that included a very powerful worm based on stolen 0day exploit reportedly sourced from the NSA and a ransomware component that encrypted files on any infected computer. As of now, reports say there were over 250,000 systems infected in over 150 countries. For more detailed information I recommend reading this blog from @blackroomsec for a less technical overview of the incident and how to better protect yourself, or this much more technical write-up from Talos Security.
Why Was WannaCry So Effective?
The WannaCry (aka WanaCrypt0r) ransomware utilized a recently patched vulnerability that Microsoft has dubbed MS17-010 to propagate their malicious code. This vulnerability allows an attacker to take control of an unpatched system remotely. The important factor is not exactly how the exploit worked; it is that there had been a vendor-provided patch for two months when this happened.
Look at any of the breach reports released for 2016, or any statistics around causes for breaches. It will be quickly evident that one of two things directly cause a significant number: known vulnerabilities and taking advantage of people and their trusting human nature. One of these is something that we can quantitatively fix, and the other is something we, as an industry, could do a whole lot better on.
Stuff We Know How to Fix
The worst, in my opinion at least, is known vulnerabilities that cause a breach. These are issues that the software makers have been made aware of or found. These vendors then released patches for these vulnerabilities to all of their customers, along with alerts, as quickly as they possibly could. Unfortunately, especially in enterprises, this patch is not automatically applied, and things move slowly through testing and approval processes before it is installed. All too often systems are left unpatched for months, or even years, after the release of the fix making it all too easy for attackers (and white hat hackers) to get into your networks.
According to Verizon’s Data Breach Investigation Report (DBIR), the top 10 known vulnerabilities accounted for 85 percent of successful exploits. I and the pen testers I work with can vouch that this statistic is all too accurate. Until about a year ago I was able to find a system vulnerable to MS08-067 in almost every single network I got to do a pen test assessment for. You can read the details of this vulnerability in Microsoft’s bulletin linked here. The key here is that until sometime in mid-2016 we were regularly compromising networks using an exploit that was patched in October of 2008.
I have no doubt, and I am sure that my fellow hackers would agree, that we will own networks for the next several years using the MS17-010. As will the bad guys.
Briefly on the People That Use the Systems
Humans are, by their nature, social creatures. Meaning that we, for the most part, like interacting with others and are quick to help others when they seek it. This is not an entirely unselfish act – we want to feel useful, and it feels good to help someone. Both of the last two statements are generally true, and also just the tip of a deep psychological and sociological iceberg that merits blog posts alone, or maybe something a lot longer. But, we have to approach our workers, the users of the systems, in a different way. We need to humanize security, teach, support, and protect these users by better educating them. There are a lot of things we can do to make users more security aware, and I will certainly go into it more in the future.
For now, remember that your users are people that don’t want to get scammed by a phishing email or lose their files to a ransomware infection. We have to use this as a guide to help develop more meaningful awareness training. As far as patching cycles go, we have a lot of work to do, but all we can do is try to make it better, and there is no better time to ask for the time and money needed than right after a large, newsworthy incident like WannaCry.