Continuando con los detalles básicos que se deben recolectar en un proceso de post-explotación en sistemas Linux, en este artículo se hablará de algunas otras cuestiones que hay que tener en cuenta para extraer información útil.

Una practica habitual una vez se consigue acceso al sistema es comprobar la cuenta con la que se está operando y cuál es su nivel de acceso. Además de esto se puede consultar qué usuarios se encuentran conectados al sistema y si lo están usando en ese momento. Es interesante ver qué hay en el directorio “/home” suponiendo que exista y ver los permisos que tiene habilitados.

Por otro lado, también es habitual ejecutar una búsqueda global el todo el sistema para encontrar ficheros de configuración, scripts o programas que tienen contraseñas “hardcodeadas”. En ocasiones las credenciales descubiertas en estos sitios pueden ser decisivas a la hora de elevar privilegios en el sistema.

Los permisos que se asignan a un fichero o directorio pueden afectar la forma en la que se comportan las utilidades disponibles en el sistema o restringir accesos. Así es como se ha diseñado el sistema y está bien, sin embargo es posible que debido a malas configuraciones por parte de un usuario se asignen permisos demasiado abiertos a ficheros o directorios con información sensible, algo que posteriormente puede ser aprovechado por un atacante en post-explotación. De hecho, es una situación bastante común ya que en ocasiones, por descuido o para probar rápidamente el funcionamiento de una herramienta, se asignan permisos como “777” o “755” a ficheros o directorios y luego se olvida asignar nuevamente unas restricciones de acceso más seguras.

Por otro lado, en sistemas Linux además de los permisos comunes de lectura, escritura y ejecución, existen otras características para la gestión de permisos como pueden ser los permisos especiales SUID/GUID, las ACLs y las capabilities. Cualquier fichero ejecutable con estas características habilitadas puede representar una forma de elevar privilegios, en la recolección de información hay que tenerlos identificados para luego verificar si efectivamente pueden ser útiles para este propósito.

Los servicios o “daemons” en sistemas Linux representan otra posible forma de elevar privilegios en el sistema. Pueden haber servicios que se ejecutan localmente y que tienen contraseñas por defecto/predecibles, ficheros de configuración o directorios con permisos débiles, versiones con vulnerabilidades conocidas o simplemente con configuraciones descuidadas. Este tipo de problemas también entran en el “checklist” de pruebas que hacen parte de cualquier proceso de post-explotación. Se deben comprobar las siguientes cosas como mínimo:

• Listado de conexiones de red (TCP y UDP) así como detectar qué servicios se encuentran activos
• Listado los binarios vinculados a los servicios y permisos asociados.
• Listado de binarios en unidades SystemD o “init.d”

• Versiones de servicios comunes, como por ejemplo MySQL, PostgreSQL, Apache HTTPD, SSHD, Tomcat, etc.
• Acceso a los ficheros de configuración de los servicios.
• Acceso a los ficheros de log de los servicios
• Listado de módulos, librerías o Shared Objects que utilizan los servicios.

La enumeración completa de cada servicio puede aportar información muy valiosa en el proceso de post-explotación y como resulta evidente, es un proceso que lleva tiempo y hay que hacerlo con cierto cuidado. Por otro lado, si hay un servicio que se encuentra escuchando únicamente en la interfaz de red local (loopback) es posible que sea necesario “abrir” ese servicio hacia fuera para acceder a él desde la máquina del atacante y realizar pruebas de explotación más interesantes, esto es muy común en servicios de bases de datos como MySQL o PostgreSQL que por defecto hacen un bind de los puertos 3306 y 5432 en la IP local. Para  hacer esto existen muchas alternativas, por ejemplo se podría crear un SSH, una redirección con SOCAT, utilizar Chisel o levantar un proxy HTTP/SOCKS con una herramienta como ncat.

En la imagen anterior aparece en la primera terminal información sobre el servicio de MySQL ejecutándose localmente en la máquina comprometida (puerto 3306). Se crea un túnel SSH local que abrirá el puerto 3333 y redirigirá las conexiones entrantes por dicho puerto al 3306 de MySQL. Desde la máquina del atacante es tan simple como utilizar cualquier herramienta que realice comprobaciones contra MySQL en la IP de la víctima en el puerto 3333, en este caso se utiliza Metasploit Framework y un módulo auxiliar trivial. Esta es una forma típica de acceder y explotar servicios que se están ejecutando en loopback y que a lo mejor tienen alguna vulnerabilidad.

En el próximo post se avanzará un poco más en comprobaciones y técnicas que se aplican en post-explotación sobre sistemas Linux.

Un saludo y Happy Hack!
Adastra.