Introducing the Windows 10 SMB Shadow Attack: Direct SMB Session Takeover

This guest post is from a member of Strontium.io’s penetration testing team. This scenario and exploit was reported to Microsoft through their vulnerability program in February 2021.

TL;DR

Sharing a folder on Windows 10 can inadvertently expose a network to this powerful Shadow Attack. All Windows 10 users should cautiously, if at all, share files, printers or use remote administration before obtaining professional security training or support.

Introduction

There are several known relay attacks on the Server Message Block (“SMB”) protocol. Relay attacks require an SMB client to be induced to send credentials to an attacker’s server. This article presents a novel way to intercept a direct connection from a client, a “Shadow Attack.” This bypasses the cumbersome relay step that all existing techniques require. In the typical approach, an attacker must wait for a client to misspell a server name to start a relay compromise. In this new approach, an attacker can gain the same privileges by simply shadowing a standard client connection.

Background

Windows 10 includes the SMB protocol for file sharing and remote administration. SMB support in Windows is generally backwards compatible. SMB has evolved security features over time, but even the most recent SMB version is weakened by its backwards compatibility. The Shadow Attack presented here uses SMB’s reliance on these historically weak protocols in a novel direct SMB session takeover.

SMB version 3 (“SMBv3”) is included in Windows 10 and configured for backwards compatibility by default. This is to ensure the latest version of Windows can communicate with older existing network services. For example, in a Windows office network, an older Windows 8 client may connect to an existing collection of services provided by new Windows 10 servers. These could include sharing files or executing applications on the server.

SMB’s security features include signing and encryption. These features exist in SMBv3 and are in themselves strong and secure; however, when SMBv3 servers receive an older SMB version connection, these features are not necessarily enabled. For example, an SMB version 2 (“SMBv2”) client connecting to an SMBv3 server, by default, will not have signing or encryption. This means that the communication will be in cleartext and the server will not verify the authenticity of the message sender. This usability decision to be backwards compatible will form the basis for the Shadow Attack opening.

The Shadow Attack on SMB takes advantage of core networking principles coupled with this downgrade weakness and nuances of the protocols themselves to allow compromise of a typical Windows 10 network. A reader with familiarity of Windows protocols and system services including SMB, TCP/IP, and ARP would be able to perform this Shadow Attack. For example, connecting a hostile laptop to one of millions of small business WiFi networks, could allow an attacker to gain access to any active Windows servers on the network.

Attack Environment

The Shadow Attack is performed in a typical office environment. The office network is a single IPv4 subnet, with ARP-enabled DHCP provisioning. The network is wirelessly connected by a small office WPA2 (802.11) router. Two Windows 10 PC’s are connected to the router. One, “SMB Server”, is configured as a standard SMBv3 server. The other is a client, “SMB Client” configured to access the server. This represents a commercial, off-the-shelf small office configuration.

A new machine, “Attacker”, joins the WiFi network. This simulates a guest in a typical office environment. There are many ways Attacker could gain access to the network, but let us assume they asked someone for the wireless network id and password. Attacker’s machine is a MacOS 10.15 laptop in this situation, however most operating systems are capable of performing this attack. Attacker is ready to perform the attack once they have access to the network.

The Shadow Attack

The Shadow Attack requires four steps. First, Attacker takes over the role of the network router. Second, Attacker waits for an existing network user to connect to an SMBv3 share. Third, Attacker intermediates the negotiation of their SMB connection. In this step Attacker downgrades their security and establishes a shadow connection. Finally, Attacker acts on behalf of the original client for any number of shadow requests.

As a metaphor for this attack, we can imagine a sealed envelope in the real world. This envelope can contain written information, such as data or instructions, that should be prevented from alteration or inspection by a mail carrier that delivers the envelope. In step one, Attacker becomes the post office. In step two, Attacker waits for a party to send an envelope asking for “high security” to their target. In step three, Attacker rips open the envelope and replaces it with one of their own. Inside, Attacker asks for “no security” and writes down the sender information which they re-use in step four. Finally, Attacker sends any messages in their own envelopes to the target, re-using the “sender information” they got in step three.

