Windows network services internals 1

 
Jean-Baptiste Marchand
[e-mail]
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
source ports used for outgoing SMB sessions (with a TCP destination port equal to 139/tcp or 445/tcp): netbts.sys
1701/udp, 1723/tcp: raspptp.sys


2.5 Sockets binding and hijacking
As explained earlier, Windows TCP/IP stack does not implement privileged ports. More precisely, any process can bind a socket to any port, even when a socket is already bound to a port. Thus, it becomes possible to hijack a TCP server.

This kind of vulnerability was published for the first time in february 1998, in the security advisory NT port binding security [14].

This advisory showed how, for example, any user could hijack the Windows NT 4 SMB server, binding a TCP server on port TCP 139 using a specific IP address in the bind() call.

Microsoft released knowledge base article 194431 [18], mentionning the problem and stating that it was fixed in Windows NT 4.0 Service Pack 4.

Actually, Microsoft introduced in NT 4.0 Service Pack 4 a new socket option, SO_EXCLUSIVEADDRUSE, that can be used by an application to protect itself from this vulnerability. However:
it seems that Microsoft itself did not use this socket option in its servers (particularly, IIS 4 and IIS 5)
this socket option can not be used by drivers, which directly communicate with the TCP/IP driver, without using the Winsock API.

2.5.1 SO_EXCLUSIVEADDRUSE socket option
The SO_EXCLUSIVEADDRUSE socket option is documented as follow in MSDN [19]:
The SO_EXCLUSIVEADDRUSE option prevents other sockets from being forcibly bound to the same address and port, a practice enabled by the SO_REUSEADDR option; such reuse can be executed by malicious applications to disrupt the application.
Thus, when this socket option is used by an application before using the bind() function, no other application will be able to bind to the same local address, even when the SO_REUSEADDR is used, as does nc.exe.

As said earlier, the Winsock API is implemented by the Afd driver, which interacts with the TCP/IP driver using the TDI interface. At the TDI level, TCP and UDP ports are represented by file objects.

The implementation of the SO_EXCLUSIVEADDRUSE socket option opens file objects in exclusive mode, setting the ShareAccess parameter of the ZwCreateFile() function to 0. Thus, file objects representing TCP and UDP ports can only be opened in exclusive mode, which correspond to exclusive binding at the Winsock level.


2.5.2 Example of multiple bindings: NetBT driver in Windows NT 4.0 SP6a
Follows a demonstration of multiple bindings on a Windows NT 4.0 SP6a system. As NetBIOS over TCP/IP is active on the system, TCP Port 139 is opened by the NetBT driver and bound to IP address 192.70.106.143:
C:>netstat -an | find "139"
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING

Then, a nc.exe process is bound to the same port and same IP address:
C:>nc -l -p 139 -s 192.70.106.143

C:>netstat -an | find "139"
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING
TCP 192.70.106.143:139 0.0.0.0:0 LISTENING

The next TCP connection will be routed to the nc.exe process, hijacking the SMB server.

Using socat [15] to establish a TCP connection to port 139 of IP address 192.70.106.143, the blah string is sent:
jbm@garbarek ~> socat - tcp4:192.70.106.143:139
blah

The blah string is received by the nc.exe process.
C:>nc -l -p 139 -s 192.70.106.143
blah

C:>

An interesting way to exploit this vulnerability would be to setup an SMB redirector, that would redirect all SMB trafic to another machine [16].

When Microsoft introduced the SO_EXCLUSIVEADDRUSE socket option in Windows NT 4.0 Service Pack 4, it did not fixed that problem because the NetBT driver was not modified to set the ShareAccess parameter of ZwCreateFile() functions calls to 0.

A fix for the NetBT driver was finally introduced in the C2 Update Post-SP6a hotfix, because one TCSEC C2 requirement mandates that an unprivileged user-mode program should not be able to listen to ports used by Windows NT services [17].

This fix is also available in the Windows NT 4.0 Security Rollup Package. To enable it, the following registry value must be configured:
Key: HKLM/SYSTEM/CurrentControlSet/Services/NetBT/Parameters
Value: EnablePortLocking (REG_DWORD)
Content: 0 to disable protection (default), 1 to enable protection

2.5.3 Multiple sockets bindings
Considering TCP servers, there are different case of multiple sockets bindings, that can occur when the first server did not specify SO_EXCLUSIVEADDRUSE and when the second server specifies SO_REUSEADDR is used by the second server
One TCP server bound to all interfaces (INADDR_ANY or 0.0.0.0) and then, a second TCP server bound to a specific interface
One TCP server bound to a specific interface and then, a second TCP server bound to all interfaces
One TCP server bound to a specific interface and then, a second TCP server to another specific interface
One TCP server bound to a specific interface and then, a second TCP server bound to the same specific interface
The first case is a serious security problem. This means that if a TCP server is bound to all interfaces, it is later possible to start a TCP server bound to the same port but on a specific interface. The second TCP server will receive all TCP connection segments sent to the IP adress of the specific interface.

As the TCP/IP stack does not implement privileged ports, it is possible to disrupt any TCP servers using this technique.

The second case is not a security problem. The second server will receive TCP connection segments sent to any IP address different from the IP address of the specific interface.

The third case is not a security problem, as the two servers are listening on different specific interfaces.

The fourth case is problematic because two TCP servers are bound to exactly the same local address (same port and same IP address). The MSDN documentation [19] explains that in that case, the behavior is undefined as to which sockets will receive incoming connection requests.

However, it seems that on Windows NT 4.0, the second server will receive packets, which is the worst case because this means that the first server is hijacked. This is what happens with the NeBT driver on Windows NT 4.0 SP6a, as seen earlier.

As a conclusion, it seems important to use the SO_EXCLUSIVEADDRUSE socket option to prevent sockets hijacking.


2.5.4 What happens when SO_EXCLUSIVEADDRUSE is not used?
Even if Microsoft introduced the SO_EXCLUSIVEADDRUSE socket option in Windows NT 4.0 Service Pack 4, it seems that it was not used in some Microsoft application servers.

For example, the http server part of Microsoft IIS 5 listens by default on all interfaces on port 80 and 443. It is possible to hijack the IIS 5 server with a TCP server bound to the IP address of a specific interface.

Even more interesting, when a TCP server listens on all interfaces, it is possible to silently intercept TCP traffic, binding a second TCP server to intercept trafic and redirecting to the loopback address, to finally deliver date to the hijacked server (thanks to Franck Davy for suggesting this).

On a Windows 2000 server with IIS 5, the HTTP service listens on all interfaces:
C:WINNT>netstat -an | find "80"
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING

Using fpipe, a second TCP server is bound to IPv4 address 192.70.106.142 and configured to redirect traffic to the loopback address (127.0.0.1), with TCP port 80 as destination:
C:WINNT>fpipe -l 80 -r 80 -i 192.70.106.142 127.0.0.1 -v
FPipe v2.1 - TCP/UDP port redirector.
Copyright 2000

3 SMB/CIFS
3.1 SMB/CIFS protocol
The SMB (Server Message Block) protocol, renamed at some point CIFS (Common Internet File System), is the protocol behind resource sharing and remote administration functionnalities in Windows systems.

For a thorough explanation of the SMB/CIFS protocol, see the SMB chapter [23] of Christopher Hertel's book, Implementing CIFS.


3.2 NetBIOS over TCP/IP
NetBIOS over TCP/IP uses 3 ports:
137/UDP, for NetBIOS name resolution, using broadcast or a WINS server
138/UDP, for session-less NetBIOS
139/TCP, for session-oriented NetBIOS
The NetBIOS API uses names to identify network ressources. The nbtstat command can be used to examine and configure NetBIOS names on a Windows system.

NetBIOS over TCP/IP in itself is just a transport protocol. However, as it is the typical transport protocol for the SMB/CIFS protocol in Windows systems, it is often confused with the SMB/CIFS protocol, which does the dirty work on Windows systems.

For technical details about NetBIOS over TCP/IP, the reference documentation is the NBT chapter [24] of Christopher Hertel's book, Implementing CIFS.


3.3 SMB transports
Before Windows 2000, the typical transport protocol of SMB/CIFS was NetBIOS over TCP/IP. Starting with Windows 2000, SMB/CIFS can be carried directly into TCP (445/tcp), without an intermediary NetBT layer.

To identify which SMB transports are active on a Windows system, the net config rdr and net config srv commands can be used. These commands use the NetWkstaTransportEnum() and NetServerTransportEnum() Win32 API:
C:WINNT>net config rdr

[...]

Workstation active on
NetbiosSmb (000000000000)
NetBT_Tcpip_{33227EBB-55A3-49EA-823D-51836B978EFD} (000102A495B2)

[...]

C:WINNT>net config srv

[...]

Server is active on
NetBT_Tcpip_{33227EBB-55A3-49EA-823D-51836B978EFD} (000102a495b2)
NetBT_Tcpip_{33227EBB-55A3-49EA-823D-51836B978EFD} (000102a495b2)
NetbiosSmb (000000000000)
NetbiosSmb (000000000000)

[...]


The NetWkstaTransportEnum() and NetServerTransportEnum() Win32 API are implemented by two RPC calls, NetrWkstaTransportEnum() and NetrServerTransportEnum(). Samba-TNG [25] rpcclient utility supports the srvtransports command, that can be used to retrieve server-side transports.

Note: Windows NT 4.0 and Windows 2000 systems apparently have a bug in the NetServerTransportEnum() API, which retrieves server-side transports: each transport appears twice.

Active transports are:
NetbiosSmb is the raw SMB transport (445/tcp) [26].
NetBT_Tcpip_{...} is the NetBT SMB transport, bound on a per-adapter basis
The raw SMB transport can not be disabled on a per-adapter basis. To completely disable it, the NetBT driver must be stopped.

A Windows system with both SMB transports active tries to connect to 445/tcp and 139/tcp at the same time. If the connection to 445/tcp is accepted, the connection to port 139 is closed (sending a TCP segment with the RST flag set), i.e., raw SMB transport is preferred over NetBT transport [27].


4 MSRPC, a.k.a. Microsoft implementation of DCE RPC
4.1 Introduction
The RPC (Remote Procedure Call) mechanism allows an application to seamlessly invoke remote procedures, as if these procedures were executed locally.

There are two main implementations of the RPC mechanism:
ONC RPC [28]
DCE RPC [29]
MSRPC is the Microsoft implementation of the DCE RPC mechanism. In particular, Microsoft added new transport protocols for DCE RPC, in particular the ncacn_np transport, which use named pipes carried into the SMB protocol.

For an interesting story of Windows and how Microsoft choose to implement DCE RPC, see the A brief history of Windows article [30].


4.2 DCE RPC Interface
An interface is a set of related operations (procedures) that can be invoked remotely. Each interface is distinguished by an interface identifier (ifid) and an interface version number.

For a detailed explanation of DCE RPC interface, see figure 2.2 [31] in the DCE RPC 1.1 documentation.
4.3 DCE RPC transports
The RPC mechanism has been designed to be transport-independant: different protocols can be used to transport remote procedure parameters and execution results.

More precisely, transport protocols are identified with protocol sequences identifiers. Windows systems typically use the following protocol sequences:
ncacn_ip_tcp: TCP/IP transport
ncadg_ip_udp: UDP/IP transport
ncacn_np: named pipes transport, using SMB
ncalrpc: local RPC
ncacn_http: HTTP transport, using IIS
An endpoint is the entity used at the transport level to invoke remotely a RPC service. Endpoint nature is specific to each protocol sequences:
ncacn_ip_tcp: TCP port
ncadg_ip_udp: UDP port
ncacn_np: named pipe
ncalrpc: LPC port
ncacn_http: 593/tcp
Most LPC ports are DCE RPC endpoints. Using the Winobj tool [32], you can see a list of LPC ports used as DCE RPC endpoints on a running system, under the RPC Control subdirectory of the NT kernel Object Manager namespace.

However, not all TCP or UDP ports are DCE RPC endpoints, as well as not all named pipes.

One method to identify if a TCP port, UDP port or named pipe is a DCE RPC endpoint is to try to bind to the RPC service supposedly listening on the supposed endpoint. If the bind operation fails or blocks, then the tested endpoint is probably not a DCE RPC endpoint.

The ifids tool, part of Todd Sabin's RPC Tools [33] can be used to identify RPC services endpoints. A demonstration of this tool is given in [36].


4.4 RPC services registration
When a RPC service starts, it can register its endpoints along with the interface identifier and version of the service. A special RPC service, the portmapper service, maintains a database, the endpoint map, that can be queried to find out endpoints that can be used to invoke a given RPC service.

When a RPC service listens on a TCP or UDP endpoint, it must register itself in the endpoint map because TCP and UDP ports are dynamically allocated to RPC services.

To query the portmapper RPC service, the rpcdump tool [33] can be used. In the output of that command, ncacn_ip_tcp and ncadg_ip_udp correspond to dynamically allocated ports.


4.5 DCE RPC over named pipes, a.k.a DCE RPC over SMB
4.5.1 Named pipes
In Windows systems, named pipes in one of the avalailable IPC (Inter-Process Communication) mechanism. It can be used either locally or remotely.

Accesses to remote named pipes, contained in the IPC$ share, are carried into the SMB protocol.

Named pipes are implemented by a file system driver, npfs.sys. The PipeList [34] tool can be used to enumerate the npfs namespace, to show which named pipes are opened on a local system.

Some named pipes are implemented as aliases [35], i.e, they don't really exist in the npfs namespace. Aliases names are stored in the registry:
Key: HKLM/SYSTEM/CurrentControlSet/Services/Npfs/Aliases/Values: lsass, ntsvcs

Named pipes are protected by security descriptors, just like any Windows NT objects. The pipeacl tool ([37] or [38]) be used to examine the content of security descriptors protecting named pipes.


4.5.2 Named pipes used as DCE RPC endpoints
Some named pipes are used as DCE RPC endpoints, i.e, they are used to carry DCE RPC PDU (Protocol Data Units). Compared to other RPC transports, the ncacn_np is different because it is authenticated (at the SMB layer, except when NULL sessions are used, as explained later).

Also, contrary to RPC services listening on ncacn_ip_tcp or ncadg_ip_udp, a portmapper service is not necessary for RPC services using named pipes, as the name of the named pipe identifies the RPC service.


4.5.3 Well-known DCE RPC named pipes endpoints
The following table gives a list of named pipes that are used as endpoints by Windows RPC services. The interface identifier associated to each named pipe represents the service typically accessed when a given named pipe is used.

However, due to the fact that any endpoint in a given process can be used to reach any RPC service, it is possible to use multiple RPC services using a single named pipe endpoint.

