a hackerek pedig módszereket fejlesztettek ki a többtényezős hitelesítés (MFA) megkerülésére olyan felhőalapú termelékenységi szolgáltatásokban, mint a Microsoft 365 (korábban Office 365).
A Mitiga, a felhő-incidensekre reagáló cég által a közelmúltban elemzett BEC-támadás egy AitM-féle adathalász támadást használt, hogy megkerülje a Microsoft Office 365 MFA-t, és hozzáférjen egy felhasználói fiókhoz. A vállalat igazgatója, majd sikerült hozzáadnia egy második hitelesítő eszközt a fiókhoz az állandó hozzáférés érdekében. A kutatók szerint az általuk elemzett kampány széles körben elterjedt, nagy tranzakciókat céloz meg, egyenként akár több millió dollárt is.
Első hozzáférés a BEC támadáshoz
A támadás egy jól kidolgozott adathalász e-mailrel indult, amely a DocuSign, egy széles körben használt felhő alapú elektronikus dokumentum-aláíró szolgáltatás értesítésének álcázva volt. Az e-mailt a megcélzott üzletembernek címezték, ami arra utal, hogy a támadók felderítő munkát végeztek. Az adathalász e-mailben található hivatkozás egy támadók által vezérelt webhelyre vezetett, amely aztán átirányít a Microsoft 365 egyszeri bejelentkezési oldalára.
Ez a hamis bejelentkezési oldal AitM technikát használ, ahol a támadók fordított proxyt hajtanak végre a hitelesítési kérelmek oda-vissza küldésére az áldozat és a valódi Microsoft 365 webhely között. Az áldozat ugyanazt a tapasztalatot élvezi, mint a valódi Microsoft bejelentkezési oldalon, kiegészítve a jogos MFA-kéréssel, amelyet hitelesítő alkalmazással kell teljesítenie. A hitelesítési folyamat sikeres befejezése után a Microsoft-szolgáltatás létrehoz egy munkamenet-token-t, amelyet a rendszer MFA-nak megfelelőként jelöl meg. A különbség az, hogy mivel a támadók proxyként működtek, mostantól ők is rendelkeznek ezzel a munkamenet-tokennel, és ezzel hozzáférhetnek a fiókhoz.
Ez a fordított proxy technika nem új, és évek óta használják az MFA megkerülésére. Ehhez még felhasználóbarát, nyílt forráskódú támadási keretrendszereket is készítettek.
A másodlagos hitelesítő alkalmazás tartósságot biztosít
A Mitiga által elemzett naplók szerint a támadók az aktív munkamenetet arra használták, hogy egy másodlagos hitelesítő alkalmazást adjanak hozzá a feltört fiókhoz, így még akkor is megmaradtak, ha a munkamenet token később lejárt. Mivel már elfogták a felhasználó hitelesítő adatait, most már saját módszerük volt az MFA kódok generálására.
“További MFA-eszköz hozzáadása egy Azure AD-felhasználóhoz nem igényel további hitelesítést, például a munkamenethez tartozó MFA újbóli jóváhagyását” – áll a kutatók jelentésében. “Ez azt jelenti, hogy a támadó akár egy teljes héttel a munkamenet ellopása után is hozzáadhat egy MFA-eszközt az áldozat fiókjához anélkül, hogy további felhasználói beavatkozást, például MFA-jóváhagyást kérne.”
A kutatók úgy vélik, hogy ez a Microsoft hitelesítési rendszerének tervezési gyengesége, mivel úgy vélik, hogy a biztonságra érzékeny műveletek, például az MFA-beállítások megváltoztatása, beleértve egy új MFA-eszköz hozzáadását, új MFA-kihívást jelentenek. Mellesleg nem ez az egyetlen kényes cselekmény, ahol ez nem történik meg. Ezenkívül a kutatók szerint az Azure AD-ben a Privileged Identity Management (PIM) funkció használata, amely lehetővé teszi a rendszergazdák számára, hogy ideiglenesen növeljék jogosultságaikat, nem igényel újbóli MFA-kihívást.
“A PIM-et úgy tervezték, hogy a rendszergazdai jogosultságokkal rendelkező felhasználók nem rendszergazdai jogosultságokkal dolgozhassanak, és csak a portált használó rendszergazdáknak növelhessék jogosultságukat” – mondták a kutatók. “A Microsoft azonban a magas kockázat ellenére nem engedi meg az ügyfélnek, hogy MFA-kihívást kérjen ehhez a tevékenységhez. Ez azt jelenti, hogy még ha engedélyezve van is a PIM, a fiók feltörésekor a támadó rendszergazdává válhat, ha felkeresi a maga a PIM portál (bár ebben az esetben a felhasználó értesítést kap arról, hogy valaki aktiválta ezt a jogosultságot).”
Egy másik probléma, amelyet a Mitiga kiemel, az az, hogy az ügyfelek nem tudják konfigurálni, hogy mikor kerül sor az MFA újrahívására, ha úgy ítélik meg, hogy az alapértelmezett viselkedés nem elég szigorú. A legjobb, amit tehetnek, ha a munkamenet token lejárati idejét a lehető legalacsonyabb értékre állítják, hogy korlátozzák a támadó időtartamát, de ez nem praktikus, mert a támadónak másodpercekbe telik egy ilyen művelet végrehajtása.
Ebben az incidensben a támadók egy dubaji IP-címről használták a munkamenet tokent, egy olyan helyről, ahol az áldozat még soha nem járt, és ahonnan még nem jelentkezett be. Egy ilyen helyváltoztatás a MFA-ban is új kihívást jelent.
“A Microsoft Identity Protection ezek közül néhányat magas kockázatú bejelentkezésként azonosított” – mondták a kutatók. Ha azonban egy szervezet nem képes ellenállni az Identity Protection által generált téves pozitívumok némelyikének, az alapértelmezett viselkedés az MFA-kihívás megkövetelése, amely jelenleg nem hatékony, mivel a támadó már beállította a Hitelesítő alkalmazást.
E-mail szálak feltárása és eltérítése
Miután hozzáfértek a vezető Microsoft 365-fiókjához, a támadók keresni kezdtek az Outlook levelezésében és a SharePoint fájljaiban. Ez lehetővé tette számukra, hogy azonosítsanak egy e-mail-szálat az áldozat cége és egy másik cég közötti közelgő tranzakcióról. A megbeszélés során több embert lemásoltak, köztük a vállalat vezetőit és a szervezetet képviselő ügyvédi iroda ügyvédeit, valamint az alapot irányító külső cég vezetőit és annak ügyvédeit.
A támadók a tranzakcióhoz kapcsolódó fájlokat kerestek, köztük szerződéseket és egyéb pénzügyi adatokat. Ezután hamis domain neveket regisztráltak a sértett cége és ügyvédi irodája számára, majd az egyik ügyvéd nevére e-mailt hoztak létre, amelyben tájékoztatták a harmadik fél céget, hogy az áldozat cége frissítette telefonos utasításait és fiókját. folyamatban lévő ellenőrzési befagyasztás.
A valódihoz hasonló hamis domainekre azért volt szükség, hogy azt a látszatot keltsék, hogy az összes korábbi fél az e-mail szálban maradt, ehelyett hamis e-mail címeket használnak, hogy az új e-mailt használhassák. levél valójában nem érkezett meg. Csak a tranzakciót kezdeményező harmadik fél cég képviselői látták a csaló e-mailt.
Szerencsére az egyik címzettnek gyanús lett az e-mail, így a tranzakció meghiúsult, de sok olyan eset van, amikor az alkalmazottak ilyen gondosan elkészített e-mailekre reagálnak, és pénzt utalnak át a támadók által ellenőrzött számlákra. Az FBI Internet Crime Complaint Center (IC3) szerint a BEC-támadások több mint 43 milliárd dolláros veszteséget okoztak 2016 júniusa és 2021 decembere között.
„Tekintettel az AitM-támadások felgyorsult növekedésére (még a támadó által egy új, kompromittált hitelesítési módszer hozzáadásával lehetővé tett kitartás nélkül is), egyértelmű, hogy többé nem hagyatkozhatunk a többtényezős hitelesítésre, mint fő védelmi vonalunkra az identitástámadásokkal szemben.” nyomatékosan javasoljuk egy másik védelmi szint kialakítását egy harmadik tényező formájában, amely fizikai eszközhöz vagy a munkavállaló engedélyezett laptopjához és telefonjához kötődik. A Microsoft 365 ezt a feltételes hozzáférés részeként biztosítja azáltal, hogy egy regisztrált és csak kompatibilis eszközön keresztüli hitelesítési követelményt ad hozzá, ami teljesen megakadályozza az AitM-támadásokat.”
A Mitiga biztonsági tájékoztatót is adott ki a BEC kampányával kapcsolatban.
Copyright © 2022 IDG Communications, Inc.