Les attaques du singe intercepteur
Denis Ducamp 12 février 2001
contre
SSH
et
HTTPS
Monkey In The Middle
(tm)
Dug Song
par Denis Ducamp
Denis.Ducamp@hsc.fr
Denis.Ducamp@groar.org
http://www.groar.org/ ducamp/
dsniff, la boite à outils
Dug Song
webmitm
sshmitm
dsniff
Les autres outils
Les bibliothèques
Pourquoi ça marche ?
Les signes d'une attaque
Comment se protéger ?
SSH / HTTPS
Ce qui ne marche pas contre sshmitm / webmitm
Conclusion
Références / Remerciements
une collection d'outils permettant :
d'auditer un réseau,
de réaliser des tests d'intrusion.
deux catégories d'outils :
écouter passivement le réseau
pour capturer des données intéressantes,
faciliter l'interception de trafic réseau
normalement non disponible à un attaquant.
de formidables outils pour :
éduquer les utilisateurs et les administrateurs
,
obtenir des budgets sécurité
:
montrez son mot de passe et son courrier électronique à votre patron
;-)
Mais surtout
n'abusez pas de ces outils !
même s'ils sont portables : *BSD, Linux, Solaris, Win32.
University of Michigan :
Center for Information Technology Integration
http://www.citi.umich.edu/
Hacker
Coordonnées personnelles :
dugsong@monkey.org
http://naughty.monkey.org/ dugsong/
Autres projets :
Check Point FireWall-1 vulnerabilities
Patches :
popa3d : APOP / Kerberos v4
John the Ripper : S/Key / Kerberos v4 TGT
SSH : AFS / Kerberos v4
OpenBSD ports and audits
OpenSSH
fragrouter
The Honeynet Project
relaye et enregistre le trafic SSH redirigé par dnsspoof
capture les mots de passe d'accès SSH
détourne les sessions interactives
seule la version 1 du protocole est supportée
et celle-ci sera toujours la seule à être supportée,
ce programme est déjà trop maléfique.
relaye de façon transparente et enregistre :
le trafic HTTP/HTTPS redirigé par dnsspoof,
capture :
les accès webmail :
les soumissions de formulaires :
numéros de cartes bleues, etc.
même les plus "sécurisés" par chiffrement SSL !
nécessite que le client soit compatible HTTP/1.1 :
émission de la commande Host: dans l'entête HTTP.
permet de capturer les mots de passe voyageant en clair,
ou de façon brouillée !!!
supporte plus de 30 protocoles normalisés / propriétaires :
FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase et Microsoft SQL.
points forts :
réassemblage complet des sessions TCP/IP,
support des routes asymétriques,
détection auto-magique du protocole applicatif,
sauvegarde dans une base Berkeley DB,
HTTP : analyse de QUERY_STRING et x-www-form-urlencoded.
arpspoof, dnsspoof, macof :
permettent l'interception de trafic réseau.
filesnarf, mailsnarf, msgsnarf, urlsnarf, webspy :
capture des informations intéressantes :
fichiers transférés par NFS v2/v3 en UDP/TCP
attention à vos clés privées,
messages transférés par POP/SMTP, IRC/ICQ/AOL/MSN/Yahoo,
URL visitées :
dans un journal au format CLF,
en live dans Netscape.
tcpkill, tcpnice :
facilitent la capture de données.
Les bibliothèques nécessaires sont nombreuses :
libpcap - ftp://ftp.ee.lbl.gov/
capture et filtrage des paquets sur le réseau
libnet - http://www.packetfactory.net/libnet/
génération de paquets sur le réseau
libnids - http://www.packetfactory.net/libnids/
réassemblage de paquets et de sessions
libdb - http://www.sleepycat.com/ (for non-BSD/Linux systems)
enregistrement unique des authentifications dans une base de données
ce qui permet de limiter les abus :)
mais un package RPM est disponible :(
La cryptographie de HTTPS et SSH est basée sur
la cryptographie à clés publiques
HTTPS y ajoute la confiance des certificats à clés publiques
L'utilisation de ces méthodes est fortement contraignante :
pour être plus acceptable, des modes dégradés sont disponibles
le client peut accepter "aveuglément" la clé du serveur
le client peut accepter que le serveur puisse avoir changé de clé
sshmitm et webmitm utilisent ces vulnérabilités ainsi introduites
la clé de session est générée par le client
puis envoyée chiffrée avec la clé publique du serveur qu'il vient de recevoir
l'attaquant n'a qu'à utiliser n'importe quelle paire de clés publique / privée
et attendre que le client accepte d'utiliser cette clé publique.
authentification client par mot de passe :
envoyé en "clair" dans le tunnel chiffré
authentification client par RSA :
le serveur envoie au client un challenge chiffré avec une clé publique autorisée
le client prouve qu'il connait la clé privée en déchiffrant le challenge
sshmitm impose l'authentification par mot de passe dans sshv1.
la clé de session est générée par le protocole de Diffie-Hellman :
le serveur s'authentifie en signant une empreinte des messages échangés
l'authentification client utilise les mêmes méthodes que sshv1
l'attaque est toujours possible par attaque de l'intercepteur sur le protocole DH
sshmitm ne met pas en oeuvre sshv2
La clé du serveur est accompagnée d'un certificat :
ce certificat peut être signé par une autorité "reconnue",
le navigateur n'accepte le certificat que s'il est destiné au site visité,
mais l'utilisateur peut l'accepter.
ce certificat peut être signé par une autorité "inconnue",
le navigateur n'accepte pas l'autorité,
mais l'utilisateur peut l'accepter.
Les signes de l'attaque sont parfaitement visibles dans tous les cas :
SSH
HTTPS
le certificat est destiné à un autre serveur
le certificat est signé par une autorité non reconnue
$ ssh -p 2222 groar
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Please contact your system administrator.
Add correct host key in /home/ducamp/.ssh/known_hosts to get rid of this message.
Avec un client OpenSSH :
Password authentication is disabled to avoid trojan horses.
Permission denied.
Avec un client SSH :
Agent forwarding is disabled to avoid attacks by corrupted servers.
X11 forwarding is disabled to avoid attacks by corrupted servers.
Are you sure you want to continue connecting (yes/no)? yes
ducamp@groar's password:
Mauvais certificat
le certificat ne correspond pas au nom du domaine demandé,
ce certificat peut avoir été signé par une autorité reconnue.
Autorité non reconnue
le certificat a été signé par une autorité non reconnue,
ce certificat peut correspondre au nom du domaine demandé.
Ce certificat a été obtenu en accédant à www.groar.org ...
... alors qu'il a été généré pour sos.groar.org
Le certificat n'est pas signé par une autorité reconnue...
...et les risques de supercherie sont indiqués par Netscape.
Ne pas utiliser les modes dégradés
toujours connaître la clé de son interlocuteur au préalable
vérifier systématiquement la clé de son interlocuteur
arrêter immédiatement la connexion en cas d'anomalie
Attention :
de nombreuses recommandations
ne sont pas sérieuses
!!!
sauf pour les lecteurs de slashdot, une citation de Dug Song :
argh! it's amazing how silly some people are. Slashdot readers are especially numb-skulled, if their insistence that SSH2 would prevent such attacks is any indication.
i'll add compression support when i get a free second.
Avant la première connexion le client doit :
récupérer la clé publique du serveur
éventuellement faire déposer sa clé publique sur le serveur
A chaque connexion le client doit toujours :
forcer une vérification stricte de la clé du serveur
condition sine qua non à une authentification par mot de passe
hoax #1 : utiliser ssh v2
aujourd'hui
seul le protocole v1 a été mis en oeuvre
dans le cas d'une
authentification par mot de passe
:
ssh v2 est
tout aussi vulnérable
que ssh v1
des versions privées ont été / seront mises au point
hoax #2 : utiliser la compression dans ssh
aujourd'hui
la compression n'a pas encore été mise en oeuvre
ce qui peut empêcher l'attaquant de visualiser la session et de la contourner
mais pas de récupérer le mot de passe
des versions privées ont été / seront mises au point
Une autorité n'est connue qu'à une seule et unique condition :
la clé publique de l'autorité doit être entrée dans le navigateur.
Ne pas accepter les clés signées par une autorité connue,
si la clé n'est pas destinée au site visité.
Ne pas accepter les clés signées par une autorité inconnue,
même si la clé est destinée au site visité.
même si le nom de l'autorité correspond à une autorité connue.
hoax #3 : utiliser de vieux navigateurs sans la commande Host:
aujourd'hui
les fonctionnalités nécessaires n'ont pas encore été mises en oeuvre
ceci réclame du code spécifique à chaque plate-forme
des versions privées ont été / seront mises au point
Le principal problème est l'éducation des utilisateurs :
les signes de l'attaque sont visibles,
mais leurs conséquences sont ignorées.
Doit suivre la mise en place d'une organisation permettant :
la distribution des clés publiques
des serveurs auprès des utilisateurs
un serveur web avec signature des clés publiques
des utilisateurs sur les serveurs accédés
une liste électronique permettant le dépôt de clés
Merci à Dug Song pour le travail réalisé
et pour la prise de conscience que ses outils permettent.
Merci à Ghislaine Labouret pour la relecture
:)
Site original :
http://naughty.monkey.org/ dugsong/dsniff/
FAQ (Foire Aux Questions) :
http://naughty.monkey.org/ dugsong/dsniff/faq.html
Mailing liste :
echo subscribe | mail dsniff-request@monkey.org
Traduction française
des manuels et de la FAQ (Foire Aux Questions) :
http://www.groar.org/ ducamp/#sec-trad
Vous pouvez poser vos questions...
et faire connaître vos remarques...
puis réveiller discrètement ceux qui dorment ;-)
Bye, bye...
(c) 02/2001 Denis de service
:)
[tm]
