Software and hardware development and engineering is both an art and a science. It is a discipline that requires countless hours being spent learning the basic principles of programming and how to apply those principles in a variety of languages. It is not easy, though at the same time, it doesn’t have to be hard either. Through the years, we’ve made a great deal of progress in academia and in practice with respect to what works, what doesn’t work, and how best to approach coding in a manner which sees our code run properly (meeting the needs and expectations which drive its development), while at the same time, executing safely in a manner which does not leave the code vulnerable to exploitation.

That last part is key and though this isn’t a blog on the merits of secure coding, secure coding is (thematically) germane to the topic du jour and we’ll see why as we continue. At this point you may be asking yourself, “Just how we have made the process of coding more efficient while ensuring that the code itself is developed safely and securely allowing us to minimize the risk of producing and releasing insecure code which could (under the right circumstances) found to be vulnerable to attack and thusly exploited by an adversary?”

In essence, it all begins with the Software Development Life Cycle (SDLC). You can read (at your leisure at the link provided) all about the SDLC and learn all about what it means to incorporate it, and how to do so through the various forms of software development models in use historically and today. In short, you need to have a handle on the following areas in order to be successful in the execution of an SDLC:

• Planning
• Implementation
• Testing
• Documentation
• Deployment
• Maintenance

And though this concept (and its variants) have been in existence for many years, critics of the methodology’s inability to ensure that coding is conducted with security at the forefront of all efforts have suggested that model is obsolete or in need of serious modifications. This criticism existed for many years (and still does to this day), and has resulted in at least two movements (one in 2012 and one in 2014) within the information security industry devoted to tackling this matter. Whether you agree with these movements is entirely up to you, however, the fact remains that improperly written code; specifically, code which is developed without security being a focal point, is and remains an issue we face on an almost daily basis.

And that brings us to last week’s most notable event, the outbreak of the ransomware known as WannaCrypt (also known as WannCrypt0r and WannaCry). On Friday, May 12, 2017, reports began emerging suggesting that a new form of ransomware had been identified in the wild with infections following suit around the world. At its height, WannaCrypt had infected an estimated 200,000+ machines in approximately 150 countries. Organizations from Spanish telecommunications giant Telefonica to the United Kingdom’s National Health Service (NHS) were impacted along with many others the world over.

Ransomware is designed with one purpose in mind: extort the party who has been impacted for something the ransomer desires (in most instances money in the form of bitcoin) and, if the victim is lucky, provide the key to decrypt their impacted device and/or files. WannaCrypt was no different. Its authors required bitcoin payment equivalent to $300 USD in exchange for the key to decrypt the device and its associated content. You may be wondering why we’re discussing WannaCrypt if it is essentially just another variant of ransomware. At a surface level you’d be correct, however, when digging deeper into the ransomware itself we note some peculiar and noteworthy things.

First, WannaCrypt had a hardcoded ‘kill switch,’ a domain which, unlike the others used by WannaCrypt, had not been registered by the authors. A British malware researcher who goes by the name MalwareTech first noted this and decided to register the domain to see what would happen. The result, which he called accidental, effectively rendered the malware inoperable.

Second, there is the curious case of code reuse as noted by Neel Mehta of Google in a Tweet which appeared Monday, May 15, 2017. It’s important to note that code reuse or appropriation is not unusual amongst malware authors. Neel’s observation noted that the code in question was present in WannaCrypt and in tools used by the infamous Lazarus Group. The Lazarus Group is most well known for being featured in a report written by a coalition of malware and threat research organizations lead by Novetta titled ‘Operation Blockbuster’ which described in detail the events surrounding the Sony Pictures attack of 2014. Theories with respect to the origins of the Lazarus Group abound to this day, with many believing that the Democratic People’s Republic of Korea (DPRK) was directly tied to this group and its efforts. As a result, many organizations have asserted that this example of code reuse is one example of evidence that supports the theory of a connection between the DPRK and the WannaCrypt outbreak.

Third, the authors of WannaCrypt chose to incorporate ETERNALBLUE, a tool alleged to have been designed for use in cyber espionage operations by the Equation Team. The tool was made publicly available in April of 2017 by the infamous hacking group the Shadow Brokers, who first appeared in the summer of 2016. The tool in question allowed the attackers to exploit a critical severity non-zero-day vulnerability in various Microsoft operating systems known as MS17-010 (CVE-2017-0144). The vulnerability in question allowed for remote code execution against SMBv1. In order to exploit the vulnerability, Microsoft asserted that, in most instances, an unauthenticated attacker could send a specially crafted packet to a targeted (vulnerable) SMBv1 server. A patch for MS17-010 was released to Microsoft customers on March 14, 2017. The ETERNALBLUE tool enabled exploitation of this vulnerability in susceptible hosts, enabling the compromise and download of the payload to take place. Over the last ~96 hours it has been reported that several more variants of WannaCrypt have been identified in the wild, with at least one that contained an additional tool acquired via the publicly exposed cache of tools made available by the Shadow Brokers.

So, what can we learn from this event? For one, we should take note that at least one or more variants were worm-enabled, using port 445 for communications and self-propagation. That is a fairly unique feature for ransomware and could be a sign of what's to come in future attacks, whether from WannaCry or others.

We can also reiterate the value of patching in a timely and efficient manner as soon as possible in order to avoid leaving the attack surface exposed for prolonged periods of time. In this case the patch was released by Microsoft for this critical yet non-zero-day vulnerability back on March 17, 2017, approximately 60 days ago and 55 days prior to the manifestation of WannaCrypt in the wild. Patching, patch management, and the trials and tribulation of patch management are well known and yet here we find ourselves in 2017 once more having a discussion on the value of patch management. Are there special circumstances where conventional patching may not be an option? Yes, there are. There are cases where specialized equipment sourced by a third party and embedded with an operating system managed by the vendor requires vendor intercession. However, it is exactly this type of use case (along with a few others) which strengthened the value proposition promoted by information security companies more than a decade ago that advocated for the selection of compensating controls which enable a ‘virtual patch’ while an organization waited for a vendor to supply an official patch. The events surrounding the WannaCrypt ransomware case ought to be a lesson for businesses great and small in that they ought to reinvigorate conversations where the business value of good IT hygiene and patch management are seen as business enablers as opposed to cost centers.