Thick Client: Pipeline Güvenliği

masaüstü uygulamasında yönetim seçeneklerinin gizlenmiş olması, arka plandaki servisin aynı yetki sınırını uyguladığı anlamına gelmez. Arayüz standart kullanıcıyla, servis ise yönetici veya SYSTEM hesabıyla çalışıyorsa aralarındaki iletişim kanalı doğrudan güven sınırına dönüşür. sınır yanlış kurulursa düşük yetkili kullanıcı, servise kendi yetkileriyle yapamayacağı işlemleri yaptırabilir.

yazıda Windows tabanlı thick client uygulamalarındaki Named Pipe iletişimini pentester gözüyle inceleyeceğiz. pipe adını bulmakla gerçek güvenlik açığını kanıtlamak arasındaki farkı, zayıf DACL uygulama seviyesi yetkilendirme hatalarının nasıl zincirlendiğini, kontrollü laboratuvarımızda zincirin nasıl sömürüldüğünü geliştiricilerin aynı sınırı nasıl sağlamlaştırabileceğini göstereceğiz.

Terim notu: Başlıktaki “pipeline” ifadesi yazıda Windows Named Pipes iletişimini anlatıyor. Teknik terim named pipe’dır; CI/CD build deployment pipeline’ları yazının konusu değildir.

Pipeline Nedir? Windows Named Pipes IPC

IPC, aynı veya farklı sistemlerdeki süreçlerin veri alışverişi yapmasını sağlayan mekanizmaların genel adıdır. Named pipe ise sunucu süreç veya daha fazla istemci arasında tek ya çift yönlü iletişim kuran, adı olan Windows nesnesidir. “Sunucu” burada ayrı bilgisayar olmak zorunda değildir; aynı makinede çalışan Windows servisi pipe sunucusu olabilir. Ayrıntılı davranış Microsoft’un Named Pipes belgesinde açıklanır.

Örnek yerel pipe yolu şöyledir:

\\.\pipe\Example.Reporting

ad yalnızca iletişim noktasını tanımlar. Bağlanan sürecin güvenilir olduğunu, gönderdiği rol bilgisinin doğru olduğunu veya istediği işleme yetkili olduğunu kanıtlamaz.

thick client neden named pipe kullanır?

ERP, muhasebe veya yönetim uygulamasında kullanıcı arayüzü, güncelleme bileşeni, yazdırma servisi arka plan görev yöneticisi farklı süreçlerde çalışabilir. Böylece uzun süren işler arayüzü kilitlemez; servisler bağımsız yönetilir yalnızca ihtiyaç duyan bileşen daha yüksek yetkiyle çalıştırılabilir.

mimarinin bedeli yeni güven sınırıdır. İstemci standart kullanıcıyla, servis yüksek yetkiyle çalışıyorsa servis soruların her birine cevap vermelidir:

kanala kim bağlanabilir?

Bağlanan istemcinin doğrulanmış kimliği nedir?

kimlik istenen işlemi yapabilir ?

İstenen üzerinde ayrıca yetkisi var ?

Şekil 1 — Arayüz yüksek yetkili servis arasındaki named pipe, uygulamanın güvenlik sınırlarından biridir. Neden Zafiyet Doğurabilir?

Named pipe kullanmak tek başına zafiyet değildir. kanala kimlerin erişebildiği kanalın hangi işlevleri hangi hesapla sunduğuyla belirlenir. Pipe’a bağlanabilmek servis üzerinden yetkisiz işlem yaptırabilmek aynı bulgu değildir.

ZayıflıkGerekli ek koşulOlası sonuçGereğinden geniş DACLPipe hassas veri veya işlev sunuyorYetkisiz erişim ya işlem talebiİstemciden gelen role güvenmekServis rolü kendi tarafında doğrulamıyorUygulama içi yetki aşımıGirdiyi servis yetkisiyle işlemekServis korunan kaynağa erişebiliyorYerel yetki sınırının aşılmasıGenel amaçlı dosya/komut işlemi sunmakKullanıcı hedefi veya parametreyi belirleyebiliyorDosya değişikliği veya kod çalıştırmaMesaj sınırı şema kontrolünün olmamasıİşleyici hatalı girdiyi güvenli reddedemiyorHizmet kesintisi veya beklenmeyen işlemAşırı yetkili veritabanı hesabıİstekler ortak yüksek yetkili hesapla yürütülüyorGereğinden fazla veri erişimi/değişikliği

