El Disciplinado, el Día Descanso y el CFP de DefCON 31

No voy a deciros que la semana pasada ha sido una semana intensa para mí, porque sería estar cerca de hacer una tautología. Con tantos datasets a la espalda soy consciente de lo que es una excepción y de lo que es una forma de ser en mí. This is the way. Mi forma de vivir cada día y cada semana, controlada por ese demonio "cabrón" que no admite "excusitas" es así. Y hoy mismo lo he sentido al sentarme frente a mi blog.

Figura 1:El Disciplinado, el Día Descanso y el CFP de DefCON 31

Hoy es sábado, de un puente en España, hace buen tiempo, es día de playa, de campo, de montaña, de hacer deporte, de salir a que te dé el aire, de ir de compras, de dedicarle tiempo a los abuelos, a los niños, de recargar pilas, de salir a pasear con tus mascotas un paseo largo y relajado, de regalar tiempo a vivir, a las personas, a los seres humanos y a los queridos animales de nuestro entorno. ¿Tienes un perrinchi? Pues a pasear con él por la calle. 

¿A quién le importa hoy un blog de tecnología? ¿A quién le importa si te has dado cuenta de un leak, un bug, en una plataforma? ¿A quién le importa una noticia más o menos de Ciberseguridad o Inteligencia Artificial, o de Web3 hoy? ¿O un evento, una entrevista, una charla, una recomendación? Hoy podría ser un buen día para descansar, y es lo que os voy a recomendar a todos. Que no hagáis nada que tenga que ver con la tecnología.

Yo he estado a punto de no publicar nada. A puntito. Por todos los motivos anteriores. Pero el demonio me ha pillado por los pelos y me ha dicho que de eso nada monada, que había que cumplir. Y es por eso que me he puesto. Y cuando estaba con la página en blanco blasfemando en arameo sobre el demonio, me he acordado de las palabras de una compañera de trabajo esta semana mientras preparando una presentación importante tomábamos un café.

A mucha de la gente que está en mi equipo le preguntan eso de "¿Cómo es Chema Alonso en el trabajo? ¿Lleva gorro? ¿Todo el día de fiestas? ¿Hacking everywhere?". No es nuevo ni para mí ni para mis compañeros, y lo comentamos muchas veces en las reuniones, los cafés y los comités. Ayer mismo, uno de mi equipo que estaba haciendo un curso de idiomas me dijo que estaban hablando de mí en su curso que hacía por vídeo conferencia y me colé en la reunión para contárselo yo en persona.  Es algo habitual cuando la gente ve una imagen, pero realmente no conoce a la persona.

Lo cierto, es que, mi compañera, esta semana, me dijo lo que acababa ella de contestar a quién le había hecho en última instancia esa pregunta. "Disciplinado. Chema Alonso es disciplinado. Sabe que lo tiene que hacer y lo hace." Y es así, no necesito que nadie venga a recordarme lo que tengo que hacer. Y si sé que lo tengo que hacer, sé que gastar cualquier energía en evitarlo puede ser más costoso. Así que, si lo tengo que hacer que sea cuanto antes y con el menor coste de energía.

En el colegio y en el instituto decidía por cada asignatura si no tenía que estudiar nada, si tenía que pegarme la panzada dos días antes y listo, o si salía más a cuenta estudiar todos los días. Con cada asignatura, que no todas eran iguales. Y si había que estudiar todos los días para que fuera más económico en tiempo, esfuerzo y energía, pues se estudiaba todos los días y listo. Pues lo mismo con todo. Sí, soy disciplinado. No importa si la tarea es pequeña o grande. Si va a durar una semana, un mes o siete años, si sé que lo tengo que hacer, decido cómo y de qué manera y lo hago. Sin ansiedad. Sin anticipación. Simplemente me pongo a hacerlo porque sé que no hay otra opción que no hacerlo. 

Figura 2: CFP de DefCON 31

Y por eso hoy os he puesto este post, y por eso hoy voy a estar trabajando para ver si enviamos el Call For Papers de DefCON 31 que acaba mañana el plazo, y vamos a ver si este año me animo a ir o no a DefCON otra vez, que hay ganas pero a esta hora aún no lo he decidido por fechas. Así que, al final, contándoos que soy Disciplinado y voy a estar trabajando en el CFP de la DefCON 31 por si me animo a echarlo, y que no debería hacerlo porque es un día de descanso.... os hecho el post de hoy. Disfrutad.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

CONs de Hackers: DefCON, RootedCON, Barnaby Jack, Dan Kaminsky, Charlie Miller y FOCA en Horizonte

Ya en la madrugada del Viernes, pasé por el programa Horizonte del gran Iker Jiménez, para, con motivo de la realización de la RootedCON 2023 en Madrid del próximo 9 al 11 de Marzo, hablar de lo que se hace allí. De en qué consiste una CON de Hackers como DefCON o RootedCON, y contar algunas de las aventuras que suceden por allí.

Figura 1: CONs de Hackers: DefCON, RootedCON, Barnaby Jack,

Dan Kaminsky, Charlie Miller y FOCA en Horizonte

El programa, que puedes ver a la carta,  es de la Temporada 3 Programa 107, y esta parte en concreto la puedes ver a partir de 1 hora y 23 minutos, que fue cuando comenzó esta sección. En ella, comenzamos hablando de en qué consiste una CON de Hackers, con sus tracks, su Bug Bounty, los CTFs y los trainings, lo que es todo el ambiente de una CON.

Figura 2: Horizonte Temporada 3 Programa 107

