Cloudbleed: cómo lidiar con eso

Tavis Ormandy (Tavis Ormandy) del Proyecto Cero de Google descubrió una vulnerabilidad importante en el servicio de infraestructura de Internet Cloudflare. ¡Esencialmente, las solicitudes web a sitios respaldados por Cloudflare recibieron respuestas que incluían información aleatoria de otros sitios respaldados por Cloudflare! Esta información podría incluir información confidencial (mensajes privados en sitios de citas, correos electrónicos), información de identidad del usuario (Información de identificación personal (PII), y potencialmente en un contexto de atención médica, Información de salud protegida (PHI) o credenciales de usuario, aplicación o dispositivo (contraseñas, claves API, tokens de autenticación, etc.)

Tanto Project Zero como Cloudflare actuaron rápidamente. El error se informó en 2017–02–17 y se implementó una mitigación en una hora. La notificación pública se realizó en 2017–02–23.

La duración (2016–09–22 a 2017–02–20) y la amplitud potencial de información expuesta es enorme: Cloudflare tiene más de 2 millones de sitios web en su red, y los datos de cualquiera de estos están potencialmente expuestos. Cloudflare ha dicho que el impacto real es relativamente menor, por lo que creo que solo se distribuyeron cantidades limitadas de información. Esencialmente, una amplia gama de datos estaba potencialmente en riesgo, pero el riesgo para cualquier dato individual era muy bajo. De todos modos, a menos que se pueda demostrar de manera concluyente que sus datos NO se vieron comprometidos, sería prudente considerar la posibilidad de que se hayan visto comprometidos.

Si bien el servicio de Cloudflare se parchó rápidamente para eliminar este error, los datos se filtraban constantemente antes de este punto, durante meses. Algunos de estos datos se almacenaron en caché públicamente en motores de búsqueda como Google, y se están eliminando. Pueden existir otros datos en otros cachés y servicios a través de Internet, y obviamente es imposible coordinar la eliminación en todas estas ubicaciones. Siempre existe la posibilidad de que alguien malintencionado descubra esta vulnerabilidad de forma independiente y antes de Tavis, y puede haber estado explotándola activamente, pero no hay evidencia que respalde esta teoría. Desafortunadamente, también es difícil refutar de manera concluyente.

La información más confidencial filtrada es la información de autenticación y las credenciales. Un compromiso de estos datos puede tener consecuencias duraderas y continuas hasta que se revoquen y reemplacen las credenciales.

Desde una perspectiva individual, esto es sencillo: la mitigación más efectiva es cambiar sus contraseñas. Si bien es probable que esto no sea necesario (es poco probable que sus contraseñas hayan sido expuestas en este incidente), mejorará absolutamente su seguridad tanto de este posible compromiso como de muchos otros problemas de seguridad mucho más probables. Cloudflare está detrás de muchos de los servicios web de consumo más grandes (Uber, Fitbit, OKCupid, ...), por lo que, en lugar de tratar de identificar qué servicios están en Cloudflare, lo más cauteloso es usar esto como una oportunidad para rotar TODAS las contraseñas en todos sus sitios . Esto mejorará su seguridad, aunque el beneficio principal es de amenazas no relacionadas con este incidente.

(La mejor práctica es utilizar una cadena larga y aleatoria para cada contraseña, única para cada sitio, y administrar esa colección utilizando un "administrador de contraseñas", como 1Password, LastPass o los administradores de contraseñas integrados en los navegadores web modernos. también debe cerrar sesión e iniciar sesión en sus aplicaciones móviles después de esta actualización. Mientras lo hace, si es posible usar 2FA o 2SV con sitios que considere importantes (usando algo como TOTP / Google Authenticator o U2F), eso es significativo actualización de seguridad, también.)

Para los operadores de sitios que usan Cloudflare: si bien puede ser perjudicial, debe considerar seriamente el impacto en sus usuarios. Use este incidente como una oportunidad para ejercer su proceso de manejo de incidentes: discuta el impacto específico para su aplicación y qué respuesta tiene más sentido (es probable que sea diferente para cada sitio o aplicación). Debe equilibrar un riesgo desconocido pero pequeño frente a . otros costos. Tenga cuidado de no "asustarlos", pero puede ser prudente tomar medidas. Como mínimo, prepararía una "respuesta estándar" para obtener asistencia sobre este incidente y, en un contexto empresarial o b2b, me comunicaría de manera proactiva con los clientes sobre el alcance del incidente y su efecto en su aplicación y sus datos. Para la gran mayoría de los sitios en Cloudflare, eso solo es probablemente suficiente.

Forzar un cambio de contraseña de usuario conlleva costos muy reales: los usuarios pueden perder la confianza en su servicio y es un inconveniente. No parece que se haya comprometido un gran número de credenciales, por lo que para un servicio al consumidor con riesgo limitado para cuentas comprometidas, puede que no valga la pena el esfuerzo de invalidar en masa las contraseñas y forzar un cambio. Para las credenciales de administrador, o para cualquier sitio que procese información altamente confidencial a través de Cloudflare, la falta de una exposición máxima cuantificable probablemente significa que vale la pena forzar una actualización de contraseña. Si tuviera alguna otra razón para querer enviar una actualización de contraseña a todos sus usuarios, esto, por supuesto, sería un factor adicional en la decisión.

Los sitios deben invalidar las credenciales de autenticación para aplicaciones móviles y otras comunicaciones de máquina a máquina (dispositivos IoT, etc.), forzando a los usuarios a volver a inscribir aplicaciones y dispositivos, si utilizaron Cloudflare como proveedor de infraestructura. Si no desea forzar un cambio de contraseñas, un paso intermedio viable podría ser invalidar los tokens de autenticación, obligando a los usuarios a iniciar sesión nuevamente con sus contraseñas existentes; Dado que los tokens de autenticación se pasan con mayor frecuencia entre el navegador y el servidor, es mucho más probable que existan en una fuga de memoria aleatoria del servidor que las contraseñas sin formato, y forzar un nuevo inicio de sesión es un impacto mínimo para los usuarios y puede no requerir ningún mensaje específico o notificación.

Además, cualquier sitio que no esté en Cloudflare pero con una gran cantidad de usuarios que usan sitios alojados en Cloudflare (esencialmente cualquier sitio grande o de consumo en Internet) debería considerar forzar cambios de contraseña de usuario en caso de que sus usuarios hayan reutilizado las mismas contraseñas en cada sitio . Probablemente esto no esté garantizado para la gran mayoría de los sitios (cualquier persona con necesidades de seguridad tan altas que tenga sentido debería usar una infraestructura de autenticación mucho más segura que las contraseñas de los usuarios; de lo contrario, es casi seguro que los usuarios reutilizarán las contraseñas con un sitio comprometido ), pero puede ser una posibilidad. Personalmente, lo usaría como una oportunidad para actualizar mi infraestructura de autenticación general en tal caso: implementar 2FA (idealmente U2F o mejor, o TOTP / HOTP seleccionable por el usuario, no SMS), monitoreo de la actividad de la cuenta, etc., en lugar de apresurarse un cambio como invalidar contraseñas. Las contraseñas independientes en Internet ya no son la mejor práctica para la autenticación de usuarios.

Si su aplicación o sitio web está en Cloudflare y está sujeto a las regulaciones nacionales o de la industria, esto puede ser un incidente denunciable. (ejemplos serían preocupaciones de salud / privacidad médica con HIPAA). Sus equipos de seguridad y cumplimiento deben evaluar. Obviamente, el pleno cumplimiento de las regulaciones aplicables es una parte esencial de la seguridad.

Subjetivamente, creo que este es un problema de seguridad grave y debe ser evaluado por cualquier servicio importante que use Cloudflare. Es probable que no sea un "fin del mundo" en gravedad, ya que a menos que haya una explotación maliciosa concertada, los datos vulnerables probablemente se distribuyan de manera bastante aleatoria a través de Internet, pero la presencia de datos en cachés de búsqueda puede hacer posible la explotación a pequeña escala. Dado que la mitigación para los usuarios finales es un buen consejo en general (use un administrador de contraseñas, use contraseñas aleatorias únicas por sitio, rote cualquier compromiso), es una "obviedad" para la mayoría de los usuarios finales conscientes de la seguridad. Para los operadores de sitios, la decisión realmente se reduce a su base de usuarios específica y su nivel de sofisticación de seguridad y tolerancia al riesgo. Aprecio profundamente tanto el trabajo en curso del Proyecto Cero de Google (especialmente Tavis) como la rápida respuesta de Cloudflare a este problema.