Enumeración en Linux para Post-Explotación – Parte 5.

Puedes ver las cuatro 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.
Enumeración en Linux para Post-Explotación - Parte 4.

Es el momento de hablar de otros detalles que se deben comprobar en la enumeración de un sistema Linux, concretamente el listado de librerías y programas con vulnerabilidades conocidas, el abuso de funcionalidades incluidas en servicios/procesos y tareas programadas inseguras.

Como en cualquier sistema, pueden existir programas y librerías que se ejecutan localmente de un modo inseguro o que incluyen vulnerabilidades que han sido reportadas públicamente. Estos casos se pueden detectar listando las características del sistema comprometido. Es un proceso que lleva tiempo ya que requiere enumerar todo el sistema y comandos como "dpkg -l" devuelven un listado bastante amplio con todas las librerías y programas instalados en el objetivo, no obstante es algo que en un proceso de post-explotación debe hacerse.

Existen programas y servicios que incluyen funcionalidades interesantes, las cuales para un atacante pueden representar una vía para elevar privilegios. Por ejemplo, un programa que permite la lectura o creación arbitraria de cualquier fichero en el sistema o que se encarga de levantar otros servicios partiendo de algún fichero de configuración son casos típicos en los que se podría llevar a cabo la elevación de privilegios horizontal o vertical.
Un ejemplo cercano es lo que se ve en muchas empresas dedicadas al desarrollo con arquitecturas basadas en microservicios utilizando Docker. Esta plataforma concretamente ejecuta instrucciones como root para la creación de contenedores, volúmenes, redes y otras funciones que son habituales en Docker. Una práctica muy extendida y que se fomenta en la documentación oficial de Docker es la de incluir a un usuario en el grupo "docker" para que no sea necesario ejecutar el cliente como "root" y de hecho es una buena práctica, siempre y cuando dicha cuenta de usuario se encuentre protegida y debidamente securizada. Por lo tanto, si durante la post-explotación se tiene acceso a una cuenta de usuario que hace parte del grupo "docker" y el servicio de Docker se encuentra correctamente instalado y configurado en dicho sistema, es altamente probable que se pueda llevar a cabo la elevación de privilegios.

En la imagen anterior, se puede ver que el usuario hace parte del grupo "docker" y a continuación, crea un contenedor utilizando el cliente de Docker con la imagen "ubuntu", en este caso se utiliza la opción "-v" para montar un volumen en Docker el cual expone los contenidos del directorio "/etc/" de la máquina host directamente en el contenedor en la ruta "/montaje". A partir de este punto será posible leer o incluso modificar ficheros tan importantes como el "/etc/passwd" o el "/etc/shadow".

Es posible que servicios de uso común como Apache o MySQL utilicen un fichero configuración en el arranque con permisos demasiado abiertos, lo que permite a un atacante local ver o incluso editar detalles sobre cómo se deben ejecutar dichos servicios. Este tipo de malas prácticas le permiten a un atacante tener una visión mucho más amplia del sistema y por este motivo los ficheros de configuración utilizados por servicios como los indicados anteriormente (entre otros) deben ser de lectura/escritura sólo para el administrador.
Por otro lado, las tareas programadas y utilidades que realizan las mismas funciones que el demonioCROND son especialmente interesantes ya que dichas tareas se ejecutan con una periodicidad concreta y con los permisos del usuario especificado. Cada cuenta de usuario puede tener sus propias tareas programadas que se ejecutarán con sus permisos y que por defecto solo son accesibles por parte del mismo usuario, es decir, que un usuario no puede ver las tareas programadas de otro. Sin embargo es posible crear tareas globales en el fichero "/etc/crontab" y aunque dicho fichero por defecto no tiene permisos de escritura para un usuario distinto a root, todos los usuarios pueden leerlo.

En la imagen anterior se puede apreciar que efectivamente hay una tarea programada que se lanza cada minuto por el usuario "root" y además, el script de dicha tarea se encarga de levantar una base de datos H2, que tal como se puede apreciar parece ser la versión 1.4.196. Dicha versión cuenta con una vulnerabilidad que se encuentra detallada en exploit-db por lo tanto este escenario es ideal para que un atacante local pueda elevar privilegios en el sistema.

En el siguiente post se explicarán más detalles sobre post-explotación en Linux.

Un saludo y Happy Hack!
Adastra.