Después, hablamos del impacto de las investigaciones, algunas como el caso de Dan Kaminsky y su bug del DNS que obligó a "parchear" Internet, el caso de Barnaby Jack y su muerte antes de contar cómo hackear los dispositivos marcapasos, o la famosa presentación de Charlie Miller y Chris Valasek hackeando un auto remotamente para controlar el volante o... quitarle los frenos.

En 2015 los programadores informáticos Charlie Miller y Chris Valasek demostraron cómo hacerse con el control remoto de un vehículo #Horizonte pic.twitter.com/jkE4goc92W

— Iker Jiménez (@navedelmisterio) March 3, 2023

Luego hablamos también de algunas charlas de las que yo he dado por allí. De la charla de DirtyTooth que publicamos inicialmente en RootedCON con el título de "It´s only Rock'n Roll but I like it" y que hizo que Apple tuviera que añadir un control de seguridad en iOS para evitar el robo de contactos de forma silenciosa.

Ver esta publicación en Instagram

Una publicación compartida de Chema Alonso (@chemaalonso)

Y por supuesto, también de Owning Bad Guys {and mafia} using JavaScript Botnets y de nuestra querida FOCA, que presentamos en DefCON con unas demos muy curiosas con Whitehouse.org y con la Agencia de Misiles Americana, que después de dar la charla, borró todos los documentos de su web.... y os expliqué cómo hacerlo usando WebArchive.

Figura 5: Las entradas de RootedCON 2023 con Tempos en MyPublicInbox

Por último, si quieres venirte a la próxima RootedCON, ya sabes que quedan unas entradas disponibles en MyPublicInbox que puedes conseguir con solo 10.000 Tempos, así que aún estás a tiempo de no perderte la CON de hackers más grande e importante de España.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Una entrevista a Yaiza Rubio antes de DefCON & BlackHat

Hoy estoy en Las Vegas, lugar que pronto será tomado por hackers de todo el mundo para disfrutar de BlackHat y DefCON, las dos conferencias más míticas de la historia. Yo he tenido la suerte de estar muchos años participando en ellas, y para mí siempre fue una maravilla. Este año, varios investigadores de ElevenPaths estarán por allí. Claudio Caracciolo y Sheila A. Berta del equipo de Buenos Aires, y Félix Brezo y Yaiza Rubio de la oficina de Madrid.

Figura 1: Una entrevista a Yaiza Rubio antes de DefCON & BlackHat

Aprovechando que estoy cerca de ellos, he querido hacer una pequeña entrevista a Yaiza, la primera mujer hacker de España que va a participar en estas conferencias. Una persona muy importante para nuestro equipo de Ciberseguridad en Telefónica, dentro de los analistas de ElevenPaths. Estas son las preguntas y estas son las repuestas.

Saludos Malignos!

1.- Sabes que eres la primera mujer de Telefónica y de España que va a dar una charla en Defcon, y para mí es un orgullo que seas de ElevenPaths, pero la pregunta que se hacen muchos es cómo se llega ahí. ¿Qué has estudiado para tener los conocimientos suficiente para lograr esto?

Te aseguro que hay caminos más directos que el que he hecho yo. Yo soy licenciada en Ciencias de la Información, Máster en Análisis de Inteligencia, Máster en Logística y Economía de la Defensa y Máster en Derecho Tecnológico y de las TIC. Estuve trabajando en S21sec e ISDEFE, pero fue a raíz del 2013 cuando entré en la unidad de ciberinteligencia de Telefónica cuando comencé a pegarme con esto de verdad. 

Como muchos, compaginaba el trabajo con formaciones, en mi caso, de hacking y de análisis forense, pero la realidad es que la mayoría de los conocimientos que tengo son a raíz de haber tenido cierta inquietud sobre algo que me ha parecido importante aprender.

2.- Y de ahí, ¿cómo llegaste a meterte en este mundo? ¿Qué te hizo acabar aquí?

Fue de pura casualidad. Félix y yo nos conocimos en el Máster de analisis de inteligencia. Con él fui adentrándome poco a poco en este mundo. Yo trabajaba en ISDEFE, en la unidad de desarrollo de negocio de la industria española de defensa y seguridad, y Félix en el laboratorio de seguridad que la Universidad de Deusto.

Nunca se me olvidará el día en el que Félix me llamó para decirme que se había encontrado con David Barroso y le dijo que estaban montando en Telefónica una unidad de ciberinteligencia. A la semana estábamos trabajando con Carlos Díaz y David Prieto en cómo montar lo que hoy es el servicio de CyberThreats de ElevenPaths.

3.- Eres una persona de gran importancia para ElevenPaths y Telefónica en el área de la Seguridad, ¿cómo se lleva la presión con eso? ¿No te da cierto vértigo?

Tampoco es para tanto. Por suerte, en Telefónica tenemos gente que lleva desde hace muchos años dedicados a la ciberseguridad como es tu caso, el de Pedro Pablo Pérez o Alejandro Ramos. El hecho de que nos hayan cogido en las dos mejores conferencias del mundo simplemente es un síntoma de que lo estamos haciendo bien.

4.- Y con tu primera experiencia en Defcon en unos días, ¿Qué es lo que más te asusta? ¿Qué es lo que más te motiva?

Lo que más me motiva es mirar atrás y ver mi evolución. Este viaje es un premio a la actitud de trabajo y la capacidad de aprender todos los días. En realidad me asustan muchas cosas, pero si lo dejara para cuando piense que estoy lo suficientemente preparada al final acabaría no haciéndolo.

5.- Resúmenos un poco de que es lo que vais a hablar en DefCON y qué es lo que vais a presentar en el BlackHat Arsenal, que también vas a estar por allí.

En BlackHat mostraremos OSRFramework. Un conjunto de herramientas de software libre con el que venimos trabajando ya cuatro años y que dan soporte a los procedimientos de investigación sobre la huella digital de ciberidentidades con presencia en la red. 