Windows, pipe bağlantısında istemcinin access token’ını nesnenin DACL’iyle karşılaştırır. Fakat bağlantı izni uygulama içindeki bütün işlemlerin izni değildir. DACL ilk kapıdır; kimlik doğrulama, işlem yetkisi yetkisi ayrı karar noktalarıdır.

Şekil 2 — Her kontrol bağımsızdır; herhangi biri başarısız olduğunda işlem durmalıdır.

Yetki yükseltme iddiası için yüksek yetkili servisin varlığı yeterli değildir. Düşük yetkili kimliğin doğrudan gerçekleştiremediği işlemi servis üzerinden yaptırabildiğini göstermemiz gerekir. Başlangıç yetkisi, servis hesabı, değişen işlem sonucu aynı kanıt zincirinde yer almalıdır.

Nasıl Ne Durumda Pipeline Güvensiz Olur? “ pipe’a yalnızca bizim EXE bağlanır” varsayımı

dosyanın adı, imzası, PID’si veya arayüzdeki rol bilgisi tek başına kimlik kanıtı değildir. Düşük yetkili kullanıcı pipe’a bağlanabiliyorsa meşru istemcinin ürettiği mesajları kendi istemcisiyle yeniden oluşturabilir. Servis aşağıdaki gibi karara güveniyorsa rolü belirleyen taraf fiilen istemci olur:

if (request.Role == "admin") { WriteProtectedFile(request.Value); }

Burada saldırgan Windows token’ını değiştirmez. Yalnızca JSON içindeki role alanını değiştirir. Servis iddiayı doğrulamadan kabul ederse arayüzde saklanan yönetim işlevi doğrudan çağrılabilir.

DACL’yi bağlantı sorununu çözmek için genişletmek

DACL, pipe nesnesine hangi SID’lerin hangi haklarla erişebileceğini belirler. Everyone, Authenticated Users veya Users gibi geniş gruplara yazma tam kontrol vermek, yüksek yetkili servisin saldırı yüzeyini büyütür.

Named pipe haklarında genel yazma izni ayrıca dikkat gerektirir. Windows’ta FILE_APPEND_DATA FILE_CREATE_PIPE_INSTANCE aynı bit değerini kullanır; Microsoft nedenle genel yazma hakkı yerine ihtiyaç duyulan hakların tek tek verilmesini önerir. Ayrıntılar Named Pipe Security and Access Rights belgesinde bulunabilir.

Üç kavramı birbirinden ayırmak gerekir:

• NULL DACL: Herkese erişim verir.
• Boş DACL: İzin veren kayıt içermez erişimi engeller.
• Özel security descriptor vermemek: Windows’un varsayılan tanımlayıcısını kullanır; otomatik olarak NULL DACL anlamına gelmez.

Varsayılan tanımlayıcı her mimari için doğru değildir. Güvenlik politikası, hedef istemci hesabı ihtiyaç duyulan haklar açıkça tanımlanmalıdır.

Bağlantı iznini işlem yetkisi saymak

kullanıcının servis durumunu görüntüleyebilmesi, ayar değiştirebilmesi gerektiği anlamına gelmez. Aynı pipe üzerinde hem herkese açık durum sorguları hem ayrıcalıklı yönetim işlemleri bulunabilir. nedenle yalnızca bağlantı sırasında kontrol yapmak yeterli değildir; servis her mesajda işlem bazında yeniden karar vermelidir.

Impersonation hataları

