lunes, julio 23, 2018

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.
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ó.
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!

24 comentarios:

Josemaria dijo...

Telefónica no es una empresa "querida" en nuestro país. Imagino que ya lo sabías cuando fichaste por ella. Ese abuso de posición dominante y de chanchullos políticos en su directiva durante tantos años (y, ejem, aún ahora...) sigue pasando factura a su imagen. Igual que siempre has sabido que Microsoft tampoco es una empresa querida y has elegido posicionarte apostado por ella. Ahora viéndolo con distancia se ve que es una constante en tu trayectoria :-) Independientemente de eso, estoy de acuerdo contigo en que se trata de un error lamentable e inexcusable por parte de los equipos de seguridad de telefónica pero también por parte de quienes reportan ese bug. Fail-Fail para ambos ;-) Ánimo y a seguir peleando Chema.

Chema Alonso dijo...

@Josemaría, no voy a entrar a debatir todas las generalidades que dices sobre Telefónica o Microsoft, que los que argumentan sin dar datos concretos nunca me han gustado. Hacer totum revolutum en un comentario es la forma más sencilla de hacer FUD. Hablas de los 127.000 empleados directos de Telefónica que estamos luchando todos los días con mucha frugalidad y no me gusta.

En cuanto al fallo, que es de lo que trata este artículo, creo que he sido claro, detallista y no he escatimado un minuto de tiempo en explicar todo lo que puedo contar hasta el momento. Si tu visión es que es 50% para seguridad y 50% para los que lo han reportado, es que, o no me he explicado bien, o no lo has leído correctamente.

Los bugs existen y existirán. Los que inyectan el bug no son los de seguridad, son los del sistema en sí. Los de seguridad tienen la misión de detectar los más posibles y de gestionar el 100% de los que se detecten, y ahí lo han bordado.

Lo otro... creo que he sido suficientemente claro en el post. Si yo doy una rueda de prensa de cada XSS, SQLi, RCE, BLDAPi que reporto no me da la vida.

Saludos!

Josemaria dijo...

No entiendo esa agresividad Chema. No hablo de generalidades. Hablo de una impresión sobre ambas empresas que, me atrevería a decir es casi estadísticamente demostrable y que estoy seguro, conoces de sobra. Ni siquiera juzgo que sea fundamentada. Digo que existe. Punto. Y si no quieres verla es que miras para otro lado. En cuanto a ese reparto de culpas del que hablas tampoco refleja para nada lo que quería decir. Digo (y tu reconoces) que ha sido un fallo por parte de los equipos que auditan la seguridad en vuestros sitios. Justificable o no, pero ha sido un fallo. Y también digo que estoy de acuerdo contigo en que no ha sido una forma correcta de actuar por parte de la gente que ha reportado el bug. En ningún caso me meto en quien la ha metido mas gorda. Un poco de tranquilidad, por favor, que es lunes y muy temprano.

Josemaria dijo...

Por cierto: conozco Telefónica desde dentro. Creo que ya te lo he dicho alguna vez. Estuve tres años trabajando en OSI. Tenían un personal de sistemas maravilloso. Aprendí mucho con ellos... Pero, sin embargo, un desprecio casi absoluto por la seguridad. Eran otros tiempos (alrededor del año 2000) pero te puedo contar anécdotas absolutamente escalofriantes de aquellos tiempos. Y lo digo realmente en serio. Imagino que el hecho de que vosotros esteis ahí ahora indica que las cosas han cambiado mucho. O eso espero.

Raul dijo...

Lo que no me parece bien es que se anuncie en un comunicado a bombo y platillo que se han comprobado los datos y no ha habido fuga de datos cuando como mínimo los que encontraron el bug y los de facua habían accedido a datos de las personas.

Por otra parte es lo que siempre pienso, que en España no hay buenos programadores y los pocos que he conocido han emigrado al extranjero. Se sigue programando como si fueran unas prácticas de primero de carrera y entre esto y el anterior fallo de no actualizar a los últimos parches de Windows y luego oigo al ciso de Telefónica echar las culpas de eso a la falta de formación de los propios trabajadores

Josemaria dijo...

@Raul: el problema es el de siempre. Externalización y reducción de costes. Repito que hablo de hace años, pero en torno al 2000 toda la parte de facturación de telefónica estaba subcontratada "al mejor postor" con una rotación tremenda en los equipos debido a los sueldos de penuria y las lamentables condiciones de trabajo. Repito también que espero que desde entonces las cosas hayan cambiado, pero en aquellas circunstancias considero que es muy difícil construir sistemas que cumplan unos mínimos.

