a Cantine nous propose de discuter du thème du Full Disclosure sous la forme d'un procès fictif. Cet évènement organisé par le Cercle Asimov et intitulé "Full-disclosure, toutes les vérités informatiques sont elles bonnes à dire ?" se tiendra le 30 septembre prochain de 19h30 à 21h30.

Il mettra en scène le procès d'un informaticien, joué par Philippe Langlois, qui après avoir alerté un hôpital d'une faille sur son infrastructure informatique et en l'absence de réaction de ce dernier, a publié sa trouvaille. L'hôpital, évidemment, va le poursuivre pour intrusion dans son système, et c'est la tenue de son procès qui servira de prétexte à l'approfondissement du thème avec l'assistance.

Côté défense, les protagoniste de la pièce sont donc Philippe Langlois en tant que prévenu, Ambroise Soreau comme avocat et Éric Filiol comme témoin. Côté accusation, on trouvera Vincent Leroux comme témoin et François Coupez comme avocat. Enfin, côté tribunal, le président sera joué par Charles Simon, entouré de deux assesseurs, Lionel de Souza et Florence Dupré^[1].

Le scénario est proposé est somme toute assez classique, mais il ne manquera pas de poser pleins de questions pertinentes concernant la divulgation de failles. On se souvient tous d'affaires qui ont généré leur lot de commentaires en leur temps, qu'il s'agisse de la fameuse affaire Kitetoa contre Tati, de Guillermito vs. Tegam ou plus récemment de celle qui a opposé Zataz à Forever Living Products. Et ce sont loin d'être des cas isolés dans le traitement juridique du Full Disclosure.

Les aspects légaux de la sécurité informatique étant une source quasiment inépuisable de trolls velus, il ne fait aucun doute que ce procès fictif donnera lieu à un discussion riche ;)

L'évènement est ouvert à tous modulo une inscription libre et gratuite sur le site de la Cantine^[2].

e viens de faire l'acquisition d'un tracker GPS que je destine, au moins dans un premier temps, au géocodage de mes photos. Après des recherches que je n'oserais qualifier d'approfondies, mon choix s'est porté sur le Qstarz BT-Q1300S.

Pas forcément pour faire du jogging, même si j'en aurais besoin, mais tout simplement parce qu'il est simple, fin, léger et, surtout, complètement supporté sous Linux. Car aussi riche que puisse être la dotation logicielle fournie par le constructeur, je traite mes photos sous Linux, pas sous Windows ni MacOS. Mon geotagging se fera donc sous ce même OS, et je me propose de vous compiler ici ce que j'ai trouvé et testé.

Le BT-Q1300S est basé sur le chipset Mediatek MT3329. Il se connecte et se recharge sur USB, supporte le BlueTooth, la norme NMEA 0183 et peut loguer jusqu'à 5 points par seconde avec 11h d'autonomie. Il permet également de sauvegarder des emplacements particuliers^[1], ce qui peut se révéler intéressant à l'usage.

Les chipset GPS Mediatek, MTK pour les intimes, sont supportés via le driver CDC ACM^[2]. Le MT3329 ne fait pas exception à la règle, immédiatement sur un noyau récent sinon modulo un léger patch. Ce qui veut dire qu'on communique avec lui via une interface série, comme avec un modem tout ce qu'il y a de plus classique.

On allume le tracker, on le branche en USB, et hop :

usb 5-1: new full speed USB device using uhci_hcd and
     address 2
cdc_acm 5-1:1.1: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
cdc_acm: v0.26:USB Abstract Control Model driver for USB 
      modems and ISDN adapters

On a maintenant un /dev/ttyACM0 pour causer dedans et récupérer les informations qui vont bien. Un peu de Googling nous amène rapidement à MTKBabel, un outil en ligne de commande destiné à piloter la fonction de tracking des chipsets MTK : lecture des données, effacement de la mémoire et configuration principalement. On probe le device, et ça répond tout de suite :

~$ mtkbabel -s 115200 -p /dev/ttyACM0
MTK Test OK
MTK Firmware: Version: 1, Release: AXN_1.30-B_1.3_C01, Model 
    ID: 0003
