La anécdota
Hace unos meses me puse en contacto con mi ISP para comentarles un pequeño fallo en su infraestructura que me afectaba personalmente, nada, poca cosa, sólo permitía que cualquier persona desde el exterior pudiera acceder remotamente a mi router a pesar de estar el acceso deshabilitado.El problema con estas cosas es: cuando entiendes el fallo y ves hasta dónde llega el problema, ¿cómo lo comunicas?¿con quién te pones en contacto? no existe una cultura ni un mecanismo aquí que permita llegado este caso hacer lo que se llama un "responsible disclosure" (término muy de moda esta semana por otros motivos que volveré a tocar más adelante), es decir una forma de poder avisar del fallo sin causar un perjuicio a la gente involucrada, algo que realmente no suele interesar, al menos a mi.
Así que empecé el calvario de la comunicación por la vía menos recomendada: el teléfono.
Por algún motivo pensé que las empresas en general tendrían alguna opción en los infinitos números de opciones de sus centralitas que fuera "quiero hablar con vosotros, y no, no es para compraros ni para venderos nada", pero obviamente estaba equivocado y acabé en algún nivel de soporte técnico en donde la chica de helpdesk y yo hablábamos un idioma similar.
Y esta es la anécdota que quería encontrar, cuando le conté el problemón que me afectaba a mi y a otras 30mil personas aproximadamente (gracias Shodan!) la chica de soporte me dijo algo así como:
- Pues no es un problema tan grande, porque nuestros clientes tienen IP dinámica, por lo que si alguien quiere controlar tu router cuando vaya a hacerlo seguramente tu ya tendrás una IP nueva y se esté conectando a otro sitio.
Bienvenidos a la seguridad probabilística
Desde entonces acuñé un nuevo término que utilizo con colegas de profesión, la seguridad de casualidad o seguridad probabilística, que viene a ser cuando tu seguridad se basa en la esperanza de que cuando un posible atacante vaya a realizar un ataque sobre tus sistemas suceda algún hecho inesperado que con más o menos probabilidad frustre el intento del atacante, dejándolo en la estacada.
Es un concepto genial, me gusta.
Y con esto llegamos a lo que de verdad quería contar en el post, que en realidad es sobre Heartbleed. Si si, el fallo ese del corazón sangrando del que se lleva hablando toda la semana, pero he hecho una maniobra de distracción para parecer más novedoso y que así la gente no me vote cansino, bueno, y porque es mi blog, que carai, y me gusta contar estas cosas así.
A estas alturas no voy a explicar lo que es Heartbleed, hay explicaciones estupendas que se pueden consultar, y yo no voy a hacer que entiendas el bug mejor que la tira de XKCD
Tampoco voy a entrar en el mundo de las conspiranoias de que si salió el mismo día del fin de soporte a Windows XP y hay un ex-empleado de Microsoft detrás del sitio web del disclosure, que por cierto no ha sido demasiado responsable.
El tema que quiero tratar es: ¿cuáles han sido las consecuencias de verdad de este bug?
Pues básicamente han sido las siguientes:
- Un número indeterminado de sitios web, algunos de ellos con un gran número de usuarios, han dejado ver datos importantes sobre sus clientes.
- Como consecuencia de esto, un número indeterminado de credenciales han sido filtradas
- Las claves privadas de un número indeterminado de servidores seguros pueden haber sido filtradas (la prueba realizada por cloudflare esta semana, demuestra que esto ha podido ser así en muy poco tiempo)
- Como consecuencia de esto, las capturas de tráfico de estos sitios seguros, presentes y pasadas, han dejado de ser seguras y se han podido descifrar completamente
- En el caso de los sitios que no han revocado y renovado el certificado (muchísimos aún a día de hoy), con su certificado robado puede haber gente haciendo el MitM perfecto, es decir, interceptando comunicaciones supuestamente seguras.
- Existen otras aplicaciones (aún no se sabe cuáles exactamente) y clientes (más de lo mismo) que también están afectadas, con consecuencias impredecibles aunque normalmente algo menos graves.
Y básicamente "sólo" es eso.
¿Por qué hay tantas cosas en el aire? pues porque básicamente no se sabe nada con seguridad, porque aunque existen pruebas que aplicándolas sobre logs de IDS recogidos con anterioridad pueden detectar el fallo, aunque con algún falso positivo, lo que no se va a poder recuperar son los datos que el servidor le envió a los atacantes.
Los datos del número de servidores, que han sido objeto de polémica estos días, también son totalmente estimados, sea cual sea el método que se use para recabar la información.
Unos han usado netcraft, otros zmap, shodan, o una combinación de todo eso, pero los datos siguen siendo estimaciones basadas en los banners que usan los servidores, sin tener en cuenta que el banner puede mentir, o puede haber un proxy en medio que se ocupe de la negociación SSL (es decir, es perfectamente posible que un sitio web alojado en un IIS se vea afectado por usa nginx como proxy inverso), ni han tenido en cuenta el resto de software y appliances que usan la librería.
Pero mi reflexión va un poco más allá, porque realmente los temas de números no me importan demasiado
Voy a hacer una suposición, supongamos que solo tres servidores han sido afectados (que lo han sido): google, facebook y yahoo.
Supongamos también que el bug solo se ha podido usar unas horas (yo lo he podido usar más de un día antes de ver sitios enormes parcheados, pero bueno, supongamos), vamos a poner que se ha podido usar 8 horas, y que solo un grupo reducido de personas ha tenido acceso a el, que tampoco ha sido el caso.
Alguien me podría decir suponiendo todo eso, ¿cual es la probabilidad de que mis usuarios en esos tres servicios hayan sido afectados? ¿el certificado SSL ha sido comprometido? durante ese tiempo ¿he podido ser víctima de un MiTM con ese certificado robado?, si alguien tenía una captura de mi tráfico cifrado ¿ha podido descifrarlo con ese certificado robado?
¿Importa esta probabilidad?
¿Importa esta probabilidad?
En INTECO hoy, por ejemplo, nos invitan a reflexionar sobre la severidad del bug, con cosas como esta:
A partir del revuelo generado, la preocupación del usuario por el alcance de la vulnerabilidad y cómo podría afectar a su privacidad el riesgo de alguien haya podido capturar sus contraseñas en alguno de los sitios web afectados también requiere cierta reflexión.
Para ello, un aspecto importante a tener en cuenta sobre el grado de exposición de las contraseñas es la ventana temporal del fallo. Es decir (dejando al margen agencias de inteligencia con supuesta información privilegiada o similar), las contraseñas sólo han estado expuestas a posibles ciberdelicuentes desde el 7 de Abril.
Es decir, supuestamente nadie ha tenido acceso al fallo (o si), y "sólo" han estado expuestas desde el 7 de abril, apenas unas horas (o no, o unos días)
Más, @gallir, el de menéame, subia a portada una noticia con la teoría de la conspiración microsoft y nos dejaba comentarios como este o este diciendo que no era tan automático pillar claves privadas, solo hay que conocer algo sobre gestión de memoria para saber eso
(y yo lo había dicho antes, twitter.com/gallir/statuses/453879009794080769, sin haberlo analizado, pero es conocimiento básico de cómo funciona la gestión de memoria en los sistemas operativos modernos).Horas después Cloudflare publicaba este reto con una página afectada por heartbleed y horas después dos personas la sacaban, demostrando lo difícil que era
Resumen, todo el mundo se apunta rápido al carro de los números y afirmaciones exageradas, pero muy pocos saben el fondo, o se documentan.
A estas horas ese sitio ya no funciona porque han revocado el certificado del servidor (je je, tiene gracia, y que el certificado sea de COMODO, más)
Así que nada, exactamente no se a que viene esta tendencia de reducirlo todo a números y llamar a la calma-pasividad por la probabilidad supuestamente de que haya pasado algo, pero ¿y si ha pasado?, tampoco entiendo que se hable de "solo X servidores" cuando solo uno de ellos tiene las credenciales de 800 millones de usuarios, solo con que yahoo hubiera sido el único afectado, esto seguiría siendo gravísimo.
Total, que esto debe ser la nueva tendencia, es lo que se llama apostar por la seguridad, es decir, pasen señores y hagan sus apuestas a ver si sus datos están afectados o no en este nuevo bug basándonos en estas nuevas estadísticas que tenemos por aquí fresquitas, bienvenidos a la seguridad probabilística.
No hay comentarios:
Publicar un comentario