SOURCE Conference Blog

'est via le Diary du SANS que j'apprenais la présence d'un malware dans le package logiciel qui accompagne un chargeur de piles USB Energizer. Par malware, on entendra une fort jolie backdoor qui permet d'accéder système à distance. Pas top.

Plus récemment c'est cette histoire de smartphone infecté qui est arrivée sur la table. Un utilisateur, se trouvant également être un employé de l'éditeur d'antivirus PandaSecurity, se s'étonnait d'avoir à faire face à un HTC Magic bien décidé à lui délivrer quelques méchanteries bien senties, dont le désormais célèbre Mariposa... Incident isolé qu'on nous dit...

Deux fois en moins d'une semaine, voilà de quoi susciter l'attention. Pour autant, c'est très loin d'être la première fois qu'on trouve du code malveillant distribué avec un équipement tout ce qu'il y a de plus légitime. Qu'il s'agisse d'une clé ou d'un disque dur USB, d'un cadre photo qui clignote, d'une machine pré-imagée ou de tout autre périphérique comme c'est le cas ici avec cet HTC Magic façon Vodafone Espagne, avec les exemples sont légion. Et si on s'intéresse aux bundles logiciels infectés ou backdoorés, on peut allègrement remonter en arrière de plus d'une dizaine d'années. Il n'y a donc pas de raison particulière de s'en émouvoir outre mesure, tout au plus d'exprimer une inquiétude bien légitime face au sentiment que les choses ne vont pas en s'arrangeant...

D'aucuns y voient un signe supplémentaire de l'échec flagrant de l'industrie de l'antivirus. J'aurais envie de leur dire qu'il ne sert à rien de tirer de la sorte sur les blessés, encore moins sur l'ambulance. Car cette histoire leur donne probablement plus tort que raison. En effet, si leur réactivité, bien qu'habituelle, peut-être blâmée dans le cas du trojan Energizer, il s'agissait manifestement d'un code inédit, donc non détectable via les bases de signature. Talon d'Achille bien connu et complètement assumé de ces produits. Par contre, dans le cas du HTC, c'est bel et bien l'antivirus qui a œuvré en bloquant Mariposa, ainsi que l'infection du poste par le non moins prolifique Conficker ou l'installation du voleur de d'identifiants Lineage.

Si le blâme paraît donc peut-être un peu facile, il est par contre tout à fait intéressant de s'interroger sur la pertinence d'un service plus ciblé comme SiteAdvisor quand on voit que ce dernier déclarait le logiciel Energizer sain depuis sa mise en ligne en mai 2009. Car si ce dernier ne se montre incapable de détecter l'apparition de nouvelles menaces sur la vaste toile, une conclusion tout à fait évidente s'impose : il n'apporte que très peu de valeur ajoutée par rapport à l'antivirus classique. Bref, si le propos de SiteAdvisor n'est que de scanner le web à la recherche d'incivilités connues, à quoi sert-il ? Sinon, il convient de reconnaître que quelque travail s'impose pour affiner le tir...

Au delà des piques lancées à des gens qui, avouons le, les méritent amplement, et sans pour autant en faire l'affaire de l'année, il est tout de même notable que cette tendance à la distribution de matériel vérolé est en train de s'affirmer doucement. Peut-être même au point de devoir la considérer comme faisant désormais partie intégrante du paysage. Et là, l'opprobre n'est en rien à jeter sur les éditeurs d'antivirus en ce qu'il s'agit d'une problématique bien plus fondamentale de maîtrise de la chaîne de production. Ainsi, et dans un registre tout à fait comparable à un fabricant de clé USB qui livre du code odieusement vulnérable, nous avons avant tout affaire à des industriels qui ne maîtrisent en rien le contenu logiciel qu'ils livrent avec leurs produits.

