The Windows NT Network Environment

NetBIOS and SMB-Based Networking⁵ in Windows NT

The chief focus of this section is the SMB protocol implemented in Windows NT (and the vulnerabilities it presents), although the NetBIOS protocol deservedly gets some of the attention. The Common Internet File System (CIFS), which implements the application and presentation layers of the OSI model, is Microsoft's implementation of SMB (a draft standard proposed by Microsoft and several other companies).

Introduction to SMB

SMB packets can be up to 65536 bytes in length, not counting an optional field in the header that indicates how long the packet is. SMB communicates directly with the NetBIOS layer, but it also works in conjunction with lower-layer protocols. At the transport layer, for example, it adds 4 bytes of data concerning transport handling initially transmitted with the TCP stream. SMB itself cannot determine which particular TCP packets are part of each individual session that has been established, so it turns over to TCP the responsibility of actually segregating the sessions. SMB can also, however, work in connection with UDP. In this case SMB sends 12 bytes of filler data to help the receiving system put the packets back in their intended sequence.

SMB also has a built-in mechanism that allows a system to transmit multiple requests within the same session. This allows sending requests in parallel rather than serially. The name of this mechanism is AndX; it is a legacy mechanism from earlier days of networking resulting in part from the need to increase the efficiency of connections.

Structure of SMB Packets

Let's look at the structure of the SMB packet. Associated with each offset is a field that carries designated types of data. Table 3.1 lists each offset, field name, and field length in bytes.

• Note that the first offset contains the optional 4-byte length integer field mentioned previously.

• The header start, a mandatory field, starts at offset 4 and is also 4 bytes in length.

• The SMB command field, 1 byte long, is used to communicate to the receiving system that the packet contains a particular SMB command used in a es the "Key" communication.

• The smb_rcls and smb_err fields, both 2 bytes in length, begin at offsets 9 and 11, respectively. These fields, used to transmit, indicate when something goes wrong in these communications and what the nature of the error condition is.

• The 1-byte smb_flg and 2-byte smb_flg2 fields, beginning at offsets 13 and 14, respectively, are fields used to set flags that indicate the status of the communication between SMB-capable hosts.

• The next field beginning at offset 16 is reserved for data in TCP and UDP information that indicates the sequence of packets.

• The TID ("Tree ID") field (starting at offset 28) is for the 2-byte tree ID, a value used for the "tree connect" mechanism that indicates exactly where in the file system on a host to connect when a session that allows such a connection has been established.

• The PID ("Process ID") field (2 bytes long, starting at offset 30) indicates the process ID of the process associated with the network application on the machine sending the packet.

• The UID is an arbitrary user ID (unrelated to the NT logon ID); this field begins at offset 32 and is also 2 bytes long.

• The MID (2 bytes long, beginning at offset 34) is for the machine ID.

• Offset 36 is the beginning point for the 1-byte parameter word count, a field that tells the receiving system how many of the subsequent smb_vwv fields will follow. These smb_vwv fields contain data used in parsing the data that follow in the variable-length buffers.

Table 3.1 The Structure of the SMB Packet

Relationship with the NetBIOS Layer

Networked clients and servers need to how to communicate with each other. They frequently need, for example, to know each other's IP address and computer name. In conventional TCP/IP-based networking, DNS readily provides this kind of information. In the SMB networking arena, however, clients and servers not only require this type of information, but also need information used by the NetBIOS layer of networking. This layer, immediately below SMB in the OSI stack, has it own conventions for communications among other hosts on the network (that is, the NetBIOS names of other hosts). Capability to determine the NetBIOS name depends on a service called the NetBIOS Name Service (nbname). This service, for which the default port binding is UDP port 137, capitalizes on several different sources, including DNS, the Windows Internet Name Service (WINS), direct queries, and broadcasts, to build "name caches" that hold the information about other machines that NetBIOS mechanisms need. Using its own naming conventions, NetBIOS subjects the name that the system administrator assigns to a host to a series of transformations to produce a NetBIOS name.⁶ Table 3.2 shows these steps.

Table 3.2 How NetBIOS Names are Derived

If the name is longer than 15 bytes, the additional bytes are truncated. Then a final byte is appended at the end to indicate the status or meaning of the NetBIOS name. Therefore, the NetBIOS name consists of a 15-byte unicast⁸ hexadecimal value plus a 1-byte trailing hexadecimal value. This last byte pair can assume any of the hexadecimal values indicated in Table 3.3.

Table 3.3 Meaning of the Trailing Hexadecimal Values of a NetBIOS Name⁹

You will see NetBIOS names when you use a packet-capture device to examine network traffic. If your protocol analyzer does not convert NetBIOS names back to computer names, you may have to perform this conversion to identify specific machines referenced in packets. Also, because NetBIOS includes mechanisms for identifying computers with NetBIOS and other sessions to a given host, you can enter the nbtstat command into a Windows command line with the following options to remotely or locally identify these sessions in addition to other information:

