m313 Security Blog

El “Host Protected Area” (HPA) es un espacio del disco duro que puede ser usado para almacenar datos y que tiene la particularidad de que los datos contenidos en dicha area no pueden ser vistos por el Sistema operativo y se situan en la parte final del mismo.

HPA fue añadida en el estandard ATA-4 y se basa en el uso de comandos ATA. Estos comandos devuelven información sobre el disco duro, veamos unos ejemplos:

READ_NATIVE_MAX_ADDRESS: devuelve la mayor dirección física.
IDENTIFY_DEVICE: devuelve el número de sectores a los que el usuario puede acceder.
SET_MAX_ADDRESS: establece la dirección máxima a la que el usuario puede acceder.

En la práctica es muy sencillo detectar cuando un disco duro tiene habilitado HPA, simplemente ver si coinciden la dirección máxima del disco (READ_NATIVE_MAX_ADDRESS) y la dirección máxima de acceso del usuario (IDENTIFY_DEVICE).
Hay que tener que cuenta que los cambios en el HPA son volátiles, se pierden al reiniciar. Es posible deshacer el direccionamiento máximo del usuario para acceder a la HPA y al reiciniar el sistema el valor de IDENTIFY_DEVICE será restablecido.

A continuación vemos el uso del binario disk_stat perteneciente al Sleuthkit con el que podemos detectar si un disco duro tiene habilitada HPA:

[root@wendigo HPA]# disk_stat /dev/sda3
Maximum Disk Sector: 268435454
Maximum User Sector: 268435449

** HPA Detected (Sectors 268435450 – 268435454) **

En el caso de discos duros Hitachi hay una herramienta que permite controlar y modificar una gran variedad de parámetros, se trata de Feature Tool.

Para trastear con el parametro SET_MAX_ADDRESS hay un pequeño programa escrito en C, se trata de setmax.c.
Como recomendación si queréis trastear os recomiendo hacerlo sobre un disco duro que no contenga datos muy valiosos

== Head of the class: Device Configuration Overlay (DCO) ==

“Device Configuration Overlay” (DCO) fue añadido en el estandard ATA-6 y incorpora nuevas características que un disco puede o no implementar. Ocupa el espacio en disco inmediatamente posterior al HPA. Algunas de las características que incorpora son los siguientes comandos:

DEVICE_CONFIGURATION_IDENTIFY: devuelve las características actuales del disco y su tamaño.
DEVICE_CONFIGURATION_SET: establece el DCO
DEVICE_CONFIGURATION_RSET: elimina el DCO

Hay que tener el cuenta que los cambios en DCO son permanentes, se mantienen tras un reinicio del sistema.
En la práctica para detectar si un disco duro tiene habiliatdo DCO, simplemente hay que comprobar si coinciden la dirección máxima del disco(READ_NATIVE_MAX_ADDRESS) y la dirección máxima del disco utilizando los comandos DCO (DEVICE_CONFIGURATION_IDENTIFY).

== Referencias ==

File System Forensic Analysis, ISBN 0-32-126817-2
http://en.wikipedia.org/wiki/Host_Protected_Area
http://www.hitachigst.com/hdd/support/download.htm
http://www.thinkwiki.org/wiki/Hidden_Protected_Area
http://www.sleuthkit.org/
http://www.win.tue.nl/~aeb/linux/setmax.c

Compártelo

El viernes ocho de Mayo de 2009, ISSA organiza en colaboración del Consejo Superior de Investigaciones Científicas la primera edición de las Conferencias ISSA de Seguridad. La conferencia se celebrará en el edificio del Instituto de Física Aplicada del CSIC.

Programa:
- 18:00 Apertura a cargo de Gonzalo Álvarez Marañón (CSIC)
- 18:05 “Seguridad de Servicios Web de Código Abierto” – Victor Manuel Fernandez (OpenSolaris)
- 19:10 “Retos para la Seguridad de Cloud Computing” – Oscar Delgado (CSIC)
- 20:00 Descanso
- 20:15 “Métricas y Madurez de Procesos de Seguridad” – Vicente Aceituno, (ISSA)
- 21:00 Despedida

Dado que el aforo está limitado a 80 plazas recomendamos inscribirse suscribiéndose a la lista de Eventos ISSA enviando un correo a:
eventos-issa+subscribe arroba googlegroups.com

Los inscritos tienen preferencia sobre los no inscritos para acceder a la sala antes de las 17:55

El Instituto de Física Aplicada está en la Calle Serrano, 144.

Para recibir una invitación para los próximos eventos de seguridad organizados por ISSA unos días antes de su anuncio público, lo que da mayores oportunidades de asistir cuando el aforo es limitado, recomendamos suscribirse enviando un correo a:
eventos-issa+subscribe arroba googlegroups.com

