Volatility Framework Installer

Estándar

Hola a tod@s!!

Hace tiempo que salió al público el estupendo trabajo de muchos investigadores que dio como resultado la herramienta Volafility Framework.

Los que me conocéis, sabéis que yo llevo dando por saco con el tema de la memoria RAM desde hace bastante tiempo. Gracias a Dios, que conforme más tiempo pasa, más información sobre este tema hay.

Yo mismo he dado algún que otro Webcast en Microsoft sobre este mismo tema, he hablado en las FIST, y en algún que otro Asegur@IT.

El Framework está escrito en su totalidad en Python. En su día, para hacer funcionar la herramienta, tanto en Windows como en Linux o MAC, tan sólo hacía falta instalar Python y vualá! Ya teníamos el Framework en funcionamiento.

Hoy día la cosa ha cambiado bastante. Existen multitud de Plugins que hacen de la herramienta una tool muy poderosa para analizar por completo la memoria RAM, pudiendo ahorrar costes en tiempo en un análisis forense corporativo o por proyecto. E incluso por diversión!!

El problema para gente que está empezando en esto, es que a día de hoy existen tantos plugins y dependencias, que instalar la herramienta desde cero, y dotarla de una funcionalidad aceptable, puede conllevar una inversión de tiempo importante.

Esto lo pensó en su día Jamie Levy (aka Gleeda), colaboradora habitual en el desarrollo de Volatility Framework, y desarrolló, entre otros impresionantes plugins, uno con la posibilidad de descargar todos los plugins de un tirón. El script para la versión 1.4 de la herramienta, e instalación bajo Linux, lo tenéis disponible aquí.

Yo he realizado mi particular script (en batch! con dos cojones!! jaja) para la total instalación de Volatility Framework, junto con todas sus dependencias. Entre las “capacidades” del Script de instalación se encuentran los siguientes puntos:

  • Descarga e instalación de Python, MinGW
  • Descarga e instalación de YARA (Gracias Hispasec!!), PYGame, PIL (Python Image Library), Distorm3
  • Descarga e instalación de Volatility Framework 1.3 (Versión estable)
  • Descarga e instalación de Plugins válidos para la versión 1.3
  • Compilación automática e instalación de diversos plugins
  • Procesado de Logs de todo lo que se descarga
  • Procesado de HASH (MD5 y SHA1) de todo lo que se descarga
  • Inclusión de rutas en PATH para dotar de máxima funcionalidad
  • Inclusión de shell de comandos con el botón derecho del ratón para facilitar el análisis (Open cmd Here)

Ahora mismo, el script es totalmente funcional para instalarlo en Windows XP/Vista/7, y, como hoy en el FTSAI nos vamos a “pelear” con la memoria y todos sus componentes, me ha parecido buena idea colgarlo por aquí.

En su día, hablando con Lympex de opensec.es, éste me pasó una versión que desarrolló para Linux, la cual todavía no he puesto en el proyecto, debido a que tiene que actualizarse. Me ha prometido que cuando la tenga funcional la colgará en el proyecto.

El proyecto está alojado en Google, y ahora sí…. No tienes excusa para seguir ampliando conocimientos en materia Forense, porque documentación hay, y facilidades también!!

http://code.google.com/p/volatility-installer/

Esta semana he empezado a realizar el mismo script en PowerShell, debido a que como batch tiene muchas restricciones, he tenido que “tirar” de herramientas de terceros, como 7zip, wget y HashMyFiles para hacerla totalmente funcional. El script es muy sencillo de utilizar y no requiere parámetros. Sólo doble clic, y a jugar….

Nota: Tanto Python, como las dependencias, junto con MinGW, se instalan de manera interactiva con el usuario. Las instalaciones son del entorno Next–>Next, menos MinGW, que necesitaremos marcar las opciones de MAKE, más el compilador. Este paso de “interacción” es necesario, ya que de manera desatendida no se compilan bien algunas bibliotecas en Python bajo Windows.

Doy por supuesto (y por invitado!) que colaboraciones y ayudas, serán muy, pero que muy bien recibidas…..

Update.- Chema, de opensec, ya me ha pasado el script de instalación y está subido al proyecto. Su script soporta la instalación de Volatility Framework en los sistemas Arch, Debian y FreeBSD!

Buen fin de semana a tod@s!!

SYSTEM, causa y efecto IV de IV

Estándar

Artículos anteriores

http://windowstips.wordpress.com/2011/01/10/system-causa-y-efecto-i-de-iv/

http://windowstips.wordpress.com/2011/01/11/system-causa-y-efecto-ii-de-iv/

http://windowstips.wordpress.com/2011/01/17/system-causa-y-efecto-iii-de-iv/

Hola a tod@s!

En este último post, nos centraremos en cómo la cuenta SYSTEM se comporta a la hora de ser utilizada de forma interactiva.

