Une vulnérabilité révélée il y a 18 ans, baptisée « 0.0.0.0 Day », permet aux sites Web malveillants de contourner la sécurité dans Google Chrome, Mozilla Firefox et Apple Safari et d’interagir avec les services sur un réseau local.
Cependant, il convient de noter que cela n’affecte que les appareils Linux et macOS et ne fonctionne pas sous Windows.
Pour les appareils concernés, les auteurs de menaces peuvent exploiter cette faille pour modifier à distance les paramètres, obtenir un accès non autorisé aux informations protégées et, dans certains cas, exécuter du code à distance.
Bien qu’il ait été signalé en 2008, il y a 18 ans, ce problème n’est toujours pas résolu sur Chrome, Firefox et Safari, bien que tous les trois aient reconnu le problème et travaillent à le résoudre.
Les chercheurs d’Oligo Security rapportent que le risque rend non seulement les attaques théoriquement possibles, mais a également observé de multiples acteurs de la menace exploitant la vulnérabilité dans le cadre de leurs chaînes d’attaques.
La faille du jour 0.0.0.0
La vulnérabilité 0.0.0.0 Day provient de mécanismes de sécurité incohérents entre les différents navigateurs et du manque de standardisation qui permet aux sites Web publics de communiquer avec les services du réseau local en utilisant l’adresse IP « générique » 0.0.0.0.
En règle générale, 0.0.0.0 représente toutes les adresses IP sur la machine locale ou toutes les interfaces réseau sur l’hôte. Il peut être utilisé comme adresse d’espace réservé dans les requêtes DHCP ou interprété comme l’hôte local (127.0.0.1) lorsqu’il est utilisé dans un réseau local.
Les sites Web malveillants peuvent envoyer des requêtes HTTP à 0.0.0.0 ciblant un service exécuté sur la machine locale de l’utilisateur, et en raison d’un manque de sécurité cohérente, ces requêtes sont souvent acheminées vers le service et traitées.
Les mécanismes de protection existants tels que le Partage de ressources d’origine croisée (CORS) et l’accès au réseau privé (PNA) ne parviennent pas à arrêter cette activité risquée, explique Oligo.
Par défaut, les navigateurs Web empêchent un site Web de faire des demandes à un site Web tiers et d’utiliser les informations renvoyées. Cela a été fait pour empêcher les sites Web malveillants de se connecter à d’autres URL dans le navigateur Web d’un visiteur sur lesquelles il peut être authentifié, comme un portail bancaire en ligne, des serveurs de messagerie ou un autre site sensible.
Les navigateurs Web ont introduit le partage de ressources d’origine croisée (CORS) pour permettre aux sites Web d’accéder aux données d’un autre site s’ils y sont explicitement autorisés.
« CORS est également formidable et rend déjà Internet beaucoup plus sûr. CORS empêche les réponses d’atteindre l’attaquant, de sorte que les attaquants ne peuvent pas lire les données lorsqu’ils effectuent des requêtes invalides. Lors de l’envoi d’une requête, Si les en-têtes CORS ne sont pas présents dans la réponse, le code Javascript de l’attaquant ne pourra pas lire le contenu de la réponse.
CORS arrêterait seulement la réponse avant qu’elle ne se propage à JavaScript, mais les requêtes opaques peuvent être envoyées en mode “no-cors” et atteindre le serveur avec succès—si nous ne nous soucions pas des réponses. «
❖ Oligo
Par exemple, si l’objectif d’un auteur de menace est simplement d’atteindre un point de terminaison HTTP s’exécutant sur un périphérique local qui pourrait être utilisé pour modifier un paramètre ou exécuter une tâche, la sortie n’est pas nécessaire.
Oligo explique que la fonctionnalité de sécurité d’accès au réseau privé (PNA) le fait un peu différemment de CORs en bloquant toutes les requêtes tentant de se connecter à des adresses IP considérées comme locales ou privées.
Cependant, les recherches d’Oligo ont révélé que l’adresse IP spéciale 0.0.0.0 n’est pas incluse dans la liste des adresses PNA restreintes, comme 127.0.0.1 par exemple, donc l’implémentation est faible.
Par conséquent, si une requête est faite en mode « no-cors » à cette adresse spéciale, elle peut contourner PNA et toujours se connecter à une URL de serveur Web fonctionnant sur 127.0.0.1.
Breachtrace a confirmé que la faille fonctionnait lors d’un test sur Linux avec le navigateur Firefox.
Activement exploité
Malheureusement, le risque n’est pas seulement théorique. Oligo Security a identifié plusieurs cas où la vulnérabilité « 0.0.0.0 Day » est une activité exploitée à l’état sauvage.
Le premier cas est la campagne ShadowRay, que les mêmes chercheurs ont documentée en mars dernier. Cette campagne cible les charges de travail d’IA exécutées localement sur les machines des développeurs (clusters de rayons).
L’attaque commence lorsque la victime clique sur un lien envoyé par e-mail ou trouvé sur un site malveillant qui déclenche JavaScript pour envoyer une requête HTTP à ‘http://0 [.]0[.]0[.]0: 8265’, généralement utilisé par Ray.
Ces requêtes atteignent le cluster Ray local, ouvrant des scénarios d’exécution de code arbitraire, de shells inversés et de modifications de configuration.
Un autre cas est une campagne ciblant la grille de sélénium, découverte par Wiz le mois dernier. Dans cette campagne, les attaquants utilisent JavaScript sur un domaine public pour envoyer des requêtes à ‘http://0 [.]0[.]0[.]0:4444.’
Ces requêtes sont acheminées vers les serveurs Selenium Grid, permettant aux attaquants d’exécuter du code ou d’effectuer une reconnaissance du réseau.
Enfin, la vulnérabilité » ShellTorch » a été signalée par Oligo en octobre 2023, où le panneau Web TorchServe était lié à l’adresse IP 0.0.0.0 par défaut au lieu de localhost, l’exposant à des requêtes malveillantes.
Réponses des développeurs de navigateurs
Oligo signale une augmentation soudaine du nombre de sites Web publics communiquant avec 0.0.0.0 depuis le mois dernier, qui a maintenant atteint environ 100 000.
En réponse à la divulgation d’Oligos de cette activité, les développeurs de navigateurs Web commencent enfin à agir:
Google Chrome, le navigateur Web le plus populaire au monde, a décidé d’agir et de bloquer l’accès à la version 0.0.0.0 via un déploiement progressif allant de la version 128 (à venir) à la version 133.
Mozilla Firefox n’implémente pas PNA, mais c’est une priorité de développement élevée. En attendant la mise en œuvre de l’ANP, un correctif temporaire a été mis en place, mais aucune date de déploiement n’a été fournie.
Apple a implémenté des vérifications IP supplémentaires sur Safari via des modifications sur WebKit et bloque l’accès à 0.0.0.0 sur la version 18 (à venir), qui sera introduite avec macOS Sequoia.
En attendant l’arrivée des correctifs du navigateur, Oligo recommande aux développeurs d’applications de mettre en œuvre les mesures de sécurité suivantes:
- Implémentez les en-têtes PNA.
- Vérifiez les en-têtes d’HÔTE pour vous protéger contre les attaques de reliure DNS.
- Ne faites pas confiance à localhost-ajoutez une autorisation, même localement.
- Utilisez HTTPS autant que possible.
- Implémentez des jetons CSRF, même pour les applications locales.
Plus important encore, les développeurs doivent se rappeler que jusqu’au déploiement des correctifs, il est toujours possible pour les sites Web malveillants d’acheminer les requêtes HTTP vers des adresses IP internes. Par conséquent, ils doivent garder cette considération de sécurité à l’esprit lors du développement de leurs applications.