Reliure DNS en 2k19, ou comment vraiment transpirer en visitant un site porno


Bonjour à tous! Aujourd'hui, nous aimerions parler d'une attaque ancienne et presque oubliée appelée rebinding DNS. La première discussion à ce sujet a commencé en 2007, mais les experts du domaine de la sécurité des informations pratiques n'y ont pas prêté l'attention voulue en ce qui concerne les particularités du fonctionnement de cette attaque, ainsi que peu de conséquences tangibles, comme il semblait alors. Aujourd'hui, nous allons essayer de les convaincre du contraire, et vous, en particulier, en démontrant que dans le monde moderne cette attaque a trouvé un second souffle et ne semble plus si inoffensive.


Qu'est-ce que la reliure DNS?


Considérez le schéma suivant:



Nous avons un ordinateur de victime avec IP 192.168.0.2 sur le réseau local, et il a également un routeur avec l'adresse IP 192.168.0.1. Le but de l'attaquant gérant le serveur avec l'adresse 13.37.13.37 et le nom de domaine hacker.com (également, notre propre serveur DNS contenant des informations sur le domaine tourne sur l'ip-shnik) est d'accéder au routeur sur le réseau local.


Pour utiliser la technique de reliure DNS, nous devons attirer la victime sur notre site malveillant. Supposons que nous ayons réussi.


Examinons maintenant en détail le fonctionnement de l'attaque.


Tout d'abord, le navigateur accède aux serveurs DNS avec une demande d'enregistrement A:



La chaîne de serveurs DNS mène à notre serveur, qui, à son tour, donne une réponse standard contenant la véritable adresse IP du site malveillant, et indique également le TTL dont nous avons besoin, dans ce cas 59.



Ensuite, le navigateur fait une requête HTTP standard pour l'IP reçue.



À l'étape suivante, le serveur répond avec une page HTML avec du code javascript accédant à notre propre domaine.



Maintenant, jusqu'à ce que le TTL expire et que l'utilisateur soit sur le site, le javascript reçu ci-dessus sera exécuté. Une fois le TTL terminé, le navigateur demandera à nouveau un enregistrement A.



À l'heure actuelle, notre javascript continue de fonctionner et le serveur DNS que nous gérons répondra par un enregistrement A avec une adresse IP du réseau local où l'attaquant souhaite se rendre.



Étant donné que le domaine, le port et le protocole restent inchangés, le SOP n'est pas violé et, par conséquent, le navigateur accède au domaine pew.hacker.com, cependant, il frappera déjà le routeur convoité et inaccessible.



En conséquence, nous recevons calmement une réponse du routeur et la redirige vers nous-mêmes en incorporant la fonctionnalité correspondante dans le code javascript chargé plus tôt.




Donc, résumons ce qui précède:


  • L'utilisateur visite le site, reçoit une véritable adresse IP et un court TTL
  • Sur le site, le navigateur appelle le même domaine où se trouve l'utilisateur. Dès que le cache expire, le navigateur demande à nouveau l'IP du domaine.
  • De plus, notre serveur DNS émet au lieu de la vraie adresse, l'adresse IP du service interne (dans notre cas, le routeur)
  • Après que la demande passe par le domaine au routeur, et le résultat nous est envoyé par le javascript préchargé par l'utilisateur à l'avance.

Nous l'avons compris! Beaucoup peuvent avoir une question raisonnable: «Et alors?», Car pour le fonctionnement, vous devez connaître les adresses IP internes des services, garder l'utilisateur pendant un certain temps, etc.


Oui, cependant, avec l'avènement des services de streaming, de l'hébergement vidéo, des bons vieux sites pornographiques et d'autres plateformes où les gens pendent pendant longtemps, l'attaquant aura assez de temps pour mener l'attaque. Quant aux adresses, elles sont souvent standard ou facilement prévisibles.


Mais c'est tout en théorie, mais qu'en pratique? Nous avons sélectionné les 4 domaines les plus pertinents en 2019, où il y a eu des incidents liés à l'attaque de reliure DNS, à savoir:


  • IoT
  • Portefeuilles Crypto
  • Applications bureautiques
  • Les nuages

Examinons chaque sujet dans l'ordre et découvrons si tout est vraiment si inoffensif?


Iot


Accueil Google



Google home est un assistant intelligent de Google. Cet appareil possède (ou avait dans le passé) une API qui ne nécessite aucune authentification pour contrôler l'appareil. Il fournit un certain nombre de fonctionnalités, telles que:


  • Lecture de contenu
  • Numériser
  • Redémarrer
  • Connexion aux réseaux WIFI, etc.

Exemple de scénario d'attaque: un attaquant peut deanonymiser un utilisateur en obtenant les coordonnées des points WIFI les plus proches. De toute évidence, aucun VPN ne peut vous sauver.


Enceintes Wi-Fi Sonos



Ces colonnes de Sonos élèvent un serveur Web sur le réseau local UPnP, qui donne accès à un certain nombre de pages intéressantes:


  • 192.168.1.76:1400/support/review - crache la sortie de certaines commandes UNIX
  • 192.168.1.76:1400/tools - vous permet d'exécuter certaines commandes UNIX

Dans ce cas, l'attaquant a la possibilité d'exécuter la commande traceroute pour scanner la topologie du réseau interne.


Radio Thermostat CT50



C'est l'un de nos cas préférés. Ce modèle de thermostat dispose également d'une API sans aucune autorisation et vous permet de modifier:


  • Mode climatique
  • La température
  • Mode rétroéclairage et autres paramètres

En conséquence, un attaquant peut faire transpirer beaucoup sa victime, mais sérieusement, une telle attaque sur un thermostat, par exemple dans un établissement médical, peut entraîner des conséquences plutôt désagréables.


Roku tv



Les téléviseurs Roku ont toujours la même maladie - une API sans authentification.


L'API vous permet de:


  • Exécutez diverses applications
  • Lire le contenu
  • Effectuer des requêtes de recherche sur le système, etc.

Dans ce cas, le maximum qui menace l'utilisateur est la fuite de données sensibles, ce qui est également désagréable.


Tout routeur WIFI



Presque tout le monde a aujourd'hui cet appareil IoT. Ce n'est un secret pour personne que de nombreux utilisateurs ordinaires ne modifient pas les mots de passe standard à partir des panneaux d'administration de leurs routeurs. Avec l'aide de la reliure DNS, rien ne nous empêche d'essayer de vous connecter avec des informations d'identification standard et d'accéder au panneau d'administration. Si l'adresse IP locale est introuvable, WebRTC vient à la rescousse.


Résumé IoT


Nous mettons en évidence certaines des fonctionnalités fournies par la reliure DNS lorsque vous travaillez avec l'IoT:


  • Possibilité de deanonymiser l'utilisateur
  • Possibilité de scanner un réseau local
  • Utilisateur simulé
  • Tout, selon la fonctionnalité de l'appareil IoT

Portefeuilles Crypto


Geth


Parlons maintenant des portefeuilles de crypto-monnaie. Le premier cas examiné est un client de portefeuilles Ethereum appelé Geth. Ici, la boîte de Pandore est dans le service JSON-RPC. Pour commencer, essayons de comprendre ce que c'est. JSON-RPC est un protocole d'appel de procédure à distance au format JSON. Tout ressemble à ceci:



La plupart des clients exécutent ce service sur localhost: 8545, et à son tour, il fournit un ensemble de fonctions intéressantes, telles que eth_sendTransaction et ainsi de suite.


Maintenant, un exemple de la façon dont vous pouvez obtenir son solde et son adresse de portefeuille à l'insu de l'utilisateur et en utilisant l'attaque de reliure DNS:



Portefeuille EOSIO Keosd


Ensuite, nous avons un client pour les portefeuilles EOSIO. Keosd lui-même démarre sur localhost: 8900 et signe automatiquement toutes les actions d'application pendant 15 minutes après la saisie des données d'autorisation. Après avoir plongé dans l'API, vous pouvez à nouveau trouver des fonctionnalités intéressantes. Pour plus de clarté, en utilisant la demande ci-dessous, vous pouvez obtenir la clé publique de l'utilisateur:



Résumé des portefeuilles Crypto:


  • un attaquant peut voler de l'argent aux utilisateurs
  • un attaquant peut modifier divers paramètres utilisateurs
  • la possibilité de désanonymiser l'utilisateur

Applications bureautiques


Client de transmission


Je voudrais commencer le bloc d'incidents liés aux applications Desktop avec une vulnérabilité relativement sensationnelle dans le client Transmission torrent.


Ici, le problème réside dans le même JSON-RPC, que nous avons examiné un peu plus haut. Dans ce cas, il vous permet de modifier les paramètres utilisateur, par exemple, de changer le dossier de téléchargement des fichiers:



D'une part, cela ne semble rien de grave, mais si vous spécifiez le partage smb contrôlé par l'attaquant au lieu du dossier (si le client utilise le client Windows), vous pouvez intercepter le hachage utilisateur, qui pourra être utilisé à l'avenir.


Client Web uTorrent


Ce camarade a dans son arsenal le même service JSON-RPC qui vous permet de modifier les fichiers de configuration utilisateur, ainsi que de télécharger des fichiers.


L'authentification est requise dans ce cas, mais les informations d'identification sont disponibles sur http://localhost:19575/users.conf . Comment cela peut-il être utilisé?


Tout d'abord, faites la demande suivante:



Après avoir reçu le jeton, nous modifions le dossier de téléchargement dans le dossier où se trouvent les programmes qui s'exécutent au démarrage du système:



Et enfin, nous donnons la commande de télécharger la charge utile nécessaire:



En conséquence, evil.exe sera lancé après le prochain redémarrage.


Minikube


Minikube est un utilitaire de ligne de commande pour configurer et exécuter un cluster Kubernetes monomode dans une machine virtuelle sur l'ordinateur local.


Il se bloque toujours sur 192.168.99.100 et l'interface Web est disponible sur le port 3000. En conséquence, un attaquant a la possibilité de créer un conteneur illicite avec un dossier partagé avec le système principal.


