Flame и доверие к обновлениям: когда канал доставки становится частью атаки
Вредоносная программа Flame использовала подделанные сертификаты Microsoft для распространения. Подпись кода и доверенные цепочки поставки - это теперь управленческая тема.
В мае 2012 года стало известно о Flame - одной из самых сложных вредоносных программ из когда-либо обнаруженных. Среди прочего, Flame умел распространяться через Windows Update, подписывая свои компоненты сертификатами, которые Windows считала доверенными. Для этого атакующие использовали уязвимость в механизме выдачи сертификатов Microsoft.
Это важный момент не потому, что Flame - это угроза для большинства компаний. Он нацелен на конкретные объекты, предположительно государственного уровня. Важно другое: атака шла не через уязвимость в приложении, а через механизм доверия к самому каналу доставки обновлений. Это смена парадигмы, и её стоит понять. Ещё раньше промышленные системы стали объектами атак, и предположение о защищённости изолированных сетей оказалось ошибочным.
Что такое атака на цепочку поставки
Классическая атака нацелена на систему напрямую: уязвимость в коде, слабый пароль, открытый порт. Атака на цепочку поставки идёт по-другому: вместо того чтобы ломать защиту системы, атакующий компрометирует что-то, чему система уже доверяет.
В случае Flame это был центр сертификации - структура, которая выдаёт криптографические подписи, подтверждающие подлинность программного обеспечения. Когда это доверие нарушено, Windows Update превращается из механизма защиты в механизм доставки вредоносного кода.
Это не уникальная ситуация для государственных атак. Коммерческие примеры тоже известны: взлом инфраструктуры разработчика программного обеспечения, после которого заражённые обновления распространялись к клиентам; компрометация репозиториев пакетов, из которых разработчики автоматически тянут зависимости.
Почему подпись кода - это управленческая тема
Технические детали здесь сложные, но решение для менеджера не требует их понимания в полной мере. Нужно понимать вопрос: на что именно ваши системы доверяют, не проверяя каждый раз заново?
Обновления операционных систем и приложений - доверяют ли ваши системы им автоматически? Внешние библиотеки и компоненты, которые использует ваш разработчик - откуда они берутся и верифицируется ли их происхождение? Системы мониторинга и агенты, установленные на серверах - кто контролирует, что именно там установлено?
Каждый из этих вопросов описывает звено в цепочке доверия. Когда одно звено компрометировано - весь последующий контроль бесполезен.
Что изменилось после Flame
Microsoft отозвала скомпрометированные сертификаты и ужесточила правила выдачи. Это правильный ответ на конкретную уязвимость. Но более широкий вывод касается всей индустрии: механизмы доверия к программному обеспечению требуют такого же внимания, как и сам код.
Несколько направлений, которые становятся важнее:
Верификация цепочки сертификатов. Не просто "подпись есть", а "подпись выдана ожидаемым удостоверяющим центром и не была отозвана".
Контроль зависимостей. Если ваш продукт собирается из десятков внешних компонентов, вопрос о происхождении и целостности каждого из них - это вопрос безопасности, а не только удобства разработки.
Принцип наименьшего доверия к обновлениям. Автоматические обновления удобны. Но критические системы могут требовать дополнительного контроля - не потому что обновления плохие, а потому что канал доставки тоже является поверхностью атаки.
Граница между паранойей и разумной осторожностью
Я не призываю отключить автоматические обновления или переходить на ручную верификацию каждого пакета. Это нереалистично для большинства компаний и создаёт свои риски - незакрытые уязвимости опаснее, чем теоретически скомпрометированный канал обновлений.
Разумная осторожность выглядит иначе:
- Знать, откуда берётся программное обеспечение в ваших системах.
- Иметь процедуру реакции на случай отзыва ключевых сертификатов или компрометации поставщика.
- Для наиболее критичных систем - рассматривать дополнительные уровни верификации.
- Следить за уведомлениями о безопасности от ключевых поставщиков, а не только реагировать после инцидента.
История Flame показывает, что атаки на доверие сложнее обнаружить, чем атаки на уязвимости. Это не повод для паники - но это повод знать, где в вашей инфраструктуре лежат точки неявного доверия.