Hello, je tente de poster au milieu de ce qui est pour moi une rentrée chargée...
Bien que ces dernières semaines, la mode soit au clickjacking, il un petit buzz s'est formé autour de l'annonce de vullnérabilités découvertes sur TCP.
Et ouais, pendant que ces messieurs du web 12.0 se déchirent sur la dangerosité d'afficher un boutton "Valider" qui en fait ne valide pas (il faudrait tout de même n'avoir aucune dignité personelle pour s'abaisser à faire de telles choses! Nos criminels ont de l'honneur...), et bien d'autres continuent d'étudier les protocoles percés sur lesquels Internet évolue.
Après DNS, c'est donc au tour de TCP d'y passer, selon les auteurs du puissant (mais moins cool que nmap hein!) scanner de port "unicorn scan", il est possible d'attaquer les implémentations actuelles de TCP, pour provoquer un déni de service. Sans dévoiler leur attaque, ils affirment que tous les services testés sont vulnérables, et qu'il n'existe aucun 'workaround" propre au problème. Chouette et rassurant non?
Fyodor, le grand gourou lumineux du monde des développeurs réseau (avec Alan Cox aussi...) a rapidement publié un article sur insecure.org, dans lequel il ralaît (à raison) contre cette pratique de petite starlette d'annoncer au monde la découverte de vulnérabilité, tout en attendant des semaines pour la révéler. Encore, avec l'histoire de Kaminsky, cela pouvait avoir un sens, étant donné que les entreprises bossaient sur un patch, autant là on frôle le ridicule vu que ce n'est pas le cas!
Par ailleurs Fyodor s'essaye à deviner l'attaque "secrète". Selon lui (confirmé par les auteurs), il s'agit d'une variante de l'attaque connue depuis 8 ans, qui consiste à ouvrir des tas de connections TCP via une raw socket, sans garder trace des connections ouvertes. Le serveur, lui, conserve tout cela en mémoire. Au bout d'un moment, on atteind des seuils en terme de fichiers ouverts, packets [ACK|FIN] envoyés et mémoire allouée et le déni de service se produit. Seule le reboot du serveur remet les choses en ordre. L'outil NAPHTA implémentait cette attaque (on était plutôt dans le proof of concept quand même...).
Résumé de l'attaque :
Avant tout, il faut configurer son firewall afin qu'il n'envoi pas de paquet [RST] à la réception de paquet [SYN|ACK].
Le client forge un paquet TCP SYN et l'envoi en direction du service visé.
(Seq = seq_client, Ack = 0)
====[ SYN ]===>
Et ouais, pendant que ces messieurs du web 12.0 se déchirent sur la dangerosité d'afficher un boutton "Valider" qui en fait ne valide pas (il faudrait tout de même n'avoir aucune dignité personelle pour s'abaisser à faire de telles choses! Nos criminels ont de l'honneur...), et bien d'autres continuent d'étudier les protocoles percés sur lesquels Internet évolue.
Après DNS, c'est donc au tour de TCP d'y passer, selon les auteurs du puissant (mais moins cool que nmap hein!) scanner de port "unicorn scan", il est possible d'attaquer les implémentations actuelles de TCP, pour provoquer un déni de service. Sans dévoiler leur attaque, ils affirment que tous les services testés sont vulnérables, et qu'il n'existe aucun 'workaround" propre au problème. Chouette et rassurant non?
Fyodor, le grand gourou lumineux du monde des développeurs réseau (avec Alan Cox aussi...) a rapidement publié un article sur insecure.org, dans lequel il ralaît (à raison) contre cette pratique de petite starlette d'annoncer au monde la découverte de vulnérabilité, tout en attendant des semaines pour la révéler. Encore, avec l'histoire de Kaminsky, cela pouvait avoir un sens, étant donné que les entreprises bossaient sur un patch, autant là on frôle le ridicule vu que ce n'est pas le cas!
Par ailleurs Fyodor s'essaye à deviner l'attaque "secrète". Selon lui (confirmé par les auteurs), il s'agit d'une variante de l'attaque connue depuis 8 ans, qui consiste à ouvrir des tas de connections TCP via une raw socket, sans garder trace des connections ouvertes. Le serveur, lui, conserve tout cela en mémoire. Au bout d'un moment, on atteind des seuils en terme de fichiers ouverts, packets [ACK|FIN] envoyés et mémoire allouée et le déni de service se produit. Seule le reboot du serveur remet les choses en ordre. L'outil NAPHTA implémentait cette attaque (on était plutôt dans le proof of concept quand même...).
Résumé de l'attaque :
Avant tout, il faut configurer son firewall afin qu'il n'envoi pas de paquet [RST] à la réception de paquet [SYN|ACK].
Le client forge un paquet TCP SYN et l'envoi en direction du service visé.
(Seq = seq_client, Ack = 0)
====[ SYN ]===>
Normalement le serveur renvoit un [SYN|ACK] avec un numéro de séquence que nous devons récupérer (IP spoofing à travailler sur un autre niveau qu'applicatif donc)
(Seq = seq_serveur, Ack = seq_client + 1)
<===[SYN|ACK]====
On capture ce paquet, et on en extrait le champ Seq afin de forger un paquet [ACK] afin de terminer l'ouverture de la connection.
(Seq = seq_client + 1, Ack = seq_serveur + 1)
====[ACK]===>
Ensuite si l'on désire augmenter la puissance de l'attaque, on peut envoyer une requête sur un gros fichier ou autre, histoire d'obliger le système cible à copier des buffers dans le kernel, et à nous envoyer des données pour lesquelles bien évidemment nous n'accuserons jamais réception!
Au bout d'une période d'inactivité, la cible va nous envoyer des [ACK|FIN] (souvent une petite dizaine).
Fyodor dit avoir écrit un outil du style, nommé ndos, et dont il fourni le help screen. Mais refuse de le releaser. Intrigué par cette attaque que je ne connaissais pas, je me suis donc attaqué à l'écriture de mon outil, reprenant les mêmes options. Je suis rapidement arrivé à un premier truc assez lent mais efficace. Inéluctablement, les cibles pliaient!!
Tellement efficace que j'ai voulu écrire une seconde version, plus rapide (schéma envoi/réception asynchrone). Cette version est en cours de développement. Je la publierais peut être, auquel cas ce sera ici même.
Ainsi, si Ronald avait vu juste au sujet de l'accroissement des menaces par requêtes non-autorisées, j'ai l'impression que le retour aux fondamentaux n'avait été annoncé nul part. Erf, autre chose, on peut sniffer le web en forgeant des paquets BGP foireux, et créer des faux passeports électroniques en trois lignes de commande.
Rien que ça?
ouep!
C'est beau le futur des fois...
