LinPEAS versus IA: Cómo usar un Copilot para escalar privilegios en GNU/Linux

• Tenemos una máquina con dos configuraciones diferentes.

• En la primera configuración, tenemos dos errores que provocarán la escalada de privilegio. Partiendo de un usuario, por ejemplo, ‘pepito’ el cual no es un sudoer, ni tiene privilegio de nada en el sistema. Deberemos pasar al usuario ‘pablo’, el cual sí es un sudoer. Posteriormente, deberemos pasar a root.

• En la segunda configuración pasaremos del usuario ‘pablo’ a root, pero ¿Qué técnicas deberemos utilizar en cada una de las configuraciones?

• El objetivo del ejercicio es ver cómo LinPEAS nos ayuda y cómo un modelo de IA fundacional (y mejor si está especializado en este campo) nos pueden guiar. Incluso, podemos utilizar herramientas clásicas y comprenderlas mejor con el modelo de IA.

Escenario 1: LinPEAS from scratch

En este escenario partimos de que tenemos una shell remota, la cual se puede haber obtenido a través de una explotación remotamente. Ahora, identificamos privilegios en el sistema y se ve que el usuario no pertenece a ningún grupo con privilegio en el sistema. Todo esto, realmente, lo va a poder realizar LinPEAS, por lo que voy a lanzar LinPEAS en el sistema. 

Una de las primeras cosas que se enseña que hay que revisar en la escalada son las versiones de las aplicaciones con privilegio, revisar los hotfix instalados y revisar versiones de kernel. Como se puede ver en la imagen, LinPEAS hace uso de una enumeración y análisis para poder identificar posibles vulnerabilidades. Para ello hace uso de Linux Exploit Suggester (hay que recordar también su versión en Windows, llamada Windows Exploit Suggester) y muestra una serie de resultados de la posibilidad de que haya encontrado un vector de explotación.

