1 [1] Introduction

2  [2] A savoir (et à se rappeler…) avant de commencer

3 [3] Les grandes étapes du “Projet” Sécurité

4  Les différents aspects de la sécurité

5 [4] Les mécanismes mis en oeuvre pour la sécurité des BDs

6 [5] Les principales attaques ciblant les SGBDs

7 [6] Le cas de l’injection SQL

8 [7] Autres menaces et faiblesses de comportement

[8] 9 [9] Une application concrète : Les basiques de a sécurité d’Oracle
[10]

1) Introduction

Evolution des architectures vers plus de complexité

On trouvera ci’-après un résumé succint des principales étapes de l’évolution des architectures matérielles et
logicielles qui se sont profondément modifiées lors des deux dernières décennies.

Type client	Type serveur	Type connexion / architecture	logiciels clients	logiciels serveur
terminal	Mainframe	directe	-	OS + Applicatif + fichiers de données
PC terminal	Départemental	réseau	émulateur	OS + Applicatif + SGBD
PC lourd	Départemental	client / serveur	applicatif nav + applet	OS + Applicatif + SGBD
PC léger	Départemental / Central	n-tier+ X Net	navigateur	Srv d’application : OS (+web) + appliSrv de données : OS + SGBD

la  plupart de ces architectures peuvent sembler désuettes, voire anachroniques,  mais il suffit de se pencher sur l’écran d’un ordinateur dans une grande surface ou un aéroport pour constater que l’émulation de terminal  (même enjolivée) est toujours très utilisée .
Quoi qu’aie pu en penser SUN il y a quelques années :” the Network  is NOT YET the computer”

On constate cependant à l’évidence une tendance à  la complexité :

• multiplication des matériels (plusieurs clients fixes ou mobiles,
  plusieurs serveurs, réseau hétérogènes)
• multiplication des couches logicielles (OS client, application client, client
  reseau, OS serveur, serveur reseau, serveur applicatif, SGBD)
• multiplication (voire ubiquité) des réseaux ( intranet, internet
  et surtout en ce qui concerne la sécurité des données
  EXTRAnet)
• généralisation du partage de données : entre particuliers,
  mais aussi employés, entreprises, clients, fournisseurs, partenaires

qui fait de la sécurité des données un enjeu majeur

La sécurité : un nouvel enjeu

Plusieurs raisons font que la sécurité devient un enjeu important  :

• complexité croissante des SI
• exigence croissante de qualité (certification ISO 9001, et plus spécifiquement  ISO 27001)
• exposition accrue des données et applications avec INTERNET + INTRANET ++ EXTRANET
• augmentation (et meilleure diffusion / communication) des attaques

Pour info, ci après les statistiques du [11] CERT  sur les enregistrements d’incidents des dernières années :

Note : l’absence de statistiques depuis 2003 indique simplement que le CERT a arrété de compter !!!!!!!!!!!!!!!!! Notamment à cause du fait que de + en + d’automates font des attaques  massives, ce qui rend leur nombre de moins en moins significatif.

2) A savoir (et à  se rappeler…) avant de commencer

• La complexité des SI impose une approche globale,
  ’systémique’ du problème (attention de ne pas envisager QUE la sécurité des BDs)

• Un SI a le niveau de sécurité du plus faible de ses composant  (principe du “maillon faible” !)

• Elle nécessite l’implication ET SURTOUT L’ADHESION  de TOUS  (si certains employés n’adhèrent pas, ils généreront  du “maillon faible”)

• La sécurité est fonction d’objectifs et d’un enjeu  (la mise en place d’un plan de sécurité est un projet)

• Il n’existe pas de système totalement sûr( on visera à satisfaire au mieux les objectifs et répondre aux besoins)

3) Les grandes étapes du “Projet” Sécurité

 

elles peuvent être résumées dans le schéma suivant  :

La phase stratégique

note : la phase stratégique reboucle sur elle même : la décision stratégique , plutôt une VOLONT2 STRATEGIQUE au départ donne lieu à une étude d’opportunité / faisabilité (en fonction des risques, des enjeux, des obligations légales, etc) et donne (ou pas) la décison stratégique.

• La législation 

Pourquoi la prendre en compte :
- il existe des lois, nul n’est censé les ignorer
- les enfreindre implique une responsabilité civile ou pénale de l’entreprise
- la loi peut imposer de nouvelles activités à l’entreprise (pas seulement interne) : exemple : la dématérialisation des marchés publics et l’e administration

Quelle législation ?
- lois nationales, directives, Européennes, lois internationales
- règlements intérieurs, conventions collectives (de la métallurgie par exemple), délibération des collectivités

Les lois nationales concernent principalement :
- la loi informatique et libertés (CNIL) (respect de la vie privée, des données personnelles, obligation de déclaration)
- la propriété intellectuelle
- protection/la copie/le piratage d’oeuvres ou de logiciels
- le recyclage de déchets électroniques et informatiques

• L’analyse des risques

On sait qu’il y a des risques, encore faut il les analyser / évaluer.
Il existe différentes catégories de menaces :
- internes / externes (80% / 20 % !!)
- par intérêt économique ou par jeu / défi intellectuel

Il existe différents types d’acteurs :
- des individus (employés rancuniers ou cupides, hackers)
- des entreprises
- des états (espionnage industriel, terrorisme)

On évaluera par exemple leur probalité (est ce qu’une administration est susceptible d’être attaquées par des entreprises concurrentes ???)

• La classification

Pragmatisme !! : toutes les informations ou ressources associées ne demandent pas le même niveau de sécurité. Cela implique de les classifier / quantifier. Un effet de bord intéressant sera que l’on limitera l’énergie et l’argent dépensé !

On quantifie la SENSIBILITE des infos et ressources (en fonction de la loi, des enjuex , des missions de l’entreprise)
==> taxinomie :

- par niveau de sensiblité
- par domaine de sécurité (confidentialité, disponiblité,…)
Ceci implique des procédures de protection et de gestion des documents et des ressources.
ET aussi un niveau de diffsuion des docs (de libre à…secret défense!)

4) Les différents aspects de la sécurité

On envisage souvent la sécurité sous un angle fermé, essentiellement celui de la confidentialité. Mais bien d’autres concepts sous tendent la sécurité. Ils sont pratiquement tous applicables aux OS ET aux SGBDs, tant il est vrai que ces deux domaines sont extrèmement recouvrants.

• confidentialité
  Tout n’est pas accessible à tout le monde! Se connecter à  l’OS ou à la base de données, donne un certain nombre de droits et de ressources en fonction d’un profil défini et maintenu par un administrateur. La granularité d’accès peut  aller jusqu’à la vision unique d’un champ d’un enregistrement d’une table articulière.
• disponibilité
  Faculté de délivrer correctement un service en terme de délai et de qualité à l’utilisateur. Se mesure en pourcentage du temps de fonctionnement total.Une disponibilité de 100% est possible (temps
  de reprise nul) il suffit de s’en donner les moyens logiciels et matériels…
• fiabilité
  Des mécanismes de sauvegarde variés (physique, logique, off-line, on-line, totale, partielle, incrémentale), ainsi que des mécanismes de journalisation, et de reprise permettent de restaurer une information sans
  pratiquement aucune perte, dans tous les cas de problème matériel ou logiciel.
• intégrité
  Que les données soient réparties ou non –dans ce dernier cas les mécanismes mis en jeux seront plus complexes– elles doivent être cohérentes. Cela sous entend, d’une part que les accès concurrents d’utilisateurs, notamment lors de mises à jour, ne doivent pas compromettre la cohérence des données et d’autre part que ces dernières satisfassent aux contraintes d’intégrité  du modèle, et / ou aux règles de gestion de l’entreprise.
• tracabilité
  en cas de problème important ou d’attaque du système, on peut recourir à l’analyse de traces ou de logs. Le niveau de détail de ces traces est paramétrable, et concerne soit les aspects système, soit réseau, soit l’accès aux données élémentaires elles-mêmes.
• maintenabilité  aptitude à la réparation, évolution, maintenance du système. Mesuré en temps de reprise après panne (Mean Time To Recover)

5) Les mécanismes mis en oeuvre pour la sécurité des BDs

Les sgbds (dignes de ce nom) se doivent de fournir un certain n ombre de mécanismes internes ou de fonctionnalités assurant un niveau satisfaisant de sécurité.

• L’authentification, est le processus qui permet de vérifier
  qu’un utilisateur réclamant un accès est bien celui qu’il prétend être, ou plus simplement le processus qui contrôle l’identité de l’utilisateur. Cette action (login) se fait en général via la fourniture du couple nom d’utilisateur / mot de passe.
  Dans certains cas l’authentification peut être implicite et héritée d’une authentification précédente, ou reconnue automatiquement (@IP du user sur le réseau par exemple), bien que simplifiant les accès ce choix peut évidemment s’avérer dangereux.

La multiplication des couches logicielles sus évoquée, et l’inflation d’applications sur les postes utilisateur fait que ce dernier est fréquemment amené à s’authentifier des dizaines de fois par jour. La signature unique (Single Sign On ou SSO) est un objectif très louable mais rarement atteint !

• Les droits et privilèges : une fois correctement identifié l’utilisateur doit pouvoir accéder aux informations
  et ressources auxquelles il a droit (et uniquement à celle là! ) Ce problème est résolu le + simplement avec la gestion de droits élémentaires accordé à un individu, ou plus efficacement avec des rôles et / ou profils affectés à des groupes d’invidus…ou à des rôles ou profils.
• Les LOGs ou traces : permet d’enregistrer tout ou partie des informations concernant les accès (réussis ou échoués). Cette trace pourra être plus ou moins verbeuse et son volume étroitement surveillée. De ce fait on l’utilisera de manière cibllée sur des périodes de temps spécifiques
• tolérance aux pannes : permet par du matériel ou du logiciel redondant (CPUs, disques, IOs) de supporter de manière partiellemnt ou complètement transparentes différents types de pannes, tant au niveau du client, que du réseau, que du serveur. Une tolérancec totale a bien sur un cout certain.
• sauvegarde et restauration
  sauvegarder les données sur des supports externes (disques,  bandes, etc.) et pouvoir les restituer, les plus à jour possible.  Le but est de ne pas perdre de données suite à un pb matériel (panne disque) , logiciel (bug) ou une fausse manipulation d’un utilisateur.
• mécanismes transactionnels
  l’atomicité des transactions, par définition assure la cohérence des données, même dans des environnements distribués. L’image avant modification, stockée de manière redondante dans ou hors de la BD, permet de faire d’éventuels retours arrière pour retrouver le dernier état cohérent, ou de s’assurer qu’il n’y aps pas eu d’opérations partielles ou incomplète (transaction bancaires par exemple)

Aspect sécurité	mécanisme mis en oeuvre	exemple d’implémentationau niveau SGBD	exemple d’implémentationau niveau OS
confidentialité	authentification indépendance logique / physique	référentiel user / password : DBA_USERS tables de user applicatifs identification externe : CREATE USER …IDENTIFIED EXTERNALLY tables / tbs / fichiers vues (1) [12] virtual private database	SSO LDAP identification externe architecture client serveur
	droits et privilèges	[13] droits d’accès aux  données GRANT SELECT ON toto [14] droits du LDD ou Systeme GRANT CREATE TABLE TO… GRANT CREATE SESSION TO… [15] roles	user OS DBA ou root
traçabilité	logs et traces	[16] tables d’audit log Oracle Net	logs apache logs OS logs réseau
fiabilité, disponibilité, maintenabilité	tolérance de panne	stand by DB cluster logiciels : architecture R.A.C	H.A.C.M.P techno RAID machine redondantes
	sauvegarde et restauration	physique : sauvegarde + journalisation + restauration logique : export / import génération de SQL	copie physique totale
intégrité	transaction atomique contraintes d’intégrité	Two Phase Commit (2PC) contraintes ‘reference’ read consistancy

(1) la vue est pratiquement le seul contrôle d’accès offrant un niveau de granularité ligne ou colonne ! et qui plus est de manière contextuelle, en les paramétrant (tranches horaires, @ IP, etc.)

6) Les principales attaques ciblant les SGBDs

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, complecité

•   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 :

[17] http://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

[18]

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 répliquées
• données répliquées en synchrone ou asynchrone

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 [19] http://www.securiteinfo.com

Buffer Overflow :

[20] Voir le document joint

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 [21] le grand glossaire de la sécurité de ECHU.ORG

7) Le cas de l’injection SQL

[22] voir le document joint

8 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 : [23] 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.

Quelques liens utiles sur la sécurité en général

[24] http://www.cert.org[25] http://www.certa.ssi.gouv.fr	LE centre d’expertise sur la sécurité internetle site du premier ministre sur la sécurité des S.I
http://blogorak.estsurinternet.com http://didier.deleglise.free.fr/ ou http://oracle.estsurinternet.com http://www.red-database-security.com/ http://www.petefinnigan.com/ http://www.oracle.com/technology/deploy/security/index.html http://otn.oracle.com	Mon blog sur Oracle 10g et la sécurité Mes tutoriels sur Oracle le site d’Alexander Kornbrust le site de Pete Finnigan Oracle security center : Oracle’s Security guide sur OTN
[26] http://www.insecure.org/links.htmlhttp://citadelle.intrinsec.org/ http://www.securiteinfo.com/	qq liens supplémentaires

Annexe : Systèmes haute sécurité (Trusted Systems)

voir le document (sécurisé) joint sur [27] lessystèmes haute sécurité