Windows Security: Part 2
Vulnerabilities in Microsoft’s implementation of the Server Message Block (SMB) protocol, the protocol behind Windows shares, have plagued Windows systems security for years. SMB is a strange protocol, and (not surprisingly) its strangeness and the many identified vulnerabilities in it go hand-in-hand. Consider how SMB works:
1. A client sends a Session Request Block to an SMB server (a server that shares files). This request includes the names of the client and server.
2. In response to the client’s request, the server forms a TCP connection on TCP port 445 in recent Windows operating systems and on TCP port 139 in older ones. The server does not verify the IP address of the client!
3. The client sends the server a list of all the SMB “dialects” it supports. Dialects are versions of SMB.
4. The server chooses the highest (most recent) dialect that is common to it and the client and sends a dialect list in which the one to use is shown.
5. The client sends a session setup request that contains a header that includes information such as the user ID, password, domain name, version of operating system, and some additional information.
6. The server responds by sending a token that includes the same kinds of information that was in the session startup request, but this time pertinent to the server. Also included is the type of file system that the server has.
7. The server selects the specific connection point (i.e., on the hard drive) and informs the client accordingly.
8. The client connects at the designated connection point (called the “Tree ID”) and sends a 2-byte SMB header to the server to verify to the server that the connection request was successful.
9. A simple kind of echo mechanism keeps the share connection alive until the client disconnects.
Many vulnerabilities in Microsoft’s implementation of this eccentric protocol have been identified over the years. A client can, for example, easily spoof an identity other than its own. A server can also be flooded with random requests during the negotiation process with the client to the point that it crashes. Forged SMB packets containing illegal values can cause an SMB server to crash or freeze. A set of related vulnerabilities allow unauthorized code to be remotely executed on an SMB server, e.g., when a specially crafted SMB packet is sent to the server. SMB clients and servers are also vulnerable to a number of buffer overflow attacks. A good example is a boundary error in the SMB client code when SMB “Trans” and “Trans2” commands are being processed. A malicious SMB server can cause a buffer overflow by sending specially crafted transaction response information to a vulnerable client. And these are just a few of the many vulnerabilities that have been found.
Microsoft has been commendable in providing patches for most of the SMB-related vulnerabilities that have been found. Additionally, Microsoft developed Server Message Block Version 2 (SMBv2) in an attempt not only to improve the performance of its SMB protocol, but also to address security weaknesses in earlier versions of this protocol. Interestingly, however, some of the most serious vulnerabilities found to date are in this new version of this protocol.
Microsoft’s SMB protocol is not the only file access protocol that is riddled with vulnerabilities. SAMBA, another version of SMB used in Unix and Linux environments, also has more than its fair share of vulnerabilities, as also does the Network File System (NFS), which is used primarily in Unix and Linux systems. What is troubling about Microsoft’s SMB protocol, however, is that it has been around for a long time and has in theory been subjected to intensive security scrutiny because of Microsoft’s Trusted Computing Initiative (TCI), yet new, critical vulnerabilities in this protocol seem to surface regularly. Clearly, Microsoft would do well to approach security weaknesses in this protocol with a higher priority.