Window networking / NetBIOS / SMB / CIFS

.1.2 NBT or Not NBT

Before we actually start, there is one more thing to mention: The SMB protocol is supposed to be "transport independent". That is, SMB should work over any reliable transport that meets a few basic criteria. NBT is one such transport, but SMB does not really require the NetBIOS API. It can, for instance, be run directly over TCP/IP.

Just for fun, we will refer to SMB over TCP/IP without NBT as "naked" or "raw". When running naked, SMB defaults to using TCP port 445 instead of the NBT Session Service port (TCP/139). Windows2000, WindowsXP, and Samba all support raw transport, but the large number of "legacy" Windows clients still in use suggest that NBT will not go away any time soon.

Other than the new port number, there are only two notable changes between NBT and naked transport. The first is that naked transport does not make use of the NBT SESSION REQUEST and POSITIVE SESSION RESPONSE messages. The second is that the two transports interpret the SESSION MESSAGE header a bit differently.

Recall (from section 1.6) that the NBT Session Service prepends a four-byte header to each SESSION MESSAGE, like so:

0 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 3 0 3 1

0 (zero) <reserved> LENGTH (17 bits)

The LENGTH field, as shown, is 17 bits wide⁵. Raw TCP transport also prepends a four-byte header, but the full 24 bits are available for the LENGTH:

0 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 3 0 3 1

0 (zero) LENGTH (24 bits)

Window networking / NetBIOS / SMB / CIFS

Windows networking is a set of protocols and services that allow Windows machines to communicate to provide facilities such as file and printer sharing and work group and domain browsing.

This section contains a brief overview of how Windows Networking works.

The next section Configuring Windows networking for KFSensor describes how to configure Windows to enable KFSensor to emulate Windows networking.

The following section KFSensor Windows networking emulation describes how KFSensor emulates Windows networking and how to configure it and interpret the events it generates.

Windows Networking

Windows Networking is extremely complex and confusing to understand given its long history of development.

Back in the old days of DOS machines could communicate with each other using a protocol called NetBIOS. This ancient protocol is inferior in almost every aspect to the IP protocol. Pure NetBIOS is hardly ever used a anymore on modern networks.
However Microsoft could not abandon it completely as so much software, including their own, relied upon it. Microsoft introduced NetBIOS over TCP/IP (NBT). NBT allows the NetBIOS API to run over an IP network.

Microsoft introduced another protocol called Common Internet File System (CIFS) which enables the core functionality of Windows Networking; file and printer sharing and domain. The core of CIFS is a protocol called the Server Message Block (SMB). The SMB sits on top of NBT as its transport layer. SMB can be implemented on other protocols other than NBT, as described later on. The long term intention of Microsoft is to abandon NBT.

While NBT is essentially a Windows protocol, there exists a module for Linux called Samba that allows Linux to provides services to Windows clients.

With all these abbreviations it can get very confusing. KFSensor just uses NBT to refer to its components that deal with Windows networking, even though strictly speaking some of these components, have nothing to do with NBT.

NetBIOS Names

NetBIOS names are used to identify machines and workgroups and form the key building blocks of the NBT system.
The names are limited to sixteen characters that are always in upper case.
The sixteenth character of a NetBIOS name is used to indicate the type of service the name refers to. A Windows machine will thus own several names that vary only by their sixteenth character.

NetBIOS names are usually encoded into a special 32 character format which makes them un-readable unless they are decoded.

There are four separate services that are used to implement Windows networking.
KFSensor emulates each one of these as described in the following sections.

Service	Port	Description
NetBIOS Name Service (NBNS)	UDP 137	NBNS is also known as Windows Internet Name Service (WINS). The job of NBNS is to match IP addresses with NetBIOS names and allow queries to be made of the matches. The name service is usually the first service that will be attacked. A visitor will need the information it can provide to begin a session on the other services.
NetBIOS Datagram	UDP 138	The Datagram service is used receive broadcasts of SMB packets via UDP. This service receives a lot of legitimate traffic from other Windows machines on the LAN as they broadcast their names and services. It is rare for an attacker to use this service, unless they are trying to add their machine to the windows network.
NetBIOS Session Service	TCP 139	The Session Service is used to handle NBT sessions. NBT sessions are a light weight protocol used to contain an SMB session. The SMB protocol and sessions based on it are used to provide the complex functionality of the services supported by Window's networking; such as file and print sharing. This is the service that attackers will be most interested in.
SMB Direct	TCP 445	In Windows 2000 Microsoft introduced an implementation of SMB that does not need NBT to communicate. This service is in practice the same as the NetBIOS Session Service, but without the additional NBT protocol around the SMB session. The SMB Direct is not supported in older Windows versions. The older hacker tools do not target this service, instead they go for the NetBIOS Session Service.

On an IP LAN:	Each node keeps a list of the names that it has registered (that is, the names it "owns"). When sending a message, the first step is to send an IP broadcast query, called a `NAME QUERY REQUEST`. If there is a machine on the IP LAN that owns the queried name, it will reply by sending a `NAME QUERY RESPONSE`. So, to send a message to the node which has registered the name `EADFRITH` the sender calls out "Yo! Eadfrith!". `EADFRITH` responds with an "I am here!" message, giving its IP address. [Figure 1.3] This is known as 'B mode' (broadcast) name resolution, and participants are referred to as 'B nodes'. In B mode, each node keeps track of--and answers queries for--its own names, so the NetBIOS Name Service "database" is a distributed database.

Each node keeps a list of the names that it has registered (that is, the names it "owns"). When sending a message, the first step is to send an IP broadcast query, called a NAME QUERY REQUEST. If there is a machine on the IP LAN that owns the queried name, it will reply by sending a NAME QUERY RESPONSE.

So, to send a message to the node which has registered the name EADFRITH the sender calls out "Yo! Eadfrith!". EADFRITH responds with an "I am here!" message, giving its IP address.

[Figure 1.3]

This is known as 'B mode' (broadcast) name resolution, and participants are referred to as 'B nodes'. In B mode, each node keeps track of--and answers queries for--its own names, so the NetBIOS Name Service "database" is a distributed database.

B mode Name Resolution

Over a Routed Internet:	Broadcasts aren't meant to cross subnet boundaries, so a different mechanism is used when the nodes are separated by routers. The Network Administrator chooses a machine to be the NetBIOS Name Server (NBNS, aka WINS Server²). Typically this will be a Unix host running Samba, or a Windows NT or W2K server. In order to use the NBNS, all of the nodes that are participating in the virtual NetBIOS LAN must be given the server's IP address. This can be done by entering the address in the client's NetBIOS configuration or, on Windows systems, via DHCP. NBT client nodes send NetBIOS name registrations and queries directly to the NBNS, which maintains a central database of all registered names in the virtual LAN. This is known as 'P mode' (point-to-point) name resolution, and participants are referred to as 'P nodes'.

Over a Routed Internet:

Broadcasts aren't meant to cross subnet boundaries, so a different mechanism is used when the nodes are separated by routers.

The Network Administrator chooses a machine to be the NetBIOS Name Server (NBNS, aka WINS Server²). Typically this will be a Unix host running Samba, or a Windows NT or W2K server. In order to use the NBNS, all of the nodes that are participating in the virtual NetBIOS LAN must be given the server's IP address. This can be done by entering the address in the client's NetBIOS configuration or, on Windows systems, via DHCP.

NBT client nodes send NetBIOS name registrations and queries directly to the NBNS, which maintains a central database of all registered names in the virtual LAN. This is known as 'P mode' (point-to-point) name resolution, and participants are referred to as 'P nodes'.

P mode Name Resolution

Node Bede registers its name with Cuthbert, the NBNS (WINS server).
Node Backhouse sends a query to Cuthbert when looking for Bede.
Cuthbert provides the IP address of Bede to Backhouse.

These are the two basic modes of NetBIOS Name Resolution over NBT. There are, of course, others. The RFCs describe 'M mode' (mixed mode), which combines P and B mode characteristics. 'H mode' (hybrid mode) was introduced later. It is similar to M mode except for the order in which B and P mode behavior is applied.

The Name Service runs on UDP port 137. According to the RFCs the use of TCP port 137 can be negotiated for some queries, though few (if any) implementations actually support this.

The NetBIOS LAN architecture is very simple. No routers, no switches--just a bunch of nodes connected to a (virtual) wire. There is no need for separate hardware addresses, network addresses, or even port numbers as there is in IP. Instead, the communications endpoints are identified by 16-byte strings known as "NetBIOS Names".

NetBIOS addressing is dynamic. Applications may add names as needed, and remove those names when they are finished. Each node on the LAN will also have a default name, known as the Machine Name or the Workstation Service Name, which is typically added when NetBIOS starts. The process of adding a name is called registration.

There are two kinds of names that can be registered: unique and group. Group names may be shared by multiple clients, thus providing a mechanism for multicast. In contrast, unique names may only be used by one client per LAN. Keep in mind, though, that these are virtual LANs which may actually be spread out across different subnets in a routed IP internetwork.

Group Name

In addition to their Machine Names, some of the nodes on this IP LAN
have registered the group name Lindisfarne. Nodes Mick and Ringo

are not members of the group Lindisfarne.

1.2.1.2 The NetBIOS Datagram Service

In the IP world, TCP provides connection-oriented sessions in which packets are acknowledged, put in order, and retransmitted if lost. This creates the illusion of a continuous, sequential data stream from one end to the other. In contrast, UDP datagrams are simply sent. Thus, UDP requires less overhead, but it is less reliable than TCP. NetBIOS also provides connection-oriented (session) and connectionless (datagram) communications. Naturally, NBT maps NetBIOS sessions to TCP and NetBIOS datagrams to UDP.