Windows "Güvenli Masaüstü" modu nasıl çalışır?

Kısa cevap

"Güvenli Masaüstü" adını iddia eden üç ayrı sorun vardır:

• GINA ve Kimlik Bilgisi Sağlayıcı Modeli gibi Windows yerleşik işlevleri.
• Aynı kullanıcı olarak çalışan ayrıcalıklı ve ayrıcalıksız uygulamaların ayrılması (nominal olarak ayrıcalık yükselmesini önler), aşağıdakilerle ilgili olabilir veya olmayabilir:
• SwitchDesktop(), KeePass'ın kullandığı şeydir ve (emin değilim) DLL Enjeksiyona dayanıklı olabilir).

Ayrıntılı cevap

Windows GUI'lerinin nasıl oluşturulduğuna hızlı bir primer olarak, temelde her şey CreateWindow() (her şeyi, her düğmeyi, her menüyü, her şeyi) olarak adlandırılan bir işlevden geçer ve hWnd veya Pencere verilir Üstesinden gelmek. Bu pencereleri değiştirmek başka bir işlevle yapılır, SendMessage().

İşte yakalama. Bir kullanıcı modu uygulaması olarak, doğru API çağrıları yapmak Diğer Windows'a oldukça kolay mesaj gönderebilirim. Düğmelerin diğer insanların formlarından kaybolması oldukça önemsizdir. DLL enjeksiyon yapmak ve mesaj alan mesaj döngüsünü bağlamak biraz daha zordur (işletim sistemi kendilerine bir şey olduğunda Windows mesajları gönderir) ama o kadar da zor değil. , "Evet/hayır" formunuzu otomatik olarak gönderebilirim. Veya etiketi ReallyDodgyVirus.exe Yerine Explorer.exe Olarak değiştirebilirim ve daha akıllıca olmazsınız.

Ekle: Gerçekten iyi bir makale Kodunuzu çalışan bir işlemin adres alanına getirmenin çeşitli teknikleri hakkında.

Şimdi, KeePass ne yapıyor?

Kaynağın çok kısa bir incelemesi, üzerinde bulunduğunuz fiziksel görüntüleme aygıtına bağlı ikinci bir masaüstü oluşturmak için CreateDesktop(), SwitchDesktop() ve CloseDesktop() kullandıklarını gösterir. İngilizce olarak, çekirdekten kendileri için hWnd nesneleri başka bir uygulamanın SendMessage() öğesinin katlanabilir aralığının dışında olan yalıtılmış bir masaüstü oluşturmasını istiyorlar.

SwitchDesktop, varsayılan masaüstünün kullanıcı arayüzünün güncellenmesini askıya aldığını belirtmeliyim. İleti döngüleri de donmuş olup olmadığından emin değilim - masaüstü yeni bir iş parçacığı olarak yaratıldığından şüphelenmiyorum.

Bu örnekte, KeePass is kullanıcı arayüzünü çizdiğinden, yürütme değil, anladığım kadarıyla NT AUTHORITY/SYSTEM Olarak. Bunun yerine, yeni masaüstü temel olarak mevcut masaüstünün geri kalanından ayrı olarak oluşturulur ve onu korur. Bu konuda düzeltilmekten mutluluk duyacağım. Ancak, SwitchDesktop için MSDN konusuna bakın:

Masaüstü görünmez bir pencere istasyonuna aitse SwitchDesktop işlevi başarısız olur. SwitchDesktop ayrıca WinLogon ve ScreenSaver masaüstü bilgisayarlar gibi güvenli bir masaüstü ile ilişkilendirilmiş bir işlemden çağrıldığında da başarısız olur. Güvenli bir masaüstüyle ilişkili işlemler, özel UserInit işlemlerini içerir. Bu tür çağrılar genellikle "erişim reddedildi" hatasıyla başarısız olur.

Bu iletişim kutuları (ekran koruyucular, Windows oturum açma), her zaman NT AUTHORITY\SYSTEM Olarak yürütmek ve UserInit işleminin gereken geçerli kimlik doğrulaması için alt işlemleri oluşturduğu şekilde Windows'a daha derinden oluşturulduğu anlamına gelir. ayrıcalık düzeyi.

Bunu ortaya koymamın nedeni, iki sorun olduğuna inanmam: farklı masaüstleri ve ayrıcalık ayrımı. Mark Russinovich'in Güvenli Masaüstü konusunun tartışılması :

