Monday, 16 March 2015

Understanding how Named Pipes work

A named pipe provides one or bi-directional communication between a pipe server and pipe clients, as well as having the ability to spawn multiple instances - allowing multiple clients accessing them at the same time.

Typically Windows makes extensive use of them - to name a few:
For a more expansive list please see here.

In order to connect to the named pipe we connect over SMB to the IPC$ share that will then allows us to connect with a named pipe. We will now need to bind to a specific interface on the named pipe and the relevent Operation Number and Operation Name to invoke a call.

For example the 'eventlog' named pipe has a operation name called "ElfrClearELFW" - by using the "ClearEventLog" Windows API you are able to clear the event log.

Named pipes can also be accessed remotely over a network for example:

When creating a named pipe (using the CreateNamedPipe function) you also have the ability to set a security descriptor that defines access permissions on the named pipe. Although if this information is ommited / null the default permissions are applied:

Local System = Full Control
Administrators = Full Control
Creator Owner = Full Control
Everyone = Read
Anonymous = Read

You can use the 'GetSecurityInfo' function to get the security discriptor information for the named pipe and use the 'SetSecurityInfo' to set access control permissions.

There is also a nice little utility that can display all of the namedpipes from SysInternals called pipelist

Named Pipes Connection Establishment is achieved by using CIFS or SMB protocol - the following information has to be worked:

- Authentication must be negotiated
- Remote process must be idenified (by using \\<hosname>\IPC$

Once this connection has been negotiated - all further RPC binds and calls are encapsulated with SMB - being sen over port 445 / 139.


Post a Comment