Part I: The Fundamentals of Windows Named Pipes

Mechanics of Windows Pipes: How Attackers Gain Privileged Access

In this three-part blog series, we will discuss the mechanics of Windows pipes and how they can be abused by attackers to gain privileged access.

In this blog post, which is part I of the series, we review the four fundamentals of named pipes. Then in part II, we will expand on the four fundamentals and provide hands-on examples on how to perform attack surface enumeration and reconnaissance against an application that implements a named pipe server (click here to read part II).

In the third and final part of three-part blog series, we will provide an in-depth exploration of reversing the protocol implemented by the named pipe server followed by a detailed analysis of exploitation.

During part II and part III of this series, the analysis of both reconnaissance and exploitation will be performed using a vulnerable application developed by VS-Labs Research team. This vulnerable application implements a named pipe server that contains some of the common vulnerabilities that VS-Labs Research Team has found in real world applications.

The code for the server component, as well as a sample client application which demonstrates the basic code needed to connect to the server and communicate with the named pipe, can be found on GitHub.

Windows Pipes Background

Pipes, like most Windows IPC mechanisms, are documented quite well by Microsoft (refer to MSDN’s pipes documentation for a full description of pipes).

Let’s start by reviewing the four fundamentals of Windows Pipes:

• What is a pipe?
• What kind of pipes exist?
• How does pipe communication work?
• What are the operational limits associated with named pipes?

These four topics above offer immediate insight into the operational usage and background of pipes on the Windows operating system. Those who are already familiar with pipes on Windows are encouraged to skip ahead by clicking here.

What is a Pipe?

Like most IPC mechanisms, pipes help facilitate communication between two applications and or processes using shared memory. 

This shared memory is treated as a file object in the Windows operating system. Since pipes are treated as file objects, standard file object functions such as ReadFile() and WriteFile(), which are exposed via the Windows Application Programming Interface (API), are commonly used during communication.

Pipe communication utilizes First-in-First-out (FiFo) implementation.

This means that the first byte of data written to a pipe is the first byte of data that will be read from the pipe. After data is read from a pipe, it is no longer available inside the pipe’s data buffer and therefore cannot be read again.

However, a function called PeekNamedPipe() exposed via the Windows API can be used to circumvent this limitation by reading data from a pipe without removing it from the pipe’s data buffer.

What Kind of Pipes Exist?

There are two main kinds of pipes: named pipes, which have a name, and anonymous pipes, which do not have a name.

An example of a named pipe is \.PipeExampleNamedPipeServer. While most details discussed in this blog are relevant to named pipes, some information can also be applied to anonymous pipes.

How Does Pipe Communication Work?

Microsoft Windows Pipes utilizes a client-server implementation whereby the process that creates a named pipe is known as the server and the process that communicates with the named pipe is known as the client.

By utilizing a client-server relationship, named pipe servers can support two methods of communication. These two methods are half-duplex and duplex communication. With half-duplex communication, a client opens a one-way channel which allows the client to write data to the server without the server being able to respond.

With duplex communication, a two-way communication channel is opened that allows the client to write data over the pipe to the server, and the server to write data over the pipe back to the client.

What Are the Operational Limits Associated with Named Pipes?

When evaluating the operation limitations associated with named pipes, it is important to note that each active connection associated with a named pipe server results in the creation of a new instance of the named pipe. These instances all share a common name; however, the buffers and handles to each named pipe instance are different.

Enumerating these instances can be accomplished using the tool PipeList, which is part of the SysInternals Suite.  An example of how this tool can be used to enumerate the number of active pipe instances can be seen in Figure 1.

With some background info on named pipes and how they operate, it is now time to review the permissions and access control lists associated with named pipes.

Named Pipe Permissions

Permissions are a core component of operating systems and are implemented in many ways. Within Windows, permissions are assigned using Access Control Lists (ACL). ACL’s are composed of Access Control Entries (ACE’s) which hold two separate permission structures.

The first is a Discretionary Access Control List (DACL), and the second is a System Access Control List (SACL). The SACL is mostly used for logging events to the security event log and is not interesting for our purposes. The DACL on the other hand is interesting since it defines who can modify, write, read, or execute a specified resource.

To view the DACL’s of a given named pipe, one can use the tool Accesschk from the SysInternals Suite.

Accesschk is a versatile tool that allows users to enumerate various resources, such as named pipes, and the permissions associated with them.

DACL enumeration can be performed on named pipes by passing the argument pipe via the command line to accesschk.exe.

This argument acts as a wild card and enumerates every existing named pipe that is currently active on the system. An example of this can be seen in Figure 2 below.

Take a Deeper Dive into Named Pipe Servers with Hands-On Examples

Now that we’ve covered some general background information in relation to named pipe usage on Windows and reviewed how to enumerate named pipe permissions, let’s take a deeper dive into identifying usage of named pipe servers within applications using a custom vulnerable application. Click here to read part II of our three-part series: Analysis of a Vulnerable Microsoft Windows Named Pipe Application.

VS-Labs Research Team

Maintain awareness regarding unknown threats to your products, technologies, and enterprise networks. Organizations that are willing to take the next step in proactively securing their flagship product or environment can leverage our zero-day vulnerability research offering. Our subscription-based capability provides your organization with immediate access to zero-day vulnerabilities affecting products and software. Learn More →