Log format: (0002003F) UTC,VALID,LATITUDE,LONGITUDE,HEIGHT,
    SPEED,RCR
Size in bytes of each log record: 34 + (0 * sats_in_view)
Logging TIME interval:       5.00 s
Logging DISTANCE interval:   0.00 m
Logging SPEED limit:         0.00 km/h
Recording method on memory full: (1) OVERLAP
Log status: (000100000000) AUTOLOG_OFF,OVERLAP_WHEN_FULL,
    ENABLE_LOG
Next write address: 219130 (0x000357FA)
Number of records: 6357
Memory health status (failed sectors mask): FFFFFFFFFFFFFFFF
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Ensuite, on peut télécharger les données :

~$ mtkbabel -s 115200 -p /dev/ttyACM0 -f tracks

Ceci va me créer un fichier tracks.bin contenant les informations de la mémoire. Ceci étant, comme c'est un format propriétaire, ce n'est pas super intéressant. Aussi on préfèrera utiliser l'export GPX^[3] :

~$ mtkbabel -s 115200 -p /dev/ttyACM0 -f tracks -t -w -c

Ces trois derniers switches permettent de créer en sus respectivement un fichier contenant la trace GPS (tracks_trk.gpx), un fichier contenant les waypoints (tracks_wpt.gpx) et un fichier contenant ces deux types d'informations (tracks.gpx).

Si les fichiers GPX sont directement utilisables pour le geotagging, sachez tout de même que vous pouvez les manipuler avec GPSBabel, en particulier les convertir dans pleins d'autres formats pour divers usages que vous pourriez vouloir en faire. En ce qui me concerne, ça me permettrait de convertir les waypoints en base de POI pour mon GPS Garmin. Plus intéressant, GPSBabel permet de manipuler les informations contenues dans un fichier GPX : suppression des doublons ou des points aberrants, ajouts de points par interpolation, modification de l'altitude, etc. Ça peut servir...

Passons au geotagging proprement dit, à savoir l'attribution à un cliché des coordonnées GPS de l'endroit duquel on l'a pris. Pour y parvenir, on effectue une corrélation temporelle entre la trace GPS et la date de prise de vue contenue dans les metadonnées EXIF des photos. Pour le dire de façon moins ampoulée, on prends la date à laquelle a été prise la photo et on regarde dans la trace GPS où on était à ce moment là, en faisant une approximation quand ça tombe entre deux points. Simple. Le logiciel que j'ai trouvé le plus efficace pour faire ça est gpscorrelate. Ça prend un fichier GPX et des images en entrée, et ça tagge. Point. J'ai encore un peu de mal avec la gestion de la différence de date au niveau des secondes, mais bon. On m'avait aussi conseillé Geotag, mais je n'en vois pas trop l'intérêt si ce n'est le support des formats RAW.

Enfin, si vous êtes un fanatique indécrottable du clikodrome, je ne peux que vous recommander le projet BT747 qui propose un outil graphique en Java permettant de tout faire : gestion du device, téléchargement des traces, export dans différents formats, affichage sur carte, geotagging, etc. Bref, une GUI fort sympathique pour gérer son tracker.

Côté visualisation des photos, on notera que Geeqie supporte l'affichage de la position sur carte en fonction du géocode, auquel cas il peut afficher une carte positionnant l'image, et qu'il existe un plugin pour EOG qui fait la même chose, en un peu mieux je trouve.

Les adaptes de Debian regretteront que que bt747, comme Geotag, ne soit pas packagé. Par contre, c'est le cas de tous les autres logiciels mentionnés : MTKBabel, GPSBabel et sa GUI, gpscorrelate et sa GUI, Geegie compilé avec support GPS et le plugin pour EOG.

Maintenant que le geotagging fonctionne, je peux passer à la suite. À savoir éviter au maximum de faire des boulettes d'une part et le configurer en tant que source pour GPSd d'autre part. Ce qui me permettra de l'utiliser avec... Kismet... Exemple complètement fortuit, évidemment ;)

ric Walter s'est trompé de métier. Il aurait en effet plus sa place en tournée avec le cirque Pinder qu'à vouloir nous expliquer les rouages d'Internet, monde qui lui semble aussi étranger que la sécurité à certains de ses confrères. Aussi, quand il met en garde les internautes contre les si prévisibles campagnes de spam profitant du battage autour d'HADOPI, on reste pensif.

Commencez donc par aller lire l'excellente analyse publiée ce matin par CNIS Mag' sur le sujet. Puis rebondissez sur l'article paru dans Le Monde qui cite les propos tenus lors du "Tchat" de vendredi dernier...

Éric Walter y conseillait aux utilisateurs de se montrer vigilants vis-à-vis de leur courrier électronique. Ceci étant, un conseil, ça ne coûte rien à donner. Aussi, grand seigneur, il leur expliquait également comment faire la différence entre un véritable email de la HADOPI et un spam. Je cite :

Les mails de recommandation de la Hadopi seront simples et 
nominatifs alors que les spams n'ont pas le nom de l'usager.

Alors ni une ni deux, je me jette sur mes boîtaspams pour y trouver, entre autres joyeusetés, des entêtes de ce genre :

From: Shannan Lavina <slavinaar@add.cc>
To: Cedric Blancher <xxx@xxx>
Subject: Free Bonus Viagra100mg pills with every order, 100%

Ou encore :

From: Aubrey Stephany <aubreypstephany_nc@abunayyangroup.com>
To: Cedric Blancher <yyy@yyy>
Sujet: Rep1icaWatches: Swiss Rep1icaWatch, Buy Perfect Watches
       Clones Cheap from $150 lf

Nous disions donc :

les spams n'ont pas le nom de l'usager

Fail^[1]...

omme souvent quand on mélange aviation et sécurité informatique, le buzz ne brille pas par son exactitude. Ainsi, il n'a pas fallu beaucoup attendre pour qu'on rebondisse sur les affirmations du journal espagnol El País et qu'un virus informatique devienne responsable du crash du vol Spainar 5022. Contrairement à d'autres avis probablement plus éclairés, mais moins sensationnels...

Évidemment, l'hypothèse de la compromission d'un ordinateur de bord, l'empêchant d'alerter l'équipage et tuant par son silence 154 des 172 personnes présentes à bord du MD82, a de quoi séduire l'amateur de scoops croustillants. Et de générer son lot de commentaires plus ou moins inspirés chez certains professionnels. Il ne manque plus que la clé USB infectée pour parfaire le scénario du Confiker-like meurtrier...

Il y a quand même quelques personnes qui se posent des questions ou font un peu de follow-up sur leurs billets. C'est rassurant, mais bon, ce n'est pas ça qui va empêcher les esprits les plus fertiles de tourner à fond les ballons... Surtout pour en faire le premier incident du genre...

Évidemment, pour remettre un peu les pieds sur Terre, il faut revenir à la source, à savoir le rapport préliminaire d'incident publié par le CIAIAC^[1]. Et ça tombe bien, parce qu'il est public.

La cause technique de l'accident est un décollage sans volets, configuration impropre sur ce type d'appareil. Les évènements qui ont mené à cette configuration sont multiples, mais semblent résulter principalement d'une revue trop rapide des checklists de décollage par un équipage stressé et ensuite du non fonctionnement du TOWS^[2], équipement de bord censé émettre une alerte vocale pour prévenir l'équipage du problème de volets.

Pas mal d'articles parus sur le sujet spéculent sur une infection du TOWS par un malware. Infection qui expliquerait son absence de réaction. Sauf que comme d'habitude, les choses sont un peu plus compliquées qu'une explication à l'emporte-pièce et la vérité est ailleurs. L'équipage était stressé par un retard imputable à une défaillance matérielle. Alors qu'il se dirigeait vers la piste de décollage, une mesure anormale retournée par une sonde de température^[3] avait conduit à son retour en porte. Or, la sonde en question n'est activée qu'en vol mais il semble qu'elle fonctionnait alors que l'avion était encore au sol.

Le fait que l'avion soit ou non au sol est détecté par des interrupteurs logés dans le train avant. Ils contrôlent des relais qui permettent d'activer ou de couper certains équipements. Parmi ces derniers figurent le RAT, mais aussi le TOWS qui n'est actif qu'au sol. Or ces deux systèmes dépendent du même relais, dont une défaillance est avancée comme hypothèse probable de la coupure du TOWS. Car si le relais en question indiquait que l'avion était en vol au RAT, il fournissait la même information au TOWS, lequel se trouvait donc désactivé. Pas de malware dans le TOWS, difficile d'en loger un dans un relais. Poursuivons...

D'après le rapport, c'était le sixième incident du genre enregistré par le DFDR^[4] de l'appareil. Trois d'entre eux se trouvent consignés dans l'ATLB^[5] de l'appareil. Il s'agit d'un journal technique, opéré par l'airline la compagnie aérienne$$Suite au commentaire de Me Capello...$ sur un système informatique externe à l'avion, dans lequel on répertorie, entre autres, les opérations de maintenance consécutives à des incidents. L'analyse de ce journal permet de remonter des alertes en cas d'occurence d'un même incident. Avec comme conséquence possible de clouer l'appareil au sol pour inspection. Or, aucune alerte n'a été remontée à l'équipe de maintenance ce jour là.

Comment expliquer ce silence ? Le malware, forcément ! C'est donc là que l'hypothèse du système compromis entre en scène. Un système vérolé n'aurait pas averti les équipes de maintenance de la répétition d'un problème de RAT dans l'ATLB, conduisant à une autorisation de décollage qui n'aurait pas due être donnée. CQFD...

Maintenant, je vais me garder de spéculer plus avant sur les causes du silence du système gérant l'ATLB. À ceux qui voudraient le faire, je recommanderai toutefois de considérer les points suivants.

D'abord, le rapport préliminaire ne fait pas mention^[6] de l'absence d'une alerte quant au contenu de l'ATLB. On peut donc s'interroger sur l'importance supposée d'un tel incident, pour autant que ça en soit un. Ensuite, dans un précédent article, El País mentionnait que Spanair se donnait un délai de 24h pour réconcilier les rapports que remontent les équipes de maintenance au sein de l'ATLB. Ce qui amène à se demander si les informations dont disposaient l'équipe de maintenance étaient à jour, et donc susceptibles de les alerter.

Ceci m'inspire que l'hypothèse du malware n'est pas la seule permettant d'expliquer cette absence d'alerte. Et quand bien même ce serait le cas, pourrait-on pour autant parler de malware tueur ? Je vous laisse juger par vous-même...

Jobs made possible because of video games

Michael Gallagher, CEO of ESA, explained that job creation has grown at a "rapid pace.” It is also making "an essential contribution to our nation's economy while stimulating technological innovations and expanding the impact of games on our daily lives." The survey shows us that 32,000 have jobs with video games usually with an average salary of $ 89,781. Video games have made it possible for numerous in the U.S. to get jobs.

California does it all

California is the largest employer of video game industry workers. It provided more than$ 2.6 billion in direct and indirect compensation to its employees in 2009. The state got about $ 2.1 billion in just revenue.

The next two states to follow are Texas and Washington. Virginia had a large expansion with a 77 percent increase between 2005 and 2009.

Why entertainment is so valuable

Families tend to buy less entertainment things in a recession. Video gaming may seem costly on the surface – consoles cost from $ 200 to $ 500, and PCs cost even more. Games range from $ 20 to $ 60, depending upon their popularity, age, format, etc. Since movie prices have gone up, seems like like video games could be better considering one can spend between 40 and 100 hours playing most of the games bought. Hand-eye coordination gets much better along with development when using video games. The video game industry has had a good effect. The U.S. economy is feeling it.

Find more information on this subject

Theesa

theesa.com/facts/pdfs/VideoGames21stCentury_2010.pdf

Washington State Lt. Gov. Brad Owen knows 'Pong'

youtube.com/watch?v=M-b9wEww9MA

Besides a zero-cost download option, we are also offering Linux-oriented installation media and an enterprise version of our system with premium features such as configurable automatic alerting, nonlinear replay, and a 3D traffic display.

Discounts—including installation media for a nominal shipping and handling fee—are available to institutional researchers or in exchange for extensions to our platform.

The software can run in its entirely on a dedicated x86 workstation with four or more cores and a network tap, though our system supports distributed hardware configurations. An average graphics card is sufficient to operate the visualization engine.

près une première réaction remarquée, RIM aurait finalement cédé aux demandes des Émirats. Le constructeur canadien du Blackberry se serait donc engagé à offrir les capacités d'interceptions exigées par les Émirats Arabes Unis et l'Arabie Saoudite pour ne pas se faire fermer leurs marchés. Maintenant, c'est au tour de l'Inde de s'engouffrer dans la brèche.

Certains y voient un précédent de taille. Parce que RIM a toujours vanté la sécurité du système Blackberry en mettant en avant l'impossibilité, même pour eux, d'intercepter le contenu des messages, ces annonces viennent écorner la confiance des utilisateurs, et surtout relancer les vieilles polémiques. Et ceci au moment où, comme par hasard, les autorités allemandes conseillent de laisser le smartphone au placard...

<disclaimer>
Avant de m'aventurer plus loin sur le sujet, je ne saurait trop recommander aux facétieux adaptes de la citation à l'emporte-pièce la lecture d'un précédent billet avant de voir dans ces lignes les prémices d'une position quelconque sur la question. Ce qui suit est un réflexion personnelle, en tant qu'individu, point barre. Ne cherchez pas à y voir autre chose. Merci d'avance. Maintenant que c'est dit, revenons au sujet principal.
</disclaimer>

La confidentialité des échanges sur le système Blackberry est une polémique récurrente. La question de savoir si on peut espionner les Blackberry, et tout particulièrement si RIM s'en est donné les moyens, bien qu'étant restée sans réponse, ne manque pas d'alimenter les réflexions. Car si rien ne prouve que ce soit le cas, il faut bien reconnaître que rien ne prouve le contraire non plus.

Aussi, quand on annonce que RIM se pliera aux demandes des Émirats, les interrogations pleuvent. Et ce, malgré le communiqué qu'il adresse à ses utilisateurs. Communiqué dont la rédaction laisse entrevoir d'intenses séances de réflexions considérant les tournures alambiquées et le vocabulaire de choix. Du coup, les analyses plus ou moins bien inspirées fusent... Seulement, quand on s'attarde sur les réactions et qu'on lit attentivement le communiqué en question, on s'aperçoit que cette polémique n'est en rien différente des précédentes. Et surtout qu'il rien de nouveau dans la paysage.

On sait, depuis le temps qu'on nous l'explique, que les communications entre un BES^[1] et ses terminaux sont chiffrées de bout en bout. Chiffrement dont la clé est négociée lors de l'enregistrement du terminal auprès de son BES^[2] et qui interdit à RIM l'accès à plus que les métadonnées^[3]. D'aucuns en déduisent que si c'était vraiment le cas, on ne pourrait pas intercepter le trafic. Et que si on peut le fait, c'est bien qu'il y a là une porte dérobée. Déduction facile ?

Pour moi, le point clé n'est pas là. Vous remarquerez que le communiqué ne porte pratiquement que sur la sécurité des solutions Blackberry d'entreprise. Et pas de les autres. Comme par exemple celles qui sont fournies par des opérateurs qui opèrent un BES pour leurs clients. Ou le fameux Blackberry Internet Service. Pourquoi ? Parce que la solution RIM ne fournit pas de sécurité de bout en bout, de l'expéditeur au destinataire. Elle ne chiffre que les flux échangés entre le terminal et son BES^[4]. Un peu comme le Wi-Fi : on protège le lien hertzien, le reste est un autre problème. De fait, les emails que vous échangez sont accessibles en clair sur les serveurs qui les stockent. Si cela ne pose pas plus de soucis que ça à une entreprise possédant sa propre infrastructure, il en va tout autrement pour tout ceux qui délèguent l'opération de leur messagerie. Que ce soit à un opérateur, à RIM ou à tout autre tiers. Car dans ce cas, leurs messages se retrouvent tout simplement accessibles chez le prestataire... En clair... Comme ça a toujours été le cas pour n'importe quel service de messagerie hébergé...

