24 сентября в Bash нашли уязвимость, которую уже назвали Shellshock (CVE-2014-6271). Она затрагивает практически каждый сервер на Linux и Unix, где работает Bash, – а это большинство инфраструктуры рунета и госсектора. По масштабу её сравнивают с Heartbleed, но эксплуатация проще: атакующий выполняет произвольные команды на чужом сервере одним HTTP-запросом. Разбираем, как это работает и что делать прямо сейчас.

В чём суть уязвимости

Bash умеет передавать функции дочерним процессам через переменные окружения. Парсер обрабатывает значение переменной и при разборе определения функции продолжает выполнять всё, что идёт после закрывающей скобки. То есть в значение переменной можно дописать команду и Bash её выполнит.

Классический тест занимает одну строку:

env x='() { :;}; echo vulnerable' bash -c "echo test"

Если в выводе появилось vulnerable – система уязвима. Опубликованный 24 сентября патч закрыл основной вектор не полностью: уже к утру 25-го появился CVE-2014-7169, обходящий первую заплатку. Ставьте обновления по мере выхода и проверяйте систему повторно после каждого.

Где это бьёт по серверам

Проблема не в самом Bash, а в том, сколько сервисов передают ему недоверенные данные через окружение. Основные точки входа:

  • CGI-скрипты на веб-серверах. Apache с mod_cgi кладёт заголовки HTTP-запроса в переменные окружения. Заголовок User-Agent или Referer со строкой () { :;}; команда выполнит код от имени веб-сервера. Это удалённая эксплуатация без аутентификации – самый опасный сценарий.
  • DHCP-клиенты. Вредоносный DHCP-сервер отдаёт опции с инъекцией, и клиент выполняет команды при получении адреса.
  • OpenSSH с ограниченными командами. ForceCommand и записи authorized_keys с command= можно обойти через SSH_ORIGINAL_COMMAND.
  • Демоны и скрипты, которые принимают внешний ввод и зовут Bash напрямую или через system().

Главный риск для бизнеса – публичные веб-серверы и приложения, где порядок наследования компонентов непрозрачен. Если вы используете коробочное ПО, точно знать состав зависимостей и точки вызова shell вы зачастую не можете – это один из аргументов в пользу заказной разработки против коробочных решений, где архитектуру и поверхность атаки вы контролируете сами.

Что делать сегодня

  1. Инвентаризируйте Bash. Прогоните тест выше на каждом сервере. Не забудьте контейнеры, образы и встроенные системы – там Bash обновляют реже всего.
  2. Обновите пакет из репозиториев дистрибутива и перезапустите затронутые сервисы. Следите за выходом патчей под новые CVE.
  3. Отключите CGI там, где он не нужен, и закройте веб-серверы от обработки лишних заголовков на уровне WAF или reverse-proxy.
  4. Проверьте логи на запросы с подстрокой () { в заголовках и URL – массовое сканирование началось в первые часы после публикации.
  5. Уберите Bash из цепочки обработки внешнего ввода, где это возможно: для системных скриптов хватает /bin/sh (dash) или прямого вызова без оболочки.

Системный подход к таким инцидентам описан в нашем чек-листе по харденингу Linux: минимум установленного ПО, сегментация и аудит сокращают как поверхность атаки, так и время реакции.

Вывод

Shellshock опасен не сложностью эксплойта, а распространённостью Bash и количеством скрытых точек, где он получает чужие данные. Закрыть вектор – это патч плюс ревизия архитектуры: какие сервисы вызывают оболочку и с какими правами. Если на сервере остались уязвимые точки входа, разумно начать с аудита инфраструктуры и устранения уязвимостей: сначала ревизия архитектуры, затем закрытие найденных векторов.