Sécurisez votre instance Oracle

Oracle mixte la notion de schéma et de login. Un Schéma est en fait lié à un utilisateur qui est propriétaire d'au moins un objet. Un schéma dans son rôle de conteneur d'objets devrait en fait être un login verrouillé dont le mot de passe ne devrait même pas être connu.

Pour les schémas métier créés par vos équipes de développement, c'est généralement le cas. Personne ne se connecte directement sur ces logins, mais un utilisateur spécifique et applicatif peut y accéder.

Dans les faits malheureusement, la plupart des applicatifs externes n'utilisent pas le prédicat du schéma pour accéder aux tables. Il leur faut donc soit se connecter directement sous le nom du schéma, soit utiliser la notion de synonyme. Couplé à un trigger sur connexion, la commande ALTER SESSION SET CURRENT_SCHEMA offre cependant une alternative élégante et permet la dissociation du schéma et du login utilisé.

Dès sa version 12, Oracle offre désormais « un emplâtre sur une jambe de bois » à cette problématique d'affinité de schémas : les bases enfichables (pluggable databases). Cette option (supplémentaire et coûteuse) offre la possibilité de limiter les droits à un nombre défini de schémas. On peut donc donner des droits étendus à une base de données multitenant spécifique. Vous trouverez de plus amples informations dans l'article Architecture multitenant Oracle 12c.

Pour couronner le tout, certains logins/schémas système Oracle sont installés par défaut dans toute nouvelle instance et ont des droits excessifs ou/et des failles sécuritaires. Il est donc primordial de ne laisser sur une instance Oracle que les schémas nécessaires. Au besoin, il est toujours possible de recréer ces schémas via les scripts Oracle. Le surplus doit être désinstallé ou, au minimum, verrouillé.

La liste des schémas Oracle, une explication sommaire et les scripts de création et de désinstallations sont décrits dans l'article Les schémas Oracle.

IV-B-1. Mots de passe simplistes▲

CREATE PROFILE Compexite_Pwd_profile 
    LIMIT PASSWORD_LIFE_TIME 30
    LIMIT PASSWORD_REUSE_TIME 180 
    LIMIT PASSWORD_REUSE_MAX 3 ;

ALTER USER scott PROFILE my_profile;

C:\oracle_checkpwd>checkpwd122.exe system/monpwd@hostdvp:1521/ORA10G.DVP.COM default_passwords.txt
Checkpwd 1.22 - (c) 2007 by Red-Database-Security GmbH
Oracle Security Consulting, Security Audits & Security Trainings
http://www.red-database-security.com

initializing Oracle client library
connecting to the database
retrieving users and password hash values
disconnecting from the database
opening weak password list file
reading weak passwords list
checking passwords
Starting 1 threads
JRULES  OK [OPEN]
SNPM    OK [OPEN]
SNPW    OK [OPEN]
MIDOFF  OK [OPEN]
WAREHOUSE has weak password BUSINESS [OPEN]
DISTRIBUTE has weak password HOUSE [OPEN]
MDSTATUS has weak password MDSTATUS [OPEN]
QC      OK [OPEN]
DASHBOARD    OK [OPEN]
SYS_USER      OK [OPEN]
DEPLOYER  OK [OPEN]
TSMSYS  OK [LOCKED]
DBSNMP  OK [OPEN]
EXFSYS  OK [LOCKED]
XDB     OK [LOCKED]
SYSMAN  OK [LOCKED]
MGMT_VIEW       OK [OPEN]
SYS     OK [OPEN]
SYSTEM  OK [OPEN]
OUTLN   OK [LOCKED]

Done. Summary:
  Passwords checked      : 43241
  Weak passwords found   : 3
  Elapsed time (min:sec) : 0:00
  Passwords / second     : 43241

IV-B-2. Mots de passe par défaut▲

IV-B-3. Mots de passe codés en dur▲

create or replace TRIGGER "SYS"."BLOCK_USER_ACCESS" 
AFTER LOGON ON DATABASE 
DECLARE
  v_prog sys.v_$session.program%TYPE;
  v_dbuser sys.v_$session.username%TYPE;
  v_osuser sys.v_$session.osuser%TYPE;
  v_db sys.v_$database.name%TYPE;

