En fait, il est intéressant de remarquer que cette technique est née du besoin de se protéger contre le wardriving. Or il se trouve qu'il s'est surtout agit de se prévenir de l'outil de wardriving le plus utilisé, à savoir Netstumbler, lequel est également et paradoxalement un des plus pauvres en la matière, souffrant en effet de restrictions imputables à la couche NDIS de Windows dont les fonctionnalités limitées en matière de WiFi l'empêchent de découvrir les réseaux cachés, dans la mesure où il ne peut envoyer que des probes requests pour faire son boulot. Par contre, un outil quelque peu évolué comme Kismet, sachant écouter le trafic réseau, les découvrira sans aucun problème s'il voit passer un probe request spécifique ou une association se faire. À outil pourri, mesure pourrie, telle pourrait être la devise de ce type de mesure...

Mais tant qu'à implémenter du cosmétique, autant mettre du filtrage d'adresse MAC ! L'AP ne répondra pas non plus aux probe requests des clients inconnus, fussent-ils génériques ou spécifiques. Même effet, cause différente, et dans ce cas, l'expérience montre que les kiddies mettent un peu plus longtemps à s'apercevoir ce qui cloche dans leur démarche. Trop compliqué à gérer à la longue ? Pourquoi pas une clé WEP ? OK, le WEP ça pue, mais juste un peu moins qu'un réseau ouvert de toute manière. Et puis quand on est capable de se communiquer un SSID, on est capable de se communiquer une clé WEP. Je vous passe le couplet sur WPA/WPA2, vous le connaissez déjà...

Mais revenons à nos moutons. Là où l'article se montre intéressant, c'est qu'il met le point sur un aspect un peu plus ennuyeux. Pour le client cette fois. Si votre client émet des probes requests contenant le SSID, un attaquant qui les capturerait serait alors capable de monter un Rogue AP utilisant ce SSID précis. On pensera à des outils comme le célèbre KARMA ou encore des techniques comme l'extration de clé WEP ou de passphrase WPA depuis une station cliente. En bref, parce qu'il nécessite l'émission de ce type de requêtes, le SSID Cloaking vous expose plus que le fonctionnement normal. Si c'est pas contre-productif tout ça... Et c'est particulièrement dommage lorsque votre système d'exploitation n'émet pas ce type de trame par défaut, comme c'est le cas avec wpa_supplicant[1] ou avec la dernière mise à jour du client WiFi de Windows XP. Certes, avec les autres, ça n'aidera pas des masses puisque lorsqu'ils se trouvent hors de portée de leurs réseaux favoris, ils ne les détectent pas et basculent automatiquement en interrogation spécifique si jamais l'un d'eux se trouvait dissimulé, annonçant alors tous les SSIDs qu'ils connaissent. Si ce n'est pas au minimum une bonne fuite d'information ça...

Bref, résumé rapide : n'utilisez pas le SSID Cloaking et, si vous êtes sous XP SP2, appliquez l'update...


Toujours dans le domaine du WiFi et plus particulièrement de la fuite d'information, David Maynor a récemment présenté un concept de la mort qui tue à Black Hat Federal, le "Data Seepage". De quoi s'agit-il ? Tout simplement d'observer le trafic d'un réseau WiFi pour en déduire tout un tas d'informations sur les clients qui y sont connectés. Ouais. C'est clairement moins rigolo que les drivers WiFi, mais ça a le mérite d'être simple et efficace. Et de ne pas manquer d'intérêt pour toute personne connaissant la valeur des informations qu'il est possible de récupérer par ce biais. Ce n'est pas pour rien qu'on parle de sécurité de l'information. Pour autant, d'ici à le saupoudrer d'une bonne dose de terrorisme islamique, il y a un pas que personnellement je n'aurais pas franchi. Ah ouais, mais c'était la BH Federal, forcément...

Pour illustrer le concept, il a publié un outil appelé Ferret. Si on essaie de l'utiliser, on s'aperçoit que le truc est affreusement buggé. Et le moins qu'on puisse dire, c'est que ça la fout quand même un peu mal, en particulier quand il s'agit de problèmes de gestion de mémoire. Surtout quand on se fout de la gueule du code des autres... OK, on est prévenu : "It is feature-poor, buggy, and probably has a remote vulnerability in it". Mais quand même, ça sent le truc codé à l'arrache, comme le montre cet exemple posté sur DailyDave :

char country[16];
[...]
if (country_len > sizeof(country-1))
    country_len = sizeof(country-1);
memcpy(country, px+offset, country_len);
country[country_len] = '\0';

Si effectivement, comme le fait remarquer l'auteur du message, calculer un sizeoff(country-1) à la place d'un sizeof(country)-1 ne représente à priori pas un gros soucis de sécurité dans le présent cas, on risque par contre d'avoir un peu de mal à effectivement remplir country avec des données réellement utilisables...

Notes

[1] scan_ssid=0, valeur par défaut