Análisis forense en Linux: Adquisición de memoria
Esta semana he tenido el placer de impartir, junto a Pedro Sánchez de Conexión Inversa, un curso de Análisis Forense en una importante compañía española situada en León. Fundamentalmente, me he centrado en la interacción con servidores Linux, por lo que posiblemente publique más de un post relacionado con el estado del arte en esta materia.
En el caso de hoy, quiero exponer una de las fases fundamentales e iniciales del análisis forense, debido a la mayor volatilidad de la misma: La adquisición o dumpeado de la memoria, utilizando técnicas que contaminen lo menos posible (tendiendo a un 0%) la evidencia original.
Me he encontrado la situación, que en el caso de llevar a cabo esta tarea en sistemas operativos Windows, es relativamente sencillo por la existencia de herramientas, libres y comerciales, debido al dominio absoluto de dicho sistema operativo en el parque de ordenadores mundial.
Sin embargo, en Linux, aparte de existir contadas herramientas libres, mantenidas y actualizadas, y debido igualmente a que cada kernel montado por cada distribución Linux es diferente, es necesario realizar un montón de procesos previos para poder hacer el volcado de la memoria, que "mancharían" el sistema.
Una de las herramientas más utilizadas es Lime (Linux Memory Extractor), de la que ya habló Alex hace tiempo en SbD, cuyo funcionamiento implica cargarse como módulo al kernel y permite de una forma bastante cómoda, volcar el contenido completo de la memoria física de la máquina en RAW, en un fichero o abrir un socket en un puerto TCP para recoger desde una máquina remota el contenido de la memoria.
Como podéis imaginar, la instalación de este módulo, depende concretamente del kernel que se esté ejecutando en la máquina "víctima" y es necesario compilarlo ad-hoc, lo que implica, entre otros pasos, la instalación de paquetes como kernel-headers, kernel-devel, svn (para bajar la última versión de lime), etc,… por supuesto con todas las dependencias que se necesiten.
En un caso que queramos hacer un forense "casero", puede ser aceptable (aunque no recomendable) hacerlo en el propio servidor, pero, como hemos dicho anteriormente, el objetivo que ha de tener el analista forense es evitar la contaminación de la máquina objetivo, puesto que instalar todo esto puede inutilizar cierta información existente en los sistemas de ficheros, relativa a archivos borrados, que con suerte y paciencia sería posible que se recuperasen.
La solución más limpia que se me ocurrió para hacer esta "cross-compilation", fue instalar en una máquina nueva (puede ser virtual), que corra exactamente el mismo kernel (ojo a la versión y arquitectura 32 bits o 64 bits) y utilizarla como infraestructura auxiliar para compilar el deseado módulo. Para ello, con una instalación mínima, sobre la que resolveremos las dependencias necesarias, descargaremos Lime:
svn checkout http://lime-forensics.googlecode.com/svn/trunk lime
cd lime/src; make
El fichero resultante tendrá el formato "lime-`uname -r`.ko". A partir de aquí, lo más limpio, sería copiar en un disco externo USB (o un pendrive) formateado con un sistema de ficheros entendible/montable por el servidor en cuestión, y una vez montado, insertarlo en el kernel objetivo. Para ello, y dependiendo de dónde queramos dejar el volcado de la memoria, en el dispositivo USB o levantando un socket en un puerto predefinido, cargaremos el .ko de una forma u otra.
En el caso de querer volcar la memoria a un fichero en un sistema de archivos del dispositivo USB, la carga del módulo sería algo así como:
cd /mnt/aux/lime; insmod lime-*.ko “path=/mnt/aux/memoria.dd format=lime”
Y en caso de abrir un socket (ojo con el cortafuegos interno de la máquina, que no prohiba el acceso a dicho puerto desde la máquina remota), lo haríamos de la siguiente manera:
cd /mnt/aux/lime; insmod lime-*.ko “path=tcp: format=lime” - donde puerto es el que deseemos y en el que no exista servicio escuchando en la máquina actualmente -
En el campo formato, tanto el valor "lime" como "raw", serían válidos para el análisis de la memoria con herramientas como Volatility, pero eso, en Linux, es otra historia de la que hablaré en otra entrada.
Fuente: Securitybydefauld
Me he encontrado la situación, que en el caso de llevar a cabo esta tarea en sistemas operativos Windows, es relativamente sencillo por la existencia de herramientas, libres y comerciales, debido al dominio absoluto de dicho sistema operativo en el parque de ordenadores mundial.
Sin embargo, en Linux, aparte de existir contadas herramientas libres, mantenidas y actualizadas, y debido igualmente a que cada kernel montado por cada distribución Linux es diferente, es necesario realizar un montón de procesos previos para poder hacer el volcado de la memoria, que "mancharían" el sistema.
Una de las herramientas más utilizadas es Lime (Linux Memory Extractor), de la que ya habló Alex hace tiempo en SbD, cuyo funcionamiento implica cargarse como módulo al kernel y permite de una forma bastante cómoda, volcar el contenido completo de la memoria física de la máquina en RAW, en un fichero o abrir un socket en un puerto TCP para recoger desde una máquina remota el contenido de la memoria.
Como podéis imaginar, la instalación de este módulo, depende concretamente del kernel que se esté ejecutando en la máquina "víctima" y es necesario compilarlo ad-hoc, lo que implica, entre otros pasos, la instalación de paquetes como kernel-headers, kernel-devel, svn (para bajar la última versión de lime), etc,… por supuesto con todas las dependencias que se necesiten.
En un caso que queramos hacer un forense "casero", puede ser aceptable (aunque no recomendable) hacerlo en el propio servidor, pero, como hemos dicho anteriormente, el objetivo que ha de tener el analista forense es evitar la contaminación de la máquina objetivo, puesto que instalar todo esto puede inutilizar cierta información existente en los sistemas de ficheros, relativa a archivos borrados, que con suerte y paciencia sería posible que se recuperasen.
La solución más limpia que se me ocurrió para hacer esta "cross-compilation", fue instalar en una máquina nueva (puede ser virtual), que corra exactamente el mismo kernel (ojo a la versión y arquitectura 32 bits o 64 bits) y utilizarla como infraestructura auxiliar para compilar el deseado módulo. Para ello, con una instalación mínima, sobre la que resolveremos las dependencias necesarias, descargaremos Lime:
svn checkout http://lime-forensics.googlecode.com/svn/trunk lime
cd lime/src; make
El fichero resultante tendrá el formato "lime-`uname -r`.ko". A partir de aquí, lo más limpio, sería copiar en un disco externo USB (o un pendrive) formateado con un sistema de ficheros entendible/montable por el servidor en cuestión, y una vez montado, insertarlo en el kernel objetivo. Para ello, y dependiendo de dónde queramos dejar el volcado de la memoria, en el dispositivo USB o levantando un socket en un puerto predefinido, cargaremos el .ko de una forma u otra.
En el caso de querer volcar la memoria a un fichero en un sistema de archivos del dispositivo USB, la carga del módulo sería algo así como:
cd /mnt/aux/lime; insmod lime-*.ko “path=/mnt/aux/memoria.dd format=lime”
Y en caso de abrir un socket (ojo con el cortafuegos interno de la máquina, que no prohiba el acceso a dicho puerto desde la máquina remota), lo haríamos de la siguiente manera:
cd /mnt/aux/lime; insmod lime-*.ko “path=tcp: format=lime” - donde puerto es el que deseemos y en el que no exista servicio escuchando en la máquina actualmente -
En el campo formato, tanto el valor "lime" como "raw", serían válidos para el análisis de la memoria con herramientas como Volatility, pero eso, en Linux, es otra historia de la que hablaré en otra entrada.
Fuente: Securitybydefauld
Comentarios
Publicar un comentario
siempre es bueno, leer tus comentarios