Named pipe Description Win32 service or process Interface identifier
atsvc Scheduler service mstask.exe 1ff70682-0a51-30e8-076d-740be8cee98b v1.0
AudioSrv Windows Audio service AudioSrv 3faf4738-3a21-4307-b46c-fdda9bb8c0d5 v1.0
browser(ntsvcs alias) Computer Browser Browser 6bffd098-a112-3610-9833-012892020162 v0.0
cert Certificate service certsrv.exe 91ae6020-9e3c-11cf-8d7c-00aa00c091be v0.0
Ctx_WinStation_API_service Terminal Services remote management termsrv.exe 5ca4a760-ebb1-11cf-8611-00a0245420ed v1.0
DAV RPC SERVICE WebDAV client WebClient c8cb7687-e6d3-11d2-a958-00c04f682e16 v1.0
dnsserver DNS Server dns.exe 50abc2a4-574d-40b3-9d66-ee4fd5fba076 v5.0
epmapper RPC endpoint mapper RpcSs e1af8308-5d1f-11c9-91a4-08002b14a0fa v3.0
eventlog(ntsvcs alias) Eventlog service Eventlog 82273fdc-e32a-18c3-3f78-827929dc23ea v0.0
HydraLsPipe Terminal Server Licensing lserver.exe 3d267954-eeb7-11d1-b94e-00c04fa3080d v1.0
InitShutdown (Remote) system shutdown winlogon.exe 894de0c0-0d55-11d3-a322-00c04fa321a1 v1.0
keysvc Cryptographic services CryptSvc 8d0ffe72-d252-11d0-bf8f-00c04fd9126b v1.0
keysvc Cryptographic services CryptSvc 0d72a7d4-6148-11d1-b4aa-00c04fb66ea0 v1.0
locator RPC Locator service locator.exe d6d70ef0-0e3b-11cb-acc3-08002b1d29c4 v1.0
llsrpc License Logging service llssrv.exe 342cfd40-3c6c-11ce-a893-08002b2e9c6d v0.0
lsarpc(lsass alias) LSA access lsass.exe 12345778-1234-abcd-ef00-0123456789ab v0.0
lsarpc(lsass alias) LSA DS access lsass.exe 3919286a-b10c-11d0-9ba8-00c04fd92ef5 v0.0
msgsvc(ntsvcs alias) Messenger service messenger 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc v1.0
netdfs Distributed File System service Dfssvc 4fc742e0-4a10-11cf-8273-00aa004ae673 v3.0
netlogon(lsass alias) Net Logon service Netlogon 12345678-1234-abcd-ef00-01234567cffb v1.0
ntsvcs Plug and Play service services.exe 8d9f4e40-a03d-11ce-8f69-08003e30051b v1.0
policyagent IPSEC Policy Agent(Windows 2000) PolicyAgent d335b8f6-cb31-11d0-b0f9-006097ba4e54 v1.5
ipsec IPsec Services PolicyAgent 12345678-1234-abcd-ef00-0123456789ab v1.0
ProfMapApi Userenv winlogon.exe 369ce4f0-0fdc-11d3-bde8-00c04f8eee78 v1.0
protected_storage Protected Storage lsass.exe c9378ff1-16f7-11d0-a0b2-00aa0061426a v1.0
ROUTER Remote Access mprdim.dll 8f09f000-b7ed-11ce-bbd2-00001a181cad v0.0
samr(lsass alias) SAM access lsass.exe 12345778-1234-abcd-ef00-0123456789ac v1.0
scerpc Security Configuration Editor (SCE) services.exe 93149ca2-973b-11d1-8c39-00c04fb984f9 v0.0
SECLOGON Secondary logon service seclogon 12b81e99-f207-4a4c-85d3-77b42f76fd14 v1.0
SfcApi Windows File Protection winlogon.exe 83da7c00-e84f-11d2-9807-00c04f8ec850 v2.0
spoolss Spooler service spoolsv.exe 12345678-1234-abcd-ef00-0123456789ab v1.0
srvsvc(ntsvcs alias) Server service lsass.exe 4b324fc8-1670-01d3-1278-5a47bf6ee188 v3.0
ssdpsrv SSDP service ssdpsrv 4b112204-0e19-11d3-b42b-0000f81feb9f v1.0
svcct(ntsvcs alias) Services control manager services.exe 367aeb81-9844-35f1-ad32-98f038001003 v2.0
tapsrv Telephony service Tapisrv 2f5f6520-ca46-1067-b319-00dd010662da v1.0
trkwks Distributed Link Tracking Client Trkwks 300f3532-38cc-11d0-a3f0-0020af6b0add v1.2
W32TIME(ntsvcs alias) Windows Time(Windows 2000 and XP) w32time 8fb6d884-2388-11d0-8c35-00c04fda2795 v4.1
W32TIME_ALT Windows Time(Windows Server 2003) w32time 8fb6d884-2388-11d0-8c35-00c04fda2795 v4.1
winlogonrpc Winlogon winlogon.exe a002b3a0-c9b7-11d1-ae88-0080c75e4ec1 v1.0
winreg Remote registry service RemoteRegistry 338cd001-2244-31f1-aaaa-900038001003 v1.0
winspipe WINS service wins.exe 45f52c28-7f9f-101a-b52b-08002b2efabe v1.0
wkssvc(ntsvcs alias) Workstation service lsass.exe 6bffd098-a112-3610-9833-46c3f87e345a v1.0

4.6 NULL sessions
4.6.1 Introduction
NULL sessions refer to the possibility to use unauthenticated SMB sessions to the IPC$ share to gather information anonymously, using RPC function calls carried into SMB.

SMB sessions are typically authenticated. However, it is possible to use an empty username and password, which results in a NULL session, i.e an anonymous SMB session.


4.6.2 NULL sessions and infrastructure-level restrictions
The NT security token (impersonation token) associated to an anonymous network logon session (NULL session) contains the EVERYONE SID. Thus, if the DACL (Discretionnary Access Control List) of a share allows the EVERYONE SID, it should be possible to connect to it.

Actually, this was the case until Microsoft added NULL sessions restrictions in WIndows NT 3.5. These restrictions are enabled by the following registry value, which is enabled by default starting with NT 3.5:
Key: HKLM/SYSTEM/CurrentControlSet/Services/LanmanServer/Parameters Value: RestrictNullSessAccess (REG_DWORD)
Content: 1 to enable NULL sessions restrictions (default value)

The first category of restrictions allows the administrator to configure which shares can be used anonymously:
Key: HKLM/SYSTEM/CurrentControlSet/Services/LanmanServer/Parameters Value: NullSessionShares (REG_SZ)

This registry value is also set by a security option, starting with Windows XP:
Network access: Shares that can be accessed anonymously
On default Windows systems, this value contains the COMCFG and DFS$ shares.

The IPC$ share does not appear in this registry value. However, it is always possible to connect anonymously to it. Restrictions for the IPC$ share are implemented at the named pipes level:
Key: HKLM/SYSTEM/CurrentControlSet/Services/LanmanServer/Parameters Value: NullSessionPipes (REG_SZ)

On default Windows NT 4.0 systems, the following named pipes can be opened in the context of a NULL session:
Key: HKLM/SYSTEM/CurrentControlSet/Services/LanmanServer/Parameters Value: NullSessionPipes (REG_SZ)
Default value: COMNAP COMNODE SQLQUERY SPOOLSS LLSRPC EPMAPPER LOCATOR WINREG

On default Windows 2000 systems, there are two more named pipes (TrkWks and TrkSvr, opened by the Distributed Link Tracking Client and Distributed Link Tracking Server services):
Key: HKLM/SYSTEM/CurrentControlSet/Services/LanmanServer/Parameters Value: NullSessionPipes (REG_SZ)
Default value: COMNAP COMNODE SQLQUERY SPOOLSS LLSRPC EPMAPPER LOCATOR TrkWks TrkSvr

