De nuevo nos encontramos ante una vulnerabilidad mediática que tiene nombre propio, y cuya repercusión podría haber sido muy elevada si no fuera porque la comunicación del fallo se hizo de forma responsable y la empresa afectada solucionó con rapidez el problema. CloudBleed es, de lo poco que llevamos de 2017, una de las vulnerabilidades que más impacto podría haber tenido en los datos confidenciales de los usuarios que acceden a alguno de los muchos sitios que confían en los servicios que proporciona Cloudflare. Vamos a ver por qué.
¿En qué consiste Cloudbleed?
Cloudbleed es la vulnerabilidad descubierta recientemente por el investigador Tavis Ormandy, que forma parte del equipo de Google Project Zero. El 18 de febrero se puso en contacto con responsables de la empresa Cloudflare, un conocido CDN, para informarles de una vulnerabilidad que permitiría robar información confidencial de aquellas webs que se alojan en este servicio.
En el fallo reportado por Ormandy se hablaba de un fallo del tipo buffer overflow en los servidores de Cloudflare que permitiría a un atacante recuperar porciones de memoria que contenían datos privados, entre los que podemos encontrar tokens de autenticación y cookies HTTP, entre otros. Esto permitiría a un atacante suplantar la sesión de otros usuarios y acceder a ciertas webs haciéndose pasar por otra persona y así obtener información confidencial.
Para quien no lo sepa, Cloudflare realiza una función de proxy entre el usuario y la web a la que intenta acceder, almacenando en sus propios servidores una copia de las webs que aloja. El principal beneficio que obtienen las webs que utilizan este tipo de servicios es la reducción en la carga de peticiones de conexión, algo que funciona muy bien contra ataques de denegación de servicio distribuido o DDoS.
Un símbolo equivocado que podría haber hecho mucho daño
Lo curioso de todo este caso es que, tras revisar el exhaustivo informe realizado por la empresa afectada, todo parece apuntar a que el fallo estuvo provocado por la utilización de un símbolo equivocado en el componente Cloudflare HTML Parser. Este módulo es utilizado por este servicio para leer el código fuente de la web alojada y luego procede a reescribir este contenido basándose en las preferencias indicadas por el usuario.
Entonces, ¿cuál era el símbolo que ha causado todo este revuelo? Simplemente el uso de “>=” en lugar de “==” provocaba un buffer overflow en el parser HTML que terminaba por volcar el contenido de la memoria del servidor de Cloudflare afectado en las peticiones HTTP del cliente.
Hay que decir que esto no se producía en todos los casos, ya que, para darse esa situación, los usuarios del servicio Cloudflare debían tener activadas dos opciones en su configuración, de nombre Ofuscación de email y Reescritura automática de HTTPs.
Cronología e impacto de esta vulnerabilidad
Si hay algo que preocupa cuando se descubre un fallo de este tipo es durante cuánto tiempo ha podido ser aprovechada por usuarios con malas intenciones. En este caso, y tras repasar la investigación interna realizada por la propia Cloudflare, se ha sabido que el error en la introducción del símbolo equivocado se produjo el pasado 22 de septiembre de 2016, mientras que la fecha en la que la empresa fue informada de este fue el 18 de febrero de 2017.
Eso nos da una ventana de 5 meses en que la vulnerabilidad pudo ser aprovechada por usuarios con malas intenciones, pero Cloudflare indica que el mayor periodo de impacto se produjo entre el 13 y el 18 de febrero de 2017, apenas 5 días, limitando bastante el número de posibles webs y datos de usuarios afectados.
Cuando el 18 de febrero Ormandy se puso en contacto con responsables de Cloudflare, la respuesta de la empresa fue rápida para tratar de mitigar las posibles filtraciones y solucionar el problema lo antes posible. En poco más de cuatro horas se desactivaron las opciones que permitían la ejecución de esta vulnerabilidad, en siete se desactivó el HTML Parser, y en tres días ya se había solucionado por completo el fallo de seguridad.
Esta rapidez de actuación junto con la comunicación responsable por parte del investigador de Google ha evitado que ahora mismo estuviésemos hablando de graves problemas en todas aquellas webs alojadas en el servicio CDN de Cloudflare y que pudiesen estar filtrando datos personales de sus usuarios.
Conclusión
El caso que acabamos de revisar es un claro ejemplo de cómo se debe actuar ante una situación de este calibre. La comunicación responsable por parte del investigador y la rápida solución por parte del fabricante han evitado un problema mayor, pero no siempre se dan estas condiciones.
Esperamos que este caso sirva como ejemplo para solucionar futuras vulnerabilidades de forma ejemplar y, sobre todo, que no acaben pagando los usuarios por los errores de las empresas que no actúan de forma apropiada cuando son informadas de fallos en sus sistemas.