feed.xml

<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.6.1">Jekyll</generator><link href="http://lsdsecdaemon.com/feed.xml" rel="self" type="application/atom+xml" /><link href="http://lsdsecdaemon.com/" rel="alternate" type="text/html" /><updated>2018-04-17T09:56:54+02:00</updated><id>http://lsdsecdaemon.com/</id><title type="html">Lsd Security Daemon</title><subtitle>LsdSecDaemon : Blog axé sur la sécurité, mais pas que.</subtitle><entry><title type="html">Highway to serv</title><link href="http://lsdsecdaemon.com/highway-to-serv" rel="alternate" type="text/html" title="Highway to serv" /><published>2018-04-14T18:00:00+02:00</published><updated>2018-04-14T18:00:00+02:00</updated><id>http://lsdsecdaemon.com/chacun-sa-route</id><content type="html" xml:base="http://lsdsecdaemon.com/highway-to-serv">&lt;p&gt;Je fais une pause dans mes pérégrinations sans fil -principalement parce que je suis pas assez doué pour trouver les infos dont j’ai besoin- et je profite d’un peu de temps libre pour parler réseau.&lt;/p&gt;

&lt;p&gt;Comme vous êtes tous nuls dans ce domaine, on va reprendre les bases, et parler d’un des outils les plus connus dans le troubleshoot réseau : traceroute.&lt;/p&gt;

&lt;p&gt;Alors, pourquoi je vais parler de ça ?&lt;br /&gt;
Tout est parti d’une discussion au boulot dans laquelle je disais “Vous ne connaissez pas le secret de traceroute”. Au final, non, ils ne le connaissaient pas. Et je parie que vous non plus. C’est pour ça que j’ai eu envie d’écrire ce petit post.&lt;/p&gt;

&lt;p&gt;C’est parti !&lt;/p&gt;

&lt;!--more--&gt;

&lt;h3 id=&quot;la-théorie&quot;&gt;La théorie&lt;/h3&gt;

&lt;p&gt;Spoiler alert : je vais prendre tout le monde pour des idiots et partir from scratch. Ceux qui veulent esquiver les explications générales, vous pouvez passer au chapitre suivant.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“Bon, traceroute, ça a l’air cool comme nom, mais ça sert à quoi ?”&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;En quelques mots, c’est un “GPS pour IP”. Ca permet de… tracer sa route en fait :)&lt;br /&gt;
L’utilité principale d’un traceroute, c’est de connaitre les équipements intermédiaires entre une machine source et une destination donnée. Par exemple, si je veux savoir le chemin qui me sépare de 8.8.8.8, je vais faire un bête :&lt;/p&gt;

&lt;div class=&quot;highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  praha-4d-c1-vl55.masterinter.net (77.93.199.253)  0.734 ms  0.805 ms  0.896 ms
 2  vl1387.cr3.r1-8.dc1.4d.prg.masterinter.net (83.167.254.150)  0.213 ms  0.226 ms  0.216 ms
 3  72.14.214.168 (72.14.214.168)  0.364 ms  0.366 ms  0.394 ms
 4  108.170.245.33 (108.170.245.33)  0.273 ms  0.275 ms  0.273 ms
 5  216.239.43.73 (216.239.43.73)  0.298 ms 108.170.237.177 (108.170.237.177)  0.298 ms 216.239.62.183 (216.239.62.183)  1.239 ms
 6  google-public-dns-a.google.com (8.8.8.8)  0.188 ms *  0.244 ms
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Si on regarde un peu plus précisément, on voit que je passe par les machines 77.93.199.253, puis par la 83.167.254.150, etc, pour arriver à la fin à la 8.8.8.8.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“OK, c’est cool, mais je m’en fous de ça moi, ça me sert à rien”&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Bah oui, mais non jeune impertinent ! Laisse moi te montrer pourquoi tu es dans l’erreur.
Imaginons un premier cas : tu n’as pas accès aux internets du web. Tu as rebooté ta box, mais rien n’y fait, ça ne fonctionne toujours pas. Et bien, un des tests à effectuer, c’est un traceroute, car ça te permettra de savoir où ça bloque.&lt;br /&gt;
En lancant la commande, tu pourras par exemple avoir ce retour :&lt;/p&gt;
&lt;div class=&quot;highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
connect: Le réseau n'est pas accessible
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;L’erreur est ici assez explicite, tu n’as pas accès au réseau. Peut-être as-tu oublié de brancher ton câble wifi ? Peut-être que ton DHCP ne te renvoie pas d’IP ? Peut-être que tu n’as pas de passerelle ? Dans tous les cas, tu n’iras pas loin et ton FAI n’y est pour rien.&lt;/p&gt;

&lt;p&gt;Tu pourras aussi avoir cet exemple :&lt;/p&gt;

&lt;div class=&quot;highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.103 (192.168.1.103)  163.938 ms !H  163.824 ms !H  163.759 ms !H

&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Là, tu as bien accès au réseau car tu as une IP (la 192.168.1.103), mais tu ne vas pas plus loin. Un problème de passerelle à coup sûr.&lt;/p&gt;

&lt;p&gt;Bref, cela te permet de voir d’où vient le souci.&lt;/p&gt;

&lt;p&gt;Imaginons maintenant un second cas. Tu es un expert du pentest, et tu dois péter le réseau interne d’un client. En faisant un traceroute depuis le lan user, tu sauras les équipements intermédiaires, et tu pourras ainsi tenter des attaques sur ces équipements, et aussi connaitre les autres réseaux du lan, et tenter de faire du nmap dessus.&lt;/p&gt;

&lt;p&gt;Tu vois, jeune impertinent, que traceroute, c’est plutôt pratique. Maintenant, tu n’es plus dans l’erreur.&lt;/p&gt;

&lt;h3 id=&quot;le-fonctionnement-technique&quot;&gt;Le fonctionnement technique&lt;/h3&gt;

&lt;p&gt;&lt;strong&gt;“Bon, ok, ça peut être marrant ton truc, mais comment ça fonctionne ?”&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Ahhhh, c’est là qu’on va arriver dans le vif du sujet. Et c’est là que vous allez apprendre un truc ou deux.&lt;/p&gt;

&lt;p&gt;Pour comprendre le fonctionnement technique, il faut se pencher un peu sur la RFC IPv4. Ne vous inquiétez pas, elle est pas méchante comparée aux spec 802.11 ^^’&lt;br /&gt;
Comme tout protocole, IP est normé et doit suivre un format spécifique qui est le suivant :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/traceroute/ip.png&quot; alt=&quot;En-tête IP&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Je vais expliquer rapidement tous les champs, et je m’attarderai ensuite sur le plus important par rapport au traceroute.&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Version : indique la version du protocole. Ici, comme on est en IPv4, c’est “4”. Seems legit.&lt;/li&gt;
  &lt;li&gt;IHL : Internet Header Length : la taille de l’en-tête IP, qui ne comprend donc pas la taille du payload des couches OSI supérieures.&lt;/li&gt;
  &lt;li&gt;TOS : Type Of Service : permet de définir si un paquet doit être priorisé ou non. C’est de la QoS version light.&lt;/li&gt;
  &lt;li&gt;Total length : taille du datagramme, qui correspond à l’IHL + le payload. Attention, on ne compte pas les couches inférieures (la partie MAC par exemple). En général, je dis toujours paquet, peu importe la couche, mais là, j’ai bien utilisé le terme datagramme car la différence est importante. (un paquet, c’est totalité des couches, le datagramme non).&lt;/li&gt;
  &lt;li&gt;Identification : un ID quoi :)&lt;/li&gt;
  &lt;li&gt;Flags : Permet de savoir si le message envoyé est fragmenté en plusieurs paquets.&lt;/li&gt;
  &lt;li&gt;Fragment offset : permet de savoir à quelle partie du fragment d’un message correspond ce paquet. Evidemment, ça dépend du flag.&lt;/li&gt;
  &lt;li&gt;TTL : Time To Live : Temps avant que le paquet ne soit considéré comme périmé.&lt;/li&gt;
  &lt;li&gt;Protocole : indique le protocole de la couche supérieure (TCP, UDP, etc).&lt;/li&gt;
  &lt;li&gt;Header Checksum : un bête checksum pour valider que l’en-tête IP n’aie pas été corrompu durant le transport.&lt;/li&gt;
  &lt;li&gt;Source/Destination addresses : Les IP source et destination.&lt;/li&gt;
  &lt;li&gt;Options : bahhhh, des options quoi ^^ Ca permet d’ajouter des infos sur l’en-tête IP au besoin.&lt;/li&gt;
  &lt;li&gt;Padding : un paquet de 0 à la fin de l’en-tête IP, afin qu’il soit un multiple de 32.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Peut-être que je ferais un article plus poussé sur IP un jour. Ou peut-être pas. En tout cas, vous voyez un peu l’idée du truc.&lt;br /&gt;
Mais revenons à nos moutons : le champ qui nous intéresse réellement ici est le TTL, et je vais donc expliquer plus précisément son fonctionnement.&lt;br /&gt;
C’est un champ codé sur 8 bits, qui peut donc aller de 0 à 255. Lorsque ma bécane envoie un paquet IP (soit la très grande majorité des paquets), mon OS va mettre le champ TTL à une valeur donnée (ça dépend de l’OS, du kernel et du temps qu’il fait dehors), mais il ne faut pas qu’il soit trop petit, sous peine que le paquet n’arrive jamais à destination.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“Comment ça, ‘n’arrive jamais à destination’ ?”&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Tu n’écoutes rien jeune impudent. J’ai dit quoi sur le TTL ? Hein ? J’ai dit quoi ? Que c’est le “temps avant que le paquet ne soit considéré comme périmé”. Avec un TTL trop court, ton paquet paquet sera bon pour la poubelle avant d’arriver à bon port.&lt;br /&gt;
A chaque machine intermédiaire, le TTL va être décrémenté d’un. Pour être plus précis, il va être décrémenté d’autant de secondes qu’il reste sur cette machine intérmédiaire. Mais dans la pratique, c’est toujours inférieur à la seconde, donc on réduit d’une seule unité.&lt;br /&gt;
Attention, quand je dit “machine intermédiaire”, ce ne sont pas TOUTES les machines intermédiaires. Ce sont toutes les machines intérmédiaires qui LISENT l’en-tête IP. Un switch par exemple, il s’en cogne de cet en-tête, puisqu’il s’arrête à la couche d’en dessous. Ainsi, on considère que les machines intermédiaires sont celles qui connectent des réseaux entre eux : les routeurs (ou assimilé).
Pour info, le TTL a été mis en place pour éviter d’avoir des paquets qui tournent en boucle à l’infini.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“‘Qui tournent en boucle’ ?”&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Exactement. Tu peux avoir des cas où un paquet est envoyé par un routeur A vers un routeur B et ledit routeur B le renvoie au routeur A. Si le TTL n’existait pas, les deux équipements se renverraient en permanence la balle (Qui à dit DoS ? :D )&lt;br /&gt;
Du coup, quand le TTL arrive à 0, il est tout simplement envoyé au cimetière des paquets (RIP).&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“Ouais ouais, c’est cool ton histoire là, mais il est où le rapport ?”&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Le rapport ? Et bien comme les routeurs sont gentils, ils nous préviennent quand un paquet est droppé à cause du TTL, grâce à un paquet ICMP, de &lt;a href=&quot;https://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol#Type_11_(temps_d%C3%A9pass%C3%A9)&quot; target=&quot;_blank&quot;&gt;type 11 et de code 0&lt;/a&gt;. (Pour ceux qui ne connaissent pas trop ICMP, les types sont grosso modo l’équivalent des ports TCP ou UDP).&lt;/p&gt;

