Cloudflare es una empresa que brinda servicios anti-DDoS, rendimiento web, CDN, WAF, ofuscamiento de correos y muchas otras ventajas, incluso gratuitamente. Estos, entre otros, son los motivos por los cuales utilizo Cloudflare desde hace 5 años en Segu-Info, y el evento reciente "de filtración de datos" me permite decir que no me he equivocado en mí elección. ¿Por qué? Sigue leyendo.

Cloudflare ha dejado al descubierto una cantidad desconocida de datos, incluyendo contraseñas de usuarios, información, mensajes privados, APIs, cookies, etc.

Google mantiene el equipo de seguridad Project Zero que se dedica a analizar aplicaciones y programas en busca de vulnerabilidades. Hace una semana, el investigador de Project Zero, Tavis Ormandy alertó a Cloudflare de un problema que habría afectado a los datos de empresas como Uber, OKCupid, Fitbit, 1Password, entre muchas otras. Concretamente, se refiere a datos sobre las sesiones que estas compañías almacenan en sus servidores y se utilizan para validar a los usuarios ante estas aplicaciones. En un comunicado público, que debería ser tomado como ejemplo de transparencia, ha sido la propia CloudFlare la que ha reconocido el problema y ha brindado todos los detalles técnicos.

Qué sucedió

CloudFlare ofrece, entre otros, un servicio CDN para la distribución de contenidos en una extensa red en todo el mundo. De un modo simple, redistribuyen los archivos de millones de sitios web (sus clientes) desde diferentes puntos geográficos y servidores para aliviar la carga sobre los servidores del portal web en cuestión, y para acelerar la descarga de sus archivos por parte de los usuarios.

El "problema" es que en esta labor de intermediario, CloudFlare debe agregar código propio, utilizado para la detección de ataques, hotlinking, y otras medidas de seguridad. Esta tarea requiere parsear el código HTML del cliente y este parser tenía un bug, que provocó la filtración de datos de alrededor de 3.400 sitios webs.

El bug descubierto el 17 de febrero afectó a los proxies reversos de Cloudflare y causó que sus servidores de borde brindaran los datos sensibles, debido a que el error permitía retornar un buffer de memoria que contenía datos privados que no necesariamente correspondían al usuario correcto.

La fuga de información, bautizada Cloudbleed (por su semejanza con HeartBleed), según Ormandy, data de septiembre de 2016, pero se desconoce la dimensión real de la vulnerabilidad o si ha sido aprovechada por delincuentes, aunque se cree que no. "Estoy encontrando mensajes privados de los principales sitios de citas, mensajes completos de un conocido servicio de chat, datos de administrador de contraseñas en línea, marcos de sitios de video para adultos, reservas de hoteles", escribió Tavis Ormandy en su comunicado.

En su anuncio, Cloudflare menciona que el mayor impacto fue desde el 13 al 18 de febrero (fecha en que Ormandy también detectó el fallo) y habrían sido afectados alrededor de 3.300.000 sitios (un 0.00003% de los requerimientos desde los CDN). Esta semana se publicó una lista no oficial de 4.288.852 sitios potencialmente vulnerables. Luego se publicó otra lista actualizada y no oficial de 5.319.353 dominios, entre los que figuraban los míos.
En cambio, Ormandy dijo que la vulnerabilidad de Cloudbleed habría filtrado datos de 3.438 dominios durante un período de cinco días en febrero. "Estamos hablando de peticiones HTTPS completas, direcciones IP de clientes, respuestas completas, cookies, contraseñas, etc.", señala.

De acuerdo con el blog de Cloudflare, el problema se derivó de la decisión de la compañía de usar un nuevo analizador (parser) HTML llamado cf-html. Este parser es una aplicación basada en Ragel y compilada en C, que escanea el código HTML del cliente para extraer información relevante y poder modificarla con el código propio de Cloudflare.

Desde la empresa aseguran que su sistema de cifrado de extremo a extremo ha impedido que el problema sea mayor, pero lo cierto es que motores de búsqueda como Bing, Google o Yahoo! han guardado esta información en una copia caché de los portales web afectados.

En el comunicado explican que tan pronto como detectaron el problema, detuvieron los servicios que estaban permitiendo el acceso a información confidencial y se corrigió el parser. Desde CloudFlare ya se han puesto en contacto con los motores de búsqueda para eliminar la información filtrada, y se ha llevado a cabo la limpieza correspondiente en la mayoría de ellos.

Algunas enseñanzas

Es importante señalar que si bien el error podría (potencial) presentarse en cualquier sitio web servido desde los CDN de Cloudflare, sólo un pequeño porcentaje de sitios fue afectado y solo aquellos que manejaban información sensible -como usuario/contraseña, cookies, token, APIs, etc.- fueron los más perjudicados, debido a la criticidad de esa información que generalmente es transmitida a través de un canal HTTPS.

Por su parte, los sitios HTTP afectados (como los míos) Segu-Info, Segu-Kids, Antiphishing y ODILA que también están en Cloudflare, pero no manipulan información sensible, no podrían haber sido víctimas de ningún ataque y ninguna fuga de información, simplemente porque la información nunca estuvo ahí.

Más allá de la gravedad del bug y del problema generado creo que es importante destacar estos puntos:

• La sinceridad del servicio de Cloudflare, informando del error y del procedimiento de seguimiento del incidente. Como digo al principio, creo que este procedimiento debe ser tomado como ejemplo por muchas empresas: el incidente nunca se niega, siempre se debe informar al cliente.
• La "vulnerabilidad" de todos aquellos que confiamos en la nube. Por ejemplo, el servicio 1Password (que almacena millones de contraseñas de millones de usuarios) no tenía una vulnerabilidad, pero su CDN era servido por Cloudflare, afectando a su vez a millones de usuarios.
• El tratamiento de incidentes debe contemplar la cadena de servicios, no solo un servicio. Por ejemplo ¿basta confiar y analizar una vez al año a mi proveedor de hosting o también debo analizar los cientos de servicios de terceros que dependen de ese primer servicio web? ¿Alguna vez analizaste cuántos servicios están involucrados en la página principal de tu sitio web? Aquí te muestro el mapa de Segu-Info para que te hagas una idea.
• Este evento fue "tapa de diario" durante 3 días. Realmente considero que fue un hype que llegó a ser Trend Topic, generado por el desconocimiento. El problema fue grave, pero eso no significa que fuera el fin de la nube tal y como la conocemos. Al contrario, debe enseñarnos algo de lo que menciono anteriormente.
• Por último, ¿ya cambiaste tus contraseñas de los servicios afectados, eliminaste las cookies y regeneraste las APIs?

Estando desconectado y de vacaciones se hacía complicado entender el alcance del problema, por lo que finalmente deseo agradecer a los que me avisaron sobre el fallo y sobre que mis sitios supuestamente eran vulnerables. ¡GRACIAS!

Lic. Cristian Borghello, CISSP, CCSK