En la primera parte de este artículo hemos visto cómo sería la parte ofensiva de nuestro supuesto práctico donde un atacante ha conseguido tomar control total y permanente de una máquina vulnerable. Ahora toca ver la otra parte, que es la de detectar la intrusión en el sistema y reconstruir los hechos en un proceso post-morten que nos ayude a entender todo lo que ha pasado.
Figura 15: Pentester e Intrusión en un sistema Versus
Analista Forense y Detección de Intrusión (Parte II de III)
Realizaremos ahora, como primer paso, una adquisición de evidencias consistente en un volcado de memoria RAM y una imagen completa del disco duro de la máquina víctima comprometida por el atacante.
Para el volcado de memoria utilizaremos avml. Lo ejecutamos y, haciendo uso de netcat, enviamos el fichero generado a nuestra máquina de Análisis Forense en la que, también mediante netcat, ya tendremos habilitado el puerto 9999 para recibirlo.
Posteriormente apagamos la máquina y la iniciamos con una distribución de Análisis Forense con la que haremos la imagen del disco. En nuestro caso, utilizamos CAINE 11.0 y volcamos el disco a una imagen en formato EWF (Expert Witness Format) haciendo uso de la herramienta Guymager.
Análisis del incidente
Pasaremos ahora a analizar el impacto que han tenido nuestras acciones en los distintos artefactos del sistema. Comenzaremos analizando el volcado de memoria mediante Volatility. Deberemos de asegurarnos de que tenemos instalado el perfil adecuado para nuestro volcado, en caso contrario siempre podemos crear uno a partir de una máquina igual a la que estamos analizando. Son procesos estandar de lo que es realizar un Análisis Forense que pueda ser utilizado
Mirando las conexiones que tenía establecidas la máquina en el momento del volcado (opción linux_netstat) podemos ver, aparte de las conexiones SSH, las conexiones de un proceso server.rb y también de una shell sh:
Con la opción linux_pstree, vemos que la shell sh es hija del proceso server.rb, lo cual ya sería de por si bastante sospechoso:
Con la opción linux_psaux vemos que server.rb (id 2067) tiene su origen en el comando bin/rails s -b 0.0.0.0 -p 3500 que inicia un servidor Rails en el puerto 3500. Vemos también que se inicia una shell interactiva (sh i) y que el usuario www-data inicia una conexión SSH.
Finalmente, con la opción linux_pslist, podemos obtener los timestamps de inicio de dichos procesos: 18:27:30 UTC, 18:49:57 UTC y 19:01:37 UTC.
Visto ya en qué hora tuvo lugar el inicio del proceso sospechoso, es momento de acotar todo lo que sucedido justo antes y justo después, así que lo mejor es hacer una historial de tiempos en el sistema comprometido. Vayamos ahora con el análisis de las evidencias de disco, y a entender cómo estaba configurado y qué ha pasado en nuestro equipo GNU/Linux vulnerado, y buscando dónde se encuentran los logs de cada servicio.
Una vez montada la imagen en nuestra máquina de análisis, asegurándonos siempre de hacerlo en modo de solo lectura para no alterar las evidencias adquiridas, lo primero que vamos a hacer es mirar el fichero de log de la aplicación que se está ejecutando en el servidor Ruby para ver si encontramos algo raro.
Figura 16: Volcado de la memoria RAM en la máquina víctima
Para el volcado de memoria utilizaremos avml. Lo ejecutamos y, haciendo uso de netcat, enviamos el fichero generado a nuestra máquina de Análisis Forense en la que, también mediante netcat, ya tendremos habilitado el puerto 9999 para recibirlo.
Figura 17: Adquisición de disco con Guymager de CAINE 11.0
Posteriormente apagamos la máquina y la iniciamos con una distribución de Análisis Forense con la que haremos la imagen del disco. En nuestro caso, utilizamos CAINE 11.0 y volcamos el disco a una imagen en formato EWF (Expert Witness Format) haciendo uso de la herramienta Guymager.
Análisis del incidente
Pasaremos ahora a analizar el impacto que han tenido nuestras acciones en los distintos artefactos del sistema. Comenzaremos analizando el volcado de memoria mediante Volatility. Deberemos de asegurarnos de que tenemos instalado el perfil adecuado para nuestro volcado, en caso contrario siempre podemos crear uno a partir de una máquina igual a la que estamos analizando. Son procesos estandar de lo que es realizar un Análisis Forense que pueda ser utilizado
 |
