WannaCry, Party Like It’s 2003

Let’s take a moment to collect what we know about WannaCry (W32/WCry) and what we can learn from it.

When looked at from a technical perspective, WCry (in its two binary components) has the following properties.

  • Comprised of two Windows binaries.
    • mssecsvc.exe: a worm that handles spreading and drops the payload.
    • tasksche.exe: a ransomware trojan that is dropped by the worm.
  • The Windows binaries had some variants, but in limited number and no polymorphism was used.
  • Spreads over SMB port 445 using a vulnerability against MS17-010 that was publicly available at exploit-db[.]com.
    • Originally the exploit was sourced from NSA tools leaked by a group called “Shadow Brokers”.
    • The MS17-010 vulnerability was in all versions of Windows up to Windows Server 2016, so this attack affected more than just Windows XP. But XP/Server 2003 had no public updates available prior to May 14th.
  • Includes “kill switch” functionality by checking www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com which the WannaCry author(s) had not registered and thus could be used by @malwaretechblog, to halt its spread.
    • There have been seen some “hex-edit idiot” variants of WCry; people modifying the original malware with a file editor in hopes of disabling the kill switch or otherwise changing its functionality.
  • Scans local network and internet for new hosts to infect.
  • Despite the early reports of distribution over email, no-one has been able to confirm any other infection vector than SMB.

All in all, writing the above makes me feel like it’s 2003 rather than 2017. In a perfect world, this malware outbreak should not have been able to happen. And the fact that the outbreak wasn’t even worse is thanks to the diligence of IT admins everywhere applying patches and keeping up firewall configurations. Without their work the outbreak would have been far worse. For example, a low ball estimate for computers infected by the W32/Blaster worm was 8 million computers and could have been as high as 16 million.

With the exception of the ransomware payload, the worm is very similar to the W32/Blaster worm from 2003, which attacked a vulnerability in RPC/DCOM, but otherwise was very similar to WCry. All in all the attackers were not exactly super hackers. It is it rather obvious that the attackers did not know what they were dealing with when they created the worm, just used an exploit they found, and were not expecting this kind of massive distribution and attention. It feels like somebody using a sledgehammer for a fly swatter. It is very likely that the attackers are running for the hills right now, as law enforcement around the world are definitely going to coordinate to hunt them down.

The answer to why WCry’s outbreak was able to happen is most likely the same as why e-mail based attacks first died back in 2008-2010 and are now again a prevalent vector. Security systems that do not get challenged are not seen as critical and thus tend to atrophy. Major internet and local network worms have not been a problem for several years, and thus organizations have neglected firewall configuration maintenance. Also, often host firewall configuration is done lazily, SMB port 445 is needed as outbound from workstation to file server and often administrators allow it to be bi-directional just in case.

The initial run of WCry is now on the decline, but the vulnerable systems remain, so it is important to reflect back on the measures that killed past network worms over time.

And the most important thing that killed network worms was the host firewall configurations that were done according to recommended best practices.

Which shortly put are…

  • Workstations are not supposed to accept inbound traffic, except from administration workstations and the domain controller.
  • Servers are supposed to be servers and not to make outbound traffic to workstations or other servers, except where needed.

This means that workstations should have inbound ports 135, 137, 138, and 445 blocked from everything but sources that are supposed to use those services for maintenance purposes. And servers obviously need to have those ports open for which they need for providing service, but even as inbound traffic is allowed outbound should be blocked.

With this kind of configuration, even if there would be a host infected with a network worm, it is unable to infect other workstations, and even as it would be able to infect a server, this server cannot pass the infection back to other workstations. This configuration also makes it difficult for an APT attacker to do lateral movement, especially if you block Windows Remote management ports 5985 and 5986 from anything but administration workstations.

Of course there are special cases such as certain hospital MRI machines which have Windows XP which cannot be patched and is running SMB server for access to the MRI images. And as these systems cannot be touched, it is critical to make sure that every system that is allowed to connect to such a resource is well protected. If all systems that can connect to such an MRI device have been protected by their own firewalls, they cannot be infected by WCry or other copy-cat attacks, and thus cannot pass infection to a device that cannot be protected.



Articles with similar Tags