OSINT: Localizar personas con Shodan usando "Banner Grabbing"

A estas alturas del año suelo, como tanta gente, echar la vista atrás y pensar en cuanto viví en los últimos doce meses. Pero esta vez las circunstancias me han obligado a reflexionar sobre lo que la ciberseguridad me ha dado desde que, allá por 2008, Chema Alonso y yo escribimos aquel artículo sobre “Metadatos en Microsoft Office” e iniciamos un camino que nos llevaría a concebir herramientas como FOCA o Metashield Protector.

Figura 1: OSINT - Localizar personas con Shodan usando "Banner Grabbing".

Imagen hecha con Dall-e 2 (A happy hacker in Picasso style)

A mi cabeza han acudido recuerdos de la Black Hat y la gente con la que la compartimos. De tardes enteras que pasaron como un soplo mientras yo trataba de terminar el libro de "Hacking con Buscadores: Google, Bing & Shodan + Robtex". De charlas. De la fascinación que experimenté mientras descubría cosas nuevas (nuevas, al menos, para mí). De las ganas de transmitir aquello que estaba viendo.

Figura 2: Enrique Rando y Chema Alonso en la Open Source World Conference 2008

presentando OOMetaExtractor para analizar metadatos de OpenOffice.

No sé por qué. Pero me quedé un rato pensando en un par de debates organizados por Yolanda Corral en su programa “Palabra de hacker” en los que participé. Uno era sobre “OSINT y hacking con buscadores” y allí me encontré con Vicente Aguilera, Rafael Otal, Miguel Ángel Cotanilla y John Jairo Fernández. El otro se titulaba “¿Qué es Shodan? El buscador, al descubierto” y en él compartí un rato con Eduardo Sánchez, Jorge Coronado y Miguel Ángel Arroyo. 

Figura 3: Libro de "Hacking con Buscadores: Google, Bing & Shodan + Robtex"

de Enrique Rando, publicado en 0xWord.

No sé en cuál de los dos nos preguntó Yolanda  qué era lo que más nos había sorprendido encontrar. Lo que sí recuerdo fue mi respuesta: localizar personas en Shodan. Bueno, personas, en realidad, no, pero sí sus nombres y apellidos y, en algunos casos, su dirección. Y es que los servicios técnicos de algunas operadoras ponían por entonces esa información en los "banners" de varios de los servicios de los routers de sus clientes. Supongo que para asegurarse de que no se conectaban al equipo equivocado.

Localizar personas con "Banner Grabbing"  

Hoy en día esos resultados son mucho menos frecuentes. Quizá porque se configure mejor los servicios. Quizá porque se expongan menos. Pero aún es posible encontrar algunos. Por ejemplo, en las cabeceras del protocolo FTP.

Figura 4: Servicio FTP (¡FTP!) con el nombre y la dirección

de una persona en su banner

… o en los mensajes que se muestran al pedir credenciales de acceso:

Figura 5: Autenticación para la administración que identifica al cliente

Pensándolo bien, esta reducción el número de resultados quizá se deba a que la tecnología ha evolucionado y ya no es habitual conectarse al router mediante FTP o Telnet. Si esta es la razón… ¡tenemos un problema! Porque la tecnología cambia rápidamente, pero las personas no. Y posiblemente terminemos cometiendo viejos errores con nuevas herramientas.

Figura 6: Hacking Web Applications: Client-Side Attacks
de Enrique Rando, publicado en 0xWord.

Por ejemplo, muchas organizaciones publicaron en Internet servicios de Escritorio Remoto cuando la pandemia de COVID-19 nos obligó a confinarnos y se produjo aquel boom del teletrabajo. Pantallas de inicio de sesión comenzaron a ser recogidas por Shodan y más de una mostraban la plantilla completa de un centro de trabajo o una organización:

Figura 7: Todos los compis de la oficina tienen cuenta en este equipo.

Y Shodan lo sabe.

Y, volviendo a los servicios técnicos de algunas operadoras, si aún siguen necesitando tener seguridad de que no tocan el equipamiento equivocado o la línea de una persona distinta de la que tienen al teléfono, no será raro que haya quien solucione el problema a la antigua usanza.

Figura 8: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

 
Pero parece que con el equipamiento actual es mejor hacerlo en otros puntos. Quizá en la configuración de la conexión punto a punto sobre Ethernet (PPPOE) de la operadora con cada cliente, donde es posible realizar de forma sencilla una gestión centralizada del enlace. Así que… ¿por qué no hacer en Shodan una búsqueda del tipo “pppoe garcia” o “pppoe juan”?

Figura 9: No sé por qué, pero separan los apellidos del nombre con una arroba @

En definitiva: como siempre, lo de siempre. Y esta es solo la parte que Shodan ve. No os robo más tiempo por hoy. Quizá otro día haya ocasión de hablar de los sistemas de vídeo-vigilancia que gestionan varias cámaras y etiquetan cada una con el nombre de la calle que monitoriza...

PD: Aunque no sé cuándo se publicará, ni si se publicará, escribo esto el 31 de diciembre. Así que os deseo que en el nuevo año no haya un segundo que no viváis con ilusión por el siguiente. Que vuestros días se os hagan cortos porque estéis haciendo lo que os apasiona con la gente que queréis. Y que los meses os parezcan largos cuando recordéis vuestros logros.

Autor: Enrique Rando González.

Contactar con Enrique Rando

Auditar la WiFi del hotel con resaca y un jailbroken iPhone

Durante estas vacaciones de Semana Santa regresé a mi querida isla de Tenerife para disfrutar de unos días de vacaciones con la familia. Como el objetivo de estos días era desconectar de la frenética actividad a que nos lleva esta vida en el mundo de la seguridad informática, decidí dejar el ordenador portátil en casa, y disfrutar de estos días de playa, relax y algo de copas en alguno de los locales de moda de la isla.

Figura 1: Uno de los locales de moda en la isla de Tenerife.

Tras una noche de fiesta me desperté a eso de las 9:15 con la cabeza apunto de estallar, a causa del famoso Ron Arehucas de Canarias, pero mi insomnio crónico no me dejaba dormir, así que como no tenía ninguna computadora a mano, cogí el teléfono móvil y me puse a teclear para ver qué había pasado por Internet. Tras revisar los feeds RSS de seguridad y leer un post del blog del Maligno, reparé en que el hotel en el que me alojaba disponía de una red WiFi privada según nos habían dicho. Como no tenía mucho que hacer, me entretuve en saber cuál sería el nivel de seguridad que ellos entendían por privado.

Figura 2: Portal Cautivo WiFi del hotel.

Al abrir el navegador tras conectarme a la red inalámbrica, apareció el clásico portal cautivo en el que debía introducir mis credenciales. Lo primero que me llamó la atención fue el nombre del host que aparecía en la URL de login: “gateway.example.com”. Lo siguiente que hice fue consultar el direccionamiento de la red WiFi a la que me había conectado en el apartado de Ajustes de mi iPhone, para ver si el portal estaba aplicando aislamiento de clientes a nivel IP:

Figura 3: Direccionamiento de la red WiFi del hotel

Como se puede observar en la imagen, la máscara de subred que se aplica para esta red es “255.255.0.0”, por lo que hablamos de una red de clase B con direccionamiento “192.168.0.0” y no sólo el portal cautivo o la puerta de enlace son accesibles, sino también el resto de equipos.

Además del nombre del hotel, he tapado el nombre que aparece en el apartado de dominios de búsqueda, pues parece que corresponde al de la empresa que instaló y configuró esta red. No obstante, centré mi atención en el nombre de servidor del portal, “gateway.example.com”, así que abrí la aplicación Terminal instalada en mi dispositivo con jailbreak para realizar un ping al host:

Figura 4: Dirección del servidor gateway.example.com

La respuesta al comando ping situaba la dirección IP del portal en la “192.168.2.1”, así que el siguiente paso fue hacer una petición directamente al servidor sin utilizar el nombre de host, para ver si se veía algo diferente:

Figura 5: Portal de administración de Hotspot 4ipnet

Lo que se veía en el navegador ahora ya no era la página de inicio de sesión en el portal cautivo, sino la página de administración del dispositivo que implementaba dicho portal, y que como se puede observar era del fabricante “4ipnet”. No pude reprimirme, y el siguiente paso fue buscar rápidamente en Google las credenciales por defecto, que tanto juego dan en muchos casos, para el usuario administrador de estos dispositivos:

Figura 6: Manuales de dispositivos 4ipnet con credenciales por defecto

Quería comprobar, que en efecto los administradores habrían cambiado la clave por defecto. Y en efecto, afortunadamente la combinación “admin” “admin” que se puede observar en la mayoría de manuales para los productos de 4ipnet me devolvió un mensaje de “Contraseña incorrecta. Siga probando :( “

Como también tenía instalada en mi iPhone el escaner de red para iPhone Scanny, y como este tipo de dispositivos ofrece habitualmente más servicios además del HTTP para la administración de los mismos, decidí comprobar qué otros puertos estaban abiertos:

Figura 7: Escaneo de puertos del servidor con Scanny

Además de HTTP, HTTPs y PPTP, también se podía acceder al host mediante ssh. En ese momento recordé que al buscar la contraseña por defecto para los dispositivos de este fabricante, visualizando el avance del texto para el primero de los resultados se podía entrever que además del usuario admin, existía una cuenta de root.

Si el administrador de la red WiFi privada del hotel había cambiado la password de administrador, lo suyo es que hubiera hecho los deberes y cambiado también de la de root. Si no fuera así, para un posible atacante de esta red WiFi privada sería tan fácil como elegir él mismo cómo quiere configurarse la red. Volví a abrir el Terminal, para intentar conectarme por ssh al hotspot utilizando la cuenta de root, y la clave por defecto “admin”..... Owned! Cual fue mi sorpresa al ver que éste me recibía con los brazos abiertos:

Figura 8: La clave de root no estaba cambiada

En este instante me levanté sobresaltado, con el móvil en la mano y el post de El Lado del Mal que había comenzado a leer en la pantalla. La red WiFi privada había pasado a ser un entorno inseguro donde simplemente con el móvil desde la cama y en unos minutos, un atacante podría tener acceso completo a la consola del servidor que administra la red WiFi del hotel, para desde ahí poder hacer cualquier tipo de maldad: robar información, instalar una backdoor, saltar a otros servidores o clientes de la red... al estilo NSA. Nada de cosas "complicadas" como atacar WPA/WPA2, hacer cracking de las claves WPA/WPA2 o romper un hash MS-Chapv2 PPTP por diccionario o CloudCracker en una conexión PPTP.

No iba a conectarme a esa WiFi nunca, así que recopilé todos los datos y esperé a que una buena ducha luchara contra los efectos del alcohol para notificar en la recepción del hotel que deberían cambiar esa password

Autor: Deepak Daswani
http://deepakdaswani.es
http://twitter.com/dipudaswani

DefCON 20: Crónica maligna de una muerte anunciada

Hay miles de DefCon en una sola DefCon. Tantas, como experiencias personales que viven los miles y miles de personas que asisten año tras año a estas conferencias. Dentro de mi DefCon, una de las cosas más chulas que pude vivir es ver como Moxie Marlinspike daba una charla para matar MS-Chap-v2 en conexiones VPN y WPA2-Enterprise. Todo empezó tal que así...

La noche antes de que comenzara DefCon había una fiesta para los speakers en el hotel Rio. Ese día yo tenía que hacer el cambio del hotel Caesar's Palace y me entretuve con RomanSoft y compañía tomando una cerveza, lo que hizo que llegara tarde para recoger mi badge de speaker con el que conseguir el acceso a la fiesta. No obstante, después de cinco años hablando pensé que podría intentar entrar en la fiesta sin identificación, así que de todas formas fui.

Al llegar a la entrada una chica me dijo que sin badge no podía entrar porque no sabía si yo era speaker o no. Estuve un poco tentado a utilizar el truco de Moxie en la RSA ese de "Google me!", pero no hizo falta. Uno de los Goons estaba allí, y me dijo: "Ah!, tu eres el speaker de BlackHat, te reconocí por por el gorro, pasa". Así que, en lugar de entrar por el morro, conseguí entrar por el gorro, cosas de la vida.

Una vez arriba, tras pedir una copichuela, me fui a la terraza, para encontrarme con Renderman "Hey man, look at me!", me dijo. Renderman se había cortado el pelo, y estaba tan sonriente y divertido como siempre. Junto a él estaba Moxie, "Chema is working, Chema is working", me dijo, y comenzamos a charlar un rato. 

- "¿A qué hora hablas Moxie?"

- "A las 10:00 el sábado".

- "Vaya, yo hablo a las 11:00, no vas a poder venir a mi charla, y sales en mis diapos".

- "No creo que pueda Chema, tengo el Q&A".

- "¿De qué vas a hablar? Yo tengo que ir a las 10:20 a la speaker room, pero me gustaría ver aunque fuera el comienzo de tu charla.

- "Cracking MS-Chap-v2 in VPN con PPTP y WiFis con WPA2-Enterprise".

- "Dictionary attack?"

- "No, 100 % success attack con cracking"

- "What? No lei nada de eso"

- "Ya, fue una charla de última hora".

- "Moxie, publicamos un libro de ataques de red, y enseñamos cómo hacer un ataque de cracking VPN PPTP por Diccionario.  Me vas a obligar a hacer una segunda edición!".

Figura 0: Update. Fotograma de vídeo pirata que grabó esa conversación.

Tras la conversación, seguimos con la fiesta, pero ahí me quedó marcada la noche del jueves, y quise recordarla con un tweet que puse sobre el tema...

Figura 1: Tweet sobe la conversación que mantuvimos

El día D

Llegado el sábado, decidí pasarme a ver la charla de Moxie aunque fuera solo los 20 primeros minutos, pero cuando llegué, la cola era inmensamente enorme. En mitad de ella estaba Pedro Laguna, que nos invitó a unirnos a él, pero se lo decliné: "Voy a saludar a Moxie, y le pido que me meta con él en la sala, a ver si puedo coger un buen sitio para irme pronto".

El auditorio donde Moxie iba a hablar es de unas 3.000 personas, y aún así hubo gente que se quedó fuera para ver la charla, así que por si acaso tenía un mal sitio, me encaminé a la sala de speakers. "Morning Moxie, necesito que me metas contigo". Moxie, no puso ningún problema, me hizo el favor, y por el camino, algo así como 800 metros, fuimos hablando de su charla. "Moxie, solo tengo 20 minutos, así que cuenta lo bueno al principio". "Sure".

Una vez dentro, conseguimos acoplarnos en una de las zonas centrales. Guardé unos sitios para Pedro Laguna y Kevin Mitnik, junto a nuestro amigo Gonzalo, y allí nos quedamos todos preparados para ver la charla. La foto de Ezequiel Salis, deja claro que el ambiente no era para menos. Si consigues localizarme, habrás resuelto este "Donde está Wally".

Figura 2: Aspecto del teatro desde el nivel 2. Hay tres niveles. Encuéntrame con Pedro Laguna

Tenía poco tiempo, y Moxie comenzó su charla hablando de ... delfines que protegen a los barcos, y de cómo uno de ellos le atacó porque un marine le estaba haciendo una demo mientras un soldado de frontera le apuntaba con un arma para que levantara su mano con un cepillo de dientes. Sí... Moxie contó esa historia y tuvo a todo el mundo muerto de risa durante 5 minutos.

Luego comenzó, y en menos de 15 minutos acabó con MS-Chap-v2. Tras explicar el algoritmo, con una presentación magistral, resumió lo no-disponible cuando grabas un handshake MS-Chap-v2 a solo:

- MD4(HashUserPassword)

- DES(HashUserPasswrod)+ DES(HashUserPasswrod)+ DES(HashUserPasswrod)

Figura 3: Generación de la respuesta en el handshake

Hasta el momento seguía vigente el trabajo de Bruce Schneier y Mudge, donde se muestra que se puede romper MS-Chap-v2 con un ataque de diccionario en el handshake, pero Moxie empezó a matarlo siguiendo el trabajo publicado aquí:

Paso 1) No es triple DES, es DES+DES+DES, así que será más fácil que lo imaginado. 24 bytes.
Paso 2) Claves DES son de 7 bytes, así que hemos de quitar uno de los bytes de cada una. 21 bytes.
Paso 3) El DES se hace con el Hash MD4, que es solo de 16 bytes de longitud y Microsoft rellena con ceros hasta 21. Así que el problem se reduce a crackear un DES de los 7 bytes del hash, un DES de los 7 segundos bytes del hash,  y un DES de los últimos 2 bytes. Este último paso es trivial, así que solo debemos resolver los dos primeros. 14 bytes.
Paso 4) Como no están anidados los DES, se pueden hacer en la misma iteración, con lo que sería hacer un único 2*57.

Con ese espacio, algo ya bastante más crackeable, Moxie decidió utilizar un servicio externo de HPC y listo a CloudCracker.com. En menos de 24 horas,  descifra cualquier clave MS-Chap-v2. No habían pasado los 20 minutos, y Moxie ya se lo había cargado. Impresive...

Saludos Malignos!

Tuenti Security Issues (II de V)

************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************

Issue 6: Registros PTR publicados en los servidores DNS

Dentro de los servidores DNS de Tuenti se puede ver que Primary Master es dns01.tuenti.com, uno de los servidores publicados en Internet, así que era muy probable que tuviera concentrada en él toda la información de los registros PTR. Haciendo uso de FOCA es bastante sencillo descubrir la infraestructura interna de servidores y máquinas que utiliza todo Tuenti con un PTR Scanning.



Figura 5: Infraestructura de servidores en Tuenti
El exponer la lista de cientos de servidores abre mucho más el abanico a un potencial atacante que quiera probar la seguridad, uno a uno, de todos ellos, complicando mucho más la vida de los equipos de seguridad.

Además esta lista de equipos de red se puede complementar con Shodan, ya que tienen indexados bastantes de los equipos de Tuenti en cada rango, y basta con utilizar el comando NET aplicado a los segmentos descubiertos, para tener una visión bastante completa de toda la red.

Issue 7: Servidores sin actualizar

La parte negativa de que se puedan descubrir muchos servidores con los registros PTR es que permite encontrar servidores perdidos, olvidados, o fuera de la política principal de seguridad porque son de pruebas, temporales, o, incluso, que son dispositivos IP. Mirando alguno al azar, era posible descubrir servidores Apache publicados en servidores accesible por Internet, en los que se muestran las versiones de los productos y, algunos, como en este caso, con vulnerabilidades conocidas, como esta de D.O.S. de fácil explotación con el CVE-2010-1452.



Figura 6: Servidor Sanson.tuenti.com con vulnerabilidades conocidas
Es suficiente con revisar el ChangeLog completo de Apache para ver todos los CVE que le afectan a la versión que estaba publicada.

Issue 8: Los metadatos

No podría dejar de mirar los servidores de Tuenti con la FOCA sin poner un ojo en la recomendación del Esquema Nacional de Seguridad sobre los Metadatos, para ver si estaban haciendo uso de alguna política de limpieza de documentos antes de publicarlos.



Figura 7: Metadatos en documentos publicados en Tuenti
Basta con buscar algunos de los documentos en PDF publicados en Internet, y descubrir nombres de usuarios, versiones del software que han comprado para utilizar en la organización, y quién lo usa, etcétera.

Issue 9: La transferencia de datos del perfil sin HTTPs

Una de las cosas que más problemas genera es la no posibilidad ni por defecto, ni configurándolo, de utilizar conexiones HTTP-s entre el usuario y los servidores de tuenti. Esto hace que cualquier cosa que se transmita pueda ser escuchada y capturada en una red insegura. Quiero centrarme en el término de red insegura, porque a veces los responsables de infraestructuras lo utilizan para pasar responsabilidades de la compañía al usuario – no he dicho que sea el caso de Tuenti -.

Una red insegura es aquella que no ofrece garantías a sus usuarios sobre la seguridad de sus comunicaciones porque no hay garantía que un atacante pueda capturar los datos o manipularlos.

Así, bajo esta definición de redes seguras nos quedarían un puñadito nada más, en las que, por ejemplo entrarían las redes TCP/IP que usan IPSec (con certificados digitales o Kerberos, no con PSK), las redes WiFi que no usan WPA/WPA2-Enterprise con EAP, las redes WIFI con WPA/WP2 con una contraseña no crackeable [WPA/WPA2 Craking] - ya que pueden ser atacadas con man in the middle [Atacar WPA/WPA2 PSK] - y las que se hacen con redes PPTP con SSTP, PPTP con passwords no crackeables y con L2TP/IPSec. El resto serían inseguras.

Eso sí, ésta red “segura” lo sería solo hasta el operador, ya que después no hay garantía ni control más allá de la red, y sucedería lo mismo con la conexión del servidor VPN a los servidors de Tuenti. Además tendríamos que quitar de la lista las conexiones VPN con L2TP/IPsec y PPTP en aquellas redes como hoteles, universidades, etcétera, donde los puertos de conexión estén bloqueados. Las 3G y GPRS deberíamos dejarlas también fuera por los problemas con GSM con A5/0 y A5/1, y por supuesto las redes WPA/WPA2-PSK en las que seamos más de 1 usuario, ya que se podrían hacer ataques de Mitm.



Figura 8: Gráfico de conexiones "seguras"
En este ejemplo, asumiento Internet como red Insegura, los datos del usuario pasarán siempre en abierto, una vez salga de la "red segura" del usuario o de la "red segura del servidor VPN" que usa el usuario.

Tras esta reducción de redes seguras nos queda:

a) Aceptar que el sistema no ofrece privacidad alguna, como en los correos SMTP/POP3, y eso debería dejarse claro cuando se solicitan datos de caracter personal o mensajes privados de los usuarios.

b) Asumir que el servidor se ha diseñado solo para unos pocos afortunados que tienen suerte de que ningún ataque a un Router mueva tráfico a China o algún insider de un operador tenga una tarde graciosa y publique en pastebin los datos de las sesiones de tuenti que pasen por su red.

c) Poner HTTPS con certificados de validación extendida y protocolos de cifrado robustos para extender la seguridad de la red hasta el usuario.

Es por eso, que lo más fácil para mejorara la seguridad es montar HTTP-s y que justificarlo con un “no te conectes desde una red insegura” es una falacia. Evidente, la falta de Http-s en la transferencia de datos no solo afecta a la privacidad de la información intercambiada, como fotos, mensajes, chats, comentarios en muros, etcétera, sino a los datos de la sesión del usuario, lo que hace que sea fácil perpetrar ataques a la cuenta del mismo.

El usuario debe por tanto tener extremado cuidado con la red que utiliza para conectarse, si valora su privacidad y qué datos envía. Este problema, lo han tenido la mayoría, si no todas, de las redes sociales, aunque muchas ya han optado y están optando por poner HTTP-s opcional, cuando menos, para los usuarios más preocupados, y Tuenti lo pondrá no tardando mucho, seguro.

************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************

Cuidadín con el "Linkedín" en las conferencias de "hackín"

Linkedin es una de esas redes sociales supuestamente creadas para no ligar. Sí, y sorprendentemente funciona, pero lo cierto es que su éxito se debe a que la gente también la usa para ligar. Por eso yo también tengo Linkedin. Así es la vida.

Ayer, en Naked Security se quejaban de que la opción por defecto de permitir ver el correo electrónico de los participantes en un mensaje debería tener el otro valor por omisión. Es decir, que debería venir desmarcado el check box para que no dependiera del usuario, que se podía descuidar como deja bien claro que le sucedió a su compañero Pablo, que tiene su base en Madrid - ¡Pablo, estamos contigo! -.

El caso es que Linkedin me tenía bastante rayado tiempo ha, porque la página web de login era vulnerable a SSLSTrip y la sesión iba en HTTP, y, sin embago, en las conferencias de seguridad y hacking, mientras tiene lugar el evento, siempre me llegan invitaciones de asistentes o ponentes a la misma.

El tema del SSLStrip

Realmente, si nos ponemos finos, todas las webs pueden ser vulnerables a SSLStrip, ya que realmente es un ataque Man in The Middle que se realiza por la red para quitar los enlaces https. Cuando yo me refiero a que una web es vulnerable a SSLStrip es porque tiene el problema de los puentes, es decir, que el usuario teclea su login y password en un formulario servido por HTTP esperando que cuando se haga clic en el botón de login aparezca, al más puro estilo de Indiana Jones y la Última Cruzada, el puente salvador que permita llegar a por el Grial.


Figura 1: Login SSLStripeado
Esto ha sido así hasta hace nada, ya que acaban de poner el login seguro. No puedo deciros exáctamente cuando hicieron el cambio, pero en la Troopers 2011 Steve Dispensa y yo estuvimos charlando sobre este caso y analizándolo para su demo de Phone Factor, y ayer, el login seguro llevaba menos de 24 horas.


Figura 2: Login Seguro en Google
Sin embargo, todavía es posible encontrar logins en Linkedin sin usar Https en el formulario de introducción de passwords, como este para los developers.


Figura 3: Developers login en Linkedin
Además, cuando se recibe una invitación para estar conectado y se acepta o se visita el perfil, el login que propone linkedin es también con un formulario visualizado bajo Http en http://www.linkedin.com/mbox


Figura 4: formulario de acceso a linkedin bajo http
El tema del Firesheep

Lo que sigue estando presente es que, una vez conectado, la sesión va en Http, así que decidimos hacer un pequeño script para que rulara el Firesheep, y nuestro amigo madridista "Culé hasta la médula" Daniel Romero, entre auditoría y auditoría, se puso con el Burp a usar el repeater para descubrir cuál es la cookie que permite mantener la sesión abierta. Y helo aquí.


Figura 5: Linkedin Firesheepeado
// Author: Informática64 - www.informatica64.com
register({
name: "Linkedin",
url: 'http://www.linkedin.com/',
domains: [ 'linkedin.com' ],
sessionCookieNames: [ 'leo_auth_token' ],
identifyUser: function () {
var resp = this.httpGet(this.siteUrl);
this.userName = 'LinkEdin User';
this.userAvatar = 'http://bitelia.com/files/2010/09/linkedin-logo.jpg';
}
});

Además, adoleciendo del problema que tienen muchos servicios en Internet que funcionan con arquitecturas cluster o en la nube, la muerte de la cookie dura mucho más allá del cierre de la sesión, con lo que es posible seguir controlando el perfil.

Uvepeeneate

La solución pasa por no usar Linkedin en una conferencia de hackers si no es a través de una VPN segura - nada de conexioens VPN vulnerables a man in the middle y cracking -, que como se ponga de moda el tener perfíles de hackers o gente de seguridad que tiene su perfíl en Linkedin esto puede ser una escabechina.

Saludos Malignos!

Crackear conexiones VPN PPTP MS-CHAPv2 (III de III)

***********************************************************************************************
- Crackear conexiones VPN PPTP con MS-CHAPv2 (I de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (II de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (III de III)
Autores: Juan Luis G. Rambla MS MVP Security & Chema Alonso
***********************************************************************************************

Ataque con asleap + ettercap paso a paso (continuación)

Antes del inicio de la comunicación, se comprueba que el único mecanismo de autenticación admitido por el cliente es MS-CHAP v2. Sería factible un ataque adicional en la que tanto el cliente como el servidos admitieran MS-CHAP y MS-CHAP v2generando una degradación de la autenticación a MS-CHAP v1, que es más sencillo. En el mismo, aunque la negociación cliente-servidor determinará que la mejor autenticación sería MS-CHAP v2 un atacante en medio podría re-negociar la comunicación entre ambos extremos para degradarlo a MS-CHAP, más vulnerable.


Figura 6: Selección de autenticación MS-CHAP v2
Al mismo tiempo que se produce el proceso de autenticación el atacante está recibiendo los datos del proceso de autenticación.


Figura 7: Conexión PPTP establecida
La información obtenida por Ettercap con los datos correspondientes a la autenticación del usuario administrator, se recogen en la Figura 8. En ella se ven los datos correspondientes al desafío y la respuesta derivada del hash NT de la contraseña de este usuario. En este caso la passrord es admin. No es utilizado en esta circunstancia el hash Lan Manager que, como se puede ver, aparece relleno con ceros.


Figura 8: Captura Hashes. Challenge y Response del usuario administrator
Crackeo de la password

Los datos recuperados se pueden utilizar para la realización del ataque de diccionario, con los ficheros creados previamente con Genkeys. Para ello además del fichero de hash y el de índice, se proporcionan los datos de desafío y respuesta tal y como pueden ver en la siguiente figura.


Figura 9: Ataque offline a la autenticación con asleap
Evidentemente la contraseña empleada, admin, es lo suficientemente débil para el ataque sea eficaz en poco tiempo. Otros tipos de contraseñas requerirían un esfuerzo desmesurado para obtenerlas.

Conclusiones

Los requistios de seguridad sobre las conexiones VPN son cada día mayores, así que para evitar esta debilidad se pueden utilizar la siguientes soluciones:

- PPTP-MSCHAPv2 con una contraseña robusta: Si no se puede cambiar la tecnología, debe utilizarse una contraseña que sea de gran longitud y complejidad para evitar ataques de diccionario o fuerza bruta. Intentar utilizar passphrases en lugar de passswords cortas.

- PPTP-EAP-TLS o PEAP-MSChapv2 [TLS-EAP-MSCHAPv2]: Otras alternativas para fortificar el proceso de negociación de credenciales es el uso de certificados digitales en el proceso de autenticación de usuarios [EAP-TLS] o cifrar el canal con TLS antes de la negociación de autenticación [Protected-EAP -> PEAP. Cunado se usa MSCHAPv2 después se llama PEAP-MSCHAPv2 o es también llamado TLS-EAP-MSCHAPv2].

- L2TP/IPSec: Para evitar la interceptación del tráfico que se genera en el momento de la negociación de la autenticación se puede utilizar IPSec (no IPSec-PSK) para cifrar y autenticar las máquinas.

- SSTP (Secure Socket Tunneling Prococol): Si hay problemas con la apertura de puertos en las conexiones desde hoteles, se puede utilizar el sistema SSTP, que cifra y autentica todo el tráfico con HTTP-s. En las máquinas clientes Windows está de serie desde Windows Vista Service Pack 1.

- DirectAccess: Establece VPNs utilizando IPv6, viene de serie con Windows Server 2008 R2 y Windows 7.

- EndPoint Security: En el caso de querer una VPN que protega al servidor y la red central contra la conexión de máquinas inseguras, desprotegidas o no válida, se pueden implementar soluciones como MS Forefront Unified Access Gateway UAG 2010 que implementa soluciones de comprobación de la salud del cliente y de redes de cuarentena, permitiendo establecer diferentes niveles de conexión. MS Forefront UAG 2010 también implementa Direct Access.

***********************************************************************************************
- Crackear conexiones VPN PPTP con MS-CHAPv2 (I de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (II de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (III de III)
Autores: Juan Luis G. Rambla MS MVP Security & Chema Alonso
***********************************************************************************************

Crackear conexiones VPN PPTP MS-CHAPv2 (II de III)

***********************************************************************************************
- Crackear conexiones VPN PPTP con MS-CHAPv2 (I de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (II de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (III de III)
Autores: Juan Luis G. Rambla MS MVP Security & Chema Alonso
***********************************************************************************************

Ataque con asleap + ettercap paso a paso

En este sentido la aplicación asleap, creada originalmente para atacar los procesos de autenticación Wifi de Cisco para el protocolo LEAP, fue modificada en 2007 para poder atacar el proceso de autenticación MS-CHAP v2. Para esta demostración se hace uso de esta herramienta, junto con la aplicación Ettercap que se será la utilizada para la realización del ataque MITM. En todo este ejemplo se utiliza el LiveCD Backtrack que contiene, desde el año 2008, ambas herramientas. En este ejemplo se usará Backtrack 4.

El ataque es de tipo diccionario, por lo que es necesario crear previamente los ficheros de hashes e índices asociados al diccionario de terminos. Este diccionario es, simplemente,un fichero de texto plano que contendrá las palabras a probar. La generación del fichero de índices y hashes se construye con la utilidad genkeys que viene conjuntamente con asleap. La siguiente imagen muestra la generación de los ficheros de hashes e índices.


Figura 1: Generación de los ficheros de hash e índice con genkeys
Como se ha comentado previamente, el ataque de MITM se realizará mediante Ettercap. Esta herramienta dispone de un plugin que permite extraer el intercambio de desafío y respuesta de una conexión VPN PPTP. El procedimiento para la realización del ataque de hombre en medio sigue la secuencia habitual:

- Habilitar el sniffing.
- Seleccionar los equipos a envenenar.
- Iniciar el envenenamiento.

Las siguientes 4 imágenes muestran estos procesos.


Figura 2: Preparación ataque MITM


Figura 3: Selección de objetivos para el envenenamiento


Figura 4: activación de envenenamiento


Figura 4: ARP Poisoning en proceso
***********************************************************************************************
- Crackear conexiones VPN PPTP con MS-CHAPv2 (I de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (II de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (III de III)
Autores: Juan Luis G. Rambla MS MVP Security & Chema Alonso
***********************************************************************************************

Crackear conexiones VPN PPTP MS-CHAPv2 (I de III)

***********************************************************************************************
- Crackear conexiones VPN PPTP con MS-CHAPv2 (I de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (II de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (III de III)
Autores: Juan Luis G. Rambla MS MVP Security & Chema Alonso
***********************************************************************************************

PPP, L2TP, PPTP

El termino VPN , va unida desde su origen a la de seguridad. Sin embargo este axioma no se cumple en todas su facetas. La conexión de redes virtuales privadas, definen eso, una conexión “segura” a través de un medio inseguro como puede ser Internet. Pero ¿cuál es verdaderamente la seguridad que ofrecen?

En los sistemas tradicionales que han soportado los escenarios Microsoft para clientes VPN, el encapsulamiento se realizaba a través del protocolo de capa 2 Point to Point Protocol (PPP). La realización del túnel se realizaba mediante los protocolos Point to Point tunneling Protocol (PPTP, propietario de Microsoft) o Layer 2 Tunneling Protocol (L2TP, estándar IETF). Ni PPTP ni L2TP describen mecanismos de cifrado o autenticación, dejando esta tarea al protocolo PPP.

De cara a la autenticación, PPP depende de los protocolos de autenticación implementables. Para escenarios Microsoft, los mecanismos admitidos son: PAP, SPAP, CHAP, MS-CHAP / MS-CHAPv2 y EAP-TLS. Excepto para el último, que implica una solución con infraestructura PKI, existen ataques conocidos que permiten recuperar una autenticación de usuario y contraseña, mediante la implementación de diferentes ataques.

L2TP, inicialmente, no ofrece mejoras ostensibles con respecto a PPTP, por lo que no aportaba ninguna solución adicional de seguridad que las planteadas ya inicialmente. La gran diferencia entre PPTP y L2TP es que el primero, utiliza como protocolo de enrutado a GRE mientras que el segundo utiliza IP. Es decir, si hay una conexiónn PPTP o L2TP/IP no se autentica a nivel de máquina, por lo que el tráfico podría ser manipulado con ataques MITM haciendo que pasara por máquinas de atacantes. Este escenariio deja toda la seguridad de la conexión en manos de la robustez del cifrado a nivel PPP y de la fortaleza del sistema de autenticación.

Consciente de este hecho, Microsoft decidió en su momento utilizar L2TP en su variante con IPsec, que garantizaba una mayor seguridad mediante encapsulamiento, cifrado y firmado en capa 3. El uso de IPSec, no en su variante Pre-Shared Key, para autenticar las máquinas de la conexión, impediría la manipulación del tráfico por medio de técnias de Man In The Middle, dificultando cualquier posible ataque. Sin embargo, el protocolo PPTP deposita la seguridad en PPP, que será el encargado de garantizar el proceso de autentificación y cidfrado y la autenticación no se hace a nivel de máquina.

Debilidades

Como ya se ha dicho, la conexión PPTP es susceptible a un ataque de Man in the Middle (MITM), lo que implicaría el posible robo del intercambio de información de autenticación que tuviera lugar al inicio de la conexión VPN. Puesto que PPP no ofrece ninguna garantía de cifrado al proceso de negociación de la autenticación, la seguridad recae sobre el mecanismo de autenticación elegido.

Los sistemas CHAP, PAP, SPAP cuentan, desde hace tiempo, con vulnerabilidades conocidas que permiten su explotación y sólo deben implementarse en entornos "legacy" como solución de compatibilidad y, por supuesto, tomando medidas de protección añadidas.

En el caso de sistemas MS-CHAPv2, Bruce Schneier, Mudge & David Wagner publicaron en 1999 un paper llamado "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2) en el que se explican las debilidades de las implementaciones MS-CHAPv1 y MS-CHAPv2. Este trabajo fue continuado por Jochen Eisinger que publicó en 2010 "Exploiting known security holes in Microsoft's PPTP Authentication Extensions (MS-CHAPv2) en el que se describe el algoritmo que hay que implementar para realizar una ataque con éxito a un proceso de autenticación MS-CHAPv2 mediante una explotación offline. Es decir, una vez grabada la sesión.

Resumen del proceso MS-CHAPv2

MS-CHAPv2 proporciona autenticación mutua con la generación de claves de cifrado de datos iniciales más seguras para el Cifrado punto a punto de Microsoft (MPPE) y diferentes claves de cifrado para los datos enviados y los datos recibidos. La autenticación se basa en el método desafío respuesta:

1. El cliente solicita un desafío del servidor.

2. El servidor devuelve un desafío aleatorio de 16 bytes.

3. El cliente genera un número de 16 bytes aleatorio denominado "Peer Authenticator Challenge".

4. El cliente genera una clave de 8 bytes partiendo del desafio recibido previamente del servidor, el generado por el equipo cliente y la cuenta de usuario.

5. La respuesta de 24 bytes, es generada utilizando la funcoón del hash NT de Windows y la clave generada en el paso 4.

6. El servidor utiliza el hash de la contraseña del usuario almacenada en la base de datos para descifrar la respuesta. Si el bloque descifrado coincide con el desafío, el cliente es autenticado.

7. El servidor utiliza la clave de 16 bytes del cliente y el hash de la contraseña para crear una respuesta del autenticador de 20 bytes.

8.- El cliente procesa una respuesta del autenticador. Si la respuesta procesada coincide con la respuesta recibida, el servidor es autenticado.

Puesto que PPP no aporta un sistema de cifrado adicional al proceso de negociación de la autenticación, este procedimiento del intercambio de claves puede ser interceptado mediante una ataque MITM para realizar un ataque offline a posteriori.

Una contraseña corta y débil podrá ser obtenida con mayor eficacia que una contraseña más larga y compleja. El mejor algoritmo basado exclusivamente en usuario y contraseña es MS-CHAPv2, pero incluso éste es susceptible a un ataque basado en diccionario.

***********************************************************************************************
- Crackear conexiones VPN PPTP con MS-CHAPv2 (I de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (II de III)
- Crackear conexiones VPN PPTP con MS-CHAPv2 (III de III)
Autores: Juan Luis G. Rambla MS MVP Security & Chema Alonso
***********************************************************************************************