Windows IPC Security

Before you delve into the coverage of IPC mechanisms, you need to expand your knowledge of Windows security a bit. Chapter 11 explained the core elements of the security model; however, there are more complicated situations to consider when you're dealing with IPC communications. In particular, you need to understand how security is affected by communication across a network and how impersonation affects the user security context. The following sections explain some basic principles of IPC security that lay the foundation for the discussion in the remainder of this chapter.

The Redirector

Windows network authentication can be confusing from the programmer's perspective because so many things seem to happen implicitly, and you might not be sure what's going on under the hood. The redirector is the component that acts as the man behind the curtain. It provides the mapping that makes it possible to use the same API calls for local files, remote files, named pipes, mailslots, and WebDAV shares. The following sections cover some security-relevant elements of the redirector without the distraction of unnecessary details.

Universal Naming Convention

Universal Naming Convention (UNC) paths were mentioned briefly in Chapter 11. For networking purposes, a UNC path provides a standardized way of referencing files and devices across networked systems. UNC paths take the following form:

\\server\share\path

The server is simply the name of the system; depending on the environment, it can be a NETBIOS name, an IP address, or a qualified DNS name. Supplying a period (.) character for the server is an alias for the local system. The share is the exported name assigned to a directory or device on the remote system. Finally, the path is just the qualified path to a file.

Session Credentials

Chapter 11 discussed how user logon sessions are containers for tokens associated with a user logon, but this explanation can be expanded to include connections to remote systems. Connecting to any remote system generates a set of session credentials for that machine, and these credentials are stored in the logon session. A logon session can have at most one session credential for each remote system.

To understand how this works, consider a connection to the remote share stuff on the host Bob; the UNC path for this share is \\Bob\stuff. You can map this share to the drive letter X with the following command:

net use X: \\Bob\stuff

Now any references to the X: drive are redirected to the stuff share on Bob. One thing you may notice about this command line is that no explicit credentials are passed for connecting to this share. The credentials are not passed explicitly because the OS passed the existing logon session credentials automatically. This implicit behavior is what saves you the trouble of reentering your password in an NT Domain or Active Directory environment. However, it can be the source of some issues when the remote system isn't in a trusted domain.

Assume that you and Bob aren't in the same domain. This means Bob's computer has an account matching your user name and password, or he has enabled anonymous access for the share. So you poke around a bit and discover that Bob does in fact allow anonymous access to the share, but these credentials are insufficient to access the share's contents. Fortunately, Bob is a friend and you have an account on his computer. So you can simply run the following command to connect with the appropriate credentials:

net use Y: \\Bob\stuff /user:Bob\Joe

This command should allow you to log on to Bob's system as a local user named Joe; issuing this command then displays a prompt for Joe's password. Unfortunately, the password still won't work at this time. To see why, just issue a net use command with no arguments. You will see that the logon session still has your connection to Bob's computer from when you mapped the X: drive. Remember that Windows allows only one set of session credentials for a remote server from a logon session. The anonymous connection to X: already established a session, so you need to disconnect that existing session before you can log on as Joe. You can unmap the X: drive with the following command:

net use X: /D

After unmapping the X: drive, you can successfully establish a new connection to Bob's system. This example should demonstrate that a logon session can maintain only one set of session credentials per remote system. This restriction isn't just limited to file shares. It's a core part of the security model and applies to all network IPC mechanisms using built-in Windows authentication.

SMB Relay Attack

The previous section stated that Windows passes your credentials automatically when connecting to another system, but this isn't exactly true. In traditional Windows authentication, the server actually presents the client with a random challenge value. The client then responds with a message authentication code (MAC) incorporating the password hash and challenge value. This challenge sequence is how LAN Manager (LM) and NT LAN Manager (NTLM) authentication avoid presenting the password hash to a potentially malicious server.

The downside to this authentication mechanism is that the server's identity is never verified. As a result, LM and NTLM authentication are vulnerable to a type of man-in-the-middle attack known as an SMB relay or SMB proxy attack. To exploit this vulnerability, an attacker causes a victim to establish a Server Message Block (SMB) connection to an attacker-controlled system. This could be done by e-mailing the victim a link to a UNC file path or through a variety of other means. The attacker then initiates a connection to a target system and acts as a proxy between the victim and the target. After the challenge exchange is completed, the attacker is connected to the target server with the victim's credentials. As an auditor, you need to be aware of situations in which an application can be coerced into connecting to untrusted machines, as it can expose the application's credentials to these attacks.

Impersonation

Impersonation is one of the components that might be most responsible for Windows popularity in enterprise environments. It allows credentials to be transferred automatically to processes in another session on the same machine or a different system. Impersonation is one of the foundational components of Windows single sign-on (SSO) capability. However, all the flexibility and convenience of this system does require devoting some extra care to its use.

Impersonation plays a major role in implementing security for Remote Procedure Call (RPC) and Distributed Component Object Model (DCOM) services, Dynamic Data Exchange (DDE) client/servers, and named pipe client/servers. The functions of each of these IPC mechanisms are covered individually over the course of this chapter, but first you need to learn a few common aspects of impersonation that apply to all these IPC mechanisms.

Impersonation Levels

Impersonation levels allow a client to restrict the degree to which an IPC server can use the client's credentials. When these values are supplied, they provide a level of protection for the client; otherwise, the client might accidentally supply its credentials to a malicious server, allowing that server to access network resources on the client's behalf. Table 12-1 summarizes the impersonation levels from the Microsoft Developer Network (MSDN, msdn.microsoft.com).

Table 12-1. Impersonation Levels

Level	Meaning
SecurityAnonymous	The server can't impersonate or identify the client.
SecurityIdentification	The server can verify the client's identity but can't impersonate the client.
SecurityImpersonation	The server can impersonate the client's security context on the local system.
SecurityDelegation	The server can impersonate the client's security context on remote systems.

Where are these impersonation levels specified by the client? Usually, they appear as a parameter in IPC connection functions. The security implications of impersonation levels are best understood in the context of a specific IPC mechanism. So you will revisit impersonation levels throughout the chapter as each IPC mechanism is discussed.

SeImpersonatePrivilege

Impersonation issues provide opportunities for privilege escalation vulnerabilities, so Microsoft made a fundamental change in the way impersonation is handled. Windows Server 2003, Windows XP SP2, and Windows 2000 SP4 added SeImpersonatePrivilege, which is a required privilege for impersonating another user. A normal user doesn't have this privilege by default, although it's granted to the built-in service accounts. This change significantly reduces the chances of impersonation-based attacks in later versions of Windows. However, for code auditors, it's best to assume the application is deployed in an environment where normal users can perform impersonation.