25 de noviembre de 2008

Virtual RAM Dumping

El SO hospedado podría ser accedido desde el anfitrión para realizar el volcado de memoria, de la misma forma que lo haría la tarjeta PCI de la solución propuesta. ¿Pero es posible hacerlo con las herramientas disponibles a día de hoy? Yo no conozco ninguna... ¿y vosotros?”

En el último post se analizó el RAM Dumping que Silverhack nos enseñó en las conferencias FIST de hace unos días. Vimos la problemática asociada a la extracción de memoria RAM de un equipo comprometido sin alterar la misma, y como la solución no es ni mucho menos trivial. Ahora bien, la solución no es para nada trivial y era preciso acudir a hardware externo que tomase el mando de la CPU y el bus RAM para hacer el volcado sin poner en peligro la integridad original.

Fue en ese momento cuando se planteó el qué podía ocurrir en servidores virtuales o entornos virtualizados, y fue ahí donde Lobosoft nos propuso su idea. Efectivamente esa alternativa venía contemplada en el paper que referencié:

If a system running in a virtual machine is compromised, the memory and disk contents can be saved by suspending the virtual machine and making copies of the files that correspond to the memory and disk areas of the virtual system. Some existing virtual machines save the disk and memory contents in a raw file and others save them in a proprietary format.”

Es decir la solución que proponen es pulsar el cuadradito rojo de VMWare y suspender de golpe la máquina virtual, no desde el sistema operativo virtual. Podremos hacer las copias pertinentes de esos archivos y analizarlas, herramientas como enCase permiten abrir y analizar estas imágenes. Sin embargo he tratado de ir más lejos, ¿Qué ocurre si ese malware es tan avanzado que detecta que se encuentra en un servidor virtual, detecta el "suspenso" y decide borrarse? Es una puerta que se encuentra abierta y que no podemos descartar a priori, aunque es el caso paranoico, pero para eso nos pagan ;-)

Bien, si observamos los archivos de cualquier máquina virtual tenemos:

Archivos de cualquier máquina virtual en VMWare.

Ahora bien cuando la arrancamos aparecen:

Mi XP Virtual tiene 256 MB RAM.

Donde se ha creado un archivo llamado VMEM con el tamaño exacto de la memoria RAM que se asignó a la máquina virtual en su creación. ¿Por qué no copiamos directamente este archivo y vemos que se puede sacar? Lo dicho, hacemos una copia (si fuera necesario calculamos los MD5, etc. pero eso ya es otro post) y probamos a utilizar algunas herramientas de RAM Dumping como el UserDump que vimos en el post anterior. Efectivamente, no funciona (no admite esos archivos como parámetro y esta pensada para ser ella la que realice los volcados), si utilizamos otras herramientas como Diagnostic Tool también tendremos problemas, no reconoce el formato del archivo. ¿Qué hacer? Bien, el archivo que hemos copiado ya es de por sí un volcado de memoria, o al menos ella misma, ¿Y si buscamos los strings?...¡Bingo! Ahí aparecen… Ahora la duda, ¿Serán los mismos que si lo hubieramos hecho dentro de la máquina virtual?

Arriba fuera de la máquina virtual, abajo dentro.

Pues no, cambian un poquito, aunque tienen cosas en común, ¿por qué? Muy sencillo, en la máquina virtual hemos hecho un dump de un proceso en concreto, en este caso firefox.exe, en la máquina real hemos hecho un dump de toda la memoria virtual, por ello cuando hacemos un find “firefox” anita.txt nos aparecen más cosas, lo que es un problema a la hora de detectar qué proceso fue el que hizo qué cosa (aunque se puede llegar a deducir) pero no es un problema a la hora de buscar en RAM, y sin alterarla, cadenas que nos lleven a obtener evidencias que apoyen nuestro dictamen.

Beneficios Virtualización = Beneficios Virtualización + 1;

Salu2!!

2 comentarios:

des dijo...

Cómo te lo curras, me ha parecido muy interesante ;)

Slds!

GigA ~~ dijo...

se hace lo que se puede des :-) He encontrado algo de info adicional:

http://neosysforensics.blogspot.com/2008/11/volcados-de-la-memoria-fsica-desde.html