RunAsClient veya ImpersonateNamedPipeClient, sunucunun istemci güvenlik bağlamında kontrol yapmasını sağlar. Impersonation kurulamazsa işlem servisin kendi yetkileriyle devam etmemeli, güvenli biçimde reddedilmelidir. Bağlamın doğru geri alınması bütün hata dönüşlerinin kontrol edilmesi gerekir. Native API davranışı ImpersonateNamedPipeClient belgesinde açıklanır.

SQL bağlantısını pipe güvenliğiyle karıştırmak

Thick client SQL Server arasında iki farklı mimari görülebilir:

A: Thick client → SQL Server'ın Named Pipes protokolü B: Thick client → uygulamaya ait named pipe → servis → SQL Server

A modelinde pipe, SQL Server bağlantısının taşıma yöntemidir. Pipe’ı SQL Server servisi oluşturur; Windows erişimi SQL login, user rol izinleri ayrı katmanlardır. Thick client’ın bağlantı dizesinde ortak SQL hesabı taşıması, hesabın aşırı yetkili olması veya kullanıcı yetkisinin yalnızca arayüzde uygulanması burada incelenmesi gereken asıl risklerdir.

B modelinde SQL bağlantısını aracı servis kurar. kez pipe’a gelen kullanıcının hangi sorgu veya iş işlemini başlatabildiği servisin veritabanında hangi hesapla çalıştığı önem kazanır. Her iki modelde “Named Pipes açık” sonucu tek başına SQL yetki aşımı anlamına gelmez.

Pentester Zafiyeti Nasıl Tespit Eder Doğrular?

İnceleme dört aşamadan oluşur: endpoint’i bulmak, erişimi doğru kullanıcıyla doğrulamak, protokolü anlamak ölçülebilir etkiyi göstermek.

1. Test bağlamını kaydetmek

İstemcinin, servisin analiz aracının hangi hesapla hangi integrity level çalıştığını kaydetmeden DACL sonucu yorumlanmamalıdır. Yönetici olarak çalışan analiz aracının bağlanabilmesi, standart kullanıcının bağlanabildiğini göstermez.

laboratuvarda:

• YaziPipeLab.Client.exe standart kullanıcıyla,
• YaziPipeLab.Server.exe UAC yükseltilmiş yönetici bağlamında,
• YaziPipeLab.AdminPipe çift yönlü yerel kanal olarak,
• %ProgramFiles%\YaziPipeLab\protected-output.txt ise sentetik korunan olarak kullanıldı.

Sunucu keyfî komut veya dosya yolu kabul etmiyor. Etki yalnızca laboratuvara ait sabit dosya örnek sır üzerinde gösterildi.

2. Pipe’ı bulmak hedef süreçle eşleştirmek

PowerShell üzerinden mevcut pipe adları listelenebilir:

