Pendant plus d’une décennie, Internet est resté vulnérable à une classe d’attaques qui utilise les navigateurs comme tête de pont pour accéder aux routeurs et autres appareils sensibles sur un réseau ciblé. Maintenant, Google fait enfin quelque chose à ce sujet.
À partir de la version 98 de Chrome, le navigateur commencera à relayer les demandes lorsque des sites Web publics souhaitent accéder à des points de terminaison à l’intérieur du réseau privé de la personne visitant le site. Pour le moment, les requêtes qui échouent n’empêcheront pas les connexions de se produire. Au lieu de cela, ils seront uniquement enregistrés. Quelque part autour de Chrome 101 – en supposant que les résultats de cet essai n’indiquent pas que des parties majeures d’Internet seront interrompues – il sera obligatoire pour les sites publics d’avoir une autorisation explicite avant de pouvoir accéder aux points de terminaison derrière le navigateur.
L’abandon prévu de cet accès intervient alors que Google active une nouvelle spécification connue sous le nom d’accès au réseau privé, qui permet aux sites Web publics d’accéder aux ressources du réseau interne uniquement après que les sites l’ont explicitement demandé et que le navigateur accorde la demande. Les communications PNA sont envoyées à l’aide du protocole CORS, ou Cross-Origin Resource Sharing. Dans le cadre de ce schéma, le site public envoie une demande de contrôle en amont sous la forme du nouvel en-tête Access-Control-Request-Private-Network : true. Pour que la demande soit acceptée, le navigateur doit répondre avec l’en-tête correspondant Access-Control-Allow-Private-Network: true.
Intrusion réseau via le navigateur
Jusqu’à présent, les sites Web avaient par défaut la possibilité d’utiliser Chrome et d’autres navigateurs comme proxy pour accéder aux ressources à l’intérieur du réseau local de la personne visitant le site. Alors que les routeurs, les imprimantes ou d’autres actifs réseau sont souvent verrouillés, les navigateurs, en raison de la nécessité pour eux d’interagir avec tant de services, sont autorisés par défaut à se connecter à pratiquement n’importe quelle ressource à l’intérieur du périmètre du réseau local. Cela a donné naissance à une classe d’attaque connue sous le nom de CSRF, abréviation de cross-site request forgery.
De telles attaques sont théorisées depuis plus d’une décennie et ont également été menées dans la nature, souvent avec des conséquences importantes. Lors d’un incident en 2014, des pirates ont utilisé des CSRF pour modifier les paramètres du serveur DNS pour plus de 300 000 routeurs sans fil.
Le changement a amené les routeurs compromis à utiliser des serveurs DNS malveillants pour résoudre les adresses IP que les utilisateurs finaux essayaient de visiter. Au lieu de visiter le site Google.com authentique, par exemple, le serveur malveillant peut renvoyer l’adresse IP d’un site imposteur piégé que l’utilisateur final n’a aucune raison de croire nuisible. L’image ci-dessous, des chercheurs de l’équipe Cymru, montre les trois étapes impliquées dans ces attaques.
Publicité
Agrandir / Trois phases d’une attaque qui modifie les paramètres DNS d’un routeur en exploitant une vulnérabilité de requête intersite dans l’interface Web de l’appareil.
Équipe du Pays de Galles
En 2016, les personnes à l’origine de la même attaque sont revenues pour pousser un logiciel malveillant connu sous le nom de DNSChanger. Comme je l’ai expliqué à l’époque, la campagne a fonctionné contre les routeurs domestiques et professionnels fabriqués par Netgear, DLink, Comtrend et Pirelli de cette façon :
DNSChanger utilise un ensemble de protocoles de communication en temps réel connus sous le nom de webRTC pour envoyer des demandes de serveur dites STUN utilisées dans les communications VoIP. L’exploit est finalement capable de canaliser le code via le navigateur Chrome pour Windows et Android pour atteindre le routeur du réseau. L’attaque compare ensuite le routeur accédé à 166 empreintes digitales d’images de microprogrammes de routeurs vulnérables connus.
En supposant que la spécification PNA entre pleinement en vigueur, Chrome n’autorisera plus de telles connexions à moins que les appareils du réseau privé ne l’autorisent explicitement. Voici deux schémas montrant comment cela fonctionne.
La route devant
À partir de la version 98, si Chrome détecte une demande de réseau privé, une “demande de contrôle en amont” sera envoyée à l’avance. Si la demande préliminaire échoue, la demande finale sera toujours envoyée, mais un avertissement apparaîtra dans le panneau des problèmes de DevTools.
“Toute demande de contrôle en amont échouée entraînera un échec de récupération”, ont écrit l’ingénieur Google Titouan Rigoudy et le développeur Google Eiji Kitamura dans un récent article de blog. “Cela peut vous permettre de tester si votre site Web fonctionnera après la deuxième phase de notre plan de déploiement. Les erreurs peuvent être diagnostiquées de la même manière que les avertissements à l’aide des panneaux DevTools mentionnés ci-dessus.”
Si et quand Google est convaincu qu’il n’y aura pas de perturbations massives, les demandes de contrôle en amont devront être accordées pour être traitées.
