Knowing what you don’t know. Some lessons learned from Equifax and WannaCry.

It seems like we’re seeing report after report in the news about so-called ‘cyber attacks’ in organizations that, it seems, should have known better or done a better job at protecting themselves (and our data). What didn’t they know that led to the attack (and subsequent breach)? What could they have done to have prevented the breach? We’ll look at these questions in the context of two recent breaches and provide some ways for you to protect your organization from similar attacks.

The Equifax breach

In May of 2017, an unknown attacker used a vulnerability in web server software at Equifax to gain access to records for approximately 144 million people.  The attacker had unfettered access to the system from approximately May 2017 through June of 2017 when the breach was discovered.  It’s worth noting that, even after the initial massive breach was discovered (and disclosed), security researchers found that Equifax was still using the username / password “admin / admin” on an Argentine website.

  • What didn’t they know that led to the attack (and subsequent breach)?  There’s a lot of speculation about what the initial attack vector was (what vulnerability was used first) and when Equifax was made aware of the vulnerability but it’s also important to recall that, even after the breach and disclosure and fallout, it was discovered that Equifax was still using the username / password of “admin / admin” on an administrative portal on it’s Argentine website.  With that in mind, the things that Equifax didn’t know that led to the attack is twofold;  they didn’t know that they were running vulnerable software on an Internet facing system AND they didn’t know that they were using default credentials on the administrative portal on an Internet facing system.
  • What could they have done to have prevented the breach?  Patching the vulnerable software and updating the credentials on the administrative portal.  A key to both of these would have been an independent audit (whether by an outside party or an internal security team that *WAS NOT* the same team as those tasked with configuring / securing the systems to begin with) to identify the vulnerabilities and report them to the appropriate teams before they were / could be leveraged by a malicious third party.  This is certainly not a comprehensive list, things like internal processes for setting [non-default] passwords, proper segmentation, etc. would also be a part of a good comprehensive information security strategy.

The WannaCry outbreak (and NotPetya, a month later)

 In May of 2017, the WannaCry ransomware was launched and used a tool called ETERNALBLUE to exploit vulnerable systems, encrypting the data on those systems and demanding a ransom for the decryption key.  The vulnerability was in a protocol used in Windows to share files on a local area network (LAN) and was patched by Microsoft in February (2 months prior to the attack).  The WannaCry attack was reported to have infected more than 230,000 computers in over 150 countries within days. It’s worth noting that a Honda manufacturing plant in Japan was infected with the WannaCry malware in June, a full month after the initial WannaCry outbreak (and 4 months after the patch had been released).

  • What didn’t they know that led to the attack (and subsequent breach)?  The WannaCry ransomware exploited a protocol that’s a) very old (SMB v1 was targeted, SMB v2 was released in 2006 and SMB v3.0 was released with Windows 8 and Windows Server 2012) and b) intended for use on internal networks and not the Internet.  Based on these two things, victims of the WannaCry breach didn’t know that a) they still had SMB v1 running on their systems or b) that those systems were exposed to the Internet.
  • What could they have done to have prevented the breach?  The spread of the WannaCry ransomware depended on two things, access to the system and an unpatched version of SMB on that system.  While installing manufacturer updates in a timely manner is important, knowing what you have exposed [either to the Internet or to less-trusted internal networks / segments] is also important.  An independent audit of both internal and external systems would have identified which of those systems were exposing SMB and that those systems were vulnerable to the ETERNALBLUE exploit.  Using that knowledge to close off access to SMB and / or install the update would have protected victims from the WannaCry ransomware.

How can you use this information to protect your organization?

Although the Equifax breach and WannaCry outbreak were very different attacks (the Equifax compromised the integrity of sensitive information and the WannaCry outbreak compromised the availability of data), the mitigation for the two is very similar.  In both cases, the targets a) didn’t know that their systems were vulnerable and b) hadn’t applied updates to those vulnerable systems in a timely manner.

  • Document your environment (establish a baseline) and perform regular tests to confirm that the reality of what is on your network matches the record of what is on your network (gap analysis).  While it is possible for internal teams to do these tests, we recommend having an independent third party do a vulnerability assessment or penetration test (depending on the environment) at least annually.
  • Develop a patch management process and incorporate that process into your existing information security strategy.  Both the Equifax breach and the WannaCry ransomware outbreak were possible because manufacturer supplied updates were not applied to vulnerable systems.

Piratica offers a full suite of services ranging from simple vulnerability scans to vulnerability assessments and penetration testing.  If your company or organization would like more information about the services that we provide or if you would like a free vulnerability scan of your organization, please contact us.

Misc / Erratta

Leave a Reply