silasspringer/cve-2018-10933Challenge CTF exploitant CVE-2018-10933 contournement d'authentification libSSH. Comprend configuration Docker, script d'exploitation et guide pas à pas pour découvrir des flags cachés via des liens symboliques.
Basé sur CVE-2018-10933
CVE-2018-10933 est une vulnérabilité découverte dans certaines versions de libSSH, qui peut permettre un accès potentiellement illimité à la machine. La vulnérabilité provient d'une gestion incorrecte des en-têtes de paquets pendant le processus d'authentification, où l'envoi d'un paquet contrefait avec l'octet MSG_USERAUTH_SUCCESS peut permettre à quiconque de contourner l'authentification. Ils ont alors un accès complet à la machine.
La base de ce défi est donc d'obliger les concurrents à fouiner dans l'image docker fournie, découvrir cette vulnérabilité, l'exploiter pour obtenir un accès, puis trouver la clé cachée dans un lien symbolique sur la machine.
Someone got into my machine via port 22...
It looks like they didnt even know my credentials.
Anyways, they made a file with an odd name, but it's gone now,
I wonder if there's still some trace of the filename -
it might be something symbolic of the attacker...
Can you figure out how they got in and help me find the filename?
Ce qui suit est une procédure détaillée de la solution prévue :
Remarquez, d'après la description du défi, que l'attaquant a obtenu un accès via le port 22, un port généralement réservé à SSH. Remarquez également que l'attaquant n'a pas utilisé d'identifiants pour obtenir l'accès.
À partir de là, si vous recherchez les bugs passés permettant d'accéder à une machine via SSH sans identifiants, le problème avec l'octet MSG_USERAUTH_SUCCESS est très probable. Alternativement, en initiant une connexion au port 22, on peut déterminer la version de libSSH qui est exécutée, puis chercher les exploits courants pour cette version.
On peut également voir dans la description que le nom de fichier qu'ils cherchent à trouver (le flag) n'existe que comme cible d'un lien symbolique.
Sachant maintenant que l'accès peut être obtenu en exploitant cette vulnérabilité, on peut écrire son propre script ou copier un exemple de script qui exécute cet exploit, et lancer une commande sur la machine cible. J'ai adapté un script d'exploitation pour cette solution, et je l'ai appelé libsshauthbypass.py.
Pour exécuter ce script et obtenir le flag de la machine, dans le cas de l'image de démonstration, on peut lancer une commande similaire à la suivante :
./libsshauthbypass.py --host localhost -p 1337 -c 'find / -type l -exec stat {} + | grep "File:" | sed -E "s/.*\-> (.*)$/\1/g" | grep "definitelyarealCTF"'
ce qui donne alors une sortie similaire à
sspringer-fedora-CVE: ./libsshauthbypass.py --host localhost -p 1337 -c 'find / -type l -exec stat {} + | grep "File:" | sed -E "s/.*\-> (.*)$/\1/g" | grep "definitelyarealCTF"'
INFO:paramiko.transport:Connected (version 2.0, client libssh_0.8.1)
definitelyarealCTF{totally_a_REAL_flag}
Pour utiliser une version de ce défi pour votre propre CTF, il est fortement recommandé de modifier le Dockerfile pour utiliser un chemin différent de celui fourni par défaut, de changer le flag dans flag.txt (bien qu'il doive toujours être sur une seule ligne), puis de reconstruire l'image. Notez qu'il peut être nécessaire d'héberger un nouveau conteneur pour chaque tentative de connexion afin d'empêcher quelqu'un d'exécuter une commande destructive et d'affecter tous les concurrents.
Pour reconstruire l'image docker avec un nouveau flag (et le tester)
flag.txt avec le nouveau flag./build_run <nom de l'image>[:<numéro de version] <numéro de port>./libsshauthbypass.py ou votre propre script pour contacter le conteneur avec la charge utile correcte et une commande que vous souhaitez exécuterexit) le shell fourni par le script build_run, le conteneur sera arrêté et supprimé, mais l'image restera et sera étiquetée comme <nom de l'image>Preuve de Concept : https://youtu.be/ELrOBm02ANg
Procédure du défi : https://youtu.be/Ii121piSZR0