Изследователи от DataDog Security Labs разкриха мащабна злонамерена кампания, при която атакуващи компрометират NGINX сървъри, за да прехващат и пренасочват легитимен потребителски трафик през собствена backend инфраструктура.

Важно е да се подчертае, че не се експлоатира уязвимост в NGINX. Вместо това атаката използва злоупотреба с легитимни конфигурационни механизми, което я прави особено трудна за откриване.

Кои системи са цел

Кампанията е насочена основно към:

• NGINX инсталации, управлявани чрез Baota hosting management panel

• Сайтове с азиатски домейни от първо ниво: .in, .id, .pe, .bd, .th

• Правителствени и образователни сайтове с домейни .gov и .edu

Това подсказва както географска насоченост, така и интерес към високодоверени уеб ресурси.

Как работи атаката

Атакуващите модифицират съществуващи NGINX конфигурационни файлове, като инжектират злонамерени location блокове. Тези блокове:

• Прихващат входящи HTTP заявки към специфично избрани URL пътища

• Преписват заявките, така че да съдържат пълния оригинален URL

• Пренасочват трафика чрез директивата proxy_pass към домейни, контролирани от атакуващите

Защо това е ефективно

Директивата proxy_pass по принцип се използва за:

• load balancing

• failover

• подобряване на производителността и надеждността

Поради тази причина нейната злоупотреба не генерира аларми в стандартни системи за сигурност.

Освен това, атаката запазва оригиналните HTTP headers, включително:

• Host

• X-Real-IP

• User-Agent

• Referer

Това прави трафика да изглежда напълно легитимен както за крайните сървъри, така и за логовете.

Многоетапен инструментариум

Кампанията използва скриптиран toolkit от пет етапа, предназначен за автоматизирана и безопасна модификация на конфигурациите:

Етап 1 – zx.sh
Начален контролен скрипт, който изтегля и стартира останалите компоненти. Включва fallback механизъм за изпращане на сурови HTTP заявки през TCP, ако curl или wget липсват.

Етап 2 – bt.sh
Фокусиран върху NGINX конфигурации, управлявани от Baota панела. Скриптът:

• избира динамично шаблони за инжекция според server_name

• презаписва конфигурацията по „безопасен“ начин

• презарежда NGINX без прекъсване на услугата

Етап 3 – 4zdh.sh
Обхожда стандартни директории като:

• sites-enabled

• conf.d

• sites-available

Използва инструменти като csplit и awk, за да предотврати повреда на конфигурациите, проверява за предишни инжекции чрез хеширане и валидира промените с nginx -t преди reload.

Етап 4 – zdh.sh
По-тясно насочен вариант, фокусиран основно върху /etc/nginx/sites-enabled, с акцент върху домейни .in и .id. При проблем с reload се използва принудителен рестарт (pkill) като резервна опция.

Етап 5 – ok.sh
Сканира компрометираните конфигурации и изгражда карта на:

• hijack-нати домейни

• използвани инжекционни шаблони

• proxy цели

Събраните данни се екфилтрират към C2 сървър на адрес 158.94.210[.]227.

Защо атаката е толкова трудна за откриване

• Няма експлойт – използва се легитимна функционалност

• Злонамереният код е скрит в конфигурационни файлове, които рядко се одитират детайлно

• Трафикът често достига директно до реалната цел, минавайки през атакуващата инфраструктура „прозрачно“

• Без специфичен мониторинг на NGINX конфигурации и upstream трафик, атаката остава невидима

Тази кампания е пример как конфигурационната злоупотреба може да бъде също толкова опасна, колкото и класическите уязвимости. За организациите, които разчитат на NGINX като критичен компонент от уеб инфраструктурата си, това подчертава нуждата от:

• редовен одит на конфигурационните файлове

• контрол на административния достъп

• мониторинг на upstream proxy трафика

• засичане на неочаквани proxy_pass правила

В противен случай дори напълно обновен и „сигурен“ NGINX може да се превърне в невидим канал за компрометиране на потребителския трафик.