Incidente de Cloudflare del 24 de enero de 2023

El 24 de enero de 2023, varios servicios de Cloudflare dejaron de estar disponibles durante 121 minutos debido a un error causado por un código que gestiona los tokens de servicio. El incidente degradó el rendimiento de una amplia variedad de productos de Cloudflare, incluidos algunos aspectos de nuestra plataforma Workers, nuestra solución Zero Trust y funciones del plano de control en nuestra red de entrega de contenido (CDN).

Cloudflare proporciona una funcionalidad de tokens de servicio que permite la autenticación de servicios automatizados en otros servicios. Por ejemplo, los clientes pueden utilizar los tokens de servicio para proteger la interacción entre una aplicación que se ejecute en un centro de datos y un recurso en un proveedor de nube pública. Como parte del lanzamiento, nuestro objetivo era añadir una función que mostrara a los administradores cuándo se utilizó un token por última vez. Esto permitiría a los usuarios limpiar sin problemas los tokens no utilizados. El cambio sobrescribió accidentalmente otros metadatos de los tokens de servicio. Como resultado, los tokens de las cuentas afectadas quedaron invalidados mientras duró el incidente.

El motivo por el que este lanzamiento afectó a otros servicios es el hecho de que Cloudflare se ejecuta en Cloudflare. Los tokens de servicio afectan a la capacidad de autenticación de las cuentas, y múltiples servicios de Cloudflare se basan en dos de las cuentas afectadas. Cuando los tokens de servicio de estas cuentas se sobrescribieron, los servicios en ejecución en estas cuentas empezaron a experimentar fallos de las solicitudes y otros errores inesperados.

Aunque este incidente afectó directamente a un segmento limitado de clientes y usuarios finales, y es posible que otros clientes hayan experimentado la degradación del servicio, el impacto global en la red y los servicios de Cloudflare no fue importante. Sin embargo, sabemos que para los clientes afectados esto no fue una grata experiencia. Estamos documentando lo que falló para que puedas comprender por qué sucedió y las medidas que estamos adoptando para evitar la repetición de un incidente de este tipo.

Cuando los usuarios inician sesión en una aplicación o en un proveedor de identidad, suelen escribir un nombre de usuario y una contraseña. La contraseña permite que ese usuario demuestre que tiene el control del nombre de usuario y que el servicio debe permitirle continuar. Es posible añadir capas de autenticación adicional, como claves de seguridad o la postura del dispositivo, pero el flujo de trabajo es una persona que demuestra a un servicio que es quien afirma ser.

Sin embargo, las personas no son los únicos usuarios que se deben autenticar en un servicio. A menudo las aplicaciones necesitan comunicarse entre ellas. Por ejemplo, imaginemos que desarrollas una aplicación que muestra a un usuario información sobre sus próximos planes de viaje.

La aerolínea guarda la información sobre el vuelo y su duración en su propio sistema. No desean que la información de cada viaje individual esté disponible públicamente en Internet, ni tampoco invitar a tu aplicación a su red privada. De la misma forma, el hotel quiere asegurarse de que solo envían la información acerca de una reserva de habitación al servicio de terceros válido aprobado.

Tu aplicación necesita un método fiable de autenticación en esos sistemas externos. Los tokens de servicio resuelven este problema, puesto que funcionan como una especie de nombre de usuario y contraseña para tu servicio. Al igual que los nombres de usuario y contraseñas, los tokens de servicio constan de dos partes: un ID de cliente y un secreto de cliente. Para una solicitud de autenticación, es necesario enviar ambas. Además, se asigna a los tokens una duración, después de la cual dejan de ser válidos y es necesaria su rotación. Puedes otorgar a tu aplicación un token de servicio y, si los sistemas superiores que necesitas lo validan, tu servicio puede obtener la información de la aerolínea y del hotel y presentarla al usuario final en un informe conjunto.

Cuando los administradores crean tokens de servicio de Cloudflare, generamos el par de ID y secreto de cliente. A continuación, los clientes pueden configurar sus servicios solicitantes para que envíen ambos valores como cabeceras HTTP cuando necesiten acceder a un recurso protegido. El servicio solicitante puede ejecutarse en cualquier entorno, incluido en la red de Cloudflare en forma de un Worker o en una ubicación aparte como un proveedor de nube pública. Los clientes deben implementar el recurso protegido correspondiente detrás del proxy inverso de Cloudflare. Nuestra red comprueba las cabeceras HTTP de cada solicitud que se dirija a un servicio configurado. Si este par está presente, Cloudflare valida su autenticidad y bloquea la solicitud o permite que continúe, según corresponda. También registramos un evento de autenticación.