Por otra parte, en Defcon profundizaremos en el proceso de preparación de un ataque de phishing el que los atacantes verán protegida su identidad apoyándose en tecnologías como Tor y la explotación de malas prácticas en la gestión de enlaces difundidos a través de redes sociales. Aunque lo hemos notificado a varias plataformas, pocas han corregido un fallo que proporcionaría una mayor seguridad a los usuarios.

6.- ¿Cómo es el día a día en ElevenPaths?

Imposible aburrirse. En mi caso, estoy muy enfocada a la investigación pero eso no quita que como analista deba trabajar conjuntamente con el resto de áreas como innovación, producto o desarrollo de negocio. Al final nos dedicamos a la venta de servicios y productos de ciberseguridad.

7.- Además, también te animaste a escribir un libro para 0xWord sobre BlockChain con otro grande, Félix Brezo. ¿Esto cuenta como hobby o como trabajo?

Es un hobby con mucha responsabilidad. Además, esta editorial se diferencia por proporcionar a sus lectores una aproximación práctica de la seguridad. No quieren ni casos de uso ni ideas que en un futuro se puedan implementar. Invierten su dinero para que después de seguir el libro tengan cierta soltura en un tema. 

Figura 2: Libro de Yaiza y Félix sobre BlockChain & BitCoin

Desde el punto de vista del que escribe, implica mucho más trabajo planteando retos para que el lector no pierda el interés sobre el tema.

8.- BlockChain es un tema muy de actualidad, y tú llevas años con Félix estudiándolo. ¿Cómo crees que va a cambiar el mundo en los próximos años?

Sin duda están surgiendo, con ciertas dudas, nuevas oportunidades relacionadas con esta tecnología. Sin embargo, desde el punto de vista de la seguridad, es probable que lleguemos a ver dentro de poco diferentes aplicaciones maliciosas que, con el objetivo de perpetuar la comunicación entre víctimas y administradores, utilicen la cadena de bloques. 

Figura 3: Charla de Yaiza y Félix sobre BlockChain & BitCoin en RootedCON

De la misma manera, con el auge del ransomware llevamos unos cuantos años sufriendo el anonimato de Bitcoin. Es triste pero antes de WannaCry no nos llegaban tantas peticiones de gente interesada en conocer cómo investigar los pagos en Bitcoin.

9.- Los que tenemos el veneno éste de la tecnología estamos siempre pensando en lo siguiente. En el To-Do list tenemos muchas cosas. ¿Qué hay en la tuya?

Blackhat y Defcon es una primera toma de contacto. En el futuro esperaremos llevar investigaciones que nos permitan competir con los mejores analistas de seguridad del mundo. Respecto a mi To-Do list personal, me gustaría invertir más tiempo en el proyecto de Cibercooperantes de INCIBE. Es importante promover la sensibilización de los riesgos de internet entre niños, padres y profesores. 

Ayudar a la gente que tienes cerca con tu experiencia es muy necesario, pero para cambiar las cosas también es necesario influir en aquellas personas que toman decisiones y que nos marcan las reglas del juego constantemente y a vaces sin el conocimiento necesario. Principalmente porque es imposible que puedan abarcar tantos temas y tan complejos. También, poco a poco completar asignaturas de la carrera de derecho que estoy haciendo, así como continuar con mis clases de árabe que ya son cuatro años los que llevo con este idioma infernal. 

¡Ah! Y no todo va a ser seguridad. En noviembre juego el campeonato de España de Padel junto con mi compañera de Telefónica de España Elena Sumastre. ¡Seguro que haremos un buen papel!

10.- ¿Quiénes fueron tus referentes?

Seguro que mucha gente que lee este blog sabía desde pequeño que quería dedicarse a la seguridad. Yo, no. Yo he tenido la suerte de conocer a mis referentes en el día a día como un tal Chema Alonso, Pablo González, Sergio de los Santos o Antonio Guzmán.

11.- Sabes que eres un referente ahora tú para las futuras generaciones, y sabes que yo tengo una niña de 9 años preciosa que ya hace pinitos con Arduino. Tú, que has sido niña y has tenido 9 años seguro que sabes mejor que yo que pasa por su mente. ¿Qué le dirías a las niñas de 8 a 12 años que hacen sus pinitos con la tecnología?

Más bien es qué le diría a sus padres y profesores. Al final, la capacidad de influencia en los jóvenes se encuentra en su círculo más cercano. Todo se fundamenta en proyectar entre los pequeños el valor de la constancia y que sus familiares se esfuercen también en fomentar esa primera experiencia positiva con la tecnología. El objetivo es que este sector sea una opción entre las jóvenes cuando crezcan. No aparecen Nadales de la nada sin un entorno favorable y sin perseverancia. 

Figura 4: Yaiza es una de las mujeres hacker
No es la primera vez que me piden mi opinión sobre por qué hay tan pocas mujeres que dediquen a lo que hago yo. Creo que Amy Cuddy, psicóloga en Harvard, dió con la clave. Las niñas cuando llegan a los 12 años cambian su lenguaje corporal porque de repente pierden seguridad. El entorno debe tener muy en cuenta este detalle porque cualquier comentario negativo sobre su valía o sobre la tecnología puede ser decisivo para no generar en ellas ese gusanillo que se necesita para querer aprender diariamente sobre esto.

12.- Para terminar, me tienes que recomendar tres libros de lectura que te hayan emocionado. Que llega el verano y hay que hacer la selección de libros. "Pásate" tres referencias.

