Злоумышленники взламывают серверы NGINX в рамках кампании по перехвату пользовательского трафика и его перенаправлению через внутреннюю инфраструктуру злоумышленников.
NGINX — это программное обеспечение с открытым исходным кодом для управления веб-трафиком. Оно обеспечивает взаимодействие между пользователями и серверами и используется для веб-обслуживания, балансировки нагрузки, кэширования и обратного проксирования.
Вредоносная кампания, обнаруженная исследователями из DataDog Security Labs, нацелена на установки NGINX и панели управления хостингом Baota, которые используются на сайтах с азиатскими доменами верхнего уровня (.in, .id, .pe, .bd и .th), а также на государственных и образовательных сайтах (.edu и .gov).
Злоумышленники изменяют существующие файлы конфигурации NGINX, внедряя вредоносные блоки ‘location’, которые перехватывают входящие запросы по выбранным злоумышленником URL-адресам.
Затем они переписывают их, добавляя полный исходный URL, и перенаправляют трафик через директиву ‘proxy_pass’ на домены, контролируемые злоумышленниками.
Эта директива обычно используется для балансировки нагрузки, позволяя NGINX перенаправлять запросы через альтернативные группы внутренних серверов для повышения производительности или надежности. Таким образом, ее неправильное использование не приводит к срабатыванию предупреждений системы безопасности.
Заголовки запросов, такие как ‘Host,’ ‘X-Real-IP,’ ‘User-Agent,’ и ‘Referer’ , сохраняются, чтобы трафик выглядел легитимным.
Для внедрения в конфигурацию NGINX используется многоэтапный инструментарий. Он состоит из пяти этапов:
- Этап 1 — zx.sh: выступает в качестве исходного скрипта-контроллера, отвечающего за загрузку и выполнение остальных этапов. Он включает в себя резервный механизм, который отправляет необработанные HTTP-запросы по протоколу TCP, если curl или wget недоступны.
- Этап 2 — bt.sh: нацелен на файлы конфигурации NGINX, управляемые панелью Baota. Он динамически выбирает шаблоны внедрения на основе значения server_name, безопасно перезаписывает конфигурацию и перезагружает NGINX, чтобы избежать простоя сервиса.
- Этап 3 — 4zdh.sh: перечисляет распространенные расположения конфигурационных файлов NGINX, такие как sites-enabled, conf.d и sites-available. Использует инструменты синтаксического анализа, такие как csplit и awk, для предотвращения повреждения конфигурации, выявляет предыдущие внедрения с помощью хеширования и глобального файла сопоставления, а также проверяет изменения с помощью команды nginx -t перед перезагрузкой.
- Этап 4 — zdh.sh: используется более узконаправленный подход, ориентированный в основном на /etc/nginx/sites-enabled, с упором на домены .in и .id. Процесс тестирования и перезагрузки конфигурации аналогичен, но в качестве запасного варианта используется принудительный перезапуск (pkill).
- Этап 5 — ok.sh: Сканирует скомпрометированные конфигурации NGINX, чтобы составить карту захваченных доменов, шаблонов для внедрения и прокси-серверов. Собранные данные передаются на командный сервер (C2) по адресу 158.94.210[.]227.
Обзор атаки с целью захвата
Источник: Datadog
Такие атаки сложно обнаружить, поскольку они не используют уязвимости NGINX, а вместо этого скрывают вредоносные инструкции в файлах конфигурации, которые редко проверяют.
Кроме того, пользовательский трафик по-прежнему доходит до пункта назначения, часто напрямую, поэтому маловероятно, что факт его прохождения через инфраструктуру злоумышленника будет замечен, если только не проводить специальный мониторинг.