Petya: a kamu zsarolóvírus csak a záró akkord volt
Dermesztő jövőkép rajzolódik ki a Petya-támadás nyomán: egyetlen gyenge láncszem elegendő volt ahhoz, hogy óriásvállalatok hálózata is kiszolgáltatott legyen. A tanulságok csak lassan kristályosodnak ki.
Közzétette a napokban az ESET és Cisco Talos Intelligence is a Petya támadás eddigieknél is mélyebb elemzését - a Talos ráadásul hozzáférést kapott a támadási vektor kiindulópontjához, a MEDoc szervereihez is. Az egybevágó elemzéseket érdemes elolvasni szakembereknek, alább a fontosabb részleteket és a konklúziókat foglaljuk össze.
Adóbevalláson keresztül mindenhová
Azt már tudjuk egy ideje, hogy a Petya terjesztéséhez a támadók egy ukrajnai adózási-számviteli szoftvert, a MEDoc-ot használta fel. A helyi Intellect Service által fejlesztett szoftver automatikus frissítés formájában töltötte le és szabadította az áldozatok gépére a támadó kódot. Ebből már rögtön ki lehetett következtetni, hogy a támadók minden bizonnyal hozzáfértek az Intellect Service infrastruktúrájához - ezt a sejtést a cégnél az incidenselhárításban segédkező Talos-szakemberek immár egyértelműen meg tudják erősíteni.
(forrás)
Az viszont igazi újdonság, hogy a logok elemzéséből egyértelművé vált, hogy a cég rendszerét jóval korábban, április 14-e előtt feltörték. A nyomok alapján úgy tűnik, hogy az egyik üzemeltető jelszavát sikerült a támadóknak megszerezniük és ezzel a jogosultsággal ajtót nyitottak a cég szerverein. Ennek birtokában már április 14-én kiadták az első olyan frissítést a MEDoc szoftverhez, amely az áldozatok gépein backdoort nyitott és elkezdett információkat gyűjteni a támadó számára. Ezt május 15-én és június 22-én két további, szintén támadó kódot tartalmazó frissítés követte.
A frissítési csomagok elemzése alapján elég jól lekövethető, hogy a leküldött kód milyen tevékenységet végzett. Először összegyűjtötte a cégazonosítót (EDRPOU) a cég nevét e MEDoc helyi fájljaiból és elküldte a támadónak. Emellett szintén begyűjtötte a proxy szerver konfigurációs információit (amennyiben a szervezet használt ilyent) és az SMTP bejelentkezési információit is az összes, a MEDoc adatbázisában szereplő szervezet esetében.
A Gitlab mint DevSecOps platform (x) Gyere el Radovan Baćović (Gitlab, Data Engineer) előadására a november 7-i DevOps Natives meetupon.
A frissítéssel leküldött backdoor több parancs futtatására is képes, a cmd.exe megfelelő paraméterekkel történő futtatása mellett adatok kiírása fájlba, összegyűjtött információk kiküldése, a fájlrendszer bármely fájljának kiolvasása is ezek közé tartozik. De az eszköz képes fogadni adatot, kiírni azt állományba, elindítani azt, majd az állományt megsemmisíteni (törölni és többszörösen felülírni). A Talos elemzése szerint a művelet végén ezzel engedték szabadon a támadók a Petyát is, amely ezt követően zsarolóvírusként viselkedve igyekezett tönkretenni a gépen tárolt adatokat.
A támadás egyik érdekes eleme, hogy a malware-t vezérlő command-control szerver a MEDoc saját, frissítéseket terjesztő szervere volt. a kommunikációt a frissítéssel leküldött kód végig a ezzel a kiszolgálóval végezte, vagyis a tűzfal vagy bármely más szemlélő számára úgy tűnhetett, hogy a szoftver csupán frissítéseket keres megadott rendszerességgel. Ami persze azt is jelenti, hogy elképesztően nehéz lett volna pusztán a hálózati forgalmat figyelve kiszűrni a gyanús társalgást, az upd.me-doc.com[.]ua címen lévő kiszolgálót az üzemeltetők minden bizonnyal feltették az engedélyezett listára.
Supply chain attack - weakest link
A supply chain attack támadástípus nem friss koncepció, ilyen támadásra már korábban is volt példa - a MEDoc és Petya azonban várhatóan új fejezetet nyit e támadástípus történetében. Az egyetlen központi szereplő amely néhány tucatnyi fejlesztővel rendelkezik, a LinkedIn-profil alapján IT-biztonsággal foglalkozó szakemberrel eggyel sem. Ez az egy cég azonban ukrajnai vagy Ukrajnában tevékenységet végző cégek ezreihez (adott esetben százezreihez) nyújtott hozzáférést a támadóknak, így egyszerre bizonyult roppant gyenge és roppant vonzó láncszemnek is.
Ahogy a supply chain attack esetében, most is felmerül a kérdés: a nagy, kritikus infrastruktúrát, kritikus adatokat kezelő szervezetek vajon milyen hatékonysággal ellenőrzik saját szoftverbeszállítóikat? A külső forrásból származó szoftvereket ugyanis e szervezetek beengedik, adott esetben magas jogosultsággal futtatják, engedélyezik az automatikus frissítést. Sok esetben ez azt jelenti, hogy a belső hálózat és rendszerek védelme csak annyira lesz erős, mint azé a frissítéseket kínáló szerveré - miközben annak üzemeltetését valaki egészen más végzi.
A Petya szabadon engedésével a támadó egy nagyon értékes backdoor-hálózatot és információforrást adott fel. A Talos következtetése eléggé vérfagyasztó: erre nagy valószínűséggel csak azután került sor, hogy a támadó meggyőződött, ezt a képességet pótolta vagy pótolni tudja más, jobb forrásból. "Valószínűtlen, hogy ezt a képességet feláldozták volna a meggyőződés nélkül, hogy hasonló képességet szereztek volna meg vagy tudnának megszerezni a szereplő számára legmagasabb prioritású célhálózatokban." A támadó tehát a hónapokon keresztül élvezett backdoor-rendszerét (egyes források szerint akár 400 ezer PC is fertőzött lehetett) robbantotta fel a Petya leküldésével - nagy és egyelőre megválaszolatlan kérdés, hogy miért?