Az incidens, amely megváltoztatta a felhőbiztonságot
2026-ra frissítve
A 2022-es LastPass-adatvédelmi incidens nem elsősorban a jelszókezelőkről szól. A bizalomról szól. Az irodák felhőszolgáltatóra bízták adataikat. Ez a bizalom megtört. Az ok rejtett hibák voltak, nem gondatlanság.
A LastPass zéró-tudás tervezést értékesített. A gyakorlatban ez nem volt zéró-tudás. 25 millió felhasználó titkosított tárcáját lopták el. A támadást először 2022 augusztusában hozták nyilvánosságra. A LastPass többször felülvizsgálta tájékoztatásait. A teljes mértéke 2022 végére derült ki.
Az egészségügyi, pénzügyi és jogi területen tevékenykedő irodák számára ez nem volt egy távoli hírtörténet. Ezek a szektorok valós felelősséggel szembesülnek, ha adatok szivárognak ki. A LastPass-eset egy szélesebb körű probléma korai jele volt.
Két hiba, amely lehetővé tette a támadást
Az incidens utáni elemzés két kulcsfontosságú gyengeséget tárt fel.
Gyenge kulcsbeállítás. A LastPass PBKDF2-t alkalmazott a kulcslevezetéshez. Az újabb fiókok 100 100 iterációt kaptak. Az OWASP 600 000-t ajánl. Néhány régi fióknak mindössze 1 iterációja volt. Kevesebb iteráció gyorssá és olcsóvá teszi a brute-force támadásokat. A tárcafájlokkal rendelkező támadók nagy sebességgel tesztelhették a mesterjelszavakat.
Tiszta szöveges metaadatok. A tárca tartalma titkosítva volt. A metaadatok viszont nem. Az URL-ek, felhasználónevek és szolgáltatásnevek mind láthatók voltak az ellopott adatokban. A támadók láthatták, melyik felhasználónak milyen szolgáltatásoknál volt fiókja. Ez célzott adathalászatot és hitelesítő adatok kitömését tette lehetővé. Nem volt szükség a tárca feltörésére.
Ez az eset megmutatja, miért kell két kérdést külön-külön feltenni. „A tervezés zéró-tudás?” ez az egyik kérdés. „A megvalósítás helyes?” ez egy másik kérdés.
Okta 2023-ban: eltérő támadás, ugyanolyan eredmény
2023 októberében az Okta biztonsági incidenst jelentett be. Egy ellopott hitelesítő adat hozzáférést biztosított egy támadónak az ügyfél-támogatási rendszeréhez. A támadás több mint 600 000 támogatási nyilvántartást tett kitéve. Ezek magukban foglaltak a felhasználók által a támogatási munkamenetek során feltöltött fájlokat.
Az Okta egy identitásbiztonsági platform. A probléma nem tervezési hiba volt. Hozzáférés-vezérlési hiba volt. Egy támogatási mérnök bejelentkezési adatait ellopták. A támadó ezeket felhasználta érzékeny adatok eléréséhez.
A LastPass és az Okta megmutatja a szolgáltatói kompromittálódás két fő útját:
- Tervezési hibák – zéró-tudás állítások, amelyek nem valósultak meg helyesen
- Hozzáférés-vezérlési hibák – érvényes hitelesítő adatok felhasználása olyan adatok eléréséhez, amelyeket nem kellene elérniük
A zéró-tudás tervezés megakadályozza az első típust. Nem állít meg egy érvényes támogatási hitelesítő adatokkal rendelkező támadót. De megakadályozza, hogy az ügyfél adatait olvassa el. A szolgáltató soha nem tárol visszafejthető tartalmat. Lásd a biztonsági és megfelelőségi áttekintőnket, hogy ez hogyan vonatkozik a személyes adatok kezelésére szolgáló eszközökre.
A SaaS-biztonsági események 300%-kal nőttek két év alatt
Az Obsidian Security 300%-os növekedést talált a SaaS-platform biztonsági eseményeiben 2022 és 2024 között.
Ez nem a támadói készségek 300%-os növekedése. Két erő hajtotta ezt. A SaaS-használat gyorsan nőtt. A támadók követték az adatokat. Egyetlen szolgáltatói kompromittálódás egyszerre teheti kitéve tucatnyi ügyfél adatait. Ez a kifizetés kedvez a szolgáltatókat célzó támadásoknak az egyes cégek elleni támadásokkal szemben.
Azoknak a vállalatoknak, amelyek úgy gondolták, hogy a felhőplatformok biztonságosak, frissíteniük kell ezt az álláspontot. A SaaS-szolgáltatók ma már elsődleges célpontok.
Kérdések, amelyeket bármely felhőszolgáltatónak fel kell tenni
A vásárlási és biztonsági csapatok számára ez az ellenőrzőlista fedi le az alapvető területeket.
Titkosítási beállítás:
- Kérje a kulcslevezetési algoritmust, iterációszámot és memóriabeállításokat.
- Erősítse meg, hogy az iterációszámok megfelelnek az OWASP minimumoknak. Ez 600 000 PBKDF2-SHA256 vagy azzal egyenértékű Argon2id.
- Ellenőrizze, hogy a kulcslevezetés az Ön eszközén történik-e, nem a szolgáltató szerverein.
Metaadat-kitettség:
- Kérdezze meg, milyen metaadatokat tárolnak tiszta szöveges formában a titkosított tartalom mellett.
- Kérjen adatmodellt. Meg kell mutatnia, mely mezők titkosítottak és melyek láthatók egy támadás esetén.
Támogatási hozzáférés:
- Kérdezze meg, hogy a támogatási munkatársak hozzáférhetnek-e az ügyféladatokhoz.
- Erősítse meg, hogy a támogatási rendszerek nem érhetik el az ügyféli tiszta szöveget.
Incidenstörténet:
- Kérjen tájékoztatást minden korábbi biztonsági eseményről, beleértve a nyilvános közzételi küszöbök alatti eseményeket is.
- Értékelje, mennyire teljes és őszinte volt a korábbi tájékoztatás.
A LastPass-incidens megvalósítási hiba és bizalomhiba volt. A konkrét válaszokat adó szolgáltatók lehetővé teszik a valódi kockázatelemzést. A homályos állításokat adó szolgáltatók rejtve hagyják a kockázatot. Ez a kockázat gyakran csak egy támadás után kerül felszínre. A szolgáltató kiértékelési útmutatásért lásd a megfelelőségi áttekintőnket.
Az anonym.legal a bejelentkezésre alkalmazza a zéró-tudás elvét: a kulcslevezetés Argon2id segítségével a böngészőjében vagy asztali alkalmazásában történik, így a jelszava soha nem hagyja el az eszközét. Az anonimizálásra küldött szöveget az EU-ban üzemeltetett API-nk dolgozza fel (Hetzner, Falkenstein). A szerverek a mentett titkosítási kulcsokat titkosítva tárolják, de ezek nem zéró-tudás módszerűek. Tudjon meg többet.