Puedes ver las tres partes anteriores de este post aquí:
Enumeración en Linux para Post-Explotación – Parte 1.
Enumeración en Linux para Post-Explotación – Parte 2.
Enumeración en Linux para Post-Explotación – Parte 3.

Aunque los siguientes puntos se han mencionado en los posts anteriores, se ha hecho de una forma un tanto superficial y dado que son detalles importantes para llevar a cabo un proceso de elevación de privilegios “en condiciones”, en esta parte de la serie se hablará sobre vulnerabilidades en el kernel, ficheros con el SUID habilitado y capabilities en Linux.

En primer lugar, es bien sabido que el kernel de Linux ha presentado vulnerabilidades muy graves a lo largo de su historia, las cuales han permitido que atacantes locales consigan la ejecución de instrucciones con privilegios de root. Encontrar una versión desactualizada del kernel no siempre significa que dicho sistema sea vulnerable ya que se puede encontrar parcheado, pero existe una posibilidad que una de las tantas vulnerabilidades reportadas en sitios como exploit-db, Security Focus o CVE-Details desemboque en la tan anhelada elevación de privilegios. Como resulta evidente, una de las primeras cosas que hay que consultar es la versión del sistema operativo y partiendo de dicha información buscar las vulnerabilidades existentes. Una alternativa para realizar este proceso consiste en utilizar el repositorio oficial de Exploit-DB y ejecutar la herramienta “searchsploit” que se encuentra disponible en dicho repositorio. La ventaja de hacerlo de esta manera es que no hace falta buscar los exploits en la página web de Exploit-DB y se tienen todas las pruebas de concepto y exploits localmente en la máquina del atacante. En un sistema Kali Linux ya viene incluido, sin embargo en cualquier otro sistema basado en Linux es tan sencillo como clonar el repositorio y ejecutar la herramienta.

En la mayoría de los casos hay que seguir un proceso de “prueba y error” partiendo de la información obtenida del sistema comprometido. Cada exploit tiene sus características propias y condiciones de funcionamiento, evidentemente no solo es requisito fundamental que la versión del kernel sea el “target” del exploit sino que además es necesario que las condiciones requeridas se cumplan.

Cuando un binario se ejecuta en el sistema lo hace con los privilegios que tenga asignados la cuenta de usuario que invoca dicho binario pero en ocasiones, se necesitan permisos adicionales que no dispone esa cuenta y que son requeridos para la correcta ejecución el programa. Este es un caso en el que pueden entrar en juego los binarios con el SUID/GUID habilitado, de tal manera que cuando se ejecutan lo hacen con los privilegios del propietario del binario. Evidentemente, si hay alguna vulnerabilidad en ese binario que le permita a un atacante local ejecutar código, estas instrucciones también se ejecutarán con los permisos del propietario de dicho binario con lo cual, esta se convierte en una vía valida para elevación de privilegios horizontal o vertical.

En la imagen anterior se puede comprobar que hay binario con el SUID habilitado y además, dicho intenta ejecutar un comando llamado “apache2” que no se encuentra incluido en el PATH. Esto significa que simplemente alterando la variable de entorno PATH e incluyendo un directorio en el que se encontrará un ejecutable con nombre “apache2” será suficiente para lanzar las instrucciones maliciosas con los privilegios del propietario de ese binario “suideado”, que en este caso es root.

El uso de ficheros con SUID/GUID o programas como SUDO permiten ejecutar comandos que requieren cierto nivel de privilegios sin necesidad de asignar un grupo o convertir en administrador al usuario que los ejecuta. Sin embargo en algunos casos este no suele ser un buen enfoque ya que existen programas que solamente necesitan permisos concretos para realizar ciertas operaciones (utilizar una interfaz de red o dispositivo en el sistema, abrir un puerto por debajo del 1024, leer ficheros concretos, hacer modificaciones en el sistema, etc.) y dado que estos mecanismos suelen ser de “todo o nada” no siempre son la mejor solución. Especialmente en el caso de los SUIDs, ya que al menos con SUDO se puede afinar bastante qué comandos puede ejecutar el usuario como administrador. Ahora bien, desde la versión 2.2.11 del Kernel de Linux se han introducido las capabilities, las cuales representan un potente mecanismo para la gestión granular de permisos sobre ficheros. Cada capability otorga un permiso concreto y nada más, lo que significa que la superficie de ataque se ve reducida al asignar únicamente los permisos que el binario necesita, evitando la situación del “todo o nada”. No obstante, debido a malas prácticas de administración o por configuraciones inseguras que se aplican en un momento determinado un binario puede tener asignadas capabilities que pueden producir una elevación de privilegios.

En la imagen anterior se puede apreciar que hay varios binarios que tienen la capability “CAP_SETUID”, la cual tal como se indica en la documentación oficial permite realizar manipulaciones arbitrarias del UID efectivo con el que se ejecuta el binario. Como se enseña en la imagen anterior, utilizando “python3.5” con dicha capability habilitada se puede generar una reverse shell. Esto evidentemente ha sido preparado así para efectos demostrativos, pero en la práctica esta situación se encontrará en muy raras ocasiones, especialmente si es un entorno maduro o con unas políticas de seguridad mínimas (y no un CTF). Como siempre, es una de las tantas cuestiones que se deben comprobar y que no requiere mucho esfuerzo. Puede ocurrir que algún binario en el sistema tenga alguna capability asignada y permita fugas de información o en el peor de los casos la elevación de privilegios.

En el próximo post se explicarán otros detalles a tener en cuenta durante la enumeración en sistemas Linux.

Un saludo y Happy Hack!
Adastra.