A a kibertámadások többsége az ellopott hitelesítő adatokra támaszkodhat – amelyeket vagy az alkalmazottak és a végfelhasználók megosztására csalva, vagy a munkaállomásokon és a hálózat más rendszerein gyorsítótárazott tartományi hitelesítő adatok begyűjtésével szereztek. Ezek az ellopott hitelesítő adatok lehetővé teszik a támadók számára, hogy oldalirányban mozogjanak a környezetben, miközben gépről gépre váltanak – mind a helyszínen, mind a felhőben – egészen addig, amíg el nem érik az üzleti szempontból kritikus eszközöket.
A Uber megsértése még szeptemberben támadók megtalálta a hitelesítő adatokat egy adott PowerShell-szkriptben. De rengeteg kevésbé feltűnő, de ugyanolyan káros módszer létezik, amellyel a támadók olyan hitelesítő adatokat találhatnak, amelyek lehetővé teszik számukra a környezethez való hozzáférést. Ide tartoznak a közös helyi hitelesítési adatok, a hasonló jelszavakkal rendelkező helyi felhasználók, valamint a hálózati megosztásokon lévő fájlokban tárolt hitelesítő adatok.
Kutatásunk során azzal a kérdéssel szembesültünk, hogy egy kompromittált gépről milyen információkat lehet kinyerni – a sérülékenységek kihasználása nélkül – oldalirányú mozgatáshoz vagy érzékeny információk kinyeréséhez. Az itt használt összes eszköz elérhető nálunk GitHub tárolóból.
A szervezetek számos eszközre támaszkodnak az SSH, FTP, Telnet vagy RDP protokollokat használó kiszolgálók és adatbázisok hitelesítéséhez – és ezen eszközök közül sok a hitelesítési adatokat menti a hitelesítés felgyorsítása érdekében. Három ilyen eszközt – a WinSCP-t, a Robomongo-t és a MobaXtermet – vizsgáljuk meg, hogy megmutassuk, hogyan tud a támadó kinyerni a nem tiszta szöveges hitelesítő adatokat.
WinSCP: Obfuszkált hitelesítő adatok
Ha a tartományvezérlő nem érhető el, a felhasználó a sikeres tartományi bejelentkezés után helyileg elmentett gyorsítótárazott hitelesítő adatokkal férhet hozzá a rendszererőforrásokhoz. Mivel a felhasználó korábban jogosult volt, a felhasználó a tartományfiók használatával bejelentkezhet a gépre a gyorsítótárazott hitelesítő adatokon keresztül akkor is, ha a felhasználót korábban hitelesítő tartományvezérlő nem érhető el.
A WinSCP lehetőséget kínál a távoli gépekhez SSH-n keresztüli csatlakozáshoz használt hitelesítő adatok mentésére. Míg a hitelesítő adatok el vannak rejtve a Windows rendszerleíró adatbázisában (ComputerHKEY_CURRENT_USERSOFTWAREMartin PrikrylWinSCP 2Sessions) mentve, egyáltalán nincsenek titkosítva. Bárki, aki ismeri az obfuszkáláshoz használt algoritmust, hozzáférhet a hitelesítő adatokhoz.
Mivel a WinSCP forráskódja elérhető a GitHubon, sikerült megtalálnunk az obfuszkációs algoritmust. Olyan eszközt használtunk, amely ugyanazt az algoritmust valósította meg a hitelesítő adatok homályosságának megszüntetésére, és tiszta szövegben fértünk hozzá a hitelesítő adatokhoz.
A tárolt hitelesítő adatok védelmére szolgáló homályos algoritmus alkalmazása nem a legjobb gyakorlat, mivel könnyen visszafordítható, és hitelesítő adatok ellopásához vezethet.
Robomongo: Nem titkos kulcs
A Robomongo (jelenleg Robo 3T) egy MongoDB-kliens, amelyet a Mongo adatbázis-kiszolgálókhoz való csatlakozásra használnak. Amikor menti a hitelesítő adatait, azok titkosítva lesznek, és a robo3t.json JSON fájl. A hitelesítő adatok titkosításához használt titkos kulcsot szintén helyileg, tiszta szöveggel, a robo3t.key fájlt.
Ez azt jelenti, hogy a géphez hozzáférő támadó a tiszta szövegben mentett kulcsot használhatja a hitelesítő adatok visszafejtésére.
Megnéztük a Robomongo forráskódját a GitHubon, hogy megértsük, hogyan használják a kulcsot a jelszó titkosításához, és megtudtuk, hogy a Qt SimpleCrypt lib-jét használja. Míg a Robomongo titkosítást használ a hitelesítő adatok biztonságos tárolására, az a tény, hogy a titkos kulcsot tiszta szövegben menti, nem a legjobb gyakorlat. A támadók esetleg elolvashatják, mert a munkaállomáshoz hozzáféréssel rendelkező bármely felhasználó visszafejtheti a hitelesítő adatokat. Még ha az információ olyan módon van is kódolva, hogy az emberek nem tudják elolvasni, bizonyos technikák meghatározhatják, hogy melyik kódolást használják, majd dekódolják az információt.
MobaXterm: A jelszó visszafejtése
A MobaXterm egy hatékony eszköz a távoli gépekhez való csatlakozáshoz különféle protokollok használatával, például SSH, Telnet, RDP, FTP stb. A hitelesítő adatokat a MobaXtermen belül elmenteni kívánó felhasználót felkérik, hogy hozzon létre egy fő jelszót érzékeny adatainak védelme érdekében. Alapértelmezés szerint a MobaXterm csak új számítógépen kéri a fő jelszót.
Ez azt jelenti, hogy a fő jelszó valahol el van mentve, és a MobaXterm lekéri, hogy hozzáférjen a titkosított hitelesítő adatokhoz. A Sysinternals Suite Procmon segítségével leképeztük a MobaXterm által elért összes beállításkulcsot és fájlt, és megtaláltuk a Windows rendszerleíró adatbázisába mentett fő jelszót (ComputerHKEY_CURRENT_USERSOFTWAREMobatekMobaXtermM). A hitelesítési adatok és a jelszavak a C és P rendszerleíró kulcsokba kerülnek.
Kezdetben nem tudtuk visszafejteni a fő jelszót, amelyet DPAPI-val titkosítottak. Végül rájöttünk, hogy az első 20 DPAPI bájt, amely DPAPI használatakor mindig ugyanaz, el lett távolítva. Amikor hozzáadtuk az első 20 bájtot, sikerült visszafejtenünk a DPAPI titkosítást, hogy megkapjuk a fő jelszó SHA512 hash-jét. Ez a hash a hitelesítő adatok titkosítására és visszafejtésére szolgál.
Itt a hitelesítő adatok biztonságos tárolására használt titkosítási kulcs DPAPI használatával kerül mentésre. Ez azt jelenti, hogy csak az a felhasználó férhet hozzá, aki elmentette a hitelesítő adatokat. Azonban egy rendszergazdai hozzáféréssel rendelkező felhasználó vagy egy támadó, aki hozzáférést kap az áldozat munkamenetéhez, szintén visszafejtheti a gépen tárolt hitelesítő adatokat.
Ismerje meg a kockázatokat
A fejlesztők, a DevOps és az IT különféle eszközöket használnak a távoli gépekhez való csatlakozáshoz és a hozzáférési adatok kezeléséhez. A szállítóknak ezeket az érzékeny információkat a legbiztonságosabb módon kell tárolniuk. A titkosítás azonban mindig az ügyféloldalon történik, és a támadó replikálhatja az eszköz viselkedését a hitelesítő adatok visszafejtése érdekében.
Mint mindig, most sem létezik olyan varázslatos megoldás, amely megoldhatná az itt tárgyalt összes problémát. A szervezetek azonban kezdhetik azzal, hogy megvizsgálják az általuk jelenleg használt szolgáltatásokat. Pontos kockázati mátrixot állíthatnak össze, és jobban felkészülhetnek az adatszivárgásokra azáltal, hogy jobban ismerik az általuk tárolt érzékeny adatok és hitelesítő adatok típusát.
