Respuesta ante incidentes y técnicas forenses en infraestructuras virtuales (parte 1 de 2)

Parte 1/2: La respuesta ante incidentes y las principales técnicas forenses para la adquisición de evidencias volátiles en infraestructuras virtuales

Parte 2/2: La respuesta ante incidentes, adquisición de evidencias no volátiles y técnicas de análisis forense en infraestructuras virtuales

Buenas,

Pues lo prometido es deuda. Hoy quiero hablar un poco de un campo poco explorado, pero que lógicamente va tomando cuerpo a medida que pasa el tiempo. No deja de ser curioso que a fenómenos como el cloud computing se le dediquen portadas, noticias y artículos, y que la virtualización, que lleva muchos años consolidada, no goce de la misma popularidad.

No vamos a discutir hoy aquí si la virtualización de infraestructuras merece o no más o menos prensa que la nube. Para mí desde luego que ha presentado a lo largo de estos años resultados tangibles, que la nube no termina de presentar, pero lo importante de la reflexión es que la virtualización es algo suficientemente extendido, y en un continuo aumento, que hace necesario que también nos fijemos en ella desde el punto de vista forense.

Este artículo tiene dos partes. La primera es una introducción y un repaso a cómo afrontar una respuesta a incidentes en una infraestructura virtualizada (en adelante, IV). Confieso que el artículo iba a ser puramente técnico y enfocado exclusivamente al análisis forense, pero un comentario del amigo José Selvi me hizo pensar que puede ser relevante para los lectores que hagamos un esfuerzo en unir las disciplinas de respuesta a incidentes y técnicas forenses, y que diferenciemos, según la fase, el examen y el análisis forense. Llevo tiempo queriendo escribir al respecto, y aprovecharé este artículo para hacerlo. También en esta primera parte veremos cómo se adquieren evidencias volátiles en IVs.

La segunda parte será más técnica, y tendrá que ver con la adquisición de evidencias no volátiles y su posterior análisis. Tomaré como ejemplo VMware, y las razones para ello son principalmente dos: por un lado es probablemente el estándar de facto en virtualización, y su presencia en entornos empresariales es aplastante, con lo que puede ser un buen ejemplo que probablemente os encontréis en un futuro. Por otro lado es un hipervisor que podéis instalaros vosotros mismos y practicar con él, ya que dispone de versiones gratuitas.

¿En qué se diferencia una infraestructura virtualizada de una tradicional?

Puede parecer obvio, pero como en cualquier disciplina técnica siempre conviene pararse a recordar la teoría. Es lo que nos diferencia de un script kiddie: queremos usar herramientas pero sólo cuando entendamos qué estamos mirando y por qué.

Simplificando mucho la respuesta, y sin entrar en detalles sobre cómo funciona cada tecnología en particular, la principal diferencia es que la infraestructura tradicional utiliza únicamente hardware real sobre el que corre un único sistema operativo. En el caso de IVs, el hardware real se utiliza para abastecer a más de un sistema operativo y esto se puede realizar de dos maneras. Existen dos tipos de hipervisores, los que van montados directamente sobre el hardware físico (bare metal, también llamados tipo 1) y los que se establecen entre el sistema operativo anfitrión y las instancias virtuales. Este tipo, denominado habitualmente como tipo 2, es el que utilizaremos de ejemplo, ya que VMware Server es un hipervisor de tipo 2. Un ejemplo de hipervisor tipo 1 puede ser Citrix XenServer o las arquitecturas VMware ESX y VMware ESXi

El tipo de hipervisor juega un rol crucial en cómo se plantea el análisis forense. No es lo mismo, ni por asomo, que el hipervisor esté montado directamente en el hardware que encima de un sistema operativo anfitrión. En la parte más técnica nombraremos alguna herramienta para interactuar con hipervisores de tipo 1, aunque nos centraremos principalmente en los tipo 2.

¿Qué particularidades presenta una IV respecto a la respuesta a incidentes y las técnicas forenses asociadas?

Si las IVs son de por sí algo poco frecuente en la literatura forense, las IVs de tipo 1 son todavía mucho más particulares y complejas. Razones, además de la propia arquitectura, la dificultad en tener una instalación estable de este tipo para experimentar y la consiguiente ralentización en la disponibilidad de herramientas para realizar tareas de análisis. Los tiempos van cambiando, e instalar un tipo 1 directamente en el metal ya no es tan complejo como antes, pero sigue entrañando cierta dificultad, ya que a fin de cuentas, están pensados para despliegues empresariales y no para dedicar una máquina doméstica única y exclusivamente a ejecutar el hipervisor.

