J'achète ce magazine ! Version PapierVersion PDF

Avoir un aperçu | Commander le numéro

par Louis Nyffenegger

Quand on aime les injections SQL et que l'on développe des applications web avec Ruby-On-Rails, se réveiller un matin en lisant " SQL injections dans ActiveRecord " annonce une très bonne journée... Cet article va détailler comment il est possible d'exploiter cette vulnérabilité pour la base de données MySQL.

1. Introduction

1.1. ActiveRecord

Le cadriciel Ruby-On-Rails est composé de plusieurs bibliothèques afin de limiter la taille du code source. ActiveRecord est la bibliothèque dédiée à la gestion de la persistance (majoritairement le stockage dans une  base de données). Elle réalise le " mapping " entre les objets et la base de données et permet aux développeurs un accès facile aux données sans utilisation du langage SQL. Par exemple, il est possible de récupérer tous les objets de la table " users " grâce au code suivant :

L'avantage de ce type de bibliothèque est de limiter énormément le risque d'injection SQL vu qu'il devient difficile (mais encore possible) pour les développeurs de faire une erreur. Cependant, si cette bibliothèque s'avère vulnérable, c'est le drame... tout le monde est vulnérable.

1.2. La vulnérabilité

Cette vulnérabilité a été publiée le premier janvier 2012 et a été découverte par Ben Murphy. La vulnérabilité découle de la façon dont ActiveRecord gère les tables de hachage. Lors de la publication de CVE-2012-2661, aucune information sur l'exploitabilité de cette vulnérabilité n'a été fournie dans l'avis de vulnérabilité.

Lors de la découverte d'une vulnérabilité, les développeurs de Ruby-On-Rails fournissent un jeu de tests pour s'assurer que la vulnérabilité est correctement corrigée et qu'elle ne sera pas réintroduite dans le futur. Ce jeu de tests donne énormément d'informations et est probablement l'endroit où commencer à chercher.

1.3. Méthode de travail

Manipuler des tables de hachage avec HTTP peut vite se révéler très laborieux, c'est pourquoi il est préférable de jouer en local avec un shell Ruby (irb ou pry) afin d'obtenir plus d'informations. Puis, au moment où un exploit fonctionne correctement, il est possible de passer à une version utilisant le protocole HTTP.