Речь не об использовании уязвимостей в Nginx — злоумышленники применяют shell-скрипты для изменения конфигураций. На данный момент это не затрагивает интересы обычных пользователей.
Специалисты DataDog Security Labs обнаружили кампанию по взлому серверов Nginx с целью перехвата и перенаправления пользовательского трафика.
Nginx — это широко распространённое программное обеспечение с открытым кодом, используемое для управления веб-трафиком. Оно выступает промежуточным звеном между пользователями и серверами, применяясь для работы веб-серверов, балансировки нагрузки, кэширования и обратного проксирования.
Разработку веб-сервера Nginx начал российский программист Игорь Сысоев. В 2019 году российская компания-разработчик Nginx была приобретена американской корпорацией F5 Networks. В январе 2022 года Игорь Сысоев покинул проект.
Вредоносная кампания нацелена на установки Nginx и панели управления хостингом Baota, которые используются сайтами с азиатскими доменами верхнего уровня (.in, .id, .pe, .bd и .th), а также правительственными и образовательными ресурсами (.edu и .gov).
Злоумышленники с помощью набора shell-скриптов модифицируют существующие файлы настроек Nginx, добавляя вредоносные блоки location. Эти блоки перехватывают входящие запросы, направляя их на определённые злоумышленниками URL-адреса.
Такие запросы перенаправляются через команду proxy_pass на домены, контролируемые злоумышленниками. Согласно данным DataDog, таких доменов всего три: th.cogicpt.org, ide.hashbank8.com и xzz.pier46.com. Перенаправление трафика зависит от доменов верхнего уровня, к которым изначально был адресован запрос.
— Очевидно, предпринимается попытка перехвата трафика, связанного с «серой зоной» — в первую очередь, азартными играми, а также новостными ресурсами, — комментирует Александр Зонов, эксперт по информационной безопасности компании SEQ. — По всей видимости, кто-то пытается таким образом увеличить посещаемость собственных сайтов. Других признаков вредоносной активности, которая могла бы навредить конечным пользователям, здесь не наблюдается. По крайней мере, пока.
Команда proxy_pass обычно применяется для балансировки нагрузки: Nginx перенаправляет запросы через резервные группы серверов для повышения производительности или надёжности; злоупотребление этой директивой не вызывает реакции систем безопасности.
Заголовки запроса, такие как 'Host', 'X-Real-IP', 'User-Agent' и 'Referer', сохраняются, чтобы трафик выглядел легитимным. Также сохраняется URL исходного запроса.
Атака использует многоэтапный набор скриптов для внедрения конфигурации в Nginx.
Первый этап – zx.sh: основной управляющий скрипт, который загружает и запускает последующие компоненты. Он содержит механизм восстановления, отправляющий «сырые» HTTP-запросы по протоколу TCP в случаях, когда недоступны стандартные утилиты curl или wget.
Второй этап – bt.sh: данный скрипт фокусируется на конфигурационных файлах Nginx под управлением панели Baota. Он гибко подбирает шаблоны для внедрения, анализируя значение server_name, аккуратно перезаписывает настройки и выполняет перезагрузку Nginx, минимизируя перерывы в работе.
Третий этап – 4zdh.sh: выполняет инвентаризацию расположений конфигурационных файлов Nginx, включая sites-enabled, conf.d и sites-available. Применяет инструменты обработки текста, такие как csplit и awk, чтобы избежать повреждения настроек, выявляет предыдущие внедрения с помощью хеш-сумм и глобального файла соответствий, а также проверяет корректность конфигурации командой Nginx -t перед её применением.
Четвертый этап – zdh.sh: использует более сфокусированную стратегию, нацеливаясь преимущественно на каталог /etc/Nginx/sites-enabled, с особым вниманием к доменам .in и .id. Сохраняет процедуру тестирования и перезагрузки конфигурации, используя принудительное завершение процессов (pkill) в качестве запасного метода.
Пятый этап – ok.sh: анализирует скомпрометированные конфигурации Nginx для формирования перечня захваченных доменов, внедрённых шаблонов и целевых прокси-серверов. Собранная информация затем передаётся на командный сервер (C2) по адресу 158.94.210[.]227.
Подобные атаки сложно выявить, поскольку они не эксплуатируют уязвимости в самом Nginx; вместо этого зловредные инструкции маскируются в его конфигурационных файлах, которые редко подвергаются детальному изучению.
Более того, пользовательский трафик продолжает достигать целевых ресурсов, часто напрямую, поэтому его маршрутизация через инфраструктуру злоумышленников остаётся практически незаметной без применения специализированных средств мониторинга.
