La manière la plus simple pour accéder à une base de données Oracle consiste à en demander le mot de passe à quelqu’un qui le connait. Vous souriez ? C’est surement que vous faites partie d’une équipe de sécurité informatique… Cynique ? Effronté ? plutôt dépité ! Vous seriez étonné de tous les gens qui connaissent les mots de passe. Comme si vous pouviez interdire les accès SQL à vos bases de données avec un firewall. D’ailleurs, il n’y a rien de plus inquiétant que de réaliser qu’il y a si peu d’utilisateurs qui s’appuient sur des méthodes d’authentification évoluées basées sur Advanced Security Option ou Enterprise User Security. Et si vous saviez ce que les bases de données contiennent. Oui, pour avoir un mot de passe, il suffit souvent de dire « s’il te plait »…

Je sais, personne n’y croit… Alors, l’alerte CVE-2012-3137, dont un correctif est inclus dans le Critical Patch Update Octobre 2012 est, un peu, comment dire ? Mon rayon de soleil ! Elle indique qu’il y a une méthode (très) efficace et quasi-intraçable pour trouver les mots de passe Oracle avec un simple accès distant. Il suffit, pour cela, de pouvoir utiliser Oracle Net. Vous pourrez alors très probablement vous connecter. Et même sans dire « s’il te plait »… Evidemment, si (1) vous utilisez l’authentification via ASO et EUS et bloqué ces comptes ou (2) vous avez appliqué le patch ou (3) que vous avez des mots de passe de 12 caractères que vous changez régulièrement, vous êtes sans doute à l’abri. A ce propos, avez-vous installé le Security Patch Update ?

Le paradoxe, c’est que vos bases de données sont peut-être plus à risque aujourd’hui que le correctif est disponible qu’il y a quelques mois. Le problème est pourtant apparu il y a plusieurs années. Il n’était jusqu’à récemment connu que de rares initiés. L’algorithme associé est simple. Basé sur l’algorithme AES 192, il est disponible dans différentes sources et notamment dans une plugin de John the Ripper. Vous trouverez ci-après des pointeurs vers les ressources utiles sur le sujet et la mise en oeuvre de l’utilisation de la faille sur un environnement de test. Évidemment, n’utilisez pas cette méthode pour autrechose que pour apprendre !

De quoi s’agit-il ?

L’histoire de la faille de sécurité est expliquée dans l’article intitulé « Attack Easily Cracks Oracle Database Passwords » sur darkreading.com. Elle aurait été révélée à Oracle par Esteban Martinez Fayo en mai 2010. Elle est liée à l’algorithme de génération de la clé de session de la version 11g. Oracle a inclus une évolution du protocole O5LOGON dans la version 11.2.0.3 dite level=12 qui ne souffre pas de cette limite, toutefois la version 11.2.0.3 supporte toujours les versions précédentes pour des raisons de compatibilité et donc la faille existe toujours même si elle peut être bloqué à l’aide du paramètre SQLNET.ALLOWED_LOGON_VERSION=12 qui, par ailleurs, empêche les autres clients 11g de se connecter. Esteban Martinez Fayo a présenté un prototype de l’attaque le 19 septembre 2012 à la conférence Ekoparty security de Buenos Aires et Oracle inclut le correctif dans le CPU d’octobre 2012.

La méthode pour retrouver le mot de passe est « brute force ». Elle consiste à récupérer une valeur de hash dans le protocole de connexion et tester la transformation des chaines de caractère à partir d’un dictionnaire ou d’un générateur selon l’algorithme de hash. La clé récupérée est salée ce qui empêche l’utilisation d’un référentiel (index). Vous devrez recalculer le hash à chaque fois à l’aide du Salt. L’algorithme est décrit dans un script Python révélé sur le site de securityfocus.com. Celui-ci est basé sur AES 192 qui est très rapide à calculer. Cet algorithme est implémenté dans certaines puces comme les GPU NVidia dont certains logiciels savent tirer parti pour calculer plusieurs millions de combinaisons par seconde. Il est implémenté sous la forme d’une plug-in John the Ripper disponible dans la version Magnum Ripper.

Capturer les HASH et SALT

Les détails de l’implémentation sont décrits dans le blog de Marcel Lambrechts intitulé « Cryptographic flaws in Oracle Database authentication protocol ». Le principe consiste à récupérer la valeur de hash envoyée à l’initialisation d’une session Oracle Net AUTH_SESSKEY et le SALT associé disponible dans AUTH_VFR_DATA.

Pour cela, vous devez connaître préalablement l’adresse et le SID d’une base de données et lancer une demande de connexion via SQL*Plus par exemple. Si vous utilisez une version 11.2.0.2 du client et que le serveur est une base de données 11g jusqu’à 11.2.0.3 sans le CPUOct2012, vous pourrez capturer les 2 variables dans le protocole. Je vous invite à lire cette présentation par László Tóth qui décrit le protocole de connexion des bases de données 11g.

Pour capturer les 2 variables, il suffit donc par exemple depuis un client Linux :

• de lancer un tcpdump pour capturer le protocole Oracle Net

tcpdump tcp port 1521 -s 0  -w output.pcap

• de lancer une connexion avec les comptes techniques connus, comme SYS par exemple comme ci-dessous :

sqlplus sys/wrongpassword@blue:1521/BLUE as sysdba

Note:
La valeur de hash est générée avant l’envoi du mot de passe ; tout ce qu’il suffit de faire consiste donc à lancer une demande de connexion, il n’est pas nécessaire qu’elle réussisse. C’est ce qui permet de collecter les informations sans avoir accès au réseau. Par ailleurs, il existe, au moins en théorie, un script NMAP nommé oracle-brute-stealth.nse qui génère la demande de connexion. Celui-ci ne fonctionne pas dans mon cas et nécessiterait surement de creuser cette fonctionnalité puisque Oracle « ne tracerait » pas la demande dans le cas où vous n’envoyez pas les messages pour challenger la connexion ce qui rendrait l’attaque quasi-invisible, même si l’audit est actif…

Vous repèrerez facilement les valeurs des variables dans le flux réseau capturé sur votre carte locale comme dans les sections coloriée ci-dessous :

^@^@^LAUTH_SESSKEY`^@^@^@`747F03096FBD0763485EB81C49AA00F1BF498A0FE9023EFCB40E884C59B11CB0E1C1E604535182FE3249F78F4942C2D1^@^@^@^@^M^@^@^@^MAUTH_VFR_DATA^T^@^@^@^T12AB75E604AD12E84F02%^[^@^@^Z^@^

John The Ripper

Installez John the Ripper comme ci-dessous, ou presque :

git clone git://github.com/magnumripper/JohnTheRipper unstable-jumbo
m
ake clean linux-x86-cuda
$ ./john -fo:o5logon -t
Benchmarking: Oracle O5LOGON protocol [32/32]... DONE

Créez ensuite un fichier qui contient les éléments suivants :

<user>:$o5logon$<hash>*<salt>

Comme ci-dessous :

sys:$o5logon$747F03096FBD0763485EB81C49AA00F1BF498A0FE9023EFCB40E884C59B11CB0E1C1E604535182FE3249F78F4942C2D1*12AB75E604AD12E84F02

Vous pouvez lancer JtR à l’aide d’un dictionnaire ou en testant systématiquement les mots de passe :

./john --wordlist=rockyou.txt ./hash.txt 
Loaded 1 password hash (Oracle O5LOGON protocol [32/32])
oracle1          (sys)
guesses: 1  time: 0:00:00:00 DONE (Sat Nov 17 21:59:53 2012)  c/s: 741068  trying: oracle1
Use the "--show" option to display all of the cracked passwords reliably

Pour aller plus loin

Si vous êtes intéressé par toujours plus d’informations, lisez :

• la note 1492721.1 à propos des moyens de prévenir l’alerte CVE-2012-3137 sans appliquer le patch
• La matrice de l’ensemble des alertes qui concernent les bases de données Oracle.
• Ne dite à personne que vous pouvez sans doute accéder à leurs mots de passe Oracle

Et pensez bien à la nature des informations, de toutes les informations, qui sont stockées dans vos bases de données…