Revenons tout d’abord sur ces protocoles. La syntaxe et la sémantique des commandes permettant l’accès aux données sont généralement définies par une norme reconnue : l’ANSI SQL. Toutefois, d’autres aspects importants des interactions client/serveur ne sont pas définis, parmi lesquels la méthode de création d’une session client, la transmission des commandes d’un client à un serveur, la méthode de renvoi des données et des états au client, la structure des données renvoyées, la mise en œuvre de mécanismes tels que les curseurs, ou encore les déclarations préconfigurées et les transactions. Ces détails sont comblés par les technologies propres à chaque constructeur. Ces derniers intègrent généralement ces fonctions via une couche logicielle indépendante, dédiée au traitement des messages et pouvant être transportée par différents protocoles réseau, tels que SQL*NET (Oracle), TDS (Sybase), une version alternative de TDS (Microsoft), ou encore DRDA (IBM).
Quelles vulnérabilités pour quels risques ?
Récemment, certains chercheurs étudiant la sécurité des protocoles de communication de bases de données propriétaires ont mis en évidence certains types de vulnérabilités qui nécessitent des altérations (d’autres n’en ont pas besoin).
Le centre de recherche ADC d’Imperva a classé ces vulnérabilités en fonction du type de manipulation permettant de les exploiter :
- Altération de la structure des messages ;
- Altération de la taille des champs ;
- Manipulation du contenu des champs ;
- Altération de la séquence des messages.
Intéressons nous à chacune d’entre elles.
Vulnérabilités par altération de la structure des messages
La structure d’un message de protocole peut être décrite comme une liste de champs dans laquelle chaque champ se voit attribuer un rôle et un format spécifique. Les vulnérabilités par altération de la structure des messages attaquent le mécanisme d’analyse des messages et modifient généralement le contenu de la mémoire.
Les principales techniques d’altération classées dans cette catégorie agissent par suppression, ajout ou duplication des champs d’un message ou en combinant ces messages d’une manière inattendue. La vulnérabilité IBM DB2 rendue publique en septembre 2006 [1] constitue un exemple de ce type de vulnérabilité. Un des messages d’établissement de connexion contient un champ optionnel indiquant le nom de la base de données. Toutefois, lorsqu’un message est envoyé sans ce nom de base de données « optionnel », une exception « non gérée » est générée sur le serveur, ce qui rend la base de données inaccessible à tous les clients.
Manipulation de la taille des champs
Parfois, la taille des champs d’un message est déclarée de façon explicite à l’aide d’un autre champ dédié. La manipulation de la taille des champs peut être utilisée pour provoquer des attaques par débordement de tampon permettant l’exécution de code arbitraire. C’est ce qui se produit lorsque l’indicateur de longueur est capable d’indiquer des tailles plus importantes que celles réellement prises en charge par le logiciel serveur. Plusieurs exemples connus de ce type de vulnérabilité sont présentés sur les figures [2] et [3].
Un autre type de risque existe si le message comporte des indications de taille de champs redondantes et si la cohérence entre les tailles indiquées et les champs correspondants n’est pas contrôlée. Le message TDS « Hello » en donne un exemple (cf. figure 1). Dans ce cas, l’indicateur de taille d’un champ spécifique peut indiquer une taille supérieure à la taille totale du message. Cela vide le contenu des tampons mémoire vers la connexion réseau, exposant ainsi des informations confidentielles, voire des mots de passe (cf. figure 2).
Figure 1 : message TDS « Hello » (taille de champ plus importante que la taille totale du message)
Figure 2 : exemple de données de tampon vidées par le serveur et montrant les noms des utilisateurs connectés.
Manipulation du contenu des champs
La manipulation de contenu autorise différents types d’attaques, y compris les élévations de droits d’accès et les échappements d’audit. Une vulnérabilité Oracle SQL*NET révélée en janvier 2006 [4] fonctionnait par exploitation des messages d’authentification. Ce message inclut un certain nombre de champs, et notamment un champ AUTH_ALTER_SESSION. Ce champ est interprété comme une commande SQL par la base de données, une fois la connexion réussie dans le même contexte de sécurité que le processus d’authentification (plutôt que dans le contexte de sécurité de l’utilisateur). Cette faille permet l’exécution de pratiquement n’importe quelle commande sans aucun suivi d’audit. Un attaquant peut ainsi changer le contenu de cette commande à sa guise (par exemple, pour s’attribuer des droits d’accès administrateur).
Altération de la séquence des messages
Un « attaquant » peut émettre une séquence irrégulière de messages de protocole correctement constitués et rendre ainsi le serveur inaccessible. L’exploitation des vulnérabilités de ce type nécessite parfois des capacités élémentaires pour la création de scripts, mais elles peuvent parfois être exploitées sans aucune automatisation.
Nouveaux types d’attaques nécessitant de nouvelles solutions de protection
Il est impossible de garantir à 100 % l’efficacité des mesures de sécurité proactives, intégrées au niveau du serveur, car les failles de programmation existent et continueront d’exister. Les éditeurs de solutions de bases de données conseillent d’utiliser une protection réactive (application de correctifs). Toutefois, l’application de correctifs dans un environnement de bases de données est généralement lente. Les dispositifs classiques de détection et de prévention des intrusions (IDS/IPS) n’offrent qu’une protection partielle : ils ne permettent pas d’avoir une vision d’ensemble des protocoles utilisés par les serveurs de bases de données.
Une bonne solution de sécurité devrait être couplée avec d’autres méthodes de protection des bases de données. Une solution IDS/IPS dédiée aux bases de données doit connaître très précisément les protocoles de communication utilisés par le serveur de bases de données. Avantage associé : proposer une validation proactive des messages de protocole et tout message ou séquence de messages ne correspondant pas au comportement attendu peut être signalé ou supprimé. Une telle solution offre une protection réactive, basée sur les signatures, à même de détecter avec précision et de bloquer efficacement les attaques connues. Cette combinaison de solutions proactives et réactives offre le meilleur dispositif de sécurité contre ces nouveaux types d’attaques ciblant les bases de données.
Par Noa Bar Yosef, Security Researcher à l’ADC (Application Defense Center) d’Imperva et Amichai Shulman, co-founder & CTO Head of the Imperva ADC
Notes
[1] Détails de l’attaque DDOS BID 19586
[2] Vulnérabilité de débordement de tampon par écoute TNS sur Oracle 8i
[3] Vulnérabilité de débordement de tampon lors de l’authentification distante sur Microsoft SQL Server
[4] Note US CERT sur les vulnérabilités (VU#871756)