Desde el descubrimiento de las vulnerabilidades CRIME, BREACH, TIME, LUCKY-13, entre otras, los ataques de canal lateral basados en la longitud se han considerado viables. Aunque los paquetes estaban encriptados, los atacantes pudieron inferir información sobre el texto sin formato subyacente analizando metadatos como la duración del paquete o la información de tiempo.
Un grupo de investigadores de la Universidad Ben Gurion que escribieron un artículo titulado "What Was Your Prompt? A Remote Keylogging Attack on AI Assistants", que describe "un nuevo canal lateral que se puede utilizar para leer respuestas cifradas de asistentes de IA a través de la web", contactaron con Cloudflare.
El equipo de Workers AI y AI Gateway colaboró estrechamente con estos investigadores a través de nuestro programa Public Bug Bounty con el fin de descubrir y actualizar íntegramente una vulnerabilidad que afecta a los proveedores de LLM. Puedes leer el documento detallado de la investigación aquí.
Desde que recibimos la notificación de esta vulnerabilidad, hemos implementado una medida de mitigación para ayudar a proteger a todos los clientes de Workers AI y AI Gateway, que en ningún momento estuvieron en riesgo, según hemos podido determinar.
¿Cómo funciona el ataque de canal lateral?
En el documento, los autores describen un método en el que interceptan la transmisión de una sesión de chat con un proveedor de LLM, utilizan los encabezados del paquete de red para inferir la longitud de cada token, extraen y segmentan su secuencia, y luego utilizan sus propios LLM dedicados para inferir la respuesta.
Los dos ingredientes principales para que un ataque sea fructífero son un cliente de chat de IA que se ejecute en modo de transmisión y un ciberdelincuente capaz de capturar el tráfico de red entre el cliente y el servicio de chat de IA. En el modo de transmisión, los tokens LLM se emiten de manera secuencial, lo que plantea una vulnerabilidad de canal lateral que emplea la longitud de token. Los atacantes podrían espiar los paquetes a través de redes públicas o proveedores de acceso a Internet (ISP).
Un ejemplo de solicitud vulnerable al ataque de canal lateral es el siguiente:
curl -X POST \
https://api.cloudflare.com/client/v4/accounts/<account-id>/ai/run/@cf/meta/llama-2-7b-chat-int8 \
-H "Authorization: Bearer <Token>" \
-d '{"stream":true,"prompt":"tell me something about portugal"}'
Usemos Wireshark para inspeccionar los paquetes de red en la sesión de chat de LLM durante la transmisión:
El primer paquete tiene una longitud de 95 y corresponde al token "Port" que tiene una longitud de cuatro. El segundo paquete tiene una longitud de 93 y corresponde al token "ug" que tiene una longitud de dos, y así sucesivamente. La eliminación del probable sobre de token de la longitud del paquete de red permite inferir fácilmente cuántos token se transmitieron y su secuencia y longitud individual con solo rastrear los datos de red encriptados.
Dado que el atacante necesita la secuencia de la longitud del token individual, esta vulnerabilidad solo afecta a los modelos de generación de texto que utilizan la transmisión. Esto significa que los proveedores de inferencia de IA que utilizan la transmisión, la forma más común de interactuar con los LLM, como Workers AI, son potencialmente vulnerables.
Este método requiere que el atacante esté en la misma red o en posición de observar el tráfico de comunicación, y su precisión depende de conocer el estilo de escritura del LLM objetivo. En condiciones ideales, los investigadores afirman que su sistema "puede reconstruir el 29 % de las respuestas de un asistente de IA e inferir con éxito el tema a partir del 55 % de ellas". También es importante tener en cuenta que, a diferencia de otros ataques de canal lateral, en este caso el atacante no tiene forma de evaluar su predicción con respecto a la realidad. Por lo tanto, es tan probable que obtengamos una oración con una precisión casi perfecta como una en la que solo las cosas que coinciden sean las conjunciones.
Mitigación de los ataques de canal lateral en los LLM
Dado que este tipo de ataque se basa en la longitud del token que se infiere del paquete, se puede mitigar con la misma facilidad ocultando el tamaño del token. Los investigadores sugirieron algunas estrategias para mitigar estos ataques de canal lateral, una de las cuales es la más sencilla. Se trata de rellenar las respuestas del token con longitudes aleatorias confusas para ocultar la longitud del token, de modo que las respuestas no se puedan inferir de los paquetes. Aunque añadimos inmediatamente la mitigación a Workers AI, nuestro propio producto de inferencia, queríamos ayudar a los clientes a proteger sus LLM, con independencia de dónde se ejecuten, añadiéndolos a AI Gateway.
A partir de hoy, todos los usuarios de Workers AI y AI Gateway están protegidos automáticamente contra este ataque de canal lateral.
Qué hicimos
Una vez que nos enteramos de este trabajo de investigación y de cómo la explotación de la técnica podía afectar potencialmente a nuestros productos de IA, hicimos lo que siempre hacemos en situaciones como esta. Reunimos un equipo de ingenieros de sistemas, ingenieros de seguridad y gerentes de producto y comenzamos a analizar estrategias de mitigación de riesgos y los próximos pasos. También convocamos a los investigadores, que tuvieron la amabilidad de asistir, presentar sus conclusiones y responder a las preguntas de nuestros equipos.
El equipo de investigación nos proporcionó un cuaderno de pruebas que podíamos utilizar para validar los resultados del ataque. Si bien pudimos reproducir los resultados de los ejemplos del cuaderno, descubrimos que la precisión variaba de forma significativa con nuestras pruebas utilizando diferentes respuestas de solicitud y diferentes LLM. No obstante, el documento merece la pena, y los riesgos no son insignificantes.
Decidimos incorporar la primera sugerencia de mitigación en el documento, que era incluir el relleno aleatorio en cada mensaje para ocultar la longitud real del token en la transmisión, lo que complica los intentos de inferir información basada únicamente en el tamaño del paquete de red.
Workers AI, nuestro producto de inferencia, ahora está protegido
Con nuestro producto de inferencia como servicio, cualquiera puede utilizar la plataforma Workers AI y hacer llamadas API a nuestros modelos de IA compatibles. De esta forma, supervisamos las solicitudes de inferencia que se realizan hacia y desde los modelos. Como tal, tenemos la responsabilidad de garantizar que el servicio sea seguro y esté protegido de posibles vulnerabilidades. En cuanto recibimos la notificación de la investigación, implementamos de inmediato una solución, y ahora todos los clientes de Workers AI están automáticamente protegidos contra este ataque de canal lateral. No hemos visto ningún ataque malicioso que se aproveche de esta vulnerabilidad, aparte de las pruebas éticas de los investigadores.
Nuestra solución para Workers AI es una variación de la estrategia de mitigación sugerida en el documento de investigación. Dado que transmitimos objetos JSON y no tokens sin procesar, en lugar de rellenar el token con caracteres de espacios en blanco, hemos añadido una nueva propiedad, "p" (para el relleno), que tiene un valor de cadena de longitud aleatoria variable.
Ejemplo de respuesta de transmisión utilizando la sintaxis SSE:
data: {"response":"portugal","p":"abcdefghijklmnopqrstuvwxyz0123456789a"}
data: {"response":" is","p":"abcdefghij"}
data: {"response":" a","p":"abcdefghijklmnopqrstuvwxyz012"}
data: {"response":" southern","p":"ab"}
data: {"response":" European","p":"abcdefgh"}
data: {"response":" country","p":"abcdefghijklmno"}
data: {"response":" located","p":"abcdefghijklmnopqrstuvwxyz012345678"}
La ventaja de esta medida es que no se requieren modificaciones en el SDK o en el código del cliente, los cambios son imperceptibles para los usuarios finales y nuestros clientes no tienen que hacer nada. La incorporación de una longitud variable aleatoria a los objetos JSON, nos permite implementar la misma variabilidad a nivel de red, y el atacante básicamente pierde la señal de entrada necesaria. Los clientes pueden seguir utilizando Workers AI como de costumbre mientras se benefician de esta protección.
Y esto no es todo.... AI Gateway protege a los usuarios de cualquier proveedor de inferencia
Hemos añadido protección a nuestro producto de inferencia de IA, pero también tenemos un producto que redirecciona las solicitudes mediante proxy a cualquier proveedor: AI Gateway. AI Gateway actúa como un proxy entre un usuario y los proveedores de inferencia compatibles, lo que ayuda a los desarrolladores a optimizar el control, el rendimiento y la observabilidad sobre su aplicación de IA. En línea con nuestra misión de ayudar a mejorar Internet, queríamos implementar rápidamente una solución que pudiera ayudar a todos nuestros clientes que utilizan la generación de texto con IA, independientemente del proveedor que utilicen o de las medidas de mitigación que tengan para evitar este ataque. Para ello, implementamos una solución similar que rellena todas las respuestas de transmisión redireccionadas mediante proxy a través de AI Gateway con interferencias aleatorias de longitud variable.
Nuestros clientes de AI Gateway están ahora protegidos automáticamente contra este ataque de canal lateral, incluso si los proveedores de servicios de inferencia ascendentes aún no han mitigado la vulnerabilidad. Si no estás seguro de si tu proveedor de inferencia ya ha actualizado esta vulnerabilidad, utiliza AI Gateway para redireccionar tus solicitudes mediante proxy y asegurarte de que estás protegido.
Conclusión
En Cloudflare, nuestra misión es ayudar a mejorar Internet, lo que significa que nos preocupamos por todos los usuarios de Internet, independientemente de cuál sea su pila tecnológica. Estamos orgullosos de poder mejorar la seguridad de nuestros productos de IA de forma transparente y sin necesidad de que nuestros clientes realicen ninguna acción.
Agradecemos a los investigadores que descubrieron esta vulnerabilidad y han colaborado para ayudarnos a comprender el problema. Si eres investigador de seguridad y estás interesado en ayudarnos a mejorar la seguridad de nuestros productos, consulta nuestro programa Bug Bounty en hackerone.com/cloudflare.