Windows SMBv3 Denial of Service Proof of Concept (0 Day Exploit)
The tweet originally announcing this issue stated that Windows 2012 and 2016 is vulnerable. I tested it with a fully patched Windows 10, and got an immediate blue screen of death (see below for screenshot).
A "Proof of Concept" (PoC) Exploit causing a blue screen of death on recent Windows version was released on Github earlier today. The exploit implements an SMBv3 server, and clients connecting to it will be affected. An attacker would have to trick the client to connect to this server. It isn't clear if this is exploitable beyond a denial of service. To be vulnerable, a client needs to support SMBv3, which was introduced in Windows 8 for clients and Windows 2012 on servers.
Right now, I do not see a Microsoft statement regarding this exploit and the vulnerability triggered by it. Of course, it is best practice to block port 445 inbound AND outbound on your firewall, limiting the impact somewhat.
A traffic capture I collected between two virtual machines (Windows 10 victim) can be found here: https://isc.sans.edu/diaryimages/smbexploit.pcap . The exploit can be seen in packet 27 and 28. The long string of "C"s does trigger the buffer overflow.
After the (normal) "Tree Connect Request" message, the server responds with a crafted "Tree Connect Response" message. The message itself is actually kind of ok, but the length of the message is excessive (1580 Bytes) and includes a long trailer.
The tree connect response message consists of:
- NetBIOS header. This just includes the message type (0) and the total length (1580 in this case).
- SMB2 header: The usual 64 bytes. The "Command" indicates that this is a tree connect message and the response flag is set.
- The Three Connect Response Message. This message has a fixed length of 8 bytes in addition to the fixed header.
This is where the message should end. But apparently, since the total message size according to the NetBIOS header is larger, Windows keeps on decoding in the crafted header (all "C"s in the exploit) which then triggers the buffer overflow.
Based on this understanding of the exploit (please let me know if I didn't get it right or missed something), I wrote a simple snort signature that looks for Tree Connect messages that exceed 1000 bytes in size. Use this at your own risk. It is in "works for me" state:
alert tcp $EXTERNAL_NET 445 -> $HOME_NET any (sid: 10001515; msg: "SMB Excessive Large Tree Connect Response"; byte_test: 3,>,1000,1; content: "|fe 53 4d 42 40 00|"; offset: 4; depth: 6; content: "|03 00|"; offset: 16; depth:2 ;)
The exploit can be found here: https://github.com/lgandx
Blue Screen of death after successful exploit:
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
Anonymous
Feb 6th 2017
7 years ago
Thanks.
Anonymous
Feb 6th 2017
7 years ago
fe nbss.length
53 smb2.server_component_smb2
4d smb2.server_component_smb2
42 smb2.server_component_smb2
40 smb2.header_len
00 smb2.header_len
Anonymous
Feb 7th 2017
7 years ago
SMB is a very old protocol, created in the days of IBM OS/2 and Novell NetWare protocols. Back in those days, SMB typically ran over a NetBIOS protocol layer, and even in today's times, SMB traffic carries a small bit of this legacy forward.
From the start of the TCP payload, there is a four-byte NetBIOS "shim" for a NetBIOS Session Service (NBSS). The first byte is always hex 0x00, and the next three bytes specify the length of the SMB payload. The 'byte_test' keyword checks this three-byte length to see if its stored value is greater than 1,000 bytes.
The first content match looks for the SMBv2/v3 magic marker, hex 0xff, "SMB@", hex 0x00, in the six bytes immediately after the NBSS shim. The second content match skips six bytes and then looks for the hex value 0x0003 (two-bytes), which specifies the "Command" as "TREE_CONNECT".
The SMB payload itself, at least generated via the PoC sample, is a series of repeated characters "C". It is this payload that overflows a buffer in a key Windows system file and then triggers a Blue Screen of Death (BSoD).
Anonymous
Feb 8th 2017
7 years ago