C'est en lisant un article sur Network World que j'apprenai l'existence de cette nouvelle technologie. Suivaient cet excellent billet de Joshua Wright et une enrichissante discussion autour de ce concept qui ne manque pas de soulever des interrogations sur son fonctionnement exact. C'est pourquoi je m'étais rapproché de Nico Darrow, l'auteur du concept, pour me faire prêter un équipement et voir de quoi il retournait. Je voulais en particulier mettre à l'épreuve un contournement basé sur la force du signal reçu. Mais voilà, Deepak Gupta et Vivek Ramachandran ne m'en ont même pas laissé l'opportunité, annonçant dès le mois de juin une présentation sur le sujet à la Defcon... Grillé ! J'ai donc patiemment attendu que se termine l'été pour regarder la vidéo de l'intervention et lire les slides. Et de vous expliquer pourquoi cette charitable intention n'apporte pas grand chose en terme de sécurité.


Tout d'abord, qu'est-ce que le "WEP Cloaking" ? Il s'agit d'une protection reposant sur l'injection dans le flux Wi-Fi légitime de trafic factice, appelé "chaff" dans la présentation, destiné à leurrer les outils comme Aircrack[1]. Il s'agit de trames chiffrées n'importe comment dont l'effet est d'empêcher les attaques de converger vers la clé WEP du réseau en perturbant l'étude probabiliste des paquets capturés. Ce trafic additionnel imite les caractéristiques du trafic légitime, avec en particulier l'utilisation d'adresses MAC existantes et du bon index de clé. Comme le déchiffrement se fait en hard, les trames factices reçues par les clients et points d'accès du réseau seront éliminées au niveau de la caret Wi-Fi, sans pénaliser le système. Le seul effet négatif de la protection sera la consommation additionnelle de bande passante. Au premier abord, ça semble tenir la route.

Pour contourner ce genre de protection, il faut isoler le bon grain de l'ivraie, à savoir le trafic légitime du trafic factice, pour que les outils tournent sur de vraies trames. Dans la mesure où ce dernier est généré par usurpation, on va évidemment vouloir se tourner vers les techniques permettant de détecter ce genre de pratiques. La première est l'étude des numéros de séquence 802.11. Chaque trame Wi-Fi porte un numéro de séquence qui ne sert à rien dans la pratique, IP n'ayant pas besoin que la couche inférieur ordonne les paquets. Cependant, ce numéro est généré de manière séquentielle et permet, en étudiant l'évolution des numéros, de détecter différentes séquences et par déduction, d'isoler les différentes stations, donc un usurpateur. Dans la cas présent, il s'agira d'isoler les générateurs de numéros de séquence des clients légitimes. Deuxième technique, l'étude des vecteurs d'initialisation[2]. De même que les fameux IP ID, ces vecteurs sont souvent générés séquentiellement. Là encore, l'étude de la valeur de ce champ dans les trames provenant d'une adresse MAC particulière peut nous permettre d'isoler les trames ajoutées. Enfin, l'étude de la force du signal reçu peut nous renseigner également. En comparant les différentes valeurs de RSSI qu'on retrouve dans les entêtes spécifiques[3], on peut mettre en évidence une usurpation. C'est cette dernière technique que je voulais investiguer, en ce qu'elle est relativement simple à implémenter, une fois qu'on qu'on a isolé les valeurs de puissance à garder et/ou isoler.

