viernes, 31 de mayo de 2013

Saltandose captchas con Shell Scripting

Análisis
Lo primero y PRIMORDIAL es analizar lo que se tiene al enfrentarse a un captcha… hay de muchos tipos, FORMAS, sabores y COLORES. Principalmente los captchas con “formas” son los mas difíciles de abordar y donde se requiere la IA. Al enfrentarnos a captchas tenemos que tener en cuenta los siguientes factores que dependiendo de cada uno de ellos sera como se aborde el reto:

  • Tipografia
  • Colores
  • Ruido
  • Forma
  • Angulos y posiciones
En este caso el captcha que abordaremos es demasiado fácil y con una tipografía muy clara. Lo mas parecido a “Letra molde”, las letras no están movidas (ángulos), no hay ruido…El único factor a vencer son los colores…El captcha tiene un fondo negro con letras con un ligero degradado…Lo cual no sera difícil vencer.

El captcha en cuestion es el siguiente:



El reto es limpiar la imagen…en este punto ustedes se preguntaran…¿Por que carambolas limpiar la imagen? Pues esto es por que muchos programas de OCR son mas precisos al tener una imagen limpia…

El captcha contiene una “vulnerabilidad” en la elección de colores la cual lo hace sumamente fácil de limpiar…¿Pueden verla?…Exacto…usan un fondo único y las letras no contienen este color…Osea: EL fondo es de color negro y las letras no contienen el color negro…

¿Y? – Fácil…¿Qué pasaria si…? Realizamos un programa que CONVIERTA TODO EL COLOR NEGRO EN BLANCO Y TODO LO QUE NO SEA NEGRO EN NEGRO… De este modo obtendríamos una imagen con fondo blanco y letras negras (O en teoría eso se quiere)

Shell Script para limpiar la imagen
Normalmente para esta tarea haría un script en PHP, pero descubrí/invente una forma para hacerlo desde bash…Y se las quiero compartir. Es por ello que lo haré desde bash…Por que muchos creen que para hacer esto es imposible en bash, ya que no hay una librería que lo haga…Y es cierto, pero nos apoyaremos de Imagemagick y todo el poder de bash.

El simple script que realice para esta tarea es el siguiente:



Brevemente explicare que hago:

Obtengo el tamaño de la imagen y lo guardo en variables:


1
2
3
pixelaje=$(convert -identify $image /dev/null | awk '{print $3}')
let px_x="$(echo $pixelaje | cut -d"x" -f1 | tr -d "\n")"
let px_y="$(echo $pixelaje | cut -d"x" -f2 | tr -d "\n")"



Creo un archivo de texto con la configuración que Imagemagick requiere para convertir un archivo de texto con pixeles a una imagen…La primera linea le dice de cuanto por cuanto sera la imagen y el valor máximo del color que se usara.


1
echo "# ImageMagick pixel enumeration: $px_x,$px_y,255,srgb" >
$txt_out

Empiezo a recorrer la imagen.


1
2
for ((y=0;y<$px_y;y++));do
for ((x=0;x<$px_x;x++));do



Obtengo el valor RGB del pixel.



1
rgb=$(convert "$image"[1x1+$x+$y] txt: | grep "(.*)" -wo |
cut -d ")" -f1 | tr -d "(" | tr -d "\n" | tr -d " "| tr "," " ")


Quizás esta sea la linea mas importante del programa, y el truco que se hace para obtener los pixeles de una imagen en bash. Así que la explicare un poco mas.

