Linux Privilege Escalation
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)
Comencemos a obtener algo de conocimiento sobre el SO en ejecución.
Si tienes permisos de escritura en cualquier carpeta dentro de la variable PATH
es posible que puedas secuestrar algunas bibliotecas o binarios:
¿Información interesante, contraseñas o claves API en las variables de entorno?
Verifica la versión del kernel y si hay algún exploit que se pueda utilizar para escalar privilegios.
Puedes encontrar una buena lista de núcleos vulnerables y algunos compiled exploits aquí: https://github.com/lucyoa/kernel-exploits y exploitdb sploits. Otros sitios donde puedes encontrar algunos compiled exploits: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
Para extraer todas las versiones de núcleo vulnerables de esa web puedes hacer:
Las herramientas que podrían ayudar a buscar exploits del kernel son:
linux-exploit-suggester.sh linux-exploit-suggester2.pl linuxprivchecker.py (ejecutar EN la víctima, solo verifica exploits para el kernel 2.x)
Siempre busca la versión del kernel en Google, tal vez tu versión del kernel esté escrita en algún exploit del kernel y así estarás seguro de que este exploit es válido.
Escalación de privilegios en Linux - Kernel de Linux <= 3.19.0-73.8
Basado en las versiones vulnerables de sudo que aparecen en:
Puedes verificar si la versión de sudo es vulnerable usando este grep.
De @sickrov
Check smasher2 box of HTB for an ejemplo of how this vuln could be exploited
Si estás dentro de un contenedor de docker, puedes intentar escapar de él:
Docker SecurityVerifica qué está montado y desmontado, dónde y por qué. Si algo está desmontado, podrías intentar montarlo y buscar información privada.
Enumera binarios útiles
También, verifica si cualquier compilador está instalado. Esto es útil si necesitas usar algún exploit del kernel, ya que se recomienda compilarlo en la máquina donde lo vas a usar (o en una similar).
Verifique la versión de los paquetes y servicios instalados. Tal vez haya alguna versión antigua de Nagios (por ejemplo) que podría ser explotada para escalar privilegios... Se recomienda verificar manualmente la versión del software instalado más sospechoso.
Si tienes acceso SSH a la máquina, también podrías usar openVAS para verificar si hay software desactualizado y vulnerable instalado en la máquina.
Ten en cuenta que estos comandos mostrarán mucha información que en su mayoría será inútil, por lo tanto, se recomienda algunas aplicaciones como OpenVAS o similares que verificarán si alguna versión de software instalada es vulnerable a exploits conocidos
Echa un vistazo a qué procesos se están ejecutando y verifica si algún proceso tiene más privilegios de los que debería (¿quizás un tomcat ejecutado por root?)
Siempre verifica si hay posibles [depuradores de electron/cef/chromium] corriendo, podrías abusar de ello para escalar privilegios](electron-cef-chromium-debugger-abuse.md). Linpeas los detecta revisando el parámetro --inspect
dentro de la línea de comandos del proceso.
También verifica tus privilegios sobre los binarios de los procesos, tal vez puedas sobrescribir a alguien.
Puedes usar herramientas como pspy para monitorear procesos. Esto puede ser muy útil para identificar procesos vulnerables que se están ejecutando con frecuencia o cuando se cumplen un conjunto de requisitos.
Algunos servicios de un servidor guardan credenciales en texto claro dentro de la memoria. Normalmente necesitarás privilegios de root para leer la memoria de procesos que pertenecen a otros usuarios, por lo tanto, esto suele ser más útil cuando ya eres root y quieres descubrir más credenciales. Sin embargo, recuerda que como usuario regular puedes leer la memoria de los procesos que posees.
Ten en cuenta que hoy en día la mayoría de las máquinas no permiten ptrace por defecto, lo que significa que no puedes volcar otros procesos que pertenecen a tu usuario sin privilegios.
El archivo /proc/sys/kernel/yama/ptrace_scope controla la accesibilidad de ptrace:
kernel.yama.ptrace_scope = 0: todos los procesos pueden ser depurados, siempre que tengan el mismo uid. Esta es la forma clásica en que funcionaba el ptracing.
kernel.yama.ptrace_scope = 1: solo un proceso padre puede ser depurado.
kernel.yama.ptrace_scope = 2: solo el administrador puede usar ptrace, ya que requiere la capacidad CAP_SYS_PTRACE.
kernel.yama.ptrace_scope = 3: No se pueden rastrear procesos con ptrace. Una vez establecido, se necesita un reinicio para habilitar el ptracing nuevamente.
Si tienes acceso a la memoria de un servicio FTP (por ejemplo), podrías obtener el Heap y buscar dentro de sus credenciales.
Para un ID de proceso dado, maps muestra cómo se mapea la memoria dentro del espacio de direcciones virtuales de ese proceso; también muestra los permisos de cada región mapeada. El archivo pseudo mem expone la memoria de los procesos. A partir del archivo maps sabemos qué regiones de memoria son legibles y sus desplazamientos. Usamos esta información para buscar en el archivo mem y volcar todas las regiones legibles a un archivo.
/dev/mem
proporciona acceso a la memoria física del sistema, no a la memoria virtual. El espacio de direcciones virtual del kernel se puede acceder utilizando /dev/kmem.
Típicamente, /dev/mem
solo es legible por root y el grupo kmem.
ProcDump es una reinterpretación de Linux de la clásica herramienta ProcDump de la suite de herramientas Sysinternals para Windows. Consíguelo en https://github.com/Sysinternals/ProcDump-for-Linux
Para volcar la memoria de un proceso, podrías usar:
https://github.com/hajzer/bash-memory-dump (root) - _Puedes eliminar manualmente los requisitos de root y volcar el proceso que te pertenece
Script A.5 de https://www.delaat.net/rp/2016-2017/p97/report.pdf (se requiere root)
Si encuentras que el proceso del autenticador está en ejecución:
Puedes volcar el proceso (consulta las secciones anteriores para encontrar diferentes formas de volcar la memoria de un proceso) y buscar credenciales dentro de la memoria:
La herramienta https://github.com/huntergregal/mimipenguin robará credenciales en texto claro de la memoria y de algunos archivos bien conocidos. Requiere privilegios de root para funcionar correctamente.
Contraseña de GDM (Kali Desktop, Debian Desktop)
gdm-password
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop)
gnome-keyring-daemon
LightDM (Ubuntu Desktop)
lightdm
VSFTPd (Conexiones FTP Activas)
vsftpd
Apache2 (Sesiones Activas de Autenticación HTTP Básica)
apache2
OpenSSH (Sesiones SSH Activas - Uso de Sudo)
sshd:
Verifica si algún trabajo programado es vulnerable. Tal vez puedas aprovechar un script que está siendo ejecutado por root (¿vulnerabilidad de comodín? ¿puede modificar archivos que usa root? ¿usar enlaces simbólicos? ¿crear archivos específicos en el directorio que usa root?).
Por ejemplo, dentro de /etc/crontab puedes encontrar el PATH: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
(Nota cómo el usuario "user" tiene privilegios de escritura sobre /home/user)
Si dentro de este crontab el usuario root intenta ejecutar algún comando o script sin establecer el path. Por ejemplo: * * * * root overwrite.sh Entonces, puedes obtener un shell de root usando:
Si un script ejecutado por root tiene un “*” dentro de un comando, podrías explotar esto para hacer cosas inesperadas (como privesc). Ejemplo:
Si el comodín está precedido de una ruta como /some/path/* , no es vulnerable (incluso ./* no lo es).
Lee la siguiente página para más trucos de explotación de comodines:
Wildcards Spare tricksSi puedes modificar un script de cron ejecutado por root, puedes obtener un shell muy fácilmente:
Si el script ejecutado por root utiliza un directorio donde tienes acceso total, tal vez podría ser útil eliminar esa carpeta y crear un enlace simbólico a otra que sirva un script controlado por ti.
Puedes monitorear los procesos para buscar procesos que se están ejecutando cada 1, 2 o 5 minutos. Tal vez puedas aprovecharlo y escalar privilegios.
Por ejemplo, para monitorear cada 0.1s durante 1 minuto, ordenar por comandos menos ejecutados y eliminar los comandos que se han ejecutado más, puedes hacer:
También puedes usar pspy (esto monitoreará y listará cada proceso que inicie).
Es posible crear un cronjob poniendo un retorno de carro después de un comentario (sin carácter de nueva línea), y el trabajo cron funcionará. Ejemplo (nota el carácter de retorno de carro):
Verifica si puedes escribir en algún archivo .service
, si puedes, podrías modificarlo para que ejecute tu puerta trasera cuando el servicio sea iniciado, reiniciado o detenido (quizás necesites esperar hasta que la máquina se reinicie).
Por ejemplo, crea tu puerta trasera dentro del archivo .service con ExecStart=/tmp/script.sh
Ten en cuenta que si tienes permisos de escritura sobre los binarios que son ejecutados por los servicios, puedes cambiarlos por puertas traseras para que cuando los servicios se vuelvan a ejecutar, las puertas traseras sean ejecutadas.
Puedes ver el PATH utilizado por systemd con:
Si encuentras que puedes escribir en cualquiera de las carpetas de la ruta, es posible que puedas escalar privilegios. Necesitas buscar rutas relativas que se utilizan en los archivos de configuración de servicios como:
Luego, crea un ejecutable con el mismo nombre que el binario de la ruta relativa dentro de la carpeta PATH de systemd en la que puedes escribir, y cuando se le pida al servicio que ejecute la acción vulnerable (Iniciar, Detener, Recargar), tu puerta trasera se ejecutará (los usuarios sin privilegios generalmente no pueden iniciar/detener servicios, pero verifica si puedes usar sudo -l
).
Aprende más sobre servicios con man systemd.service
.
Temporizadores son archivos de unidad de systemd cuyo nombre termina en **.timer**
que controlan archivos o eventos **.service**
. Temporizadores se pueden usar como una alternativa a cron, ya que tienen soporte incorporado para eventos de tiempo calendario y eventos de tiempo monótono y se pueden ejecutar de forma asíncrona.
Puedes enumerar todos los temporizadores con:
Si puedes modificar un temporizador, puedes hacer que ejecute algunas instancias de systemd.unit (como un .service
o un .target
)
En la documentación puedes leer qué es la unidad:
La unidad a activar cuando se agote este temporizador. El argumento es un nombre de unidad, cuyo sufijo no es ".timer". Si no se especifica, este valor predeterminado es un servicio que tiene el mismo nombre que la unidad del temporizador, excepto por el sufijo. (Ver arriba.) Se recomienda que el nombre de la unidad que se activa y el nombre de la unidad del temporizador tengan nombres idénticos, excepto por el sufijo.
Por lo tanto, para abusar de este permiso necesitarías:
Encontrar alguna unidad systemd (como un .service
) que esté ejecutando un binario escribible
Encontrar alguna unidad systemd que esté ejecutando una ruta relativa y que tengas privilegios de escritura sobre el PATH de systemd (para suplantar ese ejecutable)
Aprende más sobre temporizadores con man systemd.timer
.
Para habilitar un temporizador necesitas privilegios de root y ejecutar:
Note que el temporizador está activado al crear un symlink a él en /etc/systemd/system/<WantedBy_section>.wants/<name>.timer
Los Sockets de Dominio Unix (UDS) permiten la comunicación entre procesos en las mismas o diferentes máquinas dentro de modelos cliente-servidor. Utilizan archivos de descriptor estándar de Unix para la comunicación entre computadoras y se configuran a través de archivos .socket
.
Los sockets se pueden configurar utilizando archivos .socket
.
Aprende más sobre sockets con man systemd.socket
. Dentro de este archivo, se pueden configurar varios parámetros interesantes:
ListenStream
, ListenDatagram
, ListenSequentialPacket
, ListenFIFO
, ListenSpecial
, ListenNetlink
, ListenMessageQueue
, ListenUSBFunction
: Estas opciones son diferentes, pero se utiliza un resumen para indicar dónde va a escuchar el socket (la ruta del archivo de socket AF_UNIX, la dirección IPv4/6 y/o el número de puerto a escuchar, etc.)
Accept
: Toma un argumento booleano. Si es true, se crea una instancia de servicio para cada conexión entrante y solo se pasa el socket de conexión a ella. Si es false, todos los sockets de escucha se pasan a la unidad de servicio iniciada, y solo se crea una unidad de servicio para todas las conexiones. Este valor se ignora para sockets de datagramas y FIFOs donde una sola unidad de servicio maneja incondicionalmente todo el tráfico entrante. Por defecto es false. Por razones de rendimiento, se recomienda escribir nuevos demonios solo de una manera que sea adecuada para Accept=no
.
ExecStartPre
, ExecStartPost
: Toma una o más líneas de comando, que se ejecutan antes o después de que los sockets/FIFOs de escucha sean creados y vinculados, respectivamente. El primer token de la línea de comando debe ser un nombre de archivo absoluto, seguido de argumentos para el proceso.
ExecStopPre
, ExecStopPost
: Comandos adicionales que se ejecutan antes o después de que los sockets/FIFOs de escucha sean cerrados y eliminados, respectivamente.
Service
: Especifica el nombre de la unidad de servicio a activar en el tráfico entrante. Esta configuración solo se permite para sockets con Accept=no. Por defecto, se utiliza el servicio que lleva el mismo nombre que el socket (con el sufijo reemplazado). En la mayoría de los casos, no debería ser necesario usar esta opción.
Si encuentras un archivo .socket
escribible, puedes agregar al principio de la sección [Socket]
algo como: ExecStartPre=/home/kali/sys/backdoor
y la puerta trasera se ejecutará antes de que se cree el socket. Por lo tanto, probablemente necesitarás esperar hasta que la máquina se reinicie.
&#xNAN;Note que el sistema debe estar utilizando esa configuración de archivo socket o la puerta trasera no se ejecutará
Si identificas algún socket escribible (ahora estamos hablando de Sockets Unix y no de los archivos de configuración .socket
), entonces puedes comunicarte con ese socket y tal vez explotar una vulnerabilidad.
Ejemplo de explotación:
Socket Command InjectionTenga en cuenta que puede haber algunos sockets escuchando solicitudes HTTP (no estoy hablando de archivos .socket, sino de los archivos que actúan como sockets unix). Puede verificar esto con:
Si el socket responde con una solicitud HTTP, entonces puedes comunicarte con él y tal vez explotar alguna vulnerabilidad.
El socket de Docker, que a menudo se encuentra en /var/run/docker.sock
, es un archivo crítico que debe ser asegurado. Por defecto, es escribible por el usuario root
y los miembros del grupo docker
. Poseer acceso de escritura a este socket puede llevar a la escalada de privilegios. Aquí hay un desglose de cómo se puede hacer esto y métodos alternativos si la CLI de Docker no está disponible.
Si tienes acceso de escritura al socket de Docker, puedes escalar privilegios utilizando los siguientes comandos:
Estos comandos te permiten ejecutar un contenedor con acceso a nivel de root al sistema de archivos del host.
En casos donde la CLI de Docker no está disponible, el socket de Docker aún puede ser manipulado usando la API de Docker y comandos curl
.
Listar Imágenes de Docker: Recupera la lista de imágenes disponibles.
Crear un Contenedor: Envía una solicitud para crear un contenedor que monta el directorio raíz del sistema host.
Inicia el contenedor recién creado:
Conectar al Contenedor: Usa socat
para establecer una conexión con el contenedor, habilitando la ejecución de comandos dentro de él.
Después de configurar la conexión socat
, puedes ejecutar comandos directamente en el contenedor con acceso a nivel de root al sistema de archivos del host.
Ten en cuenta que si tienes permisos de escritura sobre el socket de docker porque estás dentro del grupo docker
tienes más formas de escalar privilegios. Si la API de docker está escuchando en un puerto también puedes comprometerla.
Consulta más formas de salir de docker o abusar de él para escalar privilegios en:
Docker SecuritySi descubres que puedes usar el comando ctr
, lee la siguiente página ya que puedes ser capaz de abusar de él para escalar privilegios:
Si descubres que puedes usar el comando runc
, lee la siguiente página ya que puedes ser capaz de abusar de él para escalar privilegios:
D-Bus es un sofisticado sistema de Comunicación entre Procesos (IPC) que permite a las aplicaciones interactuar y compartir datos de manera eficiente. Diseñado con el sistema Linux moderno en mente, ofrece un marco robusto para diferentes formas de comunicación entre aplicaciones.
El sistema es versátil, soportando IPC básico que mejora el intercambio de datos entre procesos, reminiscentes de sockets de dominio UNIX mejorados. Además, ayuda a transmitir eventos o señales, fomentando una integración fluida entre los componentes del sistema. Por ejemplo, una señal de un demonio Bluetooth sobre una llamada entrante puede hacer que un reproductor de música se silencie, mejorando la experiencia del usuario. Además, D-Bus soporta un sistema de objetos remotos, simplificando las solicitudes de servicio y las invocaciones de métodos entre aplicaciones, agilizando procesos que tradicionalmente eran complejos.
D-Bus opera bajo un modelo de permitir/negar, gestionando los permisos de mensajes (llamadas a métodos, emisiones de señales, etc.) basados en el efecto acumulativo de las reglas de política que coinciden. Estas políticas especifican interacciones con el bus, permitiendo potencialmente la escalación de privilegios a través de la explotación de estos permisos.
Se proporciona un ejemplo de tal política en /etc/dbus-1/system.d/wpa_supplicant.conf
, detallando los permisos para que el usuario root posea, envíe y reciba mensajes de fi.w1.wpa_supplicant1
.
Las políticas sin un usuario o grupo especificado se aplican de manera universal, mientras que las políticas de contexto "predeterminadas" se aplican a todos los que no están cubiertos por otras políticas específicas.
Aprende cómo enumerar y explotar una comunicación D-Bus aquí:
D-Bus Enumeration & Command Injection Privilege EscalationSiempre es interesante enumerar la red y averiguar la posición de la máquina.
Siempre verifica los servicios de red que se están ejecutando en la máquina con la que no pudiste interactuar antes de acceder a ella:
Verifica si puedes esnifar tráfico. Si puedes, podrías ser capaz de obtener algunas credenciales.
Verifica quién eres, qué privilegios tienes, qué usuarios están en los sistemas, cuáles pueden iniciar sesión y cuáles tienen privilegios de root:
Algunas versiones de Linux fueron afectadas por un error que permite a los usuarios con UID > INT_MAX escalar privilegios. Más información: aquí, aquí y aquí.
Explotarlo usando: systemd-run -t /bin/bash
Verifica si eres miembro de algún grupo que podría otorgarte privilegios de root:
Interesting Groups - Linux PrivescVerifica si hay algo interesante ubicado dentro del portapapeles (si es posible)
Si conoces alguna contraseña del entorno intenta iniciar sesión como cada usuario usando la contraseña.
Si no te importa hacer mucho ruido y los binarios su
y timeout
están presentes en la computadora, puedes intentar forzar la entrada de usuarios usando su-bruteforce.
Linpeas con el parámetro -a
también intenta forzar la entrada de usuarios.
Si encuentras que puedes escribir dentro de alguna carpeta del $PATH podrías ser capaz de escalar privilegios creando una puerta trasera dentro de la carpeta escribible con el nombre de algún comando que va a ser ejecutado por un usuario diferente (idealmente root) y que no se carga desde una carpeta que esté ubicada antes de tu carpeta escribible en $PATH.
Podrías tener permiso para ejecutar algún comando usando sudo o podrían tener el bit suid. Verifícalo usando:
Algunos comandos inesperados te permiten leer y/o escribir archivos o incluso ejecutar un comando. Por ejemplo:
La configuración de Sudo podría permitir a un usuario ejecutar algún comando con los privilegios de otro usuario sin conocer la contraseña.
En este ejemplo, el usuario demo
puede ejecutar vim
como root
, ahora es trivial obtener un shell añadiendo una clave ssh en el directorio raíz o llamando a sh
.
Esta directiva permite al usuario establecer una variable de entorno mientras ejecuta algo:
Este ejemplo, basado en la máquina HTB Admirer, era vulnerable a PYTHONPATH hijacking para cargar una biblioteca de python arbitraria mientras se ejecutaba el script como root:
Saltar para leer otros archivos o usar symlinks. Por ejemplo, en el archivo sudoers: hacker10 ALL= (root) /bin/less /var/log/*
Si se utiliza un wildcard (*), es aún más fácil:
Contramedidas: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/
Si se otorgan permisos sudo a un solo comando sin especificar la ruta: hacker10 ALL= (root) less puedes explotarlo cambiando la variable PATH.
Esta técnica también se puede utilizar si un suid binario ejecuta otro comando sin especificar la ruta a este (siempre verifica con strings el contenido de un extraño binario SUID).
Ejemplos de payloads para ejecutar.
Si el suid binario ejecuta otro comando especificando la ruta, entonces, puedes intentar exportar una función llamada como el comando que el archivo suid está llamando.
Por ejemplo, si un binario suid llama a /usr/sbin/service apache2 start tienes que intentar crear la función y exportarla:
Luego, cuando llamas al binario suid, esta función se ejecutará
La variable de entorno LD_PRELOAD se utiliza para especificar una o más bibliotecas compartidas (.so files) que serán cargadas por el cargador antes que todas las demás, incluida la biblioteca estándar de C (libc.so
). Este proceso se conoce como precarga de una biblioteca.
Sin embargo, para mantener la seguridad del sistema y prevenir que esta función sea explotada, particularmente con ejecutables suid/sgid, el sistema impone ciertas condiciones:
El cargador ignora LD_PRELOAD para ejecutables donde el ID de usuario real (ruid) no coincide con el ID de usuario efectivo (euid).
Para ejecutables con suid/sgid, solo se precargan bibliotecas en rutas estándar que también son suid/sgid.
La escalada de privilegios puede ocurrir si tienes la capacidad de ejecutar comandos con sudo
y la salida de sudo -l
incluye la declaración env_keep+=LD_PRELOAD. Esta configuración permite que la variable de entorno LD_PRELOAD persista y sea reconocida incluso cuando se ejecutan comandos con sudo
, lo que potencialmente lleva a la ejecución de código arbitrario con privilegios elevados.
Guarda como /tmp/pe.c
Luego compílalo usando:
Finalmente, escalar privilegios ejecutando
Un privesc similar puede ser abusado si el atacante controla la variable de entorno LD_LIBRARY_PATH porque controla la ruta donde se buscarán las bibliotecas.
Cuando se encuentra un binario con permisos SUID que parece inusual, es una buena práctica verificar si está cargando archivos .so correctamente. Esto se puede comprobar ejecutando el siguiente comando:
Por ejemplo, encontrar un error como "open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)" sugiere un potencial de explotación.
Para explotar esto, uno procedería creando un archivo C, digamos "/path/to/.config/libcalc.c", que contenga el siguiente código:
Este código, una vez compilado y ejecutado, tiene como objetivo elevar privilegios manipulando permisos de archivos y ejecutando un shell con privilegios elevados.
Compila el archivo C anterior en un archivo de objeto compartido (.so) con:
Finalmente, ejecutar el binario SUID afectado debería activar la explotación, permitiendo una posible compromisión del sistema.
Ahora que hemos encontrado un binario SUID que carga una biblioteca de una carpeta donde podemos escribir, vamos a crear la biblioteca en esa carpeta con el nombre necesario:
Si obtienes un error como
eso significa que la biblioteca que has generado necesita tener una función llamada a_function_name
.
GTFOBins es una lista curada de binarios de Unix que pueden ser explotados por un atacante para eludir las restricciones de seguridad locales. GTFOArgs es lo mismo pero para casos donde solo puedes inyectar argumentos en un comando.
El proyecto recopila funciones legítimas de binarios de Unix que pueden ser abusadas para salir de shells restringidos, escalar o mantener privilegios elevados, transferir archivos, generar shells bind y reverse, y facilitar otras tareas de post-explotación.
gdb -nx -ex '!sh' -ex quit sudo mysql -e '! /bin/sh' strace -o /dev/null /bin/sh sudo awk 'BEGIN {system("/bin/sh")}'
Si puedes acceder a sudo -l
, puedes usar la herramienta FallOfSudo para verificar si encuentra cómo explotar alguna regla de sudo.
En casos donde tienes acceso a sudo pero no la contraseña, puedes escalar privilegios esperando a que se ejecute un comando sudo y luego secuestrando el token de sesión.
Requisitos para escalar privilegios:
Ya tienes un shell como usuario "sampleuser"
"sampleuser" ha usado sudo
para ejecutar algo en los últimos 15 minutos (por defecto, esa es la duración del token de sudo que nos permite usar sudo
sin introducir ninguna contraseña)
cat /proc/sys/kernel/yama/ptrace_scope
es 0
gdb
es accesible (puedes ser capaz de subirlo)
(Puedes habilitar temporalmente ptrace_scope
con echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
o modificar permanentemente /etc/sysctl.d/10-ptrace.conf
y establecer kernel.yama.ptrace_scope = 0
)
Si se cumplen todos estos requisitos, puedes escalar privilegios usando: https://github.com/nongiach/sudo_inject
El primer exploit (exploit.sh
) creará el binario activate_sudo_token
en /tmp. Puedes usarlo para activar el token de sudo en tu sesión (no obtendrás automáticamente un shell root, haz sudo su
):
El segundo exploit (exploit_v2.sh
) creará un shell sh en /tmp propiedad de root con setuid
El tercer exploit (exploit_v3.sh
) creará un archivo sudoers que hace que los tokens de sudo sean eternos y permite a todos los usuarios usar sudo
Si tienes permisos de escritura en la carpeta o en cualquiera de los archivos creados dentro de la carpeta, puedes usar el binario write_sudo_token para crear un token de sudo para un usuario y PID. Por ejemplo, si puedes sobrescribir el archivo /var/run/sudo/ts/sampleuser y tienes una shell como ese usuario con PID 1234, puedes obtener privilegios de sudo sin necesidad de conocer la contraseña haciendo:
El archivo /etc/sudoers
y los archivos dentro de /etc/sudoers.d
configuran quién puede usar sudo
y cómo. Estos archivos por defecto solo pueden ser leídos por el usuario root y el grupo root.
Si puedes leer este archivo podrías ser capaz de obtener información interesante, y si puedes escribir cualquier archivo podrás escalar privilegios.
Si puedes escribir, puedes abusar de este permiso.
Otra forma de abusar de estos permisos:
Hay algunas alternativas al binario sudo
, como doas
para OpenBSD, recuerda verificar su configuración en /etc/doas.conf
Si sabes que un usuario generalmente se conecta a una máquina y usa sudo
para escalar privilegios y tienes una shell dentro de ese contexto de usuario, puedes crear un nuevo ejecutable de sudo que ejecutará tu código como root y luego el comando del usuario. Luego, modifica el $PATH del contexto del usuario (por ejemplo, añadiendo la nueva ruta en .bash_profile) para que cuando el usuario ejecute sudo, tu ejecutable de sudo se ejecute.
Ten en cuenta que si el usuario utiliza una shell diferente (no bash) necesitarás modificar otros archivos para añadir la nueva ruta. Por ejemplo, sudo-piggyback modifica ~/.bashrc
, ~/.zshrc
, ~/.bash_profile
. Puedes encontrar otro ejemplo en bashdoor.py
O ejecutando algo como:
El archivo /etc/ld.so.conf
indica de dónde provienen los archivos de configuración cargados. Típicamente, este archivo contiene la siguiente ruta: include /etc/ld.so.conf.d/*.conf
Eso significa que se leerán los archivos de configuración de /etc/ld.so.conf.d/*.conf
. Estos archivos de configuración apuntan a otras carpetas donde se van a buscar bibliotecas. Por ejemplo, el contenido de /etc/ld.so.conf.d/libc.conf
es /usr/local/lib
. Esto significa que el sistema buscará bibliotecas dentro de /usr/local/lib
.
Si por alguna razón un usuario tiene permisos de escritura en cualquiera de las rutas indicadas: /etc/ld.so.conf
, /etc/ld.so.conf.d/
, cualquier archivo dentro de /etc/ld.so.conf.d/
o cualquier carpeta dentro del archivo de configuración en /etc/ld.so.conf.d/*.conf
, puede ser capaz de escalar privilegios.
Echa un vistazo a cómo explotar esta mala configuración en la siguiente página:
Al copiar la lib en /var/tmp/flag15/
, será utilizada por el programa en este lugar como se especifica en la variable RPATH
.
Luego crea una biblioteca maliciosa en /var/tmp
con gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6
Las capacidades de Linux proporcionan un subconjunto de los privilegios de root disponibles a un proceso. Esto efectivamente divide los privilegios de root en unidades más pequeñas y distintivas. Cada una de estas unidades puede ser otorgada de manera independiente a los procesos. De esta manera, el conjunto completo de privilegios se reduce, disminuyendo los riesgos de explotación. Lee la siguiente página para aprender más sobre las capacidades y cómo abusar de ellas:
Linux CapabilitiesEn un directorio, el bit de "ejecutar" implica que el usuario afectado puede "cd" en la carpeta. El bit de "lectura" implica que el usuario puede listar los archivos, y el bit de "escritura" implica que el usuario puede eliminar y crear nuevos archivos.
Las Listas de Control de Acceso (ACLs) representan la capa secundaria de permisos discrecionales, capaces de anular los permisos tradicionales ugo/rwx. Estos permisos mejoran el control sobre el acceso a archivos o directorios al permitir o denegar derechos a usuarios específicos que no son los propietarios o parte del grupo. Este nivel de granularidad asegura una gestión de acceso más precisa. Más detalles se pueden encontrar aquí.
Otorgar al usuario "kali" permisos de lectura y escritura sobre un archivo:
Obtener archivos con ACLs específicas del sistema:
En versiones antiguas puedes secuestrar algunas sesiones de shell de un usuario diferente (root). En versiones más recientes solo podrás conectarte a las sesiones de pantalla de tu propio usuario. Sin embargo, podrías encontrar información interesante dentro de la sesión.
Listar sesiones de pantalla
Adjuntar a una sesión
Este era un problema con versiones antiguas de tmux. No pude secuestrar una sesión de tmux (v2.1) creada por root como un usuario no privilegiado.
Listar sesiones tmux
Adjuntar a una sesión
Check Valentine box from HTB for an example.
Todas las claves SSL y SSH generadas en sistemas basados en Debian (Ubuntu, Kubuntu, etc.) entre septiembre de 2006 y el 13 de mayo de 2008 pueden verse afectadas por este error. Este error se produce al crear una nueva clave ssh en esos sistemas operativos, ya que solo se podían generar 32,768 variaciones. Esto significa que todas las posibilidades pueden ser calculadas y teniendo la clave pública ssh puedes buscar la clave privada correspondiente. Puedes encontrar las posibilidades calculadas aquí: https://github.com/g0tmi1k/debian-ssh
PasswordAuthentication: Especifica si se permite la autenticación por contraseña. El valor predeterminado es no
.
PubkeyAuthentication: Especifica si se permite la autenticación por clave pública. El valor predeterminado es yes
.
PermitEmptyPasswords: Cuando se permite la autenticación por contraseña, especifica si el servidor permite el inicio de sesión en cuentas con cadenas de contraseña vacías. El valor predeterminado es no
.
Especifica si root puede iniciar sesión usando ssh, el valor predeterminado es no
. Valores posibles:
yes
: root puede iniciar sesión usando contraseña y clave privada
without-password
o prohibit-password
: root solo puede iniciar sesión con una clave privada
forced-commands-only
: Root solo puede iniciar sesión usando clave privada y si se especifican las opciones de comandos
no
: no
Especifica archivos que contienen las claves públicas que se pueden usar para la autenticación de usuarios. Puede contener tokens como %h
, que serán reemplazados por el directorio home. Puedes indicar rutas absolutas (comenzando en /
) o rutas relativas desde el home del usuario. Por ejemplo:
Esa configuración indicará que si intentas iniciar sesión con la clave privada del usuario "testusername", ssh va a comparar la clave pública de tu clave con las que se encuentran en /home/testusername/.ssh/authorized_keys
y /home/testusername/access
El reenvío del agente SSH te permite usar tus claves SSH locales en lugar de dejar claves (¡sin frases de contraseña!) en tu servidor. Así, podrás saltar a través de ssh a un host y desde allí saltar a otro host usando la clave ubicada en tu host inicial.
Necesitas establecer esta opción en $HOME/.ssh.config
así:
Notice that if Host
is *
every time the user jumps to a different machine, that host will be able to access the keys (which is a security issue).
El archivo /etc/ssh_config
puede anular estas opciones y permitir o denegar esta configuración.
El archivo /etc/sshd_config
puede permitir o denegar el reenvío de ssh-agent con la palabra clave AllowAgentForwarding
(el valor predeterminado es permitir).
If you find that Forward Agent is configured in an environment read the following page as you may be able to abuse it to escalate privileges:
SSH Forward Agent exploitationEl archivo /etc/profile
y los archivos bajo /etc/profile.d/
son scripts que se ejecutan cuando un usuario inicia un nuevo shell. Por lo tanto, si puedes escribir o modificar cualquiera de ellos, puedes escalar privilegios.
Si se encuentra algún script de perfil extraño, debes revisarlo en busca de detalles sensibles.
Dependiendo del sistema operativo, los archivos /etc/passwd
y /etc/shadow
pueden tener un nombre diferente o puede haber una copia de seguridad. Por lo tanto, se recomienda encontrar todos ellos y verificar si puedes leerlos para ver si hay hashes dentro de los archivos:
En algunas ocasiones puedes encontrar password hashes dentro del archivo /etc/passwd
(o equivalente)
Primero, genera una contraseña con uno de los siguientes comandos.
Luego agrega el usuario hacker
y añade la contraseña generada.
E.g: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash
Ahora puedes usar el comando su
con hacker:hacker
Alternativamente, puedes usar las siguientes líneas para agregar un usuario ficticio sin contraseña. ADVERTENCIA: podrías degradar la seguridad actual de la máquina.
NOTE: En plataformas BSD, /etc/passwd
se encuentra en /etc/pwd.db
y /etc/master.passwd
, además, /etc/shadow
se renombra a /etc/spwd.db
.
Deberías verificar si puedes escribir en algunos archivos sensibles. Por ejemplo, ¿puedes escribir en algún archivo de configuración de servicio?
Por ejemplo, si la máquina está ejecutando un servidor tomcat y puedes modificar el archivo de configuración del servicio Tomcat dentro de /etc/systemd/, entonces puedes modificar las líneas:
Tu puerta trasera se ejecutará la próxima vez que se inicie tomcat.
Las siguientes carpetas pueden contener copias de seguridad o información interesante: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Probablemente no podrás leer la última, pero inténtalo)
Lee el código de linPEAS, busca varios archivos posibles que podrían contener contraseñas. Otra herramienta interesante que puedes usar para hacerlo es: LaZagne, que es una aplicación de código abierto utilizada para recuperar muchas contraseñas almacenadas en una computadora local para Windows, Linux y Mac.
Si puedes leer registros, es posible que puedas encontrar información interesante/confidencial dentro de ellos. Cuanto más extraño sea el registro, más interesante será (probablemente). Además, algunos registros de auditoría "mal" configurados (¿con puerta trasera?) pueden permitirte grabar contraseñas dentro de los registros de auditoría como se explica en esta publicación: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.
Para leer los registros el grupo adm será realmente útil.
También debes buscar archivos que contengan la palabra "password" en su nombre o dentro del contenido, y también verificar IPs y correos electrónicos dentro de los registros, o expresiones regulares de hashes. No voy a enumerar aquí cómo hacer todo esto, pero si estás interesado, puedes revisar los últimos chequeos que linpeas realiza.
Si sabes de dónde se va a ejecutar un script de python y puedes escribir dentro de esa carpeta o modificar bibliotecas de python, puedes modificar la biblioteca OS y ponerle un backdoor (si puedes escribir donde se va a ejecutar el script de python, copia y pega la biblioteca os.py).
Para poner un backdoor en la biblioteca, simplemente agrega al final de la biblioteca os.py la siguiente línea (cambia IP y PUERTO):
Una vulnerabilidad en logrotate
permite a los usuarios con permisos de escritura en un archivo de registro o sus directorios padre potencialmente obtener privilegios elevados. Esto se debe a que logrotate
, que a menudo se ejecuta como root, puede ser manipulado para ejecutar archivos arbitrarios, especialmente en directorios como /etc/bash_completion.d/. Es importante verificar los permisos no solo en /var/log sino también en cualquier directorio donde se aplique la rotación de registros.
Esta vulnerabilidad afecta a la versión 3.18.0
de logrotate
y versiones anteriores.
Más información detallada sobre la vulnerabilidad se puede encontrar en esta página: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.
Puedes explotar esta vulnerabilidad con logrotten.
Esta vulnerabilidad es muy similar a CVE-2016-1247 (registros de nginx), así que cada vez que encuentres que puedes alterar registros, verifica quién está gestionando esos registros y comprueba si puedes escalar privilegios sustituyendo los registros por enlaces simbólicos.
Referencia de vulnerabilidad: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
Si, por cualquier motivo, un usuario puede escribir un script ifcf-<cualquier cosa>
en /etc/sysconfig/network-scripts o puede ajustar uno existente, entonces tu sistema está comprometido.
Los scripts de red, ifcg-eth0 por ejemplo, se utilizan para conexiones de red. Se ven exactamente como archivos .INI. Sin embargo, son ~sourced~ en Linux por Network Manager (dispatcher.d).
En mi caso, el atributo NAME=
en estos scripts de red no se maneja correctamente. Si tienes espacios en blanco en el nombre, el sistema intenta ejecutar la parte después del espacio en blanco. Esto significa que todo lo que esté después del primer espacio en blanco se ejecuta como root.
Por ejemplo: /etc/sysconfig/network-scripts/ifcfg-1337
El directorio /etc/init.d
es el hogar de scripts para System V init (SysVinit), el sistema clásico de gestión de servicios de Linux. Incluye scripts para iniciar
, detener
, reiniciar
y a veces recargar
servicios. Estos pueden ejecutarse directamente o a través de enlaces simbólicos encontrados en /etc/rc?.d/
. Un camino alternativo en sistemas Redhat es /etc/rc.d/init.d
.
Por otro lado, /etc/init
está asociado con Upstart, una gestión de servicios más nueva introducida por Ubuntu, utilizando archivos de configuración para tareas de gestión de servicios. A pesar de la transición a Upstart, los scripts de SysVinit todavía se utilizan junto con las configuraciones de Upstart debido a una capa de compatibilidad en Upstart.
systemd surge como un moderno gestor de inicialización y servicios, ofreciendo características avanzadas como el inicio de demonios bajo demanda, gestión de automontaje y instantáneas del estado del sistema. Organiza archivos en /usr/lib/systemd/
para paquetes de distribución y /etc/systemd/system/
para modificaciones de administradores, agilizando el proceso de administración del sistema.
LinEnum: https://github.com/rebootuser/LinEnum(opción -t) Enumy: https://github.com/luke-goddard/enumy Unix Privesc Check: http://pentestmonkey.net/tools/audit/unix-privesc-check Linux Priv Checker: www.securitysift.com/download/linuxprivchecker.py BeeRoot: https://github.com/AlessandroZ/BeRoot/tree/master/Linux Kernelpop: Enumera vulnerabilidades del kernel en linux y MAC https://github.com/spencerdodd/kernelpop Mestaploit: multi/recon/local_exploit_suggester Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester EvilAbigail (acceso físico): https://github.com/GDSSecurity/EvilAbigail Recopilación de más scripts: https://github.com/1N3/PrivEsc
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)