A new zero-day exploit exists in the wild for Windows SMB. Security researcher Gaffie discovered this vulnerability three months ago. Since Microsoft failed to patch it in the past three months, he released it. This vulnerability is specifically a null pointer dereference error in SMB (server message block) which allows a remote, unauthenticated attacker to cause a denial of service condition on a vulnerable system. This vulnerability, however, cannot be used for code execution. A vulnerability management tool can help mitigate smb v2 vulnerabilities.
SMB V2 Vulnerabilities:
The vulnerability exists because of the manner in which Microsoft Windows handle SMB traffic. A patch management software is required to patch smb v2 vulnerabilities. Microsoft Windows fails to handle a crafted SMB tree connect response from a malicious server. When an SMB tree connect request is processed successfully by the server, the server responds with SMB tree connect response packet. The total length of an SMB2 TREE_CONNECT response packet is 16 bytes in addition to the fixed SMB2 header. Thus the client always expects the SMB2 TREE_CONNECT response length to be not more than 16 bytes. Given below are the packet structure of a proper SMB2 TREE_CONNECT response packet. More details can be found here.
If a Windows client connects to a malicious SMB server and the server responds with a crafted response having more than 16 bytes, then Windows client systems crash i.e. Blue Screen of Death (BSOD) appears and system reboots itself. Thus, if the total message size in Tree Connect response is very large, windows is not able to handle it and trigger the buffer overflow. The crash confirms with fully-patched Windows 10, Windows 8.1, Windows Server 2016 and Windows Server 2012 R2 systems.
Exploit code:
Exploit code for the smb v2 vulnerabilities are available. GitHub has already released the PoC code for exploiting this vulnerability on Windows 10. It is available for anyone to use. The exploit implements an SMBv3 server, and affects the clients supporting SMBv3 connecting to it. An attacker would have to trick the victim into connecting to this malicious server.
To understand what actually triggers the crash, we will set up the malicious SMB server provided here and will try to connect to it from a fully patched Windows 10 machine, while capturing the packets. Upon running the script, the malicious server listens as expected on port 445 as shown below,
Once we try to connect to the malicious server from a fully patched Windows 10, it crashes resulting in BSOD.
Upon analyzing the packet details we can see the malicious server does not send only 16 bytes SMB2 TREE_CONNECT response but sends some additional extra bytes (C’s here) which trigger the buffer overflow in mrxsmb20.sys, resulting in BSOD and system reboot. Details captured by Wireshark are below.
There is no official patch from Microsoft as of now. All Windows users are left open to potential attacks. An obvious temporary workaround to this security issue is blocking outbound SMB connections i.e TCP ports 139 and 445 and UDP ports 137 and 138.
– Shakeel