Starting with Windows XP, this registry value can be set via a security option:
Network access: Pipes that can be accessed anonymously
However, just like IPC$ does not appear in the NullSessionShares value, it is always possible to anonymously connect to the following pipes, which are hardcoded in the npfs.sys driver:
pipelsarpc, pipesamr, pipenetlogon (pipelsass aliases)
pipewkssvc, pipesrvsvc, pipebrowser (pipentsvcs aliases)

Thus, it is possible to open the lsarpc named pipe in the context of a NULL session (but not the lsass named pipe, even if the first one is an alias of the second one, as explained earlier).

As for named pipes permissions, it is possible to use the pipeacl tool mentionned earlier to examine security descriptors set on named pipes.

In Windows 2000, named pipes DACL seem to grant permissions to the EVERYONE group and Administrators builtin. In Windows Server 2003, the DACL grant permissions to EVERYONE, ANONYMOUS LOGON and Administrator, because in Windows XP and Windows Server 2003, the following registry value is set to 0:
Key: HKLM/SYSTEM/CurrentControlSet/Control/LSA Value: EveryoneIncludesAnonymous
Content: 0 (default value)

The counterpart security option is:
Network access: Let Everyone permissions apply to anonymous users (disabled by default)
4.6.3 NULL sessions - system-level restrictions
Actually, NULL sessions have security implications because the security context of a NULL session contains the EVERYONE SID. Thus, the EVERYONE group includes anonymous users and, if a DACL allows some accesses for the EVERYONE group, such accesses can be executed in the context of a NULL session. Microsoft introduced the AUTHENTICATED USERS group in Windows NT 4.0 SP3, that contains only authenticated users. This group can be used to grant permissions instead of EVERYONE.

Also, starting with Windows NT 4.0 SP3, the LSA (Local Security Authority) can be configured to restrict the capabilities of a NULL session, with the following registry value:
Key: HKLMSYSTEMCurrentControlSetControlLSAValue: RestrictAnonymous
Content: 0 (no restriction), 1 (some restrictions), 2 (only valid in Windows 2000 and later)

This registry value is also a group policy security option, starting with Windows 2000:
Additional restrictions for anonymous connections
Setting RestrictAnonymous to 2 completely disables NULL session, because, in that case, the NT security token of a NULL session no longer contains the EVERYONE SID. Thus, connection to the IPC$ share fails, as the share permissions are set for the EVERYONE SID.

When RestrictAnonymous is set to 1 in Windows NT or Windows 2000, it is still possible to gather some interesting information anonymously [39], using the appropriate functions calls and tools [40].


4.6.4 How NULL sessions restrictions are implemented
NULL sessions restrictions for the LSA RPC service (lsarpc named pipe) and SAM RPC service (samr named pipe) are implemented with:
ACL on the LSA policy objects
ACL on the SAM objects hierarchy
The ACL tools package [41] contains the lsasacl and samacl tools, which can be used to examine DACL on these objects. As a side note, you can also examine SACL on these objects and understand why 560 and 565 events appear in the Windows Security eventlog once you enable object access auditing, as described in [42].

Restrictions for the lanmanserver and lanmanworkstation RPC services calls (srvsvc and wkssvc named pipes) are apparently hardcoded and documented in MSDN, under the Security requirements section. Sometimes, depending on the requested information level, it is necessary (or not) to be a member of the Administrators or Account Operators local group.

For some functions, the Security requirements section mentions the Pre-Windows 2000 Compatible Access, which exists on domain controllers. When this group contains the Everyone SID, it is possible to anonymously retrieve information on a domain controller. Thus, when possible, the Everyone SID must be removed from this group.

On workstations or member servers, only authenticated users can retrieve information (except when anonymous restrictions are disabled with RestrictAnonymous set to 0).


4.6.5 NULL sessions restrictions in Windows XP and Windows Server 2003
Windows XP and Windows Server 2003 have security options that can be used to specify more precisely which restrictions are enabled:
Network access: Allow anonymous SID/Name translation (Disabled by default)
Network access: Do not allow anonymous enumeration of SAM accounts (Enabled by default)
Network access: Do not allow anonymous enumeration of SAM accounts and shares (Disabled by default)
When the first security option is enabled, the DACL on the LSA policy object is modified, as shown with the lsaacl tool:
When the option is disabled, an ACE explicitly denies anonymous the Lookup Names access for the ANONYMOUS LOGON SID
When it is set, this ACE is modified, to allow the View Local Info and Lookup Names accesses for the ANONYMOUS LOGON SID.
The second security option modifies the ACE on SAM hierarchy objects, replacing the EVERYONE SID by the AUTHENTICATED USERS SID. This change is not dynamic and requires a reboot, unlike the previous security option.

The third security option sets the RestrictAnonymous registry value to 1.

The equivalent of RestrictAnonymous set to 2 in Windows XP and Windows Server 2003 is the security option mentionned earlier, which sets the EveryoneIncludesAnonymous registry value:
Network access: Let Everyone permissions apply to anonymous users (disabled by default)
4.7 RPC services listening on named pipes
This section gives a list of RPC services that are typically reached using named pipes. Some of this RPC services are dissected by Ethereal ([43]), the best network analyzer, including for Windows network protocols.

The Ethereal network analyzer properly dissects the following RPC interfaces, used by Windows administration tools:
atsvc: Scheduler service management
browser: Browser service management
dnsserver: DNS service management
netdfs: Dfs service management
spoolss : Spooler service management
srvsvc: Server service management
svcctl: services management
winreg: remote registry access
wkssvc: Workstation service management
Also, Windows NT and Active Directory domains are built on the following RPC interfaces:
lsarpc: Local Security Authority (LSA) RPC service
samr: Security Account Manager RPC service
netlogon: Netlogon service


4.7.1 lsarpc interface
The lsarpc interface is used to communicate with the LSA (Local Security Authority) subsystem.

Interface Operation number Operation name
12345778-1234-abcd-ef00-0123456789ab v0.0: lsarpc
0x00 LsarClose
0x01 LsarDelete
0x02 LsarEnumeratePrivileges
0x03 LsarQuerySecurityObject
0x04 LsarSetSecurityObject
0x05 LsarChangePassword
0x06 LsarOpenPolicy
0x07 LsarQueryInformationPolicy
0x08 LsarSetInformationPolicy
0x09 LsarClearAuditLog
0x0a LsarCreateAccount
0x0b LsarEnumerateAccounts
0x0c LsarCreateTrustedDomain
0x0d LsarEnumerateTrustedDomains
0x0e LsarLookupNames
0x0f LsarLookupSids
0x10 LsarCreateSecret
0x11 LsarOpenAccount
0x12 LsarEnumeratePrivilegesAccount
0x13 LsarAddPrivilegesToAccount
0x14 LsarRemovePrivilegesFromAccount
0x15 LsarGetQuotasForAccount
0x16 LsarSetQuotasForAccount
0x17 LsarGetSystemAccessAccount
0x18 LsarSetSystemAccessAccount
0x19 LsarOpenTrustedDomain
0x1a LsarQueryInfoTrustedDomain
0x1b LsarSetInformationTrustedDomain
0x1c LsarOpenSecret
0x1d LsarSetSecret
0x1e LsarQuerySecret
0x1f LsarLookupPrivilegeValue
0x20 LsarLookupPrivilegeName
0x21 LsarLookupPrivilegeDisplayName
0x22 LsarDeleteObject
0x23 LsarEnumerateAccountsWithUserRight
0x24 LsarEnumerateAccountRights
0x25 LsarAddAccountRights
0x26 LsarRemoveAccountRights
0x27 LsarQueryTrustedDomainInfo
0x28 LsarSetTrustedDomainInfo
0x29 LsarDeleteTrustedDomain
0x2a LsarStorePrivateData
0x2b LsarRetrievePrivateData
0x2c LsarOpenPolicy2
0x2d LsarGetUserName
0x2e LsarQueryInformationPolicy2
0x2f LsarSetInformationPolicy2
0x30 LsarQueryTrustedDomainInfoByName
0x31 LsarSetTrustedDomainInfoByName
0x32 LsarEnumerateTrustedDomainsEx
0x33 LsarCreateTrustedDomainEx
0x34 LsarCloseTrustedDomainEx
0x35 LsarQueryDomainInformationPolicy
0x36 LsarSetDomainInformationPolicy
0x37 LsarOpenTrustedDomainByName
0x38 LsarTestCall
0x39 LsarLookupSids2
0x3a LsarLookupNames2
0x3b LsarCreateTrustedDomainEx2
0x3c CredrWrite
0x3d CredrRead
0x3e CredrEnumerate
0x3f CredrWriteDomainCredentials
0x40 CredrReadDomainCredentials
0x41 CredrDelete
0x42 CredrGetTargetInfo
0x43 CredrProfileLoaded
0x44 LsarLookupNames3
0x45 CredrGetSessionTypes
0x46 LsarRegisterAuditEvent
0x47 LsarGenAuditEvent
0x48 LsarUnregisterAuditEvent
0x49 LsarQueryForestTrustInformation
0x4a LsarSetForestTrustInformation
0x4b CredrRename
0x4c LsarLookupSids3
0x4d LsarLookupNames4
0x4e LsarOpenPolicySce
0x4f LsarAdtRegisterSecurityEventSource
0x50 LsarAdtUnregisterSecurityEventSource
0x51 LsarAdtReportSecurityEvent

