Interesting Groups - Linux Privesc
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
A veces, por defecto (o porque algún software lo necesita) dentro del /etc/sudoers archivo puedes encontrar algunas de estas líneas:
Esto significa que cualquier usuario que pertenezca al grupo sudo o admin puede ejecutar cualquier cosa como sudo.
Si este es el caso, para convertirse en root solo puedes ejecutar:
Encuentra todos los binarios suid y verifica si hay el binario Pkexec:
Si encuentras que el binario pkexec es un binario SUID y perteneces a sudo o admin, probablemente podrías ejecutar binarios como sudo usando pkexec.
Esto se debe a que típicamente esos son los grupos dentro de la política de polkit. Esta política identifica básicamente qué grupos pueden usar pkexec. Verifícalo con:
Ahí encontrarás qué grupos tienen permiso para ejecutar pkexec y por defecto en algunas distribuciones de linux aparecen los grupos sudo y admin.
Para convertirte en root puedes ejecutar:
Si intentas ejecutar pkexec y obtienes este error:
No es porque no tengas permisos, sino porque no estás conectado sin una GUI. Y hay una solución para este problema aquí: https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903. Necesitas 2 sesiones ssh diferentes:
A veces, por defecto dentro del archivo /etc/sudoers puedes encontrar esta línea:
Esto significa que cualquier usuario que pertenezca al grupo wheel puede ejecutar cualquier cosa como sudo.
Si este es el caso, para convertirse en root solo puedes ejecutar:
Los usuarios del grupo shadow pueden leer el /etc/shadow archivo:
Así que, lee el archivo y trata de crackear algunos hashes.
staff: Permite a los usuarios agregar modificaciones locales al sistema (/usr/local) sin necesidad de privilegios de root (ten en cuenta que los ejecutables en /usr/local/bin están en la variable PATH de cualquier usuario, y pueden "sobrescribir" los ejecutables en /bin y /usr/bin con el mismo nombre). Compara con el grupo "adm", que está más relacionado con la monitorización/seguridad. [source]
En las distribuciones de debian, la variable $PATH muestra que /usr/local/ se ejecutará con la máxima prioridad, ya seas un usuario privilegiado o no.
Si podemos secuestrar algunos programas en /usr/local, podemos obtener fácilmente acceso root.
Secuestrar el programa run-parts es una forma fácil de obtener acceso root, porque la mayoría de los programas ejecutarán un run-parts como (crontab, cuando se inicia sesión por ssh).
o Cuando se inicia una nueva sesión de inicio de ssh.
Explotar
Este privilegio es casi equivalente al acceso root ya que puedes acceder a todos los datos dentro de la máquina.
Archivos: /dev/sd[a-z][1-9]
Nota que usando debugfs también puedes escribir archivos. Por ejemplo, para copiar /tmp/asd1.txt a /tmp/asd2.txt puedes hacer:
Sin embargo, si intentas escribir archivos propiedad de root (como /etc/shadow o /etc/passwd) recibirás un error de "Permiso denegado".
Usando el comando w puedes encontrar quién está conectado al sistema y mostrará una salida como la siguiente:
El tty1 significa que el usuario yossi está conectado físicamente a un terminal en la máquina.
El grupo de video tiene acceso para ver la salida de la pantalla. Básicamente, puedes observar las pantallas. Para hacer eso, necesitas capturar la imagen actual en la pantalla en datos en bruto y obtener la resolución que está utilizando la pantalla. Los datos de la pantalla se pueden guardar en /dev/fb0 y podrías encontrar la resolución de esta pantalla en /sys/class/graphics/fb0/virtual_size
Para abrir la imagen en bruto puedes usar GIMP, seleccionar el **screen.raw ** archivo y seleccionar como tipo de archivo Datos de imagen en bruto:
Luego modifica el Ancho y Alto a los que se usaron en la pantalla y verifica diferentes Tipos de Imagen (y selecciona el que muestre mejor la pantalla):
Parece que por defecto los miembros del grupo root podrían tener acceso a modificar algunos archivos de configuración de servicios o algunos archivos de bibliotecas o otras cosas interesantes que podrían ser utilizadas para escalar privilegios...
Verifica qué archivos pueden modificar los miembros de root:
Puedes montar el sistema de archivos raíz de la máquina host en el volumen de una instancia, de modo que cuando la instancia se inicie, carga inmediatamente un chroot en ese volumen. Esto te da efectivamente acceso root en la máquina.
Finalmente, si no te gustan ninguna de las sugerencias anteriores, o no están funcionando por alguna razón (¿firewall de la API de docker?), siempre podrías intentar ejecutar un contenedor privilegiado y escapar de él como se explica aquí:
Docker SecuritySi tienes permisos de escritura sobre el socket de docker, lee esta publicación sobre cómo escalar privilegios abusando del socket de docker.
Por lo general, los miembros del grupo adm tienen permisos para leer archivos de registro ubicados dentro de /var/log/.
Por lo tanto, si has comprometido a un usuario dentro de este grupo, definitivamente deberías echar un vistazo a los registros.
Dentro de OpenBSD, el grupo auth generalmente puede escribir en las carpetas /etc/skey y /var/db/yubikey si se utilizan. Estos permisos pueden ser abusados con el siguiente exploit para escalar privilegios a root: https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