Si on peut passer des heures à disserter sur les causes et les effets de ces carences, sur les moyens que ces gens auraient dû déployer et ceux qu'ils devront mettre en place pour y remédier à l'avenir, il n'en reste pas moins qu'il serait bon de prendre la mesure de ce signal qui retentit depuis quelques temps déjà. À savoir que même des périphériques qui nous arrivent bien emballés de provenance a priori sûres sont des sources d'infection au même titre que le web ou l'email. Et qu'il convient donc de s'en protéger. Mais si aujourd'hui cette menace s'exprime surtout à travers du malware traditionnel, une adaptation de ces moyens d'infection à leur vecteur de transport pourrait fort rapidement se montrer bien plus problématique...

We added a URL's visual to the pix/asa..so now we collect the URL's...this helps when monitoring a system as you not only see the connection, like in the old way, but now you see the urls ....As per usual you can filter it so as to look for particular organizations or countries...but using the key word you can also hunt for anything in the url...be useful if hunting C2 traffic for infections

a semaine dernière, Martin Beck a annoncé des améliorations à l'attaque sur TKIP qu'il avait publiée avec Éric Tews fin 2008. Dans son papier intitulé "Enhanced TKIP Michael Attacks", il décrit d'abord une méthode permettant de récupérer des keystreams plus longs puis une attaque sur le MIC Michael permettant de modifier le début d'une trame chiffrée.

Du travail qui fournit manifestement de bons résultats, scénarios d'exploitation à la clé, mais sous des conditions qui risquent fort de rendre ces attaques fort difficiles à réaliser puisqu'elles sont encore plus drastiques que celles nécessaires à la bonne réalisation de l'attaque originale...

Comme je l'ai déjà expliqué, les attaques en récupération de keystream sont relativement efficaces dans la mesure où le keystream récupéré est suffisamment long pour l'utilisation que vous comptez en faire d'une part, et que vous pouvez le ré-utiliser d'autre part. Dans le cas de l'attaque de Beck et Tews, si la possibilité de rejouer le keystream est bien maîtrisée, obtenir une longueur décente augmente considérablement le temps nécessaire à la réalisation de l'attaque^[1], mais également les chances de la voir échouer. D'où l'intérêt de trouver des méthodes permettant de récupérer des keystreams plus longs, plus vite.

Pour ce faire, Martin Beck propose de jouer avec la fragmentation et la prédicitibilité des entêtes IP. En effet, la valeur des trois premiers champs de l'entête IP est prédictible : les champs Version, Longeur et Diffserv donnent en général 0x4500. Sachant que les huit octets d'entête LLC/SNAP sont également connus, ça nous permet de récupérer douze octets de keystream par paquet IP observé. On peut alors les utiliser pour chiffrer des fragments d'un datagramme plus long, jusqu'à 120 octets de payload^[2]. On peut également jouer avec des paquets ARP qui fournissent nettement plus d'information puisque dans ce cas, ce sont les 28 premiers octets du payload qui sont connus^[3], ce qui repousse à 568 octets après application de la fragmentation.

À partir de là, on peut commencer à injecter du trafic à destination de la station cible. Dans l'exemple proposé, on lui envoie un TCP SYN^[4] dont l'adresse source correspond à un système contrôlé sur Internet. Si le succès est au rendez-vous, on va se retrouver avec une double situation de clair connu : d'abord parce qu'on va récupérer le TCP SYN/ACK envoyé par la station à destination de l'AP en clair sur notre serveur, ensuite parce qu'on va retrouver le TCP ACK correspondant chiffré sur le réseau Wi-Fi.

Encore faut-il que la station attaquée réponde au SYN...

La seconde partie décrit une attaque permettant de préfixer un payload chiffré par un contenu arbitraire, tout en conservant la validité du MIC. En gros, on génère une collision de MIC, ce qui est loin d'être inintéressant comme on va le voir plus loin. Si on sait faire ceci, on peut l'exploiter de la manière suivante. D'abord, on capture un paquet dont on utilisera la charge comme deuxième fragment d'une trame plus grande. Le premier fragment sera notre payload, chiffré avec un keystream connu. Ainsi, on obtient deux trames qui, une fois défragmentées, vont délivrer un paquet dont le début est maîtrisé par l'attaquant et dont la fin contient la charge du paquet capturé.

