Cloudbleed: ¿es realmente importante cambiar TODAS las contraseñas?

Si bien Miao es el adecuado para el caso de contraseñas, esta vulnerabilidad también hace que se comprometan los touthens outh. Si un sitio dependiente de Cloudflare usa Oauth, debe realizar un paso adicional para restablecer sus sesiones dependientes de la misma en toda la web.

No hay razón para cambiar ninguna otra contraseña. El único escenario en el que puedo pensar dónde se puede requerir es el siguiente:

Un atacante aprende una contraseña para su servicio de correo. Luego, él / ella usa el servicio de correo comprometido para restablecer una contraseña de un servicio que no sea CloudFlare.

Como no pude encontrar un servicio de correo que dependiera de CloudFlare, por lo que este escenario no es probable, estoy seguro de que es una respuesta de pánico.

Honestamente, no creo que las personas se vean tan afectadas como algunos pueden intentar hacerte creer. La probabilidad de que exactamente se vean afectadas sus cuentas es cercana a cero.

Para ser afectado, varias cosas deben haber sucedido al mismo tiempo:

1. Estabas navegando en uno de los sitios afectados.
2. Un atacante intentaba al mismo tiempo recopilar datos privados emitiendo tantas solicitudes erróneas como su conexión y nube de nubes le permiten hacer
3. El atacante aterrizó en las mismas instancias de proxy inverso a las que sus peticiones fueron atendidas anteriormente por

Las tres cosas deben haber ocurrido casi al mismo tiempo. En el punto 2, es posible que el atacante haya recopilado datos privados de algunos usuarios, pero la probabilidad de que fueras uno de ellos es bastante baja.

La razón por la que debe haber ocurrido al mismo tiempo es bastante simple. Las instancias de proxy no tienen memoria ilimitada y, por lo tanto, la memoria se reutiliza muy a menudo. Entonces, incluso si la memoria proxy contenía algunos datos confidenciales de su solicitud, una de las siguientes solicitudes de otros usuarios habría sobrescrito estos datos debido a la reutilización de la misma memoria.

Supongo que la instancia de proxy que usted y el atacante estaban usando en este momento también dependían de su ubicación geográfica y de la de los atacantes. Nunca recibí nada con la ayuda de cloudflare y nunca estudié cómo funciona su equilibrio de carga, pero asumo que siempre intentan darle una instancia de proxy que ofrezca el mejor rendimiento para la ubicación geográfica en particular. Sobre la base de esa suposición, supongo que los atacantes se limitaron a los proxies en la misma ubicación.

Además, como solo unas pocas solicitudes habrían contenido sus contraseñas (solo las solicitudes de inicio de sesión), la mayoría de los datos confidenciales filtrados solo habrían incluido tokens de sesión y cosas por el estilo. Por lo tanto, la posibilidad de que se filtren sus contraseñas se reduce aún más.

Siguiente punto: A partir de ahora, se supone que Cloudbleed no se explotó antes de que se descubriera y cerrara el agujero. Se supone que los datos filtrados residen principalmente en cachés de motores de búsqueda (y probablemente en todo lo demás en Internet que hace caché). Pero el número de solicitudes con datos filtrados que hicieron estos motores de búsqueda es bastante bajo en comparación con las solicitudes que necesita un atacante para obtener suficientes datos confidenciales y obtener TUS datos.

Hay algunos pasos a seguir:

1. Borra los datos de tu navegador y las cookies
2. cierre la sesión de todos los sitios web para desactivar su sesión
3. El sitio web afectado por la vulnerabilidad de sangrado de la nube debe notificar a todos los usuarios que cambien su contraseña. Se te obligará a cambiar tu contraseña.
4. Configure la autenticación de dos factores lo antes posible