Une vulnérabilité ayant la même cause première que la célèbre faille Log4j a été corrigée dans la console de la très populaire base de données Java SQL, H2 Database Engine.

Comme pour les récents exploits « Log4Shell », des attaquants non authentifiés peuvent réaliser l’exécution de code à distance (RCE) car la console accepte la dénomination Java arbitraire et l’interface d’annuaire (JNDI) URL de recherche.

La faille (CVE-2021-42392) « permet le chargement de classes personnalisées à partir de serveurs distants via JNDI », selon un GitHub conseil en sécurité publié par les mainteneurs de H2 le 5 janvier.

CONSEILLÉ Un chercheur découvre 70 vulnérabilités d’empoisonnement du cache Web et rapporte 40 000 $ en primes de bogues

La vulnérabilité a justifié les soupçons des chercheurs en sécurité qui l’ont trouvée – que l’utilisation généralisée de JNDI suggérait « il y a forcément plus de packages qui sont affectés par la même cause racine que Log4Shell », selon un article de blog publié hier (6 janvier) par Andrey Polkovnychenko et Shachar Menashe de la société de cybersécurité JFrog.

Avec près de 7 000 dépendances d’artefacts, H2 est l’un des packages Maven open source les plus populaires.

De manière inquiétante, étant donné « la tendance récente des attaques de la chaîne d’approvisionnement ciblant les développeurs », Polkovnychenko et Menashe ont déclaré avoir observé de nombreux outils de développement dépendants de H2 exposant la console H2.

Sécurisé par défaut

La paire a décrit la faille comme « extrêmement critique » si les consoles H2 sont exposées à un LAN, ou pire, à un WAN.

Cependant, la menace est considérablement réduite par le fait que la console H2 est sûre dans son réglage par défaut, n’écoutant que les connexions localhost (bien qu’il soit simple d’activer les connexions à distance, notent les chercheurs).

De plus, le RCE n’affectera généralement que le serveur qui traite la demande initiale, et de nombreux fournisseurs exécutant la base de données H2 peuvent ne pas exposer la console H2.

Néanmoins, JFrog recommande à tous les utilisateurs de H2 de passer à la dernière version, qu’ils utilisent directement la console H2 ou non.

En effet, d’autres vecteurs d’attaque existent – les chercheurs ont également trouvé l’outil H2 Shell et des vecteurs SQL dépendants de l’authentification – bien qu’ils soient « dépendants du contexte et moins susceptibles d’être exposés à des attaquants distants ».

Limitation des URL JNDI

Les versions H2 vulnérables s’étendent de 1.1.100 à 2.0.204 inclus.

Les chercheurs ont félicité les responsables de H2 pour avoir corrigé rapidement la faille dans la version 2.0.206, publiée le 5 janvier.

Semblable au correctif Log4j, le correctif limite les URL JNDI à l’utilisation du protocole Java local uniquement, bloquant ainsi les requêtes LDAP/RMI distantes.

Indépendamment du patch « -webAllowOthers est un milieu dangereux qu’il faut éviter », prévient l’avis H2.

Mais si le servlet de la console H2 est déployé sur un serveur Web, les utilisateurs peuvent ajouter une contrainte de sécurité qui n’autorisera que des utilisateurs spécifiques à accéder à la page de la console.

« À notre connaissance, CVE-2021-42392 est la première vulnérabilité RCE non authentifiée liée à JNDI à être publiée depuis Log4Shell, mais nous pensons que ce ne sera pas la dernière », ont déclaré Polkovnychenko et Menashe.

En tant que tel, JFrog continue de rechercher des défauts similaires.

L’injection JNDI a d’ailleurs été exploitée avant Log4Shell par le chercheur taïwanais Orange Tsai qui a compromis les systèmes internes de Facebook en 2020 via une vulnérabilité dans la plate-forme de gestion des appareils mobiles MobileIron.