¡Hola hackers! Normalmente no empiezo los artículos con tanta efusividad. Me suele gustar preparar una intro en la narración que os vaya cocinando el ánimo de la lectura cual cenita rica al horno. Suelo empezar con una retahíla de ideas, sonidos, colores y palabras retorcidas que esconden un mensaje para que cuando comience la enunciación de los mensajes ya tengáis las orejas y los ojos en el tiempo óptimo de horneado.
Figura 1: El número al que llama está apagado o fuera de cobertura
Vale, sí, detrás de la efusividad de la primera frase he jugado con vosotros en el mismo viejo estilo del maligno, pero es que el contenido de este post es tan sencillo como directo. Os abandono durante un tiempo. Apago el móvil. Cierro el e-mail. Dejo de publicar en el blog. Corto el Twitter. No actualizo el Instagram. Adios durante unos días. Pero no para siempre.
Es momento para ello. Mis planes para este H1 del año eran lanzar AURA en 6 países, anunciar Movistar Home, hacer el lanzamiento de la campaña de AURA en España y el Meet Movistar Home que tenemos en las tiendas. Hacer nuestro Big Data for Social Good de LUCA, la participación de ElevenPaths en la RSA y el Security Day con el lanzamientos de los productos que hicimos, al tiempo que avanzaba el despliegue y alcance la 4ª Plataforma. A eso además sumamos el trabajo en 0xWord con la culminación en el evento de 10 años. Y mis compañeros que son unos máquinas lo hicieron, así que puedo irme a descansar, que lo necesito.
Para H2 tenemos nuestros próximos retos. El lanzamiento final de Movistar Home en Octubre, el Security Innovation Day de ElevenPaths y el LUCA Innovation Day. nuestros eventos por excelencia en estas unidades, el Encuentro interno con la presentación de alguna nueva sorpresa.... y pensar en el MWC del año que viene. Así que van a hacer falta las fuerzas que tome estos días, que como todos los años, viajaré a Silicon Valley a finales del mes que viene.
Para los que pensáis que yo soy el que me ocupo de programar, gestionar y velar por toda la tecnología y la seguridad de la casa repasando los bits uno a uno by myself, os quiero tranquilizar. Esto es algo que como una gran compañía que somos lo tenemos organizado y procedimentado. Mis compañeros, cada uno en sus áreas fuera de mis unidades estarán velando por todo.
Y en mis unidades en concreto (AURA, 4P, 11Paths, LUCA+Advertising y Movistar Home) todo está organizado para que todos - absolutamente todos - los que trabajamos podamos irnos tomando vacaciones. ¿Magia? No lo creo... Os prometo que hemos conseguido organizar el trabajo para que los trabajadores nos podamos ir unos días de asueto. Os deseo a todos que también seáis capaces de lograr esto de tomaros unos días. Eso sí, hoy os dejo grabada una cosita chula que publicaré en Agosto para ver si os gusta.... que será especial y la hago con Mi Survivor.
Como siempre, serán días de familia, deporte, música, lectura, y descanso. Espero poder tomarme cervecitas, comer helados, correr, nadar, montar en bicicleta y no echaros de menos en absoluto, que ya estoy el resto del año con vosotros por aquí. Un fuerte abrazo maligno para todos los que día a día estáis cerca de mí.
Si te acercas al Espacio de la Fundación Telefónica y visitas la espectacular exposición permanente de “Historia de las Telecomunicaciones” (como ya nos contó Chema Alonso), entre todas las fantásticas piezas expuestas podrás ver una máquina Enigma. Un motivo más que suficiente para visitar la exposición. Aunque estos aparatos no son muy comunes, es relativamente fácil encontrarlas en museos alrededor del mundo. Pero esta en concreto es un poco diferente, así que merece la pena que te detengas unos minutos y prestarle un poco más de atención, ya que es una "Spanish Enigma".
Figura 1: La “Spanish Enigma“, su aportación clave al descifrado final de Enigma y el rapapolvo de Betchley Park
Esta máquina Enigma tiene algo especial, tanto en su diseño como su historia, ya que este modelo tuvo protagonismo en su descifrado final. Es inevitable hablar de Enigma y que inmediatamente no aparezca Alan Turing, uno de los padres de la Inteligencia Artificial y de la computación en general, el cual fue clave en el descifrado de sus códigos desde los cuarteles de Bletchley Park, en Inglaterra.
Estamos hablando de la rara y poco común "Spanish Enigma", posiblemente sea una de las 26 (no hay muchas de este modelo por el mundo) que se encontraron en 2008 en perfecto estado en un cuartel militar de Madrid. Vamos a contar un poco lo que hay detrás de esta maravillosa máquina y ya verás como ahora verás esa máquina Enigma de una forma distinta.
Al comienzo de la Guerra Civil Española en 1936, las tropas nacionales de Franco compraron 10 máquinas Enigma a Alemania, mientras esperaban otra remesa que solicitaron unos años antes, cuyo pedido se estaba retrasando demasiado. Era necesario cifrar lo antes posible toda la información ahora que había comenzado la Guerra Civil.
Pero el alto mando de Hitler estaba preocupado por si estas máquinas caían en manos de los republicanos así que no les enviaron su mejor y último modelo, sino una versión prácticamente idéntica al modelo comercial “D” denominada esta vez como “K”. De hecho, estos equipos estaban a la venta desde los años veinte, así que los británicos consiguieron su primera máquina Enigma en 1927 de esta sencilla forma, simplemente comprándola.
Antes de continuar con la historia, vamos a ver por qué estas máquinas Enigma “K” (posiblemente la “k” vendría de “comercial” en alemán “Kommerziell”) encontradas en España con los números de serie A-XXX y K-XXX, son diferentes al resto. El modelo K, conocida internamente como A27 (27 por el año de fabricación 1927), fue una adaptación de la Enigma comercial, conocida internamente como A26. Esta era el modelo de la gama comercial más fuerte.
En primer lugar, tenemos que fijarnos en los cuatro rotores o ruedas (wheels) y la ausencia de un panel frontal (plugboard), presente en la mayoría de máquinas Enigma militares usadas por el ejercito alemán. Los rotores son posiblemente los elementos más importantes del dispositivo. Por defecto, la mayoría sólo llevaban tres rotores y su función era añadir el máximo de dificultad posible realizando un cifrado por sustitución, es decir, internamente venían ya “programados” con unos cambios definidos en su cableado interno (por ejemplo, el contacto número 1 se podía asignar al contacto 19 lo que implicaba cambiar la letra correspondiente a ese contacto por otra). Estos rotores estaban a su vez interconectados entre ellos conectando la salida de uno con la entrada del otro.
Entonces ¿por qué tiene cuatro rotores la Spanish Enigma?. Pues el cuarto rotor de nuestra Enigma se llama “reflector” (UKW) permitía añadir más complejidad además de permitir su decodificación a partir de la clave de cifrado. Este rotor evolucionó en versiones posteriores en un panel frontal o plugboard que hemos comentado antes. Por eso esta máquina no tiene el característico panel frontal de conexiones ya que esta función, bastante más limitada, la realizaba el rotor UKW, lo que hacía que esta máquina Enigma fuera un poco más sencilla de descifrar que sus sucesoras.
También hay que indicar que la Spanish Enigma utilizaba unos rotores modificados a medida con unas claves distintas a las que se suministraban de serie, lo que despistó en un principio al equipo de Bletchley Park. Destacar que la única máquina Enigma con cuatro rotores reales fue la temida Enigma M4 (o U-boat Enigma), que fue descifrada por Alan Turing y su equipo.
Debido a este diseño, pero principalmente a su incorrecto uso como veremos más adelante, los británicos lograron comprender y emular el funcionamiento de Enigma. En concreto fue posible gracias a Dilly Knox, un experto en descifrar manuscritos antiguos que trabajó en Bletchley Park junto a Alan Turing.
Dilly Knox trabajó estrechamente con el equipo polaco, los cuales fueron los primeros en descifrar los mensajes alemanes durante los años 30, hasta que estos actualizaron su Enigma, poniéndolos en una situación desesperada (ya que la invasión parecía inminente y hasta ahora tenían controladas las comunicaciones) haciendo que estos pidieran ayuda a los franceses y británicos.
Esto proporcionó la información sobre cómo habían estado descifrando los mensajes alemanes hasta entonces, siendo esta una pieza clave que finalmente contribuyó a su descifrado final. Knox consiguió decodificar todas las comunicaciones creadas con las máquinas Enigma “K” generadas por los ejércitos españoles y los italianos, aunque el verdadero objetivo de Knox era descifrar las comunicaciones alemanas, las cuales estaban mejorando y añadiendo complejidad de forma progresiva.
Pero había un problema, las señales de radio alemanas no se recibían desde Gran Bretaña, pero sí las generadas por el ejercito español entre España y su embajada en Berlín, las cuales se recibían perfectamente desde las costas británicas. Así que Knox se puso manos a la obra, por fin tenía señales cifradas reales con las que probar sus técnicas de descifrado. Además, las comunicaciones cifradas con la Spanish Enigma entre el alto mando español ubicado en Madrid y las tropas destinadas en Alemania (como la División Azul) e incluso otras que pertenecían al mando alemán, eran bastante frecuentes.
Y aquí es donde empieza el "troleo histórico" y el rapapolvo del equipo de Bletchley Park a los militares del ejército de Franco que usaban la Enigma.
Cuando los británicos descifraron las máquinas nadie se enteró como ya podéis imaginar. Tanto fue así y tan engrasada estaba la maquinaria de descifrado de Bletchley Park que los aliados conocían el contenido de los mensajes cifrados antes que el mismísimo alto mando alemán, tal y como contamos en nuestro libro “Microhistorias: anécdotas y curiosidades de la Informática”.
Todos sabemos las maravillosas y positivas consecuencias de este gran logro al descifrar las máquinas Enigma, sobre todo en acortando el tiempo de guerra y por lo tanto reduciendo el número de víctimas. Pero pocos saben que después de la guerra tampoco se hizo público que los Aliados habían conseguido este logro.
Los países que compraron las máquinas Enigma a los alemanes la siguieron usando después de la guerra totalmente confiados, como pasó en el régimen de Franco en España, pensando que aún eran seguras. Pues esto no era así y durante varios años después de caer Hitler y su régimen de terror, los Aliados sabían absolutamente todos los movimientos de los países que aún enviaban mensajes utilizando la “Spanish Enigma” (o cualquier otra posterior). Y esto duró hasta principios de los años 50 cuando ya se dejaron de utilizar definitivamente.
En un informe creado por el equipo de Bletchley Park aparece el siguiente texto hablando sobre la mala utilización por parte de las fuerzas franquistas de la máquina Enigma:
“Como nos esperábamos (debido a la estructura con repeticiones de los mensajes), los españoles utilizaban Enigma de una forma infantil e incompetente. El orden de los rotores nunca cambiaba, y las claves se creaban para durar hasta cien días, el Ringstellung (manilla del rotor que se usaba para cambiar las posiciones del cableado interno de los rotores) duraban hasta 10 días y los indicadores de sustitución hasta cien días”.
Al parecer los militares que utilizaban las máquinas Enigma no estaba instruidos en las bases mínimas para poder generar mensajes correctamente para que fueran lo más complejos posible. Como por ejemplo cambiar el orden de los rotores a diario como mínimo (aunque más adelante se llegó a un nivel de paranoia mayor, realizando cambios no sólo de los rotores, con más asiduidad casi por mensaje).
Así que la clave principal que llevó a su descifrado, al igual que ocurrió con la Enigma nazi más delante, estaba en la repetición de dichos mensajes y también en la pobre elección de claves (nombre de ríos y provincias españolas, países, etcétera). En general, por las malas prácticas en el uso de la máquina.
Pero esto no fue lo que llevó a los británicos a descifrar las comunicaciones españolas, sino el uso repetitivo de mensajes usando la misma clave de los italianos, al menos 20 mensajes. Esto fue lo que realmente ofreció una pista sólida a los británicos para descifrarlos y averiguar el cableado usado por los italianos, y claro, más tarde se dieron cuenta que los españoles usaban el mismo para poder comunicarse con ellos.
En concreto había un mensaje con la frase “DIVISION NO HA DADO HOY PARTE NOVEDADES” (posiblemente dirigido a la División Azul que combatía con los alemanes) que se repetía a menudo y los criptógrafos de Bletchley Park consiguieron encontrar una relación entre en texto cifrado y las letras contenidas en este mensaje.
Knox consiguió descifrar la Spanish Enigma sólo utilizando lápiz, papel y cerebro. Pero para conseguir descifrar la Enigma M4, Alan Turing además de los mismos elementos que usó Knox utilizó uno adicional, uno electromecánico, la Bomba o Bombe. Había nacido la era moderna de las comunicaciones cifradas y de los ordenadores.
NOTA: Si queréis toda la información detallada sobre la Spanish Enigma, no dudéis en consultar este magnífico documento. En 2012 hicimos una visita a Blechtlley Park, en este enlace podéis ver la primera y la segunda parte con muchas fotos interesantes como máquinas Enigma, una réplica de Bombe y las famosas “hut” (cabañas) donde trabajaban los equipos de descifrado de Alan Turing (incluido su despacho).
Autores:
Como sabéis, esta semana en 0xWord se está cerrando el año. Como siempre, antes de cortar en verano para las vacaciones y hacer inventario, se ha habilitado un código descuento de 10% en todo el material que puedes utilizar para aprovisionarte de todos los libros que te hagan falta y estudiar mucho este periodo de relax.
Figura 1: Mañana acaba el plazo del cupón de 0xWord
Mañana, a las doce de la noche dejará de funcionar el código, y las compras que se hagan a partir de ese momento serán entregadas a partir del mes de septiembre, así que este es un buen momento para que te hagas con el material que necesites.
A principios del mes de julio se publicó un exploit que afectaba a la versión 2.2.8 de VLC e inferiores. Además, el exploit era funcional en Windows 10, lo cual siempre le da un toque de interés extra. El CVE asignado es el CVE-2018-11529. La vulnerabilidad radica en las versiones 2.2.X y es que VLC es propenso a una vulnerabilidad Use-After-Free (UAF Vulnerability) con la que un atacante puede ejecutar código ‘arbitrario’ a través del uso de archivos MKV.
Figura 1: Exploit para VLC 2.2.8 o inferior con ejecución de código en Windows10
Estos archivos MKV están creados de forma que cuando la aplicación ‘parsea’ el archivo se produce la explotación del UAF y la consiguiente ejecución de código. Cuando el exploit falla, se produce una denegación de servicio, ya que la aplicación ‘crashea’. El 9 de julio se publicó en SecLists el detalle de la vulnerabilidad con el exploit. Lo que más llamó la atención era el funcionamiento de la vulnerabilidad de tipo fileformat en los sistemas Windows 10.
Apareció un módulo para Metasploit
A día de hoy está en proceso de ‘pull request’ para que el módulo que ha aparecido se integre en la rama oficial de Metasploit. He querido probar el módulo y ver si realmente era funcional. Como indica la descripción, el módulo funciona para sistemas de 32 y 64 bits. La vulnerabilidad radica en el ‘parseo’ de los ficheros MKV.
Figura 2: Descripción del módulo de Mestasploit para el CVE-2018-11529
Para llevar a cabo la explotación de la vulnerabilidad, el módulo genera dos ficheros: el fichero que contiene el código que explota la vulnerabilidad, el segundo ayuda para disponer de la ruta del código vulnerable. El segundo debe encontrarse en el mismo directorio que el primero, cuando éste sea ejecutado.
Los payloads que se pueden utilizar y que se indican en la descripción son los exec, tanto en 32 como en 64 bits, y las shell reverse y de tipo bind, de nuevo en 32 y 64 bits. Los payloads de tipo Meterpreter provocan el crasheo de la aplicación.
PoC: Probando todo en mi entorno
Lo primero fue hacerse con la versión adecuada de VLC, ya que ésta no es la última. Es cierto, que la vulnerabilidad afecta a la última, y previas, de la rama 2.2.X, pero tenemos que tener en cuenta que existe la versión 3.0.0, 3.0.1, 3.0.2 y 3.0.3, por lo que se recomienda actualizar. La versión 2.2.8 es la última antes de que VLC pasara a la versión 3.0.0. Si queréis montar la prueba se puede obtener cualquier versión de VLC desde su repositorio de versiones.
Para poder obtener el módulo, ya que no se encuentra a día de hoy en la rama master, se puede descargar desde el Github de Metasploit en un Pull Request que se ha realizado y que, cuando se valide, pasará a formar parte de la rama oficial.
Figura 3: Opciones del módulo
Si miramos las opciones del módulo, son las típicas de un módulo de tipo FileFormat. Es decir, tenemos unos atributos para dos archivos que se generarán, los comentados anteriormente. Además, si ejecutamos show targets podemos ver para qué sistemas está probado el módulo. En este caso, versión VLC 2.2.8 en Windows 10 de 64 y 32 bits.
Se debe configurar el payload que se quiere meter en los archivos para que, en caso de que el exploit tenga éxito, se lleve a cabo la ejecución de código. Para este ejemplo, se ha utilizado una shell reverse TCP. El resultado de la ejecución del módulo es la creación de un par de ficheros MKV, uno de ellos con más de 900MB de tamaño.
Figura 4: Ficherso .mkv creados
Ahora, la víctima deberá ejecutar el primero de los ficheros MKV, es decir, el del atributo FILENAME. El pentester debe configurar el módulo exploit/multi/handler para recibir la conexión o generarla, en función del tipo de payload que esté utilizando, reverse o bind.
Figura 5: Configuración del hadler
Cuando el usuario de Windows 10 abra los videos con la aplicación VLC, ésta se cerrará inesperadamente y el pentester recibe la sesión a través del módulo exploit/multi/handler, tal y como se puede ver en la imagen.
Figura 6: Sesión obtenida
Es recomendable estar al día a través de sitios como Exploit-DB o el propio Github de Metasploit, ya que se puede encontrar información interesante sobre nuevos módulos que pueden aparecer en breve en la rama master.
Hace varios días que tengo ganas de sentarme a escribir un post sobre todo lo acontecido durante los siete días pasados. A explicar tal y como veo yo todo lo que ha pasado. No como persona que trabaja en ninguna empresa, sino como persona que lleva veinte años dedicado a reportar vulnerabilidades de seguridad a empresas. Es mi visión personal - y por tanto no oficial - de todo lo que ha pasado.
Figura 1: Una historia de hackers, bugs en aplicaciones y la web de Movistar
Como sabéis, esta semana ha habido mucho movimiento en medios y redes sociales sobre un bug en la web de Movistar con el que se podía acceder a datos de algunos clientes, y para evitar líos, preferí no contar nada hasta que los compañeros hubieran finalizado su trabajo. Ahora, tras hablarlo con ellos, creo que es el momento adecuado.
Sobre bugs, superbugs, megabugs, easybugs
Me gustaría decir que nunca en la tecnología que crean mis equipos va a haber bugs de seguridad. Me gustaría presumir y gritar a los siete vientos que lo que creamos no va a tener ningún fallo de seguridad. Pero no soy ningún iluso. Sé que la tecnología tiene fallos. Y los seguirá teniendo. De hecho, si alguien dice que su tecnología es 100% segura... me preocupo más.
No me voy a detener en citar los más de 1.000 bugs publicados este mes en productos de Microsoft, Oracle, Apple y demás compañías tecnológicas, porque creo que los que trabajamos en seguridad sabemos que este es nuestro día a día. Los bugs aparecen inducidos por muchas causas.
A veces simplemente por error humano. A veces por error en el proceso. A veces por cambios en el software base. A veces por cambios en la configuración. A veces por que simplemente no se pensaban posibles. Estos últimos son los que más me gustan, y denotan una maravilla tecnológica, como BEAST o CRIME contra HTTPs o Spectre & Meltdown contra los micros. Auténticas obras de arte.
Otras veces los bugs son sencillos y se cometen por errores humanos. Por descuidos. Por falta de verificación. Por falta de pruebas de QA, o por falta de pentesting. Son errores que aparecen en miles de sitios. En aplicaciones web he escrito hasta varios libros sobre ellos, como el de Pentesting con FOCA, Hacking Web Applications: SQL Injection, o el de Hacking Web Technologies.
De estos bugs sencillos - de estos últimos que son conocidos y fáciles en teoría de evitar - yo sé bastante. Llevo toda mi vida reportando XSS, SQLi, LDAPi, RCE, etc, etc, etc... a grandes empresas como Apple o Microsoft. De hecho, os he hablado muchas veces de esos. Como la shell que pillamos con la FOCA en los servidores de Apple - junto con otro buen montón de vulnerabilidades y Apple nos lo agradeció -.
Figura 3: Uno de los muchos bugs reportados a Apple
Figura 5 : Explotación de DirtyTooth antes de que Apple arreglara el bug
Los bugs existen, y nuestra misión es localizarlos y cerrarlos. No es magia, es solo ciencia. Ir cerrando y aplicando la seguridad por niveles a medida que aumenta el grado de madurez de una empresa. De todo ello he hablado en mil y una conferencia, pero os dejo esta que es donde creo que más enfoqué este asunto concreto.
Figura 6: Charla sobre la gestión de la seguridad
¿Dejará la tecnología que nosotros hacemos de tener bugs? La respuesta es no. Algunos serán complejos, otros sencillos. Nuestra misión es que haya el mínimo número de ellos y que se gestionen con resiliencia el 100 %. Es fácil de entender para cualquier profesional que trabaja en seguridad - que no hay que confundir con twitteros que pretenden serlo -.
Sobre el reporte de vulnerabilidades
Como sabéis, yo defiendo que los hackers son buenos. Son los investigadores. Son los que buscan (o encuentran a veces casi sin querer) los fallos de seguridad. Cuando eso me ha pasado a mí, o a alguno de mis compañeros, lo que siempre hacemos es pensar en el riesgo que tiene esa información.
Lo primero que pensamos es que esa información debe ser pública, porque puede ser que algún malo la esté utilizando en su provecho afectando a las personas sin que nadie sepa cómo lo está haciendo. Así que, a los que nos importa la tecnología y las personas, lo que hacemos es buscar el camino más rápido y más seguro para el reporte de vulnerabilidades, forzando a que la empresa tome medidas e informe de los fallos a las personas afectadas.
Figura 7: Cronograma de tiempos, riesgos y responsabilidades
Esto es algo que hemos hablado muchas veces. ¿Cuál es la forma responsable de reportar un bug? Y a lo que la industria - después de muchos años - ha llegado de consenso es a un proceso similar a éste, pero cada investigador es libre de hacer lo que quiera con su bug. Él toma la responsabilidad de buscar el bug, él decide qué hace con él. Yo tengo claro lo que hago yo con los míos. Lo normal es algo como esto:
- Contacta con la empresa que tiene la vulnerabilidad.
- Dale todos los detalles o negocio un bounty.
- Dale un tiempo antes de ir público (10 días, 20 días, 30 o 60 días).
- Publica los detalles.
De hecho, hay algunos investigadores españoles que han dado hasta un año a algunos fabricantes, pero para muestra este reporte de Raúl Siles de Session Fixation a en SAP donde les dio mucho tiempo antes de ir a público. Es decisión del investigador decidir el tiempo que le da - y si quiere darle tiempo incluso -. Al final, cada investigador lo hace por un objetivo.
Una vez que se ha hecho público, muchos investigadores dan "caña" a la empresa por no ser más rápida, o porque el bug era muy tonto, o porque la respuesta no fue correcta cuando se comunicó. Cada uno decide cómo va a público una vez que los usuarios están seguros y el bug parcheado.
De hecho, hay una frase que dijo Juliano Rizzo cuando publicó BEAST que llevaré conmigo siempre. Cuando les acusaban de poner en riesgo a los clientes con BEAST. Ellos avisaron a todos los fabricantes y el día que publicaron BEAST todos los sistemas estaban parcheados. Como él mismo dijo: "No hemos venido a liberar a la Bestia, hemos venido a matar a la Bestia".
Figura 9: Juliano Rizzo sobre BEAST
Por supuesto, si uno va público sin dar detalles del bug al fabricante del software, lo último que le preocupa, como es de entender, son los usuarios. Son las personas afectadas. De esos hay algunos. Son gente que busca bombo y platillo. Fama, ruido, o lo que sea, pero no que los usuarios estén seguros. De hecho, cuando esto suele pasar, en la industria se les critica mucho.
Yo primero los reporto y, después, cuando están resueltos, suelo escribir un post contando la historia. Es mi forma de hacerlo. A veces soy más crítico con la empresa - como cuando pusieron que el bug de CSSP de los servidores de gestión de bases de datos online no tenían un bug Highly Critical -. Es tu decisión. Pero ten claro que no puedes decir que te preocupan los usuarios si los dejas expuestos con un software que tiene un bug y le das el "arma" a los malos de verdad.
Sobre el bug de URL manipulation en Movistar
Centrándome ya en el bug de URL manipulation en la web de Movistar poco que añadir a lo que se ha comentado. En Hispasec lo contaban bien. Un usuario se autentica y accede a su factura. Cuando se modifica la URL para acceder a una factura que no es suya, sino de otro usuario, el backend verifica que el usuario está con sesión iniciada, pero no que esa factura es una de las que puede y debe ver.
Es un fallo clásico, conocido. Nada complicado. Solo hay que buscarlo dentro de una auditoría completa del sistema. Y aparece. Claro que aparece. El problema es que si se hacen cambios menores en la web, y se inyecta el bug por error humano una vez audiatada, hay que volver a auditar. Debería ser así. Pero a veces se cometen errores. Y ese bug sencillo se quedó en esa parte de la web.
¿Es que no tenemos pentesters en Telefónica? Tenemos CSIRT, Blue Team y Red Team que busca fallos constantemente. Tenemos equipos de auditores internos y externos que auditan los proyectos antes de ponerse en producción. Al igual que Apple, Microsoft o Google, pero los fallos aparecen por errores humanos. Como en todas las empresas. No hay más excusas. El fallo estaba, como muchos de los que detectan diariamente los miembros del Red Team de Telefónica.
¿Es que no tenéis Bug Bounty? Pues no es público, pero hasta eso tenemos. Con invitación privada con bolsa de trabajo, hay algunas empresas que hacen búsqueda de vulnerabilidades libremente por los sistemas de Telefónica. Pero no dieron con esa.
Alguno puede pensar que es que a lo mejor el Red Team es malo o las empresas que hacen el Bug Bounty, o las auditorías pre-producción no saben qué es un URL Manipulation. Pero la verdad es que no creemos que sea eso para nada, y como veréis un poco más adelante hicieron su parte en esta historia. Simplemente no habían mirado esa URL porque la cantidad de sistemas que tenemos en los países es altísima. Nuestra segunda plataforma y nuestra tercera plataforma son enormes.
Pero... sin excusas. Es un fallo nuestro que podemos subsanar para ver cómo evitamos esto en el futuro.
Sobre el reporte del bug a Telefónica
He de decir que he re-escrito esta parte varias veces porque si has leído hasta aquí todo el texto - y no en diagonal - sabrás más o menos mi opinión. Que se publique un post, un paper, se dé una conferencia o se monte el gran super-mega-pollo contra la empresa después de haberse subsanado el bug es algo normal.
Que se haga eso antes de que subsane el bug porque la empresa no ha sido capaz de arreglarlo teniendo los detalles también lo he visto.
Pero que se anuncie un bug en una empresa, se convoque una rueda de prensa y se le diga a la empresa que NO le va a dar los detalles hasta la rueda de prensa, es lo más kafkiano que he visto en mi vida como investigador de seguridad. Y actuar de esta forma defendiendo que es para ayudar a los clientes que se pueden ver afectados por ese bug es rizar el rizo de lo absurdo.
De hecho, deja clarísimo cuáles son los objetivos de los que han reportado el bug de esta manera, pero desde luego no era proteger a los usuarios.
Bajo mi entender, y como opinión personal, el objetivo de hacer algo así - si lo hiciera yo en alguno de mis reportes - sería solo hacer daño a la empresa, darse autobombo, y nunca preocuparse de los usuarios/clientes de ese sistema/empresa.
Es decir, lo último que le preocuparon fueron los clientes de Telefónica ya que, todos los que durante el tiempo que la vulnerabilidad fuera pública estarían expuestos a que cualquier malo explotase el bug.
Sobre el trabajo interno nuestro
No voy a desvelar todos los detalles del trabajo que seguimos internamente, pero sí que os quiero dar unos datos de lo que pasó el domingo pasado, para que seáis conscientes.
A las 20:20 del domingo pasado comunicaron con Telefónica para informarnos de que tenían datos de ese bug - que lo habían descubierto otras personas como vimos después en el análisis forense -, pero no quisieron dar detalles del bug. Deberíamos esperar a la rueda de prensa del lunes - a una hora antes para ser exactos - tal y coo se puede leer en el twit que ellos mismos han publicado.
Figura 11: A las 20:20 del domingo se nos dice que el lunes a las 09:00 o 10:00 (la rueda de prensa es a las 11:00)
El domingo lo que se nos dijo era que "podíamos esperar un día más", cuando el vídeo de la PoC es del jueves. Algo que para nosotros no era aceptable.
Por supuesto, a nosotros sí que nos importan nuestros clientes.
Yo me enteré en el avión camino de Las Vegas donde iba a participar en el evento de MicrosoftInspire con AURA y Movistar Home, y estuvimos evaluando si me volvía o no ese mismo día. De hecho, reservé billete de vuelta por si acaso no se había resuelto el bug para estar con mis compañeros.
El Red Team del equipo de Seguridad Interna de Telefónica, sin conocer los detalles del bug, hicieron una batida express por todos los sistemas que sospechó podían tener esos datos, y así localizar cualquier bug que pudiera permitir eso que habían anunciado.
A las 4:30 A.M. de la noche del domingo al lunes, el bug había sido descubierto y cerrado por los equipos de Seguridad y de IT de Telefónica de España. Una ventana de 8 horas que podría haberse reducido a minutos si nos hubieran dado los detalles del bug antes, pero al menos el equipo no permitió que la información pública pudiera permitir a nuevos malos hacer daño a nuestros clientes.
El resto ya lo sabéis. Cuando llegó la rueda de prensa el bug estaba resuelto a pesar de que parece que los que querían dar la rueda de prensa no querían eso. De hecho, si nosotros fuimos capaces de localizar el bug con poco detalle, con poco que hubieran contado en la rueda de prensa cualquier malo técnicamente bueno hubiera podido intentar averiguarlo por su cuenta compitiendo con nosotros con el mismo tiempo los dos.
Sobre cómo reportar un bug a Movistar
Somos conscientes de que tendremos bugs. Trabajamos, como ya os he dicho antes, para que el número sea cada vez menor, pero sobre todo para gestionar de forma resiliente el 100% de ellos. Sabemos que van a aparecer bugs que pueden descubrir los investigadores, y tenemos en las web información sobre cómo reportarlos.
De hecho, hubo mucha polémica, porque incluso llegaron a decir que no teníamos ninguna información de cómo hacerlo, cuando en la web pública de seguridad está la información, un formulario, y estamos más que contentos de que nos los reporten. Nos ayuda a hacer nuestro trabajo mejor.
Figura 13: La compañía sí tiene formularios con PGP para ello
Esto es importante, porque una de las justificaciones públicas que se dieron - totalmente falsas - es que Telefónica no tenía cómo reportar los bugs. Existe un formulario con claves PGP para hacerlo de forma segura.
Sobre los clientes afectados
Mucho se ha dicho en las redes de esto. Efectivamente el bug existía y si alguien lo hubiera explotado masivamente podría haber accedido a mucha información, pero no toda. Hubieran saltado otro tipo de sistemas de seguridad por profiling que no saltaron porque el acceso fue puntual. Es igual que si alguien hubiera explotado Spectre y Meltdown en los servidores de cualquier empresa del mundo se podría haber llevado todos los datos de la compañía. Se podrían.
A día de hoy, como estamos sujetos a GDPR, la legislación es muy clara. Nosotros hemos contactado con la Agencia de Protección de Datos y con los clientes afectados, que por suerte lo sabemos porque tenemos los logs de todos los accesos. Los legítimos, y los ilegítimos y delictivos.
Hay que tener en cuenta que igual de fácil es explotar el bug que detectar quién lo ha explotado. Al final se trata de cruzar los logs de acceso a las factura para ver qué persona ha accedido a una URL que no le correspondía. Y eso en el análisis forense ha salido rápido y fácil de ver, como os podéis imaginar.
No quiero desvelar los datos concretos porque esto está en investigación aún. Hay que tener en cuenta que de los alrededor de un centenar de cuentas afectadas - que ya han sido notificadas - la gran mayoría han sido accedidas por los investigadores (que utilizaron una cuenta legítima del sistema para autenticarse) y por los que reportaron a bombo y platillo el bug en una rueda de prensa.
Es decir, los datos que han sido filtrados - y estamos trabajando con la Agencia para que tenga todos los detalles- han sido accedidos por esas personas. Habrá que saber si utilizaron sus propias cuentas, o si alguien robo una identidad para hacer el acceso inicial y luego hacer el ataque de URL manipulation para ver los datos
Y por supuesto, hay que saber qué han hecho con los datos a los que accedieron. Pero eso será más adelante, cuando terminemos la investigación y comencemos el postmortem completo.
Conclusiones personales
Me hubiera gustado daros más datos antes, pero los equipos de seguridad interna debían hacer su trabajo. En esos momentos de tensión - y más como se ha cocinado este caso sin dar datos y con rueda de prensa por delante - los equipos necesitaban poner toda su atención en hacer su labor. Ya tuvieron bastante ruido con los twitteros desinformados, los lectores de titulares y los amantes del morbo rápido que les dieron caña por los lares de siempre.
Por supuesto, debemos seguir intentando que no aparezcan más bugs, ni como este, ni como ningún otro, pero lo más importante es que seguiremos trabajando para ser más resilientes, porque estoy seguro que aparecerán más bugs en el futuro. Tendremos que hacérselo más complicado aún a los malos. Es nuestro trabajo desde el día uno y seguirá siéndolo.
Por último, como investigador en seguridad que lleva veinte años en este mundo, creo justo conmigo mismo decir lo siguiente. Si crees en el full-disclosure es tu decisión y la respeto. No la comparto, pero es tu decisión y la tomas con todas sus consecuencias posibles - mediáticas y legales -. Pero lo que me parece un insulto a la inteligencia es que venga alguien haciendo full-disclosure y argumentando que es por el bien de los usuarios del sistema. Eso es creer que la gente no tiene capacidad de pensar, y me parece ridículo que alguien piense tan siquiera en - como dirían en mi barrio de Móstoles - vender esa moto.
Hace dos años, estando un día tranquilo y solitario en mi habitación leyendo las noticias en la web de los principales periódicos con los que me mantengo actualizado al día, me di cuenta de que me molaría tener una especie de periódico con noticias para hacer un browse manual e ir viendo las diferentes secciones. Y decidí crear "No Hack, No Fun".
Figura 1: 2 años de "No Hack, No Fun". Aún hack, aún Fun.
Fue el 17 de Julio de 2016 cuando os lo anuncié. Me había comprado la versión profesional de Paper.li y había empezado a publicar las noticias Al principio modificaba la misma edición diariamente, y después comencé a modificarla diariamente y rehacerla completamente una vez a la semana, que es lo que hago ahora mismo.
Figura 2: Primera edición de "No Hack, No Fun" del 15 de Julio de 2016
Yo me he enterado de que he hecho dos años porque he tenido que renovar mi suscripción un vez más, pero lo que más me ha llamado la atención es que ya es parte de mi rutina diaria. Sin darme cuenta he ido caminando con este mini-proyecto personal durante dos años, al que se han sumado casi 5.000 suscriptores de la newsletter y al que vienen a visitar diariamente miles de personas a ver qué hay en las secciones. Sigue habiendo hacks ergo sigue habiendo fun.
A veces, cuando voy en un tren, o en un avión en un viaje, me paro a pensar en las cosas que tengo que hacer. Normalmente, las cosas que tengo que hacer son acciones motivadas por las cosas que quiero hacer. Las metas que me he auto-impuesto. Los objetivos que me he marcado conseguir. Los lugares a dónde quiero llegar con un proyecto o una idea. Es algo que llevo haciendo años.
Figura 1: Motivación e Inspiración
Esta forma de hacer las cosas es la misma que llevo haciendo años. Creo que desde que aquel día llegué con las manos ensangrentadas por las esquirlas de ladrillo tosco que se me metían en los guantes cuando trabajé de albañil aquel verano. Cuando regresé aquel día me prometí que mis manos no volverían a estar ensangrentadas para ganarme la vida, ni mi cabeza encerrada en algo que no me permitiera hacer cosas.
Lo peor en aquel trabajo no era el calor, o el miedo a caerse al bajar una rampa de lo que sería en el futuro una escalera entre un cuarto y un quinto piso sin protección más que una cinta de aviso cargando puntales. Lo peor era tener la mente llena de ideas y no poder hacerlas. Lo sentí como una cárcel. La prisión donde metieron mi mente durante un tiempo.
Recuerdo que leía libros a la hora del bocadillo o la hora de la comida. Era mi forma de huir de allí. La forma de que mi mente no estuviera encarcelada en aquella obra de pisos del barrio de Tetuán en Madrid en la que estuve trabajando.
Con el paso de los años, he tenido muy claro que aquellas gotas de sangre, al igual que los "pitos" (dolor en los dedos por haberte lijado la piel de los dedos al golpear la lija contra un borde) que me salían en las manos de mis veranos de barnizador lijando cercos de puertas, o los dolores en mi espalda por cargar sacos de temple o botes de pintura plástica en mis años de pintor, me dieron una motivación extra para luchar por las cosas que quería hacer.
Pintar un piso, barnizar puertas, o poner paredes de ladrillo tosco no eran los objetivos que me había marcado en mi vida. Quería hacer muchas cosas, y no eran esas.
Hoy han pasado más de veinte años desde aquellos días. Después de esas aventuras en el mundo de la construcción, comencé a dar clases particulares con dieciocho años, y a sacar mis estudios adelante. Daba entre 4 y 8 horas de clases particulares todos los días y luego sacaba mis estudios. Esa fue mi rutina durante los tres años que estuve haciendo mi Ingeniería Técnica de Informática de Sistemas. Y eran tiempos geniales. Duros, intensos, y geniales.
Mis días se llenaban con las horas de clases, las horas de estudio, los ratos leyendo mientras sacaba a mi viejo perrito a la calle y nos sentábamos a disfrutar yo de la lectura y él del aire, y por último, el café con Rodol hablando de sueños. De hackers, de juegos, de tecnología, de programación, de modems, de Internet. Ayudar a los estudiantes que tenía en mis clases, la lectura de libros, los estudios de informática y los cafés con Rodol eran mi motivación para hacer cosas.
Fueron años maravillosos. Con horarios cronometrados al minuto, pero llenos de vida en mi cabeza. La cabeza que estaba libre para hacer cosas. Para crear cosas. Para planear sueños y compartirlos con Rodol. Él tenía los suyos, y compartirlos era motivador. "¿Te imaginas Rodol que un día hacemos...?"
E hicimos. Claro que hicimos. Hicimos muchas cosas. Y hacemos. Aún hacemos muchas cosas. Hicimos Informática 64, 0xWord, ElevenPaths, Aura, Movistar Home, libros, herramientas de hacking, estudios, papers, PoCs, Hacks, trabajamos con amigos, conocimos gente nueva, ampliamos nuestra vida, viajamos por el mundo - cada uno dónde quiso, que a él le gusta la aventura, y a mi por aventura me viene solo "¿habrá churros en el desayuno?".
Aún recuerdo el juramento que nos hicimos en la cafetería de la flecha, cuando diseñamos el logo de Informática 64 en una servilleta y él me dijo que nunca montaría una empresa, que era una locura. Nos prometimos que nos íbamos a divertir con lo que hiciéramos, y que sería para que en el fondo, pudiéramos tener una vida mejor que la que, por destino, nos había tocado.
Han pasado muchos años, veinte desde aquel juramento de amigos, cuando estábamos pensando en montar nuestra empresa. Hemos hecho muchas cosas juntos y separados. He visto más mundo del que soñaba. He conocido a más gente de la que imaginé. Volví a hacer todo lo que no pude hacer de joven. Acabar mi Ingeniería Superior de Informática, mi Máster y mi Doctorado, pero también sacarme el carné de moto, aprender inglés y transformar la vida de amigos y compañeros. Ira Defcon y BlackHat, hacerme un sitio en lo que me gustaba. Jugar con la tecnología y volver a jugar con ella.
Suelo decir muchas veces, que tengo la sensación de haber acabado varias vidas. La académica, la profesional, la familiar, la de pirata por los mares del sur navegando por el mundo y la de intelectual leído y aburrido. Ha ido a centenares de conciertos, y he volado miles de kilómetros para volver a lomos del Dragón Matías para recoger besos y abrazos pequeñitos.
Y aún, antes de irme a la cama una noche pienso: "¿Qué tengo que hacer mañana?". Y miro mi blog, y miro mi calendario, y anoto las nuevas ideas. Y llego el lunes a la oficina y me siento con Pablo González para repasar alguna nueva, y molesto a Antonio Vila que está desarrollando un sistema de seguridad para una red mundial con un nuevo Hack. Y me siento un minuto con Victor Mundilla para decirle que no me gusta el color de un interfaz y que la idea que me ha pasado nueva de Faast me mola cantidad, y busco a Igor o a Rodol, y les doy un abrazo porque después de veinte años están ahí, cerca de mí.
Y me levanto un sábado, como hoy, después de haber estado viajando una semana entera, con Jet Lag, pensando en qué voy a postear hoy en mi blog. Con qué os voy a intentar informar, entretener, enseñar, o simplemente qué voy a compartir con vosotros, que estás leyendo este artículo un día más. Algunos lleváis años leyendo ya este blog.
Al final, la motivación y la inspiración la tengo en lo que hago, no lo que he hecho. No se trata de llegar a ningún sitio. Yo ya sé cuál es el final del camino hace mucho tiempo. Se trata de lo que hago cada día. De cómo lo hago. De lo que me permite que mi mente esté libre. Que se cumpla aquel juramento que nos hicimos Rodol y yo. Y vosotros, sois parte de eso. Venir a este blog con regularidad es parte de mi motivación e inspiración para seguir disfrutando de lo que hago. Doy gracias por ello.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