Todas las indicaciones de fecha y hora corresponden a UTC

El 24 de enero de 2023 a las 16:55, el equipo de ingeniería de Access inicia el lanzamiento que accidentalmente empieza a sobrescribir los metadatos de los tokens de servicio y causa el incidente.

El 24 de enero de 2023 a las 17:05, un miembro del equipo de ingeniería de Access observa un problema no relacionado y revierte el lanzamiento, lo que evita que se sigan sobrescribiendo los metadatos de los tokens de servicio.

Los valores de los tokens de servicio no se actualizan en la red de Cloudflare hasta que se actualiza el propio token de servicio (más detalles a continuación). Esto hizo que el impacto fuera gradual para los tokens de servicio cuyos metadatos se habían sobrescrito.

El 24 de enero de 2023 a las 17:50, el primer token de servicio no válido para Cloudflare WARP se sincroniza con nuestra red global. Los usuarios de WARP y Zero Trust empiezan a verse afectados.

Las cargas de postura del dispositivo de WARP caen a cero, lo que hice saltar una alarma interna

El 24 de enero de 2023 a las 18:12, se declara un incidente debido a la importante disminución de cargas de postura del dispositivo de WARP realizadas con éxito.

El 24 de enero de 2023 a las 18:19, se sincroniza con nuestra red global el primer token de servicio no válido para la API de Cloudflare. Cache Purge, Cache Reserve, Images y R2 empiezan a verse afectados. Se desencadenan alertas para estos productos que identifican un mayor alcance del incidente.

El 24 de enero de 2023 a las 18:21, durante la investigación inicial, se descubren los tokens de servicio sobrescritos.

El 24 de enero de 2023 a las 18:28, se eleva el incidente para incluir todos los productos afectados.

El 24 de enero de 2023 a las 18:51, se identifica e implementa una solución inicial para revertir el token de servicio a su valor original para la cuenta de Cloudflare WARP, que afecta a WARP y Zero Trust. WARP y Zero Trust dejan de verse afectados.

El 24 de enero de 2023 a las 18:56, se implementa la misma solución en la cuenta de la API de Cloudflare, que afecta a Cache Purge, Cache Reserve, Images y R2. Cache Purge, Cache Reserve, Images y R2 dejan de verse afectados.

El 24 de enero de 2023 a las 19:00, se realiza una actualización de la cuenta de la API de Cloudflare que sobrescribe incorrectamente la cuenta de la API de Cloudflare. Cache Purge, Cache Reserve, Images y R2 vuelven a verse afectados. Se bloquean todos los cambios de las cuentas internas de Cloudflare hasta la resolución del incidente.

El 24 de enero de 2023 a las 19:07, se actualiza la API de Cloudflare para incluir el valor de token de servicio correcto. Cache Purge, Cache Reserve, Images y R2 dejan de verse afectados.

El 24 de enero de 2023 a las 19:51, se restauran los tokens de servicio de todas las cuentas afectadas a partir de una copia de seguridad de la base de datos. El incidente finaliza.

El equipo de Access estaba implementando un nuevo cambio en los tokens de servicio que añadía un campo "Last seen at". Era una función ampliamente solicitada cuyo objetivo era ayudar a identificar qué tokens de servicio se estaban utilizando activamente.

El valor de "last seen at" se obtenía al explorar todos los nuevos eventos de inicio de sesión en una cola Kafka de eventos de inicio de sesión de una cuenta. Si se detectaba un evento de inicio de sesión que utilizaba el token de servicio, se iniciaba una actualización del valor "last seen at" del token de servicio correspondiente.

Para actualizar el valor "last seen at" del token de servicio, se realizaba una transacción de lectura/escritura para recopilar la información sobre el token de servicio correspondiente. Por razones de seguridad, las solicitudes de lectura de tokens de servicio excluyen por defecto el valor "client secret". A continuación, la actualización del valor "last seen at" del token de servicio utilizaba esa información que la lectura no incluía en el valor "client secret" y actualizaba el token de servicio con un valor "client secret" vacío en la escritura.

A continuación mostramos un ejemplo de valores de token de servicio correctos e incorrectos:

Ejemplo de valores de token de servicio de Access

La base de datos de "client secret" del token de servicio no tenía una comprobación de "not null". Sin embargo, en esta situación, una cadena de texto vacía no desencadenaba un valor nulo.

