Una historia de hackers, bugs en aplicaciones y la web de Movistar

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.

Figura 2: Libro de Hacking Web Technologies

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

También en Microsoft hemos reportado muchos. Descubiertos por Faast, por la FOCA, o por pruebas manuales que hemos hecho contra estas empresas que son "Hackers Friendly". Os he contado muchas historias a lo lardo de estos años en mi blog. Aventuras con bugs fáciles de detectar y que generalmente son provocados por alguno de los motivos que he citado antes, como el bug del Open Proxy de Microsoft que también nos agradeció.

Figura 4: Reporte de Open Proxy a Microsoft.com

Por supuesto, también os he contado historias peores, como los bugs que afectan a software y a empresas derivados de nuevas técnicas. Como los bugs en los servidores que se vieron afectados cuando publiqué las técnicas de Connection String Parameter Pollution, los que se vieron afectados por Blind LDAP Injection, o incluso el famoso DirtyTooth que llevó a que Apple cambiara el funcionamiento de iOS. 

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.

Es por eso que emperesas como Google, con su Zero Project, cuando encuentra un bug en un software avisa a la empresa y le da 90 días para lo corrijan. Tanto si lo corrigen, como si no lo corrigen, Google publica el bug y toda la información, para evitar que los malos que pudieran conocer ese fallo sigan teniendo ventaja y, además, forzar a la empresa a que lo parchee con presión pública.

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.

Figura 8: Reporte de Raul Siles a SAP y time-line de publicación

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.

Figura 10: Noticia en "Una al día" sobre el bug

¿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 Microsoft Inspire 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.

Figura 12: Información para reportar un bug en el Centro de Seguridad de Movistar

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.

Saludos Malignos!