<h3><em>Not all exploits are created equal</em></h3><h2>Vulnerabilities and Patching</h2><p>Patching vulnerabilities is something everyone with a technology footprint deals with on one level or another whether they realize it or not. Consumers patch vulnerabilities all the time even if they don’t realize that’s what they are doing. Updating a phone to the latest version of Android or iOS, for instance, often includes fixes for some underlying vulnerabilities. Choosing to restart a smart TV or an Amazon FireTV to apply updates may also be applying patches to security vulnerabilities.</p><p>In the world of operating systems and enterprise software, patching vulnerabilities is a regular occurrence. At least it should be. Microsoft regularly offers updates that fix a variety of security related and non-security related bugs in their software. Oracle, Adobe, and other software companies also provide regular patches which commonly include fixes for security problems in their software. An entire industry of products has risen up to help enterprises probe for and track patch levels in software. Applying these patches is often disruptive to businesses, however, as system reboots are often required and sometimes patches break software that relies on the affected components. In order to maintain smooth business operation, proper testing must take place before applying the patches to critical systems. This problem in enterprises often leads to delays in getting patches deployed in a timely manner - if they get deployed at all.</p><h2>Finding Vulnerabilities</h2><p>Software and hardware creators learn about vulnerabilities in their systems via a variety of methods. Here are some common ways vulnerabilities are found:</p><ul><li><h3 class="nobottommargin">Internal testing</h3><p>Automating testing and applications that review source code provide feedback during development allowing fixes to vulnerabilities before products are even released. This is often performed as part of development using the Systems Development Lifecycle (<a href="http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-64r2.pdf" target="_blank">SDLC</a>) or Security Development Lifecycle (<a href="http://www.microsoft.com/en-us/sdl/default.aspx" target="_blank">SDL</a>) but may be done ad hoc during development as well. Techniques such as <a href="https://www.owasp.org/index.php/Fuzzing" target="_blank">fuzzing</a> may be employed to automate the search for vulnerabilities by rapidly throwing garbage into fields, open networking ports, or other pieces of the system and observing the response.</p></li><li><h3 class="nobottommargin">Independent Researchers</h3><p>Sometimes researchers who specialize in finding vulnerabilities will discover an unpublished vulnerability in a piece of software or hardware. It is generally up to the researcher what they do with this knowledge. The accepted process is to reach out to the creator of the software or hardware and give them the details about the vulnerability, and allow them time to provide a fix for it before making any of the details public. Not all researchers follow this best practice however, and sometimes vulnerabilities are disclosed before a fix has been made available. This often happens when the researcher feels the creator has taken too long to provide a fix so they go ahead and publish the details. Other researchers may try to sell their vulnerabilities in the form of exploits in the criminal underground where it may become used to aid malware infections or aid the compromise of specific, high-value targets.</p></li><li><h3 class="nobottommargin">Bug Bounties</h3><p>Organizations can create bug bounty programs which offer rewards for validated vulnerabilities found in their systems. The rewards can vary depending on the criticality or relative value of the vulnerability found. These programs are meant to entice researchers into looking for vulnerabilities in the organization’s systems and offer an alternative to selling them in the underground.</p></li><li><h3 class="nobottommargin">Vulnerabilities Found in the Wild</h3><p>Sometimes, either as a result of post-incident forensic examinations or through investigations into malware activity, a new vulnerability is discovered that is being actively exploited. Normally when this happens, the activity is investigated and the underlying vulnerability is addressed through a patch or other mitigation through a regular patch release cycle or a special “out-of-band” patch release to get the fix out more quickly than waiting for the next scheduled patch release.</p></li></ul><h2>Enter the Exploit</h2><p>Vulnerabilities are essentially academic in nature. They exist as software is written and are either discovered via one manner or another or they are not. Sometimes the discovery of lurking vulnerabilities can take place <a href="https://arstechnica.com/security/2017/05/intel-patches-remote-code-execution-bug-that-lurked-in-cpus-for-10-years/" target="_blank">many years</a> after the code producing the vulnerability was written. It’s not until someone produces a working exploit for the vulnerability that it truly gains usefulness for malicious behavior.</p><p>Exploits are bits of code that are designed to take advantage of a specific vulnerability. Depending on the vulnerability being leveraged, exploits can result in an escalation of privilege, the ability to run malicious code without user input, or to cause the software to hang or crash producing a denial of service amongst other results.</p><p>Not all exploits are created equal, however. Some work against default installations of software; some require very specific sets of criteria to be met. Examples include:</p><ul><li>A specific flavor of operating system or version of software installed</li><li>A specific piece of software installed that must be running at the time of exploitation</li><li>Non-default services that must be running in order to be exploited</li><li>Certain non-default features enabled or a specific configuration in place</li><li>User action required - enabling macros in a Word document for instance</li><li>A combination of any of the above items</li></ul><p>Sometimes, it takes stringing a number of exploits together to achieve the desired result. For example, in the recent <a href="http://zerodayinitiative.com/Pwn2Own2017Rules.html" target="_blank">Pwn2Own</a> competition for 2017, researchers were attempting to escape from or “break out” of a virtual machine into the host operating system. To do this, they used <a href="https://www.thezdi.com/blog/2017/3/17/the-results-pwn2own-2017-day-three" target="_blank">three separate exploits</a> against different software components in order to achieve the escape.</p><p>Not all vulnerabilities make for good exploits. In order for some vulnerabilities to be taken advantage of, very specific conditions must exist. It’s common for exploits to deliberately create the conditions necessary to reliably take advantage of a particular vulnerability. This isn’t always easy or possible, though. Some exploits may only end up successful a small percentage of times they are attempted. Sometimes, reliable exploitation of a specific vulnerability isn’t possible due to unfavorable or uncontrollable conditions. The vulnerability exists, there just isn’t a good way to take advantage of it.</p><p>The best exploits are those that can be reliably executed every time, require no user interaction, affect a large population of systems, and allow for remote code execution (RCE - the ability to force arbitrary code to run from a remote system). These are the “crown jewels” of the exploitation world and are fortunately fairly rare. Exploits that meet these criteria can be turned into worms, self-replicating and self-executing viruses. Conficker and WanaCry are examples of worms that leverage unpatched vulnerabilities to execute and spread.</p><h2>Tavis Ormandy</h2><p>While there are a great many talented vulnerability researchers, Tavis Ormandy has proven to be particularly skilled at finding viable exploits in software products. He has found bugs in a variety of security products from companies such as Sophos, Symantec, FireEye, TrendMicro, and Cloudflare. He has also found several bugs in Microsoft software as well. Many of his findings end up being critical in nature.</p><p>Earlier this year, Tavis tweeted that he and a fellow researcher had found “the worst remote code exec in recent memory”.</p><p style="text-align: center;"><em><a href="https://twitter.com/taviso/status/860679110728622080" target="_blank"><img alt="Tavis Ormandy Tweet" src="https://cdn.filestackcontent.com/sDkWWTySHWTfzGftGSFH"/>https://twitter.com/taviso/status/860679110728622080</a></em></p><p>Turns out, he had found a nasty bug in Windows Defender, the built-in antivirus software on Microsoft Windows. Tavis noted that this vulnerability would work against a default install of Windows, it’s not necessary to be on the same Local Area Network, and that it’s wormable. It affected almost all recent versions of Windows (Windows 7, 8, 8.1, 10, and Server 2016).</p><p>Microsoft responded very quickly by <a href="https://technet.microsoft.com/en-us/library/security/4022344" target="_blank">releasing a patch</a> only a few days later and acknowledged Tavis and his co-researcher, Natalie Silvanovich, for their work in discovering the vulnerability and notifying Microsoft of the details. Fortunately, Windows Defender attempts to update itself every 48 hours so most affected systems were likely fixed within days of the release of the patch. Potential crises averted. In this case, the fact that Tavis discovered and reported this potentially nasty bug means we may have been spared the spread of a nasty worm at some point in the future should someone else have discovered this vulnerability instead of Tavis.</p><h2>MS17-010</h2><p>On March 14, 2017, just a few days after the patch for Windows Defender was released, Microsoft released its usual list of monthly patch updates. Among those updates was <a href="https://technet.microsoft.com/en-us/library/security/ms17-010.aspx" target="_blank">MS17-010</a>, a patch for a vulnerability in Microsoft’s Server Message Block (SMB) protocol. The vulnerability is specific to SMBv1. Systems running SMBv2 and SMBv3 can be asked to downgrade to SMBv1 as part of standard communication so most systems running SMB at all would be affected unless SMBv1 was specifically disabled (it is enabled by default for all versions of Windows). Unlike other security fixes included in the patches released that day, no <a href="https://technet.microsoft.com/en-us/library/security/mt745121.aspx">acknowledgements</a> of who reported the vulnerability were included for MS17-010. It is currently unknown how Microsoft learned of this vulnerability.</p><h2>The Shadow Brokers &amp; The Equation Group</h2><p>A group called The Shadow Brokers appeared in August of 2016 claiming to have a trove of cyber weapons (exploits and other tools) from an organization called, the Equation Group. They released an encrypted archive supposedly containing nation-state level cyber attack tools and were attempting to auction the password to the archive. The Equation Group is a name given by Kaspersky researchers to the group behind several sophisticated hacking tools like Stuxnet, Flame, and Duqu.</p><p>After failing to retrieve the amount they were seeking to auction off the archive, they eventually released the password in a <a href="https://medium.com/@shadowbrokerss/dont-forget-your-base-867d304a94b1" target="_blank">post</a> on Medium on April 9, 2017. Ultimately, they only collected about 10.5 bitcoin (roughly $24k USD) but had been looking for 10,000 bitcoin (worth about $22.4 Million USD as of this writing). The bitcoin collected finally began moving around on May 29, 2017, perhaps in an attempt to cash it in.</p><p>The archive, it turned out, wasn’t that interesting. Most of the included exploits <a href="http://www.pcworld.com/article/3188808/security/latest-shadow-brokers-exploit-dump-poses-little-threat.html" target="_blank">were patched</a> quite a while back making them far less useful than they could have been.</p><p>Just days later, on April 14, 2017, The Shadow Brokers released another encrypted archive along with the associated password containing much more damaging contents. This release contained more recent exploits and an attack framework tool.</p><h2>ETERNALBLUE &amp; WanaCry</h2><p>ETERNALBLUE was the name of one of the exploits released by The Shadow Brokers on April 14, 2017. This exploit took advantage of the SMB vulnerability (MS17-010) patched exactly one month prior on March 14, 2017. The exploit code in ETERNALBLUE turned out to be very reliable and takes advantage of a vulnerability that exists in a wide install base allowing for remote code execution. On top of all this, the prevalence of unpatched Windows systems (including old versions of Windows XP) in places like Russia, China, and parts of Eastern Europe made the perfect kindling for the fire that would be the <a href="https://www.anomali.com/blog/wanacry">WanaCry</a> ransomware worm.</p><p>Here was the perfect combination of a recently patched vulnerability with a wide supply of vulnerable systems, working exploit code, and software designed to replicate itself and encrypt exposed files. There were many vulnerable systems connected to the Internet without blocking communication for SMB as well which helped accelerate the spread of the worm.</p><h2>Concluding Thoughts</h2><p>On December 14, 2016, The Shadow Brokers advertised the sale of a pack of tools for sale for 750 bitcoin including mention of an SMB zero-day exploit (an exploit which has no patch available). The SMB exploit was available separately for 250 bitcoin. This prompted US-CERT to release guidance on SMB best practices on January 19, 2017. The recommendations included disabling SMBv1 and ensuring SMB-related network ports were blocked at perimeter firewalls.</p><p>While it doesn’t appear that ETERNALBLUE was mentioned in The Shadow Brokers communication in its December posts, ETERNALROMANCE was shown in a <a href="https://twitter.com/shadowbrokerss/status/817960773569933313" target="_blank">screenshot</a> on The Shadow Brokers Twitter feed. ETERNALROMANCE was also an SMB vulnerability that was addressed in the MS17-010 patch from <a href="https://blogs.technet.microsoft.com/msrc/2017/04/14/protecting-customers-and-evaluating-risk/" target="_blank">Microsoft</a>. It may be that someone in the US government familiar with the tools tipped-off Microsoft regarding these exploits so they could be patched.</p><p>Once this “crown jewel” of The Shadow Brokers pack of tools was blown due to the Microsoft patch, it could be that they decided to simply release it for free along with the other stuff they were trying to sell. After failing to sell them in an auction, failing to sell them via crowdfunding, and the appeal for direct sale also failed, it could be they chose to release the tools and exploits for free due to lack of ability to monetize them.</p><p>The Shadow Brokers, apparently still trying to find avenues for monetization, are now advertising a <a href="https://steemit.com/shadowbrokers/@theshadowbrokers/oh-lordy-comey-wanna-cry-edition" target="_blank">Monthly Data Dump</a> which, as they mention, could contain anything from newer exploits against Windows 10 to secret data from various nation states. It’s hard to say what they actually have. They aren’t specific this time around regarding what they are trying to sell. It has been suggested that their Equation Group tools came from a compromised NSA staging server back in 2013. If so, they may not have much left to release from that compromise. Regardless, given the group’s history it’s fair to suggest that they continue to be monitored for further developments.</p><p>As for exploits, it’s important to understand the details behind them and which ones are particularly dangerous. The last two significant exploits that have led to successful Internet worms, MS08-067 (Conficker) and MS17-010 (WanaCry) were discovered as a result of the release of nation-state level attack tools (Stuxnet and ETERNALBLUE respectively). Staying informed is the key to staying out of the headlines. Organizations that followed US-CERT’s guidance back in January likely did not have significant issues with WanaCry. Organizations that recognized the significance of a vulnerability leading to remote code execution in the SMB protocol likely patched MS17-010 as quick as they could. If only the rest of the world paid as close attention, <a href="https://www.anomali.com/blog/wanacry-faq">May 12, 2017</a> would have been just another day.</p>