Ez a cikk a Fileless Malware sorozat része. A sorozat összes többi része:
- The Adventures of the Elusive Malware, IV. rész: DDE és Word dokumentummezők (itt vagyunk)
Ebben a cikkben egy még összetettebb, többlépcsős, fájl nélküli támadási forgatókönyvbe akartam belemerülni, a rendszer rögzítésével. De aztán ráakadtam egy hihetetlenül egyszerű, kód nélküli támadásra – nincs szükség Word vagy Excel makrókra! Ez pedig sokkal jobban bizonyítja a cikksorozat alapjául szolgáló eredeti hipotézisemet: egy szervezet külső peremének áttörése egyáltalán nem nehéz feladat.
Az első támadás, amelyet leírok, a Microsoft Word biztonsági rését használja ki, amelyen alapul elavult (DDE). Már volt . A második a Microsoft COM és az objektumátviteli képességek általánosabb biztonsági rését használja ki.
Vissza a jövőbe a DDE-vel
Emlékszik még valaki a DDE-re? Valószínűleg nem sokan. Ez volt az egyik első folyamatok közötti kommunikációs protokollok, amelyek lehetővé tették az alkalmazások és eszközök adatátvitelét.
Kicsit ismerem magam is, mert régebben ellenőriztem és teszteltem a távközlési berendezéseket. Akkoriban a DDE lehetővé tette például a call centerek üzemeltetői számára, hogy átvigyék a hívóazonosítót egy CRM-alkalmazásba, amely végül megnyitotta az ügyfélkártyát. Ehhez RS-232 kábelt kellett csatlakoztatni a telefon és a számítógép közé. Régi szép idők!
Mint kiderült, a Microsoft Word még mindig DDE.
Ezt a támadást kód nélkül az teszi hatékonnyá, hogy hozzáférhet a DDE protokollhoz közvetlenül Word-dokumentum automatikus mezőiből (le a kalappal a SensePost előtt erről).
Mezőkódok egy másik ősi MS Word funkció, amely lehetővé teszi dinamikus szöveg és egy kis programozás hozzáadását a dokumentumhoz. A legkézenfekvőbb példa az oldalszám mező, amely az {PAGE *MERGEFORMAT} értékkel illeszthető be a láblécbe. Ez lehetővé teszi az oldalszámok automatikus generálását.
Tipp: A Mező menüpontot a Beszúrás alatt találja.
Emlékszem, amikor először felfedeztem ezt a funkciót a Wordben, elképedtem. És amíg a javítás nem tiltotta le, a Word továbbra is támogatta a DDE mezők opciót. Az ötlet az volt, hogy a DDE lehetővé teszi a Word számára, hogy közvetlenül kommunikáljon az alkalmazással, hogy aztán a program kimenetét át tudja adni egy dokumentumba. Ez egy nagyon fiatal technológia volt abban az időben - a külső alkalmazásokkal történő adatcsere támogatása. Később COM technológiává fejlesztették, amit alább szintén megnézünk.
Végül a hackerek rájöttek, hogy ez a DDE alkalmazás egy parancshéj is lehet, ami természetesen elindította a PowerShellt, és onnantól a hackerek azt csinálhatnak, amit akarnak.
Az alábbi képernyőképen látható, hogyan alkalmaztam ezt a lopakodó technikát: egy kis PowerShell-szkript (a továbbiakban: PS) a DDE mezőből betölt egy másik PS-szkriptet, amely elindítja a támadás második fázisát.
Köszönet a Windowsnak a felugró figyelmeztetésért, miszerint a beépített DDEAUTO mező titokban megpróbálja elindítani a shellt
A sérülékenység kihasználásának előnyben részesített módja a DDEAUTO mezővel rendelkező változat használata, amely automatikusan futtatja a szkriptet nyitáskor Word dokumentum.
Gondoljuk át, mit tehetünk ez ellen.
Kezdő hackerként például küldhet egy adathalász e-mailt, úgy tesz, mintha a Szövetségi Adószolgálattól származna, és beágyazhatja a DDEAUTO mezőt a PS-szkripttel az első szakaszhoz (lényegében egy dropper). És még csak nem is kell valódi makrókat kódolni stb., mint ahogy én tettem
Az áldozat megnyitja a dokumentumot, a beágyazott szkript aktiválódik, és a hacker a számítógép belsejébe kerül. Az én esetemben a távoli PS szkript csak kiír egy üzenetet, de ugyanilyen könnyen elindíthatja a PS Empire klienst, amely távoli shell hozzáférést biztosít.
És mielőtt az áldozat bármit is mondana, kiderül, hogy a hackerek a falu leggazdagabb tinédzserei.
A héjat a legcsekélyebb kódolás nélkül indították el. Ezt még egy gyerek is meg tudja csinálni!
DDE és mezők
A Microsoft később letiltotta a DDE-t a Wordben, de nem azelőtt, hogy a vállalat kijelentette volna, hogy a funkcióval egyszerűen visszaéltek. Érthető, hogy vonakodnak bármin is változtatni. Tapasztalataim szerint magam is láttam olyan példát, amikor a mezők frissítése a dokumentum megnyitásakor engedélyezve volt, de a Word makrókat az IT letiltotta (de értesítést mutatott). A megfelelő beállításokat egyébként a Word beállítások részben találja.
Azonban még akkor is, ha a mezőfrissítés engedélyezve van, a Microsoft Word emellett értesíti a felhasználót, ha egy mező hozzáférést kér a törölt adatokhoz, ahogyan ez a fenti DDE esetében is történt. A Microsoft valóban figyelmeztet.
Valószínűleg azonban a felhasználók figyelmen kívül hagyják ezt a figyelmeztetést, és aktiválják a mezők frissítését a Wordben. Ez azon ritka alkalmak egyike, hogy megköszönjük a Microsoftnak a veszélyes DDE funkció letiltását.
Mennyire nehéz ma javítatlan Windows rendszert találni?
Ehhez a teszteléshez AWS-munkaterületeket használtam a virtuális asztal eléréséhez. Így kaptam egy javítatlan MS Office virtuális gépet, amely lehetővé tette a DDEAUTO mező beszúrását. Nincs kétségem afelől, hogy hasonló módon találhatunk más cégeket is, amelyek még nem telepítették a szükséges biztonsági javításokat.
A tárgyak rejtélye
Még ha telepítette is ezt a javítást, vannak más biztonsági rések az MS Office-ban, amelyek lehetővé teszik a hackerek számára, hogy valami nagyon hasonlót tegyenek, mint amit mi tettünk a Word esetében. A következő forgatókönyvben megtanuljuk használja az Excelt csaliként egy adathalász támadáshoz anélkül, hogy kódot írna.
Ennek a forgatókönyvnek a megértéséhez emlékezzünk a Microsoft komponensobjektum modelljére, vagy röviden COM (Component Object Model).
A COM az 1990-es évek óta létezik, és egy "nyelvsemleges, objektumorientált komponensmodellként" definiálják, amely RPC távoli eljáráshívásokon alapul. A COM terminológia általános megértéséhez olvassa el a következőt: a StackOverflow-n.
Alapvetően a COM-alkalmazásokat Excel vagy Word végrehajtható fájlokként vagy más futó bináris fájlként képzelheti el.
Kiderült, hogy egy COM alkalmazás is futhat сценарий — JavaScript vagy VBScript. Technikailag úgy hívják scriptlet. Lehet, hogy már látta a Windows fájlok .sct kiterjesztését – ez a szkriptletek hivatalos kiterjesztése. Lényegében ezek egy XML-burkolóba csomagolt szkriptkód:
<?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>
A hackerek és a tesztelők felfedezték, hogy a Windowsban külön segédprogramok és alkalmazások vannak, amelyek elfogadják a COM-objektumokat és ennek megfelelően a szkriptleteket is.
Átadhatok egy szkriptletet a pubprn néven ismert VBS-ben írt Windows segédprogramnak. A C:Windowssystem32Printing_Admin_Scripts mélyén található. Egyébként vannak más Windows-segédprogramok is, amelyek paraméterként fogadják el az objektumokat. Nézzük először ezt a példát.
Teljesen természetes, hogy a shell akár nyomtatott scriptből is elindítható. Hajrá Microsoft!
Próbaként létrehoztam egy egyszerű távoli szkriptletet, amely elindít egy parancsértelmezőt, és kiír egy vicces üzenetet: „Most írták le!” Lényegében a pubprn egy scriptlet objektumot hoz létre, lehetővé téve a VBScript-kódnak egy burkoló futtatását. Ez a módszer egyértelmű előnyt jelent a hackerek számára, akik be akarnak osonni a rendszerbe, és elrejtőznek.
A következő bejegyzésben elmagyarázom, hogyan tudják kihasználni a COM-szkripteket a hackerek Excel-táblázatok segítségével.
A házi feladathoz vessen egy pillantást a Derbycon 2016-ból, amely pontosan elmagyarázza, hogyan használták a hackerek a szkriptleteket. És olvasni is a szkriptletekről és valamiféle becenévről.
Forrás: will.com