4.7.2 samr interface
The samr interface is used to communicate with the SAM (Security Account Manager) subsystem.

Interface Operation number Operation name
12345778-1234-abcd-ef00-0123456789ac v1.0: samr
0x00 SamrConnect
0x01 SamrCloseHandle
0x02 SamrSetSecurityObject
0x03 SamrQuerySecurityObject
0x04 SamrShutdownSamServer
0x05 SamrLookupDomainInSamServer
0x06 SamrEnumerateDomainsInSamServer
0x07 SamrOpenDomain
0x08 SamrQueryInformationDomain
0x09 SamrSetInformationDomain
0x0a SamrCreateGroupInDomain
0x0b SamrEnumerateGroupsInDomain
0x0c SamrCreateUserInDomain
0x0d SamrEnumerateUsersInDomain
0x0e SamrCreateAliasInDomain
0x0f SamrEnumerateAliasesInDomain
0x10 SamrGetAliasMembership
0x11 SamrLookupNamesInDomain
0x12 SamrLookupIdsInDomain
0x13 SamrOpenGroup
0x14 SamrQueryInformationGroup
0x15 SamrSetInformationGroup
0x16 SamrAddMemberToGroup
0x17 SamrDeleteGroup
0x18 SamrRemoveMemberFromGroup
0x19 SamrGetMembersInGroup
0x1a SamrSetMemberAttributesOfGroup
0x1b SamrOpenAlias
0x1c SamrQueryInformationAlias
0x1d SamrSetInformationAlias
0x1e SamrDeleteAlias
0x1f SamrAddMemberToAlias
0x20 SamrRemoveMemberFromAlias
0x21 SamrGetMembersInAlias
0x22 SamrOpenUser
0x23 SamrDeleteUser
0x24 SamrQueryInformationUser
0x25 SamrSetInformationUser
0x26 SamrChangePasswordUser
0x27 SamrGetGroupsForUser
0x28 SamrQueryDisplayInformation
0x29 SamrGetDisplayEnumerationIndex
0x2a SamrTestPrivateFunctionsDomain
0x2b SamrTestPrivateFunctionsUser
0x2c SamrGetUserDomainPasswordInformation
0x2d SamrRemoveMemberFromForeignDomain
0x2e SamrQueryInformationDomain2
0x2f SamrQueryInformationUser2
0x30 SamrQueryDisplayInformation2
0x31 SamrGetDisplayEnumerationIndex2
0x32 SamrCreateUser2InDomain
0x33 SamrQueryDisplayInformation3
0x34 SamrAddMultipleMembersToAlias
0x35 SamrRemoveMultipleMembersFromAlias
0x36 SamrOemChangePasswordUser2
0x37 SamrUnicodeChangePasswordUser2
0x38 SamrGetDomainPasswordInformation
0x39 SamrConnect2
0x3a SamrSetInformationUser2
0x3b SamrSetBootKeyInformation
0x3c SamrGetBootKeyInformation
0x3d SamrConnect3
0x3e SamrConnect4
0x3f SamrUnicodeChangePasswordUser3
0x40 SamrConnect5
0x41 SamrRidToSid
0x42 SamrSetDSRMPassword
0x43 SamrValidatePassword

4.7.3 netlogon interface
The netlogon interface is used to communicate with the netlogon service, that typically run on member servers and domain controllers.

Interface Operation number Operation name
12345678-1234-abcd-ef00-01234567cffb v1.0: netlogon
0x00 NetrLogonUasLogon
0x01 NetrLogonUasLogoff
0x02 NetrLogonSamLogon
0x03 NetrLogonSamLogoff
0x04 NetrServerReqChallenge
0x05 NetrServerAuthenticate
0x06 NetrServerPasswordSet
0x07 NetrDatabaseDeltas
0x08 NetrDatabaseSync
0x09 NetrAccountDeltas
0x0a NetrAccountSync
0x0b NetrGetDCName
0x0c NetrLogonControl
0x0d NetrGetAnyDCName
0x0e NetrLogonControl2
0x0f NetrServerAuthenticate2
0x10 NetrDatabaseSync2
0x11 NetrDatabaseRedo
0x12 NetrLogonControl2Ex
0x13 NetrEnumerateTrustedDomains
0x14 DsrGetDcName
0x15 NetrLogonDummyRoutine1
0x16 NetrLogonSetServiceBits
0x17 NetrLogonGetTrustRid
0x18 NetrLogonComputeServerDigest
0x19 NetrLogonComputeClientDigest
0x1a NetrServerAuthenticate3
0x1b DsrGetDcNameEx
0x1c DsrGetSiteName
0x1d NetrLogonGetDomainInfo
0x1e NetrServerPasswordSet2
0x1f NetrServerPasswordGet
0x20 NetrLogonSendToSam
0x21 DsrAddressToSiteNamesW
0x22 DsrGetDcNameEx2
0x23 NetrLogonGetTimeServiceParentDomain
0x24 NetrEnumerateTrustedDomainsEx
0x25 DsrAddressToSiteNamesExW
0x26 DsrGetDcSiteCoverageW
0x27 NetrLogonSamLogonEx
0x28 DsrEnumerateDomainTrusts
0x29 DsrDeregisterDnsHostRecords
0x2a NetrServerTrustPasswordsGet
0x2b DsrGetForestTrustInformation
0x2c NetrGetForestTrustInformation
0x2d NetrLogonSamLogonWithFlags
0x2e NetrServerGetTrustInfo


--------------------------------------------------------------------------------

4.7.4 browser interface
The browser interface is used to manage the browser service.

--------------------------------------------------------------------------------

Interface Operation number Operation name
6bffd098-a112-3610-9833-012892020162 v0.0: browser
0x00 BrowserrServerEnum
0x01 BrowserrDebugCall
0x02 BrowserrQueryOtherDomains
0x03 BrowserrResetNetlogonState
0x04 BrowserrDebugTrace
0x05 BrowserrQueryStatistics
0x06 BrowserrResetStatistics
0x07 NetrBrowserStatisticsClear
0x08 NetrBrowserStatisticsGet
0x09 BrowserrSetNetlogonState
0x0a BrowserrQueryEmulatedDomains
0x0b BrowserrServerEnumEx


