The vulnerability MS17-010, patched on 14 March 2017 but rising to prominence with the Shadow Brokers leak of an exploit called ETERNALBLUE in mid-April 2017, has fueled multiple information security headaches. First and among the most prominent was the global WannaCry ransomware event in May 2017 (two months after the patch was released and one month after the exploit), although the vulnerability continues to be used through various “copycat” cryptominer campaigns to the present. Most recently, the City of Baltimore suffered a crippling ransomware event that was initially thought to be related to MS17-010, then subsequently confirmed (or at least declared) to be the case in New York Times reporting several days later.* Overall, MS17-010 appears to be the “gift that keeps giving” for malicious actors of all types, yet the issue raises multiple items for further discussion beyond the technical specifics of the vulnerability and its shadowy origins.
The City of Baltimore and related events emphasize the continued risk of both exposing SMBv1 (the service targeted by MS17-010) and failing to apply critical patches for remote code execution vulnerabilities. However, most “fallout” from recent reporting appears to place blame for such actions on the US National Security Agency (NSA) – authors of the ETERNALBLUE exploit. While enough information now exists within the public domain for one to make reasonable attribution of ETERNALBLUE (and related items) to the NSA, the sequence of events surrounding its disclosure, subsequent activity in the wild, and the overall nature of the exploit and intrusion market require a more nuanced understanding than simply assigning blame to the NSA for all subsequent MS17-010-fueled events.
First, the timing and nature of the patching and disclosure cycle must be considered and examined. Whether through US government disclosure to Microsoft or through some other means, some entity disclosed to Microsoft the existence of the SMBv1 vulnerability prior to the Shadow Brokers’ public disclosure of the ETERNALBLUE exploit – a time delta of approximately one month. While relatively short, the nature and severity of the vulnerability (remote code execution on vulnerable devices exposing the SMBv1 service) should prompt immediate action on the part of IT teams – if not for all devices (a likely impossibility) then at least for priority systems. Examples would include externally-accessible systems (web servers, DMZ devices), “pivot” systems enabling access to internal networks, and “crown jewels” devices of vital importance. Even systems that could not be patched in a timely fashion – such as industrial control system devices – could still be protected by ensuring systems “in front” of them were patched to prevent spread, a point I made in a 2017 SANS webcast. Had organizations adopted a layered, prioritized approach to patching MS17-010 or limiting external SMB exposure, the WannaCry event (and many subsequent activities) may never have occurred, or transpired with far lesser impact.
Following the first, widespread exploit of MS17-010 by WannaCry, many security professionals (including myself) anticipated further attempts to leverage this vulnerability for wormable functionality or unimpeded lateral movement. Yet, subsequent events (NotPetya and BadRabbit, in particular) expanded functionality beyond targeting MS17-010 to leveraging dynamic credential capture and reuse to facilitate spreading, making these far more potent and capable than the WannaCry worm. While MS17-010 use continues on some level, “wormable” or widely-spreading malware seemed to shift to other vectors for targeting from 2018 onward: complete reliance on credential capture and reuse (Olympic Destroyer), using wormable malware to facilitate ransomware installation (Ryuk) and (likely) Active Directory compromise to spread malicious software (LockerGoga). While uncomfortable to acknowledge, MS17-010 just provides one of many possible avenues to a potentially costly and damaging incident – and it is arguably less popular than many other mechanisms.
Yet – as detailed in the earlier-linked Ars Technica reporting – “lower level” adversaries continued to leverage the MS17-010 vulnerability in SMBv1 for significant, localized effects against “soft” targets, such as local governments. The motivating item behind this post, the compromise of City of Baltimore IT systems, allegedly was facilitated by MS17-010-exploiting ransomware resulting in widespread infection and loss of city services. Yet in looking at the matter, it is important to distinguish between ETERNALBLUE (the specific exploit leaked from the NSA, designed to deliver the DOUBLEPULSAR in-memory implant) and exploits reusing ETERNALBLUE code or reverse engineering the MS17-010 patch to deliver malicious code to victim systems.
Based on available, public reporting, ETERNALBLUE serves as an initial access mechanism to deliver the DOUBLEPULSAR implant to enable follow-on exploitation and persistence. This overall chain of events makes sense as an attacker would seek to gain initial access, establish a “lightweight” backdoor, then establish long-term access via legitimate-looking mechanisms for follow-on operations. Ransomware significantly changes this pattern of life, as individuals wishing to extort money instead desire to merely spread as quickly as possible throughout a victim’s network while delivering an encrypting (or other) payload to compel obedience. Simply reusing the leaked ETERNALBLUE exploit without modification would not accomplish this goal as this would provide attackers with a non-persistent backdoor to infected systems.
Instead, the underlying code (and thus the SMBv1 vulnerability) would need to be analyzed, to some extent reversed, and then a replacement payload provided to enable ransomware (or wiper) operations. Simply compiling and using the posted ETERNALBLUE information would not suffice to create a wormable event – the exploit would need to be packed, deployed, and paired with some impact payload to be of any use. This amount of and need for work is not unexpected – and would have likely occurred to some extent had ETERNALBLUE never been leaked. Instead, security personnel should expect “bad actors” to analyze and reverse engineer the patch even if no exploit were disclosed by the Shadow Brokers, as pointed out by several security experts. Once MS17-010 was disclosed, information security entered a race with exploit developers for when and how this vulnerability would be targeted and exploited – ETERNALBLUE merely accelerated the timeline. Therefore, one can cogently argue that the clock started for likely malicious use the moment Microsoft released a critical patch irrespective of any subsequent exploit disclosure.
However, it can and should be noted that the Shadow Brokers’ release of ETERNALBLUE significantly reduced the level of effort required to operationalize MS17-010 – yet simplification does not seem to be sufficient for making a claim of culpability in this case. The underlying vulnerability in the SMBv1 service existed since that service’s inception – thus waiting for some enterprising individual or entity to discover and take advantage of this fundamental weakness in the operating system. While holding Microsoft responsible for faulty code may be a bit extreme (as Microsoft likely did not introduce this vulnerability deliberately into its code base), the exploit could have never existed if not for this failure. Once present, I would argue it would only be a matter of time for any enterprising individual, dogged researcher, or well-resourced entity to discover and exploit this weakness, even if only as a proof of concept. That the NSA may have been the first to identify and leverage this weakness (for a fundamentally vulnerable service that Microsoft and others have called on users to disable for years) may be immaterial as someone would have done so eventually.
If we accept the near-inevitability that vulnerabilities will be found and exploited, then less focus should be placed on that the NSA identified and exploited MS17-010, with emphasis instead placed on why and for what purposes the entity (allegedly) performed this work. As stated in the New York Times article covering the City of Baltimore event, the NSA knew and took advantage of this vulnerability for several years before public disclosure – yet in doing so, it presumably did so to further the agency’s mission of signals intelligence collection in the service of US intelligence community needs. While there is a discussion to be had concerning the ethics and desirability of such behavior, for the purpose of this argument, I will just accept the concept that “spies are gonna spy”. While some entities (like the alleged North Korean actors behind WannaCry) may blend intelligence operations with criminal activity, for the most part such entities typically wish to remain quiet and not disclose tools and tradecraft.
From this supposition, I would argue it is clear that the NSA, in (allegedly) discovering and exploiting MS17-010, never intended this capability to spread beyond its grasp to the extent such control is possible. Thus, the NSA did not deliberately leak, disseminate, or otherwise enable subsequent operations. One counter-argument is that the Vulnerability Equities Process (VEP) should have identified what would become MS17-010 as a uniquely damaging item, thus precluding espionage use of the vulnerability in favor of disclosure and patching. On this, I think it is hard for anyone not directly involved in this specific VEP discussion to know just what considerations were in play and how the costs and benefits of disclosure vs. use balanced out. Maybe the calculus and results were “wrong” in retrospect, but absent knowing what items such as ETERNALBLUE were used for (maybe disrupting terrorist plots, or enabling insight into nuclear weapons programs of interest) such discussion seems difficult and largely theoretical.
Yet this exploration does point to a deeper issue concerning the use, development, and disclosure of vulnerabilities used for state-sponsored cyber activity – maintaining control over and attempting to restrict use of computer network operations capabilities while simultaneously using them for active engagements. When discussing this topic, I cannot emphasize the following enough: once a capability is used, it is, for all intents and purposes, disclosed. While victims or analysts may not always identify when or how a capability was used, in cases where attacks are spotted, entities can learn what was done or used to facilitate a compromise and use this knowledge to build their own, equivalent capability. This scenario was very likely the case in recent reporting by Symantec with respect to APT3’s re-use of capabilities (allegedly) tied to the NSA. While Symantec notes that how APT3 specifically “obtained Equation Group tools at least a year prior to the Shadow Brokers leak remains unknown”, the technical reporting available indicates that the deployed capability was functionally equivalent to an NSA-linked tool (the DOUBLEPULSAR backdoor) rather than a direct copy – strongly implying capture and reverse engineering of something identified by (or given to) APT3 and not a scenario like the Shadow Brokers’ leak of source code and documentation.
Essentially, once any sort of capability is used “in the wild”, any expectation that it will remain secret must end. For this reason, aside from just evading defender detection, adversaries go to great lengths at times to obfuscate or prevent analysis of capabilities – such as the encrypted payload of the Gauss malware, which has evaded analysis to this day. While items such as Gauss feature significant built-in protections and limitations to run only under specific conditions, something more “general purpose” and widespread – such as an SMBv1 exploit – offers less opportunity for hiding and can (or should) be detected through artifacts of the exploit process. As a result, the expectation that any cyber capability, irrespective of that capability’s developer or deployer, can stay “hidden” or secure forever represents wishful thinking. So long as entities – from the NSA to the MSS to the GRU – continue operating within this space, capabilities will be developed and, over time, be disseminated to other actors, from other intelligence agencies to criminal entities.
ETERNALBLUE and MS17-010 represent just a specific instantiation of an otherwise much larger phenomenon of cyber capability development and deployment. While the Baltimore example contains an element of unfortunate irony given the NSA’s location nearby, the fundamentals of this story – that cyber capabilities will migrate beyond initial actor control and be used by other actors for unintended effects – are an immutable aspect of our current reality. So long as we continue to work with vulnerable systems and software and various entities have incentives to compromise such items, we will continue to observe events like the series of MS17-010 fueled ransomware events. MS17-010 may never have existed, and many of these events would have nonetheless transpired through some other fashion – as observed in other ransomware events like Ryuk and LockerGoga.
Applying a retributive justice model to MS17-010 events where either the NSA or Microsoft are designated “at fault” for matters seems shortsighted and unproductive. For while one can trace a line from the actions of these organizations to subsequent exploitation and damage, this path crosses several barriers that were either weakly constructed when they were present at all. Examples include poor network design allowing for infections to spread quickly; insufficient patching and hardening policies where 2 year old, critical vulnerabilities remain present; and lack of planning and resourcing for incident response and containment in the event of a security event. Some of the entities that appear easiest to blame for events have already taken steps to reduce the likelihood of similar items occurring in the future – whether through a reinvigorated VEP program in the US government or an increasingly secure operating system for Microsoft. Yet any such improvements will have little impact if we continue to ignore or inadequately resource basic security practices and sound operations across all our networked environments. If there are concrete steps to take from events such as Baltimore, it is to emphasize and resource IT operations to ensure that short-term cost savings (in not applying updates or refreshing software) do not turn into long-term crisis.
The above might sound like “victim blaming”, but I would disagree – the entity “at fault” for the Baltimore event is the criminal group responsible for deploying the malware. Yet collectively, there is much we can do to make such entity’s jobs significantly harder. The woeful state of IT systems in the public sector – especially non-federal and non-defense networks – should shock and disgust anyone with even cursory knowledge of security. Yet blaming these institutions, which have faced perpetual cuts in resources and funding since the 1980s, have little scope to mitigate items on their own due to lack of resources. So if there is something to learn from events such as Baltimore, I would argue it is for the general public to become aware of and decide to properly resource information security for public sector IT. That such problems continue, such as the rather unsophisticated use of MS17-010 to target cities and school districts, represents the outcome of poor collective choices, which enterprising criminals have merely taken advantage of for profit.
*Note: I am somewhat skeptical here because I have not seen any samples myself, nor have I read any specific technical analysis related to the Baltimore event. Instead, all information I have seen is general audience journalism, which has consistently conflated the SMBv1 vulnerability patched in MS17-010 with a specific exploit for that vulnerability, ETERNALBLUE. So while I am quite willing to accept that MS17-010 was involved, the specific manner in which this was exploited is still an open question based on available information.
