HERVÉ SCHAUER CONSULTANTS Cabinet de Consultants en Sécurité Informatique depuis 1989 Spécialisé sur Unix, Windows, TCP/IP et Internet Sécurité des bases de données Nicolas Jombart Alain Thivillon
Place des bases de données dans la sécurité du SI Budgets Securité vont d'abord à l'achat de système de sécurité (firewalls, IDS,...) à la formation à la sécurisation des applications le SGBD est le parent pauvre de la sécurité Complexité Les BD sont une affaire de spécialistes: au niveau de leur gestion : DBA au niveau de la programmation On ne peut pas sérieusement faire de l'oracle deux fois par an Quand c'est le cas, la sécurité est encore pire! 2 /24
Contraintes sur la sécurité 3 /24 Rôle du DBA maintenir le SGBD gérer les comptes, les applications,... pas de formation sécurité : ne peut pas «imaginer» les attaques possibles Mises à jour des systèmes d'expérience, 80% des serveurs de BD meurent avec le système et le SGBD initial: (Informix 7.2, Oracle 7.2,...) «If it works, don't fix it» Conséquence : de nombreuses failles système et applicatives ne sont JAMAIS corrigées, surtout sur les réseaux internes Criticité des applications : Arrêts impossibles La sécurité passe en dernier
Contraintes (2) Le SGBD est souvent un composant installé par ou avec un logiciel tiers ERP (SAP, Lawson) DataMining Gestion de parc (SMS,...) Pour SQL Server : 223 Applications recensées en 2003 Géré via ce logiciel tiers Dans une version limitée (exemple MSDE pour Epolicy Manager) dans un mode d'installation par défaut Sa configuration de sécurité est bien souvent encore plus obscure! et personne ne veut/peut prendre la responsabilité de modifier le paramétrage 4 /24
Types d'attaques Attaques sur le SGBD lui même failles connues classiques (buffer overflows, bugs d'autentification, injections SQL dans les procédures stockées,...) failles dans les applications associées: serveurs Web d'administration, applications Web, serveurs LDAP, démons snmp, programmes setuid root installés par le SGBD,... Mauvaises configurations modes d'authentification dégradés (.rhosts, OPS$......) mots de passe par défaut Interception de mots de passe par écoute du réseau par lecture de fichiers de configuration sur disque 5 /24
Types d'attaques (2) Attaques sur les applicatifs Injection SQL sur les applications Web détournement des requêtes effectuées par un ERP autorisations trop larges Attaques sur l'os via le SGBD écriture/lecture de fichiers, exécution de commandes la base de données tourne avec des privilèges différents contournement de la politique de sécurité 'safe_mode' de PHP chroot critique chez les hébergeurs Web mutualisés load data infile '/web/data/a/anotheruser/db.param' INTO hack... 6 /24
7 /24 Securité Listener Gestion des accès réseaux Oracle Problèmes de sécurité Peut être arrêté à distance sans mot de passe Peut être utilisé (via la fonction de trace) pour écraser n'importe quel fichier Oracle. Attention aux entrées ExtProc qui peuvent permettre à des anonymes d'exécuter du code arbitraitre via les appels de procédures externes Multiples dénis de service Possibilité: De placer un mot de passe De limiter l'accès réseau Oracle : tcp.validnode_checking = yes, tcp.invited_nodes = (x.x.x.x,...) Cf http://www.integrigy.com/info/integrigy_oracledb_listener_security.pdf
Mots de passe par défaut Combien d'installations Oracle 8 ont encore SYSTEM/MANAGER et SYS/CHANGE_ON_INSTALL? Au moins 80% de nos audits (et c'est bien pratique,...) Permet d'accéder à tous l'environnement à distance Permer d'écrire des procédures stockées appelant le système Mots de passe des comptes applicatifs appli/appli... Comptes par défaut installés par Oracle... Possession des tables, privilèges DBA attribués abusivement,.. 8 /24
Vulnérabilités Oracle Multiples vulnérabilités découvertes en permanence 25 vulnérabilités en un seul jour Principalement liées aux extensions (mod_plsql,...) Beaucoup de problèmes liées aux procédures stockées nécessaires au fonctionnement de IAS et autres... Exemple: gain des privilèges via le compte CTXSYS Produit difficile à patcher La suppression des comptes par défaut, une installation minimalisée permet de réduire beaucoup de problèmes 9 /24
Vulnérabilités Oracle Problème le plus évident: utilisation d'une fonctionnalité dangereuse: «remote_os_authent» Oracle fait confiance au client pour authentifier l'utilisateur s'il envoie POUET, il est transformé en OPS$POUET (pas de mot de passe) ROMINET Hello, je suis POUET sqlplus /@ROMINET OK POUET! 10 /24
En environnement Internet Typiquement utilisé pour «dynamiser» les sites Web Contenu mobile (publications) Commerce électronique / Notion de compte Risques principaux sur la base de données : Injection SQL Compromission de la base depuis une autre machine compromise Les bases de données sont souvent moins durcies Comptes oracle/oracle Systèmes d'exploitation non configurés pour la sécurité Déni de service 11 /24
Défense en profondeur Architecture en strates HTTP/HTTPS Sqlnet/1521 Servlet/8080 12 /24
Conseils de sécurité Durcir le système d'exploitation Notamment l'accès, et les comptes Supprimer les exemples, les autres applications satellites Pour l'écriture de l'application Principe de séparation des privilèges Savoir quels comptes sont nécessaires (Création, Lecture, Mise à jour, Sauvegarde) Appliquer ces rôles dans la base de données Comptes SELECT seulement Comptes ayant accès à toutes les tables/à certaines tables... Se prémunir contre l'injection SQL et le déni de service En contrôlant ce qui est envoyé à la base de données 13 /24
Risques applicatifs Protection contre le déni de service Conception de la base Empêcher de générer trop de calculs ou trop de réponses Injection SQL Le principe de l'attaque : Insérer du code SQL dans une requête construite dynamiquement, pour modifier son comportement Outrepasser par exemple un contrôle effectué par l'application Fonctionnement d'une application : 1. Récupération de données client (formulaires, fichiers XML,...) 2. Construction d'une requête SQL (SELECT, INSERT, procédure,...) 3. Exécution de celle-ci sur la base 4. Traitement des résultats et présentation 14 /24
Injection SQL Différentes méthodes : Modification simple de comportement SELECT * FROM users WHERE name='hsc' and password='xxx' or 'x'='x' Enchaînement de deux requêtes SELECT * FROM table WHERE login='hsc' ; SELECT * FROM passwords ' Ne fonctionne plus avec la plupart des drivers Utilisations de fonctions spécifiques master..xp_cmdshell (MS SQL) shell("ping.exe 10.20.30.40") 15 /24 Utilisation de UNION SELECT Ccnum, Ccexp FROM Creditcards WHERE Ccnum='xxx' UNION SELECT NULL, NULL FROM 1=1 '
Injection SQL Exemple : Vulnérabilité IMP (Webmail) de janvier 2003 $sql="select username from $default->db_pref_table where username='$user@$server'"; http://webmail/imp/mailbox.php3?actionid=6&server=x&imapuser=x';somesql+--&pass=x" Écueils Utilisation des quotes (simples ou doubles) et des commentaires Les résultats ne sont pas toujours visibles Couche de présentation Les possibilités peuvent dépendre du driver utilisé et de la base attaquée 16 /24
De l'utilité des messages d'erreur Exemple avec le driver ODBC/ASP http://webserver/script.asp?id=0--%20%28select%20*%20from%20table%29 Microsoft OLE DB Provider for ODBC Drivers error '80004005' [Microsoft][ODBC Microsoft Access Driver] You have written a subquery that can return more than one field without using the EXISTS reserved word in the main query's FROM clause. Revise the SELECT statement of the subquery to request only one field. /script.asp, line 15 17 /24
Se prémunir Sécurité du développement : valider les entrées Règle fondamentale, ne protégera pas que contre l'injection SQL Injection de code, modification de comportements, buffer overflows,... Utiliser les fonctions spécialement conçues par le driver ->quote() (Perl DBI) mysql_escape_string (PHP) magic_quotes (PHP)... Se connecter avec des comptes différents si nécessaire Compte read-only Compte read-write 18 /24
Plusieurs niveaux: Sécurité des ERP Sécurité systèmes Sécurité réseau (chiffrement, firewalls, accès distants,...) Sécurité intrinsèque (accès, rôles, interfaces,...) Sécurité de la base de données Télémaintenance Doit être étudiée: Par les équipes fonctionnelles Par les consultants ERP Par l'équipe sécurité 19 /24
Exemple : SAP Peu d'études publiques de sécurité sur SAP («La sécurité SAP pour les nuls»): http://www.sapsecurity.net/ http://www.auditnet.org/sapaudit.htm http://www.giac.org/certified_professionals/practicals/gsec/0760.php Comptes systèmes créés sur Unix <SID>adm, ora<sid> Privilèges SAP : SAP_ALL S_A.SYSTEM Certaines transactions permettent d'exécuter du code système (SM59, rôle S_RSZ_ADM). 20 /24
SAP et Oracle Mot de passe par défaut sur l'utilisateur SAPR3 : SAP Oracle en mode insécurisé remote_os_authent = TRUE Utilisateurs OPS$SIDADM et OPS$ORASID ont le pribilège SAPDBA Pas de restrictions dans le LISTENER 21 /24
SAP Router: Télémaintenance SAP Relais TCP générique authentifié Permet d'atteindre toutes les applications du LAN (!) Restrictions Limitations IP Sources Limitations IP Destinations et protocoles http://help.sap.com/saphelp_nw04/helpdata/en/4f/992dbd446d11d189700000e8322d00/content.htm Doit être placé dans une DMZ 22 /24
Mobiles Sap Waldorf Proxy HTTPS Internet HTTPS IPSEC Sap Router VPN SSL Firewall SAP SAP LAN Infrastructure SAP 23 /24
Les SGBD sont: Complexes Conclusions Leur sécurité n'est pas toujours maîtrisée Les risques sont réels et parfois ignorés expériences HSC Il faut sensibiliser la chaîne: appels d'offre/cahier des charges développeurs recettes dba, admins, réseau,... Questions? 24 /24