Сховище витримало. Шлях усередину був зовсім не той.

Цього місяця 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 confirms data breach in Klue supply chain attack" — @BleepinComputer

[2] Huntress incident findings, reported via Help Net Security, "Klue breach lead to Salesforce data theft, Huntress affected" — @HuntressLabs, @helpnetsecurity

[3] The Ten Rules of Credential Management (стаття в X) — @clavitorai