Protection d’objets MSSQL 2000, 2005, 2008 et 2012

Dans le cadre de réalisation de plusieurs projets clients, SYNETIS s’est intéressé aux mécanismes de protection intrinsèques à la solution de base de données bien connue de Microsoft.

Les serveurs SQL de Microsoft connus sous le nom MSSQL ont la faculté depuis la version 6.5 (puis 7,  2000, 2005, 2008 et enfin 2012) de protéger les objets via un algorithme de chiffrement.

Les serveurs MSSQL autorisent le chiffrement sur :

  • les vues (view – v) ;
  • les fonctions (function – fct) ;
  • les procédures stockées (stored procedure – st) ;
  • les déclencheurs (trigger).

Cette protection se caractérise par un petit cadenas apposé sur ces dits objets au travers du client “Microsoft SQL Server Management Studio” (SSMS). Leur édition devient impossible, tout comme la visualisation du code source de ces objets.

Ces objets chiffrés ne peuvent être édités, modifiés, ou visualisés :

Ces mécanismes sont largement employés par de nombreux éditeurs et développeurs de produits logiciels basés sur MSSQL, afin de protéger la propriété intellectuelle et le droit d’auteur de leurs scripts. Toutefois, l’algorithme en place dans chacune des versions de MSSQL Server s’avère faible et peut être facilement inversé.

  • Comment définir un objet chiffré au sein d’une base MSSQL ?

La méthode pour protéger ces objets est d’une grande simplicité. Il suffit de déclarer chacun d’eux en utilisant les mots clés “WITH ENCRYPTION“.

Dès que ces mots clés sont renseignés, la procédure, fonction, trigger ou vue est protégée de l’édition et de la consultation. Il convient donc de toujours conserver une version en clair de l’objet, pour pouvoir le mettre à jour aisément.

Il s’avère néanmoins que l’algorithme de protection employé par MSSQL n’est pas si robuste, et que celui-ci est exploité au travers de nombreux outils shareware et freeware, pour la plupart des versions du serveur de base de données. Avec la sortie en avril dernier de la version 2012 de MSSQL, SYNETIS s’est penché sur les potentielles évolutions des mécanismes de protection mis en place pour les objets de la base. En guise de synthèse, peu d’améliorations en termes de protection ont eu lieu entre la version 2008 (R2) et la version 2012 de SQL Server.

SYNETIS vous propose au travers de cet article de retracer les grandes lignes concernant le déchiffrement d’objets MSSQL avant d’aiguiller vers de potentielles solutions d’amélioration de ce chiffrement.

  • État de l’Art du déchiffrement MSSQL toutes versions

Depuis de nombreuses années, de multiples outils permettent de déchiffrer les objets des bases MSSQL. La plupart sont payants, et disposent d’une version d’essai qui limite le déchiffrement à N caractères. De plus, certains ne prennent pas en compte toutes les versions de MSSQL, encore moins la dernière MSSQL 2012.

Une recherche sous Google permet rapidement de trouver un minimum de 6 produits que nous ne citerons pas ici.

  • Déchiffrement d’objets MSSQL 2000, 2005 et 2008 via un freeware

Au sein de cette jungle d’outil, il y en a un qui sort du lot pour sa simplicité d’exploitation, d’utilisation et ses fonctionnalités. Un autre avantage est qu’il est totalement gratuit. Cet outil assure le déchiffrement d’objets de toutes les versions des bases MSSQL sauf de la dernière en date : la 2012 (sortie en avril de la même année). L’éditeur de ce programme ne semble plus actif et aucune mise à jour n’a l’air prévu. La grande facilité d’utilisation de cet outil et les résultats obtenus sont un argument de poids pour la mise en place de mécanismes complémentaires pour le chiffrement des éléments MSSQL.

Après son installation, il suffit de lancer l’outil, renseigner le serveur MSSQL auquel se connecter ainsi que les crédentiels associés et la liste des objets devient visible (un MSSQL 2008 est exploité dans cet exemple) :

Connexion via Optillect SQL Decryptor

Il suffit par la suite de choisir l’entité à déchiffrer. Un double-clic permet de visualiser directement le code en clair (avec les commentaires) de l’objet. Un clic droit permet d’accéder aux diverses fonctionnalités sur l’entité, comme son remplacement direct dans la base de données.

  • Déchiffrement d’objets MSSQL 2000, 2005, 2008 et 2012 via une procédure stockée

Lorsque les outils disponibles ne permettent pas de déchiffrer des objets d’une version récente (MSSQL Server 2012 notamment), il est possible de définir une procédure manuellement dans la base à ces fins. Cette procédure implémente l’algorithme de déchiffrement complet.

Microsoft a fait évoluer la structure et le schéma de ses tables systèmes entre les versions 2000 (et antérieures) et les versions supérieures à 2000. Toutefois, entre les versions 2005, 2008 et 2012, l’algorithme et la structure des tables n’a pas évolué. Autrement dit, il est possible de déchiffrer n’importe quel objet via une procédure stockée SQL spécifique, quelque soit la version de MSSQL.

Cette procédure disponible sur l’Internet et publiée en 2007 est toujours fonctionnelle pour les dernières versions de Microsoft SQL Server (2005, 2008 et 2012).

Il est nécessaire de se connecter sous un compte d’administration au client SSMS pour exécuter cette procédure, via une connexion DAC (Dedicated Administrator Connection). Une telle connexion est possible bien que d’autres connexions soient déjà établies. Seule une connexion DAC est possible à la fois. Par défaut, les connexions DAC sont autorisées qu’en local ; pour les activer à distance, exécuter les commandes suivantes dans un terminal “en tant qu’administrateur” sur la machine accueillant le serveur SQL :

