Прохождение машины Reactor на Hack The Box
Машина Reactor из 11-го сезона Hack The Box построена вокруг сразу нескольких типичных для пентеста задач: разведки, анализа веб-приложения, эксплуатации уязвимости NextJS, извлечения учетных данных из базы и повышения привилегий через оставленный разработчиками отладочный интерфейс Node.js.
Цепочка атаки выглядит следующим образом:
1. обнаружение веб-приложения на порту 3000;
2. определение используемого стека NextJS;
3. эксплуатация уязвимости React2Shell;
4. получение оболочки от имени пользователя `node`;
5. извлечение хеша пароля из базы SQLite;
6. подбор пароля пользователя `engineer`;
7. подключение по SSH;
8. эксплуатация NodeJS Inspector, работающего с правами root.
Разведка и поиск открытых портов
Начинать проверку целевой системы следует с сетевой разведки. Сканирование Nmap показывает два доступных TCP-порта:
- `22/tcp` - OpenSSH;
- `3000/tcp` - веб-приложение, связанное с Node.js или NextJS.
SSH на начальном этапе не дает очевидной точки входа, поскольку неизвестны учетные данные. Поэтому основное внимание стоит сосредоточить на веб-сервисе.
При переходе на порт 3000 открывается интерфейс мониторинга состояния реактора. Страница выглядит как полноценная панель наблюдения, однако интерактивных элементов, форм авторизации или явно оставленных разработчиками подсказок на ней нет.
Фаззинг веб-приложения
Следующий этап - перебор директорий, файлов и стандартных конечных точек. Для этого можно использовать `ffuf`, проверяя распространенные пути и расширения.
Перебор не обнаруживает интересных директорий или файлов. Это не означает, что приложение защищено: уязвимость может находиться непосредственно в используемом фреймворке, а не в отдельной доступной странице.
Поэтому важно определить технологический стек. Анализ заголовков, структуры ответов и признаков клиентского JavaScript показывает, что приложение работает на NextJS. Версия фреймворка оказывается устаревшей и потенциально уязвимой.
Эксплуатация уязвимости React2Shell
Для данной версии NextJS актуальна критическая уязвимость CVE-2025-55182, получившая неофициальное название React2Shell. Ее оценка по CVSS составляет 10 баллов.
Проблема связана с небезопасной десериализацией данных, поступающих в HTTP-запросах. При определенных условиях атакующий может передать специально сформированную нагрузку и добиться удаленного выполнения команд на сервере. Особенно опасна эта ошибка тем, что для атаки не требуется предварительная авторизация.
Уязвимость затрагивает приложения, использующие связку React и NextJS, поэтому ее появление вызвало серьезный резонанс среди разработчиков и специалистов по информационной безопасности.
Для эксплуатации используется публичный скрипт. После запуска эксплойта удается выполнить команды на целевой машине. Встроенная функция обратного подключения позволяет получить интерактивную оболочку.
Перед отправкой reverse shell необходимо определить IP-адрес интерфейса, через который атакующая машина доступна из лабораторной сети. После этого на целевой системе запускается обратное соединение.
Первичная оболочка неудобна: для выполнения команд приходится несколько раз нажимать Enter. Такое поведение характерно для некоторых примитивных каналов связи. Поэтому лучше заменить ее на стандартный Bash reverse shell, а затем выполнить полноценное улучшение терминала с помощью Python, назначить корректные переменные окружения и включить обработку управляющих символов.
Полученная оболочка работает от имени пользователя `node`.
Поиск учетных данных
В домашнем каталоге обнаруживается имя пользователя `engineer`. Это важная подсказка: вероятно, следующим этапом станет получение его пароля или другого способа аутентификации.
В каталоге веб-приложения находится файл базы данных `reactor.db`. Формат SQLite позволяет исследовать его локально с помощью штатной утилиты `sqlite3`.
После просмотра списка таблиц внимание привлекает таблица `users`. В ней находятся записи пользователей и хешированные значения паролей. Такие данные не следует считать безопасными только потому, что они представлены в виде хеша: если пароль слабый или используется популярный словарь, его можно восстановить перебором.
Полученные хеши передаются в Hashcat. Для первой проверки подходит словарь `rockyou`. В результате удается подобрать пароль учетной записи `engineer`.
Теперь можно подключиться к серверу по SSH, используя найденные учетные данные. После успешного входа становится доступен файл `user.txt`, содержащий пользовательский флаг.
Анализ процессов и поиск пути к root
После получения доступа к учетной записи `engineer` необходимо провести локальную разведку. В первую очередь проверяются процессы, запущенные с правами root, а также слушающие локальные порты.
В выводе обнаруживается процесс Node.js Inspector, работающий от имени root и доступный на порту `9229`. Этот интерфейс предназначен для отладки приложений Node.js. Через него разработчик может исследовать выполнение программы, просматривать состояние процесса и выполнять JavaScript-код.
В рабочей среде такой сервис не должен оставаться доступным без ограничений. Отладочный порт предоставляет значительно больше возможностей, чем обычный веб-интерфейс, а запуск его от имени root превращает ошибку конфигурации в потенциальный путь к полному захвату системы.
Подключение к NodeJS Inspector
Для взаимодействия с Inspector используется протокол WebSocket. Если специализированной утилиты нет на целевой машине, ее можно предварительно подготовить на атакующей системе и передать через временный HTTP-сервер.
После загрузки бинарника `websocat` ему назначаются права на выполнение. Затем проверяется доступность отладочной конечной точки. NodeJS Inspector возвращает идентификатор активной отладочной сессии - он необходим для формирования дальнейших запросов.
Через WebSocket отправляется команда, которая заставляет процесс с правами root изменить права доступа к `/bin/bash` и установить SUID-бит. Смысл операции заключается в том, что Bash после запуска сможет сохранить эффективные права владельца файла, то есть root.
Важно понимать, что подобная атака возможна не из-за отдельной ошибки в Bash, а вследствие совокупности небезопасных настроек:
- отладчик запущен в рабочем окружении;
- процесс работает с максимальными привилегиями;
- порт Inspector доступен из атакуемой среды;
- отсутствует дополнительная аутентификация или фильтрация доступа.
После установки SUID-бита запускается `/bin/bash` с сохранением эффективных прав root. Проверка идентификатора пользователя подтверждает успешное повышение привилегий. В завершение остается прочитать файл `root.txt`.
Что можно было бы улучшить в конфигурации
Администратору системы следует отключать NodeJS Inspector в production-среде. Если отладка действительно необходима, порт нельзя оставлять доступным для недоверенных пользователей или сетей.
Также важно запускать веб-приложение от отдельной непривилегированной учетной записи. Даже успешная эксплуатация NextJS в таком случае ограничила бы последствия компрометации правами сервисного пользователя.
База данных с паролями не должна находиться в открытом каталоге приложения без дополнительной защиты. Хеширование необходимо выполнять стойким алгоритмом с солью и подходящими параметрами сложности. Кроме того, секреты не следует хранить рядом с файлами, доступными процессу веб-приложения без необходимости.
Отдельное внимание нужно уделять контролю исходящих соединений. Reverse shell часто требует, чтобы сервер мог установить соединение с внешним адресом. Ограничение исходящего трафика значительно усложняет эксплуатацию даже уже найденной уязвимости.
Итоговая цепочка компрометации
Компрометация Reactor демонстрирует классический сценарий многоэтапной атаки. Сначала определяется доступный веб-сервис, затем устанавливается его технологическая база. Устаревшая версия NextJS приводит к удаленному выполнению команд без авторизации.
Получив оболочку от имени `node`, атакующий находит SQLite-базу и извлекает из нее хеш пароля. Подбор пароля позволяет перейти к учетной записи `engineer` и получить `user.txt`.
Финальная стадия связана с забытым отладочным портом Node.js. Доступ к NodeJS Inspector, запущенному от имени root, дает возможность выполнить команды с максимальными привилегиями, установить SUID-бит на Bash и прочитать `root.txt`.
Таким образом, машина показывает, как уязвимость в веб-фреймворке, слабое управление секретами и небезопасная отладочная конфигурация могут последовательно привести к полному контролю над сервером.