Alerte de sécurité NGINX sous proxy _ passer l'attaque de manipulation pour détourner le trafic

Si vous utilisez NGINX pour servir des sites, faites l'équilibre de charge ou comme un mandataire inverse, faites attention: une campagne a récemment été détectée dans laquelle un acteur malveillant engage des serveurs NGINX et des outils de gestion d'hébergement pour rediriger le trafic des utilisateurs vers leur propre infrastructure, en maintenant l'apparence de normal.

NGINX est, par conception, un intermédiaire entre le visiteur et le serveur final : il reçoit les requêtes, applique les règles, peut les rechercher et les renvoyer à d'autres moteurs. Cette flexibilité est précisément ce que ces attaquants exploitent. Sécurité de Datadog Les chercheurs de laboratoires ont documenté comment les attaquants entrent des blocs de configuration malveillantes dans les fichiers NGINX - en particulier dans les installations gérées avec le panneau Baota - pour capturer des itinéraires spécifiques et les renvoyer à travers la directive _ passer par proxy aux serveurs contrôlés par eux. Vous pouvez en savoir plus sur le travail de Datadog dans la section sécurité de son blog ( Laboratoires de sécurité Datadog).

La campagne consiste à injecter des blocs. lieu qui correspondent aux routes choisies par l'attaquant et réécrivent la requête pour inclure l'URL d'origine avant de l'orienter avec _ passer par proxy à des domaines externes. Pour que la redirection semble légitime, ils gardent des en-têtes comme Hébergement, X-Real-IP, Utilisateur-Agent ou Voir. Depuis _ passer par proxy est une fonction légitime et très utilisée pour équilibrer et échouer, leur abus passe inaperçu si les configurations ne sont pas inspectées.

Le modus operandi découvert comprend un ensemble de scripts automatisés qui agissent par étapes: un pilote initial télécharge et exécute les composants restants et peut même envoyer des requêtes HTTP brutes à TCP s'il n'y a pas d'outils tels que curl ou wget; un autre composant est spécifiquement dirigé vers des fichiers gérés par le panneau Baota et sélectionne des modèles d'injection en fonction de la valeur de _nom du serveur, écraser la configuration de sorte que le service n'arrête pas de fournir le service; il existe des outils qui recherchent et traitent les fichiers de configuration dans des endroits typiques (enabled sites, conf.d, sites-disponibles), utilisent des utilitaires texte pour séparer et éditer des fragments sans les corrompre, valider les modifications avec Nginx -t avant de recharger et de marquer les fichiers déjà infectés par des quantités pour éviter de doubler l'injection; une autre pièce concentre l'attaque sur un sous-ensemble de domaines (selon les chercheurs, beaucoup avec des terminaisons régionales telles que .in et .id et aussi des sites avec .edu / .gov suffixes) et utilise des réinitialisations forcées en dernier recours; enfin il y a un script qui inventerait une carte de domaines compromis et exfiltre ces informations à un serveur de commande et de contrôle identifié par les trackers.

Précisément parce qu'une vulnérabilité n'est pas utilisée dans le moteur NGINX mais la possibilité de modifier vos fichiers de configuration, ces attaques sont complexes à détecter. Les gestionnaires peuvent ne rien remarquer d'étrange: les utilisateurs continuent à recevoir le contenu attendu et le trafic ne présente pas de défauts visibles à l'œil nu. En outre, en gardant les en-têtes et les demandes d'envoi, l'interaction semble légitime du point de vue du client et de nombreux systèmes de surveillance ignorent la différence.

Si vous voulez vérifier si votre environnement est affecté, il y a plusieurs lignes de défense pratiques. Vérifiez attentivement les paramètres NGINX pour lieu et _ passer par proxy qui pointent vers des domaines ou des PI en dehors de votre organisation; une commande simple à démarrer est de rechercher des occurrences proxy _ pass sur des itinéraires de configuration typiques, et toujours valider avec Nginx -t avant recharge. Limiter qui peut écrire dans les fichiers de configuration et dans les répertoires du panneau d'hébergement, surveiller les changements inattendus avec les systèmes d'intégrité des fichiers et enregistrer et alerter sur les recharges ou redémarrages NGINX. Il est également recommandé de limiter le trafic sortant non autorisé des serveurs Web et de protéger les panneaux de contrôle tels que Baota avec des mots de passe forts, l'authentification multifactorielle et l'accès IP si possible. Le panel Baota a une présence en ligne sur son site officiel ( BAOTA (BT.cn)) et il convient de veiller à ce que ces corps soient exposés.

Pour comprendre pourquoi détecter ces manipulations n'est pas trivial, rappelez-vous que _ passer par proxy est une directive NGINX documentée et commune; la documentation technique elle-même décrit son utilisation pour envoyer des requêtes aux moteurs et est une pièce fondamentale dans les architectures modernes ( NGINX documentation officielle sur proxy _ pass). Cela signifie que les changements malveillants sont camouflés comme des configurations valides et fonctionnelles.

Si vous souhaitez suivre les indicateurs de recherche ou de vérification, les équipes d'intervention publient habituellement des appareils et des adresses IP associés à C2 pour bloquer les pare-feu et les listes de rejet; par exemple, l'une des adresses associées aux chercheurs peut être consultée sur des bases de réputation publique ( consultation en matière d'abusIPDB pour 158.94.210.227) qui permet d'agir en réseau au niveau défensif.

Bref, il ne suffit pas de protéger le logiciel : il faut protéger la configuration et y accéder. examiner régulièrement les fichiers de configuration, limiter les changements au personnel autorisé et surveiller la télémétrie et les recharges du réseau NGINX sont des mesures essentielles pour détecter et contenir de telles campagnes. Si vous gérez des serveurs avec des panneaux d'hébergement, assurez-vous que ces panneaux sont à jour et que l'accès est fortement authentifié; la sécurité de la couche de gestion est souvent le lien le plus fragile dans ces incidents.

Si vous souhaitez approfondir des recommandations techniques spécifiques et des pratiques d'atténuation, la communauté et les fournisseurs tels que Datadog ou NGINX lui-même publient des guides et des entrées techniques à suivre: en plus de l'article technique de Datadog cité au début, NGINX maintient des entrées sur les bonnes pratiques de sécurité sur son blog ( Sécurité NGINX - guide et recommandations). Combiner ces bonnes pratiques avec l'intégrité et le contrôle du réseau est la meilleure recette pour ne pas prendre de surprises.