Beck propose assez naturellement d'ajouter à notre payload chiffré un ente de requête banale, à savoir un ping. Le premier fragment créé par l'attaquant contiendra donc les entêtes IP et ICMP de l'Echo Request, avec une adresse IP source correspondant, encore une fois, à une machine contrôlée sur Internet. Pour peu qu'elle réponde, la cible renverra un Echo Reply à destination de cette adresse. Mais au-delà de la réponse, ce qui est hautement intéressant dans cette méthode, c'est que le payload de ce nouveau paquet sera précisément le contenu chiffré capturé précédemment. Lequel se retrouvera en clair dans le paquet qu'on récupèrera sur Internet. Ce qui nous fournit une méthode de déchiffrement de paquet relativement puissante.

Si j'écris relativement, c'est parce qu'elle ne permet de pas de déchiffrer n'importe quelle trame. En effet, le MIC prenant en compte les adresses MAC source et destination de la trame originale, celles-ci doivent être réutilisées pour créer la nouvelle trame avec la méthode proposée. Du coup, quand on attaque une station, on ne peut appliquer cette technique qu'au trafic émis par le point d'accès à destination de cette même station. Mais c'est déjà pas mal...

En conclusion, on pourra apprécier les astuces mises en œuvre ici pour étendre un peu plus loin l'impact des attaques contre TKIP. L'attaque en collision sur le MIC est également remarquable. Cependant, si on considère les conditions nécessaires à leur exploitation, on s'aperçoit qu'elles deviennent encore plus restrictives, ne serait-ce que parce qu'on attend que la machine visée réponde à un TCP SYN ou un ping.

En tout cas, ce seront, s'il en était encore besoin, des arguments de plus pour ne plus utiliser TKIP...

i vous vous intéressez aux reflex numériques, vous avez forcément vu ou entendu une mention à la fameuse "équivalence focale 35mm". Pour résumer rapidement, on vous explique que si vous montez un objectif sur un reflex numérique équipé d'un capteur APS-C, c'est à dire ce qui équipe les boîtiers grand public ou semi-professionnels, il faut multiplier sa longueur focale par généralement 1.5 pour obtenir la focale effective. Donc que si vous montez un 200mm sur ce boîtier, vous obtiendrez l'équivalent d'un 300mm monté sur un boîtier 24x36 ou Full Frame.

C'est beau, c'est magique. Enfin quand même, quand on est un peu curieux, ou qu'on a fait un peu d'optique, on ne peut que se demander par quel miracle une valeur propre à l'objectif, sa longueur focale, se trouverait affectée par une modification de la taille de la surface sensible au niveau du boîtier. Comme pleins de choses dans la vie, c'est bien sûr un résumé un peu rapide pour expliquer la réalité. Raccourci largement exploité par certains marketeux...

En fait, considérant l'introduction, vous aurez deviné qu'il ne s'agit aucunement d'un changement de longueur focale. Cette valeur est en effet intrinsèque à l'objectif et reste strictement la même quelle que soit la taille de votre capteur. C'est un peu comme si vous affirmiez que la longueur focale d'une lentille change parce que vous avez divisé par deux la taille de l'écran qui est derrière... La conservation de cette longueur focale signifie en particulier que le plan focal, au niveau duquel se situe le capteur, se trouve toujours à la même distance de la monture^[1]. Il n'y donc aucune raison qu'on obtienne le moindre grossissement optique induit par le changement de taille du capteur. Alors il vient d'où^[2] ce fameux facteur 1.5 ?

