Lastpass – lider z kiepską polityką informacyjną

Lastpass jako firma zajmująca się bezpieczeństwem powinna dawać przykład, jak zachowywać się w sytuacjach kryzysowych. Niestety na przykładzie ostatnich zdarzeń, daje ona materiał do negatywnej analizy polityki informacyjnej w zakresie naruszeń…

 

Kilka tygodni temu opublikowano szczegółową analizę tego, jak naruszenie Lastpass wpłynęło na wdrożenie SSO przez Lastpass. Dzisiaj Lastpass po cichu przemycił aktualizację do ich “Zalecanych działań dla administratorów biznesowych Lastpass”, która całkowicie wypiera zarówno informacje, które Lastpass dostarczył klientom, jak i porady z poprzedniego postu. Sprawdźmy, o co chodzi.

 

Background

 

Lastpass udostępnia techniczny dokument wdrożeniowy, który opisuje sposób generowania haseł do skarbca Lastpass (który jest taki sam dla wszystkich integracji SSO)

 

Ukryte hasło główne = base64(SHA256(K1 XOR K2))

 

To równanie definiuje K1 jako sekret całej firmy i K2 jako sekret wygenerowany przez użytkownika. K2 jest przechowywany w Lastpass i pobierany przez API przy użyciu id_tokena podpisanego przez Twojego dostawcę SSO.

 

W ostatniej aktualizacji Lastpass wskazało m.in.:

 

Komponent K2 został eksfiltrowany przez aktora zagrożeń, ponieważ był przechowywany w zaszyfrowanych kopiach zapasowych bazy danych LastPass MFA/Federation Database, do której aktor zagrożeń posiadał klucze deszyfrujące.

 

 

Następnie stara się wycofać to stwierdzenie, mówiąc:

 

Model referencyjny bezpieczeństwa, który zaimplementowaliśmy dla wiedzy dzielonej, został wybrany w celu obrony przed tą specyficzną sytuacją, w której znajomość tylko jednego z komponentów wiedzy dzielonej zdradziłaby cokolwiek na temat klucza.

 

Problem

 

Nie dajmy się zwieść. Sposób, w jaki został skonfigurowany ten “dzielony” klucz, sprawia, że K1 jest nie “tajemnicą”, a bardziej przeszkodą spowalniającą. Dlaczego tak jest? K1 nie zmienia się, jest taki sam dla całej organizacji i jest dostępny dla każdego pracownika, który kiedykolwiek założył/używał Lastpass w danym przedsiębiorstwie.

 

Jak to możliwe? Otóż Lastpass K1 jest (dla większości IDP) ustawiony jako grant Access Token.

 

 

Oznacza to, że każdy użytkownik, który patrzy na swoją konsolę przeglądarki internetowej lub używa proxy, może uzyskać dostęp do K1 poprzez proste dekodowanie base64 JWT Access Token, gdy leci ono przez sieć.

 

 

Oczywiście oznacza to również, że każdy atakujący, który ma K2, może namierzyć każdego indywidualnego użytkownika w firmie z dostępem do Lastpass i wykorzystać jego dostęp do uzyskania K1 dla całej firmy (Bonus: Wiemy już, że naruszenie ujawniło nazwę firmy w skarbcu, w postaci plaintext).

 

Kryptograficznie oznacza to również, że wszystkie hasła główne są połączone. Jeśli atakujący złamie jedno K1 dla organizacji, uzyskuje dostęp do wszystkich skarbców organizacji (auć!).

Cały ten proces potęguje to, że informacje wciąż wypływają, co sprawia, że jest prawie niemożliwe, aby zainteresowane strony mogły na nie odpowiedzieć. Na przykład, nieco ponad miesiąc temu, wsparcie Lastpass wyraźnie wskazało (dla wielu źródeł), że K2 nie zostało dotknięte.

 

Rozwiązanie

 

Sugerowanym rozwiązaniem od Lastpass jest rotacja K1 (oh, to brzmi prosto… prawda?). Aby zrobić to z powodzeniem, musisz de-federować i ponownie sfederować każdego ze swoich użytkowników. Na szczęście, ponowne sfederowanie użytkowników wydaje się rotować K2 użytkowników (niepotwierdzone). W tym momencie o wiele lepszym rozwiązaniem wydaje się być założenie nowego konta. Przynajmniej dostaniemy ładne e-maile onboardingowe.

 

Należy pamiętać, że rotacja haseł nie rozwiąże w pełni problemu zagrożenia K2. Jak wspomniano, dopóki użytkownicy nie zostaną ponownie sfederowani, hasła K1 i K2 pozostaną takie same. Kolejne naruszenie lokalnie lub w Lastpass spowoduje, że wszystkie przyszłe hasła będą zagrożone.

 

Yhy, wszystko jest w porządku, nic się nie dzieje.

 

Jeśli chcesz uniknąć podobnego ryzyka, skontaktuj się z naszymi ekspertami i już dziś zaplanuj działania prewencyjne!