/*
 * Auteur : Fabien Celaia
 * Date   : 7 juillet 2006
 * Desc.  : Empêche l'utilisation de certains logins avec certains applicatifs
 */

BEGIN
  /* Récupération des informations utiles dans v$session */

  SELECT upper(program), upper(username), upper(osuser) 
  INTO   v_prog, v_dbuser, v_osuser
  FROM sys.v_$session
  WHERE  audsid = USERENV('SESSIONID')
    AND  audsid != 0  -- N'impacte pas la connexion SYS
    AND  rownum = 1;  -- Gestion du parallélisme (même AUDSID)

   SELECT upper(name) 
   INTO   v_db 
   from v$database ;

  /* Utilisation à proscrire */
  IF v_dbuser NOT IN ('SYSTEM', 'SYS', 'STREAM', 'DBSNMP')
     AND coalesce(v_osuser,'SYSTEM') not in ('SYSTEM')
     AND (v_prog ='TOAD.EXE'
       OR v_prog LIKE '%ACCESS.EXE'
       OR v_prog LIKE '%SQIREL%'
       OR v_prog LIKE 'SQLPLUS%'
       OR v_prog LIKE 'SQL DEV%'
       OR v_prog LIKE '%MSQ%.EXE')
  THEN
    RAISE_APPLICATION_ERROR(-20000,  v_osuser ||' n''est pas autorisé à utiliser  '|| v_prog ||' sur l''environnement '||v_db) ;
  END IF;

  EXCEPTION
    WHEN NO_DATA_FOUND THEN NULL;
END;

IV-B-4. Spoliation temporaire de mot de passe▲

SQL> connect system/motdepasse 
Connecté

SQL> select password from dba_users where username='MONCOCO'

PASSWORD
-----------------------------
F894765434402B67

SQL> alter user MONCOCO identified by MonPwd

User altered

SQL> connect MONCOCO/MonPwd
Connecté

SQL> connect system/motdepasse
Connecté

SQL> alter user MONCOCO identified by values 'F894765434402B67'

Une des principales failles de la sécurité Oracle est qu'il n'est quasi pas possible d'empêcher un administrateur du système d'exploitation de se connecter en tant qu'administrateur de la base de données.

Sous Windows, un administrateur est tout à fait en mesure de se mettre dans le rôle système oradba. Sous Unix, idem pour le rôle, et de manière encore plus aisée, il sera en mesure d'exécuter un sudo - oracle.

Cette capacité à se connecter sur une instance Oracle sans mot de passe, directement en sqlplus / as sysdba permet à quiconque qui aurait des droits d'administration sur la machine de se connecter en tant que superuser sur Oracle.

Cela peut aussi être considéré comme un avantage lors du départ inopiné ou du décès du DBA !

Que ce soit via SQLDeveloper ou via Toad, les configurations de connexion sont stockées sur le PC client du développeur/DBA. Bien que ces 2 applicatifs stockent les mots de passe en cryptage EAS, il est possible, au travers d'un disque partagé par exemple, d'aller « vampiriser » le fichier de configuration afin de s'approprier les accès excessifs, sans pour cela connaître les mots de passe utilisés.

IV-D-1. Informations de connexion stockées en local▲

IV-D-2. Clients non patchés / non sécurisés▲

IV-D-3. Fichiers autoexécutables▲

Le listener d'Oracle peut être détourné à des fins néfastes. Il permet de sniffer le protocole de transfert Oracle non crypté. Les requêtes, les données passent en clair au travers de la trame. Plusieurs solutions peuvent être mises sur pied afin de pallier ce problème. Il convient aussi de spécifier au listener de quelles bases il est censé gérer la communication.

Pour les applications n'étant pas orientées extranet, le risque de subir ce genre d'attaque de l'extérieur est plus limité. Cependant, il existe en interne, mais est aisément détectable, les outils de scannage (nmap, amap, etc.) étant perçus comme des attaquants par les outils réseau. Le risque existe néanmoins puisque ce type d'attaque est en mesure de faire tomber certains modules Oracle (Notification Delivery Service).

Les failles de sécurité n'étant fixées que dans les dernières versions, les anciens binaires Oracle sont plus sensibles. Il convient donc de supprimer toute ancienne version de binaire.

rm $ORACLE_HOME/bin/dumpsga

rm $ORACLE_HOME/bin/*.bak<br/>
rm $ORACLE_HOME/bin/*.0

Certains modules Oracle offrent des possibilités d'intrusion SQL. Il est donc nécessaire de réduire au maximum les droits (par défaut ALL to PUBLIC) sur ces modules. Ceux-ci ne peuvent pas être purement et simplement supprimés, car appartiennent au noyau Oracle.

revoke execute on sys.dbms_obfuscation_toolkit from public ;
grant execute on sys.dbms_obfuscation_toolkit to sysman ;
grant execute on sys.dbms_obfuscation_toolkit to dbsnmp ;
grant execute on sys.dbms_obfuscation_toolkit to wksys ;
Grant execute on sys.dbms_obfuscation_toolkit to flows_030000 ;
revoke execute on sys.utl_tcp from public ;
grant execute on sys.utl_tcp  to sysman ;
revoke execute on sys.utl_http from public ;
grant execute on sys. utl_http  to ordplugins ;
revoke execute on sys.utl_smtp from public ;
grant execute on sys.utl_smtp  to sysman ;
revoke execute on sys.utl_file from public ;
grant execute on sys. utl_file  to ordplugins ;
Grant execute on sys.utl_file to mitg_rml ;
Grant execute on sys.utl_file to mitg ;
grant execute on sys. utl_file  to xdb ;
grant execute on sys. utl_file  to sysman ;
grant execute on sys. utl_file  to dmsys ;
revoke execute on sys.dbms_lob from public ;
grant execute on sys.dbms_lob  to xdb ; 
Grant execute on sys.dbms_LOB to ctxsys ;
Grant execute on sys.dbms_lob to flows_030000 ;
Grant execute on sys.dbms_lob to mitg_rml ;
Grant execute on sys.dbms_lob to mitg ;
grant execute on sys.dbms_lob  to dmsys ;
grant execute on sys.dbms_lob  to exfsys ;
grant execute on sys.dbms_lob  to dba ;
grant execute on sys.dbms_lob  to ctxsys ;
grant execute on sys.dbms_lob  to mdsys ;
grant execute on sys.dbms_lob  to ordsys ;
grant execute on sys.dbms_lob  to wksys ;
grant execute on sys.dbms_lob  to olapsys ;
grant execute on sys.dbms_lob  to ordplugins ;
revoke execute on sys.dbms_job from public ;
grant execute on sys.dbms_job  to dbsnmp ;
grant execute on sys.dbms_job  to wksys ;
grant execute on sys.dbms_job  to exfsys ;
Grant execute on sys.dbms_job to flows_030000 ;
revoke execute on sys.utl_inaddrm from public ;
revoke execute on sys.dbms_export_extension from public ;
grant execute on sys.dbms_export_extension to dba ;
grant execute on sys.dbms_export_extension to system ;
revoke execute on sys.dbms_backup_restore from public ;
revoke execute on sys.dbms_sql  from public ; 
grant execute on sys.dbms_sql  to sysman ;
grant execute on sys.dbms_sql  to system ;
grant execute on sys.dbms_sql  to xdb ;
grant execute on sys.dbms_sql  to exfsys ;
Grant execute on sys.dbms_sql to flows_030000 ;
grant execute on sys.dbms_sql  to dmsys ;
Grant execute on sys.dbms_sql to mitg_rml ;
Grant execute on sys.dbms_sql to mitg ;
grant execute on sys.dbms_sql  to mdsys ;
grant execute on sys.dbms_sql  to olapsys ;
grant execute on sys.dbms_sql to ctxsys ;
grant execute on sys.dbms_sql  to oracle_ocm ;
revoke execute on sys.dbms_ldap  from public ;
revoke execute on sys.dbms_advisor from public ;
Grant execute on sys.dbms_ldap to flows_030000 ;
GRANT EXECUTE ON  SYS.DBMS_LDAP TO sysman ;

Sans oublier pour chaque schéma pouvant être importé :

grant execute on sys.dbms_export_extension to MonSchema ;

Pour diverses raisons (installation de modules Oracle, telle que la dbconsole par exemple), il est souhaitable d'avoir les droits initiaux sur ces modules. Voici donc les requêtes SML de rétro conversion :

grant all on sys.dbms_obfuscation_toolkit TO PUBLIC ;
grant all on sys.utl_tcp TO PUBLIC ;
grant all on sys.utl_http TO PUBLIC ;
grant all on sys.utl_smtp TO PUBLIC ;
grant all on sys.utl_file TO PUBLIC ;
grant all on sys.dbms_lob TO PUBLIC ;
grant all on sys.dbms_job TO PUBLIC ;
grant all on sys.utl_inaddrm TO PUBLIC ;
grant all on sys.dbms_export_extension TO PUBLIC ;
grant all on sys.dbms_backup_restore TO PUBLIC ;
grant all on sys.dbms_sql  TO PUBLIC ; 
grant all on sys.dbms_ldap  TO PUBLIC ;
grant all on sys.dbms_advisor TO PUBLIC ;

En spécifiant une SORT_AREA_SIZE = 0, les tris sont redirigés sur le disque (tablespace temp) plutôt que la mémoire, et donc éditables via des outils tels que BBED.

Ceci étant dit, cette attaque est purement théorique puisque

• BBED nécessite un accès local sur le serveur ;
• BBED peut aussi attaquer directement les tablespaces de données.

Elle reste cependant une alternative de contournement pour les données protégées par Virtual Private DB, Label Security, et autre Database Vault.

Souvent malheureusement, la priorité est donnée au développement, le côté sécuritaire étant temporairement mis de côté afin d'éviter de ralentir l'avancée des projets. Les droits sont souvent attribués de manière lâche afin de permettre des installations peu problématiques, les spécificités logicielles en la matière étant souvent minimums et lacunaires. Il convient de reprendre la main sur cet état de fait afin de n'attribuer à un compte que les droits justes et nécessaires.

De manière basique, certaines structures s'accommodent d'une hiérarchie de rôles minimum, dont voici un exemple

Une gestion de la sécurité plus sérieuse ne pourra se faire sans une analyse longue et rébarbative, et sans les couacs inhérents à une restriction de droits. Il va sans dire que plus cette tâche sera retardée et plus elle sera pénible à mettre en place.

Il convient donc de reprendre cette stratégie de rôles de manière plus sectorielle. Une première mesure serait de créer des droits en baissant la granularité actuelle qu'est la base de données à une granularité de schéma.

Pour reprendre l'exemple le plus flagrant, en production, seul le déployeur devrait être en mesure de créer/modifier/supprimer des objets/d'utiliser le DML.

D'autres mesures, plus conceptuelles celles-ci, devraient être prise afin d'assurer un minimum de cohérence de données, et ce même dans un environnement 3-tiers.

Oracle offre des possibilités énormes de gérer des hiérarchies de rôles, des profils… malheureusement, certaines lacunes péjorantes existent et entravent la mise en place rigoureuse des autorisations :

• certains droits doivent être donnés en direct sur les logins afin que les comportements soient corrects (surtout au niveau de la programmation de packages PL-SQL) ;
• les quotas ne peuvent pas être attribués à des rôles ;
• etc.

À partir d'un jeu de sauvegarde ou d'un fichier d'export, il est possible de remonter toute l'information sensible sur une instance étrangère/non sécurisée.

Il est dès lors nécessaire de gérer ces médias avec toute la prudence qui s'impose.

Par défaut, les fichiers d'export ont des droits trop étendus, car ils utilisent le masque (umask) par défaut. Il convient donc d'être prudent lorsqu'on réimporte un fichier ayant été stocké préalablement sur le disque ou venant de l'externe. Il est aisé d'inclure dans le code SQL du fichier d'export des portes dérobées.

Il est primordial qu'aucune information interne concernant vos instances ne se retrouve en DMZ ou sur Internet.