Sécurité offensive
Gouvernance & conformité
Protection des données
À peine deux mois après la faille de sécurité Log4Shell atteignant une bibliothèque de journalisation développée en Java, une nouvelle annonce a provoqué un vent de panique au sein des équipes cyber. Une vulnérabilité affectant depuis douze ans diverses distributions Linux vient en effet d’être mise à jour. Cette dernière, si elle ne peut être exploitée sans accès à la machine, permet l’élévation des droits de n’importe quel utilisateur à root. Ainsi, étant donné sa gravité et sa présence depuis plus d’une dizaine d’années au sein des systèmes Linux, la faille CVE-2021-4034, communément appelée faille de sécurité Pwnkit, a de quoi inquiéter.
1. Polkit une vulnérabilité vieille de douze ans
C’est en novembre dernier que la société de sécurité Qualys découvre la possibilité, via la bibliothèque libre Polkit d’obtenir les droits root sur une machine Linux. La vulnérabilité est immédiatement signalée aux équipes techniques et, rapidement, des patchs de sécurité sont publiés par Redhat et Ubuntu.
Polkit, anciennement PolicyKit, permet aux applications exécutées via des droits restreints de communiquer avec des services privilégiés. Pour ce faire, la librairie utilise un programme nommé Pkexec. Ce dernier souffre d’une mauvaise gestion des arguments de la ligne de commande. En effet, comme expliqué sur le blog de Qualys, lors d’un appel au programme via execve(), si le nombre d’arguments de la ligne de commande (argc) est défini à zéro, il est alors possible d’écraser les valeurs envp[0], et ainsi définir de nouvelles variables d’environnements.
Ce comportement est présent sur les systèmes Linux embarquant Polkit depuis une douzaine d’années, faisant redouter des exploitations largement antérieures à la découverte de la vulnérabilité.
2. Faille de sécurité Pwnkit : preuve du concept
Bien que Qualys n’ait pas publié de preuve du concept, il n’aura pas fallu attendre longtemps avoir de voir fleurir ici et là des codes attestant de la facilité d’exploitation. Un simple programme en C d’une vingtaine de lignes publié par Arthepsy sur Github permet l’élévation de privilèges sans réelle connaissance technique. Bien qu’elle nécessite tout de même un accès préalable à la machine.
Le code ci-dessus procède à la création des répertoires et des éléments supplantant les variables d’environnements de execve(). L’auteur définit une fonction shell(), cette dernière est compilée dans une librairie partagée Pwnkit.so et celle-ci est par la suite appelée par pkexec comme variable d’environnement. En effet, lors de l’appel à la fonction execve(), le dépassement de mémoire inhérent à pkexec, viendra remplacer la valeur de envp[0] par le pointeur env dans le code :
La librairie pwnkit.so est alors exécutée et nous obtenons un shell en tant que root sur la machine.
La facilité d’exploitation d’une vulnérabilité aussi dangereuse nécessite sa correction de toute urgence.
3. Faille de sécurité Pwnkit : des patchs et des protections
Cyberark a publié sur son dépôt Github un script Python permettant de découvrir si son système est vulnérable à Pwnkit, fonctionnant pour l’instant uniquement sous Debian ou Ubuntu.
Les premiers correctifs ont été publiés pour Ubuntu, Debian Mint et Redhat. La mise à jour du système sous sa dernière version devrait corriger la vulnérabilité. Il est également possible de patcher directement Pkexec via le Gitlab officiel.
Il est également envisageable si les solutions précédentes ne sont pas applicables de procéder à une neutralisation de pkexec :
Cette commande modifie les droits en supprimant le bit SUID de pkexec, ce qui l’empêche de s’exécuter en tant que binaire. Il est également possible de rechercher au sein des logs des erreurs symptomatiques de l’exploitation de Pwnkit.
La recherche des termes suivants peut indiquer des tentatives d’exploitation.
« The value for the Shell variable was not found the /etc/shells file » or « The value for environment variable […] contains suspicious content. » Ce n’est pas la première fois que Polkit souffre d’une élévation de privilège : en juin 2021, une vulnérabilité équivalente appelée CVE-2021-3560 avait déjà été découverte au sein de la librairie.
4. Faille de sécurité Pwnkit : un code d’exploitation en PHP
Si les exemples d’exploitation sont rapidement apparus après publication de la vulnérabilité, la plupart ont été développés en langage C ou Python, partant du principe d’un accès direct sur la machine. Il peut être intéressant de voir s’il est possible d’adapter les charges virales développées en C au PHP. Dans le cadre d’une faille de type upload, l’exploitation s’en verrait facilitée.
Le but étant d’obtenir un reverse shell en tant que root sur la machine vulnérable. Pour ce faire, nous nous inspirons du travail effectué par Arthepsy, en l’adaptant à nos besoins.
5. Pwnkit : ne pas compiler sur le serveur
Afin de faciliter l’exploitation et obtenir notre accès même si gcc n’est pas accessible sur le serveur cible, nous allons compiler notre pwnkit.so (qui viendra écraser les valeurs d’environnements), et ensuite l’encoder en base 64. La donnée ainsi obtenue sera inscrite en dur dans notre charge en PHP puis réécrite sur le serveur. Nous adaptons le code pour obtenir un reverse shell.
L’adresse IP et le port définis sont ceux sur lesquels l’attaquant écoutera. Le reste du code procède de manière identique au travail d’Arthepsy, à la différence que nous ouvrons un socket au lieu d’exécuter /bin/sh sur la machine.
Nous compilons la charge, et l’encodons-en base64.
Enfin notre charge utile est inscrite dans le code PHP.
6. Pwnkit : pas de libc en PHP
S’il est envisageable sous Python d’embarquer la bibliothèque C via la fonction find_library, il est largement plus difficile d’obtenir un équivalent en PHP. De plus, l’équivalent d’execve() de PHP : pcntl_exec(), ne se comportant pas de la même manière que sa version en C, l’appel à pkexec via cette fonction ne provoquera pas le dépassement de mémoire souhaité.
Ainsi, à l’instar de Pwnkit.so il faudra embarquer un programme exécutant notre payload en C au sein de notre code PHP.
En définitive le code PHP ne sert que de vecteur aux charges développées en C, cependant il devient pratique lors d’un test d’intrusion, un seul code est téléversé et automatise l’exploitation de Pwnkit.
Nous procédons à l’écriture des dossiers et fichiers nécessaire pour l’écrasement des variables d’environnements, ainsi que nos deux programmes préalablement encodés en base 64.
Ci-dessous, la charge est décodée sous le nom pwnkit.so et le programme embarquant la fonction execve sous le nom « Execution ».
Enfin, nous appelons la fonction shell_exec() afin de lancer ce dernier.
Lors du test la charge utile est téléversée sur un serveur Apache exécuté sur une Debian.
L’attaquant se met en écoute avec netcat et appel le script PHP.
Enfin, afin d’automatiser un peu le principe de compilation et d’encodage en base 64, un script PHP est facilement réalisable, téléchargeable sur le Github de Digitemis.
Conclusion
Le début d’année 2022 est riche en vulnérabilités critiques : Pwnkit, Log4Shell mais aussi la CVE-2022-21907 (exécution de code à distance sur des systèmes Windows). Il est plus que nécessaire à l’heure actuelle où les attaques se multiplient de procéder aux mises à jour requises et à un état des lieux en matière de sécurité. Audits d’architecture, tests d’intrusion, Redteam selon vos besoins et votre maturité en matière de cybersécurité. Plusieurs types de contrôles sont possibles et peuvent vous épargner une attaque coûteuse en temps et en argent.