Hola,
En el anterior artículo vimos cómo responder ante incidentes, asociando a dicha respuesta ciertas técnicas forenses. Completamos la fase de contención para evidencias volátiles, y en esta segunda parte vamos a terminar de ver cómo afrontar la fase de contención, en este caso, adquiriendo las evidencias menos volátiles en infraestructuras virtuales (IVs)
Por último cerraremos el artículo con una reseña sobre cómo afrontar la fase de erradicación, donde el analista forense se centrará en el análisis de las evidencias recolectadas.
Contención de incidentes en infraestructuras virtuales con hipervisores tipo 2: técnicas forenses de adquisición y preservación de evidencias (menos) volátiles
En el caso de hipervisores de tipo 2, y volvemos a recordar la teoría, los sistemas virtualizados utilizan los recursos físicos existiendo entre la IV y la física un sistema operativo que se denomina anfitrión, sobre el que corre el software de virtualización. En esta fase el objetivo principal es hacerse con los discos virtuales, de igual manera que en un sistema tradicional se procede a obtener una imagen del disco físico que será analizada posteriormente.
Nótese que hemos definido antes este tipo de evidencias como (menos) volátiles. Creo que es necesario matizar que el concepto de evidencia no volátil no es correcto si lo aplicamos a un disco, salvo que dicho disco sólo pueda ser consultado en sólo lectura por el sistema virtualizado. Los discos sobre los que corre el sistema virtual son volátiles, su estado es cambiante, si bien el índice de volatilidad es mucho menor que el que puede tener, por ejemplo, la memoria. Explico este concepto porque en la literatura es frecuente leer sobre evidencias no volátiles, y esto puede llevar a confusión si se aplica a discos duros, sean virtuales o no.
Propongo como ejemplo VMware Server, con lo que lo primero es identificar dónde conserva este tipo de hipervisor los discos virtuales. Ojo a la plataforma anfitrión, ya que como es obvio, las ubicaciones en una instalación Linux no son las mismas que en una Windows, y ojo también al posible cambio de la ubicación por defecto si el administrador ha escogido ubicaciones distintas. Mi instalación corre en un sistema Linux, y tiene los parámetros por defecto, lo que facilitará las cosas.
Si lanzamos el GUI Web de VMware Server (http://localhost:8222) resulta inmediato determinar dónde están los ficheros correspondientes al sistema virtual.
Lógicamente, como buenos profesionales que somos, y respetando el principio de la mínima invasión que comentamos en la primera parte del artículo, lanzar un navegador en un proceso de respuesta a incidentes es del todo desaconsejable, ya que provoca una invasión severa en el sistema, especialmente si el navegador está repleto de toolbars, pestañas guardadas y demás parafernalia, algo que no sabría esperar en un servidor, pero que os puedo garantizar que no es nada usual.
No obstante, aquí entra en juego el conocimiento de la teoría, y el juicio del investigador y su experiencia. En un hipervisor de tipo 2, caso de que estemos investigando uno de los sistemas virtuales que corre y no el hipervisor en sí, lanzar vía Web el interfaz de administración en el sistema anfitrión no provoca invasión significativa en la máquina virtual. Esto es distinto en un hipervisor de tipo 1, aunque en general los interfaces de administración no suelen provocar impactos severos en cuanto a invasión en los sistemas alojados. De todos modos, lanzar vía Web dicho interfaz no es algo aconsejable, aunque sie fuera preciso, es posible usar el interfaz para tomar un snapshot e interactuar con la máquina virtual si fuera necesario.
En este caso, el hipervisor sólo contiene una máquina virtual que, empleando una unidad de CD virtual, carga un sistema Slitaz a través de una imagen ISO. Siempre que sea posible se recomienda usar la línea de mandatos y recordad que para una instalación Linux, VMWare Server emplea autenticación PAM tanto para la consola como el interfaz Web, con lo que en este punto es necesaria bien la colaboración de los administradores o bien del uso de claves de emergencia, si se sospecha que los administradores pueden haber tomado parte en el incidente.
Para VMware Server:
Enumeración de máquinas virtuales
$ vmrun -T server -h https://localhost:8333/sdk -u usuario -p clave list
Creación del snapshot
vmrun -T server -h https://localhost:8333/sdk -u usuario -p clave snapshot «fichero.vmx» SnapshotForense
Detención de la máquina
vmrun -T server -h https://localhost:8333/sdk -u usuario -p clave stop «fichero.vmx» soft
En mi caso particular, por no continuar agotando recursos, he parado la máquina, pero en un incidente real esta opción no siempre es la aconsejable (en un segundo elaboraremos sobre los impactos en los ficheros vmem). Esto debe ser acordado con los propietarios de la máquina, ya que el apagado no siempre es necesario para la restitución de los servicios y puede provocar daños importantes en el negocio que soporta. En infraestructuras virtuales es posible trabajar en caliente, con lo que el apagado de la máquina sólo debe responder a un último recurso en caso de que la contención no sea posible, o porque la restitución así lo requiera. Dependiendo del caso, la desconexión de la red puede ser más beneficiosa.
Tras ejecutar las operaciones, nuestro sistema de ficheros ofrece el siguiente aspecto:
No entraré en detalles, pero obviamente, este es un buen momento para la obtención de MD5 de todos los ficheros y documentar todo lo que hemos realizado para garantizar la cadena de custodia. Para el transporte a otros medios cara a la conservación de las evidencias, SSH es la opción más adecuada, con o sin soporte de netcat según el caso. Nada de memorias USB, por favor :)
Tiempo para volver a invocar la teoría, y la importancia de la fase latente de la respuesta a incidentes: aprender y prepararse. En este caso se hace necesario comprender qué es cada cosa, y para ello, recurrimos a la documentación de VMware.
- El fichero vmware.log nos ofrece información interesante que tiene que ver con el funcionamiento de la máquina virtual, como la ejecución de snapshots, y está pensado para la resolución de problemas. En análisis forense, nunca está de más echarle un ojo ya que es el punto ideal para detectar administración malintencionada de la máquina.
- El fichero nvram contiene el estado de la BIOS, y en principio no es urgente su inspección.
- Otro punto de estudio, como se explica en este artículo de Hacktimes, son de los ficheros vmem contienen el fichero de paginación de la máquina virtual, que casualidades de la vida, es una copia de la memoria del sistema virtualizado, y que puede ser utilizado para realizar el análisis si no se ha podido efectuar la captura en vivo de la misma. CUIDADO: los ficheros vmem sólo deberían estar presentes si la máquina virtual está en ejecución o si el sistema ha sufrido un crash, con lo que un apagado soft debe concluir sin estos ficheros en el sistema, de modo que para prevenir disgustos, tratad de capturar la memoria en vivo.
- Los ficheros vmsn y vmsd son los que se ocupan de almacenar el estado de la máquina virtual. En el caso de vmsd, contiene metadatos sobre los distintos snapshots.
- Los ficheros vmx contienen la información de configuración de la máquina virtual, y siempre conviene echar un ojo para detectar la presencia de dispositivos hardware virtualizados necesarios para el funcionamiento, especialmente controladores no convencionales que podrían servirnos de pista para comprender mejor los impactos de la máquina investigada sobre otras máquinas en la misma red.
Existen otros tipos de fichero, como los de estado de suspensión (vmss), datos de team (vmtm) y vmxf (son ficheros vmx suplementarios de máquinas que forman parte de un team). Nosotros nos centraremos en los discos. Los ficheros vmdk son los asociados con los discos virtuales:
- nombrevm.vmdk es el disco principal de la máquina virtual, y puede haber varios si en la configuración de la máquina hemos especificado discos fraccionados. Cuando creamos máquinas virtuales, la opción por defecto es dividir en trozos los ficheros de disco virtual, de modo que es normal encontrar varios.
- nombrevm-#-######.vmdk Son los llamados redo-log e indican la presencia de un snapshot, ya que estos ficheros se crean automáticamente al crearse una copia del sistema. Registra los cambios sobre el disco principal mientras la máquina está en ejecución.
Es importante tener claro ambos conceptos, ya que dependiendo de las herramientas a utilizar, el tratamiento es distinto. Tal y como comentan en Hacktimes, los snapshots son comparables con la herramienta Compare Snapshots, aunque sólo es posible hacerlo desde una estación Windows.
Aprovecho aquí para hablar de un aspecto importante en las técnicas forenses, y ese no es otro que estar atento a los detalles. Cuando enumeremos los ficheros es frecuente encontrarse con infinidad de ellos, algunos de ellos incluso lejanos en el tiempo si el servidor lleva tiempo en producción. La presencia masiva de ficheros, especialmente redo-logs que no se justifican con secuencias lógicas de los snapshots, es un indicador claro de falta de conocimiento y/o empeño en la administración. Muchas personas creen que con instalar el servidor VMware ya vale, y sólo los muy profesionales cuidan con mimo los ficheros, eliminando lo que no es necesario y optimizando los recursos de disco. Os emplazo a echar un ojo al directorio de máquinas virtuales de cualquier amiguete primerizo en virtualización para comprobar la cantidad de GB malgastados por falta de limpieza en este sentido :)
Fase de erradicación. Técnicas forenses de análisis. Montaje estático de discos virtuales VMware
El montaje de discos virtuales es una técnica que nos permite acceder a sus contenidos sin tener que ejecutar la máquina virtual completa. Para este tipo de tareas es aconsejable emplear las utilidades VMware, en este caso, DiskMount. Ejemplificaremos el montaje con DiskMount para Linux, aunque existe una versión para Windows.
Este software tiene algunas limitaciones que deben ser comprendidas antes de ponernos manos a la obra. La más relevante son las incompatibilidades interplataforma, ya que la versión de Windows sólo puede tratar discos virtuales de sistemas Windows, y concretamente, FAT y NTFS (exFAT, por ejemplo, no está soportado), con lo que siempre que sea posible, para huir de conflictos, lo recomendable es usar la versión para Linux. DiskMount reconocerá los snapshops presentes, pero cuidado ya que DiskMount para Linux sólo montará el último snapshot disponible, ya que no ofrece la posibilidad de montar copias anteriores. Esta opción sólo está disponible en la versión Windows de DiskMount.
Como gran ventaja, además de ser herramientas ligeras y que podemos instalar cómodamente en medios de respuesta ante incidentes, permiten el montaje y análisis de discos virtuales remotos, como por ejemplo, los que pueda haber instalados en un hipervisor de tipo 1. En nuestro caso, estamos lanzando comandos directamente sobre los discos virtuales, ya que estamos analizando en la plataforma anfitriona, pero siempre que sea posible, sobre todo si las evidencias de disco virtual no han sido aseguradas o si hay sospechas de compromiso en el mismo sistema que corre el servidor de virtualización, es aconsejable lanzar comandos remotos para interactuar lo menos posible con el sistema anfitrión.
En primera instancia, enumeramos las particiones del disco virtual:
Es recomendable, antes de analizar, determinar si el disco está particionado o no, ya que dependiendo de la configuración del sistema de ficheros, puede interesarnos focalizarnos en una parte del disco. Además nos permite ganar más conocimiento sobre el montaje. Siguiendo las buenas prácticas forenses aplicables a los medios tradicionales, lo recomendable es obtener como evidencia el disco completo, y segmentar por particiones si fuera necesario en el proceso de análisis.
En el ejemplo, como era de esperar, tenemos un particionado Linux clásico, primario más swap. El montaje se establece seleccionando la máquina virtual y el punto de montaje deseado:
Una vez montado, el sistema de ficheros es perfectamente funcional y accesible para el análisis. Si por ejemplo quisiéramos enumerar los ficheros passwd y shadow:
Fase de erradicación. Técnicas forenses de análisis. Ejecución dinámica de máquinas virtuales VMware
La gran ventaja de las arquitecturas virtuales es que todo lo necesario para que el sistema funcione se traduce a ficheros. Esto hace tremendamente fácil lanzar el sistema dinámicamente y poder disfrutar de un entorno en ejecución sobre el que realizar pruebas y análisis allá donde queramos, ya que sólo bastará con disponer de los ficheros.
Es conveniente tener en cuenta que relanzar el sistema fuera de su contexto habitual tiene consecuencias sobre el análisis forense. Todas las dependencias provocadas por el posicionamiento original de la máquina pueden ser quebrantadas, así por ejemplo, las conexiones de red que existieran en la ejecución con máquinas remotas u otras máquinas dentro del hipervisor pueden desaparecer al no poder restablecerse.
Como regla general, dentro de infraestructuras virtuales, es conveniente no relanzar sistemas de producción en el laboratorio con conectividad de red. La razón es obvia, ya que podemos interferir en otros sistemas que dependan del servicio que estamos analizando, e incluso podríamos provocar conflictos severos, como colisión de direccionamiento IP, sobreescritura de almacenamiento compartido, etc. Si vamos a lanzar estas máquinas para observarlas en ejecución, en busca de evidencias, aseguraos que la máquina desde la que lancemos el snapshot no tiene conexión con la red de producción.
Una vez montado el disco virtual o lanzada la máquina, todo lo demás es idéntico a las técnicas forenses de sistemas tradicionales. Creación de líneas temporales, análisis de logs, correlación … etc. En el blog hay infinidad de artículos sobre análisis por si te apetece seguir leyendo.
Procedimientos específicos para hipervisores de tipo 1
Si alguien tiene ganas de ejercitarse, puede instalar VMware vSphere Hypervisor para poder practicar las diferencias. vSphere está basado en ESXi. Mi recomendación para este tipo de casos es la utilización de las vmfs-tools, sobre el que hay escrito un interesante artículo en http://planetvm.net/blog/?p=1592. Creo que es suficientemente explicativo para no tener que añadir más al respecto.
El tipo de hipervisor no hace que el procedimiento general de respuesta a incidentes varía. Varían sólo los procedimientos operativos, que en ese caso se pueden resumir en:
- Conexión al hipervisor mediante SSH
- Ejecución de esxcfg-info para determinar la ubicación de los ficheros de las máquinas virtuales que vamos a estudiar
- Generación de MD5, extracción y verificación de hashes
- Utilización de vmfs-tools y métodos habituales para infraestructuras tradicionales
Resumiendo
- Una vez más, recalcar que esta es una profesión donde es esencial estar al día y documentarse a fondo. Todo lo que hemos visto es para infraestructuras VMware. Si mañana toca hacer un forense en Citrix XenServer, que no se nos caigan los palos del sombrajo. Formación, formación, formación. Aprovechad la fase latente de la respuesta a incidentes para aprender, ya que lo aprendido puede tener implicaciones drásticas en cómo afrontéis los problemas cuando estos sucedan en la realidad.
- La respuesta a incidentes es una situación muy tensa, en mi opinión, y de largo, es el tipo de situación profesional más tensa al que se puede uno enfrentar en el campo de la seguridad y las técnicas forenses. Ya no se trata de las horas intempestivas, de gritos, llamadas y gente airada en espacios cerrados, o de que haya que arrastrarse por el falso suelo de un centro de datos o trepar por el falso techo para ver si desconectar un cable de red arruina el negocio o no porque ese día el tipo de redes está de vacaciones sin token, o tomándose unas copas con el móvil apagado. Son situaciones donde te juegas el prestigio delante de los dueños del negocio, de la comunidad técnica de la empresa y de tus propios compañeros. Y lo peor de perder credibilidad en un momento tan crítico es que cuando solicites tomar una acción dramática, como sacar en pleno online una máquina que está generando ventas de 2 millones de euros por hora (porque en caso de no hacerlo el incidente pasará de grave a crítico, o porque directamente ves una sesión SSH abierta enviando datos a una dirección IP en Bielorrusia), ya sabes lo que te van a responder. Una vez más, la mejor manera de asegurar nuestra credibilidad y prestigio es formarnos y practicar hasta la saciedad, aplicar el sentido común y ser extremadamente ágil y certero tomando decisiones. Casi nada.
- El conocimiento teórico es fundamental, y diferencia al buen profesional del script kiddie que sólo sabe lanzar herramientas sofisticadas en la línea de comandos. No se puede investigar algo si no se conoce bien. Es así de simple, y es aplicable a cualquier campo de las técnicas forenses. ¿Veis capaz a alguien que no sepa medicina de realizar una autopsia y sacar resultados de ella? Pues aquí pasa exactamente igual
- Es absolutamente necesario para tener éxito conocer bien los protocolos de respuesta a incidentes y la aproximación general a las técnicas forenses asociadas. Estas se respetan y se siguen siempre, y se particulariza según el caso en virtud a los procedimientos operativos. Es imperativo seguir un método ordenado, documentado y reproducible, o de lo contrario el trabajo que realicemos servirá de poco.
Espero que estos dos artículos os hayan gustado. Podríamos escribir mucho más ya que estos temas dan muchísimo de sí, pero creo que hemos hecho una buena combinación de aspectos teóricos y técnicos que os pueden servir de guía para aprender o mejorar en este campo. Por la misma razón, los comentarios que mejoren, corrijan o amplíen lo aquí escrito son bienvenidos.
Por cierto, gracias por la respuesta en Twitter y por mostrar interés en que escribiera estos textos. Espero no haber defraudado :)
Un saludo,
Gran artículo, gracias por compartirlo!
Muy buen artículo! Me gustó mucho
Impresionante, un artículo muy completo y detallado, de fácil lectura y comprensión, ánimo y a seguir así.
Ahhh y muchas gracias por la referencia a Hacktimes, siempre es de agradecer. Una grata sorpresa.
Nos leemos.
gracias!
Es complicado a veces tener en cuenta todo lo que rodea la cuestión de tener unidades virtuales. Aunque para eso, soluciono todo con Daemon Tools. Realmente muy interesante cómo se maneja.
Supongo que a la hora de redactar el informe pericial habrá que ser extremadamente cuidadosos y didácticos para facilitar la labor de la policía y no digamos de los jueces, en su inmensa mayoría tecnológicamente analfabetos. Si se trata de una investigación interna en la empresa ni tan mal. Pero en caso de que pudiéramos demostrar la existencia de un delito sobre máquinas virtuales (por ejemplo hipervisores del tipo 2 como los del presente artículo, y en concreto VMware), ¿lo tendríamos fácil a la hora de defender nuestro caso en un juzgado? ¿Contra qué argumentos de la parte contraria -por ejemplo, un empleado desleal con buenos conocimientos de virtualización- deberíamos estar en guardia?
Tal vez la pregunta parezca un tanto bizantina, pero algún día, inevitablemente, sucederá.
@Patxi,
Efectivamente, cuando se redactan informes de este tipo no sólo es que haya que ser extremadamente cautelosos, es que hay que hacerlos comprensibles. En investigaciones internas también es recomendable hacerlos fácilmente digeribles, ya que las audiencias son muy variopintas. Es por esto que lo usual es que el informe, el grueso, se redacte en lenguaje claro y que las evidencias técnicas se añaden como anexos explicativos.
Me resulta difícil pensar en qué argumentos específicos puede la parte contraria utilizar para ponernos trabas en un juzgado. Por lo que he podido ver, las partes contrarias suelen hacer especial hincapié en la cadena de custodia (es lo primero que se mira con lupa, a la mínima chorrada que falte, como una fecha en un documento de adquisición, piden la nulidad del proceso – y la consiguen-) y también suelen tratar de desviar a los testigos cualificados para que emitan opiniones que no están en el informe, que no son 100% irrefutables o que pueden ser interpretadas como especulación.
En definitiva, la mayoría de los letrados son expertos en eso, en provocar que en el proceso se generen dudas sobre la objetividad del informe o sobre la validez de las pruebas y los testigos. Es su arma más temible, y esto al final es tanto de aplicación para infraestructuras virtuales como físicas. Imagino que en estos casos harían todo tipo de intentos para hacer pensar al juez que las herramientas tradicionales no sirven para infraestructuras virtuales, que los sistemas operativos son distintos, que las huellas del usuario son distintas, etc.
Mi consejo sería preparar bien el caso, es decir, asegurar que la cadena de custodia es perfecta, y preparar bien argumentaciones para defender que en una IV las huellas del usuario son idénticas, que además hay huellas adicionales que añaden más valor a nuestras pruebas y que los sistemas y aplicaciones son también idénticas a una infraestructura convencional, con lo que el proceso de investigación es homologable. Es por esto que he insistido tanto en el artículo en buscar las equivalencias con infraestructuras convencionales.
Lamentablemente no he participado en ningún caso de IVs que haya acabado en un juzgado, con lo que no puedo darte más información.
Un abrazo,