AlvariCoke dijo...

@Josemaria , han pasado 18 años de aquello , igual lo inteligente antes de postear es hacer un apt-get update o un sleep() hasta tener datos reales. Saludos

blackwall dijo...

Pues sinceramente, siendo la empresa que es, con los recursos que tiene, intentar excusar un fallo de seguridad es simplemente, ridículo. Creo que en este tipo de empresas, digamos el TOP 10 mundial, o TOP 20, o 50 me da igual, la única respuesta válida es que alguien asuma su responsabilidad y salga por donde tenga que salir.

Como has dicho Chema, el que descubre un "bug", yo lo llamo brecha de datos en este caso, es libre de elegir cómo, cuándo y dónde lo hace público. Si esa acción que toma tiene consecuencias legales, ya se verá donde se tenga que ver, pero en ningún caso son los culpables de todo este embrollo. ¿Qué pensarías si hoy, dentro de esas empresas del TOP 50 mundial se conociera otra brecha de información? ¿No estarías asustado por lo que haya podido pasar con tus datos? Seguro que no querrías explicaciones, sino soluciones y respuestas proporcionadas a la gravedad del asunto.

Héctor dijo...

Esto no va de empresas queridas, desqueridas, amadas u odiadas. Los gustos, filias, fobias o paranoias detrás de un reporte de seguridad son irrelevantes. Esto va de responsabilidad o de irresponsabilidad. Y en este caso, por lo que leo, va de una irresponsabilidad como pocas veces he visto en mi vida profesional.

Esperar a una rueda de prensa para comunicar casi simultáneamente a la empresa afectada y al público la existencia de una vulnerabilidad que afecta a datos de ciudadanos es simplemente irresponsable, imprudente, insensato …. Y si me apuro, hasta infantil. ¿Qué preocupación real tenía el denunciante por la privacidad (derecho fundamental) de los usuarios de Telefónica, ciudadanos corrientes y molientes, en el momento de decidir sobre que hacer con esa información?
El equilibrio entre el “Medal Management vs Responsible Disclosure” es un clásico en el mundo de la seguridad, y tenemos la historia llena de encuentros y desencuentros al respecto (los más sonados últimamente los relacionados con Google y Microsoft al respecto de vulnerabilidades en Chrome y Edge). Pero en todos ellos, JAMAS se ha expuesto como en este caso de forma tan cruda el desprecio por la seguridad del potencial afectado (lease, usuario, ciudadano, consumidor etc..). La discusión se centraba en opinar sobre si el tiempo dado para resolver un problema era suficiente o no para haberlo corregido antes de su publicación. Hablamos de semanas, meses…. Pero en este caso ….¿¿¿Horas???? y en una Rueda de Prensa???
Afortunadamente para sus usuarios, Telefónica ha encontrado la forma de responder de forma rápida y corregir en horas el problema.
¿Qué hubiera pasado si el problema hubiera sido más complejo, con incidencias en otros sistemas o servicios y el problema hubiera tardado en resolverse digamos…. ¿Un mes? ¿Un mes con todos los datos de los clientes de Movistar expuestos de forma irremediable? ¿No se habría convertido el denunciante en parte fundamental del problema a cambio de un minuto de “gloria”?
En Resumen, y para la próxima. No se trata de ocultar vulnerabilidades encontradas en el mundo de la seguridad. Todo lo contrario. La seguridad por ocultación simplemente no es seguridad. Se trata de reportarlas en la forma y tiempo adecuado para minimizar el riesgo al que se expone a los usuarios potencialmente afectados. Pero no por ello “renunciar” al reconocimiento del esfuerzo y mérito de haber identificado esa vulnerabilidad. En absoluto. Pero eso ha de producirse, y de hecho afortunadamente es así en la inmensa mayoría de los casos, una vez resuelto el problema y protegido a los usuarios. Otra cosa es un lamentable desequilibrio en la gestión de la medalla.

eneas dijo...

¿Y con este bug no tendrá que ver que en Telefónica hay "becarios" y "becarios senior"? Yo ahora mismo hace tiempo que no trabajo para Telefónica, pero he trabajado para Telefónica hace bastante y mientras estuve allí descubrimos (en pruebas, donde se tienen que descubrir estas cosas, por cierto) exactamente lo mismo; un tipo ponía el id de la factura en una petición GET, ahí, golosa para la vista, y sacaba la factura que hubiera en el parámetro del GET sin validar nada más. Es que pedía a gritos cambiarlo a ver que pasaba. Yo fui muy educado y dije que eso se podría mejorar, pero otro con menos tacto dijo que el fulano no sabía programar. ¿La solución final por las fechas y tal? Pues se pone en formulario en POST y así al menos hay que saber algo para sacar facturas que no sean tuyas porque no canta en la barra de direcciones. Quiero pensar que la solución esta vez no ha sido pasarlo a POST...