| Figura 18: "Técnicas de Análisis Forense Informático para Peritos Judiciales Profesionales" de Pilar Vila en 0xWord. |
Figura 19: Conexiones sospechosas
Con la opción linux_pstree, vemos que la shell sh es hija del proceso server.rb, lo cual ya sería de por si bastante sospechoso:
Figura 20: linux_pstree para sacar el árbol de procesos
Con la opción linux_psaux vemos que server.rb (id 2067) tiene su origen en el comando bin/rails s -b 0.0.0.0 -p 3500 que inicia un servidor Rails en el puerto 3500. Vemos también que se inicia una shell interactiva (sh i) y que el usuario www-data inicia una conexión SSH.
Figura 21: Shell interactiva con usuariio www-data
Finalmente, con la opción linux_pslist, podemos obtener los timestamps de inicio de dichos procesos: 18:27:30 UTC, 18:49:57 UTC y 19:01:37 UTC.
Figura 22: Timestamps de inicio de los procesos
Visto ya en qué hora tuvo lugar el inicio del proceso sospechoso, es momento de acotar todo lo que sucedido justo antes y justo después, así que lo mejor es hacer una historial de tiempos en el sistema comprometido. Vayamos ahora con el análisis de las evidencias de disco, y a entender cómo estaba configurado y qué ha pasado en nuestro equipo GNU/Linux vulnerado, y buscando dónde se encuentran los logs de cada servicio.
(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord
Una vez montada la imagen en nuestra máquina de análisis, asegurándonos siempre de hacerlo en modo de solo lectura para no alterar las evidencias adquiridas, lo primero que vamos a hacer es mirar el fichero de log de la aplicación que se está ejecutando en el servidor Ruby para ver si encontramos algo raro.
Figura 24: Log de servidor Ruby
Este log lo encontramos en /var/log/upstart/ readme_app. Si nos vamos a la hora concreta en que sabemos que se inició el proceso server.rb (18:27:30) encontramos la entrada de la imagen anterior con unas cadenas codificadas en Base64.
Si cogemos dichas cadenas y las decodificamos haciendo uso de alguna herramienta como puede ser Cyberchef, obtenemos otra cadena en Base64 y unas líneas de código, que son las del exploit ejecutado.
Si repetimos la operación con la nueva cadena y la decodificamos, obtenemos el payload que abre la shell inversa contra la máquina 192.168.10.5, tal y como vemos en la imagen anterior.
Y si cogemos las anteriores líneas de código y directamente las ponemos en un buscador, rápidamente encontramos la referencia al CVE utilizado. Pero nos queda terminar de contar toda la historia correctamente, tal y como vamos a cerrar en la siguiente parte de este artículo.
Figura 25: Decodificación de la cadena en Base 64 con Cyberchef
Si cogemos dichas cadenas y las decodificamos haciendo uso de alguna herramienta como puede ser Cyberchef, obtenemos otra cadena en Base64 y unas líneas de código, que son las del exploit ejecutado.
Figura 26: Decodificación del payload
Si repetimos la operación con la nueva cadena y la decodificamos, obtenemos el payload que abre la shell inversa contra la máquina 192.168.10.5, tal y como vemos en la imagen anterior.
Figura 27: Buscando por el código llegamos al CVE
Y si cogemos las anteriores líneas de código y directamente las ponemos en un buscador, rápidamente encontramos la referencia al CVE utilizado. Pero nos queda terminar de contar toda la historia correctamente, tal y como vamos a cerrar en la siguiente parte de este artículo.
Saludos,
Autor: Andrés del Río
No hay comentarios:
Publicar un comentario