Puedes ver las dos 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.

A continuación se enseñan algunas otras cuestiones básicas que se deben consultar a la hora de enumerar un sistema Linux. Sirven como complemento de lo que se ha mencionado en los dos post anteriores y con toda esta información se va obteniendo una imagen mucho más amplia del sistema comprometido, incluyendo entre otras cosas, posibles vías para elevar privilegios.

En un sistema Linux hay varios directorios y ficheros destinados al almacenamiento de logs, esta información en ocasiones puede ser difícil de manejar dado que en un sistema productivo suelen haber miles de registros pero es probable que existan fugas de información o detalles sobre el sistema que pueden evidenciar una vulnerabilidad o ser la pieza que hacía falta para componer un buen vector de ataque. En los sistemas Linux hay directorios donde se almacenan ficheros de logs que son más o menos habituales, algunos se encontrarán disponibles en el sistema o no dependiendo del software instalado. Por ejemplo, si hay un servidor web Apache instalado es posible encontrar ficheros de log relacionados con los errores que se van produciendo o las trazas que van dejando las aplicaciones web. La mayoría de estos ficheros se encuentran almacenados en /var/log

Otra fuente interesante de información se encuentra disponible en los logs generados por herramientas como RPM o DPKG a la hora de instalar software en el sistema. Dichas trazas pueden revelar la existencia de programas o librerías con vulnerabilidades conocidas. Como siempre, se busca recolectar la mayor cantidad de información posible.

No obstante, hay que tener en cuenta que dependiendo de la configuración que tenga el sistema es posible que estos directorios o ficheros tengan alguna restricción de acceso, en sistemas Fedora/CentOS es común encontrarse con que los ficheros de log listados anteriormente solamente los puede leer el usuario “root”, por lo tanto hay que ver a qué ficheros se puede acceder en primer lugar. Más adelante se dedicará un post completo para ver cuáles son los ficheros de logs más importantes en un sistema Linux y su utilidad en la post-explotación.
Por otro lado, en ocasiones el historial de comandos ejecutados pueden dar pistas sobre las prácticas que sigue el administrador a la hora de gestionar el sistema, para ello el comando “history” será perfecto. Si es posible acceder a los directorios “home” de los usuarios y muy especialmente a los ficheros “.bash_history”, es posible encontrar detalles útiles. Aunque es habitual que no se pueda acceder al directorio “home” de otro usuario, esto es algo que también se debe probar.

Cada vez resulta más común encontrarse con entornos “dockerizados”, especialmente en arquitecturas basadas en microservicios. Normalmente las posibilidades que tiene un atacante en un contenedor son bastante más limitadas pero afortunadamente es fácil detectar que se está en este tipo de entornos. Hay indicios durante la enumeración que permiten saber que no se opera sobre el sistema directamente y que la vulnerabilidad explotada para ganar acceso, afecta a un servicio o programa que se encuentra en ejecución en un contenedor. Algunas de las “pistas” que pueden indicar que el servicio comprometido se encuentra en un contenedor son las siguientes:

• Hostname: Suele ser un indicio bastante común ya que por defecto es el ID del contenedor Docker.
• Dirección IP: Por defecto, en Docker el direccionamiento IP empieza en 172.17.*
• Dirección MAC. Para evitar colisiones ARP, todos los contenedores Docker tienen una MAC asignada en el rango de 02:42:ac:11:00:00 y 02:42:ac:11:ff:ff
• Procesos: El listado de procesos será muy reducido comparado con cualquier servidor “físico” ya que normalmente los contenedores se encargan de gestionar microservicios.
• CGroups: Inspeccionar los CGroups suelen enseñar suficientes evidencias sobre si los procesos se encuentran aislados en un contenedor o no. basta con ver el fichero “/proc/1/cgroup” en donde “1” representa el PID de un proceso activo.

Una mala práctica que suele presentarse en los contenedores Docker consiste precisamente en que en ocasiones es posible acceder al socket unix del demonio Dockerd. De esta manera, un atacante puede acceder a información del demonio o incluso controlarlo aunque se encuentre dentro de un contenedor. Es algo que se produce en raras ocasiones pero se debe probar.

Existen otras consideraciones a la hora de enumerar contenedores, por ejemplo la posibilidad de analizar el entorno de red en busca de otros contenedores que se encuentren en ejecución por la instancia de Docker, conexiones que se establecen entre el contenedor comprometido y otros que se encuentran disponibles en la infraestructura (algo muy común) o incluso, ver si es posible pivotar. Todo esto también hace parte de un proceso de enumeración.

Las bases de datos representan una fuente valiosa de información, no tanto como un recurso para elevar privilegios (aunque en ocasiones puede ser) sino para acceder a datos potencialmente sensibles. Las aplicaciones web utilizan bases de datos como MySQL, PostgreSQL, Oracle, SQLServer, etc. para almacenar información de las aplicaciones web desplegadas, por lo tanto no es de extrañar que esta sea una de las primeras cosas que se deben revisar en el proceso de enumeración del sistema. Lo más común es encontrarse con que es necesario contar con un usuario y contraseña para acceder al motor de bases de datos y estos detalles, tal como se ha visto en el post anterior, es posible que se hayan obtenido de un fichero de configuración. Muchas aplicaciones web desarrolladas en lenguajes como Java, Ruby on Rails o PHP leen las credenciales de acceso a base de datos de ficheros existentes en el sistema u otros recursos que se encuentran en texto plano.

Una vez dentro de la base de datos utilizando cualquier cliente compatible para dicho motor, basta con ejecutar consultas SQL o si cuenta con un cliente que tenga una GUI como DbVisualizer solamente hace falta navegar por las tablas y ver la información que almacenan. No todo en post-explotación está orientado a elevar privilegios, es posible que la información almacenada en la base de datos sea algo más valioso que tener un control total sobre sistema.

En el siguiente post se seguirán enseñando otras cuestiones a tener en cuenta durante la post-explotación de un sistema Linux.

Un saludo y Happy Hack!
Adastra.