En fait, il s'agit d'une modification de l'angle de vue. En effet, si vous considérez le faisceau de lumière qui entre dans votre objectif et qui illumine la totalité du capteur, son angle d'ouverture dépend directement de la taille de la surface sensible. Plus cette dernière est grande, plus le faisceau est ouvert. Ce qui veut dire que ce dernier sera plus ouvert pour un capteur Full Frame que pour un capteur dont les dimensions sont plus petites. Ce qui est le cas du format APS-C, avec un facteur de réduction d'environ 1.5, à savoir notre fameux facteur. En fait, ce facteur varie d'un constructeur à l'autre selon les tailles de capteur. Ainsi, sur mon K20d, le facteur est de 1.54 contre 1.53 sur mon K100d. Chez Nikon, c'est plutôt 1.5 contre 1.6 chez Canon. Sans parles des autres formats qui n'ont possiblement même pas le même rapport longueur/largeur...

Pourquoi est-ce qu'on retrouve ce facteur sous forme d'équivalence 35mm ? Si vous regardez ce qui se passe au niveau du capteur, une image enregistrée par un capteur APS-C sera en fait une partie, le centre, de l'image qu'aurait enregistré un capteur 24x36 placé au même endroit. Maintenant, si on ramène l'image capturée par le capteur APS-C à la même taille que celle prise au 24x36, donc qu'on la zoom d'un facteur 1.5, on a effectivement l'impression que la première a été prise avec une focale plus longue que la seconde. Ce qui n'est pas le cas, puisqu'il ne s'agit en réalité que d'un effet de recadrage.

Évidemment, dire qu'une image prise à l'APS-C n'est que le centre d'un cliché pris au 24x36, ce n'est pas super sexy, bien que ce soit complètement ce qui se passe. Alors on préfère parler de focale ou de grossissement équivalents. Ce qui, quand on compare deux clichés de même taille, revient à implémenter un effet de zoom numérique sur tous les clichés. Or on sait depuis longtemps ce que pensent les utilisateurs des zooms numériques, d'où leur progressive disparition du marché au profit de véritables zooms optiques. En gros, cette équivalence correspond en tout point à ce que vous pourriez faire avec The Gimp, Photoshop ou tout autre logiciel de manipulation d'image vous permettant de travailler sur un fichier RAW. Ainsi, si vous prenez une image capturée avec un capteur Full Frame, l'extraction de la zone centrale de taille 16x24 vous donnerait exactement, à densité de pixel égale, ce qu'aurait effectivement pris un capteur APS-C.

D'ailleurs, on voit bien que les objectifs spécifiquement développé pour les capteur APS-C, c'est à dire avec des diamètres restreints à cette taille de capteur et donc incompatibles avec les capteurs Full Frame parce qu'entraînant un effet de vignettage^[3], sont affublés de leur véritable longueur focale, et non de leur focale supposée équivalente. Il est également assez intéressant de constater que des boîtiers Full Frame comme le D700 de Nikon intègrent à présent le passage automatique au format APS-C quand on les monte avec un tel objectif. Ce qui évite à l'utilisateur d'avoir à recadrer lui-même.

Mais sur ce dernier boîtier qui dispose d'un capteur de 12Mpixels, considérant que la réduction de surface quand on opère en mode APS-C, on n'obtient des clichés dont la résolution n'est plus que de 5.3Mpixels. L'impact au niveau des images est donc évident : à densité de pixels égale, un cliché pris sur APS-C est nettement moins précis que le même cliché pris à "focale équivalente" sur Full Frame. D'autres facteurs entreront aussi en compte, parmi lesquelles la qualité de construction de l'objectif qui influe directement sur son pouvoir de résolution ou piqué dans le jargon. En outre, à cadrage égal, la profondeur de champ sera plus importante avec un capteur plus petit^[4], ce qui modifie l'effet obtenu de manière notable, voire donne de bien mauvaises surprises en macro par exemple lors du passage du compact au reflex, voire à l'argentique...