nbtstat (-a targethost] [-A IPaddress][-c][-n][-r][-R][-s][-S][interval]

To get a dump of a host's sessions table with the destination IP addresses, for example, enter the following:

nbtstat -S

Similarly, given its host name you can get a host to dump its name table (its name cache) that it creates by entering the following:

nbtstat -a <hostname>

You can get a host to dump its name cache given its IP address by entering the following:

nbtstat -A <IPaddr>

Requests for name cache dump are often called wildcard node status queries. The value of the nbtstat command (the execution of which is not limited to priveleged users) to remote attackers goes without saying.

Client/Server Communications

How are SMB-based client/server communications established? A series of conventions are used in which both client and server pass data to each other until, if everything has gone right, the server establishes the SMB connection to a specific point in its hard drive or other device. This negotiation process occurs in four distinct stages: establishing a TCP session, negotiating a dialect, establishing a SMB connection, and accessing resources.

Stage One: Establishing a TCP session

The first stage of the negotiation process begins when a client sends a Session Request Block to the server. The names of both the server and client (in NetBIOS format) are included in the request. The server does not check the IP address of client, and immediately creates a TCP connection with the client on port 139 of the server (normally TCP 139) on the server.

Stage Two: Negotiating a Dialect

In this stage, the main purpose is to discover the "highest" version of SMB supported by both client and server. What this in essence means is discovering which implementation of MS Networks (the basic LAN implementation used in Microsoft networking) has been used in both the client and server. The particular implementation is known as the "dialect." The various types of dialects, starting with the earliest and ending with the most recent are as follows:

PC Network Program 1.0

XENIX Core

Microsoft Networks 1.03

LanMan 1.0

Windows for Workgroups 3.1a

LM1.2X002

LanMan 2.1

NT LM 0.12

The client sends the names of all dialects that it supports. Therefore if the client is a Windows NT Workstation 4.0, it will understand the most sophisticated dialect, NT LM 0.12. It will, however, forward to the server all the dialects in the preceding list. When the server receives the dialect name(s) from the client, it responds with a dialect list index showing which to use.¹⁰ It also sets security flags (using the smb_flg and smb_flg2 fields in SMB packets) based on how sophisticated a version of SMB has been negotiated. It may additionally send 8 bytes of ciphertext for authentication; whether this is done depends on the particular authentication program. If any part of the dialect-negotiation process fails, the TCP session is terminated.

Stage Three: Establishing an SMB connection

The third stage of establishing SMB communications between a client and server once again starts with the client. The client forwards a session setup request containing a header that includes data, such as the user ID, domain name, operating system, and other (variable) information. The header is usually only 16 bytes long. The server responds by sending a token incorporating the same types of information included in the session startup request, but this time applicable to the server. Unfortunately as discussed earlier in this chapter, each user ID is not necessarily unique across sessions! If the client has sent a username that the server cannot recognize (that is, the user ID is unknown to the server), one of two results occur: denial of access (and, therefore, failure to create an SMB connection); or creation of a "null session," in which the SMB connection is nevertheless established but without a defined user ID. The big problem here is that the strength of authentication depends on the client, not the server. Incidentally, more negotiation must take place to establish an SMB connection if "share-level" security (an option in Win9x, but not in Windows NT) is in place.

Stage Four: Accessing Resources

In the fourth and final stage of the negotiation process between client and server, the server locates the specific point (for example, in the hard drive) to which the SMB connection will be made. The \PIPE\Srvsvc service is used to locate the device, and then a "tree connect" mechanism (based on the Inter Process Communication (IPC) mechanism in MS Networks) is used to access the resources (for example, files, directories, named pipes) within this device. The connection request includes the name of the requestor, TID, password (but only in the case in which share-level security is in place), and the name of the type of service being used to access the resource. The client then returns a 2-byte SMB header with the TID to the server after the tree connection is in place to acknowledge to the server that the connection request succeeded. At this point, a share connection is established, allowing the client to access resources with the restrictions imposed by both share permissions and the file system. (Chapters 5, "Configuring Windows NT Server for Security," and 6, "Maintaining Windows NT Security," provide details concerning how these restrictions work.) Because share connections time out if they are not active, a primitive type of SMB echo mechanism keeps the share active.

5. Many of the facts and ideas in this chapter were developed by Hobbit, an independent vulnerabilities researcher (see http://www.avian.org). His white paper, "CIFS: Common Insecurities Fail Scrutiny," was the basis for most of the content of this particular section of the book.

6. For more information on how to encode/decode NetBIOS names, refer to Knowledge Base article Q194203.

7. The result if the NetBIOS name were to be converted back to ASCII would be EHEMEFCACACACACACACACACACACACACA.

8. Unicast is a format in which each byte pair is separated from the next by a space.

9. This list is not exhaustive.

10. The server also volunteers its file system type to the client during negotiation.