Respuesta ante incidentes y técnicas forenses en infraestructuras virtuales (parte 2 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

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.

analisis forense infraestructuras virtuales

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.

analisis forense infraestructuras virtuales

analisis forense infraestructuras virtuales

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:

analisis forense infraestructuras virtuales

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:

analisis forense infraestructuras virtuales

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:

analisis forense infraestructuras virtuales

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:

analisis forense infraestructuras virtuales

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.

analisis forense infraestructuras virtuales

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,

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,