La década de Yahoo! en el trono de la Web

El otro día vi un vídeo de esos que hacen estadísticas sobre todo, aprovechando los datos de webs como Statista, y me sorprendió ver lo que mostraba. Se trataba de ver el TOP 10 de webs con más tráfico desde el nacimiento de Internet hasta hoy en día. Los datos se muestran mes a mes y pensé que no me iba a sorprender lo que viera, pero.. sí, sí que me sorprendió.

Figura 1: La década de Yahoo! en el trono de la Web

Saber que Yahoo! había sido el WebSite con más tráfico no era algo nuevo para mí. Estuve invitado a la Yahoo! Security Week allá por el año 2009 y pude conocer de primera mano mucha de la grandeza de esa compañía. Según los datos, alcanzó el número 1 de los WebSites más visitados en el año 2.000. En Junio del año 2.000. Cuando yo cumplía 25 años. 

Está claro que Yahoo! es la ganadora de la llamada época de las ".COM", donde los portales horizontales y verticales comenzaban a inundar la red. Portales de contenido. Contenido creciendo de manera exponencial. Y como consecuencia, los buscadores, para que los usuarios llegaran de la forma más rápida a la información más precisa.

Figura 2: Top 10 de Junio de 2002

De aquella época de las .COM, con las arquitecturas de aplicaciones de tres capas, que venían con sus servidores de base de datos Oracle, sus servidores de aplicaciones en entornos como BEA WebLogic con frontales HTTP/S, y sus servidores SUN Microsystems. Una época donde las empresas ganadoras parecían auténticos monstruos que iban a ser los reyes durante mucho tiempo.

Lo cierto es que en aquella época, los datos de tráfico web son bastantes "pequeños" comparados con los que tenemos hoy en día. En aquellos momentos aún no había llegado la movilidad, no habían llegado las apps, y las nuevas formas de utilizar Internet. Lejos estaba la Web 2.0 aún. Estábamos en ".COM", a los pocos años de haber nacido la World Wide Web.

En el año 2006, justo en los albores de la Web 2.0 y la llegada masiva de la movilidad, de iPhone, el 3G, y las redes sociales con clientes móviles, Google consiguió adelantar un mes en tráfico a Yahoo!, pero volvió a ponerse por delante, y en Junio de 2006, Yahoo! estaba otra vez en al cabeza. Ya no hablábamos de .COM. Ya Sun Microsystems no era tampoco la empresa que había sido antes. Y tampoco la forma de hacer aplicaciones. 

Figura 3: Top Ten en Mayo de 2006

Ya no hablábamos de arquitecturas en tres capas, sino de BigData, de High Perfomance Computing, y los albores del Cloud Computing. Acababa de nacer apenas unos meses atrás AWS, proponiendo una nueva forma de hacer aplicaciones escalables, además de ver que el interfaz web iba a dar cada vez más paso al Internet móvil. Pero Yahoo! aguantó en la web.

Figura 4: Top Ten en Junio de 2010

Y aguantó hasta el año 2010. Junio de 2010 y Yahoo!, ya con números de 11.5 B de usuarios por mes, seguía aguantando a Google en la cabeza de lista. Ya estaba, como podéis ver, Facebook, Amazon, Youtube y Google, apretando los números.  Y desde ahí, Yahoo! ha ido perdiendo tráfico. 

En Enero de 2022, el Top 5 lo forman Google, Youtube, Facebook, Twitter e Instagram. Y Yahoo! aguanta con 3.5B , mucho menos de lo que llegó a ser, peleando por no ser adelantado por XVideos, y sobre todo teniendo en cuenta que Google va por 90B de usuarios mes. Un crecimiento brutal.

Figura 5: Top Ten en Enero de 2022

Sin embargo, el mundo ya no es "Web", ya hay mucho mundo móvil, donde otras plataformas como TikTok tienen mucho que decir en el mundo móvil, o con mundos virtuales que cierran el tráfico en sus apps, o con los nuevos mundos virtuales descentralizados que comienzan poco a poco a crecer. Hay que tomarse esta gráfica como lo que es, una simple visión puntual reflejo de un cambio, que no es todo lo que ha pasado en estos años, pero sí que es reflejo del cambio continuo y agresivo de esta era digital en la que vivimos, donde las revoluciones duran... unos años.

Al final, este artículo solo es un recordatorio para ver que cuando llegan los cambios tecnológicos, luchar con el éxito es un problema para todas las empresas. Los ganadores de la Web, de las .COM, o de la Web2.0 no tienen porque ser los ganadores en esta nueva evolución. Ya veremos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Time-Based "Browser-Based" Cross-Site Search Attacks

Tal vez el título te pueda llevar a confusión, o tal vez parecerte un galimatías para solo tipos raros, pero la verdad es que es el más ajustado para representar una de las técnicas que fueron publicadas en la pasada BlackHat USA 2016 - ya os avisé que los hackers son para el verano - para robar información personal que tengas guardada en tu buzón de correo electrónico.

Figura 1: Time-Based "Browser-Based" Cross-Site Search Attacks

Ya sabéis que es cuestión habitual utilizar el almacenamiento en el buzón de correo electrónico como repositorio documental para muchas personas. Se dejan ahí los mensajes de e-mail con adjuntos importantes o con contenido relevante. Es una práctica habitual que hay que proteger contra los posibles ataques de RansomCloud o contra el robo simple de credenciales. Pero también contra el robo de los datos por medio de la técnica que cuenta esta historia.

Figura 2: Cómo una web maliciosa roba datos de Facebook con un Time Info-Leak

Los que habéis estado atentos, recordareis que no hace mucho os hablaba de las técnicas de Time-Based Browser-Based para robar información de redes sociales como Facebook, Linkedin o Twitter. La idea era tan sencilla como medir en el WebBrowser tiempos de acceso a la caché o de conversión de vídeo de un contenido recibido desde una web para saber si ese contenido tenía un tamaño grande o pequeño. El resto del trabajo era tan sencillo como forzar al navegador a cargar un contenido de Facebook, o Linkedin, restringido por algún patrón (por ejemplo la edad como se describe en la Figura 2) y midiendo los tiempos para saber si se le había dado acceso al documento o no se podría saber la edad del visitante.

Figura 3: Diapositivas de la presentación en BlackHat USA 2016

Ahora en el trabajo publicado en BlackHat se da una vuelta de tuerca un poco mayor, ya que aplican el mismo tipo de sistema, pero a las búsquedas de contenido en los buzones de correo electrónico. Es decir, una víctima visita una página maliciosa mientras tiene su sesión de Google o de Yahoo! abierta en el navegador. A partir de ese momento la web realiza una búsqueda de contenido en el buzón de Gmail o de Yahoo! y no va a poder ver el contenido devuelto por la búsqueda, pero sí que va a poder saber si ha tardado más o menos, por lo que tendrá la posibilidad de conocer si el resultado ha sido positivo o negativo.

Figura 4: Medición de tiempos para respuestas True y False

Entre las cosas que se pueden buscar se encuentran desde mensajes enviados de una determinada persona o el contenido dentro de ellos, como por ejemplo los números OTP de recuperación de una cuenta de Facebook u otra. Por supuesto, no parece sencillo averiguar todos los números pero si se envían mensajes controlados al buzón de la víctima sería posible, tal y como han explicado en su presentación.

Figura 5: Ataque sobre Yahoo! Mail para sacar el OTP de Facebook

En Gmail ya han cerrado la posibilidad de realizar las búsquedas desde otras webs mediante la llamada de la API, pero la técnica también funciona con el mismo autocompletar que lleva incorporado el interfaz de Gmail.

Figura 6: El ataque realizado sobre el formulario de autocompletar de Gmail

Al final, cualquier info-leak basado en tiempo va a poder ser aprovechado de forma similar, así que no es de extrañar que veamos nuevas formas de sacar información de tus sesiones abiertas de otros lugares así. Por lo tanto, evita navegar con múltiples pestañas y múltiples sesiones abiertas en ellas que ya has visto lo que puede pasar.

Saludos Malignos!

Cómo localizar cuentas en Twitter por número de teléfono #stalkers

Hace unos días publicaba un artículo en el que explicaba cómo era posible localizar cuentas de Facebook a partir de su número de teléfono, que completaba la búsqueda de números de teléfono que se puede hacer en Facebook. Con esa misma idea fui a ver qué sucedía en Twitter, y la verdad es que aunque no es exactamente igual, se pueden hacer cosas bastante curiosas. Aquí os dejo unas ideas por si os sirven de ayuda.

Figura 1: Cómo localizar cuentas en Twitter por número de teléfono #stalkers

Paso 1: Localizar si un teléfono está asociado a una cuenta de Twitter

Esto resulta bastante fácil, aunque no nos va a permitir saber a qué cuenta pertenece en concreto. Eso habrá que ver si es posible sacarlo en una segunda derivada. Para saber si el número de teléfono está asociado a una cuenta de Twitter basta con ir a las opciones de Login.

Figura 2: Login en Facebook usando número de teléfono

Como se puede ver, al igual que en Facebook, puedes autenticarte usando el número de teléfono y esto no se puede evitar con ninguna opción de seguridad de las que tienes en Twitter, así que si tienes asociado tu número de teléfono vinculado en Twitter, se puede intentar hacer login con él. La única opción es desvincular el número de teléfono de la cuenta, eliminado así la posibilidad de utilizar un Segundo Factor de Autenticación basado en mensajes SMS ni la recepción de alertas vía SMS - aunque sí que podrás seguir usando 2FA basado en la app de Twitter para el smartphone -.

Figura 3: Forgot my password con número de teléfono

Como en el caso de Facebook, basta con intentar recuperar la contraseña y poner el número de teléfono de la persona que se busca, para ver si existe o no existe ese número de teléfono en Twitter. Si existe, se obtendrán las opciones de recuperación disponibles que serán, ver los últimos números de teléfono - un poco sin sentido cuando has dado el número de teléfono para localizar la cuenta -, pero además se podrán parcialmente datos de la cuenta de correo electrónico asociados.

Figura 4: Datos parciales de cuenta de correo electrónico asociado a número de teléfono

Con esos datos parciales de la cuenta de correo electrónico, ya estamos más cerca de sacar la cuenta de Twitter asociada.

Paso 2: Localizar la cuenta de correo electrónico asociada en Twitter

Viendo las opciones de recuperación en Twitter, se puede ver que la cuenta de correo muestra los dos primeros caracteres del nombre y el primero del dominio. Aún, con Facebook, se podría sacar el TLD, para saber si es .ES, . COM, o .NET, como en este caso.

Figura 5: En Facebook sale el TLD del correo electrónico

A partir de aquí toca "averiguar" el resto de la cuenta de correo electrónico. Si no eres capaz de localizar el resto de los caracteres de la cuenta de correo electrónico la cosa estará difícil. Para ello, utiliza todo el conocimiento que tengas de esa persona y todo lo que hayas podido sacar de otras cuentas, por ejemplo en Facebook. Será como jugar a la Ruleta de la Fortuna.

Figura 6: Jugar a la ruleta de la fortuna o seguir buscando info en otras redes sociales

Para probar que estás en lo cierto con tu suposición, deberás volver a intentar recuperar la cuenta de Twitter, utilizado ahora la cuenta de correo que crees que está asociada a ese número de teléfono. 

