Az egyik legnagyobb felhőszolgáltatótól loptak el adatokat
Az elmúlt hónap során egy hackerbanda, amely valószínűleg a ShinyHunters vagy a Scattered Spider nevű csoporthoz köthető, több mint 560 millió ügyfélrekordot lopott el a Ticketmastertől, és május 28-án 500 000 dollárt kérve eladásra bocsátotta azt a BreachForums hackeroldalon,. Két nappal később a csoport azt állította, hogy 30 millió számlaadatot lopott el a spanyolországi Santander Banktól is, és 2 millió dollárt kértek érte. A bejegyzéseket követően mindkét vállalat elismerte a támadásokat.
Az adatszivárgások – és legalább 163 másik hackertámadás – oka a Googlehoz tartozó Mandiant IT biztonsági cég június 10-i elemzése szerint nem egy sebezhetőség, hanem az ellopott hitelesítő adatok használata és a többfaktoros hitelesítés (MFA) rossz ellenőrzése volt.
“A Mandiant vizsgálata nem talált olyan bizonyítékot, amely arra utalna, hogy a Snowflake ügyfélfiókjaihoz való jogosulatlan hozzáférés a Snowflake vállalati környezetének megsértéséből eredt volna.” – áll a Mandiant elemzésében. “Ehelyett a Mandiant szerint az incidens a kompromittált ügyfélhitelesítési adatokra vezethető vissza.”
Bár a Snowflake rendszereiből történő adatlopás megelőzhető lett volna MFA-val, a vállalatok hibái túlmutatnak ennek az egyetlen ellenőrzésnek a hiányán. A felhőszolgáltatásokat használó vállalkozásoknak gondoskodniuk kell arról, hogy a támadási felületeikre rálátásuk legyen. Gyorsan eltávolítsák a korábbi alkalmazottak és partnereik fiókjait, és csökkentsék azokat az utakat, amelyeken keresztül az opportunista támadók veszélyeztethetik a rendszereket, hálózatokat vagy szolgáltatásokatm – magyarázta Chris Morgan, a ReliaQuest felhőalapú biztonsági platformszolgáltató vezető kiberfenyegetettségi elemzője.
“A legnagyobb tanulság az, hogy a fenyegető szereplőknek nem kell kifinomult technikákat alkalmazniuk.” – mondja. “Jelen esetben a bizonytalan hitelesítő adatok megcélzása a fenyegető szereplő részéről kevés erőfeszítéssel elérhető, de bőséges lehetőségeket kínál.”
Íme öt tanulság a legutóbbi felhőalapú támadásokból.
1. Kezdj az MFA-val, aztán menj tovább
Az MFA adoptációjában még sok növekedési lehetőség van. Míg egy 1 évvel ezelőtt kiadott jelentés szerint a munkavállalók 64%-a és a rendszergazdák 90%-a használja az MFA-t, addig az Orca Security “2024 State of Cloud report” című jelentése szerint 10 szervezetből több mint hatnál legalább egy root felhasználó vagy rendszergazda nem engedélyezte az MFA-t egy fiókban.
A vállalkozásoknak következetes – és ellenőrizhető – 100%-ra kell eljutniuk, mondja Ofer Maor, a Mitiga felhőbiztonsági cég társalapítója és technológiai igazgatója.
A vállalatoknak “gondoskodniuk kell arról, hogy az MFA-t kikényszerítsék és megköveteljék. Ha pedig Single Sign On-t (SSO) használnak, gondoskodjanak arról, hogy a nem-SSO bejelentkezés le legyen tiltva.” – mondja. “Lépjenek túl a hagyományos MFA-n [és] kapcsoljanak be további biztonsági intézkedéseket, például eszköz- [vagy] hardveralapú hitelesítést az érzékeny infrastruktúrák esetében”.
2. Hozzáférés-vezérlési listák használata az engedélyezett IP-címek korlátozására
A szervezeteknek hozzáférési vezérlési listákat (ACL – access control list) is be kell vezetniük, amelyek korlátozzák, hogy a felhasználók hol férhetnek hozzá egy felhőszolgáltatáshoz, vagy legalábbis lehetővé teszik a hozzáférési naplók napi rendszerességgel történő felülvizsgálatát, hogy kiszűrjék az esetleges anomáliákat.
Ez tovább korlátozza a kibertámadók képességeit – mondja Jake Williams, az IANS Research elemzőcég kari elemzője és kiberbiztonsági szakembere.
“Valójában szinte bármilyen felhőinfrastruktúra esetében a legjobb gyakorlat az, hogy korlátozzuk, milyen IP-címekről érkezhetnek a felhasználók.” – mondja. “Ha ez nem lehetséges, akkor a hozzáférés felülvizsgálata még fontosabb, hogy megbizonyosodjunk arról, hogy az emberek nem olyan helyről érkeznek, ahonnan nem számítunk rá.”
3. A felhőszolgáltatások átláthatóságának maximalizálása
A vállalatoknak az alkalmazások folyamatos nyomon követésére is értelmes módon fel kell készülniük . A naplóadatokat, a hozzáférési tevékenységeket és az adatforrásokat teljes képpé összesítő szolgáltatások segíthetnek a vállalatoknak a Snowflake-hez hasonló támadások felderítésében és megelőzésében.
Emellett a szervezeteknek képesnek kell lenniük arra, hogy riasztást adjanak ki a konkrét viselkedés vagy fenyegetés észlelése esetén.
“Bár a biztonsági műveleti csapatok szétszóródnak, és általában nincs lehetőségük arra, hogy mély szakértelmet alakítsanak ki a vállalatuk által használt különböző alkalmazásokban, az eszközeiknek és a biztonsági platformjaiknak gyorsan fel kellett volna ismerniük ezeket a problémákat.” – mondja. “Ebben a forgatókönyvben minden bizonnyal voltak szokatlan helyekről érkező rendellenes bejelentkezések, valamint erősen megkérdőjelezhető támadó alkalmazások kapcsolódása az ügyfelek Snowflake példányaihoz.”
4. Ne hagyatkozz a felhőszolgáltatók alapértelmezett beállításaira
Bár a felhőszolgáltatók szeretik hangsúlyozni, hogy a biztonság egy megosztott felelősségi modell, hacsak egy támadó nem tör be a felhőszolgáltató infrastruktúrájába vagy szoftverébe – mint például a Progress Software MoveIT Cloud szolgáltatásában és MoveIT Transfer szoftverében tavaly felfedezett sebezhetőségek esetében -, a felelősség szinte mindig az ügyfélre hárul.
A felhőszolgáltatók azonban gyakran a használhatóságot helyezik előtérbe a biztonsággal szemben. Ezért a vállalatoknak nem szabad a szolgáltatóik alapértelmezett biztonsági beállításaira hagyatkozniuk. A Snowflake például sok mindent megtehetett volna az MFA kezelésének megkönnyítése érdekében, többek között a biztonsági ellenőrzés alapértelmezett bekapcsolását. – mondja Maor Mitiga.
“Ami lehetővé teszi, hogy ez a támadás sikeres legyen, méghozzá ilyen léptékben, az az, hogy a Snowflake-fiókok alapértelmezett beállítása nem követeli meg az MFA-t. Ez azt jelenti, hogy ha valaki egyszer megszerzi a kompromittált felhasználónevet és jelszót, azonnal teljes hozzáférést kaphat.” – magyarázza Mitiga. “Normális esetben a nagy érzékenységű platformok megkövetelnék a felhasználóktól az MFA engedélyezését. A Snowflake nem csak, hogy nem követeli meg az MFA-t, de nagyon megnehezíti a rendszergazdák számára ennek kikényszerítését.”
5. Ellenőrizd a harmadik feles partnereket
Végezetül a vállalatoknak azt is figyelembe kell venniük, hogy – még ha nem is használják a Snowflake-et vagy más felhőszolgáltatást – egy harmadik fél szolgáltató is használhatja a szolgáltatást a backend rendszeréhez, ami kockázatnak teszi ki az adataikat. – figyelmeztet Williams, az IANS Research munkatársa.
“Az adatij a Snowflake-ben lehetnek, még akkor is, ha nem használja a szolgáltatását.” – mondja. “Ez a mai ellátási láncok bonyolultsága… Ön átadja az adatait egy harmadik feles szolgáltatónak, aki aztán beteszi azokat a Snowflake-be. Ez a cég pedig lehet, hogy a legjobb gyakorlatokat használja, de az is lehet, hogy nem.”
Williams szerint a szervezeteknek meg kell keresniük az összes olyan szolgáltatót, aki hozzáfér az adataikhoz, és meg kell győződniük arról, hogy megteszik a megfelelő lépéseket az adatok védelme érdekében.