Prior to this attack we expect Attacker to do modest network reconnaissance to identify “SMB Client”, and “SMB Server”. Attacker could do this by monitoring the network traffic for SMB requests using the same method as in Step One. Alternatively, Attacker could identify both, in real time, as a client sends a SYN to port 445 of a server.

Step One

First Attacker captures the traffic from SMB Client. This is an ARP poisoning attack. ARP poisoning manipulates a basic property of the way packets are routed on a network. Specifically, which network device hardware address maps to which network IP address. In this ARP poisoning attack, Attacker masquerades as the router’s hardware address to effectively become the router on the network. This is accomplished by a well known software called BetterCap. At the completion of step one, SMB Client will treat Attacker’s machine as the router. Or in other words Attacker can now intercept, modify and forward all TCP/IP packets going to and from SMB Client.

The goal of Step One is to listen to all TCP/IP packets going to and from SMB Client. This can be accomplished in many ways, and most methods will be compatible with this attack. For example, on a wired LAN network it is typical to use a network hub. A network hub broadcasts all traffic to all devices. In this configuration, SMB requests would be visible without the need for ARP poisoning. However, in our testing environment the WiFi router is acting as a switch, which more intelligently routes traffic without broadcasting it. Our approach tackles this problem by utilizing ARP poisoning only on the SMB Client. This is done as a courtesy, as ARP poisoning generally doubles traffic load for each targeted device.

Note that for the purposes of this attack, Attacker is able to allow the actual router to continue to route traffic as normally.

Step Two

Second, Attacker waits for SMB Client to connect to SMB Server. Attacker does this by monitoring network traffic for an SMB connection request. The SMB protocol establishes connections by making a standard TCP/IP request to TCP port 445. Because of Step One Attacker can view the traffic of SMB Client. This means Attacker can trivially filter traffic for a connection from client to server port 445. Since SMB establishes a TCP connection on port 445 and Attacker views this activity, they are able to trigger the substantive portion of the attack.

Step Three

Third, Attacker downgrades the session. Negotiating an SMB connection is itself a multi-stage process. A TCP connection is made on port 445 by a client. A preamble is sent between the client and server. SMB messages are transported by the TCP connection between the client and server. Then the SMB Client negotiates which smb protocol version will be used. The residual TCP connection is all that is required to authenticate on behalf of the originally negotiated SMB session.

Establishing an SMB connection requires 12 TCP packets. The first three are traditional TCP SYN, SYN/ACK, ACK and are unmodified for this attack. The next four packets are version escalation / negotiation. The final four packets are the authentication process.

Attacker needs only to focus on the version escalation. To enable backwards compatibility SMB connections are initially SMBv1 compatible. The fourth packet is an SMBv1 packet requesting protocol escalation to SMBv2. This allows servers to indicate whether they want to continue escalating to newer protocol versions. Older servers could deny this request, and clients would continue using the earlier protocol and suffer its limitations. Packet five is the server’s acceptance to speak SMBv2. This is the Windows 10 default behavior. Packet six specifies yet another escalation using SMBv2 to request SMB 2, 2+, 3 and 3+ features including the security attributes of the connection. The meat of the Shadow Attack is modifying this packet number six to request a lower escalation, devoid of security and enabling our reuse. Four more packets are exchanged to complete authentication by the client and the server. Because Attacker has downgraded to a SMBv2 security-free connection all of this transpires in plaintext.

The intent of packet six is to let the server know the connection dialects supported by the client. This allows the client and server to confirm the most secure supported dialect between them. The Client advertises five supported dialects ranging from SMBv2 to SMBv3.1. In the Shadow Attack we reduce the number of dialects in packet six from five to one. The one dialect we retain is the least secure SMBv2 base version which does not have support for encryption or signing.

Packet six is a 230 byte SMB message containing the client advertised dialects. There are five dialects in a list which is parsed based on a dialect count. Byte number 67 is the dialect count. The dialect count indicates the size of the list. In our implementation we simply change the dialect count from 5 to 1. This effectively reduces the parsed list to a single entry, the desired insecure SMBv2 protocol. The server accepts this modified packet and the connection continues to be established, but in a degraded SMBv2.0.