&lt;p&gt;Tu commences à voir le rapport, jeune éffronté ?&lt;br /&gt;
Imagine que j’envoie un paquet avec un TTL de 1. Quand il va arriver au premier équipement, le champ va être décrémenté. Il tombe donc à 0, le routeur va dropper le paquet et me prévenir via un ICMP/11/0 qu’il a exterminé le paquet. Comme ça, je connais la première machine intermédiaire.&lt;br /&gt;
Imagine ensuite que j’envoie un second paquet, avec un TTL de 2. Arrivé au premier équipement, le TTL passe à 1, puis est renvoyé ver le routeur suivant. Encore une fois le TTL est décrémenté et tombe à 0. Le second routeur va donc anihiler le paquet puis me prévenir.&lt;/p&gt;

&lt;p&gt;Ainsi en envoyant plusieurs paquets avec un TTL de plus en plus grand, on peut retrouver le chemin complet vers une machine.&lt;/p&gt;

&lt;p&gt;Au passage, suite à l’écriture de cet article, on m’a demandé pourquoi on pouvait voir des étoiles dans certains retours traceroute, dans ce genre là :&lt;/p&gt;

&lt;div class=&quot;highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;traceroute -n poul.pe
traceroute to poul.pe (91.121.196.223), 30 hops max, 60 byte packets
 1  192.168.1.1  2.191 ms  2.239 ms  2.390 ms
[...]
 8  94.23.122.146  53.839 ms  88.330 ms  88.112 ms
 9  * * *
10  94.23.122.73  87.063 ms  87.058 ms  88.317 ms
11  * * *
12  * * *

&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;En fait, c’est tout à fait logique. Si on regarde le détail de la &lt;a href=&quot;https://tools.ietf.org/html/rfc792&quot;&gt;RFC 792&lt;/a&gt;, on voit ceci : “&lt;em&gt;If the gateway processing a datagram finds the time to live field is zero it must discard the datagram.  The gateway may also notify the source host via the time exceeded message.&lt;/em&gt;”. Donc, les routeurs ne sont pas dans l’obligation de nous prévenir. Dans ce cas, traceroute sait qu’il y a un équipement, mais ne peut pas trouver son IP, puisque l’équipement ne répond rien. La même situation peut se produire si un firewall bloque le traceroute.&lt;/p&gt;

&lt;h3 id=&quot;les-outils&quot;&gt;Les outils&lt;/h3&gt;

&lt;p&gt;Sur windows, c’est simple, on a tracert, épicétou.&lt;br /&gt;
Sur linux par contre, on a traceroute et tracepath. Et c’est en partie pour cela que je me suis mis à écrire cet article : c’est quoi la différence entre les 2 ?!&lt;/p&gt;

&lt;p&gt;En fait, traceroute peut avoir besoin d’ouvrir des raw sockets. Et les raw sockets, en général, ça a besoin des droits root. A l’inverse, tracepath n’ouvre pas ses sockets en raw, donc pas besoin du root :)&lt;br /&gt;
A coté de ça, en regardant les sources et les man, on voit 2 choses : traceroute a clairement plus d’options que tracepath, mais ce dernier vérifie (et modifie au besoin) la MTU (Maximum Transmission Unit, la taille maximum qu’un paquet peut avoir). Pratique quand on passe sur de l’IPSEC ou du MPLS.&lt;/p&gt;

&lt;p&gt;Sinon, bahhhh, ça va pas beaucoup plus loin en fait au niveau différences. ^^’
C’est un peu décevant, je vois pas trop l’intéret d’avoir deux outils quasiment identiques (surtout qu’ils sont tous les deux installés par défaut dans certaines distros).&lt;/p&gt;

&lt;p&gt;Au passage, s’il y a une option à connaitre sur ces outils, c’es le “-n” (“-d” sur windows) qui évite de faire une résolution DNS inverse sur les IP trouvées. Parce qu’honnêtement, je n’ai jamais eu besoin des NDD associées aux IP pendant un traceroute.&lt;/p&gt;

&lt;h3 id=&quot;le-secret-de-traceroute-&quot;&gt;Le secret de traceroute :)&lt;/h3&gt;

&lt;p&gt;Au début du post, j’ai parlé d’un secret, et puis plus j’ai avancé dans l’article, plus je me suis rendu compte qu’il était quasiment inutile ^^’
Quand on fait un traceroute, à moins de s’y intéresser vraiment, on sait pas trop comment ça fonctionne &lt;em&gt;under the hood&lt;/em&gt;. On sait que ça utilise le TTL, mais c’est tout.&lt;br /&gt;
Ce qu’il faut prendre en compte, c’est que le protocole IP a besoin pour fonctionner du champ Protocol (qui, pour rappel, définit le proto de niveau supérieur). Ce champ est donc un ID qui renvoie à une &lt;a href=&quot;https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml&quot;&gt;liste définie par l’IANA&lt;/a&gt;.
Et bah, le secret, c’est que sur windows, ça utilise de l’ICMP (ID 1) et sur linux de l’UDP (ID 17) :D&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“Quoi, c’est tout ? C’est juste ça ton secret ?”&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Bah oui ^^’
Et le truc dans l’histoire, c’est qu’avant d’écrire cet article, je trouvais ça marrant, mais au final, c’est totalement inutile puisqu’on se sert d’un champ du proto IP pour cet outil, donc au final, peu importe la couche supérieure, ça ne change absolument rien (en fait si, les firewalls auraient fait la gueule avec des trucs exotiques).&lt;/p&gt;

&lt;p&gt;J’ai cherché une explication plus détaillée sur le fait d’utiliser ICMP sur win et UDP sur nux, mais je n’ai trouvé de solution qui me plaise.&lt;br /&gt;
L’idée la plus probable, c’est que comme nux a besoin d’être root pour envoyer des paquets ICMP (si, si, promis, regardez le setuid de la commande ping :) ), les devs de traceroute ont utilisé de l’UDP pour éviter d’avoir à setuid le programme. Mais bon, c’est un peu naze comme explication, puisqu’il existe une option pour faire un traceroute avec de l’ICMP (d’où les raw sockets dont je parlais plus haut.), et donc, faut avoir les droits root. De plus, ping est setuid, donc bon, les mecs de chez linux auraient très bien setuid traceroute aussi.&lt;/p&gt;

&lt;h3 id=&quot;conclusion&quot;&gt;Conclusion&lt;/h3&gt;

&lt;p&gt;Voilà, petit article rapide, qui permet de comprendre un peu ce qu’est traceroute et son intérêt. J’espère qu’il vous aura fait prendre que le réseau cétrocoul et que vous voulez tous devenir ingé réseau maintenant :D&lt;br /&gt;
Plus sérieusement, si vous avez appris quelque chose, c’est le plus important ;)&lt;/p&gt;

&lt;p&gt;Oh, et si jamais quelqu’un sait réellement pourquoi UDP par défaut sur nux, qu’il n’hésite pas à me le dire !&lt;/p&gt;

&lt;p&gt;Enjoy&lt;/p&gt;

&lt;p&gt;The lsd&lt;/p&gt;

&lt;h3 id=&quot;liens&quot;&gt;Liens&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/Th3l5D/lame-socket-dispatcher&quot;&gt;Lame-Socket-Dispatcher&lt;/a&gt; : un script en python pour faire un traceroute. C’est un POC, rien de plus.&lt;/p&gt;</content><author><name></name></author><summary type="html">Je fais une pause dans mes pérégrinations sans fil -principalement parce que je suis pas assez doué pour trouver les infos dont j’ai besoin- et je profite d’un peu de temps libre pour parler réseau. Comme vous êtes tous nuls dans ce domaine, on va reprendre les bases, et parler d’un des outils les plus connus dans le troubleshoot réseau : traceroute. Alors, pourquoi je vais parler de ça ? Tout est parti d’une discussion au boulot dans laquelle je disais “Vous ne connaissez pas le secret de traceroute”. Au final, non, ils ne le connaissaient pas. Et je parie que vous non plus. C’est pour ça que j’ai eu envie d’écrire ce petit post. C’est parti !</summary></entry><entry><title type="html">Le Wifi, comment ça marche 2/2</title><link href="http://lsdsecdaemon.com/wifi-connection-2" rel="alternate" type="text/html" title="Le Wifi, comment ça marche 2/2" /><published>2018-02-14T19:00:00+01:00</published><updated>2018-02-14T19:00:00+01:00</updated><id>http://lsdsecdaemon.com/Wifi-comment-ca-marche2</id><content type="html" xml:base="http://lsdsecdaemon.com/wifi-connection-2">&lt;p&gt;Dans la &lt;a href=&quot;http://lsdsecdaemon.com/wifi-connection&quot; target=&quot;_blank&quot;&gt;première partie&lt;/a&gt;, on va vu comment fonctionnait les probes, et l’authentification, mais il reste encore deux ou trois trucs à comprendre avant de pouvoir surfer tranquillement sur google.&lt;br /&gt;
LET’S GO !&lt;/p&gt;

&lt;!--more--&gt;

&lt;h3 id=&quot;association&quot;&gt;Association&lt;/h3&gt;

