L’éditeur Apache a signalé en 9 décembre 2021 une faille de sécurité dans le composant logiciel de journalisation Log4J. L’exploitation de cette faille aboutit à une exécution de code arbitraire sur la machine vulnérable. En outre, Log4J est majoritairement utilisé par les applications développées en Java afin d’effectuer une journalisation. Ainsi, la vulnérabilité CVE-2021-44228, rebaptisée Log4Shell, semble apparaître comme une fragilité très dangereuse pour la pérennité des services web.
Linux : retour sur la faille de sécurité Pwnkit
À 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.
Sommaire
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.
D’autres articles de Vincent Fourcade, consultant SSI Digitemis
Cybercriminalité d’hier et d’aujourd’hui
Quelles étaient les prémices de ces guerres et crimes d’Internet ? Qui étaient les premières personnes à détourner l’outil pour leur usage ? Comment l’image du « nerd » adolescent dans son garage a laissé la place aux « cybersoldats » agissant dans l’ombre d’une organisation illégale ou au contraire dans le cadre de fonctions étatiques tout à fait légitime ? Mais surtout comment se protéger et faire évoluer nos méthodes de défense face à cette affliction ? Nous retraçons l’Histoire de la cybercriminalité, d’hier et d’aujourd’hui.
Je partage
Derniers articles
Renforcer la sécurité WordPress, du développement des plugins à la configuration serveur
Il y a peu, dans le cadre de recherches sur des plugins WordPress, notre pentester Vincent Fourcade a découvert une injection de code, côté client, dans un module du célèbre CMS. Celle-ci fut vérifiée et validée par les équipes de WPScan. Aujourd’hui, une CVE lui a été attribuée. L’occasion de revenir aujourd’hui sur la sécurité, au sens large, dans le CMS WordPress, que ce soit au niveau de la couche applicative, de la configuration du serveur ou du bureau. C’est parti !
Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client
Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?