1984 de George Orwell. Es mi libro favorito desde siempre. Es increíble cómo un libro publicado en 1949 pudo interpretar tan bien el futuro y las diferentes formas del poder para ejercer el control sobre sus ciudadanos. A pesar de estar ambientado bajo regímenes totalitarios, me gustaría volver a leerlo teniendo en cuenta lo que sabemos después de Vault 7.

Los Guardianes de la Libertad de Noam Chomsky y Edward S.Herman. Es un ensayo un poco duro de leer pero merece la pena analizar cuál era el modelo de los medios de comunicación a finales de los años 80 y cómo tenían y siguen teniendo la capacidad de dirigir la opinión pública a pesar de la aparición de internet y las fake news.

Y, por último, me gustaría recomendar el libro de Silvia Barrera, Claves de Investigación en Redes Sociales. Siempre he valorado mucho a las personas que se dedican a la seguridad pública en España. Tenemos la suerte de contar con muy buenos profesionales y más después de leer el libro de Silvia, una persona que ha dedicado toda su carrera a ayudar a los demás.

Puedes contactar con Yaiza Rubio en su buzón púbico MyPublicInbox\Yaiza Rubio

Atacar la seguridad HTTPs con un Delorean en Python

Entre la lista de conferencias que se han dado este año en DefCon 23 hay una que tenía ganas de revisar, ya que la daba uno de los mejores hackers españoles, el gran José Selvi. Sus trabajos son siempre elegantes e ingeniosos, como cuando migró JailBreakMe a JailOwnMe para ownear los terminales iPhone - tanto me gustó que le pedí que lo detallara paso a paso para incluirlo en el libro de Hacking iOS -. En esta ocasión, su charla en Las Vegas versaba sobre cómo romper la seguridad de las conexiones HTTPs por medio de un Delorean, una que ya había impartido en Black Hat Europe 2014 pero que no había podido ver todavía.

Figura 1: Atacar la seguridad de HTTPs con un Delorean en Python

Sí, el uso de un Delorean es una forma de hacer entender a todo el mundo que el ataque tiene que ver con las medidas de seguridad que dependen de la fecha del sistema operativo y que, por fallos de seguridad en el protocolo NTP, pueden ser manipuladas para hacer viajar en el tiempo al sistema. Si cuando hablamos de Leap Seconds vimos lo mal que le podía venir a al sistema un segundo introducido, os podéis imaginar si hacemos viajar en el tiempo a los sistemas informáticos durante más tiempo. 

Figura 2: Saltar la seguridad de HSTS con un Delorean

La presentación de la charla la tenéis colgada dentro de la recopilación que han hecho nuestros amigos de Cyberhades con todo el material de DefCon 23, y merece la pena que la veas - incluidas las preciosas fotos de esa ciudad de Valencia tan bonita que tenemos en España -, y en la web de BlackHat Europe 2014 tienes acceso a un WhitePaper donde se recoge el trabajo.

Implementaciones de NTP en sistemas operativos

En la lista de sistemas operativos que ha analizado José Selvi se encuentran Ubuntu, Fedora, OS X y Windows. Todos ellos hacen uso de una forma u otra del protocolo NTPv3 o NTPv4 con configuraciones susceptibles de sufrir un ataque de man in the middle. Esto quiere decir que, un atacante, podría interceptar la petición de sincronización NTP emitida por el sistema operativo y darle una hora arbitraria para configurar de forma maliciosa la hora del sistema operativo.

Figura 3: Petición NTPv4 de Ubuntu vulnerable a man in the middle

Para hacer esto, hay que utilizar algún esquema de man in the middle en redes IPv4 o IPv6 que permita interceptar la petición NTP del cliente. Aceptando que en una red insegura - sin IPSec o sin posibilidad de bloquear los ataques de man in the middle - el protocolo NTP es vulnerable, las medidas de mitigación que tienen los sistemas operativos se basan por tanto en reconocer si alguna de estas peticiones puede reconocerse como maliciosa.

En las diferentes implementaciones Fedora es que más fácil lo pone, ya que hace una petición cada minuto y por tanto se le pueden hacer cambios en la fecha del sistema constantemente. En el caso de Ubuntu la sincronización es cuando se levanta la conexión de una nueva red o se produce un reinicio. En OS X se hace cada ciertos minutos, pero en las últimas versiones depende de la carga de trabajo que tengo el sistema.  Windows es el que lo pone más complicado, ya que tarda días en hacer las peticiones, además de que no permite cambios muy grandes en los tiempos, desechando las peticiones que vienen con grandes saltos, dejando una ventana muy pequeña de ataque.

Figura 4: Cuatro de los cinco modos de funcionamiento que tiene Delorean para viajar en el tiempo

Visto esta primera parte, el resumen sería que, con mayor o menor grado de exposición, si un equipo se conecta a una red insegura, su fecha del sistema puede ser alterada de forma maliciosa por medio de una herramienta escrita en Python, que José Selvi ha bautizado como Delorean.

Ataques a HSTS con el Delorean

Visto esto, que un equipo tenga una fecha maliciosa puede ser aprovechado por un atacante para hacerle mucho daño a un equipo. Uno de los ejemplos que propone José Selvi es el de atacar el protocolo HSTS. Este protocolo cierra la posibilidad de ataques Man in The Middle que se producen cuando se utilizan conexiones HTTP, ya que con HSTS se fuerza al navegador a que la conexión sea siempre por HTTPs cuando un dominio esté en la lista. Esto se hace mediante la configuración del HTTP Header HSTS que envía el servidor web en la primera conexión. A partir de ese momento se le impide al navegador conectarse a un dominio por HTTP mientras el TTL configurado por el HSTS sea mayor que cero. Es decir, que no haya caducado.

