Утечка, изменившая предположения о безопасности облаков предприятий
Утечка LastPass 2022 года — это не просто история о менеджерах паролей. Это история о том, что происходит, когда предприятия доверяют облачным поставщикам свои самые чувствительные данные, и это доверие нарушается — не по неосторожности, а из-за слабостей в реализации, которые были невидимы снаружи.
LastPass рекламировал архитектуру с нулевым знанием. Эта архитектура на практике не была нулевым знанием. 25 миллионов пользователей потеряли свои зашифрованные сейфы. Утечка была впервые раскрыта в августе 2022 года и обновлялась несколько раз до конца 2022 года по мере расширения объема.
Для предприятий в здравоохранении, финансах и юридических услугах — секторах, где утечка данных создает регуляторную ответственность — утечка LastPass не была изолированным инцидентом, за которым можно было наблюдать издалека. Это был предварительный просмотр системной проблемы.
Важные детали реализации
Анализ после утечки выявил две критические слабости в реализации:
Недостаток количества итераций: LastPass использовал PBKDF2 для производных ключей. Для новых аккаунтов они использовали 100,100 итераций — ниже рекомендованных в отрасли 600,000. Для старых аккаунтов (в некоторых случаях до 2018 года) количество итераций было всего 1 итерация. Меньшее количество итераций делает атаки методом грубой силы на зашифрованные сейфы вычислительно осуществимыми. Нападающие, получившие доступ к сейфам, могли систематически пытаться взломать мастер-пароли.
Экспозиция метаданных: Хотя содержимое сейфов было зашифровано, метаданные — нет. URL-адреса, хранящиеся в менеджере паролей, имена пользователей и названия сервисов были видны в эксфильтрованных данных. Нападающие могли определить, с какими сервисами у пользователей есть аккаунты, что позволяло целенаправленное фишинг и заполнение учетных данных даже без взлома шифрования сейфа.
Для команд закупок, оценивающих облачных поставщиков безопасности, случай LastPass демонстрирует, что на два вопроса необходимо ответить отдельно: "Архитектура с нулевым знанием?" и "Правильная ли реализация?"
Утечка Okta: тот же месяц, другой механизм
В октябре 2023 года Okta раскрыла, что злоумышленник использовал украденные учетные данные для доступа к системе поддержки клиентов Okta. Утечка раскрыла 600,000+ записей поддержки клиентов, включая файлы, загруженные клиентами во время взаимодействия с поддержкой.
Okta — это платформа безопасности идентификации. Утечка не была фундаментальным провалом архитектуры — это был провал контроля доступа в цепочке поставок. Учетные данные инженера поддержки были скомпрометированы, и злоумышленник использовал легитимный доступ для получения чувствительных данных.
Сочетание LastPass и Okta иллюстрирует два режима отказа, с которыми сталкиваются облачные поставщики для предприятий:
- Провалы архитектуры: заявления о нулевом знании, которые не были действительно реализованы
- Провалы контроля доступа: легитимные учетные данные, приводящие к несанкционированному доступу к данным
Архитектура с нулевым знанием решает первую проблему отказа. Она не защищает от целеустремленного злоумышленника, который получает легитимные учетные данные для систем поддержки поставщиков. Но она гарантирует, что даже такой злоумышленник не может получить доступ к открытым данным клиентов — потому что системы поддержки поставщика никогда не имеют доступа к расшифровываемым данным.
Инциденты безопасности 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 была отчасти провалом реализации и отчасти провалом прозрачности в отношении реализации. Предприятия, которые задают детализированные вопросы перед выбором поставщика, получают ответы, позволяющие провести обоснованную оценку рисков. Предприятия, которые принимают высокоуровневые заявления — "мы шифруем ваши данные" — наследуют риск обнаружения деталей реализации после утечки.
Источники: