Skarbiec wytrzymał. To nigdy nie była droga wejścia.

LastPass w tym miesiącu znów został złamany. To, na co wszyscy się szykowali, nie nastąpiło. Żaden skarbiec nie został złamany. Żadne hasło główne nie wyciekło. Zaszyfrowane sekrety pozostały nietknięte. LastPass potwierdził, że jego „produkty, usługi i infrastruktura nie zostały naruszone", a skarbce klientów „pozostały bezpieczne". [1]

Atakujący nawet nie zbliżyli się do skarbca. Weszli przez dostawcę.

Oto łańcuch, bo sedno sprawy leży w mechanizmie. 11 czerwca grupa podająca się za Icarus dostała się do Klue — platformy analityki rynkowej, z której @LastPass korzystał wewnętrznie. Ich droga wejścia, według @HuntressLabs, którzy obsługiwali incydent: „dawno uśpione poświadczenie API, pierwotnie utworzone dla porzuconego prototypu integracji z zewnętrznym dostawcą". [2] Klucz stworzony dla projektu, który już nie istniał, w celu, którego nikt nie pamiętał — wciąż aktywny. Z wnętrza Klue wypchnęli złośliwy kod, który przechwytywał tokeny OAuth przechowywane przez Klue dla jego klientów: stałe zgody pozwalające mu odczytywać @salesforce, Slack, HubSpot i inne w imieniu tych firm. Jeden z tych tokenów należał do LastPass. Z jego pomocą atakujący odczytali CRM Salesforce LastPass. Imiona, adresy e-mail, numery telefonów, adresy, treści zgłoszeń do pomocy technicznej. Potem żądanie okupu. Zapłaćcie, albo trafi na stronę z wyciekami.

LastPass nie był jedynym w polu rażenia. Huntress, Recorded Future, Tanium, Jamf, BeyondTrust. Firmy z branży bezpieczeństwa, w większości. Takie, które zajmują się tym zawodowo.

Trzeba więc oddać, co się należy. Kryptografia LastPass zrobiła dokładnie to, co obiecywała. Skarbiec nie jest tu sednem sprawy. Sednem jest klasa sekretów, którą niemal nikt za sekret nie uważa: długowieczny token tkwiący w integracji SaaS, którą Pan/Pani zatwierdził(a) kiedyś raz i nigdy później nie sprawdził(a). Nie wygasa. Nie wie, że został skradziony. Daje dostęp znacznie szerszy niż powód, dla którego powstał, i nadal go daje — po cichu — dopóki człowiek nie przypomni sobie, żeby go wyłączyć. Zwykle żaden człowiek tego nie robi.

To jest ta zmiana. Model zagrożeń przesunął się od pytania „czy zdołają złamać skarbiec" do pytania „ile zapomnianych kluczy stoi w drzwiach, których przestał Pan pilnować". Martwe poświadczenie z porzuconego prototypu wystarczyło, by dotrzeć do danych klientów szeregu firm. Matematyka nigdy nie była słabym punktem. Słabym punktem był rozrost.

To dokładnie ta awaria, przed którą poświadczenie powinno być zbudowane tak, by odmawiać. Sekret wydawany przez Clavitor jest krótkowieczny i ma ograniczony zakres. Jest pośredniczony na jedną operację, wygasa samodzielnie i jest związany oraz przypisany do maszyny, która go użyła. Taki token nie może stać się tym, co tu wyrządziło szkody: zapomnianą zgodą, przechwyconą długo po tym, jak ktokolwiek pamiętał, że istnieje, odtworzoną z infrastruktury obcego podmiotu bez niczego, co wiązałoby ją z aktorem. Znika, zanim uda się go znaleźć, i nigdy nie wykraczał poza swoje jedno zadanie.

Warto jasno powiedzieć o ograniczeniu. Clavitor zarządza poświadczeniami, które sam posiada, nie stałą zgodą OAuth, którą przekazał Pan platformie dostawcy. Ten token żyje w ich systemie, pod ich kontrolami, i żaden skarbiec nie sięga tam, by go dla Pana unieważnić. Zmienia się wszystko to, co leży w zakresie Clavitor. Odmawia on bycia miejscem, w którym sekret bez terminu ważności może po cichu spocząć. Dyscyplina, której brak otworzył drogę do Klue (krótkie życie, wąski zakres, prawdziwe przypisanie), jest tu ustawieniem domyślnym, nie opcją, o której ktoś powinien był pamiętać.

Pozostaje pytanie, które nie jest wygodne. Ile aktywnych tokenów spoczywa u dostawców, których Pan/Pani wdrożył(a) rok temu i od tamtej pory o nich nie myślał(a)?

Opisaliśmy kilka właściwości, które poświadczenie powinno posiadać, zanim powierzy je Pan/Pani czemukolwiek. [3]

Clavitor (@clavitorai) to skarbiec poświadczeń zbudowany dla agentów AI — i przeciwko nim. clavitor.ai

Źródła

[1] BleepingComputer, „LastPass potwierdza wyciek danych w ataku na łańcuch dostaw Klue" — @BleepinComputer

[2] Wyniki dochodzenia Huntress, opisane w Help Net Security, „Naruszenie Klue prowadzi do kradzieży danych z Salesforce, również Huntress dotknięty" — @HuntressLabs, @helpnetsecurity

[3] Dziesięć zasad zarządzania poświadczeniami (artykuł natywny w serwisie X) — @clavitorai