Impossible de rétrograder https vers http via sslstrip, arpspoof
J'ai suivi ce guide: https://www.cybrary.it/0p3n/using-sslstrip-in-kali-linux/ et d'autres aussi, ex: officiel Sslstrip one: https://moxie.org/software/sslstrip/ sans succès.
J'utilise:
5.2.0-kali2-AMD64 #1 SMP Debian 5.2.9-2kali1 (2019-08-22) x86_64 GNU/Linux
sslstrip 0.9 by Moxie Marlinspike
et arpspoof.
Je cours en premier:
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port 8080
Puis usurpation d'arp:
arpspoof -i <interface> -t <targetIP> -r <gatewayIP>
Puis sslstrip:
sslstrip -w testfile.txt -l 8080
Ensuite, je vais sur ma machine cible, l'iPhone exécutant le navigateur Safari. Je supprime tous les cache et temp. Je navigue vers des sites Web préchargés non HSTS (linkedin.com, zsecurity.org). Je ne spécifie pas https: //, mais simplement le nom de domaine (ex: linkedin.com). Ils se chargent toujours en https.
J'ai testé cela plusieurs fois sur un autre client exécutant Windows et Internet Explorer. Même résultat, je ne peux pas forcer la cible à http.
Le fichier testsfile.txt de sslstrip est vide. Je m'attendais à ce que le client ouvre des pages Web http.
Qu'est-ce que je fais mal?
Tout d'abord: ce que fait sslstrip, c'est qu'il remplace https - les liens par non-https - les liens sur les sites Web non-https- détournés. Par exemple. lorsque la victime visite un moteur de recherche http uniquement via un wifi public non sécurisé, l'attaquant peut utiliser sslstrip pour remplacer les liens https dans les résultats du moteur de recherche par des liens http uniquement.
Je suppose que les sites Web que vous ciblez (par exemple, linkedin) redirigent toujours vers https, indépendamment de ce que la victime a tenté d'ouvrir. Et ne permettra pas les connexions http en premier lieu.
Et enfin et surtout, comme d'autres déjà mentionnés dans les commentaires, les sites Web cibles définissent très probablement un en-tête de sécurité de transport strict dans la première réponse (ou même une réponse OPTIONS, qui peut être facilement ignorée), ce qui empêchera le navigateur d'autoriser les connexions http uniquement.
Je pense que la suppression du cache et de tmp ne devrait pas être suffisante pour supprimer les entrées HSTS. Pour le navigateur safari, par ex. il y a le fichier "~/Library/Cookies/HSTS.plist" où HSTS est sauvegardé. Vous devrez supprimer ce fichier lors des tests à partir d'un bureau.