Metabase : anatomie d'une vulnérabilité critique et d'une chaîne d'exploitation complexe

Faits, analyse et incertitudes

L'essentiel de la vulnérabilité

Quatre décisions raisonnables qui produisent une faille critique

Une injection SQL permet à un attaquant de modifier la requête envoyée à la base de données, lorsque l'application incorpore des données non maîtrisées dans sa logique SQL au lieu de les transmettre comme de simples valeurs. La formulation habituelle s'arrête là. Le cas Metabase mérite d'aller plus loin, parce qu'il montre comment une telle incorporation devient possible dans une application qui, sur le papier, ne construit pas de SQL à la main.

1. Une validation qui laisse passer l'inattendu

   Les schémas de validation décrivaient les champs attendus, sans interdire les champs supplémentaires. Une requête contenant des clés non prévues était donc considérée comme valide. C'est un choix courant, souvent défendu au nom de la compatibilité ascendante.

2. Un passage de paramètres élargi

   Lors de la refonte, le code est passé de la transmission des seules clés attendues à la transmission du corps complet de la requête. Pris isolément, c'est une simplification. Combiné au point précédent, cela signifie que tout ce qu'un client envoie parvient à la couche suivante.

3. Une recherche par identifiant

   Le flux d'authentification acceptait une recherche d'utilisateur par identifiant, résolue par la couche d'accès aux données. Rien d'anormal : c'est le fonctionnement attendu d'une couche de correspondance entre objets et base de données.

4. Une échappatoire vers le SQL brut

   La bibliothèque de construction de requêtes accepte une clé spéciale signifiant « ce qui suit est du SQL à insérer tel quel ». Cette échappatoire existe dans la plupart des bibliothèques équivalentes, parce qu'aucune abstraction ne couvre tous les besoins.

Mis bout à bout, ces quatre éléments produisent le résultat suivant : une requête non authentifiée peut transporter une structure contenant une clé de SQL brut, qui traverse la validation, puis le passage de paramètres, puis la recherche d'utilisateur, pour être finalement insérée telle quelle dans une requête. Chacun des quatre composants fait exactement ce qu'on lui a demandé.

Ce que l'attaquant a réellement fait

La partie la plus révélatrice de l'analyse publiée par Metabase n'est pas la vulnérabilité mais son usage. L'attaquant n'a pas cherché à obtenir un mot de passe, ni à contourner l'écran de connexion. Il a écrit directement dans la table des sessions un enregistrement associé à l'identifiant de l'administrateur.

Du point de vue de l'application, il n'y a alors plus d'attaque en cours : il y a une session valide, associée à un compte légitime. Toutes les actions suivantes sont autorisées, journalisées comme normales et indiscernables d'une activité d'administration réelle. C'est ce qui explique que le symptôme ayant déclenché le signalement ait été la création de clés d'API, et non une alerte de sécurité.

L'éditeur indique que la signature observable se résume à deux requêtes successives : un appel au point d'entrée de réinitialisation de mot de passe renvoyant un code d'erreur, immédiatement suivi d'un appel à l'interface renvoyant l'utilisateur courant, cette fois avec un code de succès. Le premier semble avoir échoué, le second prouve qu'il a réussi.

Ce que ce cas dit du développement sécurisé

Un incident de ce type invite moins à désigner un responsable qu'à examiner les pratiques qui auraient pu l'interrompre. Quatre d'entre elles se dégagent directement de l'analyse de l'éditeur.

Fermer les schémas par défaut

Un schéma de validation fermé rejette toute clé non déclarée. C'est plus contraignant, cela casse parfois des clients existants, et c'est ce que Metabase a mis en place après coup sur l'ensemble de ses points d'entrée. Le principe est simple : une application ne doit pas transporter ce qu'elle ne sait pas nommer.

Traiter les échappatoires comme des zones sensibles

Les bibliothèques de construction de requêtes offrent presque toutes un moyen d'insérer du SQL brut. Cette possibilité est légitime, et c'est précisément pour cela qu'elle doit être repérable : interdite dans les couches exposées, recherchée automatiquement dans le code, et justifiée là où elle subsiste. Metabase a choisi d'en interdire l'émission dans ses processeurs de requêtes.

Revoir les refontes comme des changements de sécurité

Une refonte ne modifie pas la fonctionnalité, ce qui la rend difficile à tester : les tests existants continuent de passer, puisque le comportement attendu n'a pas changé. Or c'est exactement dans cet angle mort que la régression a été introduite. Une refonte touchant l'authentification, l'autorisation ou l'accès aux données mérite une relecture spécifique, centrée sur les données qui traversent plutôt que sur le résultat produit.

Modéliser les menaces au niveau du flux, pas du fichier

Aucune relecture de l'un des quatre composants pris isolément n'aurait révélé la vulnérabilité. La modélisation de menaces répond à cette limite en suivant le trajet d'une donnée depuis son entrée jusqu'à son usage, en se demandant à chaque étape ce que le composant suppose de ce qu'il reçoit. C'est un exercice de conception, pas un outil.

• Validation côté serveur

  Les contrôles effectués côté client informent l'utilisateur ; ils ne protègent rien. Seule la validation exécutée par le serveur est une mesure de sécurité.

• Tests de sécurité automatisés

  Analyse statique du code, recherche de motifs sensibles, tests d'API envoyant des champs inattendus. Ces tests trouvent rarement une chaîne complète, mais ils repèrent les briques qui la rendent possible.

• Revue de code ciblée

  Une relecture systématique de tout ne tient pas dans la durée. Une relecture renforcée des chemins d'authentification, d'autorisation et d'accès aux données tient, et couvre l'essentiel du risque.

• Défense en profondeur

  Si l'instance n'avait pas été joignable depuis Internet, la même vulnérabilité aurait eu une portée très différente. La réduction d'exposition ne corrige rien mais change tout.

Ce qu'il faut faire sur une instance Metabase

Le point le plus coûteux est l'avant-dernier. Metabase détient les identifiants des bases auxquelles il se connecte : un accès administrateur sur l'instance donne donc un accès aux données métier, potentiellement sans laisser de trace du côté de Metabase, puisque les requêtes partent ensuite directement vers l'entrepôt. Les journaux à examiner ne sont pas seulement ceux de l'outil, mais ceux des bases.