Donc non, quand on shoote à 200mm sur APS-C, on ne sort pas la même chose que sur Full Frame à 300mm. Même s'il est pratique de formuler les choses ainsi...

Logging - Cloud Kiler App

I am attending the RSA conference this week. The first session I attended was the Cloud Security Alliance (CSA) meeting. Reading some of the accompanying material and listening to some of the presentations and panels, I couldn’t help it but notice that the terms auditing and logging were all over.

Here is my attempt for an explanation of this. It seems that one of the reasons for this is the nature of the cloud. Think about it. You are in an environment where you don’t control much. You are in an environment where you cannot trust most of the infrastructure pieces. For example, if you are using AWS like we are doing at Loggly, you should generally not trust your AMIs (the OS images). Now, what do you do if you don’t trust someone? You observe them, you monitor them. That’s exactly what is and needs to happen in the cloud: You don’t trust the service. To mitigate this issue, you are going to monitor the service.

And to make this not just my explanation, here is what some panelists during the CSA meeting said:

“Loss of visibility in the cloud” – Scott Chasin, CTO McAfee SaaS Unit
“Lose control and still maintain accountability” – Ken Biery, Verizon Business.

Is the cloud the killer app for logging? And if that’s the case, how do you manage your logs in the cloud? There are hardly any cloud logging solutions out there. I think you see where I am going with this.

Here’s a quick post to let you know all the places to get your Veracode fix at RSA Conference 2010.

• On the Expo floor, we’ll be in booth 729. I’ll be at the booth for a few hours on Tuesday and Wednesday. Stop by if you’d like to talk about our service offerings, get a quick demo, or just say hello.
• On Monday morning at 9:25am, Ashish Larivee will be giving a presentation, Metrics for Insights on the State of Application Security at Mini Metricon.
• On Monday morning at 11:15am, I’ll be on a panel, Securely Getting to Planet SaaS at the Cloud Security Alliance Summit in Green Room 131.
• On Wednesday morning at 9:10am, Chris Wysopal will be on a panel, Whitelist or Trustlist? Should There be an Industry Software Whitelist? in Orange Room 301.
• On Wednesday afternoon at 1:00pm, Chris Wysopal will be giving a presentation, Detecting “Certified Pre-owned” Software and Devices in Blue Room 104.
• On Wednesday evening at 6:00pm, I’ll be participating in a Security Round Table at Ruby Skye, prior to the Rapid7 party.

Looking forward to catching up with everyone!

This is a snippet of a report written for an honours project I'm doing on security visualisation. Just some ideas I want to punt out there, cause it'd be nice to see them take off, & in case they've gone un-noticed because of their being in different topic areas,

Visualisation software for security can be used to display graphical information about the data being captured in real-time and also used for offline analysis. The difference between visualisation applications and the monitoring software of the previous objective is in the presentation of the data, although both kinds can and do make use of the more familiar graphs, such as line graphs, bar charts, pie charts, flow charts.
In general, information visualisation is a way to gain insight into complex datasets and textual information in a condensed and understandable way.
Consequently, evaluating a tools effectiveness means taking into account multidisciplinary areas knowledge of visual systems. Successful visualisation tools take into account user interface design, human-computer interaction, psychology of human perception, machine pattern recognition, and are as much borne from certainly the design side of art as they are about presenting quantified data.
To some extents this kind of information visualisation is quite new, and at its current stage is itself viewable as an overall discipline at a time before its emergence as a distinct discipline; but at the same time the areas that will feature heavily in its development are burgeoning in somewhat unnoticeable ways. For example, the prevalence of touchscreen mobile communications devices, whose interfaces are so intuitive and easy to pick up that many people only need a general idea – like another graphic that shows them in use – of how the interface works to be able to use it correctly. It feels natural enough to be able to press buttons with symbolic and pictorial representations of functions, go to the next page using a sweeping motion, zoom in and out to gain more precise datasets or larger overviews using hardware or onscreen rollbars and sliders, manipulating the onscreen display by tilting the device itself; the world wide web itself was designed from the outset as a distributed hypertext system. This sounds obvious as it is well known what the H in HTML stands for, but the framework itself is another example of a new idea (though clearly built upon cross-indexing, as used in libraries) that people find easy to accept without really noticing it – the amount of extra data conveyed within a document using an tag, navigation made easier with anchors, the hypertext links themselves that allow keywords when activated by a button click to jump to another document with further information in relation to the keyword, the use of tabbed graphical browsers – these web basics are so integrated to the user precisely because they use intuitive design interfaces.
The same ease of information access is also behind why it is so frustrating for the user to have the desktop or interface become slowed down and cluttered with unwanted elements, which aside from being relevant to the overall objectives of this project (as spam and other malware and adware are certainly cumbersome additions to any user experience) give very good design tips of what to include and not include in a graphical console.

