Aller au contenu

Que contient vraiment le keylogger de Windows 10 ?


Ldfa

Messages recommandés

(modifié le 2 septembre 2015 &agrave 11:04)

A force de lire tout et n'importe quoi à ce sujet, je me suis lancé dans mes propres analyses de trafic.

windows-keylogger

Voyons ce que contient ce Windows 10 qui fait tant parler de lui.

tcpdump

Avant tout j'en profite pour vous parler de ce super tutoriel pour lire du contenu HTTPS avec wireshark s'il provient de votre navigateur, simple et rapide. Dans mon cas ce n'est pas du flux venant d'un navigateur mais du système directement donc je ne pourrai pas utiliser cette méthode.

J'utilise Windows 10 sur une machine virtuelle (VirtualBox). J'ai donc commencé par analyser le trafic au moment de faire une recherche dans le menu démarrer. Je précise que j'ai désactiver la recherche en ligne dans les options de Windows, et pourtant il y a bien du trafic.

Voici ce que voit passer mon routeur tomato (passerelle de sortie) :

  • 192.168.0.68 = IP de ma machine Windows 10
  •  204.79.197.200 = a-0001.a-msedge.net

Et à chaque nouvelle recherche dans le menu démarrer on retrouve cette séquence.

Premièrement c'est une surprise car quand on se dit le trafic que ça doit pomper à l'échelle mondiale, c'est monumental.

Mais que transite dans ces paquets ?

Kali

Autant faire le barbu jusqu'au bout, j'ai donc sorti Kali! Cela évite d'avoir à installer une tonne d'outils qui sont déjà présents.

kali2-netconfig

J'ai utilisé une deuxième machine virtuelle, sous Kali Linux 2.0 cette fois-ci. Avec deux interfaces, une sur le réseau local (eth0) et une autre sur un réseau interne à VirtualBox (eth1) que j'ai nommé "guest" :

  • eth0 = 192.168.0.68 (dhcp via tomato, accès par pont)
  • eth1 = 10.1.1.254/24 (ip fixe, réseau interne "guest")

udhcpd

J'ai installé un serveur dhcp (pas obligatoire mais plus pratique) :

Configuration minimaliste :

Commenter la ligne /etc/default/udhcpd :

Et démarrer le service :

J'ai basculé ma VM Windows dans ce même réseau interne "guest" pour vérifier que Kali lui donnait bien une IP.

Certificats

Je pensais qu'il était nécessaire de générer un certificat pour pouvoir intercepter le trafic SSL, surtout que j'étais parti sur l'outil sslstrip au départ. Et puis cet outil n'allait pas il permet seulement de ne pas rediriger du HTTP vers du HTTPS mais il est incapable d'intercepter du HTTPS.

Je vous met quand même la procédure au cas où ça vous serve dans un cas particulier :

Seul le "common name" est important, il doit correspondre au site à intercepter. Dans l'exemple "*.bing.com" assure la compatibilité avec "www.bing.com" par exemple. Cela ne fonctionnera pas en revanche avec "bing.com" tout court, il faudra un sous domaine. Vous pouvez préciser plusieurs CN si vous utilisez un fichier de configuration.

On fusionne :

Récupérer ca.crt et importez le "autorité de certification racines de confiance > certificats" (windows + R > certmgr.msc). Cela fonctionnera pour Edge et IE, pour Firefox ça se passe dans

  • Outils > Options > Avancé > Certificats > Onglet "Autorités" : Importer

Si besoin consultez ce tutoriel complémentaire.

iptables, ouvres toi

On active le routage (les deux commandes fonctionnent) :

Puis on ajoute ces règles pour rediriger tout le trafic venant des ports 80 et 443 (HTTP et HTTPS) vers notre outil mitmproxy :

Cela va couper le trafic pour votre Windows 10.

mitmproxy

mitmproxy est présent dans Kali, c'est lui qui va relayer les requêtes web, comme un vulgaire proxy. Mais il vous permet au passage de voir ce qui transite.

Par défaut il écoute sur le port 8080 et il semblerait que le changer peut poser problème. Lançons-le :

Nous précisons au passage le certificat ca.pem, bien que je le répète ça fonctionne aussi sans dans notre cas car Microsoft ne contrôle pas l'auto-signature du certificat et n'utilise pas HSTS. En effet HSTS rend impossible toute interception si votre navigateur l'implémente :

hsts

Vous devriez maintenant pouvoir surfer depuis la VM sous Windows 10 et voir les premiers paquets transiter, faites ENTREE pour en visualiser un :

mitmproxy-response-bm

Dans la capture c'est du HTTP mais ça fonctionne aussi en HTTPS :)

Résultats

Je constate que l'IP 204.79.197.200 est attaquée en direct, autrement dit elle est hardcodée. Voilà qui explique pourquoi on pouvait lire sur la toile que Windows 10 ne tenait pas compte du fichier host. Il en tient donc bien compte, mais il ne sert à rien quand une IP est attaquée en directe.

La qualité de la capture n'est pas terrible, mon on voit que chaque recherche déclenche du trafic :

D'ailleurs selon comment vous lancez tcpdump ou wireshark c'est l'outil qui fait la résolution inverse (IP vers domaine), ce qui peut amener cette confusion. L'option "-n" ne résoud pas les IP.

Et voici le contenu d'une trame interceptée avec Kali :

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.