Shellshock: когда старый фундамент становится поверхностью атаки
Что уязвимость в bash говорит о рисках, встроенных в давно работающую инфраструктуру, и почему это разговор для руководителя, а не только для ИБ.
На прошлой неделе стало известно об уязвимости в bash - командном интерпретаторе, который присутствует практически на каждом сервере под управлением Linux и macOS, а также во встроенных системах по всему миру. Уязвимость получила имя Shellshock. Она позволяет выполнить произвольный код на удалённом сервере через специально сформированные переменные окружения - в том числе через веб-запросы к CGI-скриптам.
Технические подробности важны для инженеров. Но есть разговор, который важен для руководителя: что это говорит о рисках, встроенных в инфраструктуру, которой много лет?
Что произошло
Bash - это программа, которой больше двадцати лет. Она есть везде: в веб-серверах, в системах управления сетью, в промышленных контроллерах с IP-интерфейсами, в NAS-хранилищах, в маршрутизаторах. Проблема существовала в коде много лет, но стала видна только сейчас.
Это не экзотика. Это типичная история для базового системного программного обеспечения: оно работает незаметно, обновляется редко, и никто не смотрит в его код с точки зрения безопасности, пока что-то не случается.
Shellshock опасен не только как конкретная уязвимость. Он опасен как класс: старый компонент инфраструктуры, о котором давно не думали, неожиданно оказывается открытой дверью. Тот же паттерн проявился ранее в этом году: уязвимость в OpenSSL, о которой большинство компаний узнали только тогда, когда она уже появилась на первых полосах.
Почему это проблема управления, а не только техническая
Каждая компания, у которой есть веб-серверы, сервисы на Linux, или любое сетевое оборудование под управлением Unix-подобных систем, сейчас задаёт одни и те же вопросы своим ИТ-командам: затронуты ли мы? Что обновлено?
Правильные вопросы. Но за ними стоит более глубокий: а есть ли у нас вообще полное понимание того, что работает в нашей инфраструктуре?
Большинство компаний накопили инфраструктуру за годы. Старые серверы, забытые сервисы, встроенные устройства, которые никто не обновлял с момента установки. Всё это подключено к сети. Всё это потенциальная поверхность атаки.
Shellshock обнажает не только конкретную дыру в bash. Он обнажает отсутствие инвентаризации и понимания того, что вообще есть в сети.
Три слоя проблемы
Первый слой - немедленная реакция. Обновить bash везде, где он есть. Для большинства современных систем это решаемо за часы. Но "везде, где он есть" - это уже требует знания инвентаря.
Второй слой - встроенные и унаследованные системы. Маршрутизаторы, промышленные контроллеры, IP-камеры, NAS - это устройства, производитель которых может уже не выпускать обновления, или обновление требует сервисного визита. Здесь быстрого патча может не быть. Промышленные АСУ ТП сталкиваются с этой проблемой в наиболее острой форме: патчить трудно, но работать без режима обновлений ещё опаснее.
Третий слой - системный. Если одна уязвимость в компоненте двадцатилетней давности вызвала такой отклик, значит инфраструктура содержит компоненты, которые находятся вне активного сопровождения. Это не разовая проблема - это постоянный риск.
Что спросить у своей команды
Это хороший момент для нескольких вопросов, которые имеют смысл независимо от Shellshock:
- Есть ли у нас актуальный список всего, что подключено к сети - серверов, сетевого оборудования, встроенных устройств?
- Для каких компонентов производитель больше не выпускает обновления безопасности?
- Как быстро мы можем применить критический патч ко всей инфраструктуре?
- Какие системы у нас фактически "не трогают, потому что работает" - и когда их последний раз обновляли?
- Есть ли у нас процесс отслеживания публичных уязвимостей в компонентах, которые мы используем?
Shellshock пройдёт. Класс проблем, который он представляет, никуда не денется.