Parmi les dizaines de lignes directrices que l'on pouvait percevoir dans les présentations de la Blackhat 2007, une m'a particulièrement frappé : l'arrivée des pirates au sein des logiciels « métier » des entreprises.

Plusieurs conférences et démonstrations observées à la Blackhat 2007 ont démontré l'intérêt nouveau que portent les chercheurs en sécurité pour le coeur des entreprises d'aujourd'hui : les bases de données et les logiciels métier.

Jusqu'alors, les recherches en sécurité visaient plutôt les serveurs frontaux, comme Apache ou Microsoft IIS, les réseaux et les firewalls, et bien sûr les systèmes d'exploitation.

Au milieu des conférences sur les vulnérabilités du RFID et de Vista, trois conférences ont attiré mon attention et très certainement celle des éditeurs de progiciels et des entreprises.
Ces trois conférences possédaient un point commun : la vulnérabilité des entreprises vis à vis de leur bases de données. Qu'il s'agisse de la facturation, de la paye, des commandes, du contrôle de gestion ou encore de la prospection, ces activités sont toutes extrêmement dépendantes de la disponibilité et de l'intégrité de l'ERP (Progiciel de gestion de l'entreprise) et donc du serveur bases de données.

Prises chacune indépendamment, ces trois conférences démontrent de nouvelles failles ou méthodes d'exploitation au sein des logiciels de bases de données. Mais mises bout à bout, ces trois conférences illustrent de nouvelles menaces pour les entreprises.

Advanced Exploitation of Oracle PL/SQL Flaws

Lors de cette session, David Litchfield de la société NGS Software, a exposé plusieurs exploitations de failles au sein des serveurs de base de données Oracle. David Litchfield, qui est à l'origine des toutes premières démonstrations d'attaques SQL au sein des bases de données Oracle, a démontré l'existence d'un problème de conception au sein du modèle de sécurité des procédures stockées Oracle : les procédures PL/SQL. Derrière cette appellation, se cache le langage de scripting propre aux serveurs Oracle.

Les failles présentées lors de cette session sont basées sur une faille du mécanisme de « curseur » au sein des procédures PL/SQL. Dans le langage PL/SQL, le curseur représente en quelques sortes un pointeur vers l'objet courant dans une boucle en PL/SQL, un peu comme le pointeur « this » en JAVA.

La faille de sécurité des procédures PL/SQL est due au fait que lorsqu'une procédure stockée PL/SQ est exécutée, celle-ci s'exécute avec les droits du propriétaire (celui qui a créé cette procédure). Pour être sécurisées, les procédures PL/SQL devraient plutôt s'exécuter avec les droits de l'utilisateur courant. Pour faire une analogie avec le monde Unix, les procédures PL/SQL d'Oracle possèdent de facto l'équivalent du «setuid bit ».

Pour pouvoir exploiter cette faille des procédures PL/SQL Oracle et donc obtenir un accès privilégié à la base de données, David Litchfield propose un système ingénieux : le pirate lance une procédure stockée avec des paramètres d'appel volontairement erronées dans le but de planter la procédure. Dès lors, la procédure se lance (avec les droits du propriétaire de la procédure, soit DBA) et s'arrête en erreur. Lorsqu'une procédure PL/SQL s'arrête ainsi, celle-ci ne referme pas le curseur courant. Or, ce curseur reste associé au propriétaire de la procédure plantée. C'est ici la seconde faille de sécurité des procédures PL/SQL.

La démonstration effectuée à la Blackhat Amsterdam montre alors comment un pirate peut réutiliser ce curseur resté ouvert et s'en resservir pour exécuter des commandes sur la base avec les droits associés à ce curseur orphelin.

David Litchfield a donc réalisé « en live » plusieurs techniques permettant à un utilisateur Oracle simple de prendre les droits de l'administrateur Oracle et donc accéder en lecteur/écriture à l'ensemble des données confidentielles et de modifier la configuration de la base.

Hacking Databases for Owning Your Data

Cette présentation, qui a suivi celle de David Litchfield, a dévoilé de façon étonnante comment il est possible d'utiliser les fonctionnalités avancées des bases de données Oracle pour en prendre le contrôle permanent.

Il est donc question ici d'un cheval de Troie pour les serveurs Oracle.

Avant d'exposer les principes de fonctionnement de cette backdoor, Cesar Cerruda de la société Argeniss, a présenté un listing précis du prix de revente d'un fichier : 0,5$ pour l'adresse de quelqu'un, 10 pour son numéro de téléphone, 8 pour son numéro de sécurité sociale et 35 pour le contenu du casier militaire. Autrement dit, les pirates vont de plus en plus se focaliser sur la pénétration et le maintien dans les bases de données.

L'exposé de Cesar Cerruda se concentre sur la présentation d'une backdoor pour Oracle. Bien que Cesar suggère plusieurs moyens pour pénétrer les bases Oracle, l'objectif est ici de démontrer que le langage PL/SQL d'Oracle peut être utilisé par un pirate pour créer un processus caché qui lui permettra par la suite de venir se servir à sa guise dans une base de données piratée.

La backdoor présentée utilise les jobs planifiés d'Oracle pour démarrer de façon automatique, et la fonction UTL_TCP.OPEN_CONNECTION de PL/SQL pour venir se connecter à la machine du pirate. Nous sommes donc bien en présence d'une backdoor de type « phone-home (Voir ActuSécu XMCO de Mars 2007) » : c'est le processus pirate qui établit la connexion depuis l'intérieur vers la machine du pirate. Les firewalls sont donc facilement contournés.

Lors de la présentation, Cesar Cerruda ne se contente pas de cette backdoor. Celui-ci présente également le rootkit permettant de cacher habilement la backdoor. Le mot « rootkit » désigne un moyen technique de cacher à l'administrateur d'un système la présence d'une backdoor.

La démonstration « live » de cette backdoor a été époustouflante : le pirate prend le contrôle de la base Oracle d'une plateforme 3-tiers : le pirate découvre une faille de type SQL sur une page web, utilise un exploit Oracle permettant d'élever ses privilèges (cela rappelle ici la présentation de David Litchfield ) et injecte via cette faille la backdoor au sein de la base Oracle. La backdoor vient ensuite se connecter à la machine du pirate.

Cesar finit sa démonstration en récupérant à distance l'ensemble de la base de données piratée avec même une compression zip pour optimiser le transfert !

Attacking the Giants : Exploiting SAP internals

Lors de cette présentation, Mariano Nunez Di Croce de la société CYBSEC, a présenté une série de vulnérabilités au sein du logiciel de gestion SAP R/3.

Les failles de sécurité qui ont été présentées sont toutes liées au protocole de communication utilisé par les serveurs SAP pour communiquer entre eux : le protocole RFC (Remote Function Call), l'équivalent du protocole MSRPC de Microsoft.

Pour débuter sa démonstration, Mariano présente les résultats du reverse engineering qu'il a dû effectuer à l'encontre du protocole RFC. Premier constat, le protocole n'est pas chiffré et les mots de passe sont simplement offusqués par l'algorithme XOR ( pour les spécialistes présents dans la salle, cette déclaration a beaucoup fait sourire).

La démonstration s'est alors concentrée sur le manque de sécurité du protocole lors de son implémentation : par défaut, la connexion RFC à un serveur SAP est laissée libre. Ce problème de configuration généralisé ouvre donc la porte à la démonstration d'attaque MITM (Man In The Middle) : l'attaquant se présente sur le réseau comme un serveur SAP externe, s'enregistre auprès du serveur SAP victime et réalise des appels RFC Call-backs. La démonstration se termine par la démonstration « live » d'utilisation d'une fonctionnalité non documentée des appels RFC de SAP : la fonction RFC_REMOTE_EXEC permettant de passer des commandes système à distance sur un serveur SAP.

Conclusion

Cette dernière présentation autour de la sécurité du logiciel SAP R/3 possède un point commun avec les deux autres : les installations SAP sont généralement implémentées sur la base de données Oracle.

De très nombreuses entreprises dans le monde ont basé leur gestion et leur comptabilité autour des logiciels SAP et ORACLE. Fait encore plus gênant, la criticité de ces logiciels pour l'activité des entreprises entraîne généralement une grande méfiance des administrateurs face aux mises à jour et aux migrations de version. Lors des nos audits de sécurité, nous rencontrons très souvent des bases Oracle avec des versions datant de plus de 5 ans et des configurations demeurées telles quelles après la livraison.

Les vulnérabilités présentées lors de la Blackhat 2007 risquent ainsi de rester d'actualité encore quelques années pour les entreprises.

Qui sommes-nous ?

La société XMCO Partners
Apparition d'Xmco Partners dans la presse
Notre magazine L'ActuSécu
Nos publications techniques