Buenas y malas noticias sobre Cloudbleed

El viernes 17 de febrero el investigador de Google Tavis Ormandy realizaba una publicación en su cuenta de Twitter indicando la necesidad urgente de contactar con algún responsable de seguridad de la compañía Cloudflare. Tras ello, se inició una contrarreloj para intentar solventar un problema de seguridad a nivel mundial que podría estar permitiendo que la información privada de millones de direcciones web que tuviesen contratado este servicio estuviera siendo publicada en internet, llegando incluso a ser indexada por diferentes motores de búsqueda existentes. Dada la magnitud del incidente y el número de dominios potencialmente afectados fue apodado como «CloudBleed» mimetizando el nombre elegido para el incidente de SSL de 2014 denominado Hearthbleed.

¿Quién es CloudFlare y a qué se dedica?

CloudFlare se describe en su portfolio de servicios como un proveedor enfocado en mejorar las páginas web de sus clientes desde el punto de vista del rendimiento, la seguridad y la fiabilidad. Creada en 2009, la compañía estadounidense tiene actualmente un valor de mercado superior a los mil millones de dólares dando servicio a más de cinco millones de clientes, los cuales podrían estar potencialmente afectados por este incidente.

¿Cómo, cuándo y por qué?

La raíz del problema fue, según han publicado en su blog oficial, un cúmulo de sucesos que terminaron desencadenando un desbordamiento de buffer en un número aún indeterminado de peticiones a su servicio. Debido a este hecho, fueron publicados datos privados no cuantificados que van desde cookies HTTP, hasta cuerpos de peticiones POST (donde se podrían llegar a ver expuestas las contraseñas o tokens de autenticación) entre otros datos, con la particularidad añadida de que parte de ellos además pudieron ser capturados por los principales motores de búsqueda existentes.

Uno de los procesos responsable del desbordamiento fue un procedimiento encargado de parsear los ficheros HTML de las páginas web de sus clientes. Estas funciones desarrolladas por la compañía son necesarias para poder dotar a sus usuarios de una capa de seguridad extra como la reescritura de páginas HTTP a HTTPS o la ofuscación de correos electrónicos, así como el ofrecimiento de distintas mejoras desde el punto de vista estadístico mediante la inserción de etiquetas de Google Analytics.

Aunque estos parseadores estaban funcionando desde hace años, el problema se habría desencadenado a partir del 22 de septiembre de 2016, cuando a raíz de una actualización de la tecnología utilizada por su parser, fue habilitado de manera automática un nuevo módulo de reescritura del código HTTP. Según describen en el blog, este fallo de desbordamiento no estaría afectando a la totalidad de sus clientes, sino que también debía estar condicionado por un fallo de programación en las páginas web, ya que para que los ficheros no fueran procesados correctamente y los punteros accedieran a posiciones de memoria no deseadas era necesario que las etiquetas del código HTML estuvieran mal construidas. Según las estadísticas reportadas por la compañía esta casuística ocurrió en el 0,06% de las páginas web.

Impacto y alcance del incidente

Para poder entender un poco el alcance real del problema, Cloudflare realizó una publicación adicional el 1 de marzo donde muestra una evolución de cómo se fue desarrollando el incidente, separado en dos periodos de tiempo delimitados.

• Desde el 22 de septiembre de 2016 hasta el 13 de febrero de 2017 únicamente se habrían visto afectados 180 sitios y las cifras oficiales estiman que el fallo se desencadenó 605 037 veces. 
• Desde el 13 de febrero al 18 de febrero de 2017 el número de sitios afectados habría ascendido hasta los 6457 lo que provocó la ejecución del fallo otras 637 034 ocasiones, más que en los cuatro meses y medio anteriores.

En el momento de mayor exposición, el fallo se habría llegado a disparar en 1 de cada 3,3 millones de peticiones es decir en un 0,00003% de las solicitudes. Según sus estimaciones, el número total de veces que pudo ser ejecutado el fallo ascendería a 1 242 071, aunque las estimaciones hablan de que aproximadamente el 50% de ellas habrían sido realizadas por los propios crawlers de los principales motores de búsqueda. De esta descripción se infiere que las direcciones web que tuvieran un mayor número de consultas o que fueran más populares se podrían haber visto afectadas con más facilidad.

Pese a ello, el problema aún persiste en algunas páginas dedicadas a la captura de direcciones web para la creación de bibliotecas digitales, ya que como se observa en esta captura de archive.fo, la información expuesta por CloudFlare estaría todavía disponible para ser consultada por cualquier usuario de internet.

Ilustración 1. Captura de pantalla de una cabecera de Cloudflare insertada en una web afectada por el incidente de «CloudBleed».

¿Como podría ser utilizado?

Pero, ¿cómo podría haber sido utilizado por un atacante que conociera esta vulnerabilidad desde septiembre de 2016? Su explotación es compleja, ya que la opción más viable sería la de realizar un número muy elevado de peticiones para intentar que se produjera el desbordamiento el mayor número de veces posible. Esta posibilidad fue barajada por el equipo de Cloudflare y procedieron al análisis de diversos patrones de comportamiento para la detección de tráfico inusual, así como la reproducción del incidente en sus laboratorios donde a priori no existen evidencias de que el fallo haya sido explotado por parte de terceros actores.

Conclusiones

La problemática existente en este tipo de incidentes es compleja, ya que la compañía ha intentado obrar de una forma transparente informando acerca de lo ocurrido facilitando información como tiempos de respuesta calculados al minuto. La estrecha colaboración mantenida con los principales motores de búsqueda para la eliminación de las más de 80 000 páginas con información de Cloudflare cacheada en sus direcciones ha sido fundamental para poder mitigar las consecuencias del incidente cuanto antes poniendo sobre la mesa la importancia de la colaboración entre distintos organismos cuando tienen lugar este tipo de incidentes.

Algunas plataformas que hacían uso de los servicios de Cloudflare se apresuraron a notificar a sus usuarios tan pronto como tuvieron conocimiento del incidente y, como medida preventiva, recomendaron el cambio de tokens de autenticación y contraseñas de forma inmediata. Nuevamente, se pone de manifiesto las dificultades que entraña la delimitación del perímetro tecnológico de una organización cuando este implica a proveedores de terceras compañías. En este caso, tenemos que considerar la realidad de las dificultades que existen a la hora de cuantificar la cantidad de información que se puede haber visto afectada, por lo que, aunque las posibilidades sean remotas, nunca está de más ser especialmente precavidos. Si está de tocar la lotería, que no sea esta.