Windows network services internals 1

 
Jean-Baptiste Marchand
Jean-Baptiste.Marchand@hsc.fr
Copyright Hervé Schauer Consultants 2003


Table of Contents
1 Introduction
2 TCIP/IP stack
2.1 General architecture
2.2 No privileged ports
2.3 Dynamic ports allocation
2.4 Identifying opened ports
2.4.1 netstat command
2.4.2 Identifying processes behind sockets
2.5 Sockets binding and hijacking
2.5.1 SO_EXCLUSIVEADDRUSE socket option
2.5.2 Example of multiple bindings: NetBT driver in Windows NT 4.0 SP6a
2.5.3 Multiple sockets bindings
2.5.4 What happens when SO_EXCLUSIVEADDRUSE is not used?
2.5.5 Windows services and drivers protected against socket hijacking
2.5.6 Global protection against socket hijacking
2.5.7 Diagnosing socket binding problems
2.6 The missing network loopback interface
3 SMB/CIFS
3.1 SMB/CIFS protocol
3.2 NetBIOS over TCP/IP
3.3 SMB transports
4 MSRPC, a.k.a. Microsoft implementation of DCE RPC
4.1 Introduction
4.2 DCE RPC Interface
4.3 DCE RPC transports
4.4 RPC services registration
4.5 DCE RPC over named pipes, a.k.a DCE RPC over SMB
4.5.1 Named pipes
4.5.2 Named pipes used as DCE RPC endpoints
4.5.3 Well-known DCE RPC named pipes endpoints
4.6 NULL sessions
4.6.1 Introduction
4.6.2 NULL sessions and infrastructure-level restrictions
4.6.3 NULL sessions - system-level restrictions
4.6.4 How NULL sessions restrictions are implemented
4.6.5 NULL sessions restrictions in Windows XP and Windows Server 2003
4.7 RPC services listening on named pipes
4.7.1 lsarpc interface
4.7.2 samr interface
4.7.3 netlogon interface
4.7.4 browser interface
4.7.5 netdfs interface
4.7.6 srvsvc interface
4.7.7 svcctl interface
4.7.8 winreg interface
4.7.9 wkssvc interface
4.8 RPC services over TCP/IP
4.8.1 Portmapper RPC service
4.8.2 RPC services running in the rpcss service
4.8.3 ORPC services running in the rpcss service
4.9 Windows services running RPC services over TCP/IP
4.9.1 Messenger service
4.9.2 Scheduler service
4.9.3 WINS service
4.9.4 IIS 5 services
4.9.5 Message Queuing and Distributed Transaction Coordinator services
4.9.6 Active Directory related RPC services
4.9.7 File Replication service
4.9.8 Inter-site Messaging service
4.9.9 Windows DNS server
4.9.10 Exchange RPC services
4.9.11 Exchange RPC services in an Active Directory domain
4.10 Other RPC services
4.10.1 Plug and Play service
4.10.2 RPC locator service
4.10.3 DNS Client service - Windows 2000
4.10.4 DNS Client service - Windows XP and Windows Server 2003
4.10.5 EFS
4.10.6 Cryptographic Services service
4.10.7 Security Configuration Editor Engine
4.10.8 Windows Time service
4.10.9 Windows Audio service
4.10.10 Certificate service
4.10.11 DHCP Server service
4.10.12 Terminal Server service
4.10.13 License Logging service
4.10.14 Secondary Logon service
4.10.15 Protected storage service
4.10.16 Telephony service
4.10.17 Remote Access service
4.10.18 IPsec Policy Agent service - Windows 2000
4.10.19 IPsec Services service - Windows XP and Windows Server 2003
4.10.20 Distributed Link Tracking Client service
4.10.21 Distributed Link Tracking Server service
4.10.22 WebClient service
4.10.23 Windows File Protection
4.10.24 System Event Notification service
4.10.25 Wireless Configuration service
4.10.26 Winlogon process - Windows 2000
4.10.27 Winlogon process - Windows Server 2003
4.10.28 Application Management service
4.11 Implication of multiple RPC services in one process
4.11.1 Win32 services hosting
4.11.2 Example of multiple RPC services in one process
4.11.3 Implications of running multiple RPC services in one process
4.12 RPC services protection
4.13 DCOM
4.13.1 COM interfaces
5 Conclusion




1 Introduction
The aim of this paper is to document some not well-known characteristics of Windows systems (based on the NT kernel, i.e Windows NT, Windows 2000, Windows XP and Windows Server 2003) TCP/IP stack and network services.

The first section of the paper focuses on Windows systems TCP/IP stack, highlighting some specificities that are not well known.