&lt;p&gt;Admettons que tout ce soit bien passé jusqu’à maintenant. Il reste encore une étape obligatoire afin que mon laptop puisse enfin se connecter au reste du réseau, c’est l’association. Jusqu’à maintenant, nous avions découvert les AP via les &lt;em&gt;probes&lt;/em&gt;, puis nous avons validé qu’on pouvait s’y connecter avec l’authentification. Du coup, il ne rest plus qu’à finaliser la connexion, via un échange de requête/réponse du type Association.&lt;br /&gt;
La première question qui m’est venue en tête en lisant les docs a été “Pourquoi faire ?!”. Je veux dire, l’AP et la station sont potes maintenant, ils se sont dit des formalités, se sont serrés la pince et tout, donc où est l’intéret ?&lt;br /&gt;
Et bien en fait, tout simplement pour échanger des informations supplémentaires. Dans ces infos, on retrouve par exemple le SSID du wifi, le BSS (Basic Service Set), etc. Il sert également à transmettre l’AID (Association ID) qui est l’équivalent d’une prise réseau dans une architecture câblé (une borne, ça ne sera jamais qu’un switch, donc elle a besoin d’une “prise” sur laquelle le client se branchera).&lt;br /&gt;
Bon maintenant, vous êtes habitués aux trames, donc on va pas y aller par quatres chemins. Le &lt;em&gt;supplicant&lt;/em&gt; envoie le premier message, et l’AP la réponse associée :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/association_request.png&quot; alt=&quot;Association request&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/association_request_wireshark.png&quot; alt=&quot;Association request wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Les paramètres importants de la requête d’association envoyée par la station sont :&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;Le &lt;strong&gt;&lt;em&gt;Frame Control&lt;/em&gt;&lt;/strong&gt; positionné à 0x0000&lt;/li&gt;
  &lt;li&gt;Les &lt;strong&gt;&lt;em&gt;capabilities&lt;/em&gt;&lt;/strong&gt;, définissant les capacités demandées par l’AP lors du &lt;em&gt;probe response&lt;/em&gt; et utilisables par la station. Enfin je crois.&lt;/li&gt;
  &lt;li&gt;Le &lt;strong&gt;&lt;em&gt;Listen Interval&lt;/em&gt;&lt;/strong&gt;, qui donne à quelle intervalle de temps le supplicant écoutera les frames de type Beacons, si le Power Save Mode est activé&lt;/li&gt;
  &lt;li&gt;Une foultitude de paramèters taggués, dépendants d’options diverses et variées&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/association_response.png&quot; alt=&quot;Association response&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/association_response_wireshark.png&quot; alt=&quot;Association response wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Sur le même principe, la réponse émise par l’AP sont :&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;Le &lt;strong&gt;&lt;em&gt;Frame Control&lt;/em&gt;&lt;/strong&gt; mis à 0x0001&lt;/li&gt;
  &lt;li&gt;Les &lt;strong&gt;&lt;em&gt;capabilities&lt;/em&gt;&lt;/strong&gt;, qui valide ce qui a été envoyé par le client.&lt;/li&gt;
  &lt;li&gt;Le &lt;strong&gt;&lt;em&gt;Status Code&lt;/em&gt;&lt;/strong&gt;, mis à 0x0000 si l’association s’est déroulée correctement et que les &lt;em&gt;capabilities&lt;/em&gt; sont correctes&lt;/li&gt;
  &lt;li&gt;L’&lt;strong&gt;&lt;em&gt;Association ID&lt;/em&gt;&lt;/strong&gt;, qui est bahhhh… un ID quoi ^^&lt;/li&gt;
  &lt;li&gt;Et encore une fois plusieurs paramètres optionnels&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Je ne détaille pas les différentes capabilities, ni les paramètres taggués, déjà parce que je voulais faire un article, pas réécrire toute la doc, et ensuite parce que ça fait intervenir des notions dont je n’ai pas parlé, et qui ne font pas partie du process de connexion.&lt;/p&gt;

&lt;p&gt;Bref, une fois que la réponse a été reçue par la machine, on peut considérer que CA Y EST ! ENFIN, on est connecté au wifi !&lt;/p&gt;

&lt;h3 id=&quot;wpa-et-wpa2&quot;&gt;WPA et WPA2&lt;/h3&gt;

&lt;p&gt;Ca y est ? On est connecté ? Vraiment ? Well… Pas tout à fait en fait :D&lt;br /&gt;
Et oui, souviens toi lecteur, jusqu’à présent, on se connectait sur des réseaux “&lt;em&gt;Open&lt;/em&gt;” ou “&lt;em&gt;Shared Key&lt;/em&gt;”. Mais je n’ai pas encore parlé ici de l’authentification via TKIP ou CCMP !
Donc, pour des réseaux hotspot ou WEP, on s’arrête ici.&lt;br /&gt;
Par contre, pour les réseaux WPA/WPA2, il reste une étape obligatoire : l’authentification 802.1X (à ne pas confondre avec le 802.11, attention). Bah oui, puisqu’il a fallu rendre le tout un minimum interopérable, on a du rajouter une (dernière) couche après l’association pour ces deux chiffrements.&lt;/p&gt;

&lt;p&gt;Concrètement, le 802.1X est une norme, qui utilise le protocole EAP (pour Extensible Authentication Protol). Globalement, un poste (en câblé ou non) voulant accéder au réseau doit pouvoir prouver sa bonne foi. L’équipement directement connecté -un switch sur du câblé ou l’AP pour du wifi- à ce poste bloque tout accès au réseau (il “ferme” le port) tant que l’identité n’est pas validée. Une fois que le poste est validé, il “ouvre” le port afin que la station puisse discuter avec le réseau. Pour prouver son identité, c’est assez libre, on peut utiliser l’adresse MAC, un identifiant AD, ou encore… une clé wifi :)&lt;/p&gt;

&lt;p&gt;Comme j’ai déjà expliqué en grande partie cette authentification dans mon article sur KRACK, je ne vais pas m’embéter à tout réécrire ici, et &lt;a href=&quot;/krack-review&quot; target=&quot;_blank&quot;&gt;je vous laisse aller le lire&lt;/a&gt; :) Attention cependant, je suis resté assez spécifique au 802.1X wifi. Comme c’est une norme de plus en plus utilisée, il y a pas mal de lecture sur les internets pour du 802.1X cablé, donc je vous laisse le loisir de chercher ^^&lt;/p&gt;

&lt;h3 id=&quot;le-détail-du-format&quot;&gt;Le détail du format&lt;/h3&gt;

&lt;p&gt;Depuis tout à l’heure, j’explique le fonctionnement du 802.11 d’une manière assez statique, c’est à dire que pour chaque type de paquet, j’ai détaillé ce qu’on y trouvait.&lt;br /&gt;
En fait, ce protocole est très modulaire (et surtout très casse bonbons). J’ai fait pas mal de réseau au niveau pro, et je pense que c’est un des protos les plus tordus que j’ai pu voir jusqu’à maintenant, du fait de sa modularité, ainsi que des différentes specs rajoutées au fil du temps.&lt;br /&gt;
Bon, du coup, l’idée, c’est de comprendre le fonctionnement générique de ce protocole, et non pas juste de voir quelques paquets en dur comme on a fait jusqu’à présent.&lt;br /&gt;
Quand je dis comprendre, c’est en partie car il serait trop long de tout expliquer. En fait, chaque champ va en fait définir un subset de champs, et pareil pour chaque paramètre du subset, ce qui peut créer une ramification assez… tordue ! Disons le autrement : c’est le bordel. Je répète : LE BORDEL.&lt;/p&gt;

&lt;p&gt;Gentle reminder : ici, on lit les octets en &lt;em&gt;little endian&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/general_frame_control.png&quot; alt=&quot;Frame Control&quot; /&gt;&lt;/p&gt;

&lt;p&gt;L’idée principale, c’est que CHAQUE paquet envoyé en wifi contient un en-tête 802.11. Pour que tout fonctionne correctement, il doit être normé. Ainsi, la première partie de la frame s’appelle le MAC header, et on retrouvera toujours en première position un champ Frame Control, codé sur deux octets. Ce champ est EXTREMEMENT important, puisque c’est lui qui définir les champs suivants.
Il se divise en 3 parties :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/frame_control1.png&quot; alt=&quot;Frame Control byte 1&quot; /&gt;&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Les bits 6 et 7 correspondent à la version du protocole. La doc 802.11 définit que la version est actuellement 0. Donc, hormis un bug/attaque/autre, ces bits ne changent pas et seront à 00&lt;/li&gt;
  &lt;li&gt;Les bits 4 et 5 correspondent au type de paquet. Il en existe 4 :
    &lt;ul&gt;
      &lt;li&gt;Management (bits 00) : Ils permettent d’envoyer des “commandes” entre la station et l’AP. Typiquement les probes, les authentications et les associations sont de type management&lt;/li&gt;
      &lt;li&gt;Control (bits 01) : Ils servent à contrôler que tout se passe bien. On trouve les &lt;em&gt;ACKnowledgement&lt;/em&gt;, mais aussi d’autres (comme les RTS, qui servent à demander la parole sur le réseau)&lt;/li&gt;
      &lt;li&gt;Data (bits 10) : Ils contiennent les données des couches supérieures du modèle OSI (ARP, IP, TCP, HTTP, etc) et seront donc envoyées à la stack réseau&lt;/li&gt;
      &lt;li&gt;Extension (bits 11) : Ils sont utilisé pour étendre les fonctionnalités, mais on va pas s’embéter avec ça.&lt;/li&gt;
    &lt;/ul&gt;
  &lt;/li&gt;
  &lt;li&gt;Les bits 0 à 3 correspondent au sous-type de paquet. Je ne vais pas tous les lister parce qu’il en existe beaucoup, mais on trouve par exemple :
    &lt;ul&gt;
      &lt;li&gt;Association Request (bits 0000)&lt;/li&gt;
      &lt;li&gt;Association Response (bits 0001)&lt;/li&gt;
      &lt;li&gt;Authentication (bits 1011)&lt;/li&gt;
      &lt;li&gt;Request To Send (RTS) (bits 1011)&lt;/li&gt;
    &lt;/ul&gt;
  &lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;On remarque au passage qu’un sous type RTS et Authentication ont les mêmes bits. C’est normal : puisque le type (les bits 4 et 5) est différent, ils ne se marchent pas sur les pieds :)&lt;br /&gt;
Ainsi, si je veux envoyer une requête d’authentification, mon Frame Control correspondra à :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Version 0 : bits 00&lt;/li&gt;
  &lt;li&gt;Type Management : bits 00&lt;/li&gt;
  &lt;li&gt;Sous type Authentication : bits 1011&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;On aura ainsi un octet 1011 00 00, soit 0x0b.&lt;/p&gt;

&lt;p&gt;A l’inverse, pour un paquet RTS, le Frame Control sera :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Version 0 : bits 00&lt;/li&gt;
  &lt;li&gt;Type Management : bits 01&lt;/li&gt;
  &lt;li&gt;Sous type Authentication : bits 1011&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Ce qui nous donne 1011 01 00, soit 0xb4.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/frame_control2.png&quot; alt=&quot;Frame Control byte 2&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Le deuxième octet du Frame Control est dépendant du premier. Si le type est de 1 et le sous type de 6, on est dans une frame Control/Extension, et les paramètres seront donc spécifiques à l’extension. On va pas trop y toucher dans cet article (ni dans aucun autre d’ailleurs :) ), parce que c’est déjà assez bordélique au niveau du fonctionnement basique.&lt;br /&gt;
