sangrado de nubes

El jueves 23 de febrero de 2017, Cloudflare publicó una entrada en la que señalaba que: ^{[ 12 ]}

El fallo era grave porque la memoria filtrada podía contener información privada y porque los motores de búsqueda la habían almacenado en caché. Tampoco hemos encontrado ninguna evidencia de que se haya explotado maliciosamente ni otros informes sobre su existencia. El período de mayor impacto fue del 13 al 18 de febrero, cuando aproximadamente 1 de cada 3.300.000 solicitudes HTTP a través de Cloudflare podía provocar una fuga de memoria (aproximadamente el 0,00003 % de las solicitudes).

Cloudflare reconoció que la filtración de datos podría haberse producido ya el 22 de septiembre de 2016. La compañía también declaró que una de sus claves privadas, utilizada para el cifrado de máquina a máquina, se filtró.

Resultó que el error subyacente que causaba la fuga de memoria había estado presente en nuestro analizador basado en Ragel durante muchos años, pero no se producía ninguna fuga de memoria debido a la forma en que se utilizaban los búferes internos de NGINX . La introducción de cf-html modificó sutilmente el almacenamiento en búfer, lo que permitió la fuga, aunque no existían problemas en cf-html en sí. ^{[ 3 ]}

John Graham-Cumming , CTO de Cloudflare , señaló que los clientes de Cloudflare, como Uber y OkCupid, no fueron informados directamente de las filtraciones debido a los riesgos de seguridad que implicaba la situación. «No hubo comunicación extraoficial fuera de Cloudflare, solo con Google y otros motores de búsqueda», afirmó. ^{[ 6 ]}

Graham-Cumming también dijo que "Desafortunadamente, era el antiguo software el que contenía un problema de seguridad latente y ese problema solo se manifestó cuando estábamos en proceso de migrar hacia otro sistema". Añadió que su equipo ya ha comenzado a probar su software para detectar otros posibles problemas. ^{[ 7 ]}

Tavis Ormandy declaró inicialmente que estaba "realmente impresionado con la rápida respuesta de Cloudflare y con su dedicación para solucionar este desafortunado problema". ^{[ 1 ]} Sin embargo, cuando Ormandy presionó a Cloudflare para obtener más información, "dieron varias excusas que no tenían sentido", ^{[ 13 ]} antes de enviar un borrador que "minimiza gravemente el riesgo para los clientes". ^{[ 14 ]}

Uber declaró que el impacto en su servicio fue muy limitado. ^{[ 10 ]} Un portavoz de Uber agregó: "Solo se vieron afectados unos pocos tokens de sesión, los cuales ya han sido cambiados. Las contraseñas no quedaron expuestas". ^{[ 15 ]}

Elie Seidman, CEO de OKCupid, declaró: «CloudFlare nos alertó anoche sobre su vulnerabilidad y hemos estado investigando su impacto en los miembros de OkCupid. Nuestra investigación inicial ha revelado una exposición mínima, si es que existe alguna. Si determinamos que alguno de nuestros usuarios se ha visto afectado, le notificaremos de inmediato y tomaremos medidas para protegerlo». ^{[ 10 ] [ 15 ]}

Fitbit declaró que había investigado el incidente y que solo había encontrado que "un pequeño grupo de personas se vieron afectadas". Recomendó a los clientes afectados que cambiaran sus contraseñas y borraran los tokens de sesión revocando y volviendo a agregar la aplicación a su cuenta. ^{[ 16 ]}

En una publicación de blog, Jeffery Goldberg afirmó que ningún dato de 1Password estaría en riesgo debido a Cloudbleed, citando el uso del protocolo Secure Remote Password (SRP) por parte del servicio , en el que el cliente y el servidor verifican su identidad sin compartir ningún secreto a través de la red. Los datos de 1Password se cifran adicionalmente mediante claves derivadas de la contraseña maestra del usuario y un código de cuenta secreto, lo que, según Goldberg, protegería las credenciales incluso si los propios servidores de 1Password fueran vulnerados. 1Password no sugirió a los usuarios que cambiaran su contraseña maestra en respuesta a una posible vulneración relacionada con el fallo. ^{[ 17 ]}