[System.IO.Directory]::GetFiles('\\.\pipe\') | Where-Object { $_ -like '*YaziPipeLab*' }

Gerçek değerlendirmede liste yalnızca başlangıçtır. Uygulama açık kapalıyken alınan sonuçlar karşılaştırılabilir; Process Monitor’ \Device\NamedPipe\ yolları hedef süreç filtrelenebilir; Process Explorer veya handle.exe açık handle’ın sahibi doğrulanabilir.NET uygulamalarında NamedPipeClientStream NamedPipeServerStream, native uygulamalarda ise CreateNamedPipeW, ConnectNamedPipe, ReadFile WriteFile çağrıları aranabilir.

3. DACL gerçek erişimi birlikte değerlendirmek

SafiyeMonitor taramasında laboratuvar pipe’ı erişilebilir olarak bulundu. DACL analizinde sahip BUILTIN\Administrators, riskli ACE ise Everyone (0x001F019F) olarak görüntülendi. SDDL çıktısındaki WD, Everyone SID’ini temsil ediyor.

Şekil 3 — SafiyeMonitor, Everyone grubuna verilen geniş hakkı aday bulgu olarak işaretliyor.

Araç çıktısı tek başına nihai etki değildir. Aynı DACL standart kullanıcı PowerShell oturumundan okunarak Everyone / FullControl / Allow kaydı ayrıca doğrulandı.

Şekil 4 — Aynı güvenlik tanımlayıcısının bağımsız PowerShell kontrolü.

iki görüntü, düşük yetkili kullanıcının kanala ulaşabildiğini güvenlik tanımlayıcısının gereğinden geniş olduğunu gösterir. Henüz yerel yetki yükseltme kanıtlanmış değildir; bunun için servis üzerinden korunan işlemin gerçekleşmesi gerekir.

SafiyeMonitor olmadan manuel doğrulama

pentesterın özel araca bağlı kalması gerekmez. Kontrollü istemci bağlantısı PowerShell kurulabilir:

$pipe = [System.IO.Pipes.NamedPipeClientStream]::new( '.', 'YaziPipeLab.AdminPipe', [System.IO.Pipes.PipeDirection]::InOut ) $pipe.Connect(3000)

Bağlantının başarılı olması yalnızca pipe instance’ına erişilebildiğini kanıtlar. Hassas işlem için protokolün anlaşılması gerekir. aşamada meşru istemcinin zararsız istekleri gözlenebilir, NET serialization kodu incelenebilir veya ReadFile/WriteFile çağrıları debugger takip edilebilir. Bilinmeyen üretim protokolüne rastgele veri göndermek yerine yetkili laboratuvarda sentetik istek kullanılmalıdır.

Laboratuvar protokolü satır sonuyla biten basit JSON mesajıdır:

{"action":"readSecret","role":"admin","value":null}

Servis hatalı olarak role alanını doğrulanmış kimlik kabul. Standart kullanıcı önce korunan dosyaya doğrudan yazmayı denedi Windows erişimi tarafından reddedildi. Aynı oturumdan role=admin mesajı gönderildiğinde ise servis örnek sırrı döndürdü.

Şekil 5 — Aynı standart kullanıcı doğrudan korunan kaynağa erişemiyor, fakat istemci kontrollü rol alanıyla ayrıcalıklı servis işlevini çağırabiliyor. 4. Ayrıcalıklı etkiyi göstermek

Uygulama içi rol aşımı işletim sistemi seviyesindeki etkiyi ayırmak için ikinci istek kullandık:

{"action":"writeProtected","role":"admin","value":"SAFIYE-POC: Standart kullanici ayricalikli pipe uzerinden satiri yazdi"}

Standart kullanıcı %ProgramFiles% altındaki laboratuvar dosyasına doğrudan yazamazken yükseltilmiş sunucu aynı dosyayı değiştirdi. SafiyeMonitor’daki istek, başarılı sunucu yanıtı Notepad’deki sonuç aynı görüntüde kaydedildi.

Şekil 6 — Düşük yetkili istemcinin belirlediği veri, yüksek yetkili servis tarafından korunan laboratuvar dosyasına yazıldı.

sonuç yerel yetki sınırının ölçülebilir biçimde aşıldığını gösterir. Ancak laboratuvar keyfî dosya yolu veya komut kabul etmediği için etki “yönetici kabuğu elde edildi” şeklinde genişletilemez. Kanıtlanan durum, standart kullanıcının doğrudan değiştiremediği belirli OS kaynağını yükseltilmiş servis üzerinden değiştirebilmesidir.

Kanıt merdiveni GözlemKanıtladığıTek başına kanıtlamadığıPipe adı bulunduIPC endpoint’i mevcutHedef uygulamaya ait olduğuHedef süreç pipe’ı açtıSüreç pipe ilişkiliStandart kullanıcının erişebildiğiStandart kullanıcı bağlandıBağlantı erişimi varHassas işlem yetkisi olduğuMesaj yanıt kaydedildiProtokol kullanılabiliyorYetki sınırının aşıldığıSahte rol korunan işlev çalıştıUygulama yetkilendirmesi aşılabiliyorOS seviyesinde privilege escalation olduğuServis korunan OS kaynağını değiştirdiYerel yetki yükseltme etkisi varKeyfî kod çalıştırılabildiği

ayrım rapor kalitesini doğrudan etkiler. “Pipe erişilebilir” aday saldırı yüzeyidir; “düşük yetkili kullanıcı korunan kaynağı servis ayrıcalığıyla değiştirdi” ise doğrulanmış etkidir.

Pipeline Hardening

Kalıcı çözüm tek if veya tek DACL değişikliğinden oluşmaz. Bağlantı erişimi uygulama seviyesi yetkilendirme birlikte düzeltilmelidir.

Pipe DACL’ini açıkça tanımlamak

Laboratuvarın zafiyetli sürümünde pipe mantıkla oluşturuluyordu:

security.AddAccessRule(new PipeAccessRule( new SecurityIdentifier(WellKnownSidType.WorldSid, null), PipeAccessRights.FullControl, AccessControlType.Allow));

Hardened sürümde erişim yalnızca mimarinin gerçekten ihtiyaç duyduğu Administrators SYSTEM SID’leriyle sınırlandı. Genel üründe SID’ler doğrudan kopyalanmamalı; ürünün servis hesabı, istemci grubu işlem modeli için gereken en dar haklar seçilmelidir.

Aynı kullanıcı aynı yükseltme düzeyindeki süreçler.NET üzerindeki PipeOptions.CurrentUserOnly yararlı olabilir. Microsoft belgesine göre Windows’ta hem kullanıcı hesabını hem elevation level’ı kontrol. Farklı hesaplarla çalışan servis mimarilerinde ise açık PipeSecurity politikası gerekir. Ayrıca NamedPipeServerStreamAcl.Create çağrısında CurrentUserOnly kullanılırsa geçirilen özel PipeSecurity yok sayılır; iki mekanizmanın birleştiği varsayılmamalıdır. PipeOptions NamedPipeServerStreamAcl.Create.

Rolü mesajdan değil bağlantıdan almak

İstemcinin gönderdiği role, isAdmin veya kullanıcı adı yetki kararında kabul edilmemelidir. Sunucu gerçek Windows kimliğini bağlantı üzerinden almalı sunucu tarafındaki politikayla değerlendirmelidir:

WindowsIdentity? caller = null;.RunAsClient(() => caller = WindowsIdentity.GetCurrent(TokenAccessLevels.Query));using (caller)
{
var principal = new WindowsPrincipal(caller!);
if (!principal.IsInRole(WindowsBuiltInRole.Administrator))
throw new UnauthorizedAccessException();
}

Kimlik belirlenemiyorsa veya impersonation başarısızsa işlem servis hesabıyla devam etmemeli, reddedilmelidir. Bağlantı iznini geçen kimlik için işlem yetkisi yine ayrı kontrol edilmelidir.

Şekil 7 — Sol tarafta Everyone/FullControl istemci kontrollü rol; sağ tarafta daraltılmış DACL gerçek Windows token’ı bulunuyor. Servisin yapabileceklerini sınırlamak

Servis yalnızca işlevinin gerektirdiği işletim sistemi izinleriyle çalışmalıdır. Mesaj protokolü keyfî komut, dosya yolu veya SQL metni kabul eden genel amaçlı yürütme arayüzüne dönüşmemelidir. İşlem adları allowlist tanımlanmalı; kimlikleri, mesaj boyutları alan tipleri doğrulanmalıdır.

Yerel kullanım bekleniyorsa uzak istemciler ayrıca engellenmelidir. Native API kullanan servislerde PIPE_REJECT_REMOTE_CLIENTS mimariye göre değerlendirilebilir. İlk pipe instance’ını korumak, istemci sunucu kimliğinin doğrulanmasının yerine geçmez.

SQL tarafını ayrıca sağlamlaştırmak

Pipe güvenli olsa bile SQL sorgusu kullanıcı girdisiyle birleştiriliyorsa SQL injection riski devam eder:

string sql = "SELECT Status FROM Reports WHERE Code = '" + reportCode + "'";

Parametreli sorgu kullanılmalıdır:

using var command = new Microsoft.Data.SqlClient.SqlCommand( "SELECT Status FROM Reports WHERE Code = ", connection);command.Parameters.Add("", System.Data.SqlDbType.NVarChar, 64)
Value = reportCode;

Parametre kullanmak girdinin SQL kodu olarak yorumlanmasını engeller; kullanıcının ilgili rapora erişim hakkını sağlamaz. yetkisi ayrıca kontrol edilmeli, veritabanı hesabına yalnızca gereken tablo işlemler için izin verilmelidir. Ortak yönetici parolasını istemci EXE’sinde taşımak yerine sunucu tarafı kimlik sır yönetimi tercih edilmelidir.NET parametreleri için Microsoft’un yapılandırma belgesi incelenebilir.

Düzeltmeyi yeniden test etmek

Hardening iki farklı bağlamda yeniden test edildi. SafiyeMonitor backend’i yönetici yetkisiyle çalıştığı için Administrators sınırlandırılmış pipe’a bağlanabildi. Buna rağmen aynı writeProtected isteği kez uygulama katmanında denied sonucunu. Görseldeki Everyone risk bilgisi vulnerable aşamada yapılan taramadan panelde kalan önceki kayıttır; post-hardening DACL ölçümü olarak kullanılmamalıdır.

Şekil 8 — Pipe’a bağlanabilen yükseltilmiş analiz aracı bile istemci kontrollü role=admin alanıyla ayrıcalıklı işlemi yaptıramıyor.

Ardından aynı standart kullanıcı aynı PowerShell bağlantı koduyla test tekrarlandı. Pipe DACL’i artık düşük yetkili token’a bağlantı izni vermediği için Connect çağrısı UnauthorizedAccessException reddedildi.

Şekil 9 — Aynı test kullanıcısı aynı istemci kodu, hardened DACL sonrasında pipe’a bağlanamıyor.

düzeltmenin başarılı sayılması için yalnızca saldırı isteğinin reddedilmesi yetmez. Meşru kullanım doğrulanmalıdır:

TestBeklenen sonuçYetkili kimlik, izinli işlem kaynakİşlem tamamlanırYetkisiz kimlikBağlantı veya işlem katmanında reddedilirBağlanabilen kimlik, izinsiz işlemServis tarafından reddedilirKimliği belirlenemeyen istekİşlem başlamadan reddedilirGeçersiz veya aşırı uzun mesajKaynak sınırları korunarak reddedilirYeniden bağlantı veya rol değişikliğiÖnceki yetki kararı taşınmazNormal uygulama akışıTanımlanan veri sınırları içinde çalışır Sonuç

Named pipe denetiminde en önemli soru pipe’ın bulunup bulunmadığı değildir: Hangi kimlik, hangi işlemi, hangi hesabın yetkileriyle gerçekleştirebiliyor?

Laboratuvarımızda Everyone: FullControl DACL’i düşük yetkili kullanıcının kanala ulaşmasını sağladı; istemciden gelen role=admin değerine güvenilmesi uygulama yetkilendirmesini kaldırdı; yükseltilmiş servisin korunan dosyayı değiştirmesi ise iki hatayı ölçülebilir yerel yetki yükseltme etkisine dönüştürdü.

Sağlam çözüm aynı zinciri tersinden kurmalıdır: pipe erişimini en dar SID haklarla sınırlandırmak, kimliği bağlantının Windows token’ından almak, her işlemi kaynağı sunucu tarafında yetkilendirmek, servisin yetkilerini azaltmak düzeltmeyi aynı düşük yetkili kullanıcıyla yeniden test etmek.

pentester açısından güçlü bulgu, yalnızca zayıf ACE ekran görüntüsü değildir. Başlangıç yetkisi, erişim kontrolü, protokol isteği, servis kararı, korunan üzerindeki sonuç hardening sonrası ret birlikte gösterildiğinde hem etki hem çözüm tartışmasız hâle gelir.