Bu makale Dosyasız Kötü Amaçlı Yazılım serisinin bir parçasıdır. Serinin diğer tüm bölümleri:
- Ele Geçirilmesi Zor Kötü Amaçlı Yazılımın Maceraları, Bölüm IV: DDE ve Word Belgesi Alanları (buradayız)
Bu makalede, sisteme sabitleme ile daha da karmaşık, çok aşamalı, dosyasız bir saldırı senaryosuna dalacaktım. Ama sonra inanılmaz derecede basit, kodsuz bir saldırıyla karşılaştım; Word veya Excel makrolarına gerek yoktu! Ve bu, bu makale dizisinin altında yatan orijinal hipotezimi çok daha etkili bir şekilde kanıtlıyor: Herhangi bir organizasyonun dış çevresini kırmak hiç de zor bir iş değildir.
Açıklayacağım ilk saldırı Microsoft Word'deki bir güvenlik açığından yararlanıyor. modası geçmiş (DDE). O zaten . İkincisi, Microsoft COM'daki ve nesne aktarım yeteneklerindeki daha genel bir güvenlik açığından yararlanıyor.
DDE ile geleceğe dönüş
DDE'yi hatırlayan başka kimse var mı? Muhtemelen pek fazla değil. İlklerden biriydi uygulamaların ve cihazların veri aktarımına izin veren süreçler arası iletişim protokolleri.
Ben de buna biraz aşinayım çünkü telekom ekipmanlarını kontrol edip test ediyordum. O zamanlar DDE, örneğin çağrı merkezi operatörlerinin, arayan kimliğini bir CRM uygulamasına aktarmasına ve sonuçta bir müşteri kartı açmasına izin veriyordu. Bunu yapmak için telefonunuzla bilgisayarınız arasına bir RS-232 kablosu bağlamanız gerekiyordu. Hey gidi günler!
Görünüşe göre Microsoft Word hala DDE.
Bu saldırıyı kodsuz etkili kılan şey DDE protokolüne erişebiliyor olmanızdır. doğrudan doğruya bir Word belgesindeki otomatik alanlardan (SensePost'a şapka çıkarılır) bu konuda).
Alan kodları belgenize dinamik metin ve biraz programlama eklemenizi sağlayan başka bir eski MS Word özelliğidir. En belirgin örnek, {PAGE *MERGEFORMAT} değeri kullanılarak alt bilgiye eklenebilen sayfa numarası alanıdır. Bu, sayfa numaralarının otomatik olarak oluşturulmasına olanak tanır.
İpucu: Alan menü öğesini Ekle altında bulabilirsiniz.
Word'de bu özelliği ilk keşfettiğimde hayrete düştüğümü hatırlıyorum. Yama bunu devre dışı bırakana kadar Word hala DDE alanları seçeneğini destekliyordu. Buradaki fikir, DDE'nin Word'ün uygulamayla doğrudan iletişim kurmasına izin vermesi ve böylece programın çıktısını bir belgeye aktarabilmesiydi. O zamanlar çok genç bir teknolojiydi; harici uygulamalarla veri alışverişini destekliyordu. Daha sonra aşağıda da inceleyeceğimiz COM teknolojisine dönüştürüldü.
Sonunda bilgisayar korsanları, bu DDE uygulamasının elbette PowerShell'i çalıştıran bir komut kabuğu olabileceğini fark etti ve buradan bilgisayar korsanları istediklerini yapabilirler.
Aşağıdaki ekran görüntüsü bu gizlilik tekniğini nasıl kullandığımı gösteriyor: DDE alanından küçük bir PowerShell betiği (bundan sonra PS olarak anılacaktır), saldırının ikinci aşamasını başlatan başka bir PS betiği yükler.
Yerleşik DDEAUTO alanının gizlice kabuğu başlatmaya çalıştığını belirten açılır uyarı için Windows'a teşekkürler
Güvenlik açığından yararlanmanın tercih edilen yöntemi, betiği otomatik olarak çalıştıran DDEAUTO alanına sahip bir değişken kullanmaktır. açarken Word belgesi.
Bu konuda neler yapabileceğimizi düşünelim.
Acemi bir bilgisayar korsanı olarak, örneğin, Federal Vergi Servisi'nden olduğunuzu iddia ederek bir kimlik avı e-postası gönderebilir ve ilk aşama için DDEAUTO alanını PS komut dosyasıyla (esasen bir damlalık) gömebilirsiniz. Ve benim yaptığım gibi herhangi bir gerçek makro kodlaması vb. yapmanıza bile gerek yok.
Kurban belgenizi açar, gömülü komut dosyası etkinleştirilir ve bilgisayar korsanı bilgisayarın içine girer. Benim durumumda, uzak PS komut dosyası yalnızca bir mesaj yazdırır, ancak uzak kabuk erişimi sağlayacak olan PS Empire istemcisini de kolayca başlatabilir.
Ve kurbanın bir şey söylemesine fırsat kalmadan hackerların köyün en zengin gençleri olduğu ortaya çıkacak.
Kabuk en ufak bir kodlama olmadan başlatıldı. Bir çocuk bile bunu yapabilir!
DDE ve alanlar
Microsoft daha sonra Word'de DDE'yi devre dışı bıraktı, ancak şirket bu özelliğin kötüye kullanıldığını belirtmeden önce bunu yapmadı. Herhangi bir şeyi değiştirme konusundaki isteksizlikleri anlaşılabilir. Deneyimlerime göre, bir belgeyi açarken alanların güncellenmesinin etkinleştirildiği, ancak Word makrolarının BT tarafından devre dışı bırakıldığı (ancak bir bildirim gösterdiği) bir örnek gördüm. Bu arada, ilgili ayarları Word ayarları bölümünde bulabilirsiniz.
Ancak, alan güncellemesi etkinleştirilmiş olsa bile Microsoft Word, yukarıdaki DDE'de olduğu gibi, bir alan silinmiş verilere erişim istediğinde kullanıcıyı ek olarak bilgilendirir. Microsoft sizi gerçekten uyarıyor.
Ancak büyük olasılıkla kullanıcılar yine de bu uyarıyı görmezden gelecek ve Word'deki alan güncellemesini etkinleştirecektir. Bu, tehlikeli DDE özelliğini devre dışı bıraktığı için Microsoft'a teşekkür etmek için nadir fırsatlardan biridir.
Bugün yama yapılmamış bir Windows sistemi bulmak ne kadar zor?
Bu test için sanal masaüstüne erişmek için AWS Workspaces'i kullandım. Bu şekilde DDEAUTO alanını eklememe izin veren yamasız bir MS Office sanal makinesine sahip oldum. Benzer şekilde gerekli güvenlik yamalarını henüz yüklememiş başka şirketleri de bulabileceğinizden hiç şüphem yok.
Nesnelerin gizemi
Bu yamayı yüklemiş olsanız bile, MS Office'te bilgisayar korsanlarının bizim Word'de yaptığımıza çok benzer bir şey yapmasına olanak tanıyan başka güvenlik açıkları da vardır. Bir sonraki senaryoda öğreneceğiz Excel'i herhangi bir kod yazmadan kimlik avı saldırısı için yem olarak kullanın.
Bu senaryoyu anlamak için Microsoft Bileşen Nesne Modelini kısaca kısaca hatırlayalım. COM (Bileşen Nesne Modeli).
COM, 1990'lardan bu yana var ve RPC uzaktan prosedür çağrılarına dayalı "dilden bağımsız, nesne yönelimli bileşen modeli" olarak tanımlanıyor. COM terminolojisine ilişkin genel bir anlayış için aşağıdakileri okuyun: StackOverflow'ta.
Temel olarak, bir COM uygulamasını bir Excel veya Word yürütülebilir dosyası veya çalışan başka bir ikili dosya olarak düşünebilirsiniz.
Bir COM uygulamasının da çalışabileceği ortaya çıktı senaryo — JavaScript veya VBScript. Teknik olarak buna denir Senaryo metni. Windows'taki dosyalar için .sct uzantısını görmüş olabilirsiniz; bu, komut dosyalarının resmi uzantısıdır. Temel olarak, bunlar bir XML sarmalayıcıya sarılmış komut dosyası kodudur:
<?XML version="1.0"?>
<scriptlet>
<registration
description="test"
progid="test"
version="1.00"
classid="{BBBB4444-0000-0000-0000-0000FAADACDC}"
remotable="true">
</registration>
<script language="JScript">
<![CDATA[
var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!");
]]>
</script>
</scriptlet>
Bilgisayar korsanları ve pentester'lar, Windows'ta COM nesnelerini ve dolayısıyla komut dosyalarını da kabul eden ayrı yardımcı programlar ve uygulamalar olduğunu keşfettiler.
Bir komut dosyasını VBS'de yazılmış, pubprn olarak bilinen bir Windows yardımcı programına aktarabilirim. C:Windowssystem32Printing_Admin_Scripts'in derinliklerinde bulunur. Bu arada, nesneleri parametre olarak kabul eden başka Windows yardımcı programları da var. Önce bu örneğe bakalım.
Kabuğun bir yazdırma komut dosyasından bile başlatılabilmesi oldukça doğaldır. Microsoft'a gidin!
Bir test olarak, bir kabuk başlatan ve komik bir mesaj basan basit bir uzak komut dosyası oluşturdum: "Az önce komut dosyası oluşturuldunuz!" Temel olarak, pubprn bir scriptlet nesnesi başlatır ve VBScript kodunun bir sarmalayıcı çalıştırmasına olanak tanır. Bu yöntem, sisteminize gizlice girip saklanmak isteyen bilgisayar korsanlarına açık bir avantaj sağlar.
Bir sonraki yazıda COM scriptlet'lerinin Excel elektronik tablolarını kullanan bilgisayar korsanları tarafından nasıl istismar edilebileceğini açıklayacağım.
Ödeviniz için bir göz atın Bilgisayar korsanlarının scriptletleri nasıl kullandığını tam olarak açıklayan Derbycon 2016'dan. Ve ayrıca oku senaryolar ve bir tür takma ad hakkında.
Kaynak: habr.com
