Naruszenie, które zmieniło założenia dotyczące bezpieczeństwa chmury w przedsiębiorstwach
Naruszenie LastPass w 2022 roku nie jest przede wszystkim historią o menedżerach haseł. To historia o tym, co się dzieje, gdy przedsiębiorstwa ufają dostawcom chmury z ich najbardziej wrażliwymi danymi, a to zaufanie zostaje naruszone — nie przez lekkomyślność, ale przez słabości w implementacji, które były niewidoczne z zewnątrz.
LastPass reklamował architekturę zero-knowledge. W praktyce architektura ta nie była zero-knowledge. 25 milionów użytkowników miało swoje zaszyfrowane skarbce wykradzione. Naruszenie zostało po raz pierwszy ujawnione w sierpniu 2022 roku i było aktualizowane wielokrotnie do końca 2022 roku, gdy zakres się rozszerzał.
Dla przedsiębiorstw w sektorze opieki zdrowotnej, finansów i usług prawnych — sektorach, w których ujawnienie danych stwarza odpowiedzialność regulacyjną — naruszenie LastPass nie było odosobnionym incydentem, który można obserwować z daleka. To była zapowiedź systemowego problemu.
Szczegóły implementacji, które miały znaczenie
Analiza po naruszeniu ujawniła dwie krytyczne słabości w implementacji:
Niedobór liczby iteracji: LastPass używał PBKDF2 do derivacji kluczy. Dla nowszych kont używano 100,100 iteracji — poniżej rekomendacji branżowej wynoszącej 600,000. Dla starszych kont (w niektórych przypadkach sprzed 2018 roku) liczba iteracji wynosiła zaledwie 1 iterację. Niższe liczby iteracji sprawiają, że ataki brute-force na zaszyfrowane skarbce stają się obliczeniowo wykonalne. Napastnicy, którzy uzyskali dostęp do skarbców, mogli systematycznie próbować złamać hasła główne.
Ujawnienie metadanych: Chociaż zawartość skarbców była zaszyfrowana, metadane nie były. URL-e przechowywane w menedżerze haseł, nazwy użytkowników i nazwy usług były widoczne w wykradzionych danych. Napastnicy mogli zidentyfikować, z jakimi usługami użytkownicy mieli konta, co umożliwiało ukierunkowane phishing i stuffing poświadczeń, nawet bez łamania szyfrowania skarbca.
Dla zespołów zakupowych oceniających dostawców bezpieczeństwa chmury, przypadek LastPass pokazuje, że dwa pytania muszą być zadawane osobno: "Czy architektura jest zero-knowledge?" oraz "Czy implementacja jest poprawna?"
Naruszenie Okta: Ten sam miesiąc, inny mechanizm
W październiku 2023 roku Okta ujawniła, że aktor zagrożenia użył skradzionego poświadczenia, aby uzyskać dostęp do systemu wsparcia klienta Okta. Naruszenie ujawniło ponad 600,000 rekordów wsparcia klienta, w tym pliki przesłane przez klientów podczas interakcji wsparcia.
Okta to platforma bezpieczeństwa tożsamości. Naruszenie nie było fundamentalną awarią architektury — było to niepowodzenie w kontroli dostępu w łańcuchu dostaw. Poświadczenie inżyniera wsparcia zostało skompromitowane, a napastnik wykorzystał legalny dostęp do wrażliwych danych.
Kombinacja LastPass i Okta ilustruje dwa tryby awarii, z jakimi borykają się dostawcy chmury dla przedsiębiorstw:
- Awaria architektury: roszczenia zero-knowledge nie są rzeczywiście wdrażane
- Awaria kontroli dostępu: legalne poświadczenia prowadzące do nieautoryzowanego dostępu do danych
Architektura zero-knowledge odnosi się do pierwszego trybu awarii. Nie chroni przed zdeterminowanym napastnikiem, który uzyskuje legalne poświadczenia do systemów wsparcia dostawcy. Ale zapewnia, że nawet taki napastnik nie może uzyskać dostępu do danych w postaci niezaszyfrowanej — ponieważ systemy wsparcia dostawcy nigdy nie mają dostępu do danych, które można odszyfrować.
Incydenty bezpieczeństwa SaaS wzrosły o 300% w latach 2022-2024
Badania AppOmni i Cloud Security Alliance śledzące incydenty naruszeń SaaS w latach 2022-2024 wykazały 300% wzrost incydentów bezpieczeństwa wpływających na platformy SaaS w tym okresie.
Liczba 300% nie oznacza 300% wzrostu w zakresie zaawansowania napastników. Oznacza wzrost adopcji SaaS w połączeniu z adaptacją napastników: w miarę jak coraz więcej danych przedsiębiorstw przenosi się na platformy chmurowe, napastnicy przesuwają zasoby, aby celować w te platformy. ROI z kompromitacji dostawcy SaaS — uzyskanie dostępu do danych od dziesiątek lub setek klientów przedsiębiorstw jednocześnie — jest znacznie wyższe niż celowanie w pojedyncze przedsiębiorstwa.
Dla przedsiębiorstw, które zbudowały swoje procesy oceny bezpieczeństwa dostawców wokół założenia, że dostawcy chmury są bezpiecznymi celami, dane z lat 2022-2024 wymagają przestrojenia. To założenie jest błędne. Dostawcy SaaS są priorytetowymi celami.
Lista kontrolna audytu po LastPass
Dla przedsiębiorstw ponownie oceniających bezpieczeństwo dostawców chmury po incydentach LastPass i Okta, praktyczna lista kontrolna:
Implementacja szyfrowania:
- Poproś o algorytm derivacji kluczy, liczbę iteracji i parametry pamięci
- Potwierdź, że liczby iteracji spełniają aktualne rekomendacje OWASP (minimum 600,000 PBKDF2-SHA256 lub równoważne parametry Argon2id)
- Zweryfikuj, że derivacja kluczy odbywa się po stronie klienta, a nie na serwerach dostawcy
Ochrona metadanych:
- Zapytaj konkretnie, jakie metadane są przechowywane w postaci niezaszyfrowanej obok zaszyfrowanej zawartości
- Poproś o model danych pokazujący, które pola są zaszyfrowane, a które są dostępne w scenariuszach naruszenia
Kontrola dostępu do systemu wsparcia:
- Poproś o dokumentację dotyczącą dostępu inżyniera wsparcia do danych klientów
- Potwierdź, że systemy wsparcia nie mogą uzyskać dostępu do danych klientów w postaci niezaszyfrowanej
Historia powiadomień o naruszeniach:
- Poproś o ujawnienie wszystkich wcześniejszych incydentów bezpieczeństwa, w tym tych, które nie osiągnęły progów publicznego ujawnienia
- Oceń przejrzystość i kompletność wcześniejszych ujawnień
Naruszenie LastPass było częściowo niepowodzeniem w implementacji, a częściowo niepowodzeniem w przejrzystości dotyczącej implementacji. Przedsiębiorstwa, które zadają szczegółowe pytania przed wyborem dostawcy, otrzymują odpowiedzi, które pozwalają na świadomą ocenę ryzyka. Przedsiębiorstwa, które akceptują ogólne roszczenia — "szyfrujemy twoje dane" — dziedziczą ryzyko odkrycia szczegółów implementacji po naruszeniu.
Źródła: