Après avoir construit le conteneur, nous pouvons accéder à Cacti en naviguant vers http://localhost:80. L'étape suivante consiste à mettre à jour Cacti vers la version 1.2.24. Vous pouvez télécharger le script de mise à jour ici : https://pastebin.com/NfRiHLjR. Enregistrez le fichier dans le même répertoire que le fichier docker-compose.yml et renommez-le en upgrade_cacti.sh. Exécutez ensuite ces 2 commandes :

Maintenant, nous sommes prêts à plonger dans le code pour voir ce qui nous permet de mener une attaque par injection SQL. Le fichier vulnérable est graph_view.php et nous avons seulement besoin d'un utilisateur invité pour accéder à ce fichier, ce qui permet à tout le monde d'exploiter cette vulnérabilité. Dans ce fichier, la fonction non sécurisée est grow_right_pane_tree().

Avant d'approfondir cette fonction, nous devons remonter pour comprendre comment elle est exécutée.

D'après l'extrait de code ci-dessus, nous pouvons voir que la fonction sera exécutée si $tree_id > 0. Toutes les étapes peuvent être expliquées comme ci-dessous :

• Tout d'abord, le programme prend la valeur du paramètre action de l'entrée utilisateur et entre dans une instruction switch/case.

• Dans le cas tree_content, le code prend le paramètre node de la requête de l'utilisateur. Ensuite, il divise l'entrée par le caractère -, l'enregistre dans $part et vérifie enfin si tree_anchor apparaît dans node. Si toutes les conditions correspondent, $tree_id sera assigné comme second élément dans $part. Par exemple, tree_content-1 ou 1-2-tree_content seront valides et la valeur de $tree_id sera respectivement.

À partir de là, notre URL ressemblera à ceci : http://localhost:80?action=tree_content&node=tree_anchor-1. Il est maintenant temps d'analyser la fonction grow_right_pane_tree() pour exploiter le bug.

Le paramètre vulnérable est rfilter qui est directement passé dans l'opérande RLIKE dans la clause WHERE. Ce qui le rend vulnérable, c'est que rfilter est entouré de guillemets doubles ", mais le paramètre est vérifié par la fonction html_validate_tree_vars(), qui ressemble à ceci :

Le type de filtre de rfilter est défini sur FILTER_VALIDATE_IS_REGEX et stocké dans $filters, puis $filter est passé dans la fonction validate_store_request_vars(). Plongeons dans cette fonction, cela révélera le reste de notre analyse :

La fonction validate_store_request_vars() est responsable de la validation des entrées utilisateur. Lorsque le type de filtre est FILTER_VALIDATE_IS_REGEX, la fonction appelle la fonction validate_is_regex() avec la fonction preg_match pour vérifier si notre entrée est valide. Selon la documentation PHP :

preg_match() retourne 1 si le pattern correspond au subject donné, 0 si ce n'est pas le cas, ou false en cas d'échec.

L'instruction if utilise une comparaison stricte, ce qui signifie que ce n'est que lorsqu'une erreur se produit que nous ne pouvons pas entrer dans l'instruction if. La variable $regex, qui est notre entrée, est entourée de deux guillemets simples '. L'intention des développeurs est d'éviter que l'utilisateur n'injecte le guillemet simple ', souvent utilisé pour lancer une attaque d'injection SQL. Cela semble être une implémentation de sécurité robuste, mais regardons une fois de plus comment rfilter est passé dans la clause WHERE :

Ah-oh, l'effort de validation de l'entrée utilisateur devient inutile car rfilter est entouré de guillemets doubles ", ce qui permet aux attaquants d'injecter facilement " pour sortir de l'instruction.

Ayant compris pourquoi c'est vulnérable, nous allons maintenant approfondir la requête dans laquelle $sql_where est passé.

Après l'assignation de $sql_where, le programme appelle la fonction get_allowed_tree_header_graphs(). La fonction ressemble à ceci :

C'est ici que $sql_where est passé dans une requête. Notez que la variable est assignée 2 fois de plus avant d'être passée, à savoir $sql_where = " AND ($sql_where)"; et $sql_where = "WHERE (gti.graph_tree_id=$tree_id AND gti.parent=$leaf_id)" . $sql_where;. Combiné avec la première assignation, voici comment $sql_where est finalement créé :

Après ces 3 assignations, $sql_where ressemblera à ceci :

La requête dans laquelle $sql_where est passé semble complexe, mais nous pouvons créer une autre requête simple avec une structure similaire :

select * from users WHERE (TRUE) AND ((username RLIKE "' get_request_var('rfilter') '" -- quelque chose derrière qui n'est pas nécessaire))

Pour injecter avec succès notre charge utile, nous devons sortir des " et des )). Par conséquent, cette charge utile pourrait fonctionner "));SELECT SLEEP(5) --. Notre charge utile ressemblera à ceci, select * from users WHERE (TRUE) AND **((username RLIKE "'"));SELECT SLEEP(5) --. Ça a l'air bien ! Essayons sur Cacti

La raison pour laquelle le serveur n'a pas attendu 2 secondes est que nous avons provoqué une erreur dans la fonction preg_match(). Regardons à nouveau la fonction

Cette fonction prend notre entrée comme expression régulière. Et ) est utilisé pour grouper un ensemble de caractères. Comme il n'est pas fermé, la fonction a retourné une erreur. D'un autre côté, si nous essayons "(());SELECT SLEEP(5) --, nous ne pouvons pas sortir des (( de la requête SQL. Cependant, il existe une astuce ici, et c'est "OR"(("));SELECT SLEEP(5) --. Laissez-moi expliquer, je mets (( entre guillemets doubles pour en faire une chaîne dans la requête SQL et j'utilise OR pour correspondre au username avant. Ensuite, le guillemet double " dans l'expression régulière est simplement considéré comme un caractère normal, c'est pourquoi nous pouvons profiter de cette fonctionnalité pour sortir de la requête SQL.

En fonction du temps de réponse, nous pouvons être sûrs d'avoir injecté avec succès du SQL dans la base de données. Il s'agit d'une vulnérabilité d'injection SQL critique. L'attaquant peut exploiter ce bug pour prendre le contrôle du compte administrateur ou même exécuter des commandes à distance.

Atténuation

Comme d'habitude, les vulnérabilités d'injection en général se produisent en raison de l'absence de validation des entrées. Cependant, dans ce cas, les développeurs ont appliqué des validations, mais de manière incorrecte. Pour corriger cela, nous devons simplement entourer le paramètre rfilter avec un guillemet simple ' au lieu d'un guillemet double "

Avec cette correction simple, l'effort de validation de l'entrée utilisateur fonctionnera désormais correctement. Essayons à nouveau la charge utile pour voir si c'est toujours vulnérable.

Avec la même charge utile, mais maintenant la réponse est très rapide, ce qui signifie que nous ne pouvons plus injecter de commande SQL.

De cette analyse de CVE, nous pouvons apprendre qu'une erreur mineure peut également entraîner des conséquences catastrophiques. Nous devons soigneusement revoir le code et tester fréquemment notre site pour le rendre de plus en plus sécurisé. Ceci est la fin de l'analyse, j'espère que vous avez appris quelque chose d'utile aujourd'hui. Bonne chasse !