To some extents the development of information visualisation has been impeded because the hardware is either too expensive, spacious, or simply not available yet, therefore not able to keep up with the code requirements of the applications or the amount of data needing to be accessed, sorted through, processed. As previously mentioned, clustering is definitely a viable solution to many of the problems slowing down development. Parallel computing and information visualisation station design are very complimentary, as the latter greatly benefits from incorporating the former; this is easily understood by merely counting the amount of nodes being monitored in a given network, and considering that the monitoring station has to capture, make sense of (to various degrees), and possibly interpret and present, and certainly store or produce hard copies in realtime, for all of the nodes combined.
Video game hardware and onscreen interfaces, and music visualisers, are another two areas where a lot of progress has already been made that can be directly lifted and incorporated into information visualisation.

Like lightpens and graphics tablets used for a long time in artistic and photo editing digital applications, devices that offer remote pointing that manipulates onscreen elements are very useful to someone sat far back from multiple monitors, as the interaction is required but their field of vision has to be able to take in all the displays.
There are other existing solutions here also, particularly in the field of wearables, such as being able to fit large display formats inside regular sized glasses, and using one-handed small footprint keypad controllers.
Again, other existing areas have already taken multifunction keypad concepts onboard – gaming and video editing decks being prime examples. These allow complex functions to be executed with a key press, by assigning the desired functions as hotkey shortcuts.
Onscreen GUI menus in games offer the user at-a-glance statistics and information as well as easy access to point-of-view changes, and commonly offer the same information on teammates and enemies – it can be seen how this can be utilised in realtime security monitoring, to track multiple connections and see data on them continually updated, monitor a collegues progress, and shift between emphasis on varying datasets without having to minimise or close any displays.
Online and network gaming network configurations themselves have to deal with multiple users changing the game elements on a constant basis, and be able to update the changes and present them to all users in a synchronised way, so everyone is interacting with the same scenario. This is for now more successful in some places than others, purely because of latencies and the haphazard manner that packets may traverse the internet, and also of course based on the users own hardware and the features offered by their ISP and the associated telecoms infrastructures. However the framework itself is available and in a LAN environment can be demonstrated to work very well.
Graphics cards have also developed greatly in recent years, to the extent that what would have required a dedicated visualisation station can now be done on a home PC with one to four graphics cards. GPU and CPU hybrid systems are already in the Top 500 Supercomputer listings and the main hardware chip vendors are or have already been focusing a lot of attention on GPU development.
Music visualiser applications can also be adapted to instead of matching the visuals to audio events, to match them to network or other data events. This is a very promising area as baselining can be used to produce a backgrounded pattern or visual of the networks behaviour, and therefore any fluctuations are readily noticeable even to someone knowing nothing about network data itself.
Use of colour and shading types is also very relevant, and comes out of areas like topography. Many current security and network visualisation tools allow the user to alter colouring of data elements to suit themselves; this is another important consideration of a user interface and from a security point of view is a welcome feature, as user view customisation makes it potentially less obvious to an intruder what the data represents. Of course in collating and sharing data between the authorised users, means there has to be a means to easily combine differing views, which can be done with mapping and parsing.