Pour tous les autres types/sous types, on retrouvera une liste fixe de paramètres :&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;To DS (Distribution System) : avec le champ suivant, cela permet en gros de savoir si une machine veut discuter sur le réseau avec une autre machine, ou si c’est de la communication entre l’AP et la station. &lt;a href=&quot;https://dalewifisec.wordpress.com/2014/05/17/the-to-ds-and-from-ds-fields/&quot; target=&quot;_blank&quot;&gt;Plus de détails ici.&lt;/a&gt;&lt;/li&gt;
  &lt;li&gt;From DS : bah du coup, faut lire l’explication du champ précédent :)&lt;/li&gt;
  &lt;li&gt;More Fragment : mis à 1 s’il reste d’autres paquets pour un message donné (c’est la fragmentation réseau : un paquet à une taille définie et si le message a envoyer est plus long, on le coupe en plusieurs paquets)&lt;/li&gt;
  &lt;li&gt;Retry : mis à 1 si le paquet a été ré-émis une seconde fois par la source (donc si celle ci n’a pas reçu de ACK)&lt;/li&gt;
  &lt;li&gt;Power Management : pour tout ce qui est gestion de la batterie des machines. Le wifi étant utilisé pour des postes nomades, un gestion de l’énergie a été mise en place dans les specs&lt;/li&gt;
  &lt;li&gt;More Data : ce bit est également utilisé pour la gestion d’énergie et indique que des données sont sur l’AP, en attente d’envoi vers le &lt;em&gt;supplicant&lt;/em&gt;.&lt;/li&gt;
  &lt;li&gt;Protected Frame : assez explicite :) Ce champ est mis à 1 quand le payload du paquet est chiffré via WEP/WPA/WPA2. On le retrouve dans dans les frames datas par exemple&lt;/li&gt;
  &lt;li&gt;+HTC/Order : c’est un champ un peu bâtard. On met le +HTC (High Throughput Control) à 1 dans les frames de type Control Wrapper. Ce type de frame a surement une utilité. Mais je sais pas laquelle. Lorsque le paquet n’est pas un Control Wrapper, il sert à ordonnancer les frames QoS.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;On voit donc que ces deux premiers octets vont définir le comportement global de la frame. Maintenant, attelons nous aux autres champs. Comme dit plus haut, je ne vais pas TOUT détailler, puisqu’il existe beaucoup de combinaisons possibles, en fonction du type/sous type.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/general_duration_id.png&quot; alt=&quot;Duration-id&quot; /&gt;&lt;/p&gt;

&lt;p&gt; 
Ensuite, toujours dans le MAC header, on trouve le champ Duration/ID, d’une taille de 2 octets. Ce champ est fonction du type/sous type, et peut avoir quatre types de valeurs possibles. Je résume rapidement parce que la définition complète de ce champ fait 4 pages dans la doc (oui oui. Quatre), mais en gros, il correspond soit à l’Association ID (dont j’ai parlé plus haut), soit à une durée pour envoyer un ACK, soit à une valeur fixe de 32768.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/general_addresses.png&quot; alt=&quot;Addresses&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Suite à ce Duration/ID, viennent les champs Addresses. Généralement, dans un paquet, on trouve un tuple de deux adresses (MAC source et dest, IP source et dest, etc). Là non. On peut en avoir entre une et quatre.
Pourquoi jusqu’à quatre adresses ? Et bien en fait, c’est logique :&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;la Receiving Address (RA) :  l’adresse MAC de la machine qui recoit le paquet&lt;/li&gt;
  &lt;li&gt;la Transmitting Address (TA) : l’adresse MAC de la machine qui transmet le paquet.&lt;/li&gt;
  &lt;li&gt;la Source Address (SA) : l’adresse MAC de la machine source&lt;/li&gt;
  &lt;li&gt;la Destination Address (DA) : l’adresse MAC de la machine qu’on cherche à joindre (un autre poste du LAN ou la &lt;em&gt;gateway&lt;/em&gt;)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Ici quelques explications s’imposent : Dans un réseau Wifi, il n’y a pas forcément qu’une seule borne. Il est fréquent que plusieurs bornes utilisent le même réseau wifi. Ainsi, si ma bécane veut discuter avec google, elle va envoyer un paquet à la borne sur laquelle elle est connectée avec sa propre MAC comme SA et la &lt;em&gt;gateway&lt;/em&gt; comme DA (bah oui, on discute avec la GW, pas avec google directement). Le champ TA sera également celui de mon laptop, et le champ RA sera la MAC de la borne wifi. Si cette borne est juste un relais, elle va donc devoir envoyer ce paquet à une seconde borne. A ce moment, elle va changer les champs TA et RA. TA deviendra donc l’addresse de la première borne et SA celle de la seconde borne. Cette deuxième AP va ensuite envoyer le paquet à la gateway. Lorsque la réponse arrivera, le chemin inverse sera effectué. Cela dit, un beau schéma, c’est toujours mieux :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/addresses.png&quot; alt=&quot;Addresses explanation&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Comme toujours les champs addresses correspondent aux types et sous type. Par exemple, les frames de controle n’ont pas besoin des 4, puisque l’AP communique directement avec mon PC.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/general_bssid.png&quot; alt=&quot;BSS ID&quot; /&gt;&lt;/p&gt;

&lt;p&gt;On peut dans certaines trames également trouver le champ &lt;em&gt;BSS ID&lt;/em&gt; qui correspond à la MAC de l’AP.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/general_sequence.png&quot; alt=&quot;Sequence Control&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Ce champ se divise en deux parties : une première de 4 bits qui indique le numéro de fragmentation, et une seconde de 12 bits qui est le numéro de séquence. Qui est… bah un numéro quoi. qui s’incrémente et tout.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/general_body.png&quot; alt=&quot;Frame Body&quot; /&gt;&lt;/p&gt;

&lt;p&gt;ENFIN ! ON arrive au &lt;em&gt;Frame Body&lt;/em&gt; (c’est pas trop tôt, l’article est commencé depuis 3 mois).
Le &lt;em&gt;Frame Body&lt;/em&gt; a toujours une taille variable. Tout simplement parce qu’il est inhérent à chaque paquet.&lt;/p&gt;

&lt;p&gt;Pour les frames de types données, c’est plutôt simple :  on envoie la sauce, avec toutes les couches OSI supérieures (mais si lecteur, tu sais bien, le truc qu’on appelle IP par exemple). Là, il n’y a pas à débattre, tout ce qui est envoyé ici n’a aucun rapport avec le 802.11. La taille peut aller de 0 à 2304 octets. Si on a un message plus gros à faire passer, on doit mettre le bit More Fragments à 1. Une fois que le paquet est reçu, la stack réseau prend le relais et envoie le paquet au niveau applicatif.&lt;/p&gt;

&lt;p&gt;Ensuite, les frames de type management et controle : vous connaissez le refrain maintenant : “Ca dépend du type et du sous type”. On ne change pas une équipe qui gagne.&lt;br /&gt;
EN fait, des exemples, j’en ai déjà donné plusieurs tout au long de l’article : les probes, les authentications, les associations, etc. Ici la taille est en fonction des paramètres envoyés. Elle peut avoir une taille qui va de 0 (pour les types ACK par exemple) à 2304. Cela dit, on a rarement 2304 octets des paramètres à envoyer d’un coup ! ^^&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/general_fcs.png&quot; alt=&quot;Frame Check Sequence&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Après le &lt;em&gt;Frame Body&lt;/em&gt;, on trouve le truc le plus simple du proto : le Fram Check Sequence (FCS). C’est toujours un champ de 4 octets, qui contient un CRC32 du MAC header et du &lt;em&gt;Frame Body&lt;/em&gt;. Les plus malins auront compris qu’il sert à vérifier l’intégrité du paquet :) Si le CRC32 est bon, le paquet est accepté et transmis vers la destination. Dans ce cas, un ACK est envoyé à la source pour dire “wesh gros, j’ai fait passer ton petit mot”. Si le FCS est faux, c’est qu’il y a eu erreur. A ce moment, l’AP ne prévient même pas qu’il y a eu un souci. Du coup, mon PC attend un certain moment, puis renvoie le paquet avec le champ Retry à 1.&lt;/p&gt;

&lt;h3 id=&quot;conclusion&quot;&gt;Conclusion&lt;/h3&gt;

&lt;p&gt;Pfiouuu, c’était compliqué. 3500 pages à se taper (bon pas tout quand même, j’ai fait pas mal de Ctrl + F), des recherches dans les tréfonds des internets du web, un article de plus de 30000 caractères, mais bon, au moins, je sais ce qui se passe le matin, quand mon laptop boote et que je bois mon café :)&lt;br /&gt;
En tout cas, même si j’ai galeré, j’ai beaucoup appris techniquement, c’est un très bon exercice à faire, et j’espère que vous aurez aussi appris 2 ou 3 choses !&lt;/p&gt;

&lt;p&gt;Oh, et du coup, suite à KRACK, la Wi Fi Alliance a décidé de faire bouger les choses avec la mise en place du WPA3. A cela, deux solutions : soit ils vont updater les specs pour rajouter toujours plus de bazar, soit ils vont créer une nouvelle spec from scratch, et cet article ne sera bientôt plus utile ^^&lt;/p&gt;

&lt;p&gt;Enjoy&lt;/p&gt;

&lt;p&gt;The lsd&lt;/p&gt;

&lt;h3 id=&quot;liens-utiles&quot;&gt;Liens utiles&lt;/h3&gt;

&lt;p&gt;Tous les liens qui m’ont servi à comprendre le 802.11&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;&lt;a href=&quot;http://ieeexplore.ieee.org/document/7786995/&quot; target=&quot;_blank&quot;&gt;ieeexplore.ieee.org&lt;/a&gt; : le lien vers la doc officielle, évidemment. Attention par contre, il faut s’inscire&lt;/li&gt;
  &lt;li&gt;&lt;a href=&quot;https://mrncciew.com/&quot; target=&quot;_blank&quot;&gt;mrncciew.com&lt;/a&gt; : une bible. C’est pas super beau, un peu brouillon, mais beaucoup d’infos !&lt;/li&gt;
  &lt;li&gt;&lt;a href=&quot;https://www.cwnp.com/forums/&quot; target=&quot;_blank&quot;&gt;www.cwnp.com&lt;/a&gt; : un forum dédié au wifi. C’est le site officiel de la certif CWNP, donc il y a des infos de qualité&lt;/li&gt;
  &lt;li&gt;&lt;a href=&quot;https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11_Association_process_explained&quot; target=&quot;_blank&quot;&gt;meraki.com&lt;/a&gt; : un résumé high level des étapes de connexion&lt;/li&gt;
  &lt;li&gt;&lt;a href=&quot;https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/68583-FAQ-Wireless-Security.html&quot; target=&quot;_blank&quot;&gt;cisco.com&lt;/a&gt; : de la doc sur les méthodes de chiffrement&lt;/li&gt;
  &lt;li&gt;&lt;a href=&quot;https://supportforums.cisco.com/t5/wireless-mobility-documents/802-11-sniffer-capture-analysis-wpa-wpa2-with-psk-or-eap/ta-p/3116990&quot; target=&quot;_blank&quot;&gt;cisco.com&lt;/a&gt; : quelques explications sur les frames d’authentification&lt;/li&gt;
  &lt;li&gt;&lt;a href=&quot;http://community.arubanetworks.com/t5/Technology-Blog/A-closer-look-at-WiFi-Security-IE-Information-Elements/ba-p/198867&quot; target=&quot;_blank&quot;&gt;arubanetworks.com&lt;/a&gt; : des explications un peu plus détaillées que moi sur le RSN et TSN (Transitional Security Network, un truc qui a servi à passer de WEP à WPA2)&lt;/li&gt;
  &lt;li&gt;&lt;a href=&quot;http://fiddy.free.fr/blog/index.php?post/2008/11/25/Le-WEP-suffisamment-s%C3%A9curis%C3%A9&quot; target=&quot;_blank&quot;&gt;fiddy.free.fr&lt;/a&gt; : explications détaillées en en français sur le chiffrement WEP, et pourquoi c’est tout pété&lt;/li&gt;
  &lt;li&gt;&lt;a href=&quot;/assets/zip/802.11/files_802.11.zip&quot;&gt;Fichiers utiles&lt;/a&gt; : Des pcap épuré pour pouvoir regarder le détail, et un html avec les schémas de la struct&lt;/li&gt;
&lt;/ul&gt;</content><author><name></name></author><summary type="html">Dans la première partie, on va vu comment fonctionnait les probes, et l’authentification, mais il reste encore deux ou trois trucs à comprendre avant de pouvoir surfer tranquillement sur google. LET’S GO !</summary></entry><entry><title type="html">Le Wifi, comment ça marche 1/2</title><link href="http://lsdsecdaemon.com/wifi-connection" rel="alternate" type="text/html" title="Le Wifi, comment ça marche 1/2" /><published>2018-02-14T19:00:00+01:00</published><updated>2018-02-14T19:00:00+01:00</updated><id>http://lsdsecdaemon.com/Wifi-comment-ca-marche</id><content type="html" xml:base="http://lsdsecdaemon.com/wifi-connection">&lt;p&gt;Bon, maintenant qu’on a expliqué &lt;a href=&quot;http://lsdsecdaemon.com/krack-review&quot; target=&quot;_blank&quot;&gt;KRACK dans les détails&lt;/a&gt;, on va gratter un peu la surface et regarder comment fonctionne le mécanisme de connexion dans sa globalité.&lt;br /&gt;
Lorsqu’on se connecte sur une borne wifi, il se passe en réalité plein de choses &lt;em&gt;under the hood&lt;/em&gt;, dont personne ne se rend compte.&lt;br /&gt;
Le but de cet article est donc de démystifier un peu le fonctionnement d’une connexion classique à un AP, ce qui va permettre de préparer le terrain pour le post suivant, qui expliquera comment faire des bidouilles sympas (par exemple du jamming).&lt;/p&gt;

&lt;!--more--&gt;

&lt;h3 id=&quot;généralités&quot;&gt;Généralités&lt;/h3&gt;

&lt;p&gt;Avant de commencer, je pose quelques détails généraux, histoire qu’on parte sur de bonnes bases :)&lt;/p&gt;

&lt;p&gt;Une chose importante à prendre en compte, c’est qu’on est sur du réseau wifi. Qui dit wifi dit ondes. Et qui dit ondes dit (forcément) écoute via le mode monitor des cartes wifi. Pour expliquer un peu , il existe 4 modes au niveau wifi :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;le mode &lt;strong&gt;classique&lt;/strong&gt;, que tout le monde utilise. J’utilise le mot classique par défaut, je ne sais pas s’il y a un mot plus exact&lt;/li&gt;
  &lt;li&gt;le mode &lt;strong&gt;&lt;em&gt;promiscuous&lt;/em&gt;&lt;/strong&gt; (qui existe également au niveau cablé). Ce mode permet de récupérer tous les paquets qui ne nous sont pas adressés directement (qui n’ont pas comme adresse de destination notre MAC techniquement). Ce mode s’utilise lorsqu’on est déjà connecté à un réseau wifi&lt;/li&gt;
  &lt;li&gt;le mode &lt;strong&gt;&lt;em&gt;monitor&lt;/em&gt;&lt;/strong&gt; (pour le coup, il n’y a pas d’équivalent cablé) qui nous donne la possibilité de récupérer littérallement TOUS les paquets. C’est grâce à ce mode qu’on va pouvoir faire des trucs cools (au hasard péter des clés wifi)&lt;/li&gt;
  &lt;li&gt;le mode &lt;strong&gt;&lt;em&gt;injection&lt;/em&gt;&lt;/strong&gt;, qui permet d’aller encore plus loin que le monitor. Avec ce mode, on peut envoyer des paquets alors même qu’aucun réseau wifi n’est connecté avec la carte. En gros, on peut envoyer tout et n’importe quoi. Là aussi, c’est plutôt cool pour certaines attaques.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Dans cet article, les paquets que je montre  sont des versions “figées”, c’est à dire spécifiques à chaque type de trame. Les termes mis en gras dans les images des trames sont les plus importants et donc ceux que j’explique. J’ai mis également des screenshots wireshark pour la gloire, histoire de voir concrètement la gueule des paquets.&lt;br /&gt;
J’explique en fin de post le fonctionnement générique des trames 802.11. J’dis ça, j’dis rien, mais pour comprendre le réseau, vaut mieux aller lire les détails :)&lt;/p&gt;

&lt;p&gt;Les puristes du réseau pourront me rétorquer qu’il existe des différences entre une trame et un paquet. Ma réponse est simple : osef. D’une part parce qu’on arrive très bien à comprendre l’idée générale, et d’autre part pour éviter des répétitions dans tous les sens.&lt;/p&gt;

&lt;p&gt;Oh, et n’oublions pas aussi que la doc fait quand même TROIS MILLES CINQ CENT PAGES. Il est donc possible que je me sois planté à certains endroits, dans ce cas, il ne faut pas hésiter à me corriger :)&lt;/p&gt;

&lt;h3 id=&quot;découverte&quot;&gt;Découverte&lt;/h3&gt;

&lt;p&gt;9h du matin : j’allume mon laptop, la séquence de boot passe tranquillement pendant que je bois mon café, et quand je reviens devant mon PC, mon network manager me propose une liste de wifi sur lequel me connecter. OK c’est cool, je choisis mon réseau, la connexion se fait, et je commence ma journée de boulot.&lt;br /&gt;
Mais du coup… il s’est passé quoi exactement ?&lt;/p&gt;

&lt;p&gt;Et bien dans un premier temps, mon laptop a envoyé un gros paquet des familles, qui dit plus ou moins :&lt;/p&gt;

&lt;p&gt;“HEY HO ! ON SE REVEILLE LES ACCESS POINT ! MOI DE MON COTÉ, JE PEUX COMPRENDRE SI VOUS ME PARLEZ FRANCAIS OU ANGLAIS”.&lt;/p&gt;

&lt;p&gt;Ce paquet, c’est ce qu’on appelle un &lt;strong&gt;&lt;em&gt;Probe Request&lt;/em&gt;&lt;/strong&gt;.&lt;br /&gt;
Pour expliquer plus sérieusement, mon portable a fait une requête en &lt;em&gt;broadcast&lt;/em&gt; (donc à destination de tout le monde) afin d’annoncer à tous les réseaux alentours qu’il a besoin de se connecter à un wifi, et qu’il peut utiliser certains paramètres (au hasard, la version A/B/G/N, mais également d’autres).&lt;br /&gt;
Evidemment, les paquets de ce genre sont normés, grâce au standard 802.11, et ressemblent techniquement à cela :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/probe_request.png&quot; alt=&quot;Probe Reponse&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/probe_request_wireshark.png&quot; alt=&quot;Probe Reponse Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Je ne vais pas expliquer tous les champs, mais pour faire simple, on a ici 4 informations importantes (il y en a d’autres évidemment) :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;le &lt;strong&gt;&lt;em&gt;Frame Control&lt;/em&gt;&lt;/strong&gt; : une valeur de 0x0004 correspond à un paquet de type probe request.&lt;/li&gt;
  &lt;li&gt;la &lt;strong&gt;&lt;em&gt;Destination Address&lt;/em&gt;&lt;/strong&gt; : l’adresse MAC de la borne wifi à qui le paquet est envoyé. Je disais plus haut que les &lt;em&gt;probes requests&lt;/em&gt; envoyaient en broadcast, mais il est aussi possible d’envoyer en &lt;em&gt;unicast&lt;/em&gt; (vers une seule machine), ici 00:0E:9E:51:AC:11. Ca permet de moins congestionner le réseau.&lt;/li&gt;
  &lt;li&gt;la &lt;strong&gt;&lt;em&gt;Source Address&lt;/em&gt;&lt;/strong&gt; : l’adresse MAC de mon portable, afin que les AP puissent me répondre.&lt;/li&gt;
  &lt;li&gt;le &lt;strong&gt;&lt;em&gt;Frame Body&lt;/em&gt;&lt;/strong&gt; : alors là, c’est un peu le bordel, parce que les normes wifi ont évolué au fil du temps. Du coup, les paramètres renseignés dans le &lt;em&gt;Frame Body&lt;/em&gt; sont carrément variables. Dans la version 2016 de la norme 802.11, on trouve jusqu’à 20 champs (tableau 9.33, page 706). Chaque champ se compose de 3 parties : un ID, la taille du champ, et sa valeur. Ils permettent de définir les capacités du &lt;em&gt;supplicant&lt;/em&gt; (le client Wifi), afin que l’AP sache s’il pourra répondre ou non. On retrouve comme informations, les channels utilisables, les taux de transfert, et en fonction de pas mal de paramètres, d’autres informations.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Pour information, tout ce qui précède le &lt;em&gt;Frame Body&lt;/em&gt; est appelé le &lt;strong&gt;&lt;em&gt;MAC Header&lt;/em&gt;&lt;/strong&gt;. On n’en reparlera pas, mais sachez le :)&lt;br /&gt;
De plus, le &lt;em&gt;Frame Body&lt;/em&gt; est différent selon les paquets. Ici, on a uniquement des paramètres taggués. Comme on ne peut pas savoir à l’avance quels paramètres seront présents, on est obligé d’utiliser un principe de tags pour chaque champ (d’où l’utilisation d’ID). Le Frame Body étant spécifique selon les paquets, cela ne sera pas toujours le cas. On pourra trouver des paramètres fixes (donc pas besoin d’ID). Don’t worry, j’explique tout bien komilfo à la fin.&lt;/p&gt;

&lt;p&gt;Bref. Une fois que cette étape est passée, les AP qui sont à portée vont répondre à ma machine deux choses :&lt;br /&gt;
La première, c’est :&lt;/p&gt;

&lt;p&gt;“Ok  mec, pas la peine de crier, je t’ai entendu.”&lt;/p&gt;