{
  "1a4ddc9e-a1234-4acc-a623-7e775e579c87": {
    "client_id": "6b12308372690a99277e970a3039343c.access",
    "client_secret": "<hashed-value>", <-- what you would expect
    "expires_at": 1698331351
  },
  "23ade6c6-a123-4747-818a-cd7c20c83d15": {
    "client_id": "1ab44976dbbbdadc6d3e16453c096b00.access",
    "client_secret": "", <--- this is the problem
    "expires_at": 1670621577
  }
}

Como resultado del error, para cualquier cuenta de Cloudflare que utilizara un token de servicio para la autenticación durante los 10 minutos que estuvo implementado el lanzamiento de "last seen at", el valor "client secret" estaría establecido en una cadena vacía. A continuación, fue necesario modificar el token de servicio para que se utilizara el valor "client secret" vacío para la autenticación. Hubo en total 4 cuentas con este estado, todas ellas internas de Cloudflare.

Como solución temporal, pudimos restaurar manualmente los valores de token de servicio correctos para las cuentas cuyos tokens de servicio se habían sobrescrito. Esto evitó el impacto inmediato en los servicios de Cloudflare afectados.

A continuación, el equipo de bases de datos pudo implementar una solución para restaurar los tokens de servicio de todas las cuentas afectadas a partir de una copia anterior de la base de datos. Esto terminó con cualquier impacto resultado de este incidente.

Los tokens de servicio afectan a la capacidad de autenticación de las cuentas. Múltiples servicios de Cloudflare se basan en dos de las cuentas afectadas. Cuando los tokens de servicio de estas cuentas se sobrescribieron, los servicios en ejecución en estas cuentas empezaron a experimentar fallos de las solicitudes y otros errores inesperados.

Cloudflare proporciona un proxy de reenvío móvil y de escritorio, Cloudflare WARP (nuestra aplicación "1.1.1.1"), que cualquier usuario puede instalar en un dispositivo para mejorar la privacidad de su tráfico de Internet. Cualquier persona puede instalar este servicio sin necesidad de tener una cuenta de Cloudflare. Tampoco mantenemos registros que relacionen la actividad a un usuario.

Cuando un usuario se conecta utilizando WARP, Cloudflare valida la implementación de un dispositivo basándose en un servicio que recibe y valida las claves en el dispositivo. A su vez, ese servicio se comunica con otro sistema que indica a nuestra red que proporcione al nuevo servicio registrado acceso a nuestra red.

Durante el incidente, el servicio de registro no se podía comunicar con los sistemas en nuestra red que deberían validar el dispositivo. Como resultado, los usuarios no podían registrar nuevos dispositivos ni instalar la aplicación en un nuevo dispositivo. También es posible que observaran problemas al actualizar a una nueva versión de la aplicación (lo que también activa un nuevo registro).

Cloudflare proporciona una solución Zero Trust integral que los clientes pueden implementar independientemente de si un agente reside o no en el dispositivo. Algunos casos de uso solo están disponibles cuando se utiliza el agente de Cloudflare en el dispositivo. El agente es una versión empresarial de la misma solución Cloudflare WARP y experimentó una degradación similar cada vez que el agente necesitaba enviar o recibir el estado del dispositivo. Esto afectó a tres casos de uso en Cloudflare Zero Trust.

En primer lugar, de la misma forma que el producto para consumidores, no se podían registrar nuevos dispositivos ni revocar los dispositivos existentes. Los administradores tampoco podían modificar los ajustes de los dispositivos registrados. En todos los casos el usuario había recibido errores.

En segundo lugar, muchos clientes que reemplazan su red privada existente con la solución Cloudflare Zero Trust pueden añadir reglas que validan continuamente la identidad de un usuario mediante el uso de políticas de duración de sesión. El objetivo de estas reglas es obligar a los usuarios a volver a autenticarse para evitar que sesiones obsoletas tengan acceso continuado a los sistemas internos. El agente en el dispositivo solicita al usuario que se vuelva a autenticar de acuerdo con las señales del panel de control de Cloudflare. Durante el incidente, las señales no se enviaron y los usuarios no podían autenticarse con éxito.

Finalmente, los clientes que se basan en las reglas de postura de seguridad también se vieron afectados. Las reglas de postura del dispositivo permiten que los clientes que utilizan políticas de Access o Gateway se basen en el agente WARP para obligar continuamente a que un dispositivo cumpla las reglas de conformidad corporativas.

