Security2024-03-23T09:12:33+00:00urn:md5:849fe58bfa365529560fd255e09aad74DotclearMD5 : Jouons avec les collisionsurn:md5:cbf1fd2fe49c5651b9529bca645375c92014-01-18T15:50:00+01:00fiddySécurité <p>Les fonctions de hachage occupent une place à part entière dans le monde de la cryptographie. Ses propriétés intrinsèques leur confèrent des fonctionnalités très intéressantes. Parmi les plus rencontrées :</p>
<ul><li>Empreinte d'un programme pour vous prémunir contre toute installation d'une version corrompue</li>
<li>Empreinte d'un certificat électronique</li>
<li>Stockage des mots de passe</li>
<li>Stockage d'une position d'échecs dans une table de hachage</li>
</ul>
<p>
J'avais déjà abordé ces fonctions dans un précédent article : <a hreflang="fr" href="http://fiddy.free.fr/blog/index.php?post/2009/01/18/L-art-de-briser-SSL-%C3%A0-cause-de-MD5">http://fiddy.free.fr/blog/index.php?post/2009/01/18/L-art-de-briser-SSL-%C3%A0-cause-de-MD5</a>.</p>
<p>Je rappelle ci-dessous quelques propriétés que doivent respecter les fonctions de hachage :</p>
<ul><li>résistance à la première pré-image : réputé difficile de trouver un antécédent connaissant son image.</li>
<li>résistance à seconde pré-image : réputé difficile de trouver une entrée différente possédant le même condensé. </li>
<li>résistance aux collisions : réputé difficile de trouver deux entrées possédant le même condensé.
</li>
</ul>
<p>Dans cet article, je vais vous montrer un autre cas d'école d'exploitation de collisions en MD5.</p>
<h2>Un peu de théorie...</h2>
<p>Ce cas est rendu possible grâce à la formule : </p>
<pre><code>Soit A et A' deux collisions (ie MD5(A)=MD5(A')) alors, on a MD5(A || B) = MD5(A' || B)</code></pre>
<p>L'idée est donc de créer deux exécutables :</p>
<ul><li>HelloWorld : le début du fichier contient les octets du vecteur A, le reste R est la concaténation des programmes P et Q</li>
<li>Malware : le début du fichier contient les octets du vecteur B, le reste R est la concaténation des prograjmmes P et Q</li>
</ul>
<p>La partie R embarque la charge saine "HelloWorld" et la charge malicieuse "Malware".</p>
<p>La difficulté est donc de trouver une astuce pour que le programme B ait un comportement différent selon le fichier dans lequel il est écrit.</p>
<em>Note : non, ce n'est pas possible que le comportement soit fonction du nom du fichier puisqu'une justement les fichiers auront le même nom pour mieux berner la victime.</em>
<p>Nous allons empaqueter le programme. Un programme empaqueté (qu'on appellera binaire par la suite) est un fichier binaire non exécutable qui à l'aide d'un dépaqueteur libérera un exécutable. Ici, le dépaqueteur libérera le programme "HelloWorld" du binaire s'il contient le vecteur A en début de fichier, sinon la charge malveillante "Malware".</p>
<h2>Passons aux choses sérieuses...</h2>
<p>Le TP se fera en plusieurs étapes :</p>
<ol><li>Recherche d'une collision</li>
<li>Création de HelloWorld et de Malware</li>
<li>Création d'un outil pour générer le binaire</li>
<li>Création du dépaqueteur</li>
<li>Et le meilleur : la démonstration</li>
</ol>
<h3>Génération d'une collision</h3>
<p>Il existe pléthore d'outils de génération de collisions de MD5 sur le net. J'utilise donc une collision MD5 quelconque :</p>
<pre>d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70
d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70</pre>
<p>Avec un peu de recherche sur les moteurs de recherche, vous générerez vos propres collisions.</p>
<p><strong>Vérification</strong></p>
<pre><code>import binascii, hashlib<br />
A='d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70'
B='d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70'<br />
vect1=binascii.a2b_hex(A)
vect2=binascii.a2b_hex(B)<br />
hashlib.md5(vect1).hexdigest() => '79054025255fb1a26e4bc422aef54eb4'<br />hashlib.md5(vect2).hexdigest() => '79054025255fb1a26e4bc422aef54eb4'</code></pre>
<p>Les deux chaînes hexa ont bel et bien le même MD5.</p>
<h3>Création de HelloWorld et de Malware</h3>
<p><strong>Contenu de HelloWorld.c</strong></p>
<pre><code>#include <stdio.h><br />
/*HelloWorld*/<br />int main(void) {<br /> puts("Bonjour tout le monde !!!");<br /> getchar();<br /> return 0;<br />}
</code></pre>
<p><strong>Génération de l'exécutable</strong></p>
<pre><code>$ gcc -Wall -pedantic HelloWorld.c -o HelloWorld.exe</code></pre>
<p><strong>Contenu de Malware.c</strong></p>
<pre><code>#include <stdio.h><br />
/*Malware*/<br />int main(void) {<br /> puts("Ceci est un malware, ou pas...");<br /> getchar();<br /> return 0;<br />}
</code></pre>
<p><strong>Génération de l'exécutable</strong></p>
<pre><code>$ gcc -Wall -pedantic Malware.c -o Malware.exe</code></pre>
<h3>Création d'un outil pour générer le binaire</h3>
<p>Nous allons nous servir du langage Python 3.</p>
<pre><code>import binascii<br />
A='d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70'
B='d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70'
<br />#On convertit les chaînes en vecteurs<br />vect1=binascii.a2b_hex(A)<br />
vect2=binascii.a2b_hex(B)<br /><br />#Création des binaires<br />packHelloworld=open('HelloWorld.bin','wb')
packMalware=open('Malware.bin','wb')<br /><br />#Lecture des exécutables
helloworld=open('HelloWorld.exe', 'rb').read()
malware=open('Malware.exe', 'rb').read()<br /><br />#On écrit vect1 + helloworld + malware dans le fichier <br />packHelloworld.write(vect1)<br />
packHelloworld.write(helloworld)
packHelloworld.write(malware)<br /><br />#On écrit vect2 + helloworld + malware dans le fichier
packMalware.write(vect2)
packMalware.write(helloworld)
packMalware.write(malware)<br />
#Fermeture des fichiers
packHelloworld.close()
packMalware.close()
</code></pre>
<p><strong>Vérification</strong></p>
<pre><code>$ md5sum HelloWorld.bin; sha1sum HelloWorld.bin<br />8d3812393b08a0fb472e0377ccf81443 *HelloWorld.bin<br />c9e495cd93641cf8925ab28923db359fdd75a8ca *HelloWorld.bin<br />
$ md5sum Malware.bin; sha1sum Malware.bin<br />8d3812393b08a0fb472e0377ccf81443 *Malware.bin<br />60e6fb662a54b9a0831b84fd0c4c6b4d9ce1bfb4 *Malware.bin<br /></code></pre>
<p>Nous avons fabriqué deux binaires différents (la preuve puisque les SHA-1 sont différents) ayant le même MD5. </p>
<h3>Création du dépaqueteur</h3>
<p>Le dépaqueteur doit à partir de HelloWorld.bin (resp. Malware.bin) récupérer HelloWorld.exe (resp. Malware.exe). Pour rappel, Malware.bin et HelloWorld.bin auront bien sûr le même nom. Seul le début des deux binaires sera différent (utilisation des deux vecteurs de collision).</p>
<p>Vous avez sans doute remarqué la forte similitude entre les deux chaînes hexa A et B. Déterminons les offsets des bytes divergents :</p>
<pre><code>import binascii<br />
A='d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70'
B='d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70'<br />
vect1=binascii.a2b_hex(A)
vect2=binascii.a2b_hex(B)<br />
for i in range(len(vect1)):<br /> if(vect1[i]!=vect2[i]):<br /> print("vect1[%d]=0x%x, vect2[%d]=0x%x" %(i, vect1[i], i, vect2[i]))<br /></code></pre>
<p><strong>Résultat du script</strong></p>
<pre><code>vect1[19]=0x87, vect2[19]=0x7<br />vect1[45]=0x71, vect2[45]=0xf1<br />vect1[59]=0xf2, vect2[59]=0x72<br />vect1[83]=0xb4, vect2[83]=0x34<br />vect1[109]=0xa8, vect2[109]=0x28<br />vect1[123]=0x2b, vect2[123]=0xab<br /></code></pre>
<p>Nous allons par exemple prendre l'offset 19 et le comparer avec 0x87. S'il y a égalité, alors le dépaqueteur extrairera la charge saine sinon la charge malveillante. Nous avons également besoin de connaître les tailles des vecteurs ainsi que des fichiers HelloWorld.exe et Malware.exe.</p>
<pre><code>$ print("len(vect1)=%d, len(vect2)=%d" % (len(vect1), len(vect2)))<br />len(vect1)=128, len(vect2)=128<br />
$ print("len(helloworld)=%d, len(malware)=%d" % (len(helloworld), len(malware)))<br />len(helloworld)=29220, len(malware)=29220</code></pre>
<p>Sans surprise, les tailles des deux vecteurs ont la même taille. En revanche, la taille des deux exécutables peut être différente. Le depaqueteur attendra en paramètre le binaire à dépaqueter.</p>
<pre><code>import sys<br />TailleVect=128<br />TailleHelloWorld=29220<br />TailleMalware=29220<br /><br />binaire=open(sys.argv[1],'rb').read()<br />output=open('output.exe', 'wb')<br /><br />if binaire[19]==0X87:<br /> #extraction de HelloWorld.exe<br /> output.write(binaire[TailleVect:TailleVect+TailleHelloWorld])<br />else:<br /> #extraction de Malware.exe<br /> output.write(binaire[TailleVect+TailleHelloWorld:TailleVect+TailleHelloWorld+TailleMalware])<br /><br />output.close()</code></pre>
<h3>Démonstration</h3>
Pour mieux mettre en exergue la supercherie, j'ai renommé les deux binaires en Jeu.bin. Je ne détaillerai pas d'exemples d'attaque pour ne pas donner d'idées. Mais, les lignes suivantes parlent d'elles-même.<br /><pre><code>$ md5sum Jeu.bin<br />8d3812393b08a0fb472e0377ccf81443 *Jeu.bin</code></pre>
<pre><code>$ python depaqueteur.py Jeu.bin<br />$ output.exe<br />Bonjour tout le monde !!!<br />
$ md5sum Jeu.bin<br />8d3812393b08a0fb472e0377ccf81443 *Jeu.bin<br />
$ python depaqueteur.py Jeu.bin<br />$ output.exe<br />Ceci est un malware, ou pas...</code></pre>
<p>A travers cet article, vous avez vu comment exploiter une collision MD5. Il s'agit d'un exemple simple avec un empaqueteur. A titre d'exercice, vous pouvez largement améliorer les programmes. Par exemple, vous pouvez mettre les tailles des exécutables (HelloWorld.exe et Malware.exe) dans le binaire. Ici, on s'en rend compte facilement de l'arnaque en lisant depaqueteur.py. Mais il peut être écrit dans un langage compilé pour empêcher une lecture simple du programme.</p>
<p>Il est possible de faire encore mieux en se passant du système de packetage en exploitant d'autres combines. Cela est un peu plus compliqué et fera peut-être l'objet d'un prochain article. D'ici-là, je vous conseille d'utiliser d'autres fonctions de hachage.</p>http://fiddy.free.fr/blog/index.php?post/2014/01/18/Jouons-avec-le-MD5#comment-formhttp://fiddy.free.fr/blog/index.php?feed/atom/comments/9Quelle sécurité pour notre Wi-Fi ?urn:md5:a68de9fd8cf72c199e6665bfcf902a562009-05-17T21:27:00+02:00fiddySécurité <p>Les accès Wi-Fi sont sources de convoitise pour plusieurs raisons :</p>
<ul><li>obtenir un accès à Internet</li>
<li>usurper l'adresse IP de l'équipement incriminé.</li>
</ul>
<p>Si la première raison, à condition de ne pas abuser, n'est pas une fin gênante en soi, la seconde est bien plus grave.</p>
<p>Pour parler un peu d'actualité, imaginez un voisin se connectant sur votre Box et téléchargeant de la musique sur un P2P classique. Celui qui recevra l'avertissement ne sera pas le méchant, mais bien le titulaire de la ligne. Et c'est précisément là que le bât blesse. Ce sont pour ces raisons que j'écris ce billet qui se veut comme un best-practice de la sécurité Wi-Fi dans un cadre non professionnel.</p>
<p>La grande majorité des particuliers se connectent sur Internet via des Box (Freebox, Livebox, ...). Ce présent billet se concentrera donc uniquement sur ces équipements.</p>
<h3>Les sécurités existantes</h3>
<p>
Je ne parlerai que des sécurités simples à mettre en place, c'est-à-dire celles implémentées dans les box. Je ne parlerai donc pas de l'excellente alternative VPN. Les protocoles proposés sont au nombre de trois :</p>
<ul><li><a hreflang="fr" href="http://fr.wikipedia.org/wiki/WEP">WEP</a>,</li>
<li><a href="http://fr.wikipedia.org/wiki/Wi-Fi_Protected_Access#La_s.C3.A9curit.C3.A9_dans_le_mode_pre-shared_key">WPA-PSK, ou WPA Personal</a>,</li>
<li><a href="http://fr.wikipedia.org/wiki/WPA2#La_s.C3.A9curit.C3.A9_dans_le_mode_pre-shared_key">WPA2-PSK ou WPA2 Personal</a>.</li>
</ul>
<p>A noter également sWPA (resp WPA2) Enterprise ou le véritable WPA (resp WPA2), mais cela implique la mise en place d'un serveur Radius qui est un tantinet compliqué pour Madame Michu.</p>
<h4>WEP</h4>
<p>Aujourd'hui, encore beaucoup trop de personnes utilisent du WEP pour "protéger" leur communication. Est-il nécessaire de rappeler que ce protocole est largement désuet ? Qu'il ne tiendra pas cinq minutes face à votre voisin. Et nul besoin d'être un expert tant la documentation abonde sur le net.</p>
<p>Pour ceux qui veulent de la lecture théorique concernant les failles : <a hreflang="fr" href="http://fiddy.free.fr/blog/index.php?post/2008/11/25/Le-WEP-suffisamment-s%C3%A9curis%C3%A9">Le WEP : une passoire</a>.</p>
<p>Avec la suite aircrack-ng, cela peut être aussi simple que :</p>
<pre>airodump-ng -w output -c 11 ath0<br />aireplay-ng -1 0 -e ESSID -a MACofAP -h MACofStation ath0<br />aireplay-ng -3 0-e ESSID -b MACofAP -h MACofStation ath0<br />aircrack-ng *.cap</pre>
<p>Voici un <a hreflang="fr" href="http://www.tuto-fr.com/tutoriaux/tutorial-crack-wep-aircrack.php">lien</a> expliquant le tout en image.</p>
<h4>WPA-PSK et WPA2-PSK</h4>
<p>Je regroupe les deux étant donné qu'il n'y a pratiquement aucune différence. Et non WPA-PSK ne rime pas avec <a hreflang="fr" href="http://fr.wikipedia.org/wiki/TKIP">TKIP</a> puisque <a hreflang="fr" href="http://fr.wikipedia.org/wiki/CCMP">CCMP</a> lui a été backporté. Sur ce sujet, de nombreux articles aux titres maladroits (mais plus aguicheurs) ont été écrits . Conséquence, beaucoup pensent que "WPA ça se pirate et pas WPA2". Alors que <q>la vérité est ailleurs</q>.</p>
<p>Déjà, que les choses soient claires : il ne faut pas confondre WPA(2) et WPA(2)-PSK. WPA(2)-PSK se base sur l'utilisation d'une clé partagée (PSK). L'architecture est donc certes, beaucoup plus simple, mais aussi largement moins sécuritaire.</p>
<p>Il existe principalement deux pistes d'attaque sur la version PSK</p>
<ul><li>l'attaque sur le PSK (brute-force, attaque par dictionnaire),</li>
<li>la faiblesse TKIP.</li>
</ul>
<h5>L'attaque sur le PSK</h5>
<p>L'attaque sur le PSK est très simple. Elle consiste à récupérer le <a hreflang="fr" href="http://fr.wikipedia.org/wiki/IEEE_802.11i#Authentification">4-Way handshake</a> lors de la phase d'authentification et de l'utiliser dans les bruteforceurs. Cette attaque marche très bien sur WPA-PSK, mais également sur WPA2-PSK. Conseiller donc de migrer à WPA2-PSK pour éviter le bruteforce du PSK sur WPA-PSK est donc complètement débile. </p>
<p>La seule protection efficace est l'utilisation d'une passphrase suffisamment robuste pour l'aboutissement des outils de cracks. Il est recommandé de choisir au minimum 20 caractères dénués de sens et d'utiliser des caractères non-alphanumériques (+,*,-,#, etc.).</p>
<p>Un petit <a hreflang="fr" href="http://www.crack-wpa.fr/tutoriel-crack-wpa.php">lien</a> pour vous montrer la simplicité.</p>
<p>Cette attaque est même plus dure à détecter puisqu'après avoir récolté le 4-Way Handshake tout le calcule se réalisera offline. Alors que pour le WEP, il faut sniffer des milliers de paquets, injecter des paquets (où être très patients).</p>
<h5>La faiblesse TKIP</h5>
<p>Là c'est une autre histoire. TKIP est un protocole qui a été créé pour assurer une compatibilité avec les anciens équipements et d'offrir un maximum de sécurité. Oui mais voilà, deux chercheurs ont réussi à exploiter trois faiblesses (adaptation de <a hreflang="en" href="http://www.aircrack-ng.org/doku.php?id=korek_chopchop">ChopChop</a> (<a hreflang="en" href="http://www.aircrack-ng.org/doku.php?id=chopchoptheory">théorie de ChopChop</a>), faiblesse de Michael (algorithme d'intégrité), files de priorité). Pour l'instant les conséquences sont limitées mais il y a aujourd'hui une brèche dans la boîte qui pourrait s'agrandir avec le temps. Il n'y a pas mille remèdes : ne pas utiliser TKIP.</p>
<h3>Quelques fioritures :</h3>
<p>
Devant la facilité à se procurer des outils pour casser une clé WEP, des fioritures sont apparus :</p>
<ul><li>Non-diffusion du <a hreflang="fr" href="http://fr.wikipedia.org/wiki/Service_set_identifier">SSID</a>,</li>
<li>Filtrage par <a hreflang="fr" href="http://fr.wikipedia.org/wiki/Adresse_MAC">adresse MAC</a>.</li>
</ul>
<p>Ces deux protections n'apportent rien à part un semblant de sécurité.</p>
<h4>Non-diffusion du SSID</h4>
<p>Certains se disent que si dans les requêtes, le SSID est substitué à une chaîne de caractère vide, on est à l'abri. Eh bien il n'en est rien.</p>
<p>Lors de l'association à l'AP, le client enverra des probe requests avec les SSID enregistrés en local afin d'obtenir une réponse d'un AP (Acess Point) connu. Donc, si un attaquant est patient, il récupérera le SSID lors de cette phase. Et puis, cette "sécurité" peut même donner lieu à d'autres attaques comme le <a hreflang="en" href="http://en.wikipedia.org/wiki/Rogue_access_point">Rogue AP</a>, à cause de la fuite d'information qu'engendre les probe requests.</p>
<h4>Filtrage par MAC</h4>
<p>Cette "sécurité" part du principe que l'adresse MAC est une adresse unique. Certes, mais au-dessus de la couche hardware se trouve une couche logicielle permettant de changer l'adresse MAC. Et quitte à changer d'adresse, autant opter pour une adresse déjà associée à l'AP (obtenue par un logiciel du style Airodump, Kismet, ...). Protection donc inutile.</p>
<p>Pour vous convaincre de la facilité, voici la commande sur Gnu/Linux :</p>
<pre>ifconfig interface hw ether 00:01:02:03:04:05</pre>
<p>Sur windows, c'est un peu plus cliquissime.</p>
<h3>Conclusion</h3>
<p>Dans ce billet, j'ai expliqué brièvement que :</p>
<ul><li>le WEP est à bannir parce que cryptographiquement mauvais,</li>
<li>la non-diffusion du SSID est contre-productif,</li>
<li>le filtrage par adresse MAC se contourne aisément,</li>
<li>les passphrases doivent être robustes,</li>
<li>TKIP commence à rouiller.</li>
</ul>
<p>Ce qui élimine pas mal des fonctionnalités de la Box. Finalement, pour être à l'abri, il faut utiliser WPA-PSK + AES et WPA2-PSK + AES.</p>
<p>La passphrase (à ne pas confondre avec password) doit être solide (supérieure à 20 caractères). N'hésitez pas à consolider votre passphrase qui sera la voûte de votre sécurité Wi-Fi, d'autant plus qu'elle ne sera qu'à rentrer une fois pour toute sur votre machine.</p>http://fiddy.free.fr/blog/index.php?post/2009/05/17/Quelle-s%C3%A9curit%C3%A9-pour-notre-Wi-Fi#comment-formhttp://fiddy.free.fr/blog/index.php?feed/atom/comments/8Quand les AC utilisent MD5...urn:md5:62906b3aff437b65d12928ca34fe67e82009-01-18T00:48:00+01:00fiddySécurité <p>Récemment, des chercheurs ont fait une brillante démonstration de la faiblesse de MD5. Ils ont réussi à exploiter des collisions dans la fonction de hachage, et à prédire des serial numbers sur une AC afin de créer un rogue certificat d'Autorité de Certification (AC). Conséquence ? Possibilité de signer un certificat d'AC signée par une AC de confiance. Donc possibilité à gogo de créer de vrais certificats acceptés par les navigateurs. Je vous laisse imaginer les conséquences désastreuses.</p>
<h3>Explication de la méthode</h3>
<p>Comme dit dans l'introduction, le cœur de l'attaque est MD5. Mais pas seulement. L'utilisation d'un Serial Number trop facilement prévisible ainsi que de la date de création du certificat a permit l'exploit.</p>
<h4>MD5 : fin d'une vie</h4>
<p>Son but, comme toute fonction de hachage, est de donner une empreinte numérique de 16 octets. Elle doit posséder plusieurs propriétés :
</p>
<ul>
<li>résistance à la première pré-image :réputé difficile de trouver un antécédent connaissant son image.</li>
<li>résistance à seconde pré-image : réputé difficile de trouver une entrée différente possédant le même condensé. </li>
<li>résistance aux collisions : réputé difficile de trouver deux entrées possédant le même condensé.
</li>
</ul>
<p>
Mais MD5 ne respecte plus la dernière propriété. Il existe des algorithmes suffisamment performants pour générer des collisions.</p>
<h4>Rapide autopsie d'un certificat X.509</h4>
<h5>Structure</h5>
<p>Dans un certificat X.509, nous trouvons plusieurs champs comme :</p>
<ul><li>Version</li>
<li>Serial Number</li>
<li>Algorithme de hash (ici, ce sera MD5)</li>
<li>Nom du signataire</li>
<li>Validité</li>
<li>Détendeur</li>
<li>Algorithme de clé publique</li>
<li>Clé publique</li>
<li>...</li>
</ul>
<h5>Vérification</h5>
<p>Ces informations (M) vont être signées par l'AC avec sa clé privée D (dont sa clé publique associée est E) empêchant toute altération du certificat. Grosso modo, le certificat est donc de la forme : M | S, avec S=D(M) et | opérateur de concaténation.
</p>
<p>En effet, à la réception du certificat sur un site HTTPS, le navigateur va :</p>
<ul><li>regarder la date du certificat,</li>
<li>comparer MD5(M) et P(S),</li>
<li>vérifier de proche en proche la validité des certificats des signataires jusqu'à en trouver un de confiance dans sa base.</li>
</ul>
<p>Si le certificat n'est pas valide, ou si le navigateur est remonté au certificat root sans en trouver un de confiance, celui-ci émettra un avertissement.</p>
<h4>Prérequis de l'attaque</h4>
<p>
En plus de trouver une AC utilisant MD5 en hachage, il faut que celui-ci utilise une génération de serial number prévisible et qu'on puisse deviner la date de création du certificat. RapidSSL a donc logiquement été choisi comme cible :</p>
<ul><li>six secondes entre la demande et la création du certificat,</li>
<li>le serial number est simplement incrémenté à chaque certificat</li>
</ul>
<h4>Attaque</h4>
<p>Les deux champs que l'attaquant ne maîtrise pas dans le certificat sont la date de création du certificat et le serial number. Le but est donc de réussir à ce que l'AC signe notre certificat avec un serial number donné à une date donnée.</p>
<p>Sachant qu'il faut environ trois jours pour obtenir une collision "jouable" sur 200 playstations mises en clusters (configuration des chercheurs), il faudra être capable de prédire un serial number trois jours à l'avance.</p>
<p>Ainsi, trois jours à l'avance, on achète un certificat pour connaître le serial number SN. On prévoit que 72 heures plus tard, le serial number sera un peu plus petit que SN+1000, sachant que SN+1000 correspond au serial number que nous voulons obtenir à la date T pour respecter notre collision. Comment faire ?</p>
<p>Quelques heures avant T, on achète des certificats pour se rapprocher de plus en plus de SN + 1000 de sorte que 30 secondes avant T, le serial number soit à SN+999. Ensuite, il ne reste plus qu'à envoyer une demande de certificat à T-6 (cf prérequis) pour obtenir un certificat signé avec pour serial number SN+1000 dont la date de création est T.</p>
<p>Il ne reste plus qu'à mettre la signature du vrai certificat sur le rogue certificat d'AC créé lors de notre collision. Et comme les MD5 sont les mêmes, la signature sera la même. Nous sommes dont en présence d'un certificat d'AC ayant une signature valide puisque signée par une AC de confiance bien que cette dernière ne l'a pas vu.</p>
<h4>Conséquence</h4>
<p>Avec un certificat d'AC valide dont on a la clé privée, il est possible de bypasser complètement l'intérêt de SSL. En effet, il est possible de créer les certificats qu'on veut grâce à notre rogue certificat. Le navigateur n'y verra que du feu. Les attaques Man-in-the-Middle n'échoueront donc pas, même en SSL. Désastreux. En combinaison avec la vulnérabilité récente du DNS trouvé par Kaminsky, un pirate parviendra à faire du phishing indétectable.</p>
<h4>Solution</h4>
<p>Pour les AC, ne pas utiliser MD5 en tant que fonction de hachage. Même si on le sait depuis longtemps que MD5 n'est plus sûr, on a enfin un PoC. Il faut utiliser au moins SHA-1 ou mieux SHA-256.</p>
<p>Il est également important pour les AC de fournir un Serial Number non prévisible.</p>
<p>Il faut renouveler toutes les AC impactées et tous les certificats générés par ces dernières.</p>
<p>Pour les particuliers, il peut être intéressant d'utiliser Perspectives comme plugin pour firefox qui se base sur un réseau de notaires.</p>
<h4>Note</h4>
<p>Il est important de souligner que c'est MD5 le fautif et non SSL.</p>
<h4>Lien</h4>
<ol><li>http://www.win.tue.nl/hashclash/rogue-ca/</li>
<li>http://eprint.iacr.org/2005/067</li>
<li>http://sid.rstack.org/blog/index.php/316-ssl-n-est-pas-mort-contrairement-a-md5</li>
<li>http://www.unixgarden.com/index.php/securite/les-fonctions-de-hachage-sortiraient-elles-de-lombre</li>
</ol>http://fiddy.free.fr/blog/index.php?post/2009/01/18/L-art-de-briser-SSL-%C3%A0-cause-de-MD5#comment-formhttp://fiddy.free.fr/blog/index.php?feed/atom/comments/7Le WEP : une passoireurn:md5:63453eb4452e58b34a73b1aef597ad3a2008-11-25T13:45:00+01:00fiddySécurité <p>Récemment, j'ai lu que le WEP c'était pareil que le WPA. Tenir de tels propos est honteux, tellement que le WEP est à la ramasse et ne vaut rien niveau sécurité. Dans ce billet, je vais vous expliquer le fonctionnement du WEP, puis vous montrer ses faiblesses et comment les exploiter.</p>
<p>Un point sur la notation que je vais employer durant ce billet :</p>
<ul><li>|| opérateur de concaténation. Exemple : <pre>ABCD || E = ABCDE</pre></li>
<li>+ représente le XOR (ou exclusif), à ne surtout pas confondre avec la simple addition. Exemple : <pre>1010(2) + 1100(2) = 0110(2)</pre></li>
<li>M représente le message clair</li>
<li>C représente le chiffré</li>
<li>K représente la clé WEP</li>
</ul>
<p>De plus dans la suite de l'article, je vais dire que l'AP ou le client va envoyer comme requête :</p>
<pre>IV||C</pre><p>Cela est pour simplifier les choses. En fait, Il faut garder à l'esprit qu'il y a l'header 802.11, le BSSID, l'IV et l'adresse de destination en clair. Ensuite, en chiffré vienne LLC, SNAP, le message, et l'ICV.</p>
<h3>Le WEP en une phrase</h3>
<p>Le WEP (Wired Equivalent Privacy) est un protocole de chiffrement pour les réseaux Wi-Fi IEEE 802.11. Pour plus d'informations à ce sujet : <a href="http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy">go to wiki</a></p>
<h3>Explication du protocole</h3>
<p>Un paquet est formé respectivement de :</p>
<ul><li>IV +Pad + KeyID (4 octets)</li>
<li>PDU (> 0)</li>
<li>ICV (4 octets)</li>
</ul>
<h4>IV (Initialisation Vector) + Pad + KeyID</h4>
<p>Ce champ de 4 octets se compose en trois sous-champs : </p>
<ul><li>IV (3 octets) : qui va être utilisé comme seed</li>
<li>Pad (6 bits)</li>
<li>KeyID (2 bits)</li>
</ul>
<p>Le dernier octet (Pad + KeyID) n'est pas important pour la suite de l'article.</p>
<h4>PDU (Protocol Data Unit)</h4>
<p>Ce champ représente l'information envoyée par la couche 3 (réseau) qui va être chiffrée. Une fois déchiffré, et si tout s'est bien déroulé, le message sera passé à la couche réseau. Par la suite, j'utiliserai la notation M (au lieu de PDU) dans les calculs
pour les alléger.</p>
<h4>ICV (Integrity Check Value)</h4>
<p>Ce champ de redondance de 4 octets permet de prévenir l'altération de données accidentelles pendant la transmission. J'insiste sur le mot "accidentelle", car cela n'a pas le même but que les fonctions de hachage permettant de s'assurer de l'altération d'un message par un tiers. WEP utilise le fameux CRC32 comme ICV.</p>
<h4>Le chiffrement WEP</h4>
<p>WEP utilise un chiffrement par flot (XOR) pour crypter les données, la
clé étant obtenu par le PRNG du chiffrement RC4. Prenons l'exemple d'une clé WEP 128 bits. L'utilisateur choisit en fait 104 bits, soit 26 caractères hexadécimaux. Ceci représentera véritablement la clé WEP qu'on notera K par la suite. Elle sera concaténée avec l'IV qui changera pour chaque paquet. 104 bits (K) + 24 bits (IV) donne bien 128 bits. Ouf !</p>
<p>Et sans plus attendre, l'algorithme du chiffrement WEP :</p>
<pre>C = RC4(IV||K) + (M||CRC(M))</pre><p>Alors, le paquet qui sera envoyé sera :</p>
<pre>IV||C</pre><p>Pour le déchiffrement, le destinataire va recevoir donc le paquet ci-dessus. Il va décapsuler l'IV et calculer :</p>
<pre>RC4(IV||K) + C = RC4(IV||K) + (RC4(IV||K) + (M||CRC(M)) = M||CRC(M)</pre><p>Il ne lui reste plus qu'à décapsuler M, de calculer son ICV et de le comparer avec CRC(M). Si la vérification s'avère correcte, le PDU sera envoyé à la couche supérieure, sinon WEP générera une erreur MAC.</p>
<h4>L'authentification</h4>
<p>Tout dépend du mode utilisé :</p>
<ul><li>Open System Authentication</li>
<li>Shared Key Authentication</li>
</ul>
<p>Dans le premier mode (Open System Authentication), le client n'a aucune donnée à fournir pour s'authentifier. Il tente donc directement l'association (le filtrage par adresses MAC peut faire échouer cette étape par exemple). Le client devra quand même posséder la clé WEP pour pouvoir dialoguer par la suite, et c'est heureux.</p>
<p>Dans le second mode (Shared Key Authentication), un 4 Way Challenge-response aura lieu :</p>
<ul><li>le client envoie une requête d'authentification,</li>
<li>l'AP envoie un challenge en clair,</li>
<li>le client chiffre le challenge en utilisant sa clé WEP et l'envoie à l'AP,</li>
<li>l'AP déchiffre la trame reçu et compare au challenge. Le résultat de la comparaison donnera lieu ou non à l'authentification. Même remarque pour l'association.</li>
</ul>
<h3>Les faiblesses ?</h3>
<h4>L'authentification</h4>
<p>On pourrait penser que l'authentification par clé partagé est meilleure, puisqu'en fait l'autre n'offre aucune authentification proprement dite. Et pourtant...</p>
<p>Lors de l'authentification (Shared Key Authentication), l'AP va envoyer un challenge en clair, qu'on va noter M. Et le client va renvoyer le challenge chiffré, qu'on va noter C. Ainsi, une personne malveillante (Oscar) sniffant le réseau peut récupérer M et C.</p>
<pre>IV||C avec :<br />C = RC4(IV||K) + (M||CRC(M)<br />donc : RC4(IV||K) = C + (M||CRC(M)) = P</pre><p>Donc Oscar va pouvoir récupérer le PRNG (P) sur 128 octets (taille du challenge) correspondant à l'IV utilisé par le client. Et comme rien dans WEP n'empêche le rejeu, cette quantité sera acceptée par l'AP. Maintenant Oscar tente de s'authentifier sur l'AP qui va lui envoyer un challenge M'. Oscar, sans connaître la clé K enverra :</p>
<pre>IV||C' avec :<br />C' = P + (M'||CRC(M')</pre><p>De son côté l'AP déchiffrera C' avec l'IV envoyé par Oscar.</p>
<pre>RC4(IV||K) + C' = RC4(IV||K) + P + (M'||CRC(M') = M'||CRC(M')</pre><p>Et, paf, voilà Oscar authentifié, sans aucun calcul si ce n'est que le CRC du challenge. Donc, il vaut mieux ne pas utiliser l'authentification par clé partagé sous risque de donner à Oscar un PRNG valide avec son IV correspondant et qu'il pourra réutiliser à volonté.</p>
<h4>Le chiffrement</h4>
<p>Le chiffrement est guère mieux que l'authentification étant donné la faiblesse du chiffrement RC4. Il est possible de :</p>
<ul><li>déchiffrer un quelconque paquet facilement,</li>
<li>injecter des données,</li>
<li>et deviner la clé K</li>
</ul>
<h5>Faiblesse </h5>
<p>Dans un réseau IEEE 802.11 chiffré, il n'est pas dur de prédire le payload des en-têtes. Généralement, le début de la sortie RC4 sera "Xoré" avec le payload LLC/SNAP. Ce qui donne :</p>
<ul><li>AAAA030000000800 pour un paquet IP</li>
<li>AAAA030000000806 pour un paquet ARP</li>
</ul>
<p>Si on applique le chiffrement WEP au payload LLC/SNAP, cela donne :</p>
<pre>C=RC4(IV||K) + M||CRC(M) <br />Soit RC4(IV||K) = C + (M||CRC(M)) avec IV, M, IV connus.</pre><p>M a une taille de 8 octets (taille LLC/SNAP) et CRC(M) a une taille de 4 octets. Ce qui donne une sortie de 12 octets pour le flux RC4 qu'on peut calculer pour l'IV donné. En jouant avec la fragmentation 802.11 (qui imite à 16 fragments), nous pouvons chiffrer une trame suffisamment longue pour stimuler le réseau. Par exemple :</p>
<ol><li>AAAA0300 CRC</li>
<li>00000800 CRC</li>
<li>Débu CRC</li>
<li>t de CRC</li>
<li> not CRC</li>
<li>re p CRC</li>
<li>aylo CRC</li>
<li>ad. CRC</li>
<li>ETC CRC</li>
</ol>
<p>Et si la trame est destinée au réseau local, l'AP défragmentera le paquet et l'enverra par onde avec une nouvelle IV. Nous allons donc recevoir une nouvelle trame C de longueur 128 (8*16). Puis on recommence la fragmentation pour obtenir un paquet de longueur 1024 (128*16). Et en répétant une dernière fois ce processus, nous aurons connaissance d'un flux RC4 de la taille du MTU correspondant à un IV particulier. L'injection de n'importe quel paquet est désormais possible.</p>
<h5>Exploitation</h5>
<p>Et maintenant si on simule le réseau, (avec des paquets ARP comme le fait très bien aireplay), on peut se constituer une table RC4 en fonction d'un IV. Avec le recul qu'on a sur le chiffrement RC4, plusieurs faiblesses ont été décrites. Et le résultat est impressionnant : cassage de la clé WEP en 10 minutes (puis 1 minute avec le dopage apporté par la version PTW).</p>
<p>Il est important de remarquer que l'attaque n'a rien à voir avec du brute-force. Auquel cas, casser une clé 104 mettrait beaucoup plus de temps que 40 bits (puisqu'exponentiel). Là, il en est autrement, et on observe que l'attaque met à peine deux fois plus longtemps.</p>
<h5>Camouflage de l'ESSID et filtrage MAC</h5>
<p>Certains pensent avoir trouvé la parade en empêchant la diffusion du SSID et en filtrant les adresses MAC. Oui mais parade sans réel efficacité.</p>
<p>En effet, si on camoufle l'ESSID, un client légitime donnera la liste de ses ESSID enregistrés sur la machine jusqu'à connexion. Et si quelqu'un sniffe le réseau à ce moment-là, il obtient non seulement le bon ESSID, mais en plus les autres enregistrés chez le client. Donc pas efficace à part une fuite d'informations.</p>
<p>Et le filtrage MAC, c'est guère mieux. Si Oscar sniffe le réseau, il va obtenir l'adresse MAC d'un client autorisé (sinon autant désactiver le Wi-Fi). Il ne reste plus qu'à usurper ladite adresse MAC, et hop retour au cassage du WEP.</p>
<h3>Et donc, que faire ?</h3>
<p>La conclusion est sans appel et très simple. Il ne faut plus utiliser le WEP. Qu'il soit en 64, 128 ou 256 bits, il reste très faible. Il faut donc utiliser WPA ou mieux encore WPA2 pour l'authentification, et TKIP* (ou CCMP/AES si cela est compatible avec le driver de votre carte, avec votre OS et avec le firmware de l'AP). A noter que la version PSK de WPA est beaucoup moins sécurisé que WPA enterprise. Mais tout le monde ne peut pas se monter un serveur radius.</p>
<p>Il est également possible d'utiliser un VPN.</p>
<p>(*) TKIP : La version TKIP a vu quelques attaques dirigées contre elle. Il est donc conseillé d'utiliser CCMP/AES.</p>
<h3>Lien</h3>
<ol><li>http://wiki-files.aircrack-ng.org/doc/wepexp.txt</li>
<li>http://sid.rstack.org/blog/index.php/56-pourquoi-c-est-pourri-le-wep-part-1-comment-ca-marche</li>
<li>http://sid.rstack.org/blog/index.php/57-pourquoi-c-est-pourri-le-wep-part-2-cassage-en-regle</li>
<li>http://sid.rstack.org/blog/index.php/60-pourquoi-c-est-pourri-le-wep-part-3-comment-se-protege-t-on-alors</li>
<li>http://standards.ieee.org/getieee802/download/<em>802.11i-2004.pdf</em></li>
</ol>http://fiddy.free.fr/blog/index.php?post/2008/11/25/Le-WEP-suffisamment-s%C3%A9curis%C3%A9#comment-formhttp://fiddy.free.fr/blog/index.php?feed/atom/comments/6Le C, pas si facile que çaurn:md5:12a5dbbc0e0c87c207f1383d10d3fde62008-11-22T13:22:00+00:00fiddySécurité <p>Sur internet, on voit pas mal de chose. Récemment j'ai pu lire que le C était un langage facile. Si on peut s'habituer à la syntaxe relativement vite, produire un code portable et sécurisé est en revanche une autre paire de manche. Sceptique ? Combien de personnes vident le flux écran après affichage à l'écran sans '\n' ? Combien de personnes utilisent scanf ou fgets sans contrôle du retour ou sans vider le buffer clavier ? Probablement beaucoup, voire la majorité. La faute au facteur temps ou pire l'ignorance.
</p>
<h3>printf</h3>
<p>
Avant de fixer la règle, il faut savoir que printf envoie des caractères au buffer écran. Ce dernier se vide automatiquement lorsqu'il est rempli ou lorsqu'il y a un <strong>'\n'</strong>.
Donc, l'instruction :</p>
<pre>printf("Bonjour");</pre>
<p>ne forcera pas l'affichage de <strong>"Bonjour"</strong> à l'écran. Il faut utiliser :</p>
<pre>printf("Bonjour");<br />fflush(stdout);</pre>
<p>pour vider le flux.<br />
A noter que <strong>printf("Bonjour\n");</strong> ou <strong>puts("Bonjour");</strong> n'ont pas besoin de vidage du flux car il y a envoi du <strong>'\n'</strong> dans le flux sortie.</p>
<h3>scanf, fgets</h3>
<pre>char buf[10];<br /><del>scanf("%s",s);</del></pre>
<p> est à proscrire et pour simple raison, il n'y a pas de contrôles sur la longueur maximale de la chaîne.</p>
<pre>scanf("%9s",s);</pre>
<p> serait déjà beaucoup mieux. Mais que se passe-t-il si la longueur est variable ? Non, on ne peut pas mettre de variables à la place du 9. Dans ce cas, il faut utiliser des macros, ce qui complique le code. Sans penser que certains oublieront d'imposer la taille dans le scanf.
<br />
Donc, il est mieux de ne pas se poser de questions, et d'utiliser :</p>
<pre>fgets(buf,sizeof buf,stdin);</pre>
<p>Ici, il y a contrôle la taille, et utilisation d'une variable pour la longueur.
Sauf que voilà, ça ne suffit pas. Tout caractère passé au-delà de la taille sera ajouté au buffer. Faut donc vider ce dernier.
Pour le vider, il faut utiliser : </p>
<pre>int c; <br />while((c=getchar())!='\n' && c!=EOF);</pre>
<p>et non :</p>
<del><pre>fflush(stdin);</pre></del>
<p>dont la fonctionnalité est incertaine.
<br />
Ce qui donne comme code :
</p>
<pre>int c;<br />char buf[10];<br />fgets(buf,sizeof(buf),stdin);<br />while((c=getchar())!='\n' && c!=EOF);</pre>
<p>Oui, mais si l'utilisateur entre une chaîne trop petite, le <strong>'\n'</strong> va se stocker dans buf et du coup, boucle infinie avec <strong>while</strong>.
Donc, il faut tester soit la longueur de la chaîne entrée par l'utilisateur soit rechercher le <strong>'\n'</strong> pour en déduire si le <strong>'\n'</strong> est dans le buffer clavier ou pas. On va privilégier la deuxième technique parce qu'en plus, on pourra virer le <strong>'\n'</strong> stocké dans la chaîne.
<br />
Et puis, n'oublions pas qu'il faut vérifier la sortie de fgets pour détecter une erreur.
Au final, voici le code, portable et sécurisé.
</p>
<pre>int c;<br />char *pbuf;<br />if( fgets(buf,sizeof(buf),stdin) != NULL ) {<br /> if( (p=strchr(buf,'\n')) != NULL )<br /> *p='\0';<br /> else<br /> while( (c=getchar()) != '\n' && c != EOF );<br />}</pre><p>
<br />
Bien sûr, pour les entrées de nombres, c'est pareil. N'utilisez pas <strong>scanf("%d",&a);</strong> car si l'utilisateur entre des lettres à la place, <strong>scanf</strong> va sauter. Donc, il vaut mieux utiliser <strong>fgets</strong> puis traiter la chaîne (strtol par exemple) pour récupérer le nombre.
</p>
<h3>Et si, je fais pas de contrôle ?</h3>
<p> Alors bien sûr, certains vont se dire que ce code, c'est pur parano. Eh bien non, car en manquement de ceci, voici ce qui pourrait se produire.
<br />
Regardons le code :</p>
<pre>int toto=5;<br />char buf[10];<br /><del>scanf("%s",buf);</del><br />printf("%d",toto);</pre>
<p><br />
Si l'utilisateur entre une chaîne de dix <strong>'a'</strong> par exemple, le dernier <strong>'a'</strong> s'écrira dans la chaîne. Quid du '\0' ? Il débordera. Donc <strong>toto</strong> va devenir égal à <strong>0</strong> (l '\0' a débordé).</p>
<p>Imaginez-vous maintenant qu'un pirate utilise votre code (qui a le bit setuid d'activé), et qui mette une chaîne trop grande aussi. Très rapidement, il va tomber sur l'eip (registre contenant l'adresse de la prochaine instruction à exécuter). Il n'a plus qu'à modifier cette adresse vers une autre en mémoire contenant un joli shellcode (en faisant attention au boutisme) pour que la machine exécute le code malveillant avec les droits root. Au final, le pirate peut faire exécuter ce qu'il veut.
Je ne rentrerais pas plus dans les détails de cette attaque, le but étant juste de vous démontrer qu'il est important de sécuriser son code</p>
<h4>Note pour ceux qui ont testé de récrire sur l'EIP</h4>
<p>
Il est fort probable que ceux qui testent reçoivent : <strong>*** stack smashing detected ***</strong>.
Normal, les compilateurs connaissent maintenant ces attaques (bufferOverflow) et rajoutent quelques octets
de sécurité (le canary). Si ces octets ont été modifiés, c'est qu'il y
a eu débordements en mémoire, et on affiche le joli message. Pour
tester, il faut compiler avec <strong>-fno-stack-protector</strong> sur gcc.
</p>
<h3>Conclusion</h3>
<p>Vous pouvez vous dire que le fameux canary peut régler cette attaque. Sauf qu'on veut du code portable, et que tous les compilateurs n'ont pas cette fonctionnalité. Et puis, une sécurité ça se passe. Bien qu'elle soit assez efficace, dans certains cas, on peut écrire au-delà du canary sans l'altérer. Et puis, si l'application est sur un serveur et qu'on compte sur la protection du compilateur, une personne malveillante pourrait facilement faire crasher le programme, provoquant un joli déni de service.
</p>
<p>Si on applique, et il faut, tous ses éléments et je n'ai pas été exhaustif, le C n'est plus si facile que ça, voire même carrément difficile.
Heureusement, que la plupart des autres langages ne sont pas aussi critiques. Les autres langages ont souvent un type string qui s'occupe de faire tout le sale travail à votre place ou même l'utilisation d'exceptions permettant de continuer le code au lieu de le faire planter
</p>http://fiddy.free.fr/blog/index.php?post/2008/11/22/Le-C%2C-pas-si-facile-que-%C3%A7a#comment-formhttp://fiddy.free.fr/blog/index.php?feed/atom/comments/5ARP cache poisoningurn:md5:0e178ebaed4c08cb38ff975bcaabb69d2008-11-22T13:07:00+00:00fiddySécurité <p>
La toile est devenue aujourd'hui, un dépotoir d'outils de piratage, tant
redoutés par les entreprises, et à juste titre. Certains de ces outils
regroupent à eux seuls toute la panoplie d'un expert réseau. Encore
faut-il comprendre le fonctionnement de ceux-ci pour en titrer partie.
Au menu du jour, l'<em>Arp cache poisonning</em>, une faille qui brillamment
exploitée, peut causer beaucoup de dégâts.
</p>
<p>
La plupart des outils de piratage sont sur Linux. Ceci s'explique
facilement par le fait qu'il s'agit d'un système d'exploitation
open-source, regroupant ainsi la majeure partie des spécialistes de la
sécurité, aussi bien <em>white hats</em>, que <em>black hats</em>.
Néanmoins, un outil a été développé sur la plate-forme de Redmond, et il
n'a rien à envier à ceux de Linux. Il permet de presque tout faire. Et
nous pesons nos mots. Nous l’avons nommé Cain & Abel.
</p>
<h3>Les possibilités de Cain & Abel</h3>
<p>
Cain & Abel est un formidable outil de récupération de mots de passe.
Selon l'auteur, cet outil a été inventé pour des spécialistes de la
sécurité souhaitant vérifier la robustesse de leur réseau. Grâce à ce
logiciel, il est possible d'obtenir toutes sortes de mots de passe dans un
réseau commuté.
Par un simple sniffing, il recueille et comprend toutes les protocoles
suivants :
</p>
<ul>
<li>FTP, </li>
<li>HTTP, </li>
<li>IMAP, </li>
<li>POP3, </li>
<li>SMTP, </li>
<li>ICQ, </li>
<li>etc. </li>
</ul>
<p>
Il comprend également le WIFI et permet de casser des clés WEP et de capturer un <em>4-way handshake</em> sur WPA/WPA2 pour mener une attaque par dictionnaire dans sa nouvelle
version. Un véritable arsenal, à lui tout seul (cf figure 1).</p>
<p><img alt="" src="http://fiddy.free.fr/blog/image/figure1.png" width="500" /></p>
<p><em><strong>figure 1</strong>. Lancement de Cain & Abel</em></p>
<p>Nous allons nous intéresser à l'<em>ARP cache poisoning</em> que Cain sait,
bien entendu faire aussi : une technique redoutable permettant de rendre
cauchemardesque la vie de la victime.
</p>
<h3>Explication de l'ARP cache poisoning</h3>
<p>
Une vague explication de cette technique, histoire de rafraîchir la mémoire,
ne fera pas de mal. Un ordinateur, afin d'éviter de trop solliciter le réseau
par des requêtes <em>ARP query</em> dans le but d'obtenir l'adresse <em>MAC</em> du destinataire
grâce aux paquets ARP reply, possède un cache, appelé le cache<em> ARP</em>.
Le cache maintient une correspondance entre l'adresse IP et l'adresse MAC d'un
hôte sur le réseau. Mais que se passe t-il si une personne malveillante envoie
elle-même des paquets <em>ARP reply</em> associant son adresse <em>MAC</em> à l'adresse IP d'un
membre du réseau ? C'est très simple, puisque le cache n'effectue aucune
vérification, il associera l'adresse IP de l'hôte avec la nouvelle adresse <em>MAC</em>.
Conséquence ? Les communications de ladite victime passeront par le pirate. Ce
dernier pourra donc tout savoir. Mais, ne serait-il pas possible de faire mieux
comme s'immiscer dans une conversation ? La réponse est oui, et cela s'appelle
une attaque <em>Man-in-the-Middle</em>.
</p>
<h3>Mise en œuvre de l'attaque Man-in-the-Middle</h3>
<p>
Le principe de l'attaque Man-in-the-Middle est très simple. Ceci consiste à
s'introduire entre deux systèmes communiquant entre eux.
Par exemple, si Alice communique des informations confidentielles avec Bob, et
qu'Oscar se fait passer pour Bob auprès d'Alice et pour Alice auprès de Bob,
alors il sera l'homme du milieu et il recevra tous les paquets.
Cette attaque est facile à mettre en œuvre grâce à l'<em>ARP cache poisoning</em>.
Mettons donc cette technique en pratique.
</p>
<h4>Structure du réseau</h4>
<p>
Nous allons tout d'abord commencer par définir un contexte, afin d'être le plus clair
possible :
</p>
<ul>
<li>Soit un réseau commuté : 192.168.1.0,</li>
<li>Routeur : 192.168.1.1,</li>
<li>Alice : 192.168.1.2.</li>
</ul>
<p>
Bob est sur un autre réseau. Alice et Bob dialoguent entre eux. Oscar, qui s'est procuré
un accès au réseau 192.168.1.1 en WiFi par exemple, décide d'espionner les conversations
entre Alice et Bob. Dans toute la suite de l'article, nous nous placerons à la place de
l'attaquant Oscar.
</p>
<h4>Empoisonnement du cache</h4>
<p>
Nous désirons donc espionner Alice. Un simple sniffing du réseau ne suffirait pas puisque
le routeur ne nous transmettra pas les communications d'Alice. C'est à ce moment, que
l'empoisonnement du cache rentre en jeu.
Imaginons le scénario suivant : nous envoyons des paquets arp reply contenant l'adresse
IP du routeur et notre propre adresse MAC. Conséquence ? Le cache de l'ordinateur
d'Alice va se mettre à jour. Par la suite, dès qu'Alice dialoguera, nous entendrons
sa conversation. Il ne nous reste plus qu'à remettre les paquets au routeur pour
n'éveiller aucun soupçon. En effet, si on ne le fait pas, Alice ne pourra plus
dialoguer et nous aurons réalisé un déni de service, chose que nous ne voulons pas
faire. Nous ne sommes pas encore tout à fait satisfaits, nous pouvons faire encore
mieux. En effet, pour le moment, nous recevons les dialogues d'Alice vers le routeur,
mais pas l'inverse. Ce problème est vite résolu en envoyant au routeur des paquets
ARP reply contenant l'adresse IP d'Alice avec ma propre adresse MAC. Il en
résulte que toute conversation avec Alice, aussi importante soit-elle, passera
désormais entre nos mains. Nous pourrons alors connaître les mots de passe
des messageries, des logiciels, même les numéros des cartes bancaires.
Une horreur pour Alice.
</p>
<h4>Comment empoisonner le cache ARP avec Cain & Abel</h4>
<p>
Cette fois encore, on se rend compte que Cain est vraiment un formidable outil.
Non seulement, il va réaliser l'attaque facilement, mais en plus, il va
comprendre la plupart des conversations, comme nous allons le voir. Tout
d'abord, il suffit de scanner le réseau afin de voir les hôtes disponibles.
Pour cela, il suffit de cliquer sur la deuxième petite icône pour activer le
sniffing et ensuite de cliquer sur l'icône représentant le signe plus. Après
un certain temps de recherche par le logiciel, vous aurez tous les hôtes
du réseau disponibles comme vous pouvez le voir sur la Figure 2. Nous
allons maintenant empoisonner le cache du routeur d'une part et celui d'Alice
d'autre part. Pour cela, rien de plus facile, il suffit de cliquer sur
l'onglet APR qui se trouve en bas de la fenêtre. Maintenant, nous allons dire
à Cain de réaliser l'attaque Man-in-the-Middle entre le routeur et Alice.
Nous allons encore cliquer sur l'icône plus, ce qui nous emmène à la fenêtre
de la Figure 3. Pour commencer l'empoisonnement, il ne reste plus qu'à
cliquer sur l'icône jaune dans la barre du haut. Vous pouvez vérifier par
vous-même que l'attaque a bien marché en consultant le cache d'Alice
(arp -a sur Windows, arp -n sur Linux) et le cache du routeur. Et maintenant,
nous allons tenter de récupérer les mots de passe d'Alice lorsqu'elle tente
de se connecter à sa messagerie par exemple.
</p>
<p><img alt="" src="http://fiddy.free.fr/blog/image/figure2.png" width="500" /></p>
<p><em><strong>figure 2</strong>. Hôtes visible sur le réseau</em></p>
<p><img alt="" src="http://fiddy.free.fr/blog/image/figure3.png" width="500" /></p>
<p><strong><em>figure 3</em></strong><em>. Empoisonnement du cache</em></p>
<p><img alt="" src="http://fiddy.free.fr/blog/image/figure4.png" width="500" /></p>
<p><strong><em>figure 3</em></strong><em>. Récupération des mots de passe</em></p>
<h4>Récupération des mots de passe</h4>
<p>
Imaginons qu'Alice veuille aller lire ses mails sur yahoo. Cain va nous
permettre de récupérer l'identifiant et le mot de passe comme le montre la
Figure 4. Ce logiciel peut également récupérer sur des mots de passe sur
d'autres protocoles comme telnet, etc.
</p>
<h4>Application : capture des conversations MSN</h4>
<p>
Toutes les communications passent par notre ordinateur. C'est un fait, mais
pour l'instant, nous avons seulement réussi à obtenir les mots de passe.
N'y aurait-il pas un moyen pour voir les conversations d'Alice sur MSN ?
Bien sûr que si. Mais, cette fois, ce sera sans Cain. Il faut donc utiliser
un logiciel spécifique, capable de comprendre le protocole <em>MSNMS</em>. Msn Sniffer
comme son nom l'indique, répond exactement à nos besoins. En appuyant sur
le bouton Capture, toutes les conversations d'Alice apparaîtront sur le
logiciel puisque ces dernières passent par notre ordinateur avant d'aller
vers le routeur.
</p>
<h4>Et sur Linux ?</h4>
<p>
Sur Linux, l'attaque est à peine plus compliquée. Tout d'abord, commençons
par activer le forward des paquets sous peine de réaliser un déni de service
plutôt qu'un <em>Man-in-the-Middle</em>. Ensuite, nous allons réaliser l'arp spoofing
en utilisant la commande <em>arpspoof</em>, que vous devrez installer si cela n'est
déjà fait. Et enfin, nous utiliserons msnsniff, pour sniffer le contenu
des conversations MSN qui passent par notre ordinateur. Dans le Listing 1,
vous verrez les commandes à taper dans pour réaliser l'attaque sur Alice. </p>
<pre># echo 1 > /proc/sys/net/ipv4/ip_forward<br /># arpspoof -i ath0 -t 192.168.1.1 192.168.1.2<br /># arpspoof -i ath0 -t 192.168.1.2 192.168.1.1<br /># msnsniff -d ath0 192.168.1.2</pre><p>N'oubliez pas de remplacer ath0 par votre interface.</p>
<h4>Ce que dit la loi à ce sujet</h4>
<p>
L'ARP cache poisoning tout comme Man-in-the-Middle, modifie intentionnellement
les transmissions de données. Ceci est un délit qui est sanctionné par :
</p>
<ul>
<li>trois mois à trois ans de prison,</li>
<li>trois cents à soixante-quinze mille euros d'amende.</li>
</ul>
<p>
Aussi, je décline toute responsabilité quant à la mauvaise utilisation
du contenu du présent article. Il a été fait dans l'optique de vous montrer
les faiblesses du protocole ARP. La suite est donc très importante afin de
vous prémunir contre toute attaque de ce genre.
</p>
<h3>Les moyens de protections</h3>
<p>
Nous avons vu que l'attaque se base sur l'empoisonnement du cache. Vous ne pouvez
pas empêcher une mauvaise intention d'un attaquant. Cependant, il y a bien sûr
des points à respecter afin d'être victime.
</p>
<h4>Détection de la modification des entrées ARP</h4>
<p>
Le seul moyen de détecter si le cache <em>ARP </em>a été modifié est bien sûr de le
regarder. Donc un simple : </p>
<pre>> arp -a (Windows)<br />$ arp -n (Linux) </pre><p>et une
comparaison méticuleuse des entrées permettent de s'assurer de la validité du cache.
Aussi est-il important de bien connaître la topologie de son réseau pour discerner
toute bizarrerie.
</p>
<h3>Prévention informatique</h3>
<p>
Le problème de l'ARP cache poisoning est le protocole en lui-même. En effet,
l'authentification forte des extrémités n'a pas été implantée lors de la conception
du protocole. Cette faille ne peut être résolue qu'au niveau des couches supérieures,
c'est-à-dire couche réseau ou applicative. <!-- Bien sûr, il existe aujourd'hui une
version sécurisée du protocole, mais problème de compatibilité-->
</p>
<h4>Sécurité passive</h4>
<p>
Par défaut, les entrées dans le cache sont dynamiques, c'est-à-dire
qu'ils s'actualisent en fonction des requêtes <em>ARP reply</em> reçues. Une entrée
statique définit lors de sa création la correspondance entre une adresse
IP et l'adresse MAC une bonne fois pour toute, rendant impossible tout
empoisonnement futur du cache. Vous pouvez donc définir une entrée statique
pour chacun des destinataires, et surtout pour le routeur.
Nous vous présenterons une petite astuce, plus particulièrement comment
lancer un script au démarrage de l'ordinateur, mettant dans le cache
toutes les adresses en statique avec lequel le système communiquera,
par exemple un petit bach sur Windows ou un shell sur linux. </p>
<pre>arp -s 192.168.1.1 01:02:03:04:05:06 </pre><p>pour mettre une entrée statique dans
le cache. Attention, sur Windows, le commutateur s, permet de rentrer une entrée permanente dans le cache, elle n'empêchera donc pas l'attaque. Néanmoins,
il est possible de résoudre ce petit bogue au niveau applicatif. Certains
<em>firewalls</em> peuvent contrôler l'association adresses IP/MAC (iptables sur
Linux par exemple).
Cette technique, bien qu'elle soit la meilleure, n'est valable que pour
les petites infrastructures. Dès que le réseau devient grand, le nombre
d'hôtes empêche toute possibilité d'entrer toutes les adresses dans le cache
en statique. Une autre méthode possible est l'utilisation d'un commutateur
intelligent. Certains commutateurs ont la possibilité de contrôler
l'association port/IP/MAC, rendant impossible l'empoisonnement du cache.
</p>
<h4>Sécurité active</h4>
<p>
Il est également possible, et recommandé, d'utiliser un logiciel de
supervision de attaques (monitoring en anglais) de ce genre.
Cet outil permettra la centralisation des associations IP/MAC et le
contrôle des paquets <em>ARP</em> susceptibles de provoquer un empoisonnement du
cache. Ainsi, tout paquet douteux sera intercepté par le logiciel et
vous pourrez donc prendre les mesures adéquates. <em>WinARPWatch</em> pour Windows
et ARPWatch pour Linux sont des exemples de logiciel de ce type.
</p>
<h3>Prévention physique</h3>
<p>
L'<em>ARP cache poisoning</em> est une attaque qui ne peut avoir lieu que si le
pirate est dans le réseau. Il s'agit donc d'une attaque locale.
Aussi faut-il s'assurer qu'il ne puisse pas obtenir un accès au réseau.
Il est donc primordial de protéger l'accès aux routeurs, commutateurs.
La non-sécurisation des réseaux Wi-Fi, comme l'utilisation de cryptages WEP,
est également à proscrire puisqu'elle permet l'accès au réseau facilement.
</p>
<h3>Conclusion</h3>
<p>
Cain & Abel est un outil diabolique sur Windows, et il est nécessaire d'en
connaître ses possibilités afin de se protéger efficacement.
D'autant plus que le protocole ARP est incontournable, et il est malheureusement
non-sécurisé. Il est donc impératif de se protéger de cette attaque sous
peine d'être victime d'un <em>Man-in-the-Middle</em> qui peut être, ravageur.
Attention également à ne pas utiliser de messageries instantanées qui ne
cryptent pas les conversations si vous souhaitez une confidentialité des messages.
</p>
<h4>Référence</h4>
<ul>
<li>http://msnsniff.sourceforge.net/ - Source de msnsniff</li>
<li>http://www.effetech.com/msn-sniffer/ - Lien pour télécharger Msn Sniffer</li>
<li>http://www.oxid.it/cain.html - Site officiel de Cain & Abel</li>
</ul>Yopmail : attention aux vols de mots de passeurn:md5:6f1ce2602a3d9fcc2203d46ac45cb2432008-11-22T12:56:00+00:00fiddySécurité <p>
Qui n'a jamais entendu parler de Spam ? Personne. Et c'est normal, tous les jours
nous recevons des tonnes de mails indésirables. Le genre de mails qu'on met tout
de suite à la poubelle pour bien les séparer des autres, qui nous pollueraient la vie
si les filtres n'existaient pas.
</p>
<p>
Mais comment les spammeurs récupèrent-t-ils nos adresses ? C'est très simple, des
robots parcourent jours et nuits la toile en recherchant avec des regexp du genre
\w+@\w+\.\w+. Voilà pourquoi il n'est clairement pas conseillé de laisser son adresse
mail sur Internet. Oui mais voilà, tout n'est pas aussi simple, pour s'inscrire à des
sites, il faut la plupart du temps donner une adresse. Cette dernière est parfois donnée
à d'autres sites de spams (sans votre consentement bien sûr) et rebelotte, notre boîte de
courriels se fait pourrir.
</p>
<p>
Une solution existe, l'adresse mail jetable comme le site yopmail le propose. Ainsi,
lorsque l'on va sur un forum et qu'on doit laisser une adresse, il est possible de donner
une adresse bidon (par exemple machinBidule@yopmail.com). En se connectant sur le site de
Yopmail à l'adresse machinBidule, on pourra récupérer tous les mails. Puisqu'il s'agit d'une
adresse jetable, le spam on s'en fout : du moment que ce n'est pas notre vraie adresse.
</p>
<p>
Vu comme ça, ce genre de sites est super. C'est vrai. Mais, beaucoup d'utilisateurs utilisent
également une adresse jetable pour s'enregistrer à un site. Et là, c'est le drame. Aucune sécurité
est fait sur Yopmail. N'importe qui connaissant votre adresse mail peut lire vos messages. Un utilisateur
malveillant pourra exploiter cette faiblesse. Comment ? Imaginez le scénario suivant. Bob s'inscrit sur
un site Y de commerce électronique avec une adresse yopmail (Bob@yopmail.com). Oscar qui connaît l'adresse
yopmail de Bob va :
</p>
<ul>
<li>se connecter sur le site Y,</li>
<li>cliquer sur "mot de passe oublié",</li>
<li>rentrer l'adresse yopmail de Bob pour l'envoi du mot de passe,</li>
<li>lire le mail à l'adresse Bob@yopmail.com (et oui, tout le monde peut le lire)</li>
<li>utiliser le login et mot de passe donné dans le mail pour s'identifier sur le site Y (aïe, aïe)</li>
<li>effacer le mail sur yopmail pour effacer ses traces</li>
</ul>
<p>
De plus, certains utilisateurs ont tendance à faciliter la vie aux pirates en mettant une adresse yopmail qui se
devine facilement (leur prénom par exemple).
</p>
<p>
Donc, Yopmail bien ou pas ? Oui très bien pour mettre une adresse jetable (ça tombe bien, c'est le but du site). Mais,
il ne faut surtout pas utiliser une adresse du genre pour l'inscription sur un site, sinon aïe aïe. Dans le cas d'une
inscription sur un site demandant une adresse mail, donnez toujours une adresse nécessitant une authentification (gmail par exemple).
Sinon, le méchant Oscar usurpera votre identité.
</p>http://fiddy.free.fr/blog/index.php?post/2008/11/22/Yopmail-%3A-attention-aux-vols-de-mots-de-passe#comment-formhttp://fiddy.free.fr/blog/index.php?feed/atom/comments/3Comment détecter une carte en promiscuousurn:md5:8c06eab666e39b471d0ab511fcada1a82008-11-20T16:56:00+00:00fiddySécurité <h3>Introduction</h3>
<p>Dans un réseau local, les paquets sont envoyés via un hub ou un commutateur.
A la différence du commutateur, lorsque le hub recevra des paquets pour un
hôte, il les enverra sur tous ses ports. Ce sont les cartes réseaux qui, en
analysant l'adresse MAC de destination, vont jeter ou faire remonter à la
couche du dessus les paquets.
</p>
<h3>Comment la carte trie les paquets ?</h3>
<p>Un ordinateur est composé de deux sortes de filtres :</p>
<ol>
<li>filtre hardware</li>
<li>filtre logiciel</li>
</ol>
<h4>filtre hardware</h4>
<p>
Un paquet arrivant à destination de l'hôte sera confronté en premier lieu à ce
filtre.
Ce dernier, en consultant l'adresse MAC de destination, va savoir s'il
faut garder ou non le paquet.
Si l'adresse MAC correspond à celle de la carte réseau (UNICAST)
ou s'il s'agit de l'adresse <code>FF:FF:FF:FF:FF:FF</code> (BROADCAST)
ou encore d'une adresse (UNICAST) dont la machine appartient
le paquet sera gardé. Mais le filtre logiciel va lui faire subir une dernière
épreuve
</p>
<h4>filtre logiciel</h4>
<p>
A ce niveau, tous les paquets sont visibles. Mais avant que la machine réponde à
telle ou telle sollicitation, le paquet sera envoyé au filtre logiciel.
Ce filtre est identique au filtre hardware. Néanmoins, il existe une petite
différence, qui est de taille. Puisqu'aucune carte n'a comme octet de poids fort
FF dans l'adresse MAC d'origine, les éditeurs d'OS, pour des questions
de performances, n'identifient pas les adresses broadcast sur tous les octets.
Par exemple, tous les filtres logiciels considèrent actuellement l'adresse MAC
<code>FF:FF:00:00:00:00</code> comme une adresse broadcast.
</p>
<h4>Mode promiscuous</h4>
<p>
Aux trois modes (unicast, multicast, broadcast) du filtre hardware viennent
s'ajouter un dernier : promiscuous.
Ce mode est très simple, il consiste à laisser passer le paquet sans avoir
inspecté l'adresse MAC de destination.
</p>
<p>Vous l'avez compris, un sniffer va basculer le filtre hardware dans le mode
promiscuous, pour pouvoir lire tous les paquets, y compris ceux n'étant pas
destinés à la machine.
</p>
<h4>Remarque</h4>
<p>
Nous pouvons constater qu'un paquet qui passe le filtre hardware (s'il n'est pas
en promiscuous) passera également le filtre logiciel sur le principe du "qui
peut le plus peut le moins". En effet le filtre hardware est beaucoup moins
souple que le filtre logiciel sur l'adresse MAC.
</p>
<h3>Mais comment détecter le sniffing ?</h3>
<p>
Tout logiciel de sniffing basculera votre interface réseau dans le mode
promiscuous, désactivant donc le premier filtrage. Et comme dit précédemment, il
y a une différence entre les deux filtrages. L'astuce permettant de détecter le
mode promiscuous d'une carte consiste à envoyer un paquet qui est refusé par
l'un des filtrages et accepté par l'autre.
Ainsi, nous serons en mesure de déterminer quel filtre a agi, et par conséquent
en déduire si la carte est en promiscuous ou non.
Prenons l'exemple d'un paquet ARP who-has en broadcast falsifié
(<code>FF:FF:00:00:00:00</code>) destiné à un hôte dans le réseau et analysons-le avec les
deux filtres.</p>
<p>Détails du paquet ARP :</p>
<h5>ARP</h5>
<ul>
<li><strong>IP src:</strong> votre adresse IP</li>
<li><strong>MAC src:</strong> votre adresse MAC</li>
<li><strong>IP dst:</strong> l'adresse IP du suspect (celui dont on souhaite savoir s'il
sniffe le réseau ou non)</li>
<li><strong>MAC src:</strong> <code>0.0.0.0</code> (puisque nous ne connaissons pas son adresse MAC)</li>
</ul>
<h5>Ethernet</h5>
<ul>
<li><strong>MAC src:</strong> votre adresse MAC</li>
<li><strong>MAC dst</strong> <code>FF:FF:00:00:00:00 </code>(le broadcast falsifié)</li>
</ul>
<h4>filtre hardware</h4>
<p>
Le filtre hardware va consulter l'adresse MAC de la couche Ethernet pour voir
si le paquet est destiné à la machine. L'adresse MAC ne correspond pas à
votre adresse MAC, n'est pas du vrai broadcast (<code>FF:FF:FF:FF:FF:FF</code>) et n'est
pas du multicast. Le paquet sera donc rejeté. Vous n'aurez donc pas l'adresse
MAC du suspect.
</p>
<h4>filtre logiciel</h4>
<p>
Le filtre logiciel va également consulter l'adresse MAC de la couche Ethernet
pour voir s'il est autorisé à être lu par le noyau. Rappelez-vous, l'adresse
<code>FF:FF:00:00:00:00</code> est considérée comme du broadcast par ce filtre. Ainsi si le
filtre reçoit ce paquet, il sera transmis au noyau. Le protocole ARP va donc
s'activer. Le noyau, en remarquant que l'adresse IP du suspect est celle de son
interface réseau, va émettre un paquet ARP is-at lui donnant son adresse MAC.
Vous aurez donc l'adresse MAC du suspect.
</p>
<h4>Bilan</h4>
<p>
Admettons que le suspect est effectivement en train de sniffer le réseau. Sa
carte est donc en mode promiscuous. Ainsi le filtre hardware est désactivé,
laissant le filtre logiciel agir seul. En envoyant le paquet ARP au suspect,
nous recevrons une réponse, consultable dans le cache ARP. Nous en déduisons
dans ce cas que le suspect est coupable de sniffer le réseau.
</p>
<p>
Si nous ne recevons pas de réponses, c'est que le paquet s'est fait filtré par
le filtre hardware. Et si le filtre hardware est en place, c'est que le suspect
ne sniffe pas le réseau.
</p>
<h3>Conclusion</h3>
<p>
Le logiciel que je propose, écrit en Python pour pouvoir utiliser facilement
Scapy, permet d'automatiser tout le concept expliqué dans la présente page.
</p>
<ul>
<li><code>./detect.py -i interface AdresseIPduSuspect</code> permettra de savoir s'il a sa
carte en promiscuous ou non.</li>
</ul>
<p>
Comme dit précédemment dans l'article, le filtre logiciel dépend de l'OS. Tandis que certains OS considéreront FF:00:00:00:00:00 comme broadcast, d'autres ne
le considéreront pas comme broadcast. Il est donc possible d'en déduire le type
d'OS lorsque la carte est en promiscuous, en faisant des combinaisons de paquets
ARP avec des adresses MAC Ethernet malicieusement choisies.
</p>
<ul>
<li><code>./detect.py -O -i interface AdresseIPduSuspect</code> permettra de savoir s'il
a sa carte en promiscuous ou non, et le cas échéant d'en déduire son type d'OS.</li>
</ul>
<p>
Ce script n'est pas compliqué et est parfaitement lisible du fait qu'il se base
sur Scapy. Il a juste pour but d'automatiser la détection de Sniffeur. Cette
version n'est qu'un prototype, d'autres fonctionnalités verront le jour (ou pas).
</p>
<p>
Pour pouvoir exécuter le script, il faudra au préalable installer un
interpréteur python, et installer scapy. Vous êtes prêts ? <a href="http://fiddy.free.fr/blog/index.php?post/2008/11/20/download/detect.tgz">téléchargement</a>
</p>http://fiddy.free.fr/blog/index.php?post/2008/11/20/Comment-d%C3%A9tecter-une-carte-en-promiscuous#comment-formhttp://fiddy.free.fr/blog/index.php?feed/atom/comments/2Bienvenue sur mon blog !urn:md5:767d868aa78efd4dbe542a4e8d80f9a92008-11-20T12:44:00+00:00fiddySécuritésécu <h1>Pourquoi ce site ?</h1>
<p>
Ce site va tourner beaucoup autour de la sécurité informatique.
Sur internet, notamment avec les forums, on peut lire beaucoup d'âneries, qu'on peut répandre autour de soi.
Au final, il est parfois difficile de savoir comment protéger efficacement son système d'informations.
Je vais donc tenter d'expliquer à travers de nombreux articles différents, comment les menaces peuvent vous rendre la vie infernale et surtout comment surfer en toute sécurité.</p>
<p>Des articles devraient sortir petit à petit, suivant ma motivation. Ces derniers seront expliqués le plus clairement possible, mais certains demanderont des bases, notamment dans les protocoles réseaux. Je vous invite donc à revoir vos classiques en cas de trou de mémoires. Le site <a href="http://www.frameip.com/">frameip</a> devrait pouvoir combler ces lacunes.</p>http://fiddy.free.fr/blog/index.php?post/2008/11/20/Bienvenue-sur-Dotclear%C2%A0%21#comment-formhttp://fiddy.free.fr/blog/index.php?feed/atom/comments/1