L’adresse 0.0.0.0 au cœur d’une très ancienne faille de sécurité des navigateurs
La société de sécurité Oligo a publié hier un article de blog expliquant qu’elle avait alerté les fournisseurs de navigateurs d’une faille critique dans la façon dont ils gèrent l’adresse 0.0.0.0, qui peut rediriger les attaquants vers des ressources locales et l’exécution de code à distance.
0.0.0.0 Day : c’est le nom donné par la société israélienne Oligo à cette faille présente dans Chrome, Firefox et Safari. Elle n’a cependant rien de nouveau puisque dans certains cas elle remonte à 18 ans. Oligo précise cependant qu’elle a été découverte » récemment « .
L’adresse IP 0.0.0.0 est particulière et n’a pas la même signification selon le contexte. Sur Wikipédia, on retrouve les deux cas les plus courants. Dans le contexte d’un serveur par exemple, elle a pour valeur « toutes les adresses IPv4 de la machine locale ». Dans le domaine du routage en revanche, elle signifie le plus souvent « route par défaut ». En IPv6, plutôt que d’écrire une longue chaîne de zéros, on utilise la notation « :: ».
Quel est le rapport avec les navigateurs ? Ce problème résulte d’une mise en œuvre incohérente des mécanismes de sécurité entre les navigateurs, ainsi que d’un manque de normalisation au sein du secteur des navigateurs. « , résume Oligo.
Tous les navigateurs sauf Windows
La vulnérabilité trouvée est décrite comme « fondamental » Et » logique « . Il réside dans Chromium ainsi que dans Firefox et Safari. macOS et Linux sont concernés, mais pas Windows. Microsoft a en fait décidé de bloquer l’adresse 0.0.0.0 il y a plusieurs années.
Le problème découvert par Oligo réside dans la façon dont les navigateurs traitent les requêtes vers la fameuse adresse IP. Elle peut être utilisée pour exploiter des services locaux. Un site web public (comme les domaines se terminant par .com, .fr, etc.) sont des « capable de communiquer avec les services exécutés sur le réseau local (localhost) et potentiellement d’exécuter du code arbitraire sur l’hôte du visiteur en utilisant l’adresse 0.0.0.0 au lieu de localhost/127.0.0.1 » explique Oligo.
En bref, toute application exécutée sur localhost et accessible via 0.0.0.0 est susceptible d’être exécutée à distance. Les attaquants peuvent alors formuler une requête malveillante et l’envoyer à l’adresse 0.0.0.0 de la victime, dans l’espoir d’accéder aux ressources locales. S’ils y parviennent, un large éventail de possibilités s’ouvre à eux, avec un large choix de vecteurs pour de nouvelles attaques.
Un grand nombre de configurations vulnérables
En pratique, Oligo estime que la faille touche principalement les particuliers et les entreprises hébergeant des serveurs web pour certains scénarios, notamment des tests de développement. Mais malgré cela, les chercheurs estiment que le nombre de configurations vulnérables est très élevé.
En mars dernier, par exemple, une cyberattaque a détourné la puissance de calcul à des fins d’extraction de crypto-actifs en détournant le logiciel Ray, rapporte Forbes. Ray est utilisé par de nombreuses grandes entreprises pour entraîner des modèles d’IA. Une configuration basée sur un hôte local et une API non protégée ont rendu l’attaque possible. Anyscale, qui supervise le développement de Ray, a protesté. L’entreprise a fait référence à son guide de configuration, qui déconseille fortement d’exposer Ray à un trafic réseau non fiable.
» Lorsque les services utilisent localhost, ils supposent un environnement contraint. Cette hypothèse, qui peut (comme dans le cas de cette vulnérabilité) être erronée, entraîne des implémentations de serveur non sécurisées. « , résume Avi Lumelsky, chercheur principal à l’origine de l’étude Oligo.
Les entreprises s’efforcent de combler cette lacune
Apple a confirmé à Forbes qu’il travaillait sur le problème. Dans une future version bêta de macOS Sequoia, le problème ne devrait plus exister. Safari 18 devrait bloquer complètement l’adresse 0.0.0.0 dans le nouveau macOS. Au fur et à mesure que de nouvelles versions du navigateur seront transférées sur le système précédent, Sonoma en bénéficiera également. La situation est plus floue pour les anciennes versions.
Chez Google, la prochaine révision 128 de Chrome bloquera également l’adresse 0.0.0.0. Ce changement sera déployé progressivement au cours des prochaines versions, jusqu’à ce qu’un blocage complet soit implémenté pour Chrome 133.
Dans la fiche d’information de Google, on peut lire que cette mesure est adoptée avant que le Private Network Access n’entre en jeu. Le PNA est une spécification (encore en projet) pour un mécanisme de limitation de » la capacité des sites Web à envoyer des requêtes à des serveurs situés sur des réseaux privés « . PNA étend également le protocole CORS (Cross-Origin Resource Sharing). Avec PNA, les sites web doivent donc demander explicitement l’autorisation à des serveurs situés sur des réseaux privés pour leur envoyer des requêtes. Or, la faille découverte par Oligo permet de contourner entièrement PNA.
Chez Mozilla, c’est un peu plus compliqué. Firefox va adopter l’accès au réseau privé, mais ne prévoit pas de bloquer immédiatement l’adresse 0.0.0.0. Le navigateur n’ayant jamais restreint l’accès au réseau privé, il n’y a pas de vulnérabilité à signaler. Après l’avertissement d’Oligo, Mozilla a tout de même proposé une modification de la spécification Fetch pour introduire le blocage 0.0.0.0. Imposer des restrictions plus strictes comporte un risque important d’introduire des problèmes de compatibilité. « , a toutefois déclaré Mozilla à Forbes.
Oligo présentera ses conclusions plus en détail le 10 août au DEF CON à Las Vegas.