En relación a la respuesta ante incidentes, no está de más recordar que generalmente consta de 6 fases:

• La fase latente o de preparación, en la que simplemente nos preparamos para afrontar incidentes
• La fase de identificación, que tiene como objetivo confirmar si estamos o no ante un incidente
• La fase de contención, en la que se pretende minorar los daños si existe un incidente confirmado
• La fase de erradicación, cuyo principal objetivo es eliminar las causas y los efectos del incidente
• La fase de normalización o recuperación, que pretende lograr que el servicio que ha sufrido el incidente pueda volver a la producción
• Y por último, una fase de análisis retrospectivo que tiene como finalidad tomar nota de todas las lecciones aprendidas.

Existen diversas opiniones sobre dónde ubicar en esa cadena a las técnicas forenses. Yo soy de los que opina que existen dos puntos de entrada para las mismas:

• La fase de contención, en la que el examinador forense se centrará en la preservación de evidencias
• La fase de erradicación, donde el analista forense se centrará en el análisis de las evidencias recolectadas

Nótese que me gusta distinguir entre el examinador y el analista forense, aunque es frecuente que ambos roles recaigan en la misma persona, y lo hago porque así podemos diferenciar entre las técnicas forenses de contención (adquisición) y las de erradicación (análisis), si pretendemos enlazar los conceptos de respuesta ante incidentes y técnicas forenses.

El único axioma que debemos recordar que, independientemente de si analizamos IVs o arquitecturas tradicionales, la respuesta a incidentes tiene las mismas fases porque la metodología es la misma. Lo único que variará será la manera de llevarlas a cabo, o lo que es lo mismo, los procedimientos operativos. Además, como hemos sido capaces de relacionar técnicas forenses con respuesta a incidentes, pues nuevamente, da igual el tipo de arquitectura: el objetivo de las técnicas siempre será la adquisición y preservación de evidencias y el posterior análisis de las mismas. Veamos cómo proceder.

Contención de incidentes en infraestructuras virtuales: técnicas forenses de adquisición y preservación de evidencias volátiles

En un sistema tradicional el examinador forense hará lo posible para recolectar evidencias, siguiendo la práctica de representatividad y utilidad (adquirir pruebas válidas y que no sean cuestionables) y lo que se llama como principio de volatilidad: se recogen primero los datos más volátiles y por último, los menos volátiles, ya que los sistemas en ejecución son susceptibles de cambios, y algunos son más profundos y rápidos que otros.

En una IV se procede de la misma manera, y respetando exactamente el mismo criterio de volatilidad, pero indudablemente, las cosas pueden, y de hecho son, distintas. Datos volátiles por excelencia son la memoria volátil, las conexiones de red o los procesos en ejecución, aunque hay muchos más y a veces se pasan por alto, como por ejemplo los contenidos del portapapeles del sistema operativo, ficheros abiertos, usuarios conectados y sus correspondientes credenciales, volúmenes cifrados o almacenamiento externo montado, etc.

El dato volátil más valioso en un sistema en ejecución suele ser la memoria, ya que de ella pueden derivarse los demás datos volátiles. Es nuestro primer objetivo siempre que sea posible obtenerla, ya que a veces, la intervención puede comenzar estando el sistema apagado. Especialmente relevante es tener en cuenta es que la obtención de datos volátiles tiene que provocar la mínima invasión del sistema que queremos estudiar, de modo que no todas las técnicas son óptimas, aunque en el peor de los casos, es mejor tener una memoria obtenida por una mala praxis en la adquisición que no tener nada. Probablemente esta evidencia no será válida en un proceso judicial, pero siempre podemos emplearla para nuestro análisis.

En un sistema tradicional la captura de memoria suele depender del sistema operativo que tengamos que analizar, pero siempre requerirá que se cumplan dos cosas: que empleemos binarios estáticos ajenos al sistema (para evitar el riesgo de emplear binarios que hayan sido contaminados en el incidente) y que tal y como hemos comentado, produzcamos la mínima invasión posible. También es recomendable renombrar los binarios, para impedir que los componentes maliciosos lo detecten y lo inutilicen, aunque esta técnica de poco sirve si el incidente ha sido provocado por malware que hace comprobaciones de hashes, por ejemplo.