Dans leur présentation, Gupta et Ramachandran utilisent les deux premières techniques et explorent deux autres voies, dont la dernière est particulièrement astucieuse. Première piste, repérer les anomalies à l'œil nu. Il se trouve que si l'être humain est assez nul pour traiter des quantités importantes de données, il est imbattable pour y repérer des motifs, pourvu qu'on les lui présente correctement. Par exemple, si vous lancez des tonnes et des tonnes de scans sur une IP, une bonne représentation des résultats, comme par exemple un graph d'IPID avec Scapy[4], vous permet de discerner immédiatement des alignements, des trous, des regroupements, etc. L'idée, ici, est de laisser l'utilisateur choisir lui-même la valeur des octets de la clé, pour éliminer les déductions automatiques manifestement fausses[5]. Contrairement aux apparences, ce n'est pas forcément fastidieux voire même plutôt efficace. C'est en tout cas quelque chose que je montre en training dans certains cas où un passage d'Aircrack n'aboutit à rien. Fournir des valeurs arbitraires en fonction des votes via l'option -d permet parfois de se sortir d'un mauvais pas. Le soucis, avec cette solution, c'est qu'il faut recommencer à chaque fois qu'on veut modifier une valeur. Ici, ils ont patché Aircrack pour que ce soit fait en ligne. C'est plus propre et surtout plus simple à utiliser. Problème, vous allez devoir suivre et assister le déroulement du programme. Trop dur...

Deuxième technique évoquée, l'isolation du trafic factice à l'aide des numéros de séquence et des IVs. Comme précédemment, l'œil humain se montre fort utile : quand vous graphez la progression de ces valeurs dans le temps[6], vous pouvez repérer différents motifs. Une fois que vous pensez avoir isolé celui qui correspond aux trames générées par la protection, vous pouvez les éliminer pour ne passer que le trafic légitime à Aircrack. Un peu de travail préalable sur la capture est donc nécessaire, mais avec des outils adaptés, ça marche bien. C'est une excellente leçon à retenir : la manière de représenter de grosses quantités de données impacte directement ce que vous allez pouvoir en tirer. Ça parait con à dire, mais c'est tellement vrai qu'on ne se lasse pas de le répéter.

La troisième et dernière approche me semble la plus digne d'intérêt. Elle s'appuie sur une technique déjà utilisée par l'outil Chopchop de KoreK pour déchiffrer une trame arbitraire. L'idée consiste à utiliser un point d'accès comme un oracle en lui faisant valider des trames chiffrées. On lui soumet un contenu chiffré, et selon qu'il le relaie ou non, on va pouvoir déduire s'il est correct ou pas. Chopchop utilise cette technique pour tester les modifications apportées à la trame chiffrée qu'on veut déchiffrer. Ces modifications sont construites à partir d'hypothèses sur la valeur des octets du payload et leur vérification permet in fine de retrouver le payload en clair. Ici, nous voulons juste vérifier si une trame donnée est valide ou non. Comme le point d'accès ne connaît rien de la protection, ajoutée par un équipement externe, si nous lui fournissons un payload chiffré précédemment capturé, il nous dira s'il correspond à la clé WEP du réseau ou pas. Astucieux. Le principe est alors simple : on prend une trame capturée, on remplace l'adresses MAC destination par l'adresse de broadcast[7] et on réémet à destination de l'AP. Si celui-ci rejoue la trame, on peut la garder, sinon, on la jette. L'avantage de cette méthode est qu'elle peut tourner après la capture, en passant cette dernière dans un outil destiné à tester toutes les trames et les éliminer le cas échéant, ou pendant la phase de cracking.

La conclusion de ce papier est relativement sans appel. Avec de faibles modifications, on arrive à contourner très rapidement la protection. La dernière technique, en particulier, est tout à fait implémentable dans Airodump pour sortir une capture filtrée de toute pollution. Ceci la rend complètement automatique, ce qui ajouté, à une efficacité de 100%, relègue le "WEP Cloaking" au rang des bonnes intentions dont, à l'instar de l'enfer, est pavé le monde de la sécurité informatique.