Authentication completes in the remaining four packets. Because the connection is using the SMBv2 dialect, this authentication happens in plaintext. Because the connection is in plaintext, all the connection data is exposed to Attacker. For the purposes of the Shadow Attack, Attacker need only track four pieces of information to impersonate the client in this SMB session. Those four pieces are the TCP Seqnum, TCP Acknum, SMB Client MAC Address, and SMB Server MAC Address.

Step Four

Finally Attacker can act on behalf of the original client for any number of shadow requests. Using the TCP Seqnum, TCP Acknum, SMB Client MAC Address, and SMB Server MAC Address, Attacker can send SMB messages as the client. For example, Attacker can craft a custom SMB message with appropriately modified tcp headers to request a file from the server that they would otherwise not have access to. This forms the basis of our demo. Although this demonstration of accessing a single file may appear trivial, SMB supports command execution which could facilitate further compromises. This is further exacerbated if the client is an administrative user. If an administrative user is impersonated in this technique, SMB Server would be fully compromised by Attacker.

Demonstration

Impact

Nearly three out of four computers around the globe are running Microsoft Windows. Many users in this population of 800 million devices will be accessing files, sharing printers and performing other network administration tasks through the SMB protocol. A typical, out-of-the-box Windows configuration used for these purposes will be susceptible to the Shadow Attack presented here.

There are many ways of sharing a file or folder over SMB in Windows 10. Microsoft support documents the technique shown in figure B. The hidden consequences of this action are likely not obvious to the average user. A security perspective would encourage at least warnings educating a user that they may inadvertently be reducing their security posture by performing this share.

Microsoft responded to the Shadow Attack disclosure and confirmed that this attack is present in the default configuration of Windows because by default Windows has “encryption and signing disabled on the server.” This means that there is a “lack of chain of trust” between client and server which prevents the protocol negotiation from happening in a secure manner. Because there are further steps that can be taken by an end user to secure Windows, Microsoft recognizes this as “a device configuration flaw [that] does not meet our bar for servicing in a security update.” Although not stated in their response, we infer that Microsoft’s implicit statement is that there are necessary secure steps an end user must take before network services are secure. In other words, do not use file sharing or other SMB protocol services with Windows 10 in default configuration in an untrusted network. This implies that for corporate governance, using Windows 10 with internal networks may still expose the business to data exfiltration or compromise by internal actors. This fails to satisfy the strong access control perspective encouraged by best practices.

Moreover, Microsoft Windows exists in numerous configurations that may have even less capable security controls. For instance, Microsoft Home does not have a Local Group Policy Editor and therefore cannot configure the detailed security options of SMB to prevent this attack. Windows is also present in variants used in embedded devices such as industrial control systems, transportation networks, physical security, autonomous aircraft and other critical systems. The only option to protect these systems may be to vigilantly disable sharing through SMB, if at all possible.

Security by Default is the principle that out-of-the-box systems should be as secure as possible. In this instance, Microsoft could ship Windows in a secure configuration. For example, Windows 10 could by default require signing and encryption for all SMB connections. This would have the negative impact of reducing backwards compatibility with legacy systems, but would prevent almost a billion systems from this Shadow Attack.

Disclosure Timeline

November 27th, 2020 Proof of Concept Demonstration.

February 16th, 2021 Vendor Disclosure to Microsoft.

March 10th, 2021 Vendor Reply “expected” Behavior.

In the setup, you are able to enable SPN validation, but have encryption and signing disabled on the server. Without encryption or signing, this attack is easily possible to an adequately positioned attacker on the network.

This is all expected, as the client has no way of knowing whether the "server" it is communicating with is legitimate due to the lack of chain of trust. I wonder if it is possible for the default configuration on newer versions of Windows could disable access for older SMB dialects, otherwise this is a device configuration flaw in the finder's setup.

For this reason, this case does not meet our bar for servicing in a security update and I have closed this case.

September 1, 2021 Publication.

September 2, 2021 Released on GitHub: https://github.com/usiegl00/smbshadow