Aussi, quand on lit ce qui ressort dans la presse, on ne peut qu'esquisser un sourire. D'abord parce que les soit-disant concessions accordées par RIM n'en sont pas : les emails des utilisateurs de services Blackberry hébergés ont toujours été accessibles par les autorités sur demande auprès du prestataire. Au mieux s'agira-t-il de faciliter l'accès à des données déjà interceptables. Ensuite parce que cela résume bien l'échec de la communication de RIM, puisqu'on en vient même à lui reprocher des problématiques qui ne font pas partie du périmètre de sa solution...
Sans parler des classiques déclarations anonymes de sources proches du dossier qui annoncent, par exemple, la prochaine fourniture par RIM d'une solution d'interception des messageries d'entreprise à l'Inde^[5], en complète contradictoires avec les dires de RIM...

Chacun se fera son idée sur la question. Toujours est-il que RIM se retrouve face à un sacré sac de nœuds. Car ce qui a été unanimement présenté comme des concessions accordées aux Émirats pourrait bien ancrer durablement dans la tête des gens l'idée que le Blackberry serait espionnable...

e retour du SSTIC, Kevin Denis constatait avec un certain dépit que la sécurité TCP/IP semblait ne plus intéresser personne. C'est en effet un domaine où beaucoup croient que tout a été dit, qu'il ne reste plus rien à trouver, bref que l'étudier est une perte de temps. Je suis loin de partager cet avis.

Et je le partage d'autant moins que ce désintérêt s'exprime souvent chez des gens dont l'approche on ne plus surfacique du sujet en font soupirer plus d'un. Pour illustrer ce que j'entends par là, je vais vous parler d'un truc on ne peut plus Old School et parfaitement maîtrisé : la corruption de cache ARP. Et vous montrer combien certains devraient revoir leur classiques avant de se faire mousser à BlackHat...

La corruption de cache ARP, c'est une attaque qui pourrait figurer dans un musée. La RFC décrivant ARP date de 1982, et on trouve ce qui est probablement la première référence à l'attaque dans le numéro 34 de Phrack qui nous ramène en 1991. Depuis le problème a été largement documenté et outillé.

Aussi quand, après une discussion sur fr.comp.securite, Pappy, Valgasu et moi avons décidé d'approfondir la question pour notre article sur le sujet dans le numéro 3 de MISC. C'était en 2002, c'était déjà vieux et il ne s'agissait déjà pour nous que de proposer un panorama des techniques de corruption de cache ARP. Des petites choses comme la corruption de cache avec des requêtes, possiblement dirigées, la mise à jour d'entrées statiques sous Windows et Solaris 8, l'usurpation d'IP étaient peu documentées à l'époque, et un outil complet de génération de trafic ARP restait à écrire.

Rien de révolutionnaire n'est sorti de ce travail, mais le fait de se plonger là-dedans nous a donné l'opportunité, je pense, de faire le tour du sujet et de partager l'expérience. Ça nous a aussi permis de nous en servir efficacement quand le besoin a pu se faire sentir...

Mais revenons à nos moutons. Le problème avec les techniques antédiluviennes de ce genre, c'est qu'au bout d'un moment, certains semblent considérer qu'elles font partie du paysage et que comprendre comment ça marche ne sert à rien. Que c'est chiant. Dans la mesure où il y a des outils pour les exécuter, autant regarder vaguement ce qu'ils font et s'en contenter. J'ai l'impression que c'est exactement le panneau dans lequel sont tombés les gens d'AirTight avec leur histoire de Hole196. Prenez les slides qu'ils ont présentés à Defcon et rendez-vous d'abord à la planche 8. On nous y explique qu'une tentative de corruption de cache ARP par requête en broadcast va se trouver répétée sur le réseau filaire où elle pourra être détectée par un éventuel IDS. L'idée est reprise sur la planche 18 qui compare la corruption dite "Old Style", manifestement détectable, avec leur méthode, forcément furtive et donc plus intéressante.