Desde las URLs internas de Google Chrome, puedes consultar el estado de la política HSTS que tiene tu navegador para cada dominio, así como los datos del certificado que se espera encontrar al otro lado para que no le den uno falso. Es decir, no solo la política de HSTS, sino también cuál es el certificado del que se está haciendo Certificate Pinning.

Figura 5: Configuración de HSTS para el dominio www.gmail.com en Google Chrome

Sin embargo, usando el Delorean alguien puede llevar la fecha más allá en el tiempo, hacer que caduque el TTL de la configuración HSTS y conseguir una petición HTTP a un dominio para lograr hacer, ahora sí, un ataque de SSLStrip, como el que hacía yo con Evil FOCA para robar las cuentas de Facebook o Gmail usando el ataque de WPAD.

Figura 6: Si consigues deshabilitar HSTS puedes conseguir que el navegador pida Facebook por HTTP

A día de hoy esto no es posible con todos los dominios, ya que algunos navegadores tienen listas preconfiguradas en el código, es decir, hardcodeadas, de conexiones HSTS que no van a realizarse nunca por HTTP - ni la primera vez -. Esta lista la gestiona Google Chrome y la utilizan otros navegadores. Además, cualquiera puede solicitar estar en esa lista mediante este sitio web.

Figura 7: Configuración de política de expiración en lista precargada de certificados

Por suerte o por desgracia, los certificados de esa lista también dependen del tiempo y expiran - y no tardando mucho ya que algunos son horas, otros como Google Chrome 10 semanas -, así que es posible hacer caducar la lista precargada en los navegadores y forzar la conexión HTTP a un sitio web para lograr interceptarla y hacer un man in the middle a esa conexión.

Usando certificados digitales expirados

Otra de las cosas curiosas que se pueden hacer es la de llevar con el Delorean la fecha del sistema a un tiempo en el pasado, con el objeto de lograr que los certificados que hubieran expirando antaño o que hayan sido marcados como caducados, vuelvan a ser válidos. 

Figura 8: Certificado de Diginotar firmado para Google.com que se bloqueó

Así, por ejemplo, José Selvi explica cómo se puede engañar a un navegador para que vuelva a dar por válidos los certificados robados a Diginotar que se hicieron para firmar dominios como Google.com o Live.com. Pero también para conseguir que certificados de las listas CRL que han sido marcados como caducados vuelvan a poder usarse.

Los planificadores de tareas y las actualizaciones de seguridad

Por último, una de las cosas más curiosas que se producen es que, si un equipo cambia su fecha y su hora, todo su planificador de tareas puede dejar de funcionar. Esto hace que las tareas de mantenimiento puedan no realizarse a tiempo o incluso no hacerlo nunca. En el caso de Windows, una de las cosas que se puede hacer es llevar la fecha del sistema a un tiempo en el futuro, y cuando se planifique la siguiente actualización de software mediante Windows Update, volver a llevar el sistema a su hora actual. Esto, como efecto lateral dejaría a un equipo sin actualización de parches de seguridad.

Figura 9: Configuración de Windows Update para febrero de 2016

Mis más sinceras felicitaciones a José Selvi por este trabajo. De que forma tan sencilla ha enlazado los ataques de man in the middle, las debilidades NTP - que ya eran conocidas - con la seguridad de HTTPs para lograr, con una herramienta sencilla escrita en Python cargarse su seguridad en ciertos entornos. Me encanta.

Saludos Malignos!

49 productos de ciberspionaje de la NSA creados por ANT

El número de proyectos de hacking utilizados para el ciberespionaje hechos por la NSA es muy alto. Desde que comenzaron las noticias referentes a las prácticas extra-limitadas de espionajes hechas por la Agencia de Seguridad Nacional norte-americana hemos ido conociendo nombres de proyectos como Sinapsis, DropJeepOut, Tempora, etcétera, etcétera, todos ellos dedicados a alguna de las fases de recolección o análisis de la información capturada.

Figura 1: NSA Ant

Dentro de esas operaciones, el grupo Ant "Hormiga", se dedican a crear productos de software que deben utilizarse para troyanizar terminales, equipos de sobremesa, portátiles, software industrial, etcétera, y de ellos ya conocemos muchos de los productos que crearon. Como este proyecto Swap, orientado a lograr la persistencia del backdoor mediante la explotación de bugs en la BIOS y el uso del Host Protected Area del disco duro del equipo.

Figura 2: Proyecto ANT SWAP

Así, como este, hasta un total de 49 proyectos de Ant que han sido recopilados en un post del blog Leaked Source y que yo he convertido en un documento PDF que he subido a mi SlideShare para que podáis descargarlo y analizarlo en detalle.

Figura 2: Productos de ANT

La verdad es que técnicamente no tiene ningún desperdicio y en ellos puedo reconocer muchas de las charlas dadas en conferencias como DefCON, BlackHat o CCC, lo que deja claro que los equipos que trabajan en Ant se miran muy mucho todas estas conferencias. Casi todos los proyectos son del 2008 - el primer año que yo asistí a DefCON -, y desde entonces yo he visto conferencias sorprendentes, así que miedo me da pensar qué es lo que podrían tener montado desde 2008 al 2013.

Saludos Malignos!

MetaShield Protector, el ENS, el IBEX 35 y los líderes DLP

En el año 2008 publicamos la primera versión de FOCA. En aquel momento era una herramienta centrada en buscar fugas de información de empresas a través de los metadatos, la información oculta y los datos perdidos que contenían los archivos públicos de una organización.

Durante varios años evolucionamos la herramienta y las capacidades de la misma, además de impartir cientos de charlas sobre lo importante que era tener cuidado con estas fugas de información. Entre ellas, conferencias en BlackHat Europe 2009 y Defcon 17 con "Tactical Fingerprinting using metadata, hidden info and lost data" y Defcon 18 con "FOCA 2: The FOCA strikes back", además de estar en el BlackHat USA Arsenal de 2010, donde se contaba la demo de cómo, por ejemplo, se podría hacer un ataque dirigido a la Agencia de Misiles Americana usando metadatos.

Figura 1: Metadatos en la Missile Defense Agency

A lo largo del año 2009 comenzamos a crear MetaShield Protector, un software que evitaba la fuga de información en documentos publicados en servidores web Internet Information Services, y en gestores documentales de la familia SharePoint, y nos concedieron el Premio Red Seguridad al producto más innovador en seguridad de ese año.

También ese mismo año, el gobierno empujaba el Esquema Nacional de Seguridad, que sería aprobado al siguiente con una parte del mismo dedicada a las recomendaciones de seguridad respecto de los metadatos, para evitar riesgos asociados a una mala gestión de los mismos.

Figura 2: Programa CLEAR para detectar fugas por metadatos

Visto todos estos movimientos, parecía bastante evidente que las fugas de información por culpa de los metadatos en los documentos públicos tenían los días contados. Esto se podría esperar aún más cuando incluso el gobierno de los Estados Unidos había decidido crear el programa CLEAR para eliminar las fugas de información de las webs, y tenía en cuenta los metadatos.

Nada más lejos de la realidad.

Desde que comenzamos la andadura de Eleven Paths, decidimos comprobar cuántas empresas estaban teniendo cuidado con los metadatos, así que evaluamos diferentes entornos y se hicieron muchos informes internos con datos sectoriales relativos a las fugas de información.

Uno de los informes está referido al número de empresas españolas que cotizan en bolsa dentro del IBEX 35, para ver cuántas de ellas estaba teniendo una política de limpieza de documentos públicos, tal y como recomienda el Esquema Nacional de Seguridad y las buenas prácticas de seguridad.

La prueba fue bastante sencilla, y consistió en descargar documentos publicados en el sitio web del domino principal de la empresa y comprobar si era posible o no obtener datos de ellas. La conclusión fue que de todas ellas fue posible obtener información a través de los metadatos, es decir, que ninguna estaba teniendo una protección o política de seguridad que contemplara estas fugas de información.

Figura 3: Totales de fugas de información en empresas del IBEX 35

La segunda prueba se nos presentó cuando dimos con uno de los cuadrantes mágicos de Gartner, en concreto con el de los líderes en Data Loss Prevention, lo que nos dio un buen grupo de análisis a tener presente. La prueba era más que evidente, sobre todo después de que hubiera leído hace tiempo un artículo sobre algo similar en el que no sé porqué me dio a mí en la nariz que la prueba parecía haberse hecho con nuestra FOCA.

Figura 4: Cuadrante Mágico de Gartner de empresas líderes en DLP

Uno de nuestros compañeros decidió ir a las webs de las empresas líderes en Data Loss Prevention, descargar los documentos públicos y pasarlos por la FOCA, para ver cuáles estaban teniendo cuidado con la fuga de información por culpa de metadatos. La sorpresa es que ninguno de los líderes tenía cuidado alguno de los metadatos.

Figura 5: Resumen de fugas de datos en metadatos por empresas líderes en DLP

Para evitar que el mensaje se distorsionara, evitamos usar nombres asociados a cantidades concretas, pero lo que nos dejaron claras estas pruebas fue que aún el mercado no ha tomado conciencia de todos los riesgos asociados a los metadatos, y por supuesto decidimos seguir trabajando en mejorar nuestros productos de seguridad de este área.

Figura 6: Gráfica resumen por empresas y tipos de datos extraídos

Mejoramos MetaShield for IIS e hicimos una nueva versión de MetaShield for SharePoint, construimos una herramienta que limpia los metadatos de los documentos almacenados en carpetas de un servidor de ficheros, ya sean locales o de red al que hemos llamado MetaShield for File Servers, a la antigua Forensic FOCA la hemos evolucionado al producto que actualmente llamamos MetaShield Forensics y sacamos al mercado una herramienta que bautizamos como MetaShield for Client que pudiera instalar cualquier persona en su equipo para limpiar los metadatos con un solo clic.

Figura 7: Familia de productos MetaShield Protector

Por supuesto, la herramienta Faast también tiene entre sus objetivos la extracción de los metadatos de los documentos públicos para crear inteligencia en el proceso de pentesting persistente, tal y como lo hace FOCA, porque al final, visto lo visto, sigue siendo una fuente de información sensible que hay que tener en cuenta. Y en el interín han pasado más de cinco años, y parece que todo sigue igual. Aún la gente sigue preguntando ¿qué dices le pasó a Tony Blair con los metadatos de un documento? Meta-sorprendente.

Saludos Malignos!

WebBrowsing Fingerprinting con códigos de estado HTTP

De la reciente DEFCON 21, una de las charlas que más me ha gustado  - y que, además, tiene relación con lo publicado en este blog recientemente sobre el Web Browser Fingerprinting y con algo que me ha interesado a mí personalmente desde hace tiempo - ha sido la que ha dado Chris John Riley con el título “Defense by numbers: Making Problems for Script Kiddies and Scanner Monkeys”.

Figura 1: Defense by numbers: Making Problems for Script Kiddies and Scanner Monkeys

Su estudio, realizado sobre los tres navegadores más utilizados - Microsoft Internet Explorer, Mozilla Firefox y Google Chrome -  analiza que tipo de comportamiento tienen estos ante diferentes códigos de respuesta HTTP, esto es, qué hace un navegador cuando recibe una respuesta que no es 200 OK. Los servidores web pueden responder con distintos códigos a los clientes para informarles de las consecuencias que han tenido sus peticiones, siendo los más frecuentes:

• 200 OK
• 304 Not Modified (cuando solicitamos un fichero que ya tenemos en la cache de nuestro navegador)
• 404 Not Found
• 500 Internal Server Error

Pero hay muchos más, ¡muchísimos! Podéis ver una lista bastante completa en la página de la Wikipedia sobre códigos de respuesta HTTP.

Lo que este hombre ha probado y testeado es la forma de actuar de estos navegadores ante páginas que devuelven códigos HTTP distintos de los esperados. Además ha probado esto con distintos elementos HTML como iframes, imágenes o ficheros JavaScript remotos, y a la conclusión a la que ha llegado es que, ante la mayoría de los códigos de respuesta, los navegadores actúan como si el código fuera 200 OK (es decir, muestran la página sin mostrar ningún tipo de mensaje de error)

Figura 2: Respuesta en base a los códigos HTTP enviados por el servidor

Como se puede ver en la tabla anterior, distintos navegadores para distintos códigos producen distintos resultados. Una de las aplicaciones en las que se puede usar esta diferencia de respuestas es en el fingerprinting de navegadores web, algo muy útil para la industria de la seguridad. De su análisis concluye, entre otras cosas, que:

• Mozilla Firefox: No carga ficheros JavaScript si el código es 300 Multiple Choices, IE y Chrome si lo hacen
• Google Chrome: Carga ficheros JavaScript si el código es 307 Temporary Redirect, Firefox e IE no lo hacen
• Microsoft Internet Explorer: Carga ficheros JavaScript si el código es 205 Reset Content, Chrome y Firefox no lo hacen

Con estas pequeñas diferencias ha puesto a disposición de todos un pequeño POC en Internet e incluso el código fuente disponible en su repositorio de github.

Figura 3: Detección de Mozilla Firefox con WB Fingerprinting usando códigos HTTP

Esta técnica y este estudio son una gran base de información para entender mejor cómo funcionan los navegadores, además de, como en su objetivo original, penalizar a las herramientas automáticas que confían en el código de respuesta del servidor para reconocer el éxito o fracaso de un intentando de ataque.

Por supuesto, uno de los objetivos principales de las técnicas de WebBrowsing fingerprinting es la de poder luchar contra el Fraude Online en Internet. Supongamos que un usuario se conecta a su cuenta bancaria habitualmente desde el equipo de su casa, donde utiliza para entrar en la web de su banco MS Internet Explorer 9 y un día sus credenciales bancarias son robadas por un malware. Si el banco ha generado una huella digital de la conexión a sus servicios online y un tiempo después se intenta hacer una transferencia desde un equipo en el que se está usando otro navegador o en el que se detecta que se está haciendo un spoofing del USER-AGENT, entonces probablemente sea una transferencia fraudulenta.

Saludos!

Autor: Pedro Laguna (@p_laguna)

El documental sobre DEFCON

Hace tiempo que se sabía que se había hecho un documental sobre las conferencias DEFCON. Ahora, desde hace ya algunos días, está disponible en la red y publicado en YouTube. Si quieres ver un poco del ambiente que se respira por allí, invierte un par de horas este verano para vértelo, porque merece la pena.

Figura 1: El documental sobre DEFCON

Espero que los más jóvenes os motivéis para que en el futuro estéis todos por allí presentando vuestros trabajos, que como podéis ver es un entorno magnífico para disfrutar de la pasión de la seguridad informática y el hacking.

Saludos Malignos!

DEFCON 21: Fear the Evil FOCA [Video-Screener]

Uno de los asistentes a DEFCON 21 grabó la charla que di de Fear the Evil FOCA: Attacking Internet Connections with IPv6 directamente desde la sala. Ni el sonido ni el vídeo son perfectos, pero yo la he visto y se puede seguir bastante bien.

Figura 1: Vídeo de DEFCON 21 grabado por @asimex

Si queréis, además tenéis las diapositivas de la charla ya publicadas, y las podéis ver online al mismo tiempo que seguís la sesión. Y Evil FOCA se puede descargar ya desde Eleven Paths.

Defcon 21 - Fear the Evil FOCA: mitm attacks using IPv6 

Las demos que realicé en la presentación son:

- Te van a hackear en IPv6 por pensar que no lo usas
- Neighbor Spoofing en IPV6 para capturar ficheros SMB
- Ataque SLAAC en IPv6
- Web Proxy AutoDiscovery en IPv6

Y los otros posts de los que hablé en la charla son:

- IPv6 Conceptos Básicos I
- IPv6 Conceptos Básicos II
- Man in the middle en redes IPv4 usando IPv6
- Pasar de IPv4 a IPV6 con una respuesta DNS no pedida
- Activar IPv6 en Google Chrome
- Bridging HTTP-s(IPv4)/HTTP(IPv6)
- Topera: Un escanner de puertos sobre IPv6
- Apache Slowloris y más herramientas de pentesting en IPv6
- Michael Lynn y el CISCOGate en IPv6
- Predicción de direcciones IPv6 de vínculo local en OS X
- Ataque D.O.S. SLAAC: Desactivar IPv6 si no lo utilizas
- Ataque DHCP ACK Injector

Y si quieres más, pues el libro de Ataques en Redes de Datos IPv4 e IPv6 te ayudará con más demos y conceptos de hacking de redes.

Saludos Malignos!

Man in the Middle con Web Proxy Auto-Discovery en iPv6

La principal novedad de la versión de Evil FOCA que presenntamos en esta edición de DEF CON 21 es la implementación del ataque Web Proxy Auto-Discovery tanto en IPv4 como en IPv6, tal y como se podía ver en las diapositivas de la presentación que os dejé ayer. Además de eso, también se metió como "bonus extra" la implementación del strippeado de los resultados de Google, para que los ataques fueran más efectivos. Esta es la demo que realicé durante la presentación, paso a paso.

Descubrimiento del servidor Web Proxy Auto-Discovery

Los navegadores de Internet, por defecto, vienen configurados para buscar al servidor Web Proxy Auto-Discovery de la red mediante un registro DNS well-known llamado WPAD. Este registro es uno de los que la FOCA busca, por ejemplo, para sacar información de la red interna de una organización. Esta opción está activada en los navegadores, tal y como se puede ver en las opciones de este Internet Explorer.

Figura 1: Opción de buscar auutomáticamente la configuración de la red

Por supuesto, yo os recommiendo a todos que las quitéis si estáis en una red que no es vuestra, y si es una red gestionada por vosotros, aplicad alguna política para erradicar su activación en todos los navegadores si no hacéis uso de esto.

Este registro WPAD es buscado automáticamente por la red mediante el protocolo LLMNR, tal y como se puede ver en la siguiente imagen, tanto por IPv4 como por IPv6, pero buscando un registro tipo A, es decir IPv4.

Figura 2: Búsqueda del servidor WPAD por medio de LLMNR

La búsqueda de WPAD se hace por multicast, y en nuestro entorno, Evil FOCA captura la petición a multicast IPv6 y contesta con una dirección IPv6 en un registro AAAA, usando el mismo truco que usamos en el ataque SLAAC para pasar de A a AAAA.

Figura 3: Evil FOCA contesta con un registro AAAA

Al cliente parece que esto le deja un tanto preocupado, así que realiza una confirmación, buscando el registro WPAD por LLMNR, pero esta vez preguntando por su valor AAAA.

Figura 4: El cliente pide por LLMNR el valor de WPAD para AAAA

Para que Evil FOCA confirme que sí, que este es el servidor Web Proxy Auto-Discovery de la red y está en una dirección IPv6. Como se puede ver en la imagen, la dirección IPv6 que se usa es una dirección de vínculo local IPv6, por lo que no es necesario hacer un ataque SLAAC previamente para confgurar un gateway en IPv6.

Figura 5: Evil FOCA confirma la dirección IPv6 del WPAD

El fichero de configuración WPAD.PAC para descubrir al servidor Web Proxy

Una vez que el cliente descubre la dirección IPv6 en donde está el servidor Web Proxy Auto-Discovery, se conectará a este para conseguir la información del servidor Web Proxy de la red, que no tiene porqué ser el mismo. Es decir, el servidor Web Proxy Auto-Discovery es un servidor web donde se almacena un fichero de configuración que le dice al cliente web dónde se encuentra el servidor Web Proxy.

Figura 6: Solicitud al servidor WPAD del fichero de configuración WPAD.PAC

Este fichero de configuración se llama WPAD.PAC y es solicitado por el cliente, para que la Evil FOCA se lo entregue conn la información del lugar donde está levantado ese servidor Web Proxy.

Figura 7: Contenido de WPAD.PAC entregado por Evil FOCA con información del Web Proxy

Hay que tener en cuenta que si el cliente utiliza Google Chrome, este ataque no funcionará, ya que IPv6 viene desactivado por defecto. En ese caso se hace exactamente lo mismo, pero seleccionando en Evil FOCA el ataque WPAD en IPv4.

El ataque con Evil FOCA

Por supuesto, en Evil FOCA esto es tan sencillo como arrastrar el equipo al panel del ataque WPAD en IPv6, hacer clic en Start y Evil FOCA se encargará de interceptar la petición del registro WPAD del cliente, servirle vía web el fichero WPAD.PAC y hacer de servidor proxy HTTP, aunque vamos a confgurar la opción de usar un servidor proxy remoto para hacer algo similar a lo de la JavaScript Botnet del año pasado.

Figura 8: El ataque WPAD en IPv6 con Evil FOCA

Una vez acabada esta fase, el cliente podrá navegar por Internet, pero lo estará haciendo a través de un servidor Web Proxy en IPv6 que hará de man in the middle. Y ya que está en el medio, una de las cosas que le hemos añadido a Evil FOCA es la posibilidad de hacer SSLStrip de todos los resultados de una respuesta de Google, quitando el redirect que implanta, y cambiando los enlaces HTTP-s por enlaces HTTP.

Figura 9: Resultados de Google a través de Web Proxy en IPv6 strippeads

Por supuesto, cuando el cliente solicita una página que pide ir por HTTP-s, como la de Facebook, la herramienta Evil FOCA implementa Bridging HTTP (Pv6) / HTTP-s (IPv4), es decir, negocia con el servidor de Facebook en HTTP-s con IPv4, pero al cliente le entrega todo bajo HTTP con IPv6.

Figura 10: Facebook vista bajo HTTP(IPv6)

Esto tiene algunas implicaciones con respecto a las cookies que van marcadas como Secure, obligando a tener cuidado con la información que se envía al cliente y al servidor, pero al final, todos los datos se envían sin cifrar desde el cliente a Evil FOCA, pudiéndose robar las credenciales.

Figura 11: Credenciales de Facebook interceptadas en WireShark

Esta sermana publicaremos la versión en el blog de Eleven Paths, para que podáis testearla vosotros mismos, y en el libro de Ataques en Redes de Datos IPv4 e IPv6 tenéis más información sobre ataques man in the middle en estas redes. Las otras dos demos que realicé en la presentación las tenéis paso a paso en los artículos de Ataque SLAAC con Evil FOCA y Ataque Neighbor Advertisement Spoofing con Evil FOCA.

Saludos Malignos!