Les principales attaques ciblant les Bases de Données

Sécurité bases de données Ajouter un commentaire

Nous allons passer en revue les principaux types d’ attaques envers les SGBDs, ainsi que les précautions à prendre pour s’en prémunir.

rem : le ‘Buffer Overflow’ et ‘linjection SQL’ seront détaillés dans un autre document.

Crack de password

programmes spécialisé aléatoires ou basés sur dictionnaire, ou crack manuel

mesures à prendre :

  • ‘politique’ de mots de passes (durée de vie , historique, complexité
  • imposée, etc.)
  • chiffrement ou hash non réversible
  • changement ou suppression des users connus : super user, administrator,
    system, guest, etc (==> AUdit régulier des bases)
  • SSO (évite les passwords utilisateurs faibles)

exemple de crack de password Oracle

La table DBA_TABLES est est une table du référentiel Oracle, qui recèle, outre le nom et différentes info sur les utilisateurs de la base, leurs mos de passe crypté. On peut l’utiliser pour cracker un mot de passe avec une méthode brute.

Les avantages de travailler sur ce mot de passe crypté sont multiples :

• Efficacité : on sait en gros comment Oracle chiffre ses mots de passe : algorithme DES 64 bits, password crypté de 30 caractères maximum, utilisation du user + mot de passe pour le hashage, etc. On ne part
donc pas de zéro
• travail OFFLINE : Contournement d’une éventuelle politique de mot de passe (password policy) : ce n’est pas le cas par défaut, mais le DBA peut limiter le nombre de tentatives de connexions infructueuses
et faire échouer une méthode brute. Voir l’utilisation des ‘PROFILES’ Oracle pour plus d’information. En travaillant sur une valeur cryptée, sans tentative effective de connexion

• Discrétion : Cf. le point précédent, on peut travailler tranquillement OFFLINE, sur un poste extérieur sans limite de temps ou de nombre d‘essais. Un programme de forçage de mot de passe peut être trouvé
sur le site ‘toolcrypt.org’ à l’adresse suivante :

logo_toolcrypt.gifhttp://www.toolcrypt.org/index.html?orabf

Sur un poste de Windows moyen, il m’a fallu une dizaine de minutes avec ce programme pour casser un mot de passe ‘SYSTEM’ de 6 caractères.
En mode commande il suffit d’entrer la commande suivante :

C:> orabf 70F277D6E92A1D9B:SYSTEM -n 6
– 70F277D6E92A1D9B est la valeur chiffrée lue dans le dictionnaire
– SYSTEM est le nom de l’utilisateur correspondant
– 6 la longueur minimale du mot de passe cherché

Mais attention : le décryptage d’un mot de passe alphanumérique > 8 caractères peut durer de quelques jours à plusieurs semaines !

Un comparatif intéressant des programmes de forçage des mots de passe Oracle, gratuits ou payants a été fait par la société ‘Red Database Security’ et peut être trouvé ici :
http://www.red-database-security.com/whitepaper/oracle_password_cracker.html

Contournement de l’applicatif par programme client SQL

Au lieu de se connecter via le programme apllicatif, on peut utiliser le mode commande ligne ou un interpréteur SQL standard (SQL+ d’Oracle) ou un outil d’admin (PHPMyAdmin, OEM). On utilise alors directement les droits
du compte propriétaire des données (en général tous les droits).

mesures à prendre :

