Хранилище устояло. Но вход был не через него.
LastPass снова взломали, и хранилище устояло. Вход оказался через мёртвый OAuth-токен от заброшенной интеграции — тот класс секретов, который почти никто не считает секретами.
В этом месяце LastPass снова взломали. То, к чему все готовятся, не произошло. Ни одно хранилище не было вскрыто. Ни один мастер-пароль не скомпрометирован. Зашифрованные секреты остались нетронутыми. LastPass подтвердил, что «продукты, сервисы и инфраструктура не пострадали», а клиентские хранилища «остались в безопасности». [1]
Злоумышленники даже не подходили к хранилищу. Они вошли через поставщика.
Приведём цепочку, потому что суть — именно в механизме. 11 июня группа, называющая себя Icarus, проникла в Klue — платформу рыночной аналитики, которую @LastPass использовал внутри компании. Способ проникновения, по данным @HuntressLabs, работавших с инцидентом: «давно не использовавшиеся учётные данные API, изначально созданные для заброшенного прототипа сторонней интеграции». [2] Ключ, созданный для проекта, который больше не существовал, для цели, которую никто не помнил, всё ещё был активен. Изнутри Klue они внедрили вредоносный код, собиравший OAuth-токены, которые Klue хранил для своих клиентов: постоянные разрешения, позволяющие читать @salesforce, Slack, HubSpot и другие системы от имени этих компаний. Один из этих токенов принадлежал LastPass. С его помощью злоумышленники прочитали Salesforce CRM LastPass. Имена, адреса электронной почты, номера телефонов, адреса, содержимое обращений в поддержку. Затем — записка с вымогательством. Платите, или всё окажется на сайте с утечками.
Пострадали не только в LastPass. Huntress, Recorded Future, Tanium, Jamf, BeyondTrust. В основном компании из сферы безопасности. Те, кто зарабатывает этим на жизнь.
Отдадим должное: криптография LastPass сделала именно то, что обещала. Хранилище — не суть происходящего. Суть — в классе секретов, который почти никто не считает секретом: долгоживущий токен внутри SaaS-интеграции, которую вы однажды согласовали и больше не открывали. Он не истекает. Он не знает, что его украли. Он даёт доступ куда шире, чем требовалось при создании, и продолжает давать его — тихо, — пока кто-нибудь из людей не вспомнит, что его надо отозвать. Обычно никто не вспоминает.
В этом и сдвиг. Модель угроз сместилась с «смогут ли они вскрыть хранилище» на «сколько забытых ключей подпирает двери, за которыми Вы перестали следить». Мёртвые учётные данные из заброшенного прототипа хватило, чтобы добраться до клиентских данных целого ряда компаний. Слабым звеном никогда не была математика. Слабым звеном был разрастание.
Именно от такого сбоя должна быть устроена защита учётных данных. Секрет, который выдаёт Clavitor, краткоживущий и ограниченный по области действия. Он брокеруется для одной операции, истекает сам и привязан к машине, которая его использовала, с фиксацией источника. Такой токен не может стать тем, что нанесло ущерб в этом случае: забытым разрешением, собранным спустя долгое время после того, как кто-либо помнил о его существовании, и воспроизведённым с чужой инфраструктуры без какой-либо привязки к исполнителю. Он исчезает прежде, чем его успевают обнаружить, и никогда не выходит за пределы своей единственной задачи.
Есть ограничение, которое стоит оговорить прямо. Clavitor управляет учётными данными, которые он хранит, а не постоянным OAuth-разрешением, которое Вы передали платформе поставщика. Этот токен живёт в их системе, под их контролем, и никакое хранилище не может дотянуться до него, чтобы отозвать его за Вас. Меняется всё, что находится в зоне ответственности Clavitor. Он отказывается быть местом, где может тихо лежать секрет без срока действия. Дисциплина, отсутствие которой открыло доступ в Klue (короткий срок жизни, узкая область действия, реальная фиксация источника), здесь поведение по умолчанию, а не настройка, о которой кто-то должен был помнить.
Вопрос, который остаётся, неудобный. Сколько активных токенов лежит у поставщиков, которых Вы подключили год назад и с тех пор не вспоминали?
Мы описали несколько свойств, которыми должны обладать учётные данные, прежде чем им стоит доверять что-либо. [3]
Clavitor (@clavitorai) — хранилище учётных данных, созданное для ИИ-агентов и против них. clavitor.ai
Источники
[1] BleepingComputer, «LastPass подтверждает утечку данных в результате атаки на цепочку поставок Klue» — @BleepinComputer
[2] Результаты расследования Huntress, опубликованные через Help Net Security, «Взлом Klue привёл к краже данных из Salesforce, пострадал Huntress» — @HuntressLabs, @helpnetsecurity
[3] Десять правил управления учётными данными (статья в X) — @clavitorai