Figura 7: Buscar información de recuperación de cuenta Twitter utilizando correo electrónico

Si es la que cuenta que tú suponías, entonces llegarás exactamente a las mismas opciones de recuperación de cuenta que salieron cuando introdujiste el número de teléfono.  Tanto si has sido capaz de descubrir la dirección de correo electrónico como si no has sido capaz, puedes intentar descubrir la cuenta Twitter con el último paso.

Paso 3: Localizar la cuenta de Twitter asociada a esa dirección de correo electrónico

En Twitter hay dos opciones para permitir que te localicen. Una de ellas es por medio de correo electrónico y otra por medio de número de teléfono. Si la cuenta ha sido fortificada y ha eliminado estas dos opciones, entonces no podremos seguir.

Figura 8: Opciones de visibilidad de cuentas Twitter para que te localicen

Sin embargo, si ha dejado la opción por defecto para localizarle por correo electrónico y número de teléfono, el proceso es sencillo. Basta con ir a Encontrar Amigos en Twitter.

Figura 9: Encontrar amigos vía agenda de contactos de cuentas de correo elecrtrónico

Yo tengo una cuenta de Yahoo! creada especialmente para eso. En ella pongo en los contactos entradas de las direcciones de correo y números de teléfono que deseo localizar. Una vez la tengo dada de alta, le pido a Twitter que busque mis amigos de mi cuenta de Yahoo!

Figura 10: Cuenta de Twitter localizada a través de contacto de agenda de Yahoo!

Si esa cuenta de Twitter tiene por defecto la opción de que le localicen por correo electrónico, entonces obtendremos cuál es la cuenta de Twitter que está asociada a esa cuenta de correo, que a su vez estaba asociada a ese número de teléfono.

Corolario sobre el descubrimiento por número de teléfono en Twitter

Como habéis visto, en las opciones de Twitter que se ven en la Figura 8, hay una opción para permitir que te busquen vía número de teléfono, y según dice la ayuda esta información por defecto deja que te localicen vía correo electrónico o número de teléfono - si hay alguno vinculado a la cuenta -.

Figura 11: Por defecto te pueden localizar por e-mail y número de teléfono

En la API normal de Twitter no he localizado forma de hacer esa consulta en USER LOOKUP, pero creo que dejando marcada la opción de que te localicen por número de teléfono, Twitter puede permitirle esto a terceros con APIs comerciales - o directamente con la búsqueda de de amigos- , así que mi recomendación es que lo quites. De hecho, la información que da en la ayuda al respecto es bastante clara.

Figura 12: Cómo Twitter usa tu teléfono y correo electrónico con terceros

Recordad que Twitter necesita tu número de teléfono - así como el resto de anunciantes necesitan tu cuenta Twitter si ya tienen tu número de teléfono - para poder ponerte anuncios en función de los cereales que desayunas por la mañana o si vas a tener un bebé.

Saludos Malignos!

HackerOne: Un "Broker" para reportar bugs y ganar dinero con Bug Bounties

Hoy os quiero hablar HackerOne, una plataforma que facilita la comunicación entre el equipo de seguridad de una empresa con profesionales o con principiantes en la seguridad informática también llamados hackers. Gracias a HackerOne se han corregido miles de fallos y actualmente se ha pagado 2.49 Millones de Dólares o 2.30 Millones de Euros.

Figura 1: HackerOne: Un "Broker" para reportar bugs y ganar dinero con bug bounties

Entre las empresas que podemos encontrar hay algunas muy famosas como Twitter, Yahoo!, Dropbox y la propia HackerOne inclusive. Además, hay un programa financiado por organizaciones preocupadas por la seguridad de los demás llamado Internet Bug Bounty, que básicamente está enfocado al reporte de bugs que afectan a todo Internet, como los casos de Heartbleed o ShellShock.

Funcionamiento de HackerOne

Del dinero que se paga por los bugs descubiertos un 20% se lo lleva HackerOne, como broker de reporte. A cambio de ese 20% HackerOne se hace responsable de que al hacker le llegue todo el dinero, evitando los formularios de impuestos y demás quebraderos de cabeza. Por lo que tu equipo no tiene que preocuparse en que los hackers sean pagados y puede centrarse en trabajar. A día de hoy estas son las estadísticas de la web:

Figura 2: Estadísticas de HackerOne

Supongo que estaréis pensando, ¿solo hay 83 empresas registradas? En realidad no, además de programas públicos en los que cualquiera puede participar también hay programas en los que solo se puede acceder por invitación, ya sea porque  quieren tener controlados el número de usuarios, estén probando HackerOne o simplemente no quieran aparecer en la lista de programas.

Muchas de las empresas dan recompensas que van desde los 10 a 20.000 dólares y ese dinero lo puedes pasar a una cuenta de Paypal, un monedero de BitCoins o donarlo a una organización de caridad. La edad mínima para cobrar un premio es de solo 13 años.

Figura 3: Interface de reporte de bugs

Os dejo una captura de pantalla en la que se muestra un reporte realizado a HackerOne por un usuario. Como podéis observar la interfaz es simple. Si ponemos el cursor encima de un nombre de usuario veremos información básica sobre el: el número de bugs encontrados - sólo los aceptados -, las veces que le han dado las gracias y la reputación que tiene.

Gestión de la reputación en HackerOne

La reputación es calculada en base al número de reportes aceptados, los no aceptados por duplicados o porque el bug no existe.

Ganas reputación si:

● Tu reporte es cerrado como “Resuelto”: +7 (Si te han premiado aumenta)
● Tu reporte es cerrado como “Duplicado ( Resuelto) “ Solo se aplica si se envio antes de que el otro reporte fuera solucionado.
● Tu reporte es cerrado como “No se va a resolver” +1
● Tu reporte es cerrado como “Duplicado (No se va a resolver) “ +1

Pierdes reputación si:

● Tu reporte es cerrado como “No aplicable” ­5
● Tu reporte es cerrado como “Duplicado (No aplicable)” ­5
● Tu reporte es cerrado como “Necesita más información” ­1

Si tienes mucha reputación obtendrás algunos privilegios como poder ser invitado a programas antes de que estén disponibles al público por otro lado, si tu reputación baja se limitará el número de reportes que podrás enviar en un periodo de tiempo.

Ventajas de utilizar HackerOne como plataforma de reporte de bugs

Para mi las ventajas de usar HackerOne son estas:

● Evita el papeleo a los equipos de seguridad
● Permite que cualquier persona reporté siendo reconocido por su trabajo y premiado por ello.
● Fomenta la búsqueda de fallos que puedan afectar a todo Internet
● Servicio gratuito que asegura la seguridad de los reportes y anonimato de los usuarios.

Mi conclusión personal es que HackerOne es una herramienta que fomenta la búsqueda de fallos gracias a que cualquier persona interesada puede participar y ser reconocida por su trabajo. Es gracias a esa motivación que las empresas registradas se vuelven más seguras haciendo que Internet sea un lugar más seguro.

Autor: Daniel Sesé

Cuentas robadas y bloqueos en Yahoo!, Gmail y Hotmail

Gestionar la seguridad de cualquier servicio online que sea ofrecido por Internet sin poner un ojo en los rincones de la red donde se encuentran las guaridas de los ladrones de identidad es imposible. Es por eso que para todas las empresas que precien la seguridad de sus sistemas su CPD hace tiempo que se convirtió en un Mundo Sin Fin. Con estas cosas en mente fui a probar a ver cuánto tardan las cuentas identidades robadas de los servicios de Hotmail, Yahoo! y/o Gmail en ser bloqueadas o qué medidas de seguridad tenían después de ser expuestas en algún rincón de Internet, y la verdad es que ha sido un resultado curioso que os cuento por aquí.

Buscamos un dump fresco

Para hacer la prueba me dediqué a buscar en Pastebin algunos ficheros con dumps de passwords que no llevaran mucho tiempo publicados. La idea es tan sencilla como filtrar los resultados por fecha y hacer las búsquedas adecuadas para que aparecieran los dumps. Alguno con varios miles de claves, otros con solo algunos cientos, pero en todos ellos con cuentas de Microsoft, Yahoo! y/o Hotmail, que es lo que quería probar y que seguramente habrían sido robadas por medio de algún malware in the browser.

Figura 1: Dump con 3708 cuentas con 24 horas de antigüedad

Pruebas con los sistemas de protección "autenticación adaptativa"

En el caso de Gmail lo cierto es que si las cuentas tenían más de 24 horas no parecían funcionar ninguna de ellas, pero en algún caso llegué al segundo factor de verificación. Este segundo filtro de seguridad salta debido a que la huella digital de la conexión de esa cuenta no le encajaba a Gmail, y por tanto - con buen criterio - se asumía que había posibilidad de que no fuera una conexión legítima.

Figura 2: Segundo factor para una cuenta robada de Gmail.

La huella digital de la conexión se genera para conocer el patrón de conexión habitual de un cliente, como su región geográfica, su navegador, y la configuración del entorno de completo, algunas veces con técnicas de fingerprinting del navegador exhaustivo. Con estos datos, si se nota un cambio radical lo que debe hacerse es bloquear la conexión con un segundo desafío.

En el caso de Microsoft Hotmail las cuentas tampoco parecían bloqueadas, pero si protegidas por alguna capa extra debido al "número" de conexiones simultáneas desde diferentes zonas geográficas, y de nuevo aparecía un desafió de segundo factor.

Figura 3: Cuenta con protección, pero la password parece funcionar

En el caso de Yahoo! de nuevo apareció un comportamiento similar. Primero un captcha doloroso que obliga a afinar tu humanidad para reconocer los números y las letras, y luego una verificación extra cuando la contraseña era correcta para poder continuar.

Figura 4: Segundo factor en Yahoo! para una cuenta robada. Contraseña funciona.

En todos los casos el haber realizado las pruebas desde la red TOR sumado a la huella digital de las conexiones parece que genera alertas extras de seguridad, lo que tiene más que todo el sentido del mundo. Es por eso que yo me "quejé" de que el comportamiento de algunos bancos en su banca online no detectarán un cambio de conexión en la huella digital tan brutal como conectarse a la cuenta por medio de la red TOR cuando antes nunca se había realizado.

Para terminar, también probé alguna cuenta de Facebook, pero al salir por un nodo en la red TOR situado en alguna dirección IP de algún país remoto, acabé topándome con una barrera idiomática. 

Figura 5: Cuenta de Facebook ...¿?

Lo cierto es que con las cuentas de Facebook, a veces puedes saber mucho sobre la víctima, ya que con las búsquedas en el propio Facebook es fácil saber a quién le han robado la cuenta en cada momento.

Rompiendo la barrera geográfica

Por supuesto, también hay dumps con la dirección IP de la víctima, lo que ayuda a que sea más fácil saltarse la validación de "ubicación extraña" si controlas algún equipo cerca de esa ubicación geográfica.

Figura 6: Dump con usuarios, passwords y direcciones IP

Dicho esto, os recomiendo a todos que pongáis un second factor authentication tipo Google Authenticator a tu cuenta Gmail, una verificación en 2 pasos para Apple o asociar un número de teléfono para poner un OTP en Hotmail, o poner un Latch en los servicios que ya puedas... just in case.

Saludos Malignos!

La NSA robó pan en la casa de San Juan ¿Quién yo? Sí, tú.

Hace no mucho un miembro de la NSA dijo públicamente que se esperaban muchas filtraciones aún, ya que sabían que Edward Snowden se había llevado miles de documentos. Es de suponer que en el momento en que salieron los primeros documentos al escrutinio público, la NSA organizara un Plan de Contingencia para determinar el alcance de la filtración. En ese momento - meses atrás - ya sabrían de qué carpetas y sistemas Edward Snowden se habría llevado los documentos y qué tenía en su poder la opinión pública.

Sabiendo de esa forma qué es lo que iba a salir publicado, lo normal es que decidieran un Plan de comunicación controlada, avisando a los países que iban a salir afectados de forma privada y así controlar el impacto de la primera reacción. Sería mejor que el cabreo de un Presidente de Gobierno fuera en privado, lejos de cámaras o micrófonos, mientras le enseñan la portada del The Guardian o Washington Post con la información pertinente.

De esa forma, públicamente se podrían guardar las formas, y por detrás se traza una negociación interna y una estrategia de representación pública ante los medios, para que todo el mundo salga con la máxima dignidad posible. Un bonito paripé mediático.

Entre el trabajo de contingencia también se encontraría el desmantelar cualquier operación en curso que hubiera en cualquier país extranjero para que ningún agente de la NSA que hubiera desplegado fuera de los USA pudiera ser capturado. Los equipos destinados a capturar las conversaciones telefónicas en las ciudades europeas y fuera de ellas, deberían poner pies en polvorosa. Entre ellos, los que vivian hacinados en una habitación para escuchar las conversaciones de la Santa Sede y conocer los intríngulis del Vaticano.

Lo que no sé yo si tenían controlado era la reacción de Google o Yahoo! al descubrir que habían organizado una operación para capturar el tráfico que los gigantes envían entre los distintos Data Centers de la compañía con el programa MUSCULAR. La idea es que, compinchados con los amigos del Reino Unido - los compañeros del Global Communications HeadQuarter - decidieron interceptar el tráfico que pasa cuando los datos se mueven por los cables al circular de un centro de procesamiento de datos a otros.

En el medio hay SSL, pero como ya es sabido, si Google o Yahoo! no están haciendo uso de Certificate Pinning en ese tránsito,  el conseguir el descifrado es tan sencillo como conseguir tener una entidad certificadora intermedia que la NSA pueda utilizar para generar los certificados digitales correspondientes sin romper la cadena de confianza hasta una raíz aceptada en los equipos. "Easy Money", deben pensar los agentes de la NSA, pues como se ve en la diapositiva en la que explican todo el trabajo del programa MUSCULAR ponen un bonito emoticon sonriente.

Figura 1: Cómo espiar a Google según la NSA

A Google no le ha parecido tan gracioso el asunto, porque han capturado datos de sus conexiones de fibra privadas pinchando los cables, algo muy de espía de película de los años 60, y las reacciones han sido de palabras duras. En palabras del Chief Legal Office de Google, David Drummond:

"We are outraged at the lengths to which the government seems to have gone to intercept data from our private fibre networks, and it underscores the need for urgent reform."

Y es que el problema va mucho más allá, ya que mientras que a los estadounidenses el espionaje a personas de segunda clase que vivimos en otros lugares del mundo les calienta poco las glándulas pituitarias - de ahí el Patriot Act y FISA -, cuando de un ciudadano de la Unión se trata, la judía cambia de color, haciendo que un programa como éste que captura datos indiscriminadamente e iguala a todos los usuarios en minusculidad les haga sacar las pancartas a la calle. Algo que la NSA ha dicho que no haría queriendo - a pesar de que hemos visto que algún agente se ha propasado un poco -. Este cómic representa muy bien el pensar americano.

Figura 2: "- La NSA no violaría nuestra privacidad, ¿verdad?"
"-Bueno, no a proposito"
"- Así es, sería totalmente por accidente... ups!"

Mientras esta serie de noticias se suceden, desde la NSA han decidido empezar a tirar balones fuera con algunas de las cosas que parece que se les han escapado de las manos. Que el presidente Barack Obama aprobara el espionaje a los países aliados han decidido rebatirlo, así como que hubiera una operación de espionaje con la Santa Sede, manteniendo que esa información es errónea y mal interpretada. No olvidemos que el catolicismo es una de las religiones más fuertes y poderosas en EEUU y echarse encima a esa comunidad no le sentaría nada bien a un gobierno en parihuelas por los presupuestos. Lo mejor ha sido la respuesta del Papa Francisco, que un arrebato de sencilla humildad y llaneza ha dicho algo así que traducido al idioma de Móstoles, vendría a significar un "me la trae al pairo lo que escuchen de mí".

Sabemos que hay que darles toda la credibilidad a los miembros de la NSA, sobre todo después de que la conferencia que diera el general en BlackHat estuviera llena de verdades demostradas con el tiempo. Sin embargo, solo por si hubiera algún insignificante error u omisión en todas las declaraciones de la NSA sobre este tema, el parlamento alemán, ha decidido ir "right to the source, not to the horse", y hablar con el mismo Edward Snowden para conocer más detallitos de todo este proceso, que ya tiene a propios e impropios desconcertados.

Lo más extraño es que esto pasará. Los documentos se acabarán. La NSA cambiará los programas, los medios, las herramientas de espionaje. Los representantes públicos hablarán de cambio, de control, de nuevas medidas, de no lo vamos a hacer más. Y todo pasará.... a las sombras otra vez.  Pero allí, en las sombras, desarrollarán las mismas capacidades, y seguirán con lo mismo. Esto, no lo va a parar nadie ya, y si no es la NSA la que robó el pan en la casa de San Juan, será otra, pero alguna será.

Saludos Malignos!

X-Keyscore: El sistema de data mining de la NSA

Según las últimas revelaciones publicadas por The Guardian provenientes de las filtraciones del Edward Snowden, la NSA tiene varios sistemas de análisis de información sobre todos los datos que almacena. Uno de ellos es X-Keyscore, un sistema para analizar todo el tráfico HTTP que es capturado, suponemos que con algún sistema similar al de la operación Tempora del GCHQ por el que pinchaban los cables de Internet.

Figura 1: Logo del producto de la NSA X-Keyscore

El sistema es como un cluster en Linux distribuido geográficamente que permite realizar consultas detalladas sobre el tráfico HTTP y los datos analizados en él. En una de las presentaciones filtradas de la NSA, de la que se han censurado algunas diapositivas que contenían información concreta de operaciones, se puede ver un mapa en el que se muestran dónde estaban los servidores en el año 2008. Al menos uno de ellos se encontraba en España.

Figura 2: ¿Dónde está X-Keyscore?

Según se explica, el sistema recoge todo el tráfico de Internet HTTP, lo analiza, y genera meta-información sobre lo capturado. Descubre cuando es un correo electrónico, un chat de Facebook, cuando es una búsqueda de Google o cuándo es una conexión cifrada.

Figura 3: Metadatos generados de sesiones HTTP

En los ejemplos se recomiendan consultas por idioma del sistema operativo, por sistemas explotables con vulnerabilidades conocidas o por el uso de cifrado, lo que podría hacer caer a casi cualquiera que use PGP en las listas de posibles terroristas.

Figura 4: Trucos para localizar terroristas. Buscar quién usa cifrado

El programa permite también buscar por el contenido de los correos electrónicos, aunque tiene límites, ya que el sistema solo almacena todo el tráfico que es capaz de capturar durante unos días, y los metadatos generados durante unos 30 días.

Figura 5: Explicación de cómo interceptar correos electrónicos

Pero quizá lo más delicado de todo esto es la información que se publica en el periódico sobre los aspectos legales del sistema, donde se dice que:

Legal vs technical restrictions 

While the Fisa Amendments Act of 2008 requires an individualized warrant for the targeting of US persons, NSA analysts are permitted to intercept the communications of such individuals without a warrant if they are in contact with one of the NSA's foreign targets.

Es decir, que mientras que para un ciudadano de los USA se necesita una orden judicial, para un ciudadano de fuera de los Estados Unidos no es necesario. Como se puede ver en la siguiente captura, el analista solo necesita explicar porqué sabe que es un ciudadano de fuera de los USA para no ser necesario pedir una orden a un juez.

Figura 6: Selección de por qué se le espía

Una vez más, estas revelaciones dejan muy preocupado a todo el mundo, y aunque la NSA muestre su lado amable resolviendo criptogramas, este tipo de información obligará al gobierno de los USA a dar explicaciones.

Saludos Malignos!

Time-Based Blind SQL Injection en Yahoo!

Las técnicas de Time-Based Blind SQL Injection me tuvieron enganchado largo tiempo. La posibilidad de poder extraer datos de una consulta generando retardos de tiempo en las respuestas True es algo que me enamoraba.

Herramientas como SQL Ninja, las Time-Based Blind SQL Injection using Heavy Queries - de las que hablé en mi primera Defcon -, el exploit de Solar Empire, el Deep Blind SQL Injection o Marathon Tool, llenaron muchos de los posts de este blog durante mucho tiempo. Me encantaba, y de hecho terminaron por convertirse en el libro de Hacking de Aplicaciones Web: SQL Injection que escribimos entre Enrique Rando/**/AND/**/Chema Alonso.

Tanto tiempo le dediqué que Palako y yo estuvimos dando la charla de seguridad en la Yahoo! Security Week hablando largo tiempo de estas cosas - hasta jugándonos el pellejo con algunas demos de lo más "on the blade" posible -, de cómo es posible extraer grandes fuentes de información, incluido ficheros con técnicas de Remote Downloading Files usando los retardos de tiempo. Así que estoy seguro que los equipos de seguridad de Yahoo! sabían de esto, porque los Paranoids otra cosa no, pero de esto deben saber sí o sí.

Dicho esto, sorprende que Yahoo! se haya comido un par de Time-Based Blind SQL Injection en el lugar más típico, en parámetros numéricos de ficheros PHP, algo que los número tres que se prueba en cualquier auditoría de seguridad que cuenta con PHP de por medio. Este es el lugar donde se encontró:

http://tw.ysm.emarketing.yahoo.com/soeasy/index.php?p=2&scId=113; select SLEEP(5)--

Basta con lanzarle un Havij a cualquier sitio de estas características para que la auditoría termine justo ahí. Así que... esto tiene pinta de ser otra web que salió a producción sin auditoría previa.

Saludos Malignos!

El buscador más encontrado buen buscador será

Ayer por la mañana pensaba escribir sobre lo del SQL Injection en MySQL porque tiene cierta ironía. Sin embargo, el post de Yago me motivó para escribir sobre el tema del OCSP. Al ponerlo a ello pensé... "Olvidate de lo del hack de MySQL Injection porque lo van a publicar en Una al día seguro..." y dicho y hecho.

Así que, como me inculcó mi mamá, no se debe dejar para mañana lo que puedas hacer hoy. Sabido eso, es decir, que el post de hoy me lo han quitado, y que lo que a mí me hubiera gustado contar hoy es lo que publicó Una al día - no veáis que pedazo de anuario que escribió Pajarraco de los Santos sobre las noticias de Una al día durante los últimos 12 años - has de parar de leer aquí, ya que el resto del post es una chorrada.

Lo cierto es que muchos de los posts de El lado del Mal son una chorrada, así que probablemente, si eres un lector al uso, ya habrás incumplido mi recomendación y estarás leyendo esta chorrada. ¿Me equivoco?

En fin, como quería hacer una chorrada en penitencia pensé en qué podría ser una buena chorrada para flagelarme, y llegué a la conclusión siguiente: Vamos a buscar un buscador de Internet en un buscador de Internet.

Este tipo de chorradas son las que se suelen hacer en las grandes empresas para cumplir con disciplina las reglas de Dilbert que siempre situán a la empresa a un paso de la solución. Sí, ya sabéis, ese tipo de empresas que "Buscan un grupo de personas para que busquen una solución".

Por si, llegado este punto, aun sigues interesado en la chorrada [Deberías hacértelo mirar] estos son los resultados que he obtenido, que dicho sea de paso, son para mear y no echar gota.

Para Google, los buscadores de Internet más buscados, es decir, los que se convierten en los más encontrados vía Google son: Terra y Yahoo!. Toma ya!


Si crees que Google es un gran buscador, entonces debes reconocer que Bing es aún mejor. Primero se puede ver como "indexa" correctamente los resultados de Google, posicionando a Terra como mejor resultado. Luego recomienda Google, ¡para que encima digan que son malos competidores!


Para Terra, la cosa está clara, los mejores son ellos, pero, por si hay dudas, Bing es una mucha mejor opción que Google, ¡y eso que utilizan los resultados de Google!. Sin embargo, no sé exactamente que resultados usan, ya que Yahoo!, que era la segunda opción de Google, desaparece totalmente de aquí.


Por último, para Yahoo! el primer resultado es un sito SEO-Oriented para buscador de Internet, mientras que el segundo mejor resultado es Terra.


Visto esto, hay que reconocer que Bing es mejor buscador que Google porque ofrece un mejor juego de resultados para Buscadores de Internet que Google. Además, hay que tener en cuenta que si el mejor es Terra - ya que en medio es el mejor posicionado en todos - entonces Bing es una mejor opción que Google, ya que sale mejor en la lista de resultados... y. Sí, las conclusiones son también una chorrada, pero... ¿no te avisé al principio del post?

Saludos Malignos!

DKIM, Domainkeys, Identified Internet Mail y el Spam (2 de 3)

***********************************************************************************************
- DKIM, Domainkeys, Identified Internet Mail y el Spam (1 de 3)
- DKIM, Domainkeys, Identified Internet Mail y el Spam (2 de 3)
- DKIM, Domainkeys, Identified Internet Mail y el Spam (3 de 3)
***********************************************************************************************

¿Qué hacer con los correos no firmados con DKIM?

En teoría, el RFC que define el funcionamiento del servicio de DKIM dice que:

5.4. Unverified or Unsigned Mail

Messages lacking a valid author signature (a signature associated with the author of the message as opposed to a signature associated with an intermediary) can prompt a query for any published "signing practices" information, as an aid in determining whether the author information has been used without authorization.

Es decir, que el servidor que recibe “puede” y no “debe” realizar una consulta para conocer la política de firmas. Esto quiere decir que, si un correo no llega firmado desde un dominio que utiliza DKIM, pero el servidor decide no hacer la consulta al servidor DNS del dominio de origen para buscar la política que se quiere aplicar, entonces estaría cumpliendo con el estándar perfectamente.

Luego que una empresa haga la inversión en implementar DKIM no garantiza que en los servidores que usan DKIM no entren correos falsos de su dominio.

¿Cuáles son y dónde se guardan las políticas?

Dentro del dominio del emisor de un mensaje de correo electrónico, se guarda en un registro del DNS conocido como ADSP (Author Domain Signing Practices) en DKIM y en el registro _Domainkey en el caso del ya histórico Domainkey original.

Curiosamente, en el caso de Yahoo! la política aún está en el registro que usa Domainkey y no en DKIM, lo que puede significar muchas cosas.


Figura 4: Política de Yahoo
Por su parte, Paypal, para que no le quede ninguna duda a nadie, aparte de implementar el registro en formato domainkey, lo tiene ya implementado en formato DKIM.


Figura 5: Políticas de Paypal
Políticas DKIM y Domainkey

Las políticas en ambos protocolos han cambiado. Mientras que en Domainkey se utiliza un sistema similar a SPF, es decir, con Fail, Softail, Neutral y Pass que se almacenan en el valor o=, en DKIM se utilizan tres valores:

- All = Todos los mensajes vienen firmados.
- Unknown = No se sabe si todos vienen o no vienen firmados
- Discardable = Todos los mensajes son firmados, si no llega firmado, el dominio remitente solicita que sea eliminado el mensajes de correo electrónico.

Como se ha visto, Yahoo! tiene una política Softfail para Domainkeys, lo que indica que debería poner alguna marca al mensaje o similar. Por el contrario, la política DKIM, que debería estar en el regsitro ADSP _adsp._domainkeys.yahoo.com no está implementada.

¿Y Gmail?

Pues a pesar de que Gmail sí que está firmando sus mensajes con DKIM, resulta que ni Gmail.com, ni el propio Google.com, tienen política DKIM o DomainKeys.


Figura 6: Política "ausente" de Gmail
¿Y qué hacemos si un mensaje no viene firmado desde Gmail si no hay política? Pues nada, ya que según dice el RFC hay que aplicar la política unknown:

A.2. Domain Exists, ADSP Does Not Exist

A mail message contains this From: header line: From: alice@bbb.example (Old-fashioned Alice) The ADSP lookup first identifies the Author Address alice@bbb.example and the Author Domain bbb.example. It does an MX DNS query for bbb.example and gets back record (3). Since that query didn't return an error, it then proceeds to a TXT DNS query for _adsp._domainkey.bbb.example, which returns NXDOMAIN. Since the domain exists but there is no ADSP record, ADSP returns the default unknown result: messages may or may not have an author domain signature.

O lo que es lo mismo, mientras no firmes todos los mensajes con DKIM no puedes pedir que se borren los correos que no vayan firmados. Y la pregunta que surge es... ¿y cómo están aplicando todo esto los filtros antispam?

***********************************************************************************************
- DKIM, Domainkeys, Identified Internet Mail y el Spam (1 de 3)
- DKIM, Domainkeys, Identified Internet Mail y el Spam (2 de 3)
- DKIM, Domainkeys, Identified Internet Mail y el Spam (3 de 3)
***********************************************************************************************

DKIM, Domainkeys, Identified Internet Mail y el Spam (1 de 3)

***********************************************************************************************
- DKIM, Domainkeys, Identified Internet Mail y el Spam (1 de 3)
- DKIM, Domainkeys, Identified Internet Mail y el Spam (2 de 3)
- DKIM, Domainkeys, Identified Internet Mail y el Spam (3 de 3)
***********************************************************************************************

DKIM - Domakin Keys Identified Mail - es la unión de dos protocolos anteriores, conocidos como Domainkeys (catalagado ya como histórico) e Identified Internet Mail (del que cogió algunos aspectos) y su objetivo principal es garantizar que un mensaje en concreto procede de un determinado dominio. La garantía de procedencia desde un dominio en concreto se realiza mediante el uso de firmas digitales que se añaden a los mensajes de correo electrónico que son enviados desde los servidores legítimos de ese dominio.

Para que esta idea funcione, cuando un mensaje va a ser enviado desde un determinado servidor de correo, éste, es decir, el servidor de correo saliente, firma el mensaje y añade al correo electrónico una cabecera DKIM que lleva la firma resumen del mensaje, el algoritmo de firma utilizado y el nombre de la clave que se ha utilizado para firmar este mensaje. Será el servidor del correo entrante el que, una vez detectada la cabecera DKIM, leerá el nombre de la clave que se ha utilizado para firmar y se conectará al servidor DNS del dominio firmante para recuperar la clave pública asociada.

Para garantizar que ese es el correo que se envió desde ese servidor de correo se comprobará que la firma es correcta, garantizando que el mensaje viene de ese dominio.

Estos son los principios básicos de DKIM, cuya primera versión es de 2007 y la última revisión del estándar se ha publicado en Agosto de 2009, y , al igual que SPF y SenderID tiene muchas luces y sombras a sus espaldas.

Abuso de DKIM con procesos de re-envío

Google ha anunciado que añade DKIM a Google Apps para que pueda ayudar a la reducción del Spam, y la realidad es que esto, a pesar de que da más información y esos siempre es bueno a la hora de detectar un mensaje de spam, hay que tomarlo con mucho cuidado.

La primero y más evidente es que, si la firma del mensaje va incluida en el propio mensaje, es evidente que no va todo el mensaje firmado. Así, DKIM firma solo mensaje en sí y no todo el sobre, con lo que la protección de integridad del mensaje está sujeta solo al contenido del mismo. Fuera de esa firma de integridad se quedan, entre otros, campos como los destinatarios del mensaje.

Conocido esto, imaginemos que un atacante hace una lista de correo en cualquier servidor de listas y mete en ella todas las direcciones de correo a las que quiere spammear. Ahora utiliza un dominio legítimo que esté firmado con DKIM, como por ejemplo Yahoo! o Gmail y envía, desde ese correo el mensaje a la lista de correo. Cuando el bouncer reenvíe el mensaje este seguirá con la firma DKIM intacta y aparecerá firmado por el destinatario.

Este ejemplo de uso con una lista de correo se puede sustituir por cualquier programa automático o botnet, ya que con tener el mensaje y la firma que pone Gmail a ese mensaje, el atacante puede enviárselo a sí mismo y reenviarlo a cualquier otro destinatario.

Correos firmados por DKIM

Aunque no sea una bala de plata para acabar con el spam, la idea es que una vez que sepa que el mensaje viene en origen ese dominio deberá tener un tratamiento especial con dicho mensaje, ya sea mostrando una marca de garantía al usuario o no metiéndolo nunca en la bandeja de spam, o lo que decida la política del servidor de correo entrante.


Figura 1:Correo firmado por Yahoo


Figura 2: Cabecera del mensaje de correo de Yahoo con firmas DKIM y DomainKeys
Como se puede ver Yahoo trae en el mensaje la cabecera de firma Domainkeys y la de DKIM, es decir, las dos por si acaso el servidor reconoce una u otra. En ambas cabeceras se especifica que se ha utilizado la misma clave, que está en este registro del DNS.


Figura 3: Clave pública de firma de Yahoo
Tratamiento especial en los filtros antispam a los mensajes firmados DKIM

Al poderser abusar esa firma mediante procesos de reenvío, la pregunta que muchos se hacen es... ¿se deberá dar un tratamiento especial en los filtros antispam si los correos vienen firmados? Si se hiciera eso, se estaría tendiendo una alfombra roja a los spammers en los servidores de correo, por lo que nadie se atreve a hacer esa prioridad al correo firmado por DKIM.

No obstante, tenemos la garantía de que el mensaje original salió como ha llegado y desde un origen concreto, con lo que se podría localizar al spammer en el dominio de origen, por lo que tal vez sería posible hacer una operación de búsqueda y bloqueo de ese spammer en el dominio.

***********************************************************************************************
- DKIM, Domainkeys, Identified Internet Mail y el Spam (1 de 3)
- DKIM, Domainkeys, Identified Internet Mail y el Spam (2 de 3)
- DKIM, Domainkeys, Identified Internet Mail y el Spam (3 de 3)
***********************************************************************************************