&lt;p&gt;C’est l’&lt;strong&gt;&lt;em&gt;ACK&lt;/em&gt;&lt;/strong&gt; (&lt;em&gt;ACKnowledgment&lt;/em&gt;) que l’AP envoie au &lt;em&gt;supplicant&lt;/em&gt;, juste pour valider que le message a bien été reçu.&lt;br /&gt;
C’est un paquet très court, qui ne contient quasiment rien. Il est tellement court, qu’il ne contient même pas l’adresse MAC de la source ! Après quelques recherches, on explique &lt;a href=&quot;https://stackoverflow.com/questions/37040303/why-do-802-11-acknowledgement-frames-have-no-source-mac&quot; target=&quot;_blank&quot;&gt;ici&lt;/a&gt;, &lt;a href=&quot;http://cnp3book.info.ucl.ac.be/2nd/html/protocols/wifi.html&quot; target=&quot;_blank&quot;&gt;là&lt;/a&gt; et dans le §9.2.8 de la doc que c’est normal qu’il n’y ait pas de source parce que l’AP ne peut répondre qu’à une seule machine pendant un court laps de temps, grâce à un &lt;em&gt;timer&lt;/em&gt;. Du coup, on sait forcément à qui s’adresse le ACK et ça fait un paquet plus court à envoyer.&lt;br /&gt;
Voilà à quoi ressemble un &lt;em&gt;ACK&lt;/em&gt; :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/ack.png&quot; alt=&quot;ACK packet&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/ack_wireshark.png&quot; alt=&quot;ACK packet Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Au niveau des infos, c’est plus simple, vu que le but du jeu, c’est juste que l’AP dise que le message est bien arrivé. Dans les champs utiles, on a simplement :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;un &lt;em&gt;Frame Control&lt;/em&gt; qui correspond à 0x00D4,&lt;/li&gt;
  &lt;li&gt;l’adresse de destination, qui est donc l’adresse source du &lt;em&gt;probe request&lt;/em&gt;.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Ce message apparait quasiment après chaque paquet reçu, je n’en parlerai plus à partir de maintenant, mais il faut garder en tête qu’il est (presque) toujours présent.&lt;/p&gt;

&lt;p&gt;La deuxième chose, c’est ça :&lt;/p&gt;

&lt;p&gt;“Toi et moi, c’est un match, tiens voilà mes infos si tu veux qu’on discute ensemble”.&lt;/p&gt;

&lt;p&gt;C’est le &lt;strong&gt;&lt;em&gt;Probe Response&lt;/em&gt;&lt;/strong&gt;. Techniquement, il contient, comme pour la requête, plusieurs informations utiles au client (nom du constructeur, SSID, channel, etc) et ressemble beaucoup au Probe Request :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/probe_response.png&quot; alt=&quot;Probe Response&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/probe_response_wireshark.png&quot; alt=&quot;Probe Response Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Dans la liste des champs intéressants, on retrouve les mêmes choses que pour le probe request (&lt;em&gt;Frame Control&lt;/em&gt;, Destination, Source, &lt;em&gt;Body&lt;/em&gt;).&lt;br /&gt;
Evidemment, les MAC source et destination sont inversées, et le &lt;em&gt;Frame Body&lt;/em&gt; est différent. Celui-ci, encore une fois très important, donne des informations, comme le type de chiffrement utilisé (j’en reparle un peu plus loin), qui permettent à mon PC de savoir s’il est en capacité de se connecter à cet AP.&lt;/p&gt;

&lt;p&gt;Bon, maintenant que les réponses des bornes ont été récupérées par ma machine, elle décide quel est le meilleur réseau auquel se connecter, en fonction de plusieurs paramètres, du genre la puissance du signal, le réseau préféré, ou encore le débit proposé. Libre à l’OS de choisir ce qu’il veut. Le mien, par exemple, a une fâcheuse tendance à choisir le réseau le plus pourri.
Une fois que le choix est fait, on va passer à la phase suivante : l’authentification.&lt;/p&gt;

&lt;h3 id=&quot;authentification&quot;&gt;Authentification&lt;/h3&gt;

&lt;p&gt;On a découvert les réseaux à proximité, on va donc pouvoir s’attaquer à la deuxième étape : l’authentification.&lt;br /&gt;
Une fois que le &lt;em&gt;supplicant&lt;/em&gt;  a choisi son AP, il va devoir lui dire qu’il veut se connecter. Et alors là… C’est le bordel. Grave.&lt;/p&gt;

&lt;p&gt;Pour s’authentifier, le client va donc envoyer une première requête. Cette requête va contenir un élément important : le type d’authentification. Soit &lt;strong&gt;&lt;em&gt;Open&lt;/em&gt;&lt;/strong&gt;, soit &lt;strong&gt;&lt;em&gt;Shared Key&lt;/em&gt;&lt;/strong&gt;. Bêtement, on pourrait penser que &lt;em&gt;Open&lt;/em&gt; correspond aux réseaux ouverts (wifi mcdo ou autres), et que &lt;em&gt;Shared Key&lt;/em&gt; correspondrait aux wifi authentifié (WEP et WPA/WPA2). MAIS NON.&lt;br /&gt;
La blague dans l’histoire, c’est que :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;&lt;em&gt;Shared Key&lt;/em&gt; correspond à du chiffrement WEP,et uniquement à du WEP (§12.3.3.3.1 de la doc 802.11)&lt;/li&gt;
  &lt;li&gt;&lt;em&gt;Open&lt;/em&gt; correspond à un wifi ouvert… ou alors à du chiffrement via WPA/WPA2. Les maux de têtes commencent à arriver ? Ce n’est que le début.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;C’est débile, oui, mais pourquoi ? En fait, à la mise en place de la norme 802.11, les créateurs n’ont prévu à la base que de wifi non chiffré, ou chiffré en WEP. Du coup, il faut prendre en compte que tout ce qui n’est pas WEP, est &lt;em&gt;Open&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;Maintenant, comment mon ordinateur sait que l’AP m’a proposé du non chiffré, du WEP, du WPA, ou du WPA2 ?&lt;br /&gt;
A la base, c’était simple. Le &lt;em&gt;Probe Response&lt;/em&gt; contenait un champ &lt;strong&gt;&lt;em&gt;Privacy&lt;/em&gt;&lt;/strong&gt; (un bit mis à 1) qui définissait ou non l’utilisation du WEP. Et puis, ce fut le drame.&lt;br /&gt;
Lorsque l’IEEE s’est rendu compte que WEP était pété, il ont sorti un truc à l’arrache, histoire colmater un peu : le WPA. Ce WPA utilise un chiffrement de type TKIP.&lt;br /&gt;
SAUF QUE, comme il a été fait un peu à la wanagain bistoufly, les mecs se sont dit qu’ils allaient préparer un truc plus propre pour la suite : WPA2, qui utilise du CCMP.&lt;br /&gt;
SAUF QUE, histoire que tout soit bien retrocompatible, quand ils ont fait l’amendement 802.11i (qui officialise WPA/WPA2), les bonhommes ont décidé que WPA devrait AUSSI supporter CCMP, et que WPA2 devrait AUSSI supporter TKIP.&lt;br /&gt;
SAUF QUE, encore une fois, histoire de compatibilité, il a fallu faire des bidouilles &lt;em&gt;from space&lt;/em&gt;. Donc, pour WPA, il a fallu utiliser un paramètre optionnel spécifique (le tag 221) qui liste les chiffrements disponibles en WPA. Pour WPA2, ils ont créé un autre paramètre : le RSN (Robust Security Network).
(Evidemment, trouver ça dans 3500 pages de doc… bisou.)&lt;/p&gt;

&lt;p&gt;Donc, pour résumer le fonctionnement, dans le &lt;em&gt;Probe Response&lt;/em&gt;, ça se passe comme ça :&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;Mode &lt;em&gt;Shared&lt;/em&gt; : WEP&lt;/li&gt;
  &lt;li&gt;Mode &lt;em&gt;Open&lt;/em&gt; :
    &lt;ul&gt;
      &lt;li&gt;tag RSN :
        &lt;ul&gt;
          &lt;li&gt;CCMP et/ou TKIP (mode WPA2)&lt;/li&gt;
        &lt;/ul&gt;
      &lt;/li&gt;
      &lt;li&gt;tag optionnel 221 :
        &lt;ul&gt;
          &lt;li&gt;CCMP et/ou TKIP (mode WPA)&lt;/li&gt;
        &lt;/ul&gt;
      &lt;/li&gt;
      &lt;li&gt;aucun tag :
        &lt;ul&gt;
          &lt;li&gt;wifi non chiffré&lt;/li&gt;
        &lt;/ul&gt;
      &lt;/li&gt;
    &lt;/ul&gt;
  &lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;En fonction de ces informations, ma bécane saura ainsi lors de cette première requête de la phase d’authentification s’il faut envoyer une demande &lt;em&gt;Shared&lt;/em&gt; ou &lt;em&gt;Open&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;On va commencer par étudier le type &lt;em&gt;Open&lt;/em&gt;, c’est le plus simple :)&lt;br /&gt;
La requête qu’envoie mon PC, c’est littéralement :&lt;/p&gt;

&lt;p&gt;“Hey, psst, hey ! Tu me laisses rentrer s’il te plait ?”&lt;/p&gt;

&lt;p&gt;Comme d’hab, je met le petit schéma de la requête. Pour le coup, j’ai détaillé le &lt;em&gt;Frame Body&lt;/em&gt; parce qu’il est important de comprendre ce qu’il contient.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_open_msg1.png&quot; alt=&quot;Open Authentication request&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_open_msg1_wireshark.png&quot; alt=&quot;Open Authentication request Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Tout se joue donc au niveau du &lt;em&gt;Frame Body&lt;/em&gt;. En mode &lt;em&gt;Open&lt;/em&gt;, on trouve trois champs :&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;l’&lt;strong&gt;&lt;em&gt;Authentication algorithm&lt;/em&gt;&lt;/strong&gt; : qui correspond à 0x0000&lt;/li&gt;
  &lt;li&gt;l’&lt;strong&gt;&lt;em&gt;Authentication SEQuence&lt;/em&gt;&lt;/strong&gt; : puisque c’est le premier message de l’authent, il correspond à 0x0001&lt;/li&gt;
  &lt;li&gt;le &lt;strong&gt;&lt;em&gt;Status Code&lt;/em&gt;&lt;/strong&gt; : tout se passe bien, il est à 0x0000&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Une fois que l’AP a reçu ce message d’authentification, il va bien évidemment y répondre. La réponse est quasiment identique à la requête. Dans le &lt;em&gt;Frame Body&lt;/em&gt;, le seul champ différent est l’Authentication SEQuence qui passe à 0x0002. Le reste ne bouge pas, si tout se passe bien :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_open_msg2.png&quot; alt=&quot;Open Authentication response&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_open_msg2_wireshark.png&quot; alt=&quot;Open Authentication response Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Une fois que la réponse est envoyée au client (et que l’AP a bien reçu le ACK qui suit), tout est ok, les deux machines sont dans un état authentifié, mais non associé. Je parle de l’association après, mais pour l’instant, étudions un peu l’authentification en mode &lt;em&gt;Shared&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;En mode &lt;em&gt;Shared&lt;/em&gt; (donc WEP), il y a un &lt;strong&gt;&lt;em&gt;4Way handshake&lt;/em&gt;&lt;/strong&gt;, qui permet de valider la clé Wifi, sans qu’elle ne passe en clair sur le réseau (bon, le WEP a été pété malgré ça, mais l’intention était louable :) )&lt;br /&gt;
