MS17-010 - Eternal Blue

Note from the Author: Welcome to the first post in my CVE of the week series! This post covers a brief overview of my findings while experimenting with the infamous EternalBlue Exploit. For a more in depth writeup of this CVE, including things like my specialized, EternalBlue-tuned sysmon config, SMB blocking Access Control List, and custom Splunk Dashboard created for this lab, check out my github: github.com/paperclipsvinny/cve-of-the-week

Overview

Scope & Authorization

This testing was conducted on a Windows 7 system, operated offline, for educational and defensive security research purposes only. I conducted this testing ethically, with express authorization.

At-A-Glance

CVE ID: CVE-2017-0143 – CVE-2017-0148
Alias: MS17-010 – EternalBlue
Disclosed: March 14, 2017
Severity: 9.8 (Critical)
Exploit Type: RCE
Software Affected: Microsoft Windows operating systems using SMBv1:
Windows 7, XP, Vista (SP2), 8, 8.1, 10 (prior to build 1703)
Windows Server 2003, 2008, 2008 R2, 2012, 2012 R2, 2016
Notable Victims:
Healthcare: NHS (UK), Harapan Kita Hospital (Indonesia), Instituto Nacional de Salud (Colombia)
Shipping: Maersk, FedEx (TNT Express)
Pharmaceutical: Merck (MSD)
Automotive: Renault, Nissan, Honda

Typical Attack Chain

Although the entire lab was set up by yours truly, here’s what I did in the attacker role: Conduct Network Service Discovery to confirm the target was vulnerable, both using nmap scans, scripts, and the metasploit auxiliary/scanner/smb/smb_ms17_010 module. Then, the next step was initial access- although scripts handled this, the basic bug logic is buffer overflow, where an attacker send a malformed SMB_COM_TRANSACTION2 packet where TotalDataCount exceeds DataCount, which is then allocated as a small buffer by the srv.sys driver, but copies data based on TotalDataCount, causing a buffer overflow. This enables the attacker to write past allocated memory into adjacent kernel structures. Without going into too much detail, the data written from the overflow corrupts an SRVNET_BUFFER_HDR structure which contains an Memory Descriptor List (MDL) pointer. The attacker then redirects that MDL pointer to the malicious shellcode, which is then executed in kernel mode upon processing of the next smb request. Then, the shellcode gets the payload running in user-mode with SYSTEM privileges. Once the attacker has a shell, it's just a matter of exfiltrating data, such as user hashes, etc, and whatever other actions the Attacker performs– lateral movement, obfuscation/ Anti-forensics, Denial of service, etc.

Example Payloads

Payloads are truly where my lab got interesting. I originally wanted to try running the generic Metasploit EternalBlue payload against 3ndG4me’s AutoBlue script that allows further customization to write payloads that are stealthier, and then compare detections; however I could not get the AutoBlue script to reliably generate a shell without crashing the Kernel. The main issue I attribute that to was that it was incredibly hard finding the correct groom value, as well as the right named pipe (every time the Kernel crashed it caused the layouts to change). Groom connections are used to spray the kernel heap with controlled data, which is supposed to make memory layout predictable before triggering the overflow, but in my case was unreliable.

After inspecting the Metasploit script, it was clear that Metasploit was relying on smart guessing and luck- starting with an initial grooming count, and then incrementally trying different groom count values, each time increasing by 1, which is a similar tactic that I attempted, but I was not able to successfully get a shell. A lot of the time it would simply fail to connect, despite networking being configured. I suspect it might be due to Python/Impacket version incompatibilities, which I also experimented with, but eventually decided to accept that public exploit code often requires specific environments to function, and can be finicky. At least experimenting with compiling custom shellcode taught me some new things.

I then pivoted to attempting the same stealth techniques in Metasploit– mainly, process injection into wmiprvse.exe to hide the LSASS access, and setting the exit behavior to kill just the thread, rather than the whole process. I chose wmiprvse.exe after checking some logs generated by legitimate behavior, and realized it would be very hard to write a detection rule that doesn’t false positive on the WMI provider host (wmiprvse.exe)’s legitimate LSASS access. However, ironically, a weird quirk with PrependMigrate + EternalBlue — caused the metasploit exploit to fire multiple times and each one opened a session. Which made the stealthier attack LESS sneaky (although with subsequent testing I was not able to reproduce this error).

Remediation

The easiest way to stop Eternal Blue from spreading is to patch your systems! Update to the latest version of Windows, etc. However, for the sake of this lab, I also created an access control list on my cyber range that completely shut down the exploit. The Access Control list basically blocks common SMB/NetBIOS ports such as 445, 138,139, etc. and logs any packets that match that rule, inbound on FastEthernet0/0.

If you want to know more about the configuration of my air gapped cyber range, check out this article on its creation.

Overall, this lab gave me valuable insight into how kernel and system processes operate, as well as how advanced evasion techniques can be used to avoid detection. Stay tuned for next week’s CVE! </>