Activation de l'accès DAC distant

Pour ouvrir une connexion via le client SSMS en tant qu’administrateur DAC, faire “File > New > Database Engine Query”. Renseigner les crédentiels nécessaires à la connexion tout en préfixant le “Server name” de “admin:” (la casse n’a pas d’importance) :

Un nouvel onglet d’exécution de requête apparaît. Celui-ci dispose des privilèges d’administration DAC. Copier/coller la procédure de déchiffrement d’objet MSSQL précédente, et modifier en amont de cette procédure le nom de l’objet à déchiffrer (fonction, procédure, trigger ou vue). Enfin, cliquer sur “Execute” et le code en clair de l’objet apparaît en tant que résultat :

L’objet déchiffré contient toujours les mots clés “WITH ENCRYPTION”. Il suffit de supprimer ces mots clé et de ré-exécuter le code d’altération (ALTER) de l’objet pour le ré-enregistrer en clair dans la base.

  • Analyse de l’algorithme de déchiffrement

Le stockage des différents objets MSSQL (dans les versions supérieures ou égales à 2005) se fait dans la colonne “imageval” de la table “sys.sysobjvalues”. Cette table est protégée lors d’une connexion simple via SSMS à la base, même sous un compte d’administration. C’est pourquoi il est nécessaire de faire une connexion DAC.

L’algorithme de chiffrement effectue un simple XOR sur le code SQL de l’objet à protéger avant de le stocker dans cette table.

La technique de déchiffrement qui est utilisée dans la procédure précédente est la suivante :

  • Récupération des données chiffrées de définition de l’objet (à partir de son identifiant unique), dans la colonne “imageval” de la table “sys.sysobjvalues” et stockage de cette valeur dans une variable “@ContentOfEncryptedObject”.
  • Calcul de la taille de l’objet dans “@ContentDataLength” via la fonction “DATALENGTH(@ContentOfEncryptedObject)/2” (stockage en hexadécimal, d’où le /2).
  • Création d’une instruction “ALTER PROCEDURE” complétée par le caractère de commentaire MSSQL “-” jusqu’à la taille de l’objet définie précédemment. Exemple : “ALTER PROCEDURE [dbo].[helloWorld] WITH ENCRYPTION AS———–[…]”
  • Exécution de l’instruction d’altération de la procédure. Ceci à pour effet de supprimer la procédure effective précédente, que l’on cherche à déchiffrer. Cette procédure a été sauvegardée dans “@ContentOfEncryptedObject”.
  • Récupération de la nouvelle procédure redéfinie (complétée avec des “-“) dans la variable “@ContentOfFakeEncryptedObject”.
  • Annulation de la modification de la procédure (RollBack), pour restaurer la version chiffrée ciblée (toutefois la fausse procédure a été stockée dans “@ContentOfFakeEncryptedObject”).
  • Création d’une instruction “CREATE PROCEDURE” complétée par le caractère de commentaire MSSQL “-” jusqu’à la taille de l’objet “@ContentDataLength”. Exemple : “CREATE PROCEDURE [dbo].[helloWorld] WITH ENCRYPTION AS—————[…]” et stockage de cette instruction dans la variable “@ContentFakeObject”

Une fois les différentes variables initialisées, l’algorithme de décodage via un “OU exclusif” (XOR) peut être appliqué. Celui-ci est réalisé caractère par caractère en fonction de la taille de objet définie (@i = 1 to @ObjectDataLength), entre les données de la procédure chiffrée cible, les données de la fausse procédure chiffrée et les données de l’instruction de création de la procédure (en clair). Soit :

L’idée est de définir la clé du XOR à partir des deux “fausses” procédures ; puis d’utiliser cette clé sur la véritable procédure cible. Le résultat est le code (commenté) de l’objet en clair.

  • Renforcement de sécurité

Pour renforcer les mécanismes de protection intégrés à MSSQL, différentes solutions existent.  On peut citer l’une d’entre elle, nommée “{3S} SQL Smart Security”.

3S

Cette solution est un add-in de “Microsoft SQL Server Management Studio” (SSMS) pour les versions 2005, 2008, 2008 R2, 20012 et leurs versions EXPRESS respectives. La version actuelle de ce produit (1.1) ne traite que les procédures stockées. L’éditeur prévoit à l’avenir de l’étendre aux fonctions, déclencheurs et aux vues.

L’idée de cette solution est d’enrichir et de renforcer le mécanisme intrinsèque à MSSQL “WITH ENCRYPTION” via de nouveaux mécanismes cryptographiques.

Suite à l’installation du package MSI de “{3S} SQL Smart Security”, de nouveaux menus et onglets sont disponibles dans SSMS. L’outil permet d’enregistrer une base de données préexistante au sein de l’add-in. Suite à cet enregistrement, la solution permet d’effectuer une sauvegarde avant tout chiffrement, puis d’appliquer la protection sur telle ou telle procédure stockées.

Lors d’une tentative de déchiffrement via un des outils présentés plus haut, seules les métadonnées “{3S} SQL Smart Security” sont accessibles. Ces métadonnées permettent d’appeler le véritable moteur d’exécution des procédures chiffrées de “{3S} SQL Smart Security”. L’éditeur de cette solution informe que le chiffrement est à sens unique.

Il est possible de visualiser le fonctionnement de cette solution au travers de la vidéo de démonstration suivante. Un manuel détaillé du produit et de ses atouts est également disponible.

Sources & ressources :

Étiquettes : , , , , , , , , , , , , , , , , ,