Pourquoi je vous parle de ça maintenant ? D'abord parce c'est une preuve, s'il en fallait encore, que le WEP est mort. Point barre. Il est certes charitable de vouloir aider ces gens enfermés dans des solutions obsolètes et lourdes, mais ce n'est pas en jetant un écran de fumée qu'on y arrivera. On sait, suite à l'affaire TJX, le mal que peuvent faire ce genre de réseau, autant ne pas proposer de rustines inefficaces et continuer à prôner l'évolution. Ce qui m'amène à un second point. La sécurité par l'obscurcissement, si vous me permettez le jeu de mot. Là où certains veulent dissimuler leurs techniques de protection[8], d'autres se battent pour fournir à l'attaquant des informations erronées sur leur système afin de se protéger. Si l'attaquant n'arrive pas à comprendre ce qu'il attaque, il n'y arrivera pas. C'est par exemple le principe de toutes les techniques destinées à empêcher Nmap de deviner la nature d'un système d'exploitation. L'OS fingerprinting est une occupation archi-connue, qui fait appel à relativement peu de techniques, mais dont la complexité suffit à rendre sa prévention relativement compliquée. Qu'il s'agisse de Nmap, Xprobe2, ChronOS, p0f, SinFP ou d'autres éléments comme la simple lecture des bannières ou des codes d'erreur de services, la surface à protéger est suffisamment vaste pour qu'il soit peu probable de réellement empêcher quelqu'un d'obtenir un résultat, sans parler du temps investi pour y parvenir, le tout sans nuire aux performances de la machine, à comparer avec le gain en sécurité effective, relativement réduit à mon avis. Typiquement, un bot ne fait pas de fingerprinting, si votre machine est vulnérable, il la roote. Point.

Cependant, ça n'empêche pas certains d'arriver, eux aussi, avec des grandes idées de ce genre. C'est ainsi qu'Arxceo Corporation, dans la lignée de la campagne AVID[9], nous propose un outil anti-reconnaissance destiné à compliqué la tâche du pentester et arrêter la propagation des vers, connus comme inconnus[10]. Bref, la fin des vers. Trop beau pour être vrai ? Si on creuse un peu, on découvre grosso modo le principe du Tarpit, technique qui n'a rien de nouveau et qui a certes fait ses preuves, mais aussi montré ses limites, comme on pourra le voir dans l'article "Défense par diversion et quarantaine" publié dans le numéro 28[11] de MISC. Là encore, du trafic légitime, du trafic additionnel pour polluer l'attaquant, on en revient toujours au même problème. L'attaquant réduira sa surface d'attaque, distinguera les vraies machines des fausses et n'en finira son travail qu'avec plus de satisfaction...

Globalement, c'est jouer le jeu du chat et de la souris, de l'épée et du bouclier, dont l'issue est claire : l'attaquant gagne toujours, parce qu'il a toujours un coup d'avance à ce jeu là. Et surtout parce que là où la défense doit être cent pour cent efficace vingt-quatre heures sur vingt-quatre, le méchant n'a besoin que d'une faille. Une seule...


Ce qui me fait une excellente transition pour vous annoncer la sortie prochaine du tout premier hors-série de MISC, entièrement consacré aux tests d'intrusion. Vaste sujet pour lequel Pappy nous a laissé, Philippe et moi, dédier quelques pages à la cartographie de réseau à distance. Vous pourrez y trouver un aperçu de ce qu'on peut utiliser comme informations ainsi que différentes techniques de représentation et d'interprétation pour découvrir la tête d'une infrastructure réseau, dans la même veine de ce que je vous racontais précédemment.

Notes

[1] Permettez que j'oublie le -ng...

[2] Plus couramment appelés IVs.

[3] Genre Prism ou Radiotap.

[4] Cherchez la seconde occurence du mot "Gnuplot".

[5] Cf. slide 39.

[6] Cf. slides 47 et 48.

[7] FF:FF:FF:FF:FF:FF

[8] Principe de la sécurité par l'obscurité.

[9] AntiVirus Is Dead

[10] Ça ne vous rappelle rien ?

[11] Dans lequel vous trouverez également un article sur SinFP cité précédemment.