Sauf que ce n'est pas la réalité du terrain. En 2002, quand nous avons travaillé sur l'ARP cache poisoning, l'outil "Old Style" de l'époque était le célèbre arpspoof du package dsniff. La technique qu'il implémente consiste à envoyer des réponses ARP non sollicitées en unicast vers la machine à corrompre. Technique qui ne correspond donc en rien au scénario proposé dans la présentation et qui, surtout, n'entraîne pas de diffusion sur le réseau filaire quand il est dirigé vers une station Wi-Fi . L'attaque n'a donc aucune raison d'y être détectée par un IDS classique.

On peut aussi corrompre un cache ARP avec des requêtes. Et bien que ce type de paquets soit destiné à être envoyé en broadcast, on préférera de loin émettre des requêtes ARP en unicast. D'aucuns peuvent trouver ça étrange, mais c'est complètement supporté dans la mesure où la couche ARP se contrefiche de savoir comment le paquet est arrivé jusqu'à elle... Là encore, on a un exemple de corruption de cache ARP Old Style qui va passer à travers l'IDS filaire...

En fait, faire de la corruption de cache ARP en broadcast est une approche inutilement bruyante du problème. Approche qu'on ne devrait utiliser que s'il fallait toucher l'ensemble du subnet d'un coup... Exécuter l'attaque en unicast est bien plus efficace, ne serait-ce que du point de vue de la furtivité. Dans le contexte décrit par AirTight, le trafic unicast ainsi produit sera protégé par la PTK et ne génèrera pas la superbe alerte montrée sur la slide 23 du Webinar Hole196.

De manière générale, on peut conclure que le discours soutenant l'intérêt de Hole196 pour faire de la corruption de cache ARP n'est appuyé que par un use case un peu foireux. D'autres méthodes permettent d'arriver au même résultat sans déclencher les alertes annoncées et sans avoir à s'embarrasser de ces histoires de GTK. Les auteurs ignoraient-ils donc l'existence de ces dernières^[1] ? Je ne sais pas, mais ce ne serait pas la première fois que ce genre d'erreur serait faite.

Pas mal de gens ont en effet essayé de produire des techniques de détection, voire même de prévention, de corruption de cache ARP. Et pas mal d'entre elles échouent parce qu'elles ne ciblent que certains scénarios d'exploitation. Or l'expérience montre que ce genre d'approche est vouée à l'échec. Dans notre cas, l'erreur la plus courante consiste à ne surveiller que les réponses ARP, puisque c'est ce que met en œuvre l'outil d'attaque le plus connu. Or c'est l'intégralité du trafic ARP qu'il faut inspecter, comme le fait arpwatch quand on lui envoie l'intégralité du trafic. Ou alors, il faut durcir l'implémentation de la couche ARP, ce que fait ArpOn sous Unix.

Si vous voulez lire quelque chose d'intéressant sur la sécurité Wi-Fi publié à BlackHat et Defcon, je vous conseille de vous tourner vers les travaux de Leandro Meiners et Diego Sor sur le "WPA Migration Mode" de Cisco. Ce mode, qui permet d'accepter des clients ne supportant que WEP ou LEAP sur des réseaux WPA/WPA2 acceptant TKIP, se fait donc démonter dans les grandes largeurs. Le code implémentant l'attaque est disponible et en passe d'être inclus dans Aircrack-ng et probablement dans Kismet.

On sent bien le fail qui s'apparente à équiper un coffre-fort d'une porte en contre-plaqué. Ou une serrure biométrique dernier cri d'un barillet de secours trivial à crocheter^[2]. Bref, quelque chose qui ne viendrait pas à l'esprit d'une personne sensée...