El agente comunica estas señales a un servicio de Cloudflare responsable del mantenimiento del estado del dispositivo. El producto de control de acceso a Zero Trust de Cloudflare utiliza un token de servicio para recibir esta señal y evaluarla junto con otras reglas para determinar si un usuario puede acceder a un recurso determinado. Durante este incidente, el valor por defecto de estas reglas era una acción en bloqueo. Esto significaba que el usuario vería interrumpido el tráfico modificado por estas políticas. En algunos casos, esto implicaba que todo el tráfico dirigido a Internet desde un dispositivo se bloqueaba por completo, por lo que los usuarios no podían acceder a nada.

Cloudflare Gateway almacena en caché el estado de la postura del dispositivo cada 5 minutos para aplicar políticas de Gateway. El estado de la postura del dispositivo se almacena en caché para que Gateway pueda aplicar políticas sin tener que verificar el estado del dispositivo para cada solicitud. En función del tipo de política de Gateway con el que estuviera emparejado, el usuario obtendría dos resultados distintos. Si estuviera emparejado con una política de red, el usuario experimentaría una interrupción de la conexión y, para una política HTTP, vería una página de error 5XX. Hasta la resolución del incidente, el valor máximo fue de 50 000 errores 5XX por minuto respecto a la línea base, con más de 10,5 millones de errores de lectura de postura.

Errores 5XX de Gateway por minuto

Número total de errores de postura del dispositivo de Gateway

Cloudflare R2 Storage permite que los desarrolladores almacenen grandes cantidades de datos no estructurados sin las costosas tarifas de ancho de banda de salida asociadas con los típicos servicios de almacenamiento en la nube.

Durante el incidente, el servicio R2 no pudo realizar solicitudes de API de salida a otras partes de la infraestructura de Cloudflare. Como resultado, los usuarios de R2 observaron un alto índice de errores al realizar solicitudes a R2.

Muchos productos de Cloudflare dependen también de R2 para el almacenamiento de datos y también se vieron afectados. Por ejemplo, durante este periodo los usuarios de Cache Reserve se vieron afectados y observaron una mayor carga del origen para aquellos elementos que no estaban en la caché primaria. Durante este incidente, la mayoría de las operaciones de lectura y escritura en el servicio Cache Reserve se vieron afectadas, lo que causó el error de las entradas y salida de Cache Reserve. Sin embargo, cuando Cache Reserve observa un error de R2, recurre al origen del cliente, por lo que durante este intervalo se siguió proporcionando el tráfico del usuario.

La red de entrega de contenido (CDN) de Cloudflare almacena en caché, en nuestros centros de datos en todo el mundo, el contenido de las propiedades de Internet de nuestra red. El objetivo es reducir la distancia que necesita recorrer la solicitud de un usuario para obtener una respuesta. En algunos casos, los clientes quieren purgar lo que almacenamos en caché y reemplazarlo por otros datos.

El panel de control de Cloudflare, donde un administrador interactúa con nuestra red, utiliza un token de servicio para autenticarse y acceder al servicio de purga de caché. Durante el incidente, mientras el token de servicio no era válido, muchas solicitudes de purga fallaron. Observamos un impacto promedio de 20 errores de solicitud de purga/s y un máximo de 70 solicitudes/s.

Nos tomamos muy en serio este tipo de incidentes y reconocemos su impacto. Hemos identificado varias medidas que podemos adoptar para hacer frente al riesgo de un problema similar en el futuro. Como resultado de este incidente, estamos implementando el siguiente plan de corrección:

Prueba: el equipo de ingeniería de Access añadirá pruebas unitarias que detectarían automáticamente cualquier problema similar de sobrescrituras de tokens de servicio antes del lanzamiento de cualquier nueva función.

Alerta: el equipo de Access implementará una alerta automática para cualquier incremento drástico de los errores de las solicitudes de autenticación de tokens de servicio, a fin de detectar cualquier problema antes de que su alcance sea mayor.

Proceso: el equipo de Access ha identificado mejoras de proceso para permitir la reversión más rápida para tablas de bases de datos específicas.

Implementación: todos los campos relevantes de la de base de datos se han actualizado para incluir comprobaciones de cadenas vacías, además de las comprobaciones de "not null" existentes.

Lamentamos las molestias que esto ha causado a nuestros clientes de los distintos servicios de Cloudflare. Estamos aplicando activamente estas mejoras para garantizar una mejor estabilidad en el futuro y que este tipo de problema no se repita.