À en croire Frederik Kriewitz, il est possible de récupérer le login et le mot de passe d'un utilisateur lorsqu'il s'authentifie à un portail FON. Argh... Alors que tout semble se passer dans une belle session HTTPS toute propre, une petite redirection maladroite vers une page non chiffrée suffit à tout mettre par terre.

[Update] Pour répondre au commentaire de jme, voici un schéma[1] détaillant l'échange. Les numéros représentent les différentes étapes de l'authentification.

Authentification FON

Lorsqu'un utilisateur non authentifié demande une page web (1), disons http://www.google.com/, le portail captif le redirige (2) directement à l'aide d'un 302 vers une URL du type https://login.fon.com?challenge,mac,uamip,uamport,hotspotmac dans laquelle les variables sont les suivantes :

  • challenge : une chaîne de caractères ;
  • mac : l'adresse MAC du client ;
  • uamip, uamport : l'IP et le port sur lesquels est accessible le portail captif du routeur FON ;
  • hotspotmac : l'adresse MAC du routeur FON.

L'utilisateur accède donc à un portail HTTPS sur lequel il entre son login et son mot de passe (3), mais sur le site de FON, pas sur le routeur, comme vous pouvez le voir. Or l'utilisateur doit s'authentifier sur le routeur pour sortir, puisque c'est lui qui va devoir placer les autorisations ad hoc. Le navigateur reçoit donc en guise de réponse (4) une redirection une URL de la forme http://uamip:uamport?username,challengedPW, où username représente le login de l'utilisateur et challengedPW une chaîne générée à l'aide du challenge précédemment présenté, du mot de passe et d'un secret partagé entre le site FON et le portail captif du routeur qui s'avère être le logiciel Chillispot. Le client se connecte donc à cette URL (5) ce qui va permettre au routeur de valider le login/password présenté (6) auprès de FON et de pousser une autorisation le cas échéant.

On fait alors face à deux problèmes :

  • la première redirection (2) est envoyée en clair comme réponse à la première requête HTTP de l'utilisateur, ce qui permet à un attaquant de récupérer le challenge ;
  • la connexion consécutive à la seconde redirection (5) permet de récupérer le login et la chaîne challengedPW.

Si on regarde le code de Chillispot, il est simple de trouver l'algorithme qui permet de récupérer le mot de passe en décodant la chaîne challengedPW, le seul élément inconnu étant alors le secret partagé, sur lequel va donc reposer toute la sécurité de l'édifice. Or il se trouve qu'il est connu parce que commun à tous les routeurs FON. Dès lors, il est trivial pour l'attaquant de retrouver le mot de passe à partir de l'observation d'une authentification réussie.

Le problème a été exposé fin juillet dans un forum FON et s'est trouvé confirmé par d'autres utilisateurs. Cependant, il ne serait toujours pas pris en compte et Frederik a décidé de passer à l'offensive en publiant un outil permettant d'extraire les éléments d'authentification FON d'une trace pcap. En fait, l'outil a l'air un peu plus générique que cela. Il semble en effet permettre de récupérer les identifiants de tout utilisateur s'authentifiant sur un hotspot Chillispot si on connait le secret partagé. Les "foneros" n'ont qu'à bien se tenir, en ouvrant directement https://login.fon.com/ au lieu d'un site quelconque en clair, même si l'impact n'est finalement que relativement faible, puisque, si j'ai bien suivi, ces éléments permettant un accès illimité, l'attaquant pourrait obtenir l'accès, mais sans porter atteinte au porte-feuille de l'utilisateur légitime. Par contre, l'argument de la sécurité en prend encore un sacré coup puisque les couples login/password perdent leur valeur comme élément d'authentification des utilisateurs : si n'importe qui peut les récupérer par simple écoute du réseau, on ne peut pas s'y fier pour imputer une action[2] à quelqu'un. Déjà qu'on pouvait spoofer n'importe qui, maintenant, on peut carrément utiliser son compte. On touche le fond...

C'est bien à la lumière de ce genre de problème, qui sera probablement corrigé prochainement[3], qu'on voit l'importance de fournir des moyens de connexion sécurisés du début à la fin de la session WiFi et que l'utilisation d'un réseau ouvert ne fait que compliquer les choses de ce point de vue là, sans pour autant atteindre son but. Et d'ailleurs, vous savez ce qu'utilise Chillispot pour valider ses authentifications ? Un serveur RADIUS... Pourquoi ne pas l'attaquer directement en EAP, ce serveur RADIUS ?! Maintenant, je pourrais terminer en paraphrasant la conclusion de Jim Geovedi, elle-même empruntée à Andrew Cushman, grand patron sécurité chez Microsoft, "Why don't you ask them to write better code ?". Mais non, je vais juste détourner légèrement cette citation : "Why don't you ask them to use secure means ?". Parce que dans ce cas, en utilisant quelque chose de propre, ils n'auraient même pas besoin de l'écrire, le code sécurisé en question...

Notes

[1] Fait sous Dia, na !

[2] Malhonnête en particulier...

[3] Jusqu'au suivant...