Pero el problema de fondo es que mesa de compras racanea, paga poco y por eso las consultoras os mandan becarios. Y RRHH contrata becarios que además piensan que saben mucho más de lo que creen porque, bueno, son de Telefónica.

Hacer las cosas bien tiene un coste. Normalmente no se nota cuando se hace con los pies, pero esta vez ha cantado. Y tú te enfadas con el que ha dado la noticia. Enfádate mejor con los que piensan que es igual que las cosas las haga un "recurso" o las haga otro "recurso".

Chris dijo...

Trabajo para una empresa americana que perfectamente puede competir con Telefónica. Tenemos un bug bounty publico, el propio equipo de seguridad revisa el codigo que maneja PII (Personal Identificable Information). Lo siento, pero no te compro que en todas las empresas estas cosas pasan. Como mínimo, la persona responsable de esto debería haber dimitido.

Fallo de QA? Acaso solo hay un equipo de QA? No se hacen revisiones de código entre companeros, entre departamentos?

El fallo fue en vuestra pagina web PRINCIPAL! Manejando información crítica (direcciones, DNIs, nombres, numeros de cuenta, etc). Eso no es un pequeño fallito.

Si, pequeños fallos de seguridad pueden ocurrir (invalidar sesiones que no son tuyas, bloquear cuentas por contraseñas incorrectas, CSFR mal manejados) pero no dejar al descubierto la factura de cualquier cliente que contiene TODA su información personal. Eso es una cagada en toda regla.

Si, en mi empresa se hacen postmortems, utilizamos tecnicismos como los que tú escribes, pero ante todo, intentamos hacer un buen trabajo y reconocer nuestras cagadas.

En mi empresa, un sistema que da acceso a información tan tonta como un apellido, se revisa el código 100 veces, se hacen pentest internos y despues se vuelve hacer lo mismo, se utilizan auditores externos, y cuando finalmente se está satisfecho, se pasa el código a producción. Si alguien ańade un simple print a ese código, la auditoría comienza de nuevo.

Un sistema que da acceso a facturas es CRITICO. Un bug por modificación de URL demuestra una falta de rigor técnico que asusta.

Hace cosa de 2 ańos reporte un bug en un portal de RIMA (Telefónica) que usando el usuario y contraseña DEMO/DEMO daba acceso a algunas gráficas de peering de algunos clientes nacionales.
Tardasteis 4 meses en responder a mi correo y solucionarlo.

Lo siento, pero no te compro que “estas cosas pasan”.

Como he mencionado más arriba, pequeños fallos de seguridad que no exponen la información de todos sus clientes, ocurren en muchas empresas, pero no cosas como esta, o por lo menos, en empresas de este calibre.

Pones como ejemplo a Google, perfecto. Esta fue de las mayores cagadas y el mayor bug bounty pagado hasta la fecha.

https://www.google.co.uk/amp/s/www.bizjournals.com/sanjose/news/2018/01/22/google-bug-bounty-android-guang-gong-goog.amp.html

Si te lees el CVE, veras como únicamente si se alinean los astros, tal vez, remotamente, se consiga acceso a una parte de Android.

Google maneja los datos de billones de personas. Microsoft los datos de cientos de millones de personas. Hasta la fechas, no he escuchado que han tenido un problema de seguridad exponiendo toda la información de TODOS sus clientes modificando una estupida URL.

Hablemos con propiedad.

Ramón Sola dijo...

Bonita forma de escurrir el bulto, Chema: matar al mensajero. Tanta parrafada inútil para excusar algo que no tiene excusa.

Iván Ruiz dijo...

Buenas ! Quisiera dar mi punto de vista. Soy software engineer, y no he trabajado en telefónica, pero si he trabajaro en un par de las principales compañias del mundo de la tecnología

Pensar que un producto tecnologico, hecho por la empresa que sea y con los recursos que se quiera, no va a tener fallos , bugs, brechas de seguridad ... etc es simplemente idiota. Probablemente los que lo pensais no habeis escrito nada minimamente complejo.

acerswap dijo...