Windows Bütünlük Mekanizması ve UIPI, yüksek uygulamalar etrafında koruyucu bir bariyer oluşturmak için tasarlanmıştır. Orijinal hedeflerinden biri, yazılım geliştiricilerinin kısayollar almasını ve yönetim görevlerini yerine getirmek için zaten yükseltilmiş uygulamalardan yararlanmasını engellemektir. Standart kullanıcı haklarıyla çalışan bir uygulama, yönetim işlemlerini gerçekleştirmek için teklifini yapmak veya kodunu yükseltilmiş bir uygulamaya enjekte etmek için yükseltilmiş bir uygulamaya sentetik fare veya klavye girişleri gönderemez.

SteveS'in dediği gibi UAC, NT AUTHORITY/SYSTEM Olarak ayrı bir masaüstü işlemi gerçekleştirir. İşlem Gezgini üzerinden UAC'yi (consent.exe) Çalışırken yakalayabilirseniz, şöyle görünür:

Ayrıcalıkları bir süreç olarak artan ayrıcalıklara sahip değilim, ama burada anladığımı düşünüyorum: Windows API'sındaki ayrıcalık yükseltme sürecinin NT AUTHORITY/SYSTEM Olarak çalışmasına neden olduğuna inanıyorum (bu nedenle yeni süreci istediği ayrıcalıklar altında, bu durumda bir Yönetici). Bir uygulama daha yüksek ayrıcalıklar istediğinde, bu soru size yerel olarak yeni bir masaüstünde sorulur ve hiçbir uygulamanız Masaüstü Tutamağı veya GUI öğesi tutamaçlarından hiçbirini alamaz. Onayladığınızda consent.exe İşlemi ayrıcalıklı kullanıcı olarak oluşturur. Bu nedenle, NT AUTHORITY\SYSTEM Olarak çalışan işlem, güvenli bir masaüstü oluşturma yöntemi olarak değil, yeni bir ayrıcalıklı işlem oluşturma ihtiyacının bir sonucudur. Masaüstünün varsayılandan farklı olması, her iki durumda da güvenliği artıran şeydir.

Mark'ın yukarıda ne anlama geldiğine inanıyorum, bu güvenli masaüstlerine ek olarak iki şey oluyor:

• Varsayılan yönetici masaüstünüz aslında Windows XP ve önceki sürümlerin aksine ayrıcalıksız olarak çalışıyor ve
• Ayrı ayrı masaüstlerinde ayrıcalıksız ve ayrıcalıklı uygulamalar var (sorumluluk reddi: bellekteki nesneler üzerinde ACL olabilir, emin değilim), ayrıcalıklı kodun ayrıcalıklı nesnelere erişememesini sağlar.

Windows Oturum Açma Kullanıcı Arabirimi Vista/7'de yeniden farklıdır.

Açıkçası, bu yöntemlerin hiçbiri sizi çekirdek modu kök setlerine karşı savunmayacaktır, ancak ayrıcalıklı uygulamaları yalıtarak veya hassas iletişim kutusu KeePass durumunda ayrıcalık yükselmesini ve kullanıcı arabirimi bütünlüğünün bozulmasını engellemezler.

Düzen

KeePass koduna daha sıkı baktığımda, bu kullanışlı C # parçasını gördüm:

Bitmap bmpBack = UIUtil.CreateScreenshot();
if(bmpBack != null) UIUtil.DimImage(bmpBack);
/* ... */

SecureThreadParams stp = new SecureThreadParams();
stp.BackgroundBitmap = bmpBack;
stp.ThreadDesktop = pNewDesktop;

Buradan, aslında consent.exe'yi taklit etmek için KeePass'ın arka planın ekran görüntüsünü aldığını, kararttığını ve eski masaüstünün arka planıyla yeni masaüstünü oluşturduğunu görebilirsiniz. Bu yüzden eski masaüstünün işlenmemiş olsa bile çalışmaya devam ettiğinden şüpheleniyorum. Bu bence hiçbir sihir NT AUTHORITY\SYSTEM Eylem hem KeePass ve consent.exe İle gerçekleşiyor doğrular (Ben consent.exe UI-wise aynı şeyi yapıyor şüpheli, sadece bağlamda başlatılıyor olur NT AUTHORITY\SYSTEM).

Düzenleme 2

DLL Enjeksiyon dediğimde, özellikle DLL enjeksiyon kullanıcı arayüzünü bozmayı düşünüyorum. DLL Enjeksiyon mümkün olmaya devam ediyor) bir süreç olarak KeePass üzerinde, bu güvenli kullanıcı arayüzünü etkilemek için kullanıp kullanamayacağından emin değilim, ancak işlemin ve iş parçacıklarının belleğine erişmek için kullanılabilir, böylece girilen parola ön şifrelemesini yakalayabilir. Zor, ama mümkün olduğunu düşünüyorum, eğer bilseler, bu konuda tavsiyede bulunan birini takdir ediyorum.