My next class:

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

  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: https://github.com/lgandx

Blue Screen of death after successful exploit:

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
4 comment(s)
My next class:

Comments

There are other technologies for providing user access to SMB storage without actually using Windows SMB/ CIFS Protocol - hence eliminating known/or unknown risks of such exposure in high risk protected services environment. The most recommended technology is Web Distributed Authoring and Versioning service based on Hypertext Transfer Protocol (HTTP) which allows desktop client/and services across platforms to perform full read/write file operations with support of authorization access and authentication control via LDAP and GPO - which makes it easy to implement and manage.
As someone just starting to learn Snort rules... can you please reverse that snort rule? IE can you show us how to look at the rule and apply it to the packet it came from? The reverse of what you did to write the rule.-> "|fe 53 4d 42 40 00|"; offset: 4; depth: 6; content: "|03 00|"; offset: 16; depth:2 ;

Thanks.
Frame 27, row '0030'

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
Not my explanation thanks to JK for this:

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

Diary Archives