Tout d'abord, vous devez obtenir le jeton csrf.



Ensuite, vous devez créer un conteneur, et pour cela, envoyez la demande suivante:



Voyons voir ce qu'il fait. Dans celui-ci, nous indiquons que lors du démarrage du conteneur, nous devons transmettre le shell inverse, et également monter le dossier Utilisateurs à partir du système principal:



Ruby on Rails


Il existe un joyau pour le framework Ruby on Rails qui vous permet d'exécuter du code Ruby directement dans le navigateur.



Essayons de comprendre ce dont nous avons besoin pour cela?


Nous devons d'abord aller sur une page inexistante:



Ensuite, nous essayons d'accéder à la console via le navigateur:



Enfin, nous formons une demande de lancement de l'application calculatrice (dans cet exemple, le vecteur pour MAC OS X):



Application de bureau Blizzard


Non seulement les développeurs et les utilisateurs réguliers sont sensibles à une attaque comme la reliure DNS, mais aussi les joueurs. Ici, nous rencontrons à nouveau un problème de service JSON-RPC qui sort dans ce cas sur localhost sur le port 1120. Le service permet d'effectuer des mises à jour, de modifier les paramètres et d'autres options de maintenance diverses.


Dans ce cas, l'authentification est prise en charge, mais la transmettre en effectuant des requêtes depuis localhost n'est pas difficile:



En conséquence, vous pouvez réaliser quelque chose de similaire:



Plus de détails peuvent être trouvés ici .


Résumé de l'application de bureau:


  • un attaquant peut obtenir RCE sur le système principal (n'oubliez pas non plus VM Escape)
  • un attaquant pourrait accéder à des données sensibles, etc.

Les nuages


Eh bien, et enfin, la chose la plus intéressante reste - les nuages. L'essentiel est que les services cloud sont souvent utilisés pour héberger des logiciels qui analysent les utilisateurs qui viennent sur le site. Par exemple, en cliquant sur le lien de l'en-tête Referer avec un navigateur sans tête pour analyser la ressource à partir de laquelle le client est allé sur le site. Ce vecteur d'attaque peut également être utilisé, car en substance, un navigateur sans tête est un navigateur Web à part entière sans interface graphique, mais avec prise en charge de DOM, JS et tout le reste.


Revenons à nos béliers, que pouvons-nous faire dans ce cas? En effet, pour une attaque, il faut retarder l'utilisateur (dans ce cas, le bot) sur la page. Eh bien, pour cela, nous pouvons utiliser une image sur la page qui a une longueur de contenu de plus qu'elle ne l'est réellement. En conséquence, le bot pensera que l'image n'a pas encore été téléchargée et persistera sur notre page, puis nous utilisons notre technique de reliure DNS standard.


Par conséquent, puisque nous enverrons des demandes à partir d'un proxy, nous pouvons faire beaucoup de choses amusantes. Par exemple:


  • analyser le réseau interne
  • se connecter aux services internes (théoriquement)
  • voler les données d'autorisation d'autres services, etc.

Allons directement sur Amazon. AWS EC2 possède des fonctionnalités telles que le service de métadonnées d'instance. Il permet à toute entité EC2 d'utiliser l'API REST située au 169.254.169.254, qui révèle des informations sur l'instance.


Par exemple, voici une courte liste de services similaires pour différents clouds:



Voyons maintenant un cas dans lequel nous nous livrons à AWS.


Tout d'abord, laissez le bot faire une demande à l'API:



Dans la réponse, nous pouvons obtenir des informations confidentielles, par exemple, des crédits dans un script qui s'exécute au démarrage de la machine:



Ensuite, nous pouvons extraire le nom du nœud avec lequel nous continuerons à travailler:



Ensuite, nous ferons l'appel suivant par le nom déjà connu et - bingo!




Nous avons reçu diverses informations sur les utilisateurs, telles que AccessKeyId, SecretAccessKey, Token, etc.


Après avoir reçu ces données, nous pouvons les utiliser pour autorisation via le client de la console:



Le résultat total:


Soulignons les points faibles communs que nous avons remarqués lors de l'utilisation d'une attaque de reliure DNS:


  • API sans authentification
  • Services locaux sans authentification
  • Ignorer le paramètre Host à demander
  • Utiliser http au lieu de https

Ainsi, malgré divers arguments d'experts dans le domaine de la sécurité des informations pratiques, une attaque de ce type est née de nouveau à l'ère de l'IoT, des services cloud, des crypto-monnaies et ainsi de suite, même malgré la nécessité de retarder le client du côté de l'attaquant, car dans le monde des cinémas en ligne, l'hébergement vidéo et d'autres services qui fournissent du contenu à l'utilisateur, il n'est pas difficile de le faire. Par conséquent, soyez prudent lorsque vous voyagez dans le monde en ligne, lors de l'achat d'un autre assistant intelligent et lors du développement, bien sûr.


Sources:


Source: https://habr.com/ru/post/fr439522/


All Articles