A blogon már régebben is szerepelt az Office régi verzióiból bent maradt DDE funkciók kihasználása, most egy kicsit visszatérünk erre a sérülékenységre, mert nem hogy nem kopott ki, de újra "hódít".

A régebbi Office alkalmazásokban a Dynamic Data Exchange (DDE) protokoll biztosította az Office alkalmazások közötti adatcserét, ezt ugyan már az új Office verziók nem használják, viszont kompatibilitási okokból a funkció megtalálható a modernebb Office kiszerelésekben.

A DDE „macro-less” malware tavaly kapott nagy publicitást, a Sense Post kutatói által bemutatott módszerre aztán a vírusvédelmi vendorok is reagáltak, szóval a „klasszikus” DDE hívásokat meglehetősen jól észlelik az Anti-Vírus megoldások (meg persze a Microsoft is).

Azonban a DDE bizniszben sem áll meg az élet, a mostani postban a DDE „macro-less” módszerek „új generációját” mutatjuk be, szóval a DDE kihasználási lehetőségek továbbra is működhetnek.

Mivel korábban már írtunk a Content Disarm and Reconstruction (CDR) megoldásokról és szanitizációs eljárásokról, azt is megnézzük, hogyan boldogul a CDR, és persze a vírusvédelem a trükkös DDE tartalmakkal.

DDE élt, él, élni fog?

A mintában egy olyan módszert használunk, amely a régi, DOS-idők berögződése miatt tud működni (és persze azért, mert nem a „klasszikus” DDE-hívásokkal operál).

Az „áldozat” szerepében az Excel, akinek jó tulajdonsága, hogy a cella függvényhívásokban akár külső alkalmazások is szerepelhetnek.
 

Látjuk, hogy a RunDll32 kerül meghívásra a cellában, amely aztán az URL.dll-en keresztül megnyitja a weboldalt.

Ami az érdekes, hogy a régi DOS-beidegződés miatt a külső alkalmazás meghívásakor csak az első 8 karakter számít, az utána következő string-résszel egyáltalán nem foglalkozik az Excel.

Az olyan megoldások, amelyek esetleg vizsgálják azt, hogy milyen külső alkalmazás (akár potenciálisan veszélyes alkalmazás) kerül meghívásra, vakfoltra futnak, hiszen még ha ugranának is a RunDll32(.exe)-re, a „rundll32idebarmitbeirhatok” alkalmazásnevet nem fogják potenciálisan veszélyesnek tartani.

Szóval ezt akár nagyzolva obfuszkációnak is lehet nevezni (mivel végül is az).

Persze nem csak böngészőt lehet indítani, ott van az msiexec vagy a regsrv32 amit fel lehet használni, de végső soron akár a RunDll32-vel meghívható pl. a Kernel32.dll, amelyen keresztül aztán további utasítások adhatók ki. Ráadásul az a szép ebben, hogy egyetlen cellában akár több egymást követő parancs is befűzhető (pl. az egyik letölt, a másik elindítja).

Mit mond a vírusvédelem?

Bár a vírusvédelmi gyártók képviselői előszeretettel hangoztatják, hogy a VirusTotal nem alkalmas az egzakt tesztelésre, ezt általában a malware készítők nem nagyon veszik figyelembe, mert, ha nem is a Vírus Total-t, de hasonló, un. „counter AV/AM” szolgáltatásokat használnak a kódok felismerésének teszteléséhez (az egyik legnagyobb ilyen szolgáltató – Scan4You - főmuftiját nemrégiben zárták be). 

Szóval nézzük, mit mond a kódra a Virus Total 60 motorja.

Meglepő módon egyetlen gyártó, a Baidu motorja észleli a nem teljesen barátságos kódot, a többi motor pedig némán hallgat. (Buherátor mester által összeszedett "tipikus" és lehetséges gyártói magyarázkodó válaszokból most is tetszőlegest lehet választani a miértre.) 

Akkor most nézzük meg, hogy mi történik akkor, ha a fájlt átfuttatjuk a DocBleach open source CDR alkalmazáson.

Content Disarm and Reconstruction

A CDR alkalmazások elvileg szétszedik a fájlokat, majd újra összeépítik őket úgy, hogy a nem szokványos és beágyazott funkciókat egyszerűen kihagyják az új állományból.

A marketingben a CDR alkalmazásokat ezért úgy tüntetik fel, hogy a még nem ismert fenyegetéseket is mitigálják – hiszen nem felismerik a kártékony kódot, hanem a dokumentumok formátumát ismerve a potenciálisan veszélyes objektumelemeket távolítják el, azokat, amelyek alkalmasak lehetnek kártékony tartalmak megjelenítésére és/vagy futtatására.

A mostani tesztig 100%-ban egyetértettem a marketing szöveggel, abból kiindulva, hogy a CDR-nek egyszerű dolga van, csak rakja össze az állományt az embeded objektumok meg streamek nélkül és kész.

Sajnos Buherátornak megint igaza volt, a CDR-ek sem mindenhatók.

Három CDR megoldást teszteltem, amelyből az egyik (amúgy méregdrága fizetős) csont nélkül benne hagyta az „obfuszkált” kódot, amely a szanitizáció után is tökéletesen működőképes maradt.

Az ingyenes DocBleach azonban tette a dolgát, és "kitakarította" a DDE kódot az Excel fájlból.

Ami viszont meglepő volt a számomra, hogy a fájl a szanitizáció után is tartalmazott DDE-hívást. Mi a fene!?

A DocBleach láthatóan újraépítette a fájlt, viszont nem egyszerűen csak „elfelejtette” visszatenni bele az objektumot, hanem beletett a helyére egy másikat, amely elindítja a CMD-t, majd kilép.

Ez meglehetősen szokatlan, bár működik. Összehasonlításul, a harmadik, fizetős CDR megoldás teljesen kireszelte az objektumot a szanitizált fájlból.

A videót itt tudjátok megnézni:

Összefoglalás, konklúzió

Szóval megint az van, hogy bár az elv és az elgondolás jó, a CDR megvalósítások azonban nem minden esetben hozzák az elvárt eredményt.

A legfontosabb tanulság mégis az, hogy ha valaki védelmi megoldásba akar beruházni, nem árt, ha vásárlás előtt leteszteli azt, amiért pénzt ad ki.

A védelmi eszközökbe vetetett túlzó bizalom sokkal károsabb, mint az adott védelmi rendszer hiánya: vakká tehet bennünket, hamis biztonságérzetet ad – és esetleg súlyos csalódáshoz meg incidenskezeléshez vezet(het).

A Microsoft már a tavalyi DDE-hype idején bejelentette, hogy kivégzik a DDE-t és a későbbi termékekben már nem lesz implementálva. Az Excel 2016-tól már elvileg letiltható a DDE, erről itt lehet bővebben olvasni.