The second section briefly mentions the SMB/CIFS protocol, which is probably the most important network protocol on Windows systems (not to be confused with NetBIOS over TCP/IP, as frequently seen, which is just a transport protocol for SMB/CIFS). The reference documentation for SMB/CIFS is Christopher Hertel's book, Implementing CIFS ([1])

The third section deals with MSRPC, a core Windows subsystem that implements a remote procedure call method, used for local processes communication as well as remote procedures calls.

A presentation entitled Windows network services internals and based on this paper was given at the HiverCon03 security conference ([2]). Slides of the presentation are available at http://www.hsc.fr/ressources/presentations/hivercon03/ and contain demonstration screenshots of the different subjects discussed in this paper.


2 TCIP/IP stack
2.1 General architecture
The Windows systems network architecture reference schema is available on the http://www.ndis.com/ website [3].

As usual in Windows systems, the network architecture is very modular but consequently also very complex. This explains why it is, for example, difficult to properly implement an IP filtering software on Windows systems.


2.2 No privileged ports
Unix systems implement privileged ports: ports lower than 1024 can only be used by the system administrator (root user). Considering that typical internet servers run on a low TCP port (for example, 25/tcp for an SMTP server or 80/tcp for an HTTP server), this limitation ensures that only the system administrator can run such servers.

Windows systems do not implement privileged ports. As a consequence, anybody can bind a TCP or UDP server on a low port. As explained later, this has some serious security implications.


2.3 Dynamic ports allocation
In the TCP/IP model, dynamic ports are typically used as source port by a TCP or UDP client, to communicate with a remote TCP or UDP server, using a well-known port as destination port. In Windows systems, dynamic ports are also used by RPC services (in that case, a portmapper service is needed to find the appropriate RPC service).

When an application or driver requests a dynamic TCP or UDP port from the TCP/IP driver, the allocated port belongs by default to the 1025-5000 range (port 1024 is apparently never used on Windows systems).

The upper limit of this range can be changed, modifying the following registry value:
Key: HKLM/SYSTEM/CurrentControlSet/Services/TcpIp/Parameters/Value: MaxUserPort (REG_DWORD)
Default value: 5000 (decimal)

This range is shared for TCP and UDP ports. Moreover, dynamic ports are allocated incrementally. For example, if an application requests a TCP port and obtains TCP port 1025, the next application requesting a UDP port will obtain port 1026.

Exclusion from the dynamic port range can be configured with the ReservedPorts registry value:
Key: HKLM/SYSTEM/CurrentControlSet/Services/TcpIp/Parameters/Value: ReservedPorts (REG_MULTI_SZ)

Configuring this value can be necessary when some services need a fixed port in the lower part of the dynamic range, like 1080/tcp for a SOCKS proxy or 1433/tcp and 1434/udp for MS SQL Server. Otherwise, such ports may be dynamically allocated before services startup, which would cause the service start failure.

However, it seems that the ReservedPorts registry value is also used by the Windows 2000 IPv4 NAT driver [4], to determine which range can be used for source ports of NATed connections.


2.4 Identifying opened ports
2.4.1 netstat command
Systems implementing the TCP/IP protocol typically include the netstat utility, which can be used, among other things, to list opened sockets.

The netstat command of Windows systems is known to be buggy:
Before Windows NT 4.0 SP3, netstat does not display listening TCP ports ([5])
On Windows NT 4.0, netstat displays TCP ports as listening, when sockets are only bound to UDP ports ([6])
The second bug can lead to suprising netstat outputs on Windows NT 4.0 systems. One particularly odd result is that TCP port 135 (used by the rpcss service, as explained later) is displayed twice in netstat outputs:
C:WINNT>netstat -anp tcp | find ":135 "
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 *:*

This is because the rpcss service opens both ports 135/tcp and 135/udp. But, with the bug aforementionned, 135/tcp is displayed a second time. This explains why 135/tcp appears twice.

Another serious bug exists in all versions of Windows NT systems before Windows Server 2003: for each outgoing TCP connection established from a Windows system, the local source port is displayed as LISTENING ([7]).

In the following example, a TCP connection was established to port 22 of a remote server. The TCP/IP driver allocated port 1367 as source port for the connection. In the netstat output, the port appears in the LISTENING state:
C:WINDOWS>netstat -anp tcp | find ":1367"
TCP 0.0.0.0:1367 0.0.0.0:0 LISTENING
TCP 192.70.106.142:1367 192.70.106.76:22 ESTABLISHED

However, this port is not really in the LISTENING state, i.e, it is not possible to establish a new TCP connection on port 1367. Using hping [8] to send a TCP segment with the SYN flag set, a TCP segment with the RST-ACK flags set is returned:
jbm@garbarek ~> sudo hping -S -c 1 192.70.106.142 -p 1367
HPING 192.70.106.142 (ep1 192.70.106.142): S set, 40 headers + 0 data bytes
len=46 ip=192.70.106.142 flags=RA seq=0 ttl=127 id=47511 win=0 rtt=3.7 ms

--- 192.70.106.142 hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 3.7/3.7/3.7 ms

It turns out that this bug comes from an incorrect mapping between TDI objects and TCP sockets.

The Winsock API (implementation of BSD sockets API on Windows systems) is implemented on TCP/IP using the Afd driver, which uses the TDI (Transport Driver Interface) API to communicate with the TCP/IP driver.

To implement an outgoing TCP connection, the Afd driver creates two TDI objets:
a TDI address object
a TDI connection object
Using a simple TCP client (nc.exe, [9]) to establish a TCP connection to port 22 of a remote server:
C:WINNT>nc -z 192.168.1.254 22

the implementation at the TDI level can be monitored, using the TDIMon tool [10]:
1 8246D3F0 IRP_MJ_CREATE TCP:0.0.0.0:0 SUCCESS Address Open
2 8246D3F0 TDI_SET_EVENT_HANDLER TCP:0.0.0.0:1038 SUCCESS Error Event
3 8246D3F0 TDI_SET_EVENT_HANDLER TCP:0.0.0.0:1038 SUCCESS Disconnect Event
4 8246D3F0 TDI_SET_EVENT_HANDLER TCP:0.0.0.0:1038 SUCCESS Receive Event
5 8246D3F0 TDI_SET_EVENT_HANDLER TCP:0.0.0.0:1038 SUCCESS Expedited Receive Event
6 8246D3F0 TDI_SET_EVENT_HANDLER TCP:0.0.0.0:1038 SUCCESS Chained Receive Event
7 8246D3F0 TDI_QUERY_INFORMATION TCP:0.0.0.0:1038 SUCCESS Query Address
8 824C1AE0 IRP_MJ_CREATE TCP:Connection obj SUCCESS Context:0x822CF9B8
9 824C1AE0 TDI_ASSOCIATE_ADDRES TCP:Connection obj SUCCESS TCP:0.0.0.0:1038
10 824C1AE0 TDI_CONNECT TCP:0.0.0.0:1038 192.168.1.254:22 SUCCESS

The output can be interpreted as follow:
line 1, a create request (IRP_MJ_CREATE) for a TDI address object is sent to the TCP/IP driver. The drivers returns an object with 0x8246D3F0 address.
from line 2 to line 6, handlers are associated with the object, for the different events that can occur. In particular, line 4 associates a handler to receive notifications when data arrive on port 1038.
line 8, 9 and 10 show the creation of the TDI object used to represent the outgoing TCP connection. On line 10, the TDI_CONNECT command establishes the TCP connection to port 22 of the machine with 192.168.1.254 as IP address.
Thus, it appears that at the TDI level, a TCP connection is implemented using two TDI objects:
one object representing the TCP connection itself
one object used to receive data sent to the local port
The problem is that the GetTcpTable() API retrieving the content of the current TCP connections table incorrectly translates the second TDI object as a TCP listening socket. As a consequence, the port is displayed as LISTENING by the netstat command.

Note that any tools using this API will report incorrect results. Thus, results of such tools must be analyzed carefully, to filter ports reported as LISTENING.

This bug has been fixed in Windows Server 2003.


2.4.2 Identifying processes behind sockets
Starting with Windows XP, the netstat command can be used to identify which process uses a given socket [11]. Before Windows XP, the following tools can be used:
TCPView [12]
Fport [13]
These tools will give the PID (Process Identifier) of processes using sockets.

However, knowing the PID is not always enough to identify precisely which system component opened a given socket, particularly in the following cases:
Standard Windows services run in a few shared processes (services.exe, svchost.exe). The aforementionned tools return the PID of the process but can not idenfity which service in a shared process opened a given socket. It is then necessary to stop services inside the shared process, to determine which service owns a given socket.
Some sockets are reported as owned by the System process.
On a default Windows system, some sockets will be reported as owned by the System process (pid 8 on Windows 2000, pid 4 on Windows XP and Windows Server 2003): these sockets are opened by drivers communicating directly with the TCP/IP driver in kernel-mode.

It is not possible to statically identify which driver opened a given port. Thus, it is sometimes hard to figure out why a port is opened when it has been opened by a driver. For example, on some Windows systems, port 1025 (the first dynamic port) seems to be opened by an unknown driver at system startup.

The following well-known ports are opened by the following drivers:
137/udp, 138/udp, 139/tcp, 445/tcp, 445/udp: netbt.sys