How to Secure .NET Named Pipe Communication From DLL Injection on the Client Side?

Question

Our .NET Framework C# application has two parts, a client (unelevated) and a service (elevated). The communication between the client and the service takes place over the named pipe. The client (named pipe client) always communicates with the service (named pipe server) whenever an elevated task is to be performed. The communication is in the form of JSON string. This communication needs to be secured so that the service cannot be fooled into performing an elevated task on behalf of an attacker. @Xecrets The service is a sort of privileged helper for the client to perform elevated tasks. The service has some powerful functions such as copying file into Program Files, installing MSIs, as well as running .reg registry files.

There are already some security measures taked at the server end:

1. Pipe Security object has some security measures:

PipeSecurity pipeSecurity = new PipeSecurity();
var id = new SecurityIdentifier(WellKnownSidType.AuthenticatedUserSid, null);

// Allow read and write access to the pipe from different user sessions
pipeSecurity.SetAccessRule(new PipeAccessRule(id, PipeAccessRights.ReadWrite, AccessControlType.Allow));
            
// Grant Service user instance full control.
pipeSecurity.AddAccessRule(new PipeAccessRule(System.Security.Principal.WindowsIdentity.GetCurrent().User, PipeAccessRights.FullControl, AccessControlType.Allow));
           

2. The service checks for the path of the process exe that tries to connect to the service named pipe. Service only accepts connection if the client process is on whitelisted path.

The Problem

There is however a risk of another exploit, DLL Injection. If a DLL is injected into our client process, when the DLL tries to connect to our service named pipe, the path of the DLL appears to be the same as that of the client app. This fools the service and some arbitrary commands can be passed from the injected DLL (malicious) to the Service. This could possibly allow privilege escalation. How can we make sure that only and only our client app can communicate with the service?

Related

Maybe this is related, I am not sure: Get client user token from named pipe

Should we try to secure the named pipe to avoid an injected DLL to communicate with our service or should we try using a different IPC altogether e.g. Service Contract?

Ideas In Mind

Tried refining the following ideas to resolve this problem:

1. Microsoft Security and Access Rights (https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipe-security-and-access-rights) This looks a bit difficult to understand. Also I am not sure if this will actually solve my problem.

2. Considered using asymmetric encryption in the communication between the client and the service. But the challenge in this approach is that the distribution of the public and private keys securely between the client and service looks impossible. Given the client is running unelevated, the client would definitely not be able to store the public key at secure location. Hence an attacker would easily be able to modify the public key and provide his own public key to fool the service.

Answer 1

You need to change the level of abstraction of the requests. Instead of giving the client control over individual functions such as modifying files and registry entries, require the client to request an operation (install this update) and have the service decide how to perform that operation safely (perhaps it checks for a signature on the update that needs to be installed, and if that signature is present, it reads instructions from inside the signed update file)