Yo estoy completamente en contra de la politica de Full disclosure. Hacer publica una vulnerabilidad es ponerselo facil a los atacantes, y eso no debe hacerse nunca. Pone en peligro a los usuarios cuando aun no está reparado el fallo y pone en peligro tambien a aquellos que no pueden subsanarlo instalando parches (como por ejemplo los usuarios corporativos o con sistemas antiguos). Una vulnerabilidad solo debe ser conocida, idealmente, por los encargados de resolverla y el que la descubrio. Toda divulgacion publica es dañar a los usuarios.

Unknown dijo...

Si, hay bugs, pero no de este calibre. Nadie esta diciendo que no haya bugs. Lo que la gente está diciendo es que este bug es de manual de como no hacer las cosas.

Unknown dijo...

Estoy de acuerdo en eso, pero no en la forma de escurrir el bulto.

D dijo...

Cuanto cobra el becario que arregló el bug y cuanto cobras tu por hacer solo bla-bla?

crixto dijo...

Me alegra leer un comentario realista sobre algo tan grave como la exposición de datos de clientes de la manera más tonta posible.... esta entrada de puro bla-bla-bla es solo para escurrir el bulro mientras don gorrito andsnñor las vegas jajajaja encima diciendo si pensando en volver para “trabajar” con sis compañeros jajajajaja es de risa...

emilitingo dijo...

Pobre persona...eso de tirar mierda al otro para que la tuya huela menos...NO AYUDA

NetVicious dijo...

Opino lo mismo que tú sobre full-disclosure, pero los de Facua están calentitos desde hace tiempo con Telefónica por un burofax un poco intimidante que recibieron hace ya tiempo [1], e imagino que querían pegar fuerte esta vez, aprovechando las nuevas leyes de GDPR para que le cayera una multa gorda a Telefónica.


[1] https://www.elconfidencial.com/tecnologia/2015-11-11/guerra-entre-telefonica-y-facua-por-la-subida-en-las-tarifas-de-movistar-fusion_1091436/

Unknown dijo...

Ramz

David dijo...

Vamos a ver, a los que dicen que Chema está escurriendo el bulto es porque sois de aquellos twitteros que habláis de Seguridad y jamás habéis pisado una empresa en vuestra vida, ni sabéis como se gestiona la seguridad, añadamos a esto, que no habéis leído el articulo completo, de hecho, ni siquiera lo leísteis como para hablar

Un articulo así de completo nadie lo hace, y más detallando las vulnerabilidades de forma frontal! Yo también he reportado múltiples vulnerabilidades y he detallado, como no podría ser de otra manera, las mismas a los implicados en cada caso, obviamente, mi criterio es que si no lo corriges en 2 semanas, vas al paredón publico, pero ojo! tienen todos los detalles posibles y pueden preguntarme de forma abierta sobre las vulnerabilidades o contratarme para cerrarlas durante esas 2 semanas previas al disclosure, todo vale!

Ahora bien, en este caso es claro que el que descubrió la vulnerabilidad quería aprovecharse de la situación, y en un hecho sin precedentes, sin ética, sin moral y sin escrúpulos, no reporto de forma clara la vulnerabilidad y SI quería que todos la explotaran! Si, Telefónica se hubiese perjudicado, pero aún más los usuarios, que son los que más importan en todo este rollo!

Gonzaluskax dijo...

@Josemaría la externalización en Telefonica/Movistar sigue siendo la misma o más, nada ha cambiado, yo trabaje en el centro de datos de Julian Camarillo de Telefónica y desde hace 10 años he pasado por varias empresas subcontratadas, en cada una reducción de sueldo, yo cuando no entre en la última (multinacional de la India por cierto) me ofrecían 10000 euros anuales de sueldo y llegue a cobrar 15000 en mis inicios y los que estuvieron antes de que entrase yo cobraban más, últimamente metian a cualquiera, rotación tremenda como tu dices, he visto entrar gente de la que no les fiarias ni un euro, auditores pasar por alto fallos escalofriantes en sus auditorías al centro de datos (decíamos los empleados de broma que les pagarían servicios de señoritas de compañia a cambio de tales omisiones), pésimo control de seguridad (los de seguridad también cada vez peor) y asi con todos los departamentos que habia alli en el edificio de Julian Camarillo y otros (Distrito C y Alcalá de Henares) menos jefazos es todo subcontratado y becarios, ay aun me acuerdo de los amigos que curraban igual de mal subcontratados como yo en Telefonica Moviles.

Unknown dijo...

Veo tanta gente con conocimientos enormes a cerca de estos temas que están profundamente escudriñados y mi punto de vista es el siguiente

.


Gracias por su atención.
Sigan en lo suyo amos de la tecnología.

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares