Tag: wanacrypt

INSIGHTS | May 16, 2017

#WannaCry: Examining Weaponized Malware

By Brad Hegrat

Attribution: You Keep Using That Word, I Do Not Think It Means What You Think It Means…

In internal discussions in virtual halls of IOActive this morning, there were many talks about the collective industry’s rush to blame or attribution over the recent WanaCry/WannaCrypt ransomware breakouts. Twitter was lit up on #Wannacry and #WannaCrypt and even Microsoft got into the action, stating, “We need governments to consider the damage to civilians that comes from hoarding these vulnerabilities and the use of these exploits.”

Opinions for blame and attribution spanned the entire spectrum of response, from the relatively sane…

…to the sublimely sarcastic.

As a community, we can talk and debate who did what, and why, but in the end it really doesn’t matter. Literally, none (well, almost none) of us outside the government or intelligence communities have any impact on the discussion of attribution. Even for the government, attribution is hard to nearly impossible to do reliably, and worse – is now politicized and drawn out in the court of public opinion. The digital ink on malware or Internet attacks is hardly even dry, yet experts are already calling out “Colonel Mustard, Lead Pipe, Study” before we even know what the malware is fully capable of doing. We insist on having these hyperbolic discussions where we wax poetic about the virtues of the NSA vs. Microsoft vs. state actors. 

It’s more important to focus on the facts and what can be observed in the behavioral characteristics of the malware and what organizations need to do to prevent infection now and in the future. 

How people classify them varies, but there are essentially three different classes of weaponized malware:

  • Semi-automatic/automatic kits that exploit “all the things.”These are the Confickers, Code-red, SQL Slamming Melissa’s of the world
  • Manual/point targeted kits that exploit “one thing at a time.” These are the types of kit that Shadow Brokers dropped. Think of these as black market, crew-served weapons, such as MANPADS
  • Automatic point target exploit kits that exploit based on specific target telemetry AND are remotely controllable in flight. This includes Stuxnet. Think of these as the modern cyber equivalent of cruise missiles

Nation state toolkits are typically elegant. As we know, ETERNALBLUE was part of a greater framework/toolkit. Whoever made WannaCrypt/Cry deconstructed a well written (by all accounts thus far) complex mechanism for point target use, and made a blunt force weapon of part of it. Of those three types above, nation states moved on from the first one over a decade ago because they’re not controllable and they don’t meet the clandestine nature that today’s operators require. Nation states typically prefer type two; however, this requires bi-directional, fully routed IP connectivity to function correctly. When you cannot get to the network or asset in question, type three is your only option. In that instance, you build in the targeting telemetry for the mission and send it on its way. This requires a massive amount of upfront HUMINT and SIGINT for targeting telemetry. As you can imagine, the weaponized malware in type three is both massive in size and in sunk cost.

WannaCry/WanaCrypt is certainly NOT types two or three and it appears that corners were cut in creating the malware. The community was very quick in actively reversing the package and it doesn’t appear that any major anti-reversing or anti-tampering methods were used. Toss in the well-publicized and rudimentary “kill switch” component and this appears almost sloppy and lacks conviction. I can think of at least a dozen more elegant command and control functions it could have implemented to leave control in the hands of the malware author. Anyone with reverse engineering skills would eventually find this “kill switch” and disable it using a hex editor to modifying a JMP instruction. Compare this to Conficker, which had password brute-forcing capabilities as well as the ability to pivot after installation and infect other hosts without the use of exploits, but rather through simple login after passwords were identified.

This doesn’t mean that WannaCry/WanaCrypt is not dangerous, on the contrary depending upon the data impacted, its consequences could be devastating. For example, impacting the safety builder controlling Safety Instrumented Systems, locking operators out of the Human Machine Interfaces (HMI’s, or computers used in industrial control environments) could lead to dangerous process failures. Likewise, loss of regulatory data that exists in environmental control systems, quality systems, historians, or other critical ICS assets could open a facility up to regulatory action. Critical infrastructure asset owners typically have horrific patch cycles with equally appalling backup and disaster recovery strategies. And if businesses are hit with this attack and lose critical data, it may open up a door to legal action for failure to follow due care and diligence to protect these systems. It’s clear this ransomware is going to be a major pain for quite some time. Due care and preventative strategies should be taken by asset owners everywhere to keep their operations up and running in the safest and secure manner possible.

It really doesn’t do much good to philosophically discuss attribution, or play as a recent hashtag calls it, the #smbBlameGame. It’s relatively clear that this is amateur hour in the cybercrime space. With a lot of people panicking about this being the “next cyber cruise missile” or equivalent, I submit that this is more akin to digital malaria.

INSIGHTS | May 13, 2017

We’re gonna need a bigger boat….

By Brad Hegrat

A few weeks ago back in mid-March (2017), Microsoft issued a security bulletin (MS17-010) and patch for a vulnerability that was yet to be publicly disclosed or referenced. According to the bulletin, “the most severe of the vulnerabilities could allow remote code execution if an attacker sends specially crafted messages to a Microsoft Server Message Block 1.0 (SMBv1) server. This security update is rated Critical for all supported releases of Microsoft Windows.”

Normally, when Microsoft issues a patch or security there is an acknowledgment on their website regarding the disclosure. Below is the website and it is an interesting process, at this point, to make a visit. https://technet.microsoft.com/en-us/library/security/mt745121.aspx

Notice anything?  MS17-010 is conspicuous in its absence.


It is often said that timing is everything, and in this case, Microsoft beat the clock. Exactly one month later, on 14 April 2017, ShadowBrokers dropped a fifth in a series of leaks supposedly associated with the NSA which included an exploit codenamed ETERNALBLUE. Flashing forward to today almost one full month later this payload has been weaponized and, over the last few hours, has been used in a rash of ransomware attacks throughout the UK, mainland Europe, and western Asia.
UK Hospitals Hit in Widespread Ransomware Attack
NSA Exploit Used by Wannacry Ransomware in Global Explosion
Spain Ransomware Outbreak

 

Considering the timing, one could be inclined to consider that this was not just Microsoft’s good fortune.

 

While pretty much the entire wired world is rushing to patch MS17-010, even though that patch has been out for almost two months, there is one technology area that is cause for particular concern especially when it comes to ransomware. This area of concern is the global industrial environments.

Historically, general purpose, run of the mill malware that leverages SMB and NetBIOS interfaces in the industrial environment are particularly troublesome, with many systems remaining infected many years later. Besides ICS environments being in an operational state that complicates the life of those seeking to patch them, some of these legacy systems often use a protocol called Object linking and embedding for Process Control (OLE for Process Control, or OPC for short). OPC Classic (a legacy protocol implementation), relies on the Distributed Component Object Model (DCOM) which makes heavy use of the Distributed Computing Environment / Remote Procedure Calls (DCE/RPC) protocol. 

In addition to NetBIOS and depending on both configuration and implementation, SMB is one of the interfaces that can be leveraged by these other services. Because both NetBIOS and SMB are needed in some manner by ICS software and protocols, many ICS systems have been negatively impacted by malware leveraging SMB and NetBIOS attacks reaching back well over a decade.


 Consider the major, well-known examples of malware impacting the ICS space. In November of 2008, the first variant of Conficker was publicly identified and due to the ICS requirements of keeping the NetBIOS and SMB ports open, Conficker is still found to this day. Conficker exploited MS08-067 and due to its password brute forcing capability, is incredibly resilient to remediation attempt at the system level. Another major example that utilized the attack vector in MS08-067 was Stuxnet. We all know how that turned out.  MS17-010 has the potential to be every bit as damaging and in some ways much worse.

With the WannaCry/WanaCrypt ransomware in the wild, crossing into industrial control systems would be particularly devastating. Systems requiring real-time interfacing and control influence over physical assets could face safety/critical shutdown, or worse. When thinking about critical services to modern society (power, water, wastewater, etc.), there is a real potential, potentially for the first time ever, where critical services could be suspended due to ransomware. It may be time to rethink critical infrastructure cybersecurity engineering because if MS17-010 exploiting malware variants are successful, we are clearly doing something wrong.