La salida es muy larga, por lo que no se puede mostrar todo (recomendado probarlo en vuestro laboratorio). Siguiendo hacia abajo se puede encontrar una serie de datos interesantes: son ficheros relacionados con SSH. Una clave pública (y la privada también estaba en el sistema), el fichero de equipos conocidos (es decir, las máquinas a las que se ha conectado el usuario ‘pepito’ (o nopriv) y el fichero de claves autorizadas.

En este caso, se puede ver un dato curioso el valor de authorized_keys del usuario ‘pablo’ es el mismo que el de la clave pública del usuario ‘pepito’. No nos lo dice LinPEAS, pero se puede relacionar viendo el valor de los ficheros. Esto quiere decir que, muy probablemente, el usuario ‘pepito’ puede hacer login como usuario ‘pablo’ a través del uso de clave pública (y la clave privada se encuentra en el home de ‘pepito’.

Justamente, si seguimos un poco más abajo en la salida de LinPEAS encontramos esto. En efecto, la clave privada se encuentra disponible. El pentester podría llevarse la clave privada a su equipo e intentar acceder como el usuario ‘pablo’ (sin conocer la credencial de éste, ya que la autenticación se realizará por clave pública).

En un movimiento un tanto extraño, se puede identificar que el usuario ‘pepito’ (o nopriv en la máquina) puede autenticarse como el usuario ‘pablo’. ¿Será algún tipo de escalada? También LinPEAS nos vuelva toda la información de usuarios y grupos y se puede ver que ‘pablo’ es un usuario de tipo sudoer, por lo que respecto al usuario ‘pepito’ sí hay una escalada (sin llegar a ser root).

Figura 9: Libro de Ethical Hacking 2ª Edición de Pablo González en 0xWord

Una vez que somos ‘pablo’ a través de una conexión local de SSH (como decía un tanto raro) hay que seguir analizando con LinPEAS. La herramienta marca que el usuario pablo pertenece al grupo sudo. Esto hace pensar que habrá que configurar la configuración de éste.

En la revisión de la configuración de sudo se puede encontrar la etiqueta NOPASSWD, algo no recomendado de configurar. Se puede ejecutar como sudo y sin contraseña 3 scripts. Esto, a priori, puede no suponer mucho, habrá que estudiar si se puede hacer algo con esos scripts.

Por un lado, la etiqueta NOPASSWD sobre 3 scripts y después, LinPEAS, indica que el script /usr/local/bin/echo.sh tiene permisos de escritura para otros usuarios, es decir, podremos modificar el contenido de dicho fichero (o sobrescribirlo completamente). A partir de aquí, se puede ejecutar como sudo y colocando, por ejemplo, una llamada de netcat desde el propio script a un listener que tengamos nosotros y conseguir ser root. 

Analizando en la siguiente configuración con LinPEAS podemos encontrar algunas cosas interesantes: el bit SUID activo sobre algún binario que no debiera, tareas programadas con permisos débiles, un posible path hijacking, etcétera. LinPEAS nos da mucha información y proporciona un gran número de chequeos, los cuales hay que podar y quedarse con la información de interés.

En la imagen, se puede la evaluación del bit SUID y como se encuentra un binario interesante. Por otro lado, se recomienda utilizar el proyecto GTFOBins con el que se puede obtener mucha información de los binarios y de los vectores de escalada que se pueden utilizar.

Otro punto débil es el cron. Tareas ejecutadas cada minuto como root. Hay que revisar el fichero /deploy.sh.

Escenario 2: El modelo como ayudante de pentester

Ahora, el segundo escenario consiste en dos cosas:

• Evaluar la información que recopila LinPEAS y mostrar las capacidades de un modelo como copiloto.

• Ir desgranando el proceso paso a paso e ir ayudándote del modelo con pequeños trozos de información.

Éstas serían las dos primeras aproximaciones que se pueden llevar a cabo. Para empezar, volcaremos la información sobre el modelo (todo lo que ha recopilado LinPEAS) y le diremos que analice y que nos diga que encuentra. La verdad es que devuelve mucha información. Hay que fijarse que en el punto 4 (de los 10 que nos saca) nos habla de las claves SSH (siempre son un punto a tener en cuenta). De momento es una aproximación y el modelo da algunas pautas y un análisis un poco más superficial de lo que se ha ido encontrando con LinPEAS.

Ahora, le pedimos que haga un análisis del componente de las claves SSH y ficheros relacionados. El resultado nos indica que la clave pública id_rsa.pub y authorized_keys son idénticas y nos sugiere que la clave pública permite al usuario ‘pepito’ (en la máquina usuario ‘nopriv’) autenticarse en el sistema como usuario ‘pablo’ sin necesidad de contraseña. El análisis es correcto por parte del modelo.

También se realiza un análisis de la seguridad de las claves utilizadas en la máquina. Y por último, nos indica el modelo que si la clave privada id_rsa está comprometida (y lo está, ya que tenemos acceso) se puede utilizar para autenticarse en el mismo sistema, por SSH, como el usuario ‘pablo’.

Este es un buen ejemplo de lo que es un copiloto o ayudante en ciberseguridad y en este caso en pentesting. Ahora, se le indica al modelo que analice toda la salida generada por LinPEAS y el resultado nos indica muchas cosas:

5.- Aquí está de nuevo el caso de las claves SSH y los ficheros relacionados. Lo explica de nuevo bastante claro, aunque este caso, quizá lo explicó mejor cuando le preguntamos concretamente sobre ello.

Esto es el contexto híbrido. Trabajo como especialista y me ayudo de un ayudante que la IA me proporciona. Importante, hay que tener en cuenta que en muchos campos será necesario utilizar modelos locales que aporten privacidad a los datos manejados. Esto será fundamental, para que los copilotos y ayudantes estén en el día a día de los profesionales de la ciberseguridad. Esto es solo un ejemplo, de lo que puede ayudarnos un modelo, donde no pretendemos que nos haga todo, si no que nos de puntos de vista y ayude en lo que pueda.

Moraleja