Le premier message est, à l’instar du mode &lt;em&gt;Open&lt;/em&gt;, envoyé par le client et est identique, hormis l’&lt;em&gt;Authentication Algorithm&lt;/em&gt;, qui correspond cette fois-ci à 0x0001, pour signifier le mode &lt;em&gt;Shared&lt;/em&gt;. Malheureusement, je n’ai pas d’équipements qui me permette de faire d’authent WEP sous la main, donc j’ai honteusement (ou pas) “emprunté” des images venant de &lt;a href=&quot;https://mrncciew.com/2014/10/10/802-11-mgmt-authentication-frame/&quot; target=&quot;_blank&quot;&gt;mrncciew.com&lt;/a&gt;. On lui dit merci :)&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_shared_msg1.png&quot; alt=&quot;Shared Authentication request&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_shared_msg1_wireshark.png&quot; alt=&quot;Shared Authentication request Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Le second message, envoyé par l’AP, va faire les actions suivantes : incrémenter le numéro de séquence pour le passer à 0x0002, et envoyer un paramètre taggué (id 16), qui correspond à un challenge que ma machine devra utiliser pour valider la clé Wifi. La valeur de ce challenge est une chaine pseudo aléatoire de 128 octets.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_shared_msg2_wireshark.png&quot; alt=&quot;Shared Authentication challenge Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Un troisième message va être envoyé par le supplicant. Celui ci va contenir principalement :&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;l’Initialization Vector (IV), qui permet d’éviter d’avoir deux messages chiffrés identiques pour un même clair&lt;/li&gt;
  &lt;li&gt;l’Integrity Check Value (ICV), qui est un bête CRC32 du challenge clair&lt;/li&gt;
  &lt;li&gt;le challenge response, qui est (IV + challenge) chiffré avec la clé WEP.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_shared_msg3_wireshark.png&quot; alt=&quot;Shared Authentication challenge validation Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Une fois ce message reçu par l’AP, ce dernier va déchiffrer le challenge, vérifier qu’il correspond bien à son ICV, et vérifier qu’il correspond au clair envoyé dans le message 2.&lt;br /&gt;
Si le challenge et sa réponse sont équivalents, l’AP va donc envoyer un dernier message de validation, les données du &lt;em&gt;Frame Body&lt;/em&gt; seront classiques : l’Authentication Algorithm toujours positionné à &lt;em&gt;Shared Key&lt;/em&gt;, l’Authentication SEQuence à 0x0004, et le Status Code à 0x0000.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_shared_msg4.png&quot; alt=&quot;Shared Authentication response&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/802-11/authentication_shared_msg4_wireshark.png&quot; alt=&quot;Shared Authentication response Wireshark&quot; /&gt;&lt;/p&gt;

&lt;p&gt;A l’inverse, s’il y a un souci (mauvaise clé par exemple), le Status Code sera différent de 0x0000 et l’AP considérera que le client n’a pas pu s’authentifier.&lt;br /&gt;
Ouf, next step !&lt;/p&gt;

&lt;p&gt;Pour la suite, &lt;a href=&quot;/wifi-connection-2&quot;&gt;c’est par ici&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Enjoy&lt;/p&gt;

&lt;p&gt;The lsd&lt;/p&gt;</content><author><name></name></author><summary type="html">Bon, maintenant qu’on a expliqué KRACK dans les détails, on va gratter un peu la surface et regarder comment fonctionne le mécanisme de connexion dans sa globalité. Lorsqu’on se connecte sur une borne wifi, il se passe en réalité plein de choses under the hood, dont personne ne se rend compte. Le but de cet article est donc de démystifier un peu le fonctionnement d’une connexion classique à un AP, ce qui va permettre de préparer le terrain pour le post suivant, qui expliquera comment faire des bidouilles sympas (par exemple du jamming).</summary></entry><entry><title type="html">KRACK : Review</title><link href="http://lsdsecdaemon.com/krack-review" rel="alternate" type="text/html" title="KRACK : Review" /><published>2017-10-22T19:07:10+02:00</published><updated>2017-10-22T19:07:10+02:00</updated><id>http://lsdsecdaemon.com/KRACK-Review</id><content type="html" xml:base="http://lsdsecdaemon.com/krack-review">&lt;p&gt;Salut tout le monde&lt;/p&gt;

&lt;p&gt;Bon, toute personne ayant suivi un minimum l’actu sécu ces jours ci aura forcément entendu parler de KRACK, la nouvelle vulnérabilité contre le WPA2.&lt;/p&gt;

&lt;p&gt;Découverte et rendue publique par &lt;a href=&quot;https://twitter.com/vanhoefm&quot;&gt;Mathy Vanhoef&lt;/a&gt;, cette attaque permet en gros, d’exploiter une faiblesse dans l’implémentation de WPA2.&lt;br /&gt;
Mais ici, pas de buzzword comme “WPA2 est cassé”, “Le protocole WPA n’est plus” ou autre trucs de marketeux.&lt;br /&gt;
Nan, ici, on va parler technique et expliquer un peu plus en détails le fonctionnement d’une des attaques. Parce que oui, en fait, il y en a plusieurs. Je vais donc expliquer la méthode la plus basique (en espérant ne pas avoir dit trop de bêtises; si c’est le cas, il ne faut pas hésiter à me corriger :) )&lt;/p&gt;

&lt;p&gt;Pour tout comprendre, il faut déjà garder en tête une des finalités de KRACK : pouvoir faire un “Man In The Middle” (on notera les guillemets, j’expliquerai plus bas pourquoi).&lt;br /&gt;
Maintenant, place aux explications !&lt;/p&gt;

&lt;!--more--&gt;

&lt;h3 id=&quot;back-to-basics&quot;&gt;Back to basics&lt;/h3&gt;

&lt;p&gt;Avant même de parler de la vulnérabilité en elle même, il faut comprendre le fonctionnement d’un “Nonce” : c’est un message (nombre, lettres, peut importe), qui doit être utilisé une seule et unique fois, afin d’éviter des attaques par rejeu. Par exemple, si un serveur envoie un Nonce de “54321”. Le client enverra une réponse contenant “54321”. Le serveur doit ensuite considérer que “54321” n’est plus valide et générer un nouveau Nonce. Ainsi, si un attaquant essaie de relancer le message du client (qu’il a obtenu via une écoute du réseau par exemple), le serveur voyant le Nonce de “54321” saura qu’il y a attaque par rejeu et rejettera le paquet.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/krack-review/nonce.png&quot; alt=&quot;Nonce&quot; /&gt;&lt;/p&gt;

&lt;h3 id=&quot;le-coeur-de-la-faiblesse--le-4-way-handshake&quot;&gt;Le coeur de la faiblesse : le 4 way handshake.&lt;/h3&gt;

&lt;p&gt;Bon, maintenant, comment fonctionne exactement une connexion wifi en WPA2 ?&lt;br /&gt;
La phase d’authentification s’appelle le 4 Way Handshake, tout simplement parce qu’il y aura un échange de quatre paquets entre le client (le supplicant en VO) et le point d’accès wifi (l’authenticator en VO).&lt;/p&gt;

&lt;p&gt;Lorsqu’un client effectue une demande de connexion, il se passe (entre autres) ces étapes :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;
    &lt;p&gt;l’AP (point d’accès) va envoyer un premier message qui contiendra un compteur et ce qu’on appelle un ANonce (Authenticator Nonce, qui est juste un nombre ici)&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;Grâce à cela, le client va pouvoir calculer une PTK (pour Pairwise Transient Key). Cette PTK est basée sur la clé Wifi, le ANonce, le SNonce (qui est le Supplicant Nonce, généré à la réception du ANonce), et les adresse MAC de l’AP et du client. En gros, le calcul est hash(ANonce+SNonce+Clé wifi+MAC AP+Mac supplicant).&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;Une fois la PTK calculée, le client va envoyer un deuxième message, vers le serveur. Ce message contiendra le même compteur que précédemment, et le SNonce.&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;Coté AP, la PTK va être calculée exactement de la même manière que précédemment. Ainsi, le client et l’AP auront la même PTK. A ce point du handshake, même si un attaquant espionne les connexions, il ne pourrait pas casser la connexion, puisque même s’il a pu capturer le ANonce et le SNonce, la PTK est basée en partie sur la clé Wifi.&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;Une fois la PTK connue des deux cotés, l’AP envoie dans le troisième message ce qui s’appelle une GTK (Group Transient Key), ainsi que le compteur, incrémenté de 1. La GTK est une clé envoyée de manière chiffrée grâce à la PTK et sert pour envoyer de messages en multicast et broadcast.&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;Le client envoie enfin le 4ème et dernier message, qui est juste un accusé de réception du troisième. Dans le même temps, il valide la PTK et la GTK, qui sont donc considérés comme valides.&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;A la réception de l’accusé, l’AP va de son coté valider la PTK&lt;/p&gt;
  &lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Voilà pour la partie détaillée. Pour faire plus simple, ça fait quelque chose comme :&lt;/p&gt;

&lt;p&gt;“Salut client, on s’authentifie ? Tiens, un message secret : poulpe”&lt;br /&gt;
“Coucou AP, ok pour s’authentifier. Voilà mon message secret : epluop”&lt;br /&gt;
“OK, tout est correct, voilà une clé chiffrée que tu dois déchiffrer pour discuter en multicast : cbhycr”&lt;br /&gt;
“Nickel, j’ai bien reçu ta clé chiffrée.”&lt;/p&gt;

&lt;p&gt;Une fois que ce 4 way handshake est passé, le client et l’AP peuvent discuter de manière chiffrée.&lt;/p&gt;

&lt;p&gt;Schématiquement, ça ressemble à ça :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/krack-review/4way.png&quot; alt=&quot;4 way handshake&quot; /&gt;&lt;/p&gt;

&lt;h3 id=&quot;pourquoi-tout-il-est-cassé-&quot;&gt;Pourquoi tout-il-est-cassé ?&lt;/h3&gt;

&lt;p&gt;En soi, le design est (presque) correct. Ce qui pose problème, c’est (en partie) l’implémentation par les différents constructeurs de ce handshake. L’implémentation dans une utilisation classique est correcte (encore heureux, sinon, on pourrait pas utiliser de WPA2 ^^)&lt;/p&gt;