pas de gestion de droits applicative !
connexion au compte propriétaire interdite (compte locké par exemple)
une gestion des droits fine (connexion + consultation et / ou mise à jour de tables (voire de vues) ciblées

Récupération de données OFFLINE ou Hors production

Il existe des sources de données partiellement ou parfois totalement redondantes de la base de données de production. Ces données peuvent être dans le même format que les données d’origine (tables d’une BD Oracle) ou dans des formats différents (texte, CSV, SQL, …).

Ces données redondantes sont en général moins (ou pas du tout) sécurisées, par rapport à la base de production,
et seront donc une cible plus facile pour les pirates fatigués.

Pour corser le tout, une mauvaise habitude assez répandue dans les entreprises consiste à recopier intégralement des données de production, dans les bases de test ou de développement, pouyr éviter d’extraire des jeux d’essai de données complexes, ou pour ne pas repartir de données vides lors d’un eopération de maintenance logicielle…

Comme données Offline, on citera par exemple :

  • BDs de développement, BDs de test,
  • export de données au format propriétaire (export Oracle par exemple)
  • reverse engineering SQL
  • export au format texte fixe ou CSV
  • sauvegardes binaires des fichiers de la BD, sur bande, disque ou DVD
  • fichier de trace, de LOG ou d’audit
  • base redondante de secours (standby DB)
  • données répliquées en synchrone ou asynchrone pour infocentre et reporting

donnees_offline

Back doors

(”Portes dérobées”) : Programmes usurpateurs qui détournent des fonctionnalités systèmes dans le but d’ouvrir
des accès utiles aux pirates pour contrôler à distance les machines ciblées (modification des programmes de login avec user/passwd en dur, ouverture de ports particuliers, etc.) . Ces programmes sont la plupart
du temps installés par le biais d’un “cheval de Troie”. Parmi les plus (tristement) célèbres, on peut citer BackOrifice (BO) ou encore NetBus.

Les accès illicites via ces backdoors pouvant être facilement détectés par des commandes système standards (liste des process connectés, des ports ouverts) ils sont parfois utilisés conjointement avec des rootkits, ensemble de commandes standards modifiées pour masquer les intrusions.

certaines back doors peuvent être inclsues dans le code d’applications standards,
sans intention forcément malveillante mais pour réserver au développeur du programme, un accès ‘privé’ à toute
les machines hébergeant son code. L’accès au source d’un logiciel libre peut nous prémunir contre ce genre d’indélicatesse.

Refus de service (Deny of Service)

voir le papier de sogoodtobe sur http://www.securiteinfo.com

Recherche d’infos de configuration

( d’identification, d’authentification , méta données )

  • au sein de l’applicatif (en clair dans le source interprété… ou désassemblé)
  • dans l’environnement (fichiers de configuration accessibles sur le serveur ou pire sur le client : *.ini)
  • dans la bases de données elle même
  • sur le réseau (écoute / sniff des lignes)

mesures à prendre :

  • chiffrer (solidement) les infos sensibles dans la BD, dans les fichiers de config,
  • restreindre les accès aux répertoires et fichiers
  • restreindre l’accès aux méta données
  • s’appuyer sur des mécanismes existant identification / authentification par le SGBD, par l’OS
  • réseau : utiliser des protocoles sécurisés : SSL (nécessite des certificats), IPSec, paramétrer finement le firewall, utiliser ports et user ‘originaux’
  • ‘politique’ de mots de passe

Les menaces les plus connues du grand public, visent à paralyser, ou détruire tout ou partie du système d’information. Elles ne ciblent pas vraiment les SGBDs mais nous les citerons néanmoins parce qu’incontournables.
Jetons un oeil aux définitions données par le grand glossaire de la sécurité de ECHU.ORG


Autres menaces et faiblesses de comportement

  • Virus : Au sens large du terme, on qualifie généralement de virus tout programme capable de se reproduire (techniquement, se recopier) lui-même et d’endommager des données informatiques. On les classe
    en plusieurs catégories, principalement: parasite, compagnon, amorce, multiformes, résident mémoire ou non, furtifs, polymorphes, réseau et flibustier.
  • Ver (ou Worm) : programme qui peut s’auto-reproduire et se déplacer à travers un réseau en utilisant les mécanismes réseau, sans avoir réellement besoin d’un support physique ou logique (disque dur, programme hôte, fichier …) pour se propager; un ver est donc un virus réseau.
  • Cheval de Troie : (en anglais trojan horse) un programme informatique effectuant des opérations malicieuses à l’insu de l’utilisateur : vol des mots de passe, copie de données sensibles, exécution d’action nuisible …Une intro très accessible de ces notions est dispo sur :
    http://www.commentcamarche.net/
    et d’autres infos encore sur : http://assiste.com

Quelques faiblesses de comportement

  • ‘portes’ ouvertes : (pas seulement les ‘back doors’ !)porte de la salle machine ouverte, poste ou serveur sans mot de passe ou mot de passe faible, poste sans veille, post it (!)
    ;-) fermez les portes !! mettez en oeuvre la gestion de mots de passe !!
  • Installation par défaut :- les valeurs de paramètres sont connues (port 80 / 1525, les administrateurs sont connus (SA SQLServer, SYS et SYSTEM Oracle, ROOT MySQL)
    - des services superflus sont accessibles (srv ftp, srv samba, snmp, serveur d’admin, etc )- les communications ne sont pas chiffrées (ftp, telnet, pop)
    ;-) lisez la doc !! auditez vos serveurs !!
  • mauvaise politique de gestion des droits (top, au lieu de bottom-up) :- installation confortable : tous les logiciels sont installés sous root, tous les utilisateurs de l’applicatif sont DBAs
    - allow all implicite…deny N / deny all.. allow n
    - utilisation abusive de l’héritage
    - mots de passe faibles
    ;-) maitrisez la gestions des droits de vos OS / logiciels serveurs / bases de données
  • absence de mise à jour
    ;-) faites de la veille technologique, patchez régulièrement, surveillez les alertes
  • mauvais codage (parametres en clair dans les URLs, connexion non chiffrées, code ‘injectable’, etc.) ;-) documentez vous (best practices, faites tester vos programmes)
  • controle d’accès au niveau applicatif, qui peut facilement être court circuité
    ;-) (re) centralisez (ET FACTORISEZ!) les controles au niveau données : contraintes d’intégrité

Comme chacun sait (depuis certaines émissions de télé) c’est le maillon faible de la chaîne qui cassera imanquablement. On peut mettre en place le plus beau (et le + cher) des firewalls, il sera bien
inutile si un adminitrateur est resté ‘loggé’ root sur son poste (Statistiquement la majorité des attaques provient de l’intérieur des entreprises !)

Cependant, on n’oubliera pas de rester pragmatique : tous les PMEs ne sont pas le pentagone et n’intéressent pas tous les hackers de la planète.
Les besoins et les objectifs doivent être clairement définis au départ et l’adéquation de la solution vérifiée.
Un certains nombres d’utilitaires libres sont disponibles sur internet pour vérifier la fiabilité de votre système d’information. Voir parmi la liste des liens utiles.

Il faudra de + trouver un équilibre entre niveau de sécurité satisfaisant et confort (voire simple possibilité) de travai ldes autres acteurs.

Faire un commentaire