Nexus — PoC d'élévation de privilèges locale

Traversée de chemin via la synchronisation de modèles Gitea avec des objets Git forgés → root

Un exploit de preuve de concept pour l'élévation de privilèges sur la machine HackTheBox Nexus. Un service systemd appartenant à root synchronise les dépôts de modèles Gitea sur le disque sans assainir les noms d'entrées, permettant à un utilisateur authentifié à faibles privilèges d'écrire des fichiers arbitraires en tant que root via une traversée de répertoire — utilisé ici pour implanter une clé SSH dans /root/.ssh/authorized_keys.

⚠️ Avertissement

Ce code est fourni à des fins éducatives et de tests de sécurité autorisés uniquement — c'est-à-dire des environnements de laboratoire tels que HackTheBox, ou des systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation écrite explicite de tester. L'utilisation non autorisée contre des systèmes que vous ne contrôlez pas est illégale. L'auteur décline toute responsabilité en cas de mauvaise utilisation.

Si la machine Nexus est encore active sur HackTheBox, ne publiez pas et ne partagez pas cet exploit — les règles de HTB interdisent la distribution de solutions pour des machines actives.

Résumé de la vulnérabilité

Le script de synchronisation lit les fichiers des dépôts marqués comme modèles dans Gitea et les écrit sur le système de fichiers local. Le chemin de destination est construit approximativement ainsi :

dest = os.path.join(base_dir, name)   # name comes straight from the Git tree
open(dest, "w").write(content)

os.path.join() ne neutralise pas les séquences ... Une entrée d'arbre dont le nom est un chemin de traversée (par ex. ../../../../../root/.ssh/authorized_keys) fait donc que le processus privilégié écrit en dehors du répertoire prévu.

Pourquoi des objets Git forgés ?

Git stocke le contenu et les noms séparément :

• un blob contient le contenu brut d'un fichier (sans nom) ;
• un tree associe nom → objet (c'est là que réside le nom de fichier) ;
• un commit pointe vers un arbre de niveau supérieur.

Le nom de fichier dans une entrée d'arbre n'est que du texte, il peut donc être .. — mais le client Git standard refuse de créer une telle entrée, précisément pour empêcher cette attaque.

Ce PoC contourne cette vérification côté client en écrivant des objets Git bruts directement dans .git/objects/ (en calculant les identifiants SHA-1 à la main) et en fabriquant refs/heads/main manuellement. Le dépôt poussé contient alors une entrée d'arbre nommée .., que le processus de synchronisation root résout et suit.

Chaîne d'attaque (contexte complet de la machine)

1. Point d'entrée — téléversement de fichier sans restriction dans Krayin CRM (CVE-2026-38526) → RCE en tant que www-data.
2. Mouvement latéral — identifiants en clair dans le .env de production, réutilisés comme mot de passe système → SSH en tant qu'utilisateur à faibles privilèges.
3. Élévation de privilèges — ce PoC → root.

Le thème récurrent à travers ces trois étapes : un processus privilégié faisant confiance à des données contrôlées par l'attaquant sans validation (un type MIME usurpé, un mot de passe réutilisé, un nom de fichier non assaini).

Prérequis

• Exécuter sur l'hôte cible, en tant qu'utilisateur authentifié à faibles privilèges.
• Gitea accessible à l'adresse http://localhost:3000.
• git, python3, curl et ssh disponibles (par défaut sur la machine).

Utilisation

chmod +x nexus_privesc.sh
./nexus_privesc.sh -t <TARGET_IP> -u <GITEA_USER> -p <GITEA_PASS> [-d DEPTH]

Exemple :

./nexus_privesc.sh -t 10.129.21.192 -u jones -p 'REDACTED' -d 5

Ce que fait le script

1. Génère une paire de clés SSH ed25519 (/tmp/.exploit_key).
2. Demande un jeton d'API Gitea via authentification basique.
3. Crée un dépôt et le marque comme modèle.
4. Forge des objets Git bruts encodant un arbre de traversée .. qui pointe vers /root/.ssh/authorized_keys, avec la clé publique de l'attaquant comme contenu.
5. Pousse le dépôt empoisonné.
6. Attend le minuteur de synchronisation appartenant à root (~60s).
7. Se connecte en tant que root avec la clé implantée.

Surveiller la synchronisation sur la cible avec :

tail -f /var/log/template-sync.log

Une exécution réussie journalise une ligne comme :

synced: ../../../../../root/.ssh/authorized_keys

Ajustement de DEPTH

DEPTH est le nombre de niveaux .. nécessaires pour remonter depuis le répertoire de synchronisation/staging jusqu'à la racine du système de fichiers (/). Si la synchronisation réussit dans le journal mais que le SSH root échoue, la traversée a atterri au mauvais niveau — réessayez avec -d 4 ou -d 6. La valeur exacte peut être confirmée en lisant le chemin de staging dans /etc/gitea/template-sync.py.

Remédiation

• Ne jamais construire de chemins de système de fichiers à partir de noms non fiables avec os.path.join() seul. Normalisez et confinez les chemins, par ex. :

  root@kitploit:~

  base = os.path.realpath(base_dir)
  dest = os.path.realpath(os.path.join(base, name))
  if not dest.startswith(base + os.sep):
      raise ValueError("path traversal blocked")
  

• Rejeter les noms d'entrées d'arbre contenant .., des chemins absolus ou des séparateurs de chemin.

• Exécuter le service de synchronisation sous un compte dédié à faibles privilèges, et non root.

• Activer receive.fsckObjects = true dans Gitea pour rejeter les objets poussés malformés.

Références

• CWE-22 — Improper Limitation of a Pathname to a Restricted Directory (Path Traversal)
• CVE-2026-38526 — Krayin CRM unrestricted file upload (foothold stage)
• Git internals — objects (blob / tree / commit): https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
• MITRE ATT&CK — T1068 Exploitation for Privilege Escalation

Auteur

<your name / handle> — for educational use on HackTheBox.