a fait un peu plus d'un mois qu'on me rabat les oreilles avec la Wifi-Box. Cet équipement, décrit comme le "Wifi network unlocker", capable de déverrouiller les réseaux Wi-Fi protégés qui vous entourent, a l'air de retenir pas mal l'attention de nos chers relais de news comme remède au mal HADOPI. Korben n'a même pas pu se retenir de se fendre d'un test la semaine dernière...

Alors on me demande régulièrement si cette Wifi-Box, essentiellement composé d'un périphérique USB muni d'une proéminente antenne, est bien le casse Wi-Fi de poche qu'on nous promet à tous les coins de news ? Et bien que n'ayant pas testé le produit, mais ayant fait le tour des specifications et du test mentionné plus haut, il me semble que la réponse est aussi simple qu'attendue : évidemment non...

Pour se convaincre de cela, il n'est même pas nécessaire de s'attarder sur le test de Korben ; il suffit de se pencher sur la description du produit. La simple lecture du contenu du package, des caractéristique du boîtier et du mode de fonctionnement général permet d'arriver assez rapidement à la conclusion suivante : en fait, il s'agit d'une carte Wi-Fi USB haute puissance avec une antenne externe omni 6dBi d'un fort beau gabarit, le tout livré avec une BackTrack obsolète aggrémentée de SpoonWEP2 et un manuel. Ni plus, ni moins...

Rien de bien neuf sous le soleil donc, mais l'initiative pourrait rester intéressante. Seulement, à 70USD port non compris^[1], je trouve le package un peu cher, considérant qu'il faut le faire venir d'Asie. On trouve en effet des équipements équivalents, haute puissance en USB avec connecteur d'antenne, voire supérieurs comme l'AWUS036H, pour moins de 50EUR en France^[2], et carrément moins cher à l'étranger, en particulier outre-atlantique et surtout en Asie. De plus, considérant la facilité avec laquelle on peut ramener une BackTrack et la profusion de tutoriels disponibles sur le net, je doute que la différence de prix soit justifiée par ce dernier apport.

Mais au moins, on ne trompe pas le client. Tout ceci est clairement expliqué, encore faut-il prendre le temps de lire la description. Ce que les sites qui ont annoncé le support du cassage de PSK n'ont pas dû faire puisqu'il est spécifié très explicitement que si le produit peut cracker des clés WEP, les clés partagées WPA ou WPA2 ne sont pas au programme, puisque non supportées par SpoonWEP. Ce qui est fort honnête de leur part. Il aurait en effet été facile d'annoncer ce support, puisque des outils sont disponibles sur BackTrack à ces fins, mais on aurait cruellement manqué d'un bon gros dictionnaire efficace pour y parvenir. Ceci étant, à leur décharge, casser du WPA/WPA2 PSK, ça reste très surfait dans un monde où que certains FAI s'obstinent encore à livrer des box dont le Wi-Fi est protégé en WEP par défaut^[3]. Et casser du WEP aussi quand d'autres se prennent à générer leurs clés préconfigurées en fonction du SSID ;)

Pendant ce temps, à Vera Cruz, on notera qu'en matière de cassage de PSK, les dernières versions de Pyrit apportent des gains de performance de l'ordre de 20% à 30%^[4]...

Bref, la Wifi-Box est très sûrement une belle carte Wi-Fi USB qui fournit quelques 500mW^[5], là où une AWUS036H vous délivrera le double, livrée avec une fort jolie antenne, mais ça s'arrête clairement là. Le reste, la BackTrack 3 avec SpoonWEP2 et la documentation, relève quand même pas mal du cosmétique. À vous de voir si ça justifie une dizaine d'euros de plus. Rien à voir en tout cas, dans le produit comme dans l'esprit, avec un système comme HostileWRT avec lequel on ne manque pas de la comparer. À tort manifestement...