--------------------------------------------------------------------------------

4.7.5 netdfs interface
The netdfs interface is used to manage the DFS (Distributed File System) Windows component.

--------------------------------------------------------------------------------

Interface Operation number Operation name
4fc742e0-4a10-11cf-8273-00aa004ae673 v3.0: netdfs
0x00 NetrDfsManagerGetVersion
0x01 NetrDfsAdd
0x02 NetrDfsRemove
0x03 NetrDfsSetInfo
0x04 NetrDfsGetInfo
0x05 NetrDfsEnum
0x06 NetrDfsRename
0x07 NetrDfsMove
0x08 NetrDfsManagerGetConfigInfo
0x09 NetrDfsManagerSendSiteInfo
0x0a NetrDfsAddFtRoot
0x0b NetrDfsRemoveFtRoot
0x0c NetrDfsAddStdRoot
0x0d NetrDfsRemoveStdRoot
0x0e NetrDfsManagerInitialize
0x0f NetrDfsAddStdRootForced
0x10 NetrDfsGetDcAddress
0x11 NetrDfsSetDcAddress
0x12 NetrDfsFlushFtTable
0x13 NetrDfsAdd2
0x14 NetrDfsRemove2
0x15 NetrDfsEnumEx
0x16 NetrDfsSetInfo2


--------------------------------------------------------------------------------

4.7.6 srvsvc interface
The srvsvc interface is used to manage the lanmanserver service.

--------------------------------------------------------------------------------

Interface Operation number Operation name
4b324fc8-1670-01d3-1278-5a47bf6ee188 v3.0: srvsvc
0x00 NetrCharDevEnum
0x01 NetrCharDevGetInfo
0x02 NetrCharDevControl
0x03 NetrCharDevQEnum
0x04 NetrCharDevQGetInfo
0x05 NetrCharDevQSetInfo
0x06 NetrCharDevQPurge
0x07 NetrCharDevQPurgeSelf
0x08 NetrConnectionEnum
0x09 NetrFileEnum
0x0a NetrFileGetInfo
0x0b NetrFileClose
0x0c NetrSessionEnum
0x0d NetrSessionDel
0x0e NetrShareAdd
0x0f NetrShareEnum
0x10 NetrShareGetInfo
0x11 NetrShareSetInfo
0x12 NetrShareDel
0x13 NetrShareDelSticky
0x14 NetrShareCheck
0x15 NetrServerGetInfo
0x16 NetrServerSetInfo
0x17 NetrServerDiskEnum
0x18 NetrServerStatisticsGet
0x19 NetrServerTransportAdd
0x1a NetrServerTransportEnum
0x1b NetrServerTransportDel
0x1c NetrRemoteTOD
0x1d NetrServerSetServiceBits
0x1e NetprPathType
0x1f NetprPathCanonicalize
0x20 NetprPathCompare
0x21 NetprNameValidate
0x22 NetprNameCanonicalize
0x23 NetprNameCompare
0x24 NetrShareEnumSticky
0x25 NetrShareDelStart
0x26 NetrShareDelCommit
0x27 NetrpGetFileSecurity
0x28 NetrpSetFileSecurity
0x29 NetrServerTransportAddEx
0x2a NetrServerSetServiceBitsEx
0x2b NetrDfsGetVersion
0x2c NetrDfsCreateLocalPartition
0x2d NetrDfsDeleteLocalPartition
0x2e NetrDfsSetLocalVolumeState
0x2f NetrDfsSetServerInfo
0x30 NetrDfsCreateExitPoint
0x31 NetrDfsDeleteExitPoint
0x32 NetrDfsModifyPrefix
0x33 NetrDfsFixLocalVolume
0x34 NetrDfsManagerReportSiteInfo
0x35 NetrServerTransportDelEx


--------------------------------------------------------------------------------

4.7.7 svcctl interface
The svcctl interface is used to manage Windows services via the SCM (Service Control Manager).

--------------------------------------------------------------------------------

Interface Operation number Operation name
367aeb81-9844-35f1-ad32-98f038001003 v2.0: svcctl
0x00 CloseServiceHandle
0x01 ControlService
0x02 DeleteService
0x03 LockServiceDatabase
0x04 QueryServiceObjectSecurity
0x05 SetServiceObjectSecurity
0x06 QueryServiceStatus
0x07 SetServiceStatus
0x08 UnlockServiceDatabase
0x09 NotifyBootConfigStatus
0x0a ScSetServiceBitsW
0x0b ChangeServiceConfigW
0x0c CreateServiceW
0x0d EnumDependentServicesW
0x0e EnumServicesStatusW
0x0f OpenSCManagerW
0x10 OpenServiceW
0x11 QueryServiceConfigW
0x12 QueryServiceLockStatusW
0x13 StartServiceW
0x14 GetServiceDisplayNameW
0x15 GetServiceKeyNameW
0x16 ScSetServiceBitsA
0x17 ChangeServiceConfigA
0x18 CreateServiceA
0x19 EnumDependentServicesA
0x1a EnumServicesStatusA
0x1b OpenSCManagerA
0x1c OpenServiceA
0x1d QueryServiceConfigA
0x1e QueryServiceLockStatusA
0x1f StartServiceA
0x20 GetServiceDisplayNameA
0x21 GetServiceKeyNameA
0x22 ScGetCurrentGroupStateW
0x23 EnumServiceGroupW
0x24 ChangeServiceConfig2A
0x25 ChangeServiceConfig2W
0x26 QueryServiceConfig2A
0x27 QueryServiceConfig2W
0x28 QueryServiceStatusEx
0x29 EnumServicesStatusExA
0x2a EnumServicesStatusExW
0x2b ScSendTSMessage


--------------------------------------------------------------------------------

4.7.8 winreg interface
The winreg interface is used to access to the registry, either locally or remotely. The interface also contains 3 operations related to systems shutdown.

--------------------------------------------------------------------------------

Interface Operation number Operation name
338cd001-2244-31f1-aaaa-900038001003 v1.0: winreg
0x00 OpenClassesRoot
0x01 OpenCurrentUser
0x02 OpenLocalMachine
0x03 OpenPerformanceData
0x04 OpenUsers
0x05 BaseRegCloseKey
0x06 BaseRegCreateKey
0x07 BaseRegDeleteKey
0x08 BaseRegDeleteValue
0x09 BaseRegEnumKey
0x0a BaseRegEnumValue
0x0b BaseRegFlushKey
0x0c BaseRegGetKeySecurity
0x0d BaseRegLoadKey
0x0e BaseRegNotifyChangeKeyValue
0x0f BaseRegOpenKey
0x10 BaseRegQueryInfoKey
0x11 BaseRegQueryValue
0x12 BaseRegReplaceKey
0x13 BaseRegRestoreKey
0x14 BaseRegSaveKey
0x15 BaseRegSetKeySecurity
0x16 BaseRegSetValue
0x17 BaseRegUnLoadKey
0x18 BaseInitiateSystemShutdown
0x19 BaseAbortSystemShutdown
0x1a BaseRegGetVersion
0x1b OpenCurrentConfig
0x1c OpenDynData
0x1d BaseRegQueryMultipleValues
0x1e BaseInitiateSystemShutdownEx
0x1f BaseRegSaveKeyEx
0x20 OpenPerformanceText
0x21 OpenPerformanceNlsText
0x22 BaseRegQueryMultipleValues2


