Aplikasi desktop modern sering memisahkan arsitektur menjadi dua komponen utama: antarmuka pengguna (UI) yang berjalan dengan hak akses pengguna standar (Medium Integrity), dan background service atau daemon yang berjalan sebagai NT AUTHORITY\SYSTEM. Komunikasi antar-proses (IPC) via HTTP localhost atau Named Pipes sering menjadi celah eksploitasi Local Privilege Escalation (LPE) jika service mempercayai setiap request lokal tanpa validasi identitas pemanggil.

Akar Masalah Kerentanan IPC Lokal

Riset keamanan pada berbagai utilitas OEM (seperti pola kerentanan pada MSI Center) menunjukkan kegagalan desain yang konsisten pada trust boundary lokal:

  • Implicit Trust pada Localhost: Service mengikat HTTP listener pada 127.0.0.1 atau Named Pipe dengan Discretionary Access Control List (DACL) yang longgar (seperti Everyone: (F)), mengasumsikan bahwa semua traffic lokal berasal dari aplikasi terpercaya.
  • Ketiadaan Autentikasi Pemanggil: Service memproses perintah administratif tanpa memverifikasi Security Identifier (SID) atau Integrity Level (IL) dari proses yang mengirim pesan.
  • Arbitrary Execution Endpoint: API service menerima input dinamis seperti path file biner, argumen eksekusi, atau command shell mentah dari client tanpa validasi integritas payload.

Pola Eksploitasi: Penyerang tanpa hak akses administratif dapat mengirim HTTP POST atau payload IPC ke endpoint daemon lokal untuk menjalankan binary arbitrary (misalnya cmd.exe) yang langsung diwarisi konteks hak akses SYSTEM.

1. Verifikasi Eksplisit Caller via OS Token

Protokol berbasis Named Pipe di Windows menyediakan infrastruktur bawaan untuk mengidentifikasi caller secara deterministik. Service harus menginspeksi token proses klien sebelum mengeksekusi aksi dengan hak akses tinggi.

using System;
using System.IO.Pipes;
using System.Runtime.InteropServices;
using System.Security.Principal;

public static class PipeSecurityValidator
{
    [DllImport("kernel32.dll", SetLastError = true)]
    private static extern bool GetNamedPipeClientProcessId(IntPtr Pipe, out uint ClientProcessId);

    public static bool IsCallerAuthorized(NamedPipeServerStream pipeStream, string expectedUserSid)
    {
        // 1. Ekstraksi Process ID dari client
        if (!GetNamedPipeClientProcessId(pipeStream.SafePipeHandle.DangerousGetHandle(), out uint clientPid))
        {
            return false;
        }

        // 2. Impersonate caller untuk membaca context token secara aman
        bool authorized = false;
        pipeStream.RunAsClient(() =>
        {
            WindowsIdentity clientIdentity = WindowsIdentity.GetCurrent();
            
            // Validasi SID pemanggil: Cocokkan dengan SID akun login aktif (bukan guest/anonymous)
            if (clientIdentity.User == null || clientIdentity.User.Value != expectedUserSid)
            {
                authorized = false;
                return;
            }

            // Validasi Integrity Level minimal Medium atau High
            authorized = !clientIdentity.IsAnonymous && clientIdentity.IsAuthenticated;
        });

        return authorized;
    }
}

Penggunaan Named Pipes memungkinkan verifikasi SID langsung melalui API kernel. Jika arsitektur mengharuskan penggunaan socket/HTTP lokal, kernel tidak menyertakan context token secara otomatis dalam payload TCP loopback, sehingga pola Named Pipe atau Domain Sockets (pada sistem POSIX) jauh lebih aman untuk IPC antar-privilege.

2. Mekanisme Ephemeral Handshake Token

Untuk mengamankan API HTTP lokal yang tidak memiliki metadata token bawaan, service harus menerapkan mekanisme secret exchange terisolasi saat startup:

  1. Service daemon yang berjalan sebagai SYSTEM membuat token acak berbasis kriptografi (misalnya 32 bytes via RNGCryptoServiceProvider) saat session user dimulai.
  2. Service menyimpan token tersebut ke dalam file konfigurasi atau Named Pipe khusus pada direktori yang diproteksi ACL ketat: hanya dapat dibaca oleh user Windows aktif saat itu (SID spesifik) dan SYSTEM.
  3. UI client membaca token dari path terproteksi tersebut, kemudian menyertakan token dalam header X-Service-Auth-Token pada setiap panggilan HTTP ke daemon.
  4. Setiap request tanpa header yang valid langsung ditolak dengan status HTTP 401 sebelum parsing payload dilakukan.

3. Validasi Skema Ketat dan Execution Allowlist

Jangan pernah mengekspos endpoint yang menerima path eksekusi atau parameter perintah dinamis dari IPC. Terapkan pola Action Dispatcher dengan daftar izin statis (allowlist).

using System;
using System.Collections.Generic;
using System.Diagnostics;

public enum PermittedAction
{
    RestartDriver,
    ApplyLedProfile,
    CollectTelemetry
}

public class ExecutionEngine
{
    // Mapping statis: Client hanya boleh mengirimkan Action ID, bukan executable path
    private static readonly Dictionary<PermittedAction, string> WhitelistedBinaries = new()
    {
        { PermittedAction.RestartDriver, @"C:\Program Files\VendorService\Tools\RestartDriver.exe" },
        { PermittedAction.ApplyLedProfile, @"C:\Program Files\VendorService\Tools\LedControl.exe" }
    };

    public static void ExecuteAction(PermittedAction action, string sanitizedArguments)
    {
        if (!WhitelistedBinaries.TryGetValue(action, out string binaryPath))
        {
            throw new UnauthorizedAccessException("Aksi tidak terdaftar dalam allowlist.");
        }

        // Verifikasi integritas biner target sebelum eksekusi (cegah DLL hijacking / symlink abuse)
        ProcessStartInfo startInfo = new()
        {
            FileName = binaryPath,
            Arguments = sanitizedArguments,
            UseShellExecute = false,
            CreateNoWindow = true,
            RedirectStandardOutput = true
        };

        using Process proc = Process.Start(startInfo);
        proc.WaitForExit(5000);
    }
}

Trade-off dan Pertimbangan Arsitektur

  • Named Pipe vs Loopback HTTP: HTTP lokal mudah dikembangkan untuk frontend Electron atau Web-based UI, namun rentan serangan SSRF dari browser (DNS rebinding) serta tidak mendukung native token validation. Named Pipes memerlukan layer P/Invoke atau native library di sisi client, namun menawarkan mitigasi native terhadap serangan cross-origin dan manipulasi koneksi.
  • Impersonation Risks: Penggunaan token impersonation (seperti RunAsClient) harus dibatasi hanya untuk operasi pengecekan identitas. Menjalankan logika kompleks di bawah token impersonation berisiko membuka celah privilege drop atau eksploitasi sekunder jika client mengontrol resource target.