Поделиться
Хакеры научились тайком подменять настройки знаменитого веб-сервера с российскими корнями
Речи не идёт о какой-либо эксплуатации уязвимостей в 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.
Этап 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.
Эти атаки трудно обнаружить, поскольку они не используют никаких уязвимостей Nginx; вместо этого они скрывают вредоносные инструкции в его файлах настроек, которые редко подвергаются тщательному анализу.
Кроме того, пользовательский трафик по-прежнему достигает места назначения, часто напрямую, поэтому прохождение через инфраструктуру злоумышленника вряд ли можно обнаружить без специального мониторинга.
Поделиться
Короткая ссылка
