- Synacktiv describes how a low-privilege Windows process can tap or alter the named-pipe link to a SYSTEM process in an app.
- Caller checks such as process ID or signature slow attackers but are not a remediation on their own, the researchers say. Strict access rules and message validation help.
- Ask which desktop products use this design, how pipes are secured, and whether tests cover the channel. The write-up names no affected products.
Some desktop products are not one program. They are several, and some run with full system rights while others run as the logged-in user. The pieces must talk to each other. In our view, that link is a trust boundary, and it is easy to overlook in reviews.
The business risk is specific. A process running with ordinary user rights may attack a process running as SYSTEM, the highest level on Windows. Synacktiv, a security consultancy, says it often sees this design during security assessments. It describes how the link between the two parts can be attacked.
The lesson is that a check on who is calling is not the same as a safe channel. In Synacktiv's technique, caller checks can leave a gap. They slow an attacker down, but the researchers do not treat them as a fix.
How the link works
Windows lets processes talk through named pipes. One side creates a pipe under a name such as \\.\pipe\example_pipe_name. The other side opens that name. Data then flows both ways, much like a TCP or websocket connection. All processes on the machine share that naming space, and the pipes can be listed with standard tools.
Each pipe has access rules. Synacktiv notes the defaults: Administrators and SYSTEM get read and write. Everybody and Anonymous Logon get read. A process that is not elevated also gives its own user read and write. The researchers say this leaves room for man-in-the-middle attacks.
Two ways in, and the fixes
In the first, the privileged service sets loose access rules because it expects ordinary users to connect. If an attacker's account holds write rights, it can create its own copy of the pipe. Legitimate and hostile copies then sit side by side. Synacktiv's fix is to set restrictive rules and not grant the right to append data to other users.
In the second, the attacker races the service. A pipe's access rules are read only when its first copy is created. If the attacker creates the pipe first, the attacker writes the rules. The defence is a flag, FILE_FLAG_FIRST_PIPE_INSTANCE, which makes creation fail if the pipe already exists.
Why checking the caller falls short
Sometimes a service wants only one specific program to connect, such as a helper that shows windows in the user's session. A common step is to check the caller's digital signature or its process ID.
Synacktiv's point is that, because of how Windows security boundaries work, a payload can be injected into the legitimate client. The client still looks genuine to the service. The injected code can then inspect and change what travels down the pipe. Synacktiv says such checks slow attacks but cannot be considered a remediation on their own.
The team built a tool on Frida, a toolkit for hooking into running programs. It hooks the system calls that read and write pipe data. It sends that data to a management process and on to an HTTP proxy, so testers can edit messages in transit. The tool is on Synacktiv's GitHub. Synacktiv says the approach needs no administrator rights to inspect pipe content, which tools such as API Monitor would require.
The tool is a testing aid for this approach. The write-up reports no attacks in the wild and names no affected products.
Why the tooling is harder than it sounds
Reading a pipe can be done in several ways, and each needs its own hook. In the simple synchronous case, the data is ready when the read call returns. In the asynchronous case, the read call returns at once, before any data exists. The tool must remember the pending request and change the buffer later, once the system reports it complete.
Completion routines are callbacks that Windows queues for a thread. Injecting data into one is trickier. A queued call takes one argument, while the callback takes three. Synacktiv gets around this with a lookup table that maps one identifier to the three values. This is a hurdle for testers, not a finding about risk.
What leaders should ask
The takeaway is that identity checks should be paired with validating each message. Synacktiv calls for validating data that arrives over untrusted channels such as pipes, especially when it can come from another security context.
The research does not name affected products, so these questions are for your own inventory. Each ties back to the same risk: a user-level process reaching a SYSTEM process.
First, which of our desktop products run a SYSTEM part and a user part, and how do they talk? Second, are pipe access rules restrictive, and is the first-instance flag set? Third, does the SYSTEM side check every message it receives, or does it trust the caller's identity? Fourth, does the next penetration test cover this internal channel?
The channel between a privileged helper and its user-level partner is easy to forget. Treat what arrives on it as input from a stranger.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Synacktiv.
