Hardware

Méthode.

Même Google l'impose pour effectuer une simple recherche et plus aucun grand site (Facebook, Twitter, etc.) ne gère l'authentification de ses ouailles sans y avoir recours. Ce protocole de cryptage reste pour l'heure inviolé mais des techniques existent pour passer outre, par exemple en s'intercalant entre le client et le serveur via une technique MITM (man-in-the-middle). La mise en place d'un point de vue logiciel s'avère nettement plus compliquée qu'une simple récupération de paquet avec WireShark et nous ne rentrerons pas ici dans les détails. Une fois l'ensemble correctement paramétré, l'utilisateur reçoit alors un message d'avertissement lui indiquant que "l'identité du site n'a pu être vérifiée" mais il conserve la possibilité de l'ignorer. S'il choisit cette option, il obtiendra le petit cadenas habituel et la navigation se poursuivra sans autre forme de procès. Nous avons voulu savoir combien de personnes outrepasseraient la mise en garde de leur navigateur ou de leurs Apps sur smartphone. L'expérience précédente a donc été reproduite pendant deux heures, mais cette fois avec un système élaboré de réécriture des certificats SSL.

Données récupérées.

Autant mettre tout de suite fin au ­suspense : les résultats font froid dans le dos. Environ 60 % des utilisateurs de notre point d'accès public ont ignoré les messages d'avertissement et continué à naviguer comme si de rien n'était. Nous avons pu récupérer tout ce qu'il est possible d'imaginer, en particulier un grand nombre de mots de passe de Twitter et ­Facebook. Une fois la session SSL "cassée", ils transitent en clair dans les paquets. Et les néophytes ne sont pas les seuls à fouler au pied les règles élémentaires de sécurité. Un administrateur réseau s'est ainsi servi de notre borne publique pour accéder à son compte OVH, probablement pour gérer un de ses serveurs. Immédiatement, nous avons pu récupérer son identifiant et son mot de passe. Un autre utilisateur s'est connecté à Amazon via l'application iOS dédiée. Impossible de savoir s'il a obtenu ou non un message d'avertissement, mais nous avons illico récupéré ses identifiants. Mais le pire reste à venir. Nous nous sommes aperçus à l'analyse des logs qu'un certain Éric B., connecté au point d'accès, n'avait pas hésité à passer une petite commande chez un revendeur en ligne avec leur Carte Bleue ! A priori, nous pensions que les services bancaires (ATOS en l'occurrence) avaient mis en place un système de pré-encodage sur leurs informations ultra-sensibles. Il n'en est rien : les informations de paiement circulent en clair une fois la session SSL compromise et nous avons pu lire une copie de la carte VISA d'un certain Éric Belkacem. Numéro, date d'expiration et même CVV (le cryptogramme situé à l'arrière), tout y est ! Devant l'ampleur de ces fuites de données, largement suffisantes pour valider l'expérience, nous nous sommes arrêtés là.

L'origine de la fuite.

Impossible ensuite de contacter la plupart des utilisateurs qui ont volontairement ignoré l'avertissement. Des informations type e-mails ou numéros de téléphone figuraient très probablement dans les logs, mais nous avons préféré les effacer. Une remarque s'impose malgré tout. Quelques tests effectués par la suite sur deux tablettes (Android et iOS) ont montré que les applications n'affichaient pas toujours d'avertissement en cas de certificat SSL non valide. Toutes refusent de fonctionner si AUCUN certificat n'est reçu, mais si un semblant de certificat "pseudo-valide" est présenté (expiré, concernant un autre site…), certaines s'en contentent ou n'affichent qu'un message sibyllin et très peu ­anxiogène. De même, une technique particulière permet d'exploiter une faille de certains navigateurs pour "optimiser" le message d'erreur affiché et ainsi inciter l'utilisateur à l'ignorer. Non, nous n'en dirons pas plus !