convert $image[1x1+$x+$y] txt:   Esta linea lo que hace es decirle que obtenga de la imagen, el pixel que esta en la posición ($x,$y) y que me muestre 1×1 solo un pixel y al final le decimos que nos muestre el valor como texto.
Lo demás es solo para limpiar y dejar solo los valores RGB para que al final nos quede algo asi:
Y ya eso lo pasamos a variables independientes y claro las declaramos de tipo numérico.
1
2
3
let r=$(echo $rgb | awk '{print $1}')
let g=$(echo $rgb | awk '{print $2}')
let b=$(echo $rgb | awk '{print $3}')
Hacemos una comprobación diciendo que si el valor de R o G o B es mas grande que “100″ (Osea que no es tan obscuro para llegar al negro Lo pintemos de negro en la coordenada dada…De lo contrario se pintara de blanco.
1
2
3
4
5
if [[ $r -gt 100 || $g -gt 100 || $b -gt 100 ]];then
echo "$x,$y$black" >> $txt_out
else
echo "$x,$y$white" >> $txt_out
fi
Donde por cierto los colores $black y $white valen segun imagemagick esto;
1
2
black="(  0,  0,  0)  #000000  black"
white="(255,255,255)  #FFFFFF  white
Al final se convierte el archivo .txt creado a una imagen .pnm (Se usa este formato ya que el programa de OCR requiere este formato).
1
convert $txt_out captcha_clean.pnm
Y por ultimo se Usa el programa gocr para obtener las letras de la imagen.
1
cracked=$(echo $(gocr captcha_clean.pnm))

Y voila!!!
Captcha Cracked!!! No que los bots no podían leer la imagen?? ¬¬
El codigo lo pueden ver en mi Pastebin AQUÍ!!! Este CÓDIGO SOLO ES DE EJEMPLO!!! Esto igualmente como dije, se puede realizar de un modo mas rápido con PHP…Dejo un código de ejemplo…
Y bien para terminar modifique un poco el script de arriba, para hacerlo generico…llegando con:
Al cual se le pasa como parametro una imagen y se le definen los colores que se quieren discriminar…con esto el la limpiara y la intentara decodificar…Ej:
Este captcha se quiso “crackear” sin limpiarlo y este es el resultado NEGATIVO:
Y con captcha-cracker-neobits.sh

BASH + IMAGEMAGICK + gocr == PWNED!!!
Notas Finales:
  • Y bueno con esto demuestro que con bash podemos seguir haciendo cosas hermosas…Obviamente, en “producción” esta no es ni por cercana la mejor opción…Ya que es lento…
  • PHP es un excelente lenguaje para manejor de imagenes…pero son mas rapidos los lenguajes compilados.
  • Tesseract es otro programa PODEROSISIMO para OCR
  • Este ejemplo es completamente demostrativo, ya que con lo tardado de la limpieza, no sirve para hacer un bot malicioso (Ese nunca fue mi proposito)
Espero haya gustado este nuevo post Y sin mas…
Saludos!

FUENTE:
http://news-technology-learning.blogspot.com/2013/05/saltandose-captchas-con-shell-scripting.html?showComment=1369830772831#c8713352826960060827

Provocar el fallo de cualquier sistema Windows de 32 bits

Las siguientes dos instrucciones en ensamblador son capaces de inutilizar (crash) cualquier sistema operativo Windows de 32 bits (hasta Windows 7 SP1 con los últimos parches) siempre que ntoskrnl.exe esté cargado bajo 0x8323f000 y donde 0x8327d1b7 es la dirección de nt!KiSystemServiceAccessTeb:

xor ebp, ebp
jmp 0x8327d1b7

Seguro que pensarás "qué diablos, ¿cómo es eso posible?". En efecto, suena bastante absurdo que un thread en ring 3 que intenta saltar al espacio de direcciones del núcleo pueda provocar una excepción no controlada dentro del ring-0 de Windows. Sin embargo incluso en el año 2013 Windows todavía es fragil en ciertas áreas y existen algunas vulnerabilidades que pueden ser explotadas mediante diversas técnicas...
 


Ésta en concreto, explicada por el gran Mateusz "j00ru" Jurczyk en su conferencia en la última NoSuchCon, se aprovecha de un bug en nt!KiTrap0E, el manejador por defecto de las excepciones de errores de página (#PF) en arquitecturas X86. 

El manejador confía en el campo KTRAP_FRAME.Ebp como un puntero válido en modo kernel cuando se procesan fallos en EIP específicos. Debido a que KTRAP_FRAME.SegCs no se comprueba correctamente (o mejor dicho no se comprueba), es posible elaborar un frame con un Eip controlado y el registro EBP en modo de usuario, lo que permite a un atacante local provocar una caída del sistema a través de una referencia a memoria no válida o revelar el bit menos significativo de cualquier byte en el espacio de direcciones del núcleo.

Código fuente de las pruebas de concepto: 
kitrap0e_bsod.zip (0.5kB, ZIP), kitrap0e_leak_bits.zip (1.4kB, ZIP) y kitrap0e_addr_space.zip (1.5kB, ZIP). Estos programas provocan un fallo del sistema operativo, permiten descubrir bits de la memoria del kernel y escanean el espacio de direcciones del kernel, respectivamente.

Fuentes:
NoSuchCon’13 and crashing Windows with two instructions
Abusing Windows NT #PF Trap Handler to Bugcheck and Leak Information
http://www.hackplayers.com/2013/05/2-instrucciones-para-crashear-Windows-32-bits.html 

lunes, 27 de mayo de 2013

¿Funcionalidad o usabilidad?

Ambas cosas. Una de las máximas de Steve Jobs era que "las funcionalidades esenciales de un sistema tenían que ser sencillas de utilizar por parte de los usuarios", funcionalidad y usabilidad deben ir de la mano, si bien no siempre van al mismo ritmo, ya que generalmente la funcionalidad va por delante de la usabilidad y es en cierto modo lógico que así sea, porque si bien ambas se realimentan del feedback, hasta que no se va consolidando la funcionalidad, la usabilidad ocupa otro lugar en la escala de prioridades.
Lo anterior no quita que se deba desarrollar con intención la funcionalidad pensando en la usabilidad, si no se hace así, no solo se no se está sacando el máximo partido posible al esfuerzo que se está invirtiendo sino que puede darse el caso de que la funcionalidad tenga que cambiarse posteriormente para adaptarse a una usabilidad que no es posible conseguir con el enfoque inicial.
Esa intención se consigue trabajando con el usuario en la definición del sprint y tratando de aplicar todo nuestro conocimiento y experiencia para asesorarle, teniendo en cuenta que hay que tener la mente muy abierta porque no hay que olvidar que el sistema que estamos construyendo no es para nosotros sino para el usuario y que si el usuario, tras escucharnos, decide tomar un camino, hay que respetarlo por mucho que pensemos que se equivoca.

viernes, 24 de mayo de 2013

Lo que hay que considerar cuando las pruebas de compatibilidad del navegador

En antiguas entradas tratamos como realizar pruebas en diferentes navegadores ahora veremos que considerar cuando las hacemos.

1.  Identificar Navegadores  - Primero tenemos que definir lo que tendrá que ser probado en qué navegadores. El equipo de la analítica general, puede ayudar en esta tarea, ya que tendrán hasta la fecha los datos de uso del navegador.

Otras cosas a tener en cuenta
- Los modos de compatibilidad del navegador (Esto es importante ya que algunos sitios obligan ciertos navegadores en vista de compatibilidad)
- Configuraciones de sistemas operativos

2  Defina el enfoque  - También sería necesario definir en qué estado realizamos prueba completa compatibilidad con los navegadores y en qué etapa se utiliza un solo navegador.(Dependiendo de la metodología de desarrollo utilizada) En mi experiencia he encontrado usando IE7 para la prueba de regresión completa y el uso de todos los navegadores para la prueba funcional es un método eficaz. Mi razonamiento es que IE históricamente se encuentra con más problemas que cualquier otro navegador.

Otras cosas a tener en cuenta
- Entender lo que hace cada uno utiliza navegadores facilitará su agrupación.

. 3  Identificar Herramientas  - Herramientas como Fiddler será útil porque van a identificar estas llamadas, también puede utilizar las herramientas de desarrollo que vienen con el navegador embargo violinista tiene la ventaja añadida de que permite al usuario romper y manipular estas llamadas.

4.  Entender Servicio y llamadas a la API  - comprender el funcionamiento interno de la AUT nos ayudará a determinar los puntos de falla y nos ayuda a plantear preguntas lógicas. Por ejemplo, ¿Qué pasa si la API de falla antes de una respuesta?

Otras cosas a tener en cuenta
- Características de HTML5 no están disponibles para todos los navegadores en función de cómo la AUT se implementa esto puede tener importancia. Sobre todo si los desarrolladores están implementando una solución del lado del cliente. http://html5test.com/compare/browser/ )  

5.  Cómo probar -  visualizaciones de hardware son una manera eficaz de realizar navegadores, sin embargo entornos visualizados hardware se encontrará con desaceleraciones significativas e imponer una gran capacidad de memoria. Así que es una buena alternativa a la prueba de hardware del host nativo cómo tiene sus inconvenientes.

Otras cosas a tener en cuenta
- Trate de evitar la realización de pruebas en modo de compatibilidad no siempre proporciona una visión coherente de la compatibilidad. Por ejemplo, en las pruebas de IE7 y pruebas en IE8 en modo de compatibilidad IE7 no son los mismos que se utilizan diferentes DLL.
- Spoon.net siempre proporciona una buena solución, las aplicaciones virtuales Spoon funcionan a la misma velocidad que las aplicaciones se ejecutan de forma nativa en contra del equipo anfitrión, con un tamaño mínimo de memoria pero que Spoon sistema operativo virtual sólo virtualiza funciones del sistema operativo en modo de usuario, mientras que la virtualización de hardware sistemas de emular toda la pila del sistema operativo, incluidos los componentes en modo kernel.Las aplicaciones que requieren controladores de dispositivo u otro software de usuario de modo que no pueden exigir un entorno de hardware virtualizado para que funcione correctamente.

Fuente:

Diferencia entre la regresión y la repetición de pruebas

Diferencia entre la regresión y la repetición de pruebas, inquietante pregunta y que normalmente se confunden entre las pruebas de regresión y volver a probar.


Diferencia entre la regresión y la repetición de las pruebas
1 - Repetición de pruebas se hace para asegurarse de que el fallo es fijo y si una funcionalidad está bien o no, esto es una especie de método de verificación utilizada en las pruebas cuando los errores corregidos. Considerando que, de regresión es re-ejecución de los casos de prueba para la parte sin cambios para ver esa funcionalidad sin cambios está trabajando muy bien no lo son.
2 - Repetición de pruebas es una prueba planificada, mientras que la regresión  es conocida como la prueba genérica.
3 - Repetición de pruebas sólo se realiza para los casos de prueba falló mientras regresión  se realiza para los casos ha pasado la prueba.
4 - Siempre debemos tener esto en cuenta, una nueva prueba tiene mayor prioridad que la prueba de regresión . Sin embargo, en los proyectos más grandes Repetición y regresión se hace en paralelo effort.But nunca olvidan importancia tanto en el éxito del proyecto.

viernes, 17 de mayo de 2013

GameOver: Web PenTest Learning Platform


GameOver, es una plataforma web para el aprendizaje de pentesting. Se encuentra dividida en dos secciones:

La primera se compone de aplicaciones web especiales que están diseñadas especialmente para enseñar los fundamentos de la seguridad Web. Esta sección cubre:

XSS
CSRF
RFI & LFI
BruteForce Authentication
Directory/Path traversal
Command execution
SQL injection

La segunda sección es una colección de aplicaciones Web deliberadamente inseguras, donde se pondrá a prueba las habilidades para explotar los fallos de seguridad como si se estuviera en un escenario real.

Enlace para la descarga: http://sourceforge.net/projects/null-gameover/files

Credenciales de autentificación: username:root password:gameover

Tras la descarga deberemos emular el fichero .VM con virtualbox, convirtiéndolo a formato VDI. Aprovecho para comentar que virtaulbox esta bajo licencia opensource. Como segunda opción podremos emularlo con el software privativo vmware.


Fuente:http://dominiohacker.com/gameover-web-pentest-learning-platform-43/

Cheat Sheets de OWASP


A veces es necesario tener a mano soluciones rápidas y eficientes para evitar tener que releer todo un libro buscando aquel truco que sabemos que hemos leído pero que no recordamos a perfección como era  o dónde fué exactamente que lo leímos. Por otro lado si bien "googlear" es a veces la solución más rápida, tratándose de prevención y seguridad pudieran existir diferentes "soluciones" o puntos de vista, y tratando se escoger las apropiadas podríamos perder un tiempo preciado.
Cuando se trata de seguridad de aplicaciones, tener a mano una lista de trucos eficientes que nos ayuden a prevenir ataques a la hora de generar código o plantear soluciones integradas de protección puede ser una ayuda invaluable.
Pensando precisamente en lo anterior, la gente de OWASP ha creado las listas u hojas de trucos o "cheat sheets", para tener a mano de forma rápida la información de seguridad necesaria para aplicar las técnicas correctas cuando estemos ensamblando y programando las rutinas esenciales de nuestras aplicación.
Estas hojas de trucos  o "cheat sheets" son varias, y a continuación les muestro los enlaces de las más conocidas y útile a mi parecer:
Sin duda como podrán apreciar al leerlas son documentos eficiente que van directo al grano en lo referente a explicar los procesos de los tipos de ataque pero sobretodo en lo que se refiere a las técnicas de prevención necesarias a la hora de ensamblar y crear código. Espero que les sean de utilidad.

Fuente: http://www.e-securing.com/novedad.aspx?id=63

Extrayendo contraseñas en memoria de Truecrypt

Truecrypt actua como software de cifrado "al vuelo" (en inglés “on the fly” encryption, en adelante OTFE). Esto quiere decir que de una forma transparente se descifran los datos cuando se requieren del disco y se cifran antes de escribirse en el disco. Para ello y a grandes rasgos, una vez que se monta un volumen con Truecrypt, la clave simétrica (contraseña o keyfile) se transfiere al filtro criptográfico que la almacena en memoria y genera claves derivadas (header key y master key) para automatizar este proceso de cifrado/descifrado. Si no lo hiciera, el usuario tendría que escribir manualmente la contraseña cada vez que accediera al volumen cifrado y por lo tanto su uso no sería demasiado versátil.



Sin embargo y dada su naturaleza se dice que el OTFE (incluido Truecrypt) sólo protege los datos cifrados “en descanso”. Es decir, una vez que un volumen cifrado se monta permanecerá accesible a los usuarios del sistema como si de texto plano se tratara hasta que se desmonte dicho volumen o se apague el sistema. El por qué está claro: en definitiva la contraseña para acceder al volumen cifrado se encuentra en la información volátil de la memoria física (RAM) y, si la obtenemos (un técnica forense muy común), nuestro único problema será sólo identificarla. Véamos cómo.

Obteniendo un volcado de la memoria RAM


En nuestro ejemplo utilizaremos un equipo con sistema operativo Windows 7 de 64 bits, 4 gb de memoria RAM y TrueCrypt 7.1a instalado. 


Lo primero que haremos será obtener una foto o adquisición de la memoria física.
Existen varias herramientas que pueden ayudarnos a obtener el volcado. En nuestro caso por sencillez utilizaremos DumpIt de Moonsols que funciona en máquinas en x86 (32-bits) y x64 (64-bits):
D:\Python27\Tools\volatility-2.1>DumpIt.exe
  DumpIt - v1.3.2.20110401 - One click memory memory dumper
  Copyright (c) 2007 - 2011, Matthieu Suiche 
  Copyright (c) 2010 - 2011, MoonSols 


    Address space size:        5234491392 bytes (   4992 Mb)
    Free space size:         110475653120 bytes ( 105357 Mb)

    * Destination = \??\D:\Python27\Tools\volatility-2.1\W7PTVMOTOS-20130430-125054.raw

    --> Are you sure you want to continue? [y/n] y
    + Processing... Success.

El resultado como podéis comprobar es un fichero en crudo o raw de algo menos de 5 Gbs. Podría parecer que el volcado de memoria obtenido es un conjunto de datos desordenados pero la realidad sin embargo es que está altamente estructurado. Además Truecrypt especifica que los datos sensibles no son almacenados en la memoria paginada (por seguridad y rendimiento), por lo que siempre la contraseña estará en la memoria física.

Para la búsqueda de la contraseña usaremos principalmente Volatility, un framework con una buena colección de herramientas en Python para el análisis y extración de datos de memoria volatil (RAM). Antes de comenzar comprobamos la existencia del proceso TrueCrypt.exe, si bien aviso que de nada os servirá recorrer las strings de un volcado del proceso:

D:\Python27\Tools\volatility-2.1>vol.py -f W7PTVMOTOS-20130430-125054.raw --profile=Win7SP0x64 volshell
Volatile Systems Volatility Framework 2.1
Current context: process System, pid=4, ppid=0 DTB=0x187000
Welcome to volshell! Current memory image is:
file:///D:/Python27/Tools/volatility-2.1/W7PTVMOTOS-20130430-125054.raw
To get help, type 'hh()'

>>> ps()
Name             PID    PPID   Offset
[...]
TrueCrypt.exe    2132   2036   0xfffffa800abbb060
...]
>>>

Reducir el espacio de búsqueda

Una vez que ya tenemos el volcado de memoria, lo siguiente será reducir el espacio de búsqueda de direcciones virtuales para centrarnos sólo en la información útil concerniente a Truecrypt.

Como cualquier otro software de cifrado completo de discos o contenedores, Truecrypt posee componentes en modo usuario y en modo kernel. Los primeros hacen referencia al interfaz mediante el cual el usuario interactua con el programa y los segundos se presentan normalmente como un driver de dispositivo que maneja todas las operaciones de cifrado/descifrado. Como comentaba, el driver esencialmente intercepta las peticiones de lectura y escritura "al vuelo" y se encarga de automatizar el proceso para que el resto de aplicaciones y el sistema operativo acceda al disco como si de un volumen normal se tratara. En consecuencia, podemos asumir que la contraseña estará en el espacio de direcciones de este driver. Por lo tanto, si reducimos el espacio de búsqueda a modo kernel descartaremos más del 50% del total de información a analizar.

Ahora bien, la forma más rápida es centrarse en los datos correctos es mediante la identificación de etiquetas o Pool tagging que debería utilizar el driver si sigue las recomendaciones de Microsoft. En Windows, cualquier dispositivo Truecrypt tiene asociado un bloque de memoria llamado DEVICE_EXTENSION, que es el espacio que debe tener residente para llevar a cabo todas las operaciones de E/S y que por ende contendrá la clave correspondiente. El puntero hacia la estructura de DEVICE_EXTENSION se encuentra en DEVICE_OBJECT/DRIVER_OBJECT, que es el ejecutable que Windows tiene que localizar para usar el driver.

Mediante el plugin devicetree de Volatitity obtendremos las relaciones del objeto del driver de Truecrypt con su correspondiente dispositivo:

D:\Python27\Tools\volatility-2.1>vol.py -f W7PTVMOTOS-20130430-125054.raw --prof
ile=Win7SP0x64 devicetree > test.txt
Volatile Systems Volatility Framework 2.1

DRV 0x1353e4aa0 \Driver\truecrypt
---| DEV 0xfffffa800abca080 TrueCryptVolumeX FILE_DEVICE_DISK
---| DEV 0xfffffa800af4f080 TrueCryptVolumeW FILE_DEVICE_DISK
---| DEV 0xfffffa8006946e30 TrueCrypt FILE_DEVICE_UNKNOWN

Como véis, el offset del driver de Truecrypt es 0x1353e4aa0 y mediante IoCreateDevice ha creado varios objetos de dispositivo de tipo FILE_DEVICE_DISK (particiones de disco) con sus direcciones de memoria virtuales correspondientes.
En nuestro ejemplo nos centraremos en obtener la clave del volumen que se montó con la letra X. Dentro de volshell, exploraremos con dt (Display Type) los type information de los objetos del dispositivo para conocer su estructura de datos:

>>> dt("_DEVICE_OBJECT", 0xfffffa800abca080)
[_DEVICE_OBJECT _DEVICE_OBJECT] @ 0xFFFFFA800ABCA080
0x0   : Type                           3
0x2   : Size                           1840
0x4   : ReferenceCount                 67
0x8   : DriverObject                   18446738026506635936
0x10  : NextDevice                     18446738026579423360
0x18  : AttachedDevice                 0
0x20  : CurrentIrp                     0
0x28  : Timer                          0
0x30  : Flags                          80
0x34  : Characteristics                256
0x38  : Vpb                            18446738026463075744
0x40  : DeviceExtension                18446738026575733200
0x48  : DeviceType                     7
0x4c  : StackSize                      7
0x50  : Queue                          18446738026575732944
0x98  : AlignmentRequirement           0
0xa0  : DeviceQueue                    18446738026575733024
0xc8  : Dpc                            18446738026575733064
0x108 : ActiveThreadCount              0
0x110 : SecurityDescriptor             18446735964904258368
0x118 : DeviceLock                     18446738026575733144
0x130 : SectorSize                     512
0x132 : Spare1                         0
0x138 : DeviceObjectExtension          18446738026575734704
0x140 : Reserved                       0
>>>

El resultado nos muestra el DeviceExtension del dispositivo, así que mostraremos el espacio de direcciones en hexadecimal con db(address, length=128, width=16, space=None):

>>> db(18446738026575733200, 1600)
[...]
0xfffffa800abca460  00 f0 52 e1 01 00 00 00 00 10 00 00 00 00 00 00   ..R.............
0xfffffa800abca470  00 00 53 e1 01 00 00 00 00 10 00 00 00 00 00 00   ..S.............
0xfffffa800abca480  00 c0 da 0a 80 fa ff ff 00 00 00 40 06 00 00 00   ...........@....
0xfffffa800abca490  00 00 00 00 00 00 00 00 01 00 06 00 00 00 00 00   ................
0xfffffa800abca4a0  a0 a4 bc 0a 80 fa ff ff a0 a4 bc 0a 80 fa ff ff   ................
0xfffffa800abca4b0  00 00 00 00 00 00 00 00 01 00 06 00 01 00 00 00   ................
0xfffffa800abca4c0  c0 a4 bc 0a 80 fa ff ff c0 a4 bc 0a 80 fa ff ff   ................
0xfffffa800abca4d0  00 32 56 05 00 00 00 00 00 2c 02 0a 00 00 00 00   .2V......,......
0xfffffa800abca4e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0xfffffa800abca4f0  00 00 00 00 00 00 00 00 01 00 06 00 00 00 00 00   ................
0xfffffa800abca500  00 a5 bc 0a 80 fa ff ff 00 a5 bc 0a 80 fa ff ff   ................
0xfffffa800abca510  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0xfffffa800abca520  01 00 00 00 00 00 00 00 5c 00 3f 00 3f 00 5c 00   ........\.?.?.\.
0xfffffa800abca530  46 00 3a 00 5c 00 4d 00 69 00 6f 00 5c 00 63 00   F.:.\.M.i.o.\.c.
0xfffffa800abca540  69 00 66 00 72 00 61 00 64 00 6f 00 32 00 2e 00   i.f.r.a.d.o.2...
0xfffffa800abca550  74 00 63 00 00 00 00 00 00 00 00 00 00 00 00 00   t.c.............
0xfffffa800abca560  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0xfffffa800abca570  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0xfffffa800abca580  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
[...]

Como veis, al comenzar a explorar la memoria desde la dirección del DeviceExtension (18446738026575733200) ya obtenemos un dato muy útil: el contenedor del volumen de Truecrypt es F:\Mio\cifrado2. 


Ahora bien, si queremos obtener la contraseña para descifrar este contenedor mediante una revisión manual resultará prácticamente imposible dada la cantidad de datos que manejamos, así que tendremos que volcar todo el espacio ejecutable del driver de Truecrypt y realizar posteriormente una búsqueda basada en formato.
La forma fácil para encontrar donde "vive" el driver de Truecrypt es mediante el módulo driverscan de Volatility, sin embargo, podemos utilizar el DriverObject (18446738026506635936) mostrado anteriormente:

>>> dt("_DRIVER_OBJECT", 18446738026506635936)
[_DRIVER_OBJECT _DRIVER_OBJECT] @ 0xFFFFFA80069E4AA0
0x0   : Type                           4
0x2   : Size                           336
0x8   : DeviceObject                   18446738026575732864
0x10  : Flags                          18
0x18  : DriverStart                    18446735827444617216
0x20  : DriverSize                     266240
0x28  : DriverSection                  18446738026505988352
0x30  : DriverExtension                18446738026506636272
0x38  : DriverName                     \Driver\truecrypt
0x48  : HardwareDatabase               18446735277674784088
0x50  : FastIoDispatch                 0
0x58  : DriverInit                     18446735827444871912
0x60  : DriverStartIo                  0
0x68  : DriverUnload                   18446735827444650112
0x70  : MajorFunction                  -

Y ahora que conocemos donde empieza exactamente el driver y cual es su tamaño podemos volcarlo en hexadecimal para centrar nuestro análisis:

>>> db(18446735827444617216, 266240)

Current context: process System, pid=4, ppid=0 DTB=0x187000
>>> Memory unreadable at fffff880044ed000
>>> 

Realmente el mensaje devuelto significa que algunos bytes no son legibles. Este error suele ocurrir cuando existen datos del objeto paginados pero, como hemos comentado, Truecrypt no pagina nada, por lo que el problema tiene que deberse a algún bug en el proceso de adquisición de la memoria. No obstante si ajustamos los límites podremos volcar correctamente la información que necesitamos:

echo "db(0xfffff880044ed000, 0x3c7ff)" | python vol.py -f W7PTVMOTOS-20130430-125054.raw --profile=Win7SP0x64 volshell > volcado.txt

Búsqueda de la contraseña basada en formato

Analizando el código fuente de Truecrypt, concretamente el fichero de cabecera Password.h, la contraseña debe tener el siguiente formato:

     typedef struct
    {
          // Modifying this structure can introduce incompatibility with previous versions
          unsigned __int32 Length;
          unsigned char Text[MAX_PASSWORD + 1];
          char Pad[3]; // keep 64-bit alignment
    } Password;

Esta estructura fue introducida en la versión 4.0 y posteriormente en la versión 5.0 se añadió el padding. Lo que deberíamos buscar entonces es una contraseña con valor de longitud (un valor entre 1 y 64 almacenado en el primero de los cuatro bytes), 65 bytes de datos de contraseña y luego 3 bytes de relleno o padding para mantener la alineación de 64 bits. Los datos deben contener exactamente los caracteres ASCII de la contraseña y el resto de bytes restantes deben ser ceros exceptuando el padding que tiene un valor aleatorio.

Una opción podría ser recorrer el volcado en hexadecimal mediante un editor de texto normal tipo Notepad++ y por ejemplo buscar patrones "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00". En mi caso existen 950 ocurrencias y es fácil encontrar la contraseña, o mejor dicho las contraseñas en plural porque de golpe podemos obtener las contraseñas de los dos volumenes cifrados que estaban montados en el equipo en el momento de la adquisión de memoria:
 
La otra opción sería escribir un script que busque ese patrón (en hexadecimal o en raw) o no reinvertar la rueda y utilizar alguna herramienta ya hecha (llamarme script kiddie) como cryptoscan o incluso Forensic Disk Decryptor de Elcomsoft con la que sin ningún conocimiento y por menos de 300 euros se pueden descifrar volúmenes TrueCrypt y también de BitLocker y PGP.

Conclusiones

La conclusión principal es que, una vez que un volumen cifrado de Truecrypt es montado en el equipo objetivo, la contraseña para descifrarlo queda residente en la memoria RAM y cualquier atacante puede obtenerla "fácilmente" mediante la adquisión de la misma y posterior análisis.

Recordemos que el volcado de memoria puede realizarse directamente o mediante hiberfil.sys si el equipo ha sido hibernado y, sobretodo, que no necesariamente tenemos que estar delante del equipo y validados con un usuario para obtener un volcado de la memoria.

Por ejemplo, exiten ataques DMA a través de Firewire, ExpressCard, Thunderbolt o cualquier puerto de expansión como PCI o PCI-Express que permiten el acceso directo a la memoria evadiendo las restricciones del sistema operativo debido a la especificación OHCI 1394 (spoofeando un dispositivo SBP2). O imaginad un artefacto de malware residente en el equipo que vuelque la memoria de forma oculta al usuario y envíe los datos de vuelta al servidor C&C.

Existen varios vectores de ataque y muchas posibilidades... ¿a qué hora no te sientes tan seguro sólo por tener tus datos en un volumen cifrado? ;)

Referencias:
Cyber Defense Exercise 2013: Extracting cached passphrases in Truecrypt
RAM is Key. Extracting Disk Encryption Keys From Volatile Memory
Volatility Command Reference  
TrueCrypt Volume Format Specification
Truecrypt Encryption Scheme
Truecrypt Header Key Derivation, Salt, and Iteration Count
Updated Cryptoscan for the Volatility Framework


Fuente:http://www.hackplayers.com/2013/05/extrayendo-passwords-en-memoria-de-truecrypt.html