BlogWonderHowTo

Cómo: usar un bit SUID mal configurado para escalar privilegios y obtener la raíz

Obtener acceso a un sistema siempre es emocionante, pero ¿a dónde se dirige a partir de ahí? Raíz o busto. Claro, un host comprometido es una excelente manera de ejecutar una botnet, o hacer alguna otra cosa aburrida y nefasta, pero como piratas informáticos, queremos root. También queremos tomar el camino más fácil posible, buscar fruta madura y explotarla. Los programas SUID son los más bajos de las frutas fáciles de conseguir.

En este artículo, usaremos el comando de búsqueda de Linux para buscar programas SUID (establecer identificación de usuario) para escalar nuestro nivel de privilegios. Un Poco SUID es un permiso especial en Linux que permite que un programa se ejecute como propietario del programa para todos los usuarios del sistema que tienen acceso a él. Es muy raro que el primer punto de acceso a un host sea un caparazón raíz, por lo que si le sucede a usted, es como ganar la lotería: aproveche el momento.

El escenario

Se nos ha dado acceso al sistema como usuario sin privilegios. ¿El reto? Obtener root de todos modos. Es una situación poco común y la vamos a aprovechar al máximo. En este caso, dado que el host es mi propia máquina virtual, me he dado un par de programas SUID para explotarlos con fines ilustrativos. ¡Empecemos!

Paso 1: localizar posibles programas SUID

Nuestro primer paso es localizar nuestros programas raíz SUID. Si esta búsqueda no arroja nada anormal, buscaría todos los programas SUID con la esperanza de comprometer a un usuario con un poco más de acceso. El comando para esto es:

  • buscar / -user root -perm -4000 -print 2> / dev / null

En un lenguaje sencillo, este comando dice que busque archivos en el directorio / propiedad del usuario root con bits de permiso SUID (-perma -4000), imprímalos y luego redirija todos los errores (2 = stderr) a / dev / null (donde se tiran). La razón de esta redirección es que no estamos interesados ​​en cosas a las que no podemos acceder, y los errores de acceso denegado pueden llenar un terminal bastante rápido.

En la lista anterior, tanto nmap como vim.basic son de particular interés. Las versiones anteriores de nmap permitían un modo interactivo y vim.basic es un editor de texto simple que también tiene un modo interactivo.

Ninguno de estos debería ser realmente raíz SUID. Existe un caso para nmap debido a que algunas funciones no funcionan, a menos que pueda crear paquetes sin procesar. No puedo pensar en un caso para vim.basic, pero solo porque no puedo pensar en uno no significa que alguien más en algún lugar no lo haya hecho. Como la mayoría de las configuraciones erróneas, esta probablemente se deba a la conveniencia. En algunas versiones de Linux que ejecutan nmap con SUID root en modo interactivo, permitirá al usuario escapar a un shell de root. Lo mismo ocurre con vim.basic.

Paso 2: Pruébelos

Primero está nmap. Empecemos en modo interactivo con el comando:

Después de iniciar nmap en modo interactivo, intentemos escapar a un shell usando el comando ! sh. El ! ejecuta un comando en primer plano y, en este caso, estamos intentando ejecutar sh.

Nmap se nos escapa a un shell, pero seguimos siendo un usuario sin privilegios. Si esto hubiera funcionado de la manera que he visto en algunos sistemas, tendríamos un shell de root. En este caso, no funcionó. La escalada de privilegios no siempre es corta y seca; A veces, las cosas que funcionan en un sistema no funcionan en otro. (Los piratas informáticos expertos pueden notar que esta versión de nmap está extremadamente desactualizada y es potencialmente una aplicación vulnerable).

A continuación, veamos vim.basic. Probé la misma técnica de escape de proyectiles que la anterior, pero sin dados. El sistema está generando el shell como nuestro usuario actual, al igual que lo hizo nmap. Si cualquiera de estos nos hubiera permitido escapar a un caparazón, habríamos terminado. Ahora necesitamos un poco de pensamiento lateral: vim.basic sigue siendo raíz SUID, así que tal vez haya una mejor manera de hacerlo.

Después de ejecutar! Sh en vim.basic.

Intentemos abrir un archivo privilegiado usando vim.basic, en este caso, / etc / sudoers. Este archivo contiene reglas para el comando sudo, qué usuarios pueden usar y con qué comandos pueden usarlo. El comando sudo permite a los usuarios ejecutar comandos como root.

¡Es un éxito! Ahora podemos recopilar información como root, y el potencial con solo esto es increíble. Pero todavía no tenemos un shell raíz. Desde aquí, hay muchas formas de avanzar y obtener acceso de root, como editar directamente el archivo sudoers para darnos acceso a nosotros mismos. Esto puede ser peligroso si no obtenemos la sintaxis correcta, porque el comando sudo podría dejar de funcionar por completo. Por lo general visudo, que incluye la verificación de sintaxis incorporada, se utiliza para editar el archivo sudoers.

Paso 3: obtenga una cáscara de raíz

Dado que no nos preocupa en absoluto cubrir nuestras pistas, y dado que esto es solo una máquina virtual, sigamos adelante y divirtámonos. Primero, editemos /root/.bashrc y dar acceso root a nuestro usuario:

Luego, en la parte inferior, agregue:

Desde .bashrc es ejecutado por bash al iniciar sesión, esto debería darnos acceso de root a través de sudo la próxima vez que root inicie sesión. Ahora necesitamos una razón para que root inicie sesión. Ya que no nos preocupa que nos descubran, optemos por una bomba de bifurcación:

Esta es solo una función bash simple que se llama a sí misma y luego canaliza la salida a otra llamada de la función sin fin. Efectivamente, hace que el sistema se bloquee. Eso debería reiniciar e iniciar sesión como root.

Después de que la máquina se bloqueó, seguí adelante, reinicié la VM e inicié sesión como root, lo que dio el mensaje “Añadiendo arimmer de usuario al grupo sudo”. Obviamente, esto es ruidoso y menos que ideal en una situación en la que no queremos que nos atrapen. Si bien hay formas más silenciosas, esta es rápida y podríamos haber omitido ese mensaje al redirigir la salida a / dev / null.

Ahora iniciemos sesión como arimmer y veamos qué sucede.

¡Perfecto! Si bien este ejemplo obviamente está configurado en una máquina virtual, es ilustrativo de los problemas con los comandos SUID. Puede parecer que este tipo de problema no surgiría en la naturaleza, pero he visto problemas similares y los aproveché para aumentar los privilegios. Cuando se trata de elevar los privilegios, es importante tener una gran cantidad de trucos. En algunos casos, puede ser así de fácil, en otros, es posible que deba ser un poco más complicado.

Por difícil que sea, es importante recordar que el primer objetivo es la fruta madura. Empiece siempre por los exploits más fáciles y vaya hasta los más difíciles. En este ejemplo, el comando nmap realmente no nos ayudó en absoluto. En lugar de seguir golpeándome la cabeza contra él, seguí adelante y, en este caso, valió la pena. Tomaré acceso de root completo desde el comando de búsqueda sobre la búsqueda de ExploitDB y trabajaré con pruebas de conceptos cualquier día.

Si alguien en la comunidad tiene otra dirección en la que hubiera tomado esto, me encantaría escucharlo.

Capturas de pantalla de Barrow / Null Byte

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba
Cerrar