&lt;p&gt;Bon. Imaginons maintenant qu’on puisse se mettre ENTRE le client et l’AP, que pourrait-il se passer ? Juste comme ça, absolument rien : même si on récupère le ANonce et le SNonce, on ne pourrait pas récupérer la PTK, celle ci étant créée grâce à la clé WIFI (et donc pas la GTK non plus, mais c’est pas grave) ce qui rendrait impossible le déchiffrement des trames suivantes.&lt;/p&gt;

&lt;p&gt;Cela dit, et c’est là que le bas blesse, la méthode de validation de ce 4way handshake est un peu foireuse selon les cas.&lt;/p&gt;

&lt;p&gt;L’attaque fonctionne ainsi :&lt;/p&gt;

&lt;p&gt;Entre le client et l’AP, un rogue AP est créé par l’attaquant. Il sera donc en position de Man In The Middle et pourra voir passer tous les paquets. Lors du 4way handshake, voilà ce qui va se passer :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;l’AP envoie son ANonce. L’attaquant le laisse passer et le renvoie donc au client&lt;/li&gt;
  &lt;li&gt;le client envoie son SNonce. Comme précédemment, l’attaquant le voie et le laisse passer vers l’AP&lt;/li&gt;
  &lt;li&gt;le serveur va donc envoyer sa GTK, avec son compteur, incrémenté de 1. L’attaquant ne touche à rien et le paquet arrive au client&lt;/li&gt;
  &lt;li&gt;enfin le client envoie son ACK final. C’est ici que tout se joue : l’attaquant bloque ce paquet.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;La suite est un peu plus tricky :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;A ce stade, tout semble OK pour le client, il installe sa PTK et GTK. Sauf que l’AP n’ayant pas reçu le ACK du client, il va renvoyer la GTK, avec un compteur incrémenté encore une fois de 1.&lt;/li&gt;
  &lt;li&gt;le client reçoit ce paquet. Que fait il ? Bêtement, il voit un paquet contenant une GTK, il se dit, “OK je réinstalle ma GTK, ma PTK, et je réinitialise mon compteur”&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;A ce niveau, que s’est-il passé ? Le serveur à envoyé deux messages contenant la GTK : celui contenant compteur+1, et celui contenant compteur+2 (en soi, la GTK on s’en fout, c’est le compteur qui est important)&lt;br /&gt;
Le client a envoyé un ACK contenant compteur+1, qui a été bloqué par l’attaquant, puis un autre message, contenant compteur+2.&lt;br /&gt;
Sauf que l’AP n’a reçu que celui contenant compteur+2, le message ayant compteur+1 étant tombé aux oubliettes.&lt;/p&gt;

&lt;p&gt;Un bon schéma des familles pour mieux comprendre :&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/images/krack-review/4way_attack.png&quot; alt=&quot;4 way handshake attacked&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Dans un flux “normal”, n’importe quel message contenant compteur+1 devrait être rejeté par l’AP. Cependant, la RFC définit ceci :&lt;br /&gt;
“On reception of message 4, the Authenticator verifies that the Key Replay Counter field value is one that it used on this 4-way handshake”&lt;/p&gt;

&lt;p&gt;Autrement dit, puisque l’AP a envoyé des messages compteur+1 et compteur+2 AVANT de recevoir le ACK du client (contenant compteur+2, tout le monde suit ?), il accepte des messages contenant compteur+1 ET compteur+2.&lt;/p&gt;

&lt;p&gt;Enfin, puisque le client a réinitialisé son compteur, il va donc renvoyer un message contenant compteur+1. Ainsi, il fait exactement ce qu’il ne faut pas faire : du Nonce reuse. L’AP considérera ce compteur comme valide, puisqu’envoyé avant réception du ACK final.&lt;/p&gt;

&lt;p&gt;Il est possible que certains soient perdus (c’est mon cas par exemple), mais c’est pas encore fini ^^’.&lt;/p&gt;

&lt;p&gt;Très bien, on peut effectuer des attaques par rejeu. Mais bon, que peut on en faire ? Selon les protocoles, les résultats sont différents, mais on se base au final sur des attaques connues :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;sur TKIP, il est possible de déchiffrer et injecter des paquets. Cela est possible car le chiffrement est faible. En gros, le chiffrement des paquets se fait en RC4, avec une clé de 128 bits basé sur la PTK, la MAC de la source et le Nonce. Comme on connait la MAC, et le Nonce, on peut casser facilement le RC4 et donc injecter des paquets. (ce qui ne signifie pas qu’on récupère la clé wifi, juste la clé temporaire.)&lt;/li&gt;
  &lt;li&gt;pour le CCMP, c’est basé sur AES. Donc, c’est un peu poil plus chaud. Mais comme on est aussi basé sur le Nonce, on peut à priori déchiffrer plus facilement.&lt;/li&gt;
  &lt;li&gt;pour le GCMP, le Nonce reuse fait des massacres ici : “If a nonce is ever repeated, it is possible to reconstruct the authentication key used by the GHASH function”. Mais pour comprendre ça, il faut lire un autre paper, et il est déjà 23H&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;On notera que selon les techniques d’attaque, il est possible d’effectuer du rejeu/déchiffrement/injection dans un sens ou l’autre (client vers AP ou l’inverse).&lt;/p&gt;

&lt;h3 id=&quot;mais-au-fait-comment-on-fait-un-mitm-ap-sinon-&quot;&gt;Mais au fait, comment on fait un MITM AP sinon ?&lt;/h3&gt;

&lt;p&gt;Alors, pour cette partie, c’est plus simple. c’est également une attaque connue, mais c’est rigolo.&lt;br /&gt;
Le but est donc de créer un Roque AP, et que le client se connecte dessus. Pour cela, va donc falloir créer un AP qui possède le même nom et la même adresse MAC que l’AP original, mais sur un canal différent.&lt;br /&gt;
Si le client se connecte directement sur notre AP, il suffit de forwarder les paquets à l’AP réel et tout est bon. Mais il y a aussi des chances pour qu’il tente de se connecter à l’AP d’origine.&lt;/p&gt;

&lt;p&gt;Du coup, pour être sur que le client se connecte sur notre AP, on va faire ce qu’on appelle du jamming. En gros, on envoie un max de signaux pourrie à la véritable AP, qui va plus pouvoir répondre. Comme notre AP répond au même nom et à la même MAC que la véritable, le client va tout simplement se connecter sur notre Rogue AP. Juste après ça, on arrête le jam pour pouvoir retransmettre les paquets.&lt;/p&gt;

&lt;p&gt;C’est ce qu’on appelle un Channel Attack.&lt;/p&gt;

&lt;p&gt;La question, c’est pourquoi un Channel Attack ?&lt;br /&gt;
La réponse est simple : si on créé un AP n’ayant pas la même MAC, le calcul de la PTK sera éronné et l’attaque ne fonctionnera tout simplement pas. Du coup, on est obligé d’avoir la même MAC. Mais évidemment, on ne peut pas se mettre sur le même channel, sinon le client ferait la gueule ^^&lt;/p&gt;

&lt;p&gt;Pour résumer, KRACK, c’est une combinaison de plusieurs attaques :&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Rogue AP, avec un Channel Attack&lt;/li&gt;
  &lt;li&gt;Une fois en position de MITM, on va sélectionner des paquets à renvoyer ou non vers le client&lt;/li&gt;
  &lt;li&gt;Suite à ça, le client va réinitialiser son compteur&lt;/li&gt;
  &lt;li&gt;le compteur étant utilisé comme Nonce, il sera réutilisé&lt;/li&gt;
  &lt;li&gt;ce qui nous permet de faire des attaques par rejeu&lt;/li&gt;
  &lt;li&gt;et dans certains cas de pouvoir injecter des paquets&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Pour info, j’ai honteusement copié le post que j’ai créé &lt;a href=&quot;https://www.newbiecontest.org/forums/index.php?topic=4651&quot;&gt;sur Newbie Contest&lt;/a&gt;. Du coup, ça fait un peu réchauffé (avec des schémas en plus quand même), mais ça m’a au moins motivé à lancer LsdSecDaemon :)&lt;/p&gt;

&lt;p&gt;Enjoy&lt;/p&gt;

&lt;p&gt;The lsd&lt;/p&gt;

&lt;h3 id=&quot;liens-utiles-&quot;&gt;Liens utiles :&lt;/h3&gt;

&lt;p&gt;Paper : &lt;a href=&quot;https://papers.mathyvanhoef.com/ccs2017.pdf&quot;&gt;https://papers.mathyvanhoef.com/ccs2017.pdf&lt;/a&gt;&lt;br /&gt;
Site de KRACK Attacks : &lt;a href=&quot;https://www.krackattacks.com/&quot;&gt;https://www.krackattacks.com/&lt;/a&gt;&lt;br /&gt;
AP Jamming : &lt;a href=&quot;https://people.cs.kuleuven.be/~mathy.vanhoef/papers/acsac2014.pdf&quot;&gt;https://people.cs.kuleuven.be/~mathy.vanhoef/papers/acsac2014.pdf&lt;/a&gt; et &lt;a href=&quot;https://www.cs.montana.edu/yang/paper/jamming.pdf&quot;&gt;https://www.cs.montana.edu/yang/paper/jamming.pdf&lt;/a&gt;&lt;br /&gt;
Un POC pour tester, tout frais : &lt;a href=&quot;https://pastebin.com/aZyyS16w&quot;&gt;https://pastebin.com/aZyyS16w&lt;/a&gt;&lt;br /&gt;
Une vidéo de vulgarisation : &lt;a href=&quot;https://www.youtube.com/watch?v=fOgJswt7nAc&quot;&gt;https://www.youtube.com/watch?v=fOgJswt7nAc&lt;/a&gt;&lt;br /&gt;
L’article de pixis sur cette attaque, je vous le conseille fortement : &lt;a href=&quot;http://beta.hackndo.com/krack/&quot;&gt;http://beta.hackndo.com/krack/&lt;/a&gt;&lt;/p&gt;</content><author><name></name></author><summary type="html">Salut tout le monde Bon, toute personne ayant suivi un minimum l’actu sécu ces jours ci aura forcément entendu parler de KRACK, la nouvelle vulnérabilité contre le WPA2. Découverte et rendue publique par Mathy Vanhoef, cette attaque permet en gros, d’exploiter une faiblesse dans l’implémentation de WPA2. Mais ici, pas de buzzword comme “WPA2 est cassé”, “Le protocole WPA n’est plus” ou autre trucs de marketeux. Nan, ici, on va parler technique et expliquer un peu plus en détails le fonctionnement d’une des attaques. Parce que oui, en fait, il y en a plusieurs. Je vais donc expliquer la méthode la plus basique (en espérant ne pas avoir dit trop de bêtises; si c’est le cas, il ne faut pas hésiter à me corriger :) ) Pour tout comprendre, il faut déjà garder en tête une des finalités de KRACK : pouvoir faire un “Man In The Middle” (on notera les guillemets, j’expliquerai plus bas pourquoi). Maintenant, place aux explications !</summary></entry></feed>