Злом, що змінив припущення корпоративної хмарної безпеки
Злом LastPass 2022 року — це не насамперед історія про менеджери паролів. Це історія про те, що відбувається, коли підприємства довіряють хмарним постачальникам свої найбільш конфіденційні дані, а цей довір порушується — не через необережність, а через недоліки реалізації, що були невидимі ззовні.
LastPass позиціонував ZK-архітектуру. На практиці архітектура не була ZK. 25 млн користувачів мали свої зашифровані сховища викрадені. Злом вперше розкрито у серпні 2022 року і неодноразово оновлювався протягом пізнього 2022 року в міру розширення масштабів.
Для підприємств у сфері охорони здоров'я, фінансів і юридичних послуг — галузях, де розкриття даних тягне регуляторну відповідальність — злом LastPass був не ізольованим інцидентом, що можна спостерігати здалеку. Це було попередженням про системну проблему.
Деталі реалізації, що мали значення
Аналіз після злому виявив два критичних недоліки реалізації:
Недостатня кількість ітерацій: LastPass використовував PBKDF2 для деривації ключа. Для новіших облікових записів використовувалося 100 100 ітерацій — нижче галузевої рекомендації у 600 000. Для старіших облікових записів (у деяких випадках до 2018 року) кількість ітерацій становила лише 1. Менша кількість ітерацій робить атаки методом повного перебору на зашифровані сховища обчислювально здійсненними. Зловмисники, що отримали сховища, могли систематично намагатися зламати головні паролі.
Розкриття метаданих: Хоча вміст сховища був зашифрований, метадані — ні. URL-адреси, збережені в менеджері паролів, імена користувачів та назви сервісів були видимі у викрадених даних. Зловмисники могли визначити, яким сервісам користувачі мали облікові записи, що дозволяло цілеспрямований фішинг і підстановку облікових даних навіть без зламу шифрування сховища.
Для команд закупівель, що оцінюють постачальників хмарної безпеки, справа LastPass демонструє, що на два питання необхідно відповідати окремо: «Чи є архітектура ZK?» і «Чи правильна реалізація?»
Злом Okta: той самий місяць, інший механізм
У жовтні 2023 року Okta повідомив, що зловмисник використав викрадені облікові дані для отримання доступу до системи підтримки клієнтів Okta. Злом розкрив понад 600 000 записів підтримки клієнтів, включаючи файли, завантажені клієнтами під час взаємодії з підтримкою.
Okta — платформа ідентифікації безпеки. Злом не був фундаментальним архітектурним збоєм — це був збій контролю доступу в ланцюгу постачання. Облікові дані інженера підтримки були скомпрометовані, і зловмисник використав законний доступ для досягнення конфіденційних даних.
Поєднання LastPass та Okta ілюструє два режими невдачі, з якими стикаються корпоративні хмарні постачальники:
- Архітектурні збої: ZK-заяви, що справді не реалізовані
- Збої контролю доступу: законні облікові дані, що ведуть до несанкціонованого доступу до даних
ZK-архітектура усуває перший режим невдачі. Вона не захищає від рішучого зловмисника, що отримує законні облікові дані для систем підтримки постачальника. Але вона гарантує, що навіть такий зловмисник не може отримати доступ до відкритого тексту клієнтів — оскільки системи підтримки постачальника ніколи не мають доступу до даних, що піддаються дешифруванню.
Інциденти безпеки SaaS зросли на 300% з 2022 по 2024 рік
Дослідження AppOmni та Cloud Security Alliance щодо відстеження інцидентів зломів SaaS з 2022 по 2024 рік виявило зростання на 300% інцидентів безпеки, що вплинули на SaaS-платформи протягом цього періоду.
Цифра 300% не відображає зростання витонченості зловмисників на 300%. Вона відображає зростання впровадження SaaS у поєднанні з адаптацією зловмисників: оскільки все більше корпоративних даних переміщувалося на хмарні платформи, зловмисники перерозподіляли ресурси для атак на ці платформи. ROI від компрометації SaaS-постачальника — отримання доступу до даних від десятків або сотень корпоративних клієнтів одночасно — суттєво вищий, ніж атака на окремі підприємства.
Для підприємств, що будували процеси оцінки безпеки постачальників на підставі припущення, що хмарні постачальники є безпечними цілями, дані 2022–2024 рр. вимагають перекалібрування. Припущення хибне. SaaS-постачальники є першочерговими цілями.
Чеклист аудиту після LastPass
Для підприємств, що переоцінюють безпеку хмарних постачальників після інцидентів LastPass та Okta, практичний чеклист:
Реалізація шифрування:
- Запросіть алгоритм деривації ключа, кількість ітерацій і параметри пам'яті
- Підтвердіть, що кількість ітерацій відповідає поточним рекомендаціям OWASP (мінімум 600 000 PBKDF2-SHA256 або еквівалентні параметри Argon2id)
- Перевірте, чи деривація ключа відбувається на стороні клієнта, а не на серверах постачальника
Захист метаданих:
- Конкретно запитайте, які метадані зберігаються у відкритому тексті поряд із зашифрованим вмістом
- Запросіть модель даних, що показує, які поля зашифровані, а які доступні у сценаріях злому
Засоби контролю доступу системи підтримки:
- Запросіть документацію щодо доступу інженерів підтримки до даних клієнтів
- Підтвердіть, що системи підтримки не мають доступу до відкритого тексту даних клієнтів
Історія повідомлень про зломи:
- Запросіть розкриття всіх попередніх інцидентів безпеки, включаючи ті, що не досягли порогів публічного розкриття
- Оцініть прозорість і повноту попередніх розкриттів
Злом LastPass був частково невдачею реалізації і частково невдачею прозорості щодо реалізації. Підприємства, що задають детальні питання перед вибором постачальника, отримують відповіді, що дозволяють обґрунтовану оцінку ризику. Підприємства, що приймають заяви загального характеру — «ми шифруємо ваші дані» — успадковують ризик виявлення деталей реалізації після злому.
Джерела: