SECURIDAY 2012 Pro Edition

Transcription

1 SECURINETS CLUB DE LA SECURITE INFORMATIQUE INSAT SECURIDAY 2012 Pro Edition Atelier audit de base de données Chef Atelier : Bilel BARHOUMI (GL 3) Ahmed BEN REHAYEM (RT 3) Maha ROMDHANI (RT 3) Oussema KHLIFI (RT 3) Said IBRAHIM (GL 3) 28/04/2012

2 Table des matières I. Présentation de l atelier : But : Quelques notions :... 4 i. Base de données :... 4 ii. SGBD :... 4 iii. Audit : Les différents niveaux de l'audit de base de données :... 5 i. Audit de structure :... 5 ii. Audit de qualité des données :... 5 iii. Audit de configuration et de performances :... 5 iv. Audit des requêtes clientes :... 6 v. Audit d'infrastructure réseau :... 6 II. Présentation des outils utilisés :... 6 SGBDs :... 6 Outils d investigation :... 6 III. Topologie du réseau :... 7 IV. Configuration des outils : Microsoft Sql Server :... 7 i. Création des instances d objets de SQL Server :... 8 ii. Création des objets de spécification d audit serveur iii. Création des objets de spécification d audit de bases de données : iv. Visualisation des enregistrements d audit : Oracle 11g : i. Logminer : Explorer les fichiers Redo Logs et Archive Logs : ii. Le Flash-Back : MySql 5.5 : i. Préparation du serveur ii. Activation du log à la volée iii. Désactivation des logs iv. Visualisation du fichier log :

3 V. Un scénario de test : VI. Conclusion: Changer le mot de passe par défaut Refuser les connexions distantes Supprimer les comptes inutiles Supprimer la base de données d exemple Activer les logs et les externaliser Exécuter le service avec un compte de service Restreindre les privilèges des utilisateurs Chiffrer les données stockées Appliquer les patchs de l éditeur

4 I. Présentation de l atelier : 1. But : Notre atelier consiste à analyser l'existant d'une base de données (ou d'un ensemble cohérent de bases de données) plus ou moins profondément afin d'en diagnostiquer l'état et de préconiser des améliorations, essentiellement sur le plan de la conformité et des performances. 2. Quelques notions : i. Base de données : Une base de est une entité dans laquelle il est possible de stocker des données de façon structurée et avec le moins de redondance possible. Ces données doivent pouvoir être utilisées par des programmes, par des utilisateurs différents. ii. SGBD : Un système de gestion de base de données (SGBD) est un ensemble de logiciels qui manipulent le contenu des bases de données. Il sert à effectuer les opérations ordinaires telles que rechercher, ajouter ou supprimer des enregistrements, manipuler les index, créer ou copier des bases de données. Les SGBD sont équipés de mécanismes qui effectuent des vérifications à l'insu de l'utilisateur, en vue d'assurer la réussite des transactions, éviter des problèmes dus à la concurrence et assurer la sécurité des données. 4

5 Les principaux systèmes de gestion de base de données sur le marché : IBM DB2, Oracle Database, MySQL, PostgreSQL et Microsoft SQL Server iii. Audit : L'audit, exercé par un auditeur, est un processus systématique, indépendant et documenté permettant de recueillir des informations objectives pour déterminer dans quelle mesure les éléments du système cible satisfont aux exigences des référentiels du domaine concerné. 3. Les différents niveaux de l'audit de base de données : i. Audit de structure : Il s'agit de montrer si la structure de la base est en adéquation avec les exigences fonctionnelles et particulièrement adaptée à l'usage qui en est fait (requêtes). On vérifiera en particulier que le modèle de données a été respectueux des règles de l'art : modélisation relationnelle (MCD, MLD), respect des formes normales, contraintes de domaine, schéma externe... et correspond à la nécessité de service. ii. Audit de qualité des données : Il s'agit de vérifier que la base n'est pas polluée par de nombreuses données inutiles ou erronées. En particulier on vérifiera l'existence de contraintes telles que : contraintes de domaine, intégrité référentielles, unicité, validation, format (notamment les formats normalisés de données)... iii. Audit de configuration et de performances : Il s'agit de vérifier si la configuration du serveur logique (SGBDR) et du serveur physique (hardware) est conforme aux exigences du service des données : en particulier RAM, disques, processeurs, paramétrages à tous niveau. 5

6 Cela nécessite de tracer l'activité du serveur sur divers plans techniques puis d'analyser les données recueillies à l'aide de différentes techniques et moyens qui peuvent faire l'objet de plusieurs passes successives pour affinement. iv. Audit des requêtes clientes : Il s'agit de vérifier : - le style de développement adopté (requêtes adhoc, emploi de procédures stockées, mapping relationnel objet...), - la qualité de l'écriture des requêtes et l'indexation des tables. On procède à l'aide de différentes techniques en fonction de la façon dont est écrit le programme applicatif, techniques qui peuvent être combinées (analyse d'échantillon, traçage de l'activité du moteur SQL, revue de code...). v. Audit d'infrastructure réseau : Il s'agit de vérifier ce qui se passe entre les serveurs SQL et les "clients". Ces clients pouvant être d'autres serveurs (Web, objet...) ou des clients applicatifs finaux. Il faut mesurer les temps de réponse effectifs (trames) et ressentis (utilisateur). II. Présentation des outils utilisés : SGBDs : Pour la réalisation de cet atelier, on a choisi quelques SGBQ qui sont très utilisés dans les entreprises : Oracle 11g : Oracle est un système de gestion de base de données relationnelle produite par Oracle Corporation, c est un des SGBD les plus rapide et performant disponible sur le marché. Microsoft SQL Server 2008 R2: SQL Server est un SGBD relationnel produit par Microsoft, c est un des concurrents direct d oracle. MySQL 5.5: MySQL est un SGBD relationnel open source très populaire, il est largement utilisé dans les sites web vu sa licence flexible et son faible cout. Outils d investigation : SQLMap : c est un outil permettant d effectuer des requêtes SQL de manières automatisées dans le but de trouver et d exploiter une mauvaise configuration sur un serveur Web. Tamper Data : est une extension (add-on) Firefox qui vous donne le pouvoir de visionner, enregistrer et même de modifier les requêtes HTTP sortantes. 6

7 III. Topologie du réseau : Pour la configuration des SGBDs on va travailler sur la même machine contenant le SGBD. Pour la partie injection Sql on utilise notre ordinateur qui doit être connecté au serveur web contenant le web : soit via internet soit réseau locale. IV. Configuration des outils : Cette partie concerne tous ce qui est configuration de chaque outil. Elle doit comporter toutes les commandes que vous avez utilisés (en expliquant bien sûr à quoi elles servent) et éventuellement des imprimes écran qui montrent les résultats obtenus. 1. Microsoft Sql Server : SQL Server 2008 propose une nouvelle fonctionnalité d'audit unifiée qui permet de mettre en place facilement ces audits ce qui permet à un administrateur de bases de données de se concentrer uniquement sur le véritable enjeu : trouver les audits qui seront en adéquation avec les besoins de l'entreprise. Nous utiliserons le langage TSQL pour créer nos objets d'audits. Il est cependant possible d'arriver au même résultat avec la console graphique de gestion des bases de données SQL Server Management Studio. 7

8 i. Création des instances d objets de SQL Server : Commençons par créer 3 instances d audit : Comme résultat, les 3 instances sont créées : 8

9 Après avoir créé et activé les objets d'audit SQL Server pour les 3 cibles concernées, il faut ensuite effectuer un paramétrage supplémentaire pour que SQL Server soit autorisé à écrire dans le journal de sécurité Windows. Pour cela nous utiliserons la console de gestion des stratégies locales du serveur. Autoriser le compte de service SQL Server à générer des audits de sécurité : Panneau de configuration > Système et sécurité > Outils d administration > Attribut de des droits utilisateurs > Générer des audits de sécurité. Ajouter le compte de service du serveur SQL : Dans notre cas nous ajouterons le compte LOCAL SYSTEM 9

10 Activer les audits d'accès sur les objets : Console de gestion des stratégies locales > Stratégie d'audit > Auditer l'accès aux objets. Activer les audits pour les 2 types d'accès : Réussite et Echec ii. Création des objets de spécification d audit serveur Il faut maintenant créer deux objets de spécification d'audit au niveau de l'instance SQL Server : Un objet de spécification d'audit sera à l'écoute des événements ou actions concernant les changements sur les comptes de connexion. Un deuxième objet de spécification d'audit sera, quant à lui, destiné aux changements d'état intervenant sur le serveur. 10

11 On peut vérifier la création des deux spécifications d audit créées comme indiqué dans la figure ci-dessous : Ajouter à l'objet de spécification d'audit serveur nommé audit_modif_users_login le groupe d'événement SERVER_PRINCIPAL_CHANGE_GROUP qui permet de surveiller, entre autres, les événements de création, de suppression et de modification de compte de connexion. Il faudra, au préalable, le désactiver pour pouvoir le modifier. 11

12 iii. Création des objets de spécification d audit de bases de données : iv. Visualisation des enregistrements d audit : Audit de sécurité des comptes de connexion : On va simuler quelque action sur les comptes de connexion pour pouvoir après les récupérer dans les fichiers journaux : Création des comptes de connexion : 12

13 Modification de mot de passe des comptes : Ajout de compte de connexion test1 au role fixe de serveur sysadmin Regarder dans le journal de sécurité de Windows : 13

14 Voici un exemple de ce que l'on trouve dans le journal après avoir exécuté les scripts TSQL ci-dessus : Audit de changement d état du serveur SQL : Initions maintenant un changement dans les options de configuration du serveur. Nous autorisons la procédure xp_cmdshell. 14

15 Redémarrer le serveur de bases de données en utilisant l invite de commande : Audit des accès à la table dbo.users : Tout d abord, on commence par faire des requetes SQL : Select, Update, Insert, Delete Pour consulter les journaux d audit de la base de données : 15

16 Le résultat est le suivant : On voie que SQL Server 2008 possède un outil d'audit extrêmement puissant. Cette nouvelle fonctionnalité permet de répondre parfaitement aux aspects sécurité, performance et gestion. 2. Oracle 11g : i. Logminer : Explorer les fichiers Redo Logs et Archive Logs : Logminer permet de scruter les fichiers REDOLOG (en ligne ou archivés) et dévoiler les transactions s'y trouvant. Les transactions sont trouvées sur la base des requêtes SQL. La vue V$LOGMNR_CONTENTS fournit les instructions SQL que ORACLE a exécuté ainsi que les ordres SQL nécessaires pour revenir en arrière (UNDO). Cette vue doit être peuplée avec le contenu des fichiers REDOLOG. Grâce à l outil logminer on peut : Repérer l heure exacte d exécution d une commande Identifier les commandes passées Générer un script permettant de passer l inverse des commandes sans passer par une restauration incomplète 16

17 Répertorier l ensemble des instructions passées dans une même transaction Calculer des statistiques d accès aux objets Trouver l origine de la génération d un gros volume de redo logs La lecture du fichier REDOLOG : Etape N 1 : Connexion en user SYS : en utilisant l invite de commande Sqlplus d Oracle (menu démarrer > tous les programmes > Oracle Data Base > Outil d administration) On exécute le DBMS_LOGMNR avec le path des fichiers redolog à analyser : SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(logfilename => C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG\O1_MF_1_7OT7NDO0_.LOG,o ptions => DBMS_LOGMNR.new); SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(logfilename => ' C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG\O1_MF_2_7OT7NHON_.LOG,op tions => DBMS_LOGMNR.new); 17

18 Vous pouvez voir les dates/heures des switch logfile et les SCN par cette requête : SQL> SELECT FILENAME, LOW_TIME, HIGH_TIME, LOW_SCN, NEXT_SCN FROM V$LOGMNR_LOGS; Etape N 2 : On démarre LOGMINER. A partir de cet instant une vue V_$LOGMNR_CONTENTS sera disponible et alimentée. SQl> EXECUTE DBMS_LOGMNR.START_LOGMNR(options=> DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.NO_ROWID_IN_STMT + DBMS_LOGMNR.NO_SQL_DELIMITER); Etape N 3 : On interroge la vue V_$LOGMNR_CONTENTS ou la table V$LOGMNR_CONTENTS. 18

19 SQL> SELECT USERNAME AS USR, SEG_OWNER AS OWNER, Table_name, Operation, SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS; Etape N 4 : On ferme LOGMINER. La vue V_$LOGMNR_CONTENTS est purgée. SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR(); On ré exécute l étape 1 à 4 pour analyser un autre redolog. ii. Le Flash-Back : Le flashback permet de récupérer un ensemble de données ou d objets dans le passé puis de les réinjecter dans la base de données. La technologie d Oracle 10g ou 11g, offre la capacité d interroger des versions anciennes de schéma d objets ou de données. Le «flashback» a été créé pour réparer facilement les données corrompues d une table par un batch, en réinjectant dans la base de données les données récupérées avant le passage du batch grâce au flashback. Le flashback permet un retour arrière dans la base de données afin de sélectionner des objets ou parties d objets pour les réinjecter dans la version actuelle de la base de données. 19

20 La technologie flashback permet d assurer vite et facilement une réparation à tous les niveaux : Flashback database : vous laisse rapidement ramener votre base à un point dans le temps en réparant toutes les modifications apportées depuis cet instant. Flashback table : vous permet de retrouver rapidement une table et son contenu à un moment dans le passé. Flashback Query : vous laisse voir les modifications apportées par une transaction à une ou plusieurs données, accompagnées de ses métadonnées. SIMULATION : Instructions étape par étape sur la configuration de base de données flash-back dans base de données Oracle 11gR2 est donnée ci-dessous: 1> La base de données doit être en mode ARCHIVELOG. Si ce n'est pas configurer le mode ARCHIVELOG SQL> select log_mode from v$database; 2> Définissez les paramètres d'initialisation SQL> alter system set db_recovery_file_dest_size=3g; SQL> show parameter db_recovery_file_dest SQL> alter system set db_flashback_retention_target=120; 20

21 3> Effectuez un arrêt de la base de données SQL> shutdown immediate; 4> Démarrage de l'instance de base de données oracle et l'amener à monter Etat SQL> startup mount; 5> Activer la journalisation flashback. À ce stade, la base de données flash-back est activé. SQL> alter database flashback on; SQL> select * from v$bgprocess where name='rvwr'; 6> Ouvrez la base de données SQL> alter database open ; 21

22 3. MySql 5.5 : MySQL a plusieurs fichiers de log qui peuvent vous aider à savoir ce qui se passe à l'intérieur de mysqld: Fichier Le log d'erreurs Le log ISAM Le log de requêtes Le log de mises à jour Le log binaire Le log des requêtes lentes Description Problèmes rencontrés lors du démarrage, de l'exécution ou de l'arrêt de mysqld. Garde une trace des changements liés au tables ISAM. Utilisé uniquement pour déboguer le code ISAM. Connexions établies et requêtes exécutées. Désapprouvé : Enregistre toutes les commandes qui changent les données. Enregistre toutes les commandes qui changent quelque chose. Utilisé pour la réplication. Enregistre toutes les requêtes qui ont pris plus de long_query_time à s'exécuter ou celles qui n'ont pas utilisé d'index. i. Préparation du serveur Il va quand même falloir redémarrer le service au moins une fois pour activer un paramètre par défaut : l'emplacement du fichier de log. Pour ce faire, il suffit d'éditer le fichier my.ini (ou my.cnf sous Linux) et d'ajouter/modifier la directive suivante : general_log_file = c:/mysql/logs/query.log Il faut donc logiquement redémarrer le service pour prendre en compte ce paramètre. ii. Activation du log à la volée Dans une invite de commande MySQL ou tout autre outil capable d'exécuter des requêtes mysql avec un utilisateur ayant des droits d'admin, il faut lancer la commande suivante : SET GLOBAL general_log = 'ON'; Les logs sont activés et ajoutés au fichier défini ci-dessus. iii. Désactivation des logs Il suffit de repasser le paramètre à OFF : SET GLOBAL general_log = 'OFF'; Le fichier de log est alors déverrouillé par MySQL et nous pouvons le manipuler comme nous le souhaitons (déplacement, suppression,...) 22

23 iv. Visualisation du fichier log : Accéder au fichier «c:/mysql/logs/query.log» On trouve tous les requêtes exécutées par le SGBD avec les dates. V. Un scénario de test : L administration de la bibliothèque de l INSAT a demandé à des étudiants de créer un site web qui facilite la gestion de la bibliothèque. Ce site permet aux étudiants de chercher de livres dans la bibliothèque. Il permet aussi aux bibliothécaires d ajouter des livres et de faire les emprunts des livres. Vu que ce site va être à la disposition des étudiants, on nous a appelés pour vérifier la sécurité des données contre la suppression et la modification. Pour faire ce diagnostic on va utiliser l injection sql à travers le site. Voilà le site que on va travailler dessous. : 23

24 On choisit l url encerclé pour faire notre injection. On a besoin aussi de récupérer le cookie : pour cela on utilise Tamper data (menu outil de Firefox). Et l injection est réalisé par l outil Sqlmap qui est un outil gratuit et inclue dans la distribution Backtrack. 24

25 i. Tester si l url est vulnérable ou pas. -u (url) : l url choisie --cookie : le cookie fourni par le serveur web pris de Tamper Data --dbs (data base system) : pour afficher le SGBD Le résultat de la requête : l url est vulnérable il retourne les informations concernant le sgbd, la technologie web et les différents bases de données. 25

26 Notre site permet la recherche des livres dans une bibliothèque. Donc, on va choisir la base de données Bibliothèque comme cible. ii. Affichage des tables : -D : la base de données --tables : afficher tous les tables On s intéresse à la table «user» car on voit qu elle peut contenir les mots de passe des administrateurs. iii. Affichage de structure de la table use : 26

27 iv. Affichage du contenue de la table user : On peut aussi voir le contenu de la base de données mysql qui contient tous les informations en relation avec le SGBD : Affichage des différentes tables : 27

28 Affichage et téléchargement du contenue de la table user : Résultat : Sqlmap sauvegarde le résultat dans un fichier comme le suivant : Sécurisation contre les injection Sql : 28

29 Dans le cas où on utilise un entier dans notre variable : $id = $_GET["id"]; if ((!$id) (!ereg("^[0-9]+$", $id))) exit("pas de page à cette addresse"); Vérifier si la variable entré est un nombre ou non VI. Conclusion: Comme conclusion voici quelques conseils de première nécessité pour sécuriser votre base de données. Ceux-ci doivent néanmoins être accompagnés de mesures de sécurisation de votre système d exploitation et de votre moteur d application. 1. Changer le mot de passe par défaut Avant de passer à table, Scott et Tiger se lavent les mains. Même chose lorsque nous avons terminé l installation de notre base de données : il faut systématiquement modifier les mots de passe par défaut. 2. Refuser les connexions distantes Pour ne pas tenter le diable, nous allons également nous assurer que le service de base de données n est pas exposé sur une adresse IP publique. Par défaut, nous devrons nous assurer qu il est en écoute sur l interface loopback ( ) ou une socket système. 3. Supprimer les comptes inutiles Nous allons ensuite supprimer les accès aux données qui nous paraissant inutiles : c est assez simple, nous supprimons tous les comptes d accès configurés après l installation, à l exception bien entendu du compte d administration principal (root, sa, ). 4. Supprimer la base de données d exemple Suivant la règle «tout ce qui ne nous sert pas doit être supprimé», nous allons faire de même avec les bases ou tables de données livrées à l installation pour servir d exemples. Attention, tous les moteurs ne sont pas livrés avec ce type de données. 5. Activer les logs et les externaliser L activation des fichiers de logs doit être un réflexe de la première heure. En cas d interruption du service, d incidents logiciels ou matériels, ou d intrusion sur le système, les journaux d activités permettront de mieux analyser la situation et de prendre les mesures nécessaires. 6. Exécuter le service avec un compte de service Les moteurs de bases de données sont généralement conçus pour n utiliser que des droits limités sur le système d exploitation. Les répertoires et les ports d écoute utilisés en standard sont en effet au sein d un contexte utilisateur et non celui du noyau. 29

30 7. Restreindre les privilèges des utilisateurs Dans une démarche toujours pragmatique, nous allons nous assurer que les privilèges fournis aux utilisateurs de la base de données sont en adéquation avec le besoin fonctionnel. Le compte utilisé pour se connecter à la base et y consulter des données au travers d un script PHP, n aura nullement besoin de droits d écriture ou de suppression. 8. Chiffrer les données stockées Les moteurs les plus récents proposent tous en standard ou via un module additionnel, des options de chiffrement des données. Ne nous gênons pas pour activer l option si nos bases de données sont constituées de données sensibles. 9. Appliquer les patchs de l éditeur Cela semble relever de l'évidence même, mais une fois les phases d'installation, de configuration et de recette terminées, beaucoup d entre nous oublient que nos logiciels s inscrivent dans un cycle de vie parfois mouvementé. 30