Windows SMBv3 Denial of Service Proof of Concept (0 Day Exploit)

Published: 2017-02-02
Last Updated: 2017-02-02 23:36:21 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

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: . 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:

  1. NetBIOS header. This just includes the message type (0) and the total length (1580 in this case). 
  2. SMB2 header: The usual 64 bytes. The "Command" indicates that this is a tree connect message and the response flag is set.
  3. 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:

Blue Screen of death after successful exploit:

Johannes B. Ullrich, Ph.D.

4 comment(s)
Diary Archives