• En UNIX y derivados es normal que haya utillaje para adquirir la memoria en el propio sistema y este suele ser el origen de un problema común basado en la excesiva confianza en los elementos del sistema. El ejemplo clásico es la utilidad dd, que puede ser empleada con una invasión mínima para obtener la memoria. Es frecuente también que el dispositivo de memoria (pro ejemplo, /dev/mem) no pueda ser accedido directamente y que haya que recurrir a un alias (por ejemplo, /proc/kcore) para realizar el volcado. No obstante, por las mismas razones que expondremos para sistemas Windows, lo ideal es disponer de una batería de binarios confiables para depender lo menos posible en los del sistema ya que estos pueden estar contaminados. Para saber qué tipo de binarios te pueden hacer falta, echa un ojo a http://computer-forensics.sans.org/blog/2010/03/09/building-a-unixlinux-incident-response-forensic-disk/. En este punto asumo que los interesados tienen capacidad para comprender estos comandos, cómo generar un medio de respuesta ante incidentes y por tanto, no entraré en más detalles.
• En sistemas Windows, lo normal es que no haya herramientas para realizar la captura, y por tanto, siguiendo el principio de la mínima invasión, lo apropiado es lanzar una línea de comando confiable desde una unidad óptica (CD, DVD) y desde ella, lanzar la herramienta de captura que vayamos a utilizar. Dada la naturaleza de las plataformas Windows, es ciertas versiones es complicado o incluso imposible lanzar herramientas que no utilicen las DLLs y otros componentes del sistema en estudio, aunque en versiones recientes (Windows XP en adelante), es posible emplear DLLs independientes. Además de los cambios en la memoria, la ejecución de herramientas provoca una larga ristra de cambios en el sistema, desde el registro hasta los logs del sistema, sin embargo, dado que el 0% de invasión no es factible, se considera buena práctica reducir al mínimo el impacto procediendo de la manera descrita. Herramientas usuales para realizar la captura pueden ser Windows Forensic Toolchest, que automatiza la recolección de datos volátiles mucho más allá de la memoria, y Helix. Ambos automatizan la cadena de custodia, ya que permiten la generación de hashes de integridad al vuelo.

En ambos casos hemos basado todo en la disponibilidad de un medio óptico para lanzar nuestras herramientas. ¿Nos servirá esto también en una IV?

El proceso es similar, pero en este caso podemos apoyarnos en una funcionalidad adicional que es la creación de snapshots para obtener, nada más confirmado el incidente, una primera copia del montaje. Esto nos confiere mucha tranquilidad, ya que una vez generado el mismo, dispondremos de una copia exacta del entorno en ejecución que incluso puede ser lanzado después en el laboratorio. Veremos algún ejemplo en la segunda parte del artículo. Pero cuidado con el exceso de confianza.

El principal riesgo de confiar excesivamente en los snapshots es que la máquina virtual a analizar puede -y de hecho generalmente así sucede- estar en comunicación con otras máquinas de la infraestructura, virtuales o no, con lo que nadie piense que el snapshot nos da derecho a tocar el sistema a nuestro antojo, rebobinar, volver a tocar, volver atrás, y así indefinidamente, porque podemos perjudicar a otros servicios del entorno. Incluso alertar al atacante, si este está conectado desde una máquina ajena a la que estamos estudiando. El snapshot nos garantiza que el sistema en ejecución puede ser lanzado siempre que queramos a posteriori, pero en ningún caso es un juguete para experimentar en una respuesta ante incidentes. No perdamos esto de vista, por favor.

Otra diferencia de las IVs y las físicas es que podemos suplir en mejores condiciones el problema número uno en el trabajo de campo de la respuesta a incidentes: ¿Y si no hay una unidad óptica en la máquina? Si hemos basado nuestro kit de binarios estáticos y confiables a un CD o DVD, ¿qué hacemos si no podemos usarlo porque no hay una unidad a tal efecto?. Dejaremos aparte otro de los problemas habituales, ese que como podéis imaginar, es que cuando queramos leer el medio óptico estático, no podamos, bien porque tengamos un DVD y el sistema físico tenga un CD, bien por defectos del disco, del lector … etc. En ausencia de un medio óptico en el sistema físico, es factible como plan «B» enganchar nuestra unidad óptica portátil, aunque esto desde luego provoca invasión en el sistema, si bien sigue siendo aceptable. Tampoco hablaremos de qué ocurre si nuestro lector portátil es USB y la máquina física no tiene USB, o si los USB están capados en la BIOS o mediante software de control.

En una IV existen dos maneras de resolver el problema

• La primera es montar el medio óptico del sistema físico en la máquina virtual, lo cual no requiere la parálisis del sistema y provoca una invasión controlable.
• La segunda es ser precavidos, y además de llevarnos el kit de binarios en CD o DVD, llevarnos una imagen de dicho medio óptico (ISO, por ejemplo) de modo que podamos montar una unidad óptica virtual ajena a la física desde la que podamos lanzar nuestro kit.

Sea como fuere, el objetivo es recolectar, con la mínima invasión posible, toda la información que podamos.

¿Y qué hago cuando tengo toda la información? ¿Dónde la meto?

Buena pregunta. ¿Qué hacemos al recolectar? ¿Lo vamos dejando todo en algún sitio y luego lo recogemos? ¿Lo vamos transportando al vuelo a un lugar seguro?

Siempre que sea posible, y para eso están netcat y similares, establecer un túnel para enviar a otro lugar las ejecuciones es una buena idea. Esto genera invasión, pero es controlable y fácilmente identificable, y es mucho más deseable que dejar huellas en el sistema de ficheros que estemos investigando.

Esto es igual de válido para máquinas tradicionales como IVs. Generalmente no es buena idea, por la invasión que se produce, meter una llave USB en la ranura de la máquina para copiar allí lo que hayamos guardado. Esto sólo debe hacerse si es que no existe ninguna otra manera de sacar la información del sistema, con lo que como ejercicio, invito al lector a que plantee diversos escenarios que se pueden presentar, y cuáles son los mejores técnicas para efectuar la extracción de la información generada.

Resumiendo

• Por obvio que parezca, conviene saber qué diferencias hay entre un sistema físico y uno virtual, y dentro de los virtuales, cuáles responden a una hipervisión de tipo 1 o 2. Y dentro del tipo, hay que practicar concienzudamente para cada tipo de sistema operativo que podamos encontrarnos, porque algunos comandos difieren entre sistema y sistema. Por ejemplo, las rutas en FreeBSD o AIX se obtienen ejecutando netstat -r, pero en DG-UX se lanza sysadm y en Tru64, se consultan en /etc/routes
• Las fases de la respuesta a incidentes y las técnicas forenses asociadas son las mismas en un sistema tradicional que en una IV. La metodología es válida precisamente porque no hay que cambiarla en función al escenario a investigar. Lo que varía usualmente son los procesos operativos, es decir, cómo hacer en cada caso lo que cada fase requiere.
• La adquisición de evidencias en una IV sigue los mismos principios que en una instalación tradicional, y debe regirse siempre por el principio de la volatilidad (priorizar la adquisición de más a menos volátil), la mínima invasión (no es buena idea lanzar un navegador instalado en el sistema y bajarse el win32dd para sacar una captura de memoria en un XP en mitad del proceso de respuesta a incidentes) y siguiendo pautas que aseguren que las evidencias sean representativas.
• Los snapshots, en una investigación, son una fuente de evidencias, no son una herramienta para probar en vivo diferentes técnicas de adquisición, ni para analizar datos en la respuesta ante incidentes.
• Las máquinas virtuales en ejecución suelen estar conectadas a otras máquinas, virtuales o no, con lo que este factor debe tenerse en cuenta y si es preciso modificar la cadena de volatilidad según el escenario. Este no es un trabajo para amigos del checklist, a veces hay que modificar los procedimientos operativos.
• Da igual si estás analizando una infraestructura convencional o una IV: siempre te hará falta un kit de herramientas, y conviene pensar en todos los escenarios posibles para no cometer el error de no poder lanzarlas cuando haga falta.
• Las gran ventaja de las IVs es que ofrecen posibilidades en la respuesta a incidentes que las máquinas tradicionales no suelen ofrecer. El ejemplo típico, además de la creación de snapshots, es el montaje en caliente de dispositivos para utilizar herramientas confiables.
• Antes de lanzar comandos piensa detenidamente cómo vas a sacar la información del sistema. Este punto es crucial, ya que existen infinidad de maneras de hacerlo, y cada una tiene un impacto diferente.
• Es fundamental que los equipos forenses inviertan mucho tiempo en la fase latente de la respuesta a incidentes, es decir, en la preparación. Procedimientos, scripts, herramientas … La cantidad de diferentes escenarios y las miles de cosas que pueden fallar son tales que la única manera de salir airoso en el trabajo de campo es combinar la experiencia y el aprendizaje. En esta profesión no podemos permitirnos el lujo de acudir al lugar del incidente y no saber que hacer.

En la próxima entrega veremos cómo realizar la adquisición de evidencias no volátiles y el correspondiente análisis forense, como parte de la fase de erradicación en la respuesta a incidentes, y lo ejemplificaremos con ficheros VMDK de VMware Server.

Un saludo,