Para ello, y en el banco de pruebas que hemos montado, realizaremos una elevación de privilegios, tal y como se ha comentado ampliamente por la Red. Tenéis artículos con formas de realizar este tipo de elevación en los siguientes links:

http://vtroger.blogspot.com/2005/09/mas-vale-quedarse-corto.html

http://www.securitybydefault.com/2010/12/bienaventurados-los-que-no-ven-porque.html

Al realizar el truco, (que no vulnerabilidad) y cambiar alguno de los componentes de accesibilidad por una Shell de Windows, ésta se iniciará de forma interactiva y podremos interactuar con la misma. Entre las “curiosidades” iniciales que nos encontraremos, podremos enumerar las siguientes:

  • El panel de control, no funciona
  • El explorador de Windows, junto con el escritorio, funciona de forma parcial
  • La Shell finaliza al cabo de un tiempo

El acceso total al sistema, lo tenemos única y exclusivamente a través de la línea de comandos.

Esta “irregularidad” viene dada por culpa de las claves de registro que se asocian a cada perfil de usuario.

Cuando un usuario se crea en el sistema, éste recibe un perfil de usuario. La cuenta de sistema, es decir, la cuenta SYSTEM, precarga en  memoria la clave HKEY_LOCAL_MACHINE, y el usuario que trabaja de forma interactiva en el sistema cargará a su vez la clave HKEY_CURRENT_USER, la cual se carga a través de un fichero en el perfil de usuario, que se llama NTUSER.DAT.

Si realizamos una comparación de las claves de registro que crea en el perfil la cuenta SYSTEM, con las que se crean cuando iniciamos sesión con una cuenta de usuario normal, podremos ver ciertas características que no se encuentran en el perfil de SYSTEM.

Si analizamos esas claves con alguna herramienta que permita abrir este tipo de ficheros (NTUSER.DAT), podremos ver ese tipo de diferencias, y contemplar qué claves carga la cuenta SYSTEM cuando inicia sesión en el sistema.

Para el desarrollo de este artículo, se utilizará la herramienta Windows Registry Recovery, la cual nos permite visualizar este tipo de ficheros de forma amistosa y rápida.

Imagen 1.- Claves cargadas por el usuario SYSTEM en Windows 7

Como se puede ver en la anterior imagen, la cuenta SYSTEM carga lo justo y necesario para realizar su trabajo, sin cargar más de lo necesario.

Imagen 2.- Claves cargadas por un usuario típico en Windows 7

En cuando a la imagen anterior, se puede visualizar que un usuario típico, carga lo que necesita para poder interactuar con el sistema. Algo lógico por parte del sistema operativo, ya que estos usuarios son los que están diseñados para trabajar de manera interactiva con el sistema.

Por otra parte, el usuario SYSTEM, opera desde la instancia HKEY_USERS\.DEFAULT. Esta instancia, es en realidad un alias de HKEY_USERS\S-1-5-18, instancia que identifica al SID de la cuenta SYSTEM. Al inicializar la elevación de privilegios, y siempre que no se inicie otro usuario en el sistema, la cuenta SYSTEM, utilizará una instancia que se cargará en 3 sitios diferentes. La ruta de carga es la que se muestra a continuación:

  • HKEY_CURRENT_USER
  • HKEY_USERS\.DEFAULT
  • HKEY_USERS\S-1-5-18

Para verificar lo anterior, desde la Shell de comandos arrancada cuando se realiza la elevación de privilegios, se puede crear una clave en HKEY_CURRENT_USER. Esta clave, se mostrará a su vez en las claves HKEY_USERS\.DEFAULT y HKEY_USERS\S-1-5-18.

Imagen 3.- Instancias cargadas por el usuario SYSTEM

Imagen 4.- Instancias cargadas por el usuario SYSTEM

Estas instancias, a su vez, contienen la información para interactuar con el sistema, es decir, contienen las claves de registro necesarias para lanzar un escritorio interactivo, pero tienen pequeñas diferencias. Estas diferencias, analizadas con cualquier herramienta de monitoreo, muestran como a la hora de lanzar el escritorio interactivo, éste falla al intentar encontrar ciertas claves de registro, necesarias para mostrar iconos, accesos directos, y rutas de lanzamiento a las aplicaciones. El efecto final es que el sistema operativo es capaz de “pintar” el escritorio, pero al no encontrar rutas a las aplicaciones, ni accesos directos que llamen a un programa, éste se queda “a medias”.

Imagen 5.- Rutas no encontradas

 

Como habréis podido observar a lo largo de estos cuatro artículos, es que una elevación de privilegios en Windows implica el conocimiento de muchos factores a la hora de lanzar un posible ataque, y las posibles consecuencias de que este funcione, o no…

Un saludo a tod@s!