Compártelo

winAUTOPWN es una herramienta que permite atacar automáticamente sistemas Windows. Tiene una gran cantidad de exploits integrados y a diferencia de otras soluciones como Metasploit, Immunity Canvas o Core Impact apenas tiene dependencias.

Funciona en linea de comandos e incluye exploits en perl, php, python y cygwin dlls.
Ejecutarlo es tan simple como lanzar el binario, y nos va preguntando por datos sobre la víctima:

No he trasteado demasiado con la herramienta, aunque la he lanzado sobre la máquina Windows que utilizé de demo en los artículos sobre Metasploit y Meterpreter y no han tenido éxito los exploits sobre las mismas vulnerabilidades (ms08-067), tal como puede verse a continuación:

La principal ventaja es que se actualiza constantemente y es gratuita.
winAUTOPWN puede descargarse aqui. La página oficial es la siguiente:

http://winautopwn.co.nr/

Compártelo

Este post pretende ser una introducción al análisis forense del uso de este conocido navegador web.
Cuando analizamos los rastros que deja un navegador en una máquina fundamentalmente nos interesa saber a qué URL’s ha accedido el usuario, su historial de navegación para establecer si realiza un uso adecuado del mismo, extensiones instaladas, etc.

En Mozilla Firefox casi todos esos datos se guardan en el perfil, que se haya en una ruta variable en función del sistema operativo en que se ejecute:

Linux: /home/usuario/.mozilla/firefox/directorio_del_perfil
Windows XP: C:\Documents and Settings\usuario\Datos de programa\Mozilla\Firefox\Profiles\directorio_del_perfil
Windows Vista: C:\Users\usuario\AppData\Roaming\Mozilla\Firefox\Profiles\directorio_del_perfil
MacOS: /Library/Application Support/Firefox/Profiles/directorio_del_perfil

Hay que tener en cuenta que previamente se ha realizado la adquisición de la imágen, recuperación de datos que hayan sido borrados, etc.
A continuación comenzaremos el estudio del historial, para ello mi aplicación favorita es el Mandiant Web Historian, es gratuita, funciona sobre Windows y es una delicia. Nos va a producir un informe en el que nos mostrará el nombre, URL’s, fechas de primer y último acceso, si ha sido borrada, número de visitas, etc.
Animo a todo el mundo a probar esta herramienta, que por cierto no funciona únicamente sobre historiales de Mozilla Firefox.
A continuación una captura de Web Historian:

Una fuente de información muy útil son las cookies del navegador, con ellas podemos no solo establecer patrones de navegación sino en ciertos casos obtener cookies de sesión que puedan ser determinantes a lo largo de la investigación. De la mano de Nirsoft tenemos el programa MozillaCookiesView, gratuita y para plataformas Windows. A continuación una captura de MozillaCookiesView:

Otra fuente de información alternativa y muy util son los contenidos cacheados por el navegador, estos pueden visualizarse directamente a través del sistema de ficheros en las carpetas temporales. Me gusta bastante la herramienta Web Cache View que funciona para varios navegadores y puede hacernos esta tarea un poco más sencilla, también gratuita y para plataformas Windows.

Junto con todo esto lo ideal es realizar un análisis de todo el perfil, y tenemos una herramienta para ello. Se trata de FireFox Forensics, esta herramienta realiza un análisis bastante completo de todo el perfil, permisos, historial, favoritos, etc. Aqui tenemos una captura del programa en accion:

Vamos a dar un paso más centrándonos fundamentalmente en el navegador de la fundación Mozilla. Internamente funciona utilizando una base de datos de SQlite para guardar diversos datos, el esquema de dicha base de datos es el siguiente:

Extraer manualmente esos datos puede resultar muy tedioso. Afortunadamente tenemos la herramienta Firefox3 Extractor f3e, esta herramienta de comandos gratuita y para plataformas Windows puede aportarnos un plus muy interesante a lo que hayamos encontrado anteriormente, su uso es muy simple, colocamos los ficheros de la misma (f3e.exe y sqlite3.dll) en la carpeta del perfil y la ejecutamos, como podemos ver a continuación:

A modo de resumen, aunque pueda parecer algo no especialmente interesante, el análisis forense del navegador, en este caso Mozilla Firefox puede proporcionarnos datos de vital importancia en el curso de una investigación. A modo de nota resaltar que no he encontrado herramientas intersantes para automatizar estas tareas sobre UNIX, una lástima.

:: Referencias ::
http://www.securityfocus.com/infocus/1827
http://www.securityfocus.com/infocus/1832
http://www.mozilla-hispano.org/documentacion/Carpeta_del_perfil

Compártelo

El presente artículo tiene por objetivo introducirnos al análisis forense de un sistema Windows para investigar qué dispositivos USB han sido conectados y permitir extraer la mayor información posible sin tenerlos a mano, solo por los rastros que dejan en el equipo.
Puede parecer banal pero en realidad supone una parte muy importante en algunas investigaciones, ya que nos permite no solo conocer si un dispositivo ha sido conectado sino cuándo se ha realizado la última conexión, tipo de dispositivo, etc.

Teoría.

Lo primero que debemos conocer es cómo funciona el sistema, qué sucede cuando enchufamos un dispositivo USB, por ejemplo un pendrive al sistema Windows:

1. El Manager Plug and Play (PnP) recibe el evento y le pregunta al dispositivo por sus descriptores en el firmware del mismo. Un ejemplo de esta información es el fabricante, tipo de dispositivo, etc.

2. El Manager PnP utiliza esta información para localizar el driver que utiliza el dispositivo y si es necesario cargar uno nuevo( lo que quedaría reflejado en el fichero de log c:\windows\setupapi.log ).

3. Una vez identificado el sistema crea una entrada en el registro de Windows en la siguiente rama:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR

El propio nombre de esta entrada ya nos proporciona información, veamos un ejemplo práctico:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&Ven_TomTom&Prod_GO

4. El dispositivo está listo para usarse.

Práctica.

Imaginemos por ejemplo que estamos examinando un servidor y nos encontramos con la entrada que vimos anteriormente, claro indicio de que alguien con acceso al mismo ha conectado su dispositivo de navegación GPS TomTom, probablemente para actualizarlo.

Pero esto es solo el principio, hasta aqui podemos identificar qué tipo de dispositivos se conectan pero una parte fundamental del análisis forense sería identificar unívocamente el dispositivo concreto que se ha conectado al sistema. Para ello nos sirve el campo iSerialNumber.
Todos los dispositivos certificados con el logotipo de Windows tienen un valor único para el campo iSerialNumber. En el siguiente ejemplo vemos una imágen en la que podemos apreciar el número de serie de un dispositivo USB:

La pregunta a realizarse ahora es qué sucede si conectamos un dispositivo que no tiene el logo y por lo tanto es susceptible de no incorporar número de serie. Lo que sucede en estos casos es que el manager PnP le asigna un identificador, que será unico en el equipo, pero que evidentemente no coincidirá con los que les asigne otro sistema Windows. Esto puede resultarnos una complicación en el caso de que investiguemos el rastreo de un dispositivo concreto, aunque el campo FriendlyNameParentIdFix. Microsoft no proporciona información acerca de cómo se crea dicho campo, pero nunca me he encontrado dos dispositivos idénticos que en distintas máquinas den distinto valor en el ParentIdFix. Esto no es muy científico, por lo que únicamente con esto no disponemos de una prueba consistente, pero puede ayudar en algunos momentos o darnos pistas en el curso de una investigación.

Otra pregunta que surge llegados a este punto es diferenciar los dispositivos que tienen número de serie unívoco de los que no. Es muy sencillo, los que no lo tienen, contienen en su segundo carácter del identificador asignado por el Manager PnP el símbolo &.
En el siguiente ejemplo vemos el rastro de dos dispositivos, uno con iSerialNumber propio y otro sin él (asignado por el sistema):

Otro valor importante que se puede obtener del registro es el LastWrite time, o momento de última escritura. Si comprobamos el LastWrite de la clave correspndiente al iSerialNumber podremos establecer la hora a la que dicho dispositivo fue conectado por ultima vez.

Herramientas.

Como se ha podido intuir esta tarea puede suponer un trabajo muy tedioso si investigamos un equipo que lleve funcionando varios años. La cantidad de dispositivos que han podido ser conectados mediante USB al mismo puede llegar a ser muy considerable.
Afortunadamente hay herramientas que automatizan en gran parte este proceso, de manera que nos ahorran el trabajo tedioso de investigar manualmente el registro.

USBDeview. Esta aplicación de Nirsoft se conecta al registro y nos muestra de manera muy sencilla diversos datos sobre los dispositivos USB: fecha de creación, última vez que fueron conectados, número de serie, tipo de dispositivo, etc. Es gratuita y muy pero que muy recomendable.
A continuación muestro una captura de pantalla de la herramienta:

DeviceLock Plug and Play. Similar al anterior.

Referencias.

Windows Forensic Analysis. Halan Carvey.
Información del registro de Windows. Microsoft.

Compártelo