Le concept de Websocket fait partie des fonctionnalités qui sont en train d'émerger avec HTML5, CSS3, les device events, etc. Elles servent principalement à remplacer les hacks utilisés par les développeurs web de la nouvelle génération (comprendre Web2 (attention aux allergiques)); ces hacks étant, pour faire simple, une solution au manque de canal de communication persistent, bidirectionnel et évènementiel (en Javascript, car Flash et Java possèdent déjà leur solution) entre le client et le serveur .
Les Websockets sont une des briques qui permettent (permettront) de transformer radicalement l'expérience web de tous les utilisateurs d'Internet (une fois encore).
Contexte
Cinq chercheurs dont trois très reconnus dans le domaine ont publié / signé récemment un papier de recherche intitulé :
"Transparent Proxies: Threat or Menace?"
Ce papier fait état de deux vulnérabilités liées à l'utilisation de sockets binaires dans un environnement présentant des proxys HTTP transparents.
On y lit que les Websockets sont concernées, ainsi que Flash et Java. Une proposition de correction pour le draft Websocket est présentée.
Deux semaines plus tard, Firefox 4 et Opera décident de désactiver la fonctionnalité le temps qu'une nouvelle version soit proposée. Ce nouveau draft rendra toutes les implémentations clients/serveurs actuelles obsolètes.
Explication
Le papier décrit deux problemes, dont la source est commune :
Un proxy HTTP qui s'emmêle les pinceaux entre ip, host et vhost.
Les sockets binaires, qu'elles soient faites avec Flash, Java ou Javascript, ne sont qu'un vecteur permettant de forger la requête nécessaire à l'exploitation du proxy vulnérable.
Ce type de vulnérabilité n'a rien de nouveau et nous avons déjà eu l'occasion d'en tester quelques unes dans des scénarios externes (ce qui nous a permis d'accéder à des services internes).
Le premier problème se situe au niveau du routage, imaginez un scénario ou un navigateur établit une connexion vers un serveur 1.1.1.1, avec un header HTTP falsifié du serveur google.com "Host: google.com".
Il arrive qu'un proxy transparent, capturant la requête à l'insu de l'utilisateur et du serveur, se permette de rediriger la connection vers google.com (plutôt que sur le serveur 1.1.1.1). Nous ne nous intéresserons pas à ce cas dans ce billet.
Le deuxième problème concerne les fonctionnalités de cache de ces proxys, et cela semble bien plus intéressant.
Tout comme précédemment, imaginons le scénario durant lequel nous forçons un navigateur à se connecter à un serveur nous appartenant, en forgeant la requête afin de demander une ressource du vhost google.com ("Host: google.com"). Si notre serveur lui fournit une ressource malicieuse avec un header de cache de dix ans, alors un proxy invisible/transparent, analysant le flux à la volée, pourrait au milieu de cet échange prendre la décision de mettre cette ressource en cache.
Le souci est que comme vu précédemment (bien que le cas soit différent), ce proxy se contente de croire le header "Host:", en ignorant le "pinning" vhost-ip pourtant évident à des fonctionnalité de ce type. Il en résulte qu'à la prochaine requête (légitime cette fois) vers cette ressource de google.com (faite par un navigateur passant par le noeud où se trouve ce proxy), son cache sera invoqué et la ressource malicieuse chargée à la place de la légitime (Cache-poisoning).
Dans les scénarios réels évoqués, l'exemple du fichier javascript "ga.js" correspondant à google-analytics est révélateur, mais l'on pourrait tout aussi bien imaginer des attaques sur des webmails ciblés (étant donné que l'attaque nécessite de toutes façons une intervention extérieure derrière un proxy vulnérable).
Contenu
Ce papier contient une partie de description technique, une étude basée sur l'exploitation d'une masse de la population, et une proposition de solution pour les Websockets.
La proposition de draft pour les Websockets ne sera pas détaillée ici. Les lecteurs intéressés se réfèreront aux discussions de la mailing list associée.
Pour commencer, il n'apporte rien de nouveau d'un point de vue technique: d'un côté les premiers problèmes liés au pinning DNS (association forcée d'un domaine et d'une ip pour une session donnée) ont été rendus publics en 1996 (ils impliquaient les applets Java). Contrairement à ce qui est écrit dans le papier, ces problèmes ne sont pas récents, même les médias s'en sont emparés il y a trois ans, voire quatre pour certaines présentations (Collin Jackson et Adam Barth, deux des auteurs dont on parle, ayant même participé à un papier résumant le sujet en 2007).
De l'autre côté, les problématiques (évoquées plus haut) liées aux proxys transparents ont déjà été très longuement décrites en 2009, dans un papier de recherche de Robert Auger (PayPal) qui suivait un avis de l'US-CERT.
Les exploits développés sont en Flash et Java, et ils n'ont pas été rendus publics. Les chiffres de personnes vulnérables au cache poisoning (basé sur Java ou Flash) sont de moins de 50 sur 150000 (pour plus de détails reportez vous au papier). N'ayant pas la possibilité légale de reproduire les tests effectués par ces chercheurs (tests d'exploitation de masse sans consentement), nous ne pourrons les vérifier.
Néanmoins, nous avons reproduit une des attaques, et vous proposons de la tester de manière volontaire (Flash doit être activé, c'est compatible tous navigateurs, il suffit de cliquer sur le bouton bleu pour lancer le test qui prendra entre une et quinze secondes à s'effectuer):
Si vous obtenez une croix rouge à ce test, vous êtes vulnérable au cache poisoning. Nous sommes intéressés par vos retours, en particulier par le nom de l'équipement, version et configuration qui seraient mis en cause. N'hésitez pas à nous contacter: contact@atlab.fr.
A retenir
- Des chercheurs académiques se sont permis de tester et répertorier le taux d'expansion d'une vulnérabilité de manière mondiale au travers de l'achat d'un espace annonceur (probablement sans le consentement de l'annonceur, et surement sans celui des utilisateurs).
- La vulnérabilité est liée à des proxys transparents non à jour, les Websockets étant un vecteur d'exploitation.
- Aucun exploit en pur Javascript - WebSocket n'a été développé ou n'a été mentionné (les tests ont été effectués avec Java et Flash).
- Les exploits basés sur Flash ou Java seront toujours fonctionnels et le resteront très probablement aussi longtemps que ces plugins existeront.
- Le pourcentage de personnes vulnérables est très faible (de l'ordre de 0,03%) pour une attaque à tendance ciblée sur un proxy d'entreprise.
- Ce papier n'a rien apporté de nouveau d'un point de vue technique.
- Il est responsable de la refonte complète du handshake (qui devient beaucoup plus complexe), a rendu obsolète toutes les implementations courantes du protocole, et après médiatisation a fait désactiver la fonctionnalité dans Firefox4 et Safari.
L'équipe Atlab toute entière vous souhaite une bonne fin d'année.
(Pour les heureux possesseurs de Google Chrome et son V8, un joyeux noël en retard).