--------------------------------------------------------------------------------

4.7.9 wkssvc interface
The wkssvc interface is used to manage the lanmanworkstation service.

--------------------------------------------------------------------------------

Interface Operation number Operation name
6bffd098-a112-3610-9833-46c3f87e345a v1.0: wkssvc
0x00 NetrWkstaGetInfo
0x01 NetrWkstaSetInfo
0x02 NetrWkstaUserEnum
0x03 NetrWkstaUserGetInfo
0x04 NetrWkstaUserSetInfo
0x05 NetrWkstaTransportEnum
0x06 NetrWkstaTransportAdd
0x07 NetrWkstaTransportDel
0x08 NetrUseAdd
0x09 NetrUseGetInfo
0x0a NetrUseDel
0x0b NetrUseEnum
0x0c NetrMessageBufferSend
0x0d NetrWorkstationStatisticsGet
0x0e NetrLogonDomainNameAdd
0x0f NetrLogonDomainNameDel
0x10 NetrJoinDomain
0x11 NetrUnjoinDomain
0x12 NetrValidateName
0x13 NetrRenameMachineInDomain
0x14 NetrGetJoinInformation
0x15 NetrGetJoinableOUs
0x16 NetrJoinDomain2
0x17 NetrUnjoinDomain2
0x18 NetrRenameMachineInDomain2
0x19 NetrValidateName2
0x1a NetrGetJoinableOUs2
0x1b NetrAddAlternateComputerName
0x1c NetrRemoveAlternateComputerName
0x1d NetrSetPrimaryComputerName
0x1e NetrEnumerateComputerNames


--------------------------------------------------------------------------------

A vulnerability in the workstation service was published in November 2003 by Yuji Ukai, working for eEye ([45]). It can be exploited anonymously because it is always possible to open the wkssvc named pipe in the context of a NULL session, as explained earlier.


4.8 RPC services over TCP/IP
Windows RPC services are typically invoked using DCE RPC over SMB. However, some network services offer RPC services listening on TCP/IP.


4.8.1 Portmapper RPC service
TCP/IP RPC services listen on dynamic TCP or UDP ports. Thus, to reach a given RPC service, identified by its interface identifier (UUID), a port mapping service is necessary.

The portmapper service is an RPC service listening on different endpoints:
ncalrpc: epmapper LPC port
ncacn_np: epmapper named pipe
ncacn_ip_tcp: 135/tcp
ncadg_ip_udp: 135/udp
ncacn_http: 593/tcp
Typically, to discover the port on which a given RPC service can be reached, a client will establish a TCP connection to port 135, asking for the port allocated to a given RPC service. Then, the client closes the connection to port 135 and opens a new connection to the port returned by the portmapper service.

To register itself in the endpoint database maintained by the portmapper service, a service calls the RpcEpRegister() function.

By default, TCP/IP ports for RPC services are allocated in the range of dynamic ports, which starts at 1025. This explains why on most Windows systems, ports immediately higher than 1024 are used by RPC services. It is possible to configure a specific ports range for RPC services, using the rpccfg tool, as described in another document [46].

To query the portmapper service, it is possible to use a tool typically named rpcdump. Microsoft resource kit contains a Windows version of rpcdump. There is also a Windows version in Todd Sabin's RPC Tools [33], whereas Dave Aitel's SPIKE toolkit contains dcedump [47], a version running on Unix.

Using ifids on one of the portmapper RPC service endpoints, it appears that different RPC interfaces are supported on a Windows 2000 machine:
C:> ifids -p ncacn_np -e pipeepmapper /.
Interfaces: 11
e1af8308-5d1f-11c9-91a4-08002b14a0fa v3.0
0b0a6584-9e0f-11cf-a3cf-00805f68cb1b v1.1
975201b0-59ca-11d0-a8d5-00a0c90d8051 v1.0
e60c73e6-88f9-11cf-9af1-0020af6e72f4 v2.0
99fcfec4-5260-101b-bbcb-00aa0021347a v0.0
b9e79e60-3d52-11ce-aaa1-00006901293f v0.2
412f241e-c12a-11ce-abff-0020af6e7a17 v0.2
00000136-0000-0000-c000-000000000046 v0.0
c6f3ee72-ce7e-11d1-b71e-00c04fc3111a v1.0
4d9f4ab8-7d1c-11cf-861e-0020af6e7c57 v0.0
000001a0-0000-0000-c000-000000000046 v0.0

On a Windows XP or Windows Server 2003 system, the result is:
C:WINDOWS> ifids -p ncacn_ip_tcp -e 135 127.0.0.1
Interfaces: 11
e1af8308-5d1f-11c9-91a4-08002b14a0fa v3.0
0b0a6584-9e0f-11cf-a3cf-00805f68cb1b v1.1
1d55b526-c137-46c5-ab79-638f2a68e869 v1.0
e60c73e6-88f9-11cf-9af1-0020af6e72f4 v2.0
99fcfec4-5260-101b-bbcb-00aa0021347a v0.0
b9e79e60-3d52-11ce-aaa1-00006901293f v0.2
412f241e-c12a-11ce-abff-0020af6e7a17 v0.2
00000136-0000-0000-c000-000000000046 v0.0
c6f3ee72-ce7e-11d1-b71e-00c04fc3111a v1.0
4d9f4ab8-7d1c-11cf-861e-0020af6e7c57 v0.0
000001a0-0000-0000-c000-000000000046 v0.0

As explained later, some of these interfaces are supposed to be only used locally whereas some are designed to be used remotely. However, because all these RPC services run in the same process, they appear when querying one endpoint of the rpcss service such as TCP port 135 or epmapper named pipe.

In the next two sections, these RPC interface identifiers are classified and explained.


4.8.2 RPC services running in the rpcss service
Note: names and purposes of some of the interfaces described in the two following sections have been documented by Microsoft France technical departments.

The first RPC interface is the DCE RPC endpoint portmapper interface [48]:
e1af8308-5d1f-11c9-91a4-08002b14a0fa v3.0: epm


--------------------------------------------------------------------------------

Interface Operation number Operation name
e1af8308-5d1f-11c9-91a4-08002b14a0fa v3.0: epm
0x00 ept_insert
0x01 ept_delete
0x02 ept_lookup
0x03 ept_map
0x04 ept_lookup_handle_free
0x05 ept_inq_object
0x06 ept_mgmt_delete
0x07 ept_map_auth


--------------------------------------------------------------------------------

The ept_map_auth operation is apparently specific to Microsoft implementation of the epmapper interface.

The second RPC interface is used by local processes to reach the local endpoint mapper:
0b0a6584-9e0f-11cf-a3cf-00805f68cb1b v1.1: localepm


--------------------------------------------------------------------------------

Interface Operation number Operation name
0b0a6584-9e0f-11cf-a3cf-00805f68cb1b v1.1: localepm
0x00 OpenEndpointMapper
0x01 AllocateReservedIPPort
0x02 ept_insert_ex
0x03 ept_delete_ex


--------------------------------------------------------------------------------

Remaining interfaces are used by the COM/DCOM implementation. The rpcss service not only runs the RPC subsystem but also the COM Service Control Manager (SCM), which is at the core of the COM/DCOM infrastructure. As a result, some RPC services are available in the rpcss service, as well as some ORPC services, as explained in the next section.

The IActivation interface is an RPC interface implemented by the COM SCM (Services Control Manager) to handle COM objects activation requests :
4d9f4ab8-7d1c-11cf-861e-0020af6e7c57 v0.0: IActivation

This RPC interface has exactly one operation, RemoteActivation(), as described in section 6.2 of the DCOM specification ([49]).

--------------------------------------------------------------------------------

Interface Operation number Operation name
4d9f4ab8-7d1c-11cf-861e-0020af6e7c57 v0.0: IActivation
0x00 RemoteActivation


--------------------------------------------------------------------------------

The IOXIDResolver RPC interface (formerly known as IObjectExporter) is remotely used to reach the local object resolver (OR). The Object Resolver component is in charge to:
return protocol sequences, string bindings and machine id for an object server, given its OXID (ResolveOXID() and ResolveOXID2() (only supported by DCOM version 5.2 and above))
respond to ping requests (SimplePing() and ComplexPing() functions)
respond to ServerAlive() and ServerAlive2() functions requests
The interface identifier of IOXIDResolver is:
99fcfec4-5260-101b-bbcb-00aa0021347a v0.0: IOXIDResolver


--------------------------------------------------------------------------------

Interface Operation number Operation name
99fcfec4-5260-101b-bbcb-00aa0021347a v0.0: IOXIDResolver
0x00 ResolveOxid
0x01 SimplePing
0x02 ComplexPing
0x03 ServerAlive
0x04 ResolveOxid2
0x05 ServerAlive2


--------------------------------------------------------------------------------

There is also a local version of the IOXIDResolver:
e60c73e6-88f9-11cf-9af1-0020af6e72f4 v2.0: ILocalObjectExporter


--------------------------------------------------------------------------------

Interface Operation number Operation name
e60c73e6-88f9-11cf-9af1-0020af6e72f4 v2.0: ILocalObjectExporter
0x00 Connect
0x01 AllocateReservedIds
0x02 BulkUpdateOIDs
0x03 ClientResolveOXID
0x04 ServerAllocateOXIDandOIDs
0x05 ServerAllocateOIDs
0x06 ServerFreeOXIDAndOIDs
0x07 Disconnect


--------------------------------------------------------------------------------

For more information about the DCOM transport into DCE RPC, see [51].

The ISCM RPC interface is a local interface used by local applications to communicate with the local COM SCM:
412f241e-c12a-11ce-abff-0020af6e7a17 v0.2: ISCM


--------------------------------------------------------------------------------

Interface Operation number Operation name
412f241e-c12a-11ce-abff-0020af6e7a17 v0.2: ISCM
0x00 ServerRegisterClsid
0x01 ServerRevokeClsid
0x02 GetThreadID
0x03 UpdateActivationSettings
0x04 RegisterWindowPropInterface
0x05 GetWindowPropInterface
0x06 EnableDisableDynamicIPTracking
0x07 GetCurrentAddrExclusionList
0x08 SetAddrExclusionList
0x09 FlushSCMBindings
0x0a RetireServer


--------------------------------------------------------------------------------

The IROT RPC interface is used by local processes to access the Running Object Table (ROT), to register or unregister COM objects:
b9e79e60-3d52-11ce-aaa1-00006901293f v0.2


--------------------------------------------------------------------------------

Interface Operation number Operation name
b9e79e60-3d52-11ce-aaa1-00006901293f v0.2: IROT
0x00 IrotRegister
0x01 IRotRevoke
0x02 IrotIsRunning
0x03 IrotGetObject
0x04 IrotNoteChangeTime
0x05 IrotGetTimeOfLastChange
0x06 IrotEnumRunning


--------------------------------------------------------------------------------

The IMachineActivatorControl is also a local interface used to notify the COM SCM when COM surrogates start or stop:
c6f3ee72-ce7e-11d1-b71e-00c04fc3111a v1.0: IMachineActivatorControl


--------------------------------------------------------------------------------

Interface Operation number Operation name
c6f3ee72-ce7e-11d1-b71e-00c04fc3111a v1.0: IMachineActivatorControl
0x00 ProcessActivatorStarted
0x01 ProcessActivatorInitializing
0x02 ProcessActivatorReady
0x03 ProcessActivatorStopped
0x04 ProcessActivatorPaused
0x05 ProcessActivatorResumed
0x06 ProcessActivatorUserInitializing


--------------------------------------------------------------------------------

Starting with Windows XP, a new RPC interface is available, DbgIdl, to help debugging of RPC services:
1d55b526-c137-46c5-ab79-638f2a68e869 v1.0: DbgIdl


--------------------------------------------------------------------------------

Interface Operation number Operation name
1d55b526-c137-46c5-ab79-638f2a68e869 v1.0: DbgIdl
0x00 RemoteGetCellByDebugCellID
0x01 RemoteOpenRPCDebugCallInfoEnumeration
0x02 RemoteGetNextRPCDebugCallInfo
0x03 RemoteFinishRPCDebugCallInfoEnumeration
0x04 RemoteOpenRPCDebugEndpointInfoEnumeration
0x05 RemoteGetNextRPCDebugEndpointInfo
0x06 RemoteFinishRPCDebugEndpointInfoEnumeration
0x07 RemoteOpenRPCDebugThreadInfoEnumeration
0x08 RemoteGetNextRPCDebugThreadInfo
0x09 RemoteFinishRPCDebugThreadInfoEnumeration
0x0a RemoteOpenRPCDebugClientCallInfoEnumeration
0x0b RemoteGetNextRPCDebugClientCallInfo
0x0c RemoteFinishRPCDebugClientCallInfoEnumeration


--------------------------------------------------------------------------------

More information about this interface is available in the RPC Debugging section of the Microsoft Debugging Tools package documentation ([50]).


4.8.3 ORPC services running in the rpcss service
ORPC (Object RPC) services are used by DCOM (Distributed COM). ORPC calls can be distinguished from RPC calls because, on the wire, they always have an implicit parameter, either of type ORPCTHIS or ORPCTHAT (see section 3.2 of [49]).

Also, versions of ORPC services interface identifiers is always 0.0, as explained in [51] :
Finally, the interface version number (named if_vers) must always be 0.0. This is because a COM interface may never be modified after it is published. COM interfaces are not versioned; a new interface is defined instead.
The following ORPC services are running in the rpcss service:
00000136-0000-0000-c000-000000000046 v0.0: ISCMActivator
000001a0-0000-0000-c000-000000000046 v0.0: ISystemActivator

ISCMActivator is an ORPC interface implemented by the COM SCM to handle remote activation requests (CoCreateInstance(), CoGetClassObject(), ...) :

--------------------------------------------------------------------------------

Interface Operation number Operation name
00000136-0000-0000-c000-000000000046 v0.0: ISCMActivator
0x00 QueryInterfaceSCMActivator
0x01 AddRefISCMActivator
0x02 ReleaseISCMActivator
0x03 SCMActivatorGetClassObject
0x04 SCMActivatorCreateInstance


--------------------------------------------------------------------------------

ISystemActivator is an ORPC base interface that must be implemented by servers supporting object activation. In the specific case of the COM SCM, running inside the rpcss service, this interface is used when the activation process is looking for an object, asking to the local or a remote SCM to activate a given object.

--------------------------------------------------------------------------------

Interface Operation number Operation name
000001a0-0000-0000-c000-000000000046 v0.0: ISystemActivator
0x00 QueryInterfaceIRemoteSCMActivator
0x01 AddRefIRemoteISCMActivator
0x02 ReleaseIRemoteISCMActivator
0x03 RemoteGetClassObject
0x04 RemoteCreateInstance


--------------------------------------------------------------------------------

On 2003/07/21, a vulnerability affecting the ISystemActivator interface has been published [52]. This vulnerability affects any Windows 2000 system and can be used to, at least, crash the rpcss service. It can be exploited anonymously because the interface does not require authentication.