Multipath Reliable Connection (MRC): Un protocolo de red diseñado para los LLMs

Este fin de semana he estado leyendo sobre este nuevo protocolo de red creado especialmente para resolver el problema de la congestión del tráfico de red que se produce en los mega-datacenters utilizados para entrenar los nuevos LLM cuando se mueven datos de GPU a GPU en los centros de datos. En estos casos, estamos hablando de interconexión de datos entre clusters que pueden contener centenares de miles de GPUs, por lo que los protocolos que envían los datos por la red son críticos en la reducción del tiempo de entrenamiento, mediante una reducción de la latencia de envío de paquetes de red y, por consiguiente, reducción del consumo de energía. 

Figura 1: Multipath Reliable Connection (MRC).

Un protocolo de red diseñado para los LLMs

MRC está creado específicamente para resolver esos problemas, y ha sido publicado en el paper de Open Compute "Multipath Reliable Connection (MRC) Specification" donde equipos de OpenAI, Microsoft, NVIDIA, Broadcom y AMD han estado trabajando para definir el nuevo protocolo que ya han puesto en producción en los clusters de entrenamiento de OpenAI y Microsoft, incluidos centros de datos de entrenamiento de Oracle.

Figura 2: Multipath Reliable Connection (MRC)

El protocolo MRC se basa en RoCEv2 (RDMA over Converged Ethernet v2), es decir, que sigue aprovechando las capacidades de RDMA (Remote Direct Access Memory) para enviar tráfico por la red de computador a computador desde la memoria de uno hasta la memoria de otro sin pasar por la CPU utilizando RoCEv2, que está diseñado especialmente para las redes Ethernet.

Figura 3: La red es el punto de congestión de los mega-datacenters

Sin embargo, en entornos de alta congestión - como es el de entrenar un LLM de frontera en un datacenter con cientos de miles des GPUs pasándose datos - , es que la red necesita una arquitectura de capas (Tiers) para conectar switches, de tal manera que dependiendo de la distancia física que exista entre las GPUs que se pasan los datos, hay que atravesar muchas capas de Switches de interconexión, y es ahí donde se produce la congestión. 

Figura 4: La propuesta de OCP es MRC con Packet Spraying

Para resolver esto, la solución es ampliar el número de capas, ampliando la latencia, para que existan más rutas posibles, lo que tampoco es una solución perfecta. Lo que propone MRC es utilizar Packet Spraying, es decir, dividir los datos que se van a enviar en pequeños paquetes de red que utilizarán, cada uno de ellos, una ruta diferente dentro de las rutas posibles.

Figura 5: Arquitectura en Tiers de Switches

Para eso es necesario conocer el estado de calidad de la red, los puertos disponibles, y poder crear una ruta para cada paquete de la red. Esto se hace con un protocolo llamado  SRv6 (Segment Routing over IPv6) que se encarga de crear la ruta para cada paquete dentro de la estructura de Tiers de los Switches de interconexión. 

Figura 6: Control de Congestión con QPCP

La especificación completa, donde se definen los estados de los protocolos de control de la congestión y calidad de la red en cada momento QP Congestion Protocol (QPCP) están todos correctamente descritos en la especificación, ya que se trata de un protocolo abierto, y tienes el paper académico de Resilient AI Supercomputer Networking using MRC and SRv6 con las pruebas realizadas publicado.

Figura 7: Resilient AI Supercomputer Networking using MRC and SRv6

Este es un ejemplo de cómo la necesidad de innovar con Inteligencia Artificial está impulsando la innovación en otras áreas adyacentes de forma masiva, como es la gestión de la energía, los protocolos de red o la gestión de grandes volúmenes de datos. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Bug Hunting and Vibe-Exploiting en 86-DOS "High-performance operating system for the 8086" version 1.00 del 04/28/81

Hace un par de días, coincidiendo con el 45 aniversario de su creación, Tim Paterson ha puesto en GitHub el código fuente en abierto de varias versiones de nuestro querido DOS, para que los amantes del retro-computing puedan analizarlo, utilizarlo, mejorarlo, o construir cosas nuevas. Entre ellas está el código del 86-DOS "High-performance operating system for the 8086" version 1.00 del 04/28/81, una joya. Quiero agradecer a Tim Paterson que haya compartido esta maravilla de nuestra historia para poder estudiarlo, quererlo y seguir dándole continuidad.

Figura 1: Bug Hunting and Vibe-Exploiting en 86-DOS

"High-performance operating system for the 8086"

version 1.00 del 04/28/81

La gracia del mundo en que vivimos hoy en día, es que, gracias a la irrupción de la Inteligencia Artificial, se puede hacer Bug Hunting para encontrar bugs y explotarlos simplemente pidiéndole esto al modelo. De esto os hablé en el artículo de "Cómo usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source", que os invito a leer, así como compraros el libro de "Bug Hunter" (hoy lo tienes con descuento aún).

Figura 2:"Bug Hunter" escrito por David Padilla en 0xWord

Como oso podéis imaginar, como puro entretenimiento, y experimento, le pedí a Gemini Thinking que analizara el código de la versión 86-DOS publicada en GitHub, para ver qué vulnerabilities podía encontrar y de eso va este artículo de hoy.

Figura 3: Código fuente en ASM de 80-DOS_1.00

El resultado tras pasarle el código es que Gemini ha reportado 6 Bugs en el código Ensambalador (ASM) de esta versión 86-DOS, que os paso a dejar por aquí. Y mola mucho lo bien explicados que están cada uno de ellos.

Figura 4: Arbitrary Memory Overwrite

Además, como os conté en el artículo de "Cómo crear un exploit 1-day sobre un CVE de Chrome con Vibe Coding usando Claude Opus (no Mythos) y poner en jaque todas las apps en Electron" hoy en día es posible utilizar también a los modelos de IA para la fase de creación del exploit, así que le he pedido que me haga una PoC de cómo explotar cada uno de ellos. Así que le he pedido un poco de Vibe-Exploiting.

Figura 5: PoC de Exploit para el bug 1

Por supuesto, en esta versión de DOS no hay DEP, ASLR o Privilegios de CPU, que tienen los sistemas operativos Windows hoy en día - Máxima Seguridad en Windows lo explica perfectamente - pero es que aún faltaban muchos hackers haciendo exploits de Smashing the Stack, y por supuesto las vulnerabilidades como Spectre, Meltdown o GhostRace a bajo nivel.

Figura 6: Information Leakage en el nombre de un fichero a copiar

Explotar estas vulnerabilidades es bastante sencillo sin tener que conseguir evitar las protecciones de hoy en día, así que este Information Leakage se basa en poner nombres largos y ver qué datos de la memoria se consiguen, como vemos aquí.

Figura 7: Explotación del bug #2

En total, como os he dicho son seis, y cada uno de ellos es distinto, lo que hace aún más bonito este ejercicio teórico, ya que de todos ellos se aprende algo diferente.

Figura 8: Missing Directory Entry Validation

En este caso no nos ha hecho el exploit, porque lo que hay que hacer es una explotación modificando los bytes del disco a bajo nivel, con un editor hexadecimal sin pasar por las herramientas de gestión de ficheros el sistema operativo.

Figura 9: Explotación del bug #4

El siguiente es un ejemplo de cómo hay direcciones importantes del sistema operativo que pueden ser sobrescritas para tomar el control del flujo de ejecución del sistema operativo.

Figura 10: Lack of Interrupt Vector Protection

Esto es un fallo que permite a un malware tomar control de esas direcciones de memoria y ejecutar un software malicioso, como un rootkit que troyanice todo el sistema operativo. Esto es por lo que se crearon los sistemas de arranque seguros con los TPM (Trusted Platform Modules).

Figura 11: Explotación con secuestro de interrupcion

El penúltimo de los bugs reportados es la posibilidad de poder corromper el sistema de archivos FAT de un disco con un puntero a un cluster malicioso, como se explica en la imagen siguiente.

Figura 12: Fat Corruption via Malicious Cluster Pointer

Y para explotarlo, aquí tienes un ejemplo en forma de snippet de código para meter dentro de un programa que lo ejecute y corrompa la FAT.

Figura 13: Snippet de código para explotarlo

Y la última vulnerabilidad es un bug que permite una Denegación de Servicio (DoS) que puede crashear el sistema operativo y obligar al reinicio de la máquina.

Figura 14: Stack Exhaustion

El problema es la gestión de la pila (stack) del sistema y para meter un puntero a la base de la pila que genera una re-escritura de los registros y colapsa cuando intenta volver de la llamada, porque está sobre-escrita la dirección de retorno.

Figura 15: Exploit genera un bucle con la INT 21h

El uso de buscar vulnerabilidades con IA es algo de lo que ya os hablé en el libro de Hacking y Pentesting con Inteligencia Artificial, y por supuesto es parte fundamental del trabajo de Bug Hunter que David Padilla ha publicado.

Figura 16: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Reprompt Attack en Microsoft Copilot con Spear Phishing

Los investigadores de Varonis han hecho pública su investigación sobre Reprompt en Microsoft Copilot que permitía ejecutar comandos con un solo click en un correo electrónico, generar acciones y exfiltrar datos. El reporte se hizo de forma responsable, y Microsoft ha configurado Safeguards para evitar este tipo de ataque, pero merece la pena ver su funcionamiento.

Figura 1: Reprompt Attack en Microsoft Copilot con Spear Phishing

El ataque se aprovecha del parámetro "http://copilot.microsoft.com/?q=" que permite inyectar un Prompt en una URL de Microsoft Copilot, lo que permite hacer Spear Phishing sin necesidad siquiera de que la víctima invoque un Prompt de Copilot, y una vez que se ha hecho clic, el resto es todo automático.

Figura 2: Repromt Attack

Es decir, que un solo clic, y se acabó. Esto puede hacerse también en otro tipo de Client-Side Attacks que hagan al usuario navegar con sus credenciales a la URL que desea el atacante, así que navegar con la sesión de Microsoft Copilot, y se acabó.

Figura 3: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

Una vez encontrado el punto de inyección de Prompts en Copilot - mediante un Spear Phishing, por ejemplo, el truco de Repromt se basa en pedirle a Microsoft Copilot que haga lo que haga, lo haga dos veces porque la primera vez, el modelo se niega a navegar a una URL remota, pero pidiéndoselo que lo haga dos veces lo hace.

Figura 4: Spear Phishing con Link a Copilot para hacer un Reprompt Attack

Este comportamiento puede ser por motivos de rendimiento, por asistir al usuario, y por resolver correctamente el Prompt que se le pide, pero lo cierto es que en las PoC publicadas es como lo hacen.

Figura 5: Ataque de Exfiltración de Memory con Reprompt

En la primera PoC, que es una exfiltración de un dato secreto en la Memory de Copilot, se le pide que construya una URL como si fuera un juego, pero dentro de ella debe incluir la información secreta de la memoria del usuario, así como el nombre de la víctima.

Figura 6: Valor a exfilrar de la Memory

El proceso completo comienza con el clic en el correo de Spear Phishing que lleva a la ejecución del Prompt en Microsoft Copilot y la exfiltración de los datos en el Log del servidor web controlado por el atacante que se usa para sacar la información privada.

Figura 7: Valor exfilrado en el log del servidor del atacante

En el vídeo que tenéis aquí podéis ver el ataque completo en menos de un minuto, que es lo que se tarda en hacer un clic y que tus datos privados se haya exfiltrado.

Figura 8: PoC 1 de Reprompt Attack en MS Copilot

Este ataque se puede complejizar mucho más, y en cada petición, encadenar un nuevo Prompt para exfiltrar datos usando técnicas de Prompt Injection camuflando los nuevos Prompts dentro de formatos de imágenes JPG que son entregadas como texto, de tal manera que cada vez que se pide una imagen, se le da un nuevo Prompt.

Figura. 9: Encadenado de Prompt Injection

Usando esta técnica, la PoC 2 realiza la exfiltración del nombre del usuario, la localización, el último Prompt, la fecha, etcétera, encadenando una petición con otra usando fases de explotación diferente. 

Figura 10: Exfiltración encadenada 

Las salidas de todas esas exfiltraciones acaban quedando en el log del servidor controlado por el atacante, como podéis ver en las imágenes, y en el vídeo siguiente.

Figura 11: PoC 2 de Reprompt Attack en MS Copilot

Microsoft ya ha puesto salvaguardas para evitar que este ataque se pueda reproducir, pero abre una nueva vía de ataques que hay que tener presente en la implementación de servicios digitales que puedan ser explotados con Prompts en parámetros, además del truco de "hazlo dos veces".

Figura 12: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Adulteración del Knowledge Graph de una arquitectura RAG para proteger los datos de un servicio de Inteligencia Artificial

Las arquitecturas RAG (Retrieval Augmented Generation) son hoy en día una de las formas más sencillas de conectar el conocimiento de una organización con un modelo LLM para explotar los datos de una organización utilizando servicios digitales basados en IA. En el caso de las plataformas Microsoft, se utilizan los Knowledge Graph (KG) que llevan tantos años desarrollando, así que a los servicios que usan una arquitectura RAG con un KG se le llama GraphRAG, y están conectados al conocimiento de una persona o una empresa.

Figura 1: Adulteración del Knowledge Graph de una arquitectura

RAG para proteger los datos de un servicio de Inteligencia Artificial

Este conocimiento almacenado en los Knowledge Graphs le dan el contexto necesario a los LLM para que puedan resolver los Prompts que se les solicita de manera efectiva, y es como funciona, por ejemplo, la arquitectura de Microsoft 365 Copilot.

Figura 2: Arquitectura con Knowledge Graph de Microsoft 365 Copilot

Por supuesto, si ese Knowledge Graph no son los datos de un usuario, sino los datos de una compañía completa, estaríamos hablando de información muy sensible de las empresas, por lo que hay que tener mucho cuidado de que alguien robe esos datos, pero aún más. Una forma de atacarlos es lo que explicamos en el artículo de "GenAI Apps & Services: Cómo explotar arquitecturas RAG con Plugins Inseguros" del que también hablé en esta conferencia:

Figura 3: Hacker & Developer in the Age of GenAIpor Chema Alonso en la dotNET 2024

Pero, suponiendo que alguien se lleva directamente una copia completa, ¿podríamos hacer que si un atacante tuviera acceso al Knoledge Graph de una arquitectura RAG como la anterior sólo recibiera información errónea en las respuetsas? De eso trata el artículo: "Making Theft Useless: Adulteration-Based Protection of Proprietary Knowledge Graphs in GraphRAG Systems"

Figura 4:Making Theft Useless: Adulteration-Based Protection

of Proprietary Knowledge Graphs in GraphRAG Systems

Hay que tener en cuenta que si un atacante se llevara el Knowledge Graph (KG) de una empresa, necesitaría muy poco para replicar el funcionamiento del servicio digital basado en la arquitectura GraphRAG robada, ya que casi todos se basan en piezas comunes, donde lo diferencial son los datos contenidos en el Knowledge Graph de la compañía, que además lleva tiempo generar.

Figura 5: Si un atacante roba el Knowledge Graph (K)

puede replicar el servicio y usar los datos del KG

Una vez clonada la arquitectura, se podría acceder al conocimiento y la información que el Knowledge Graph contenga, haciéndole las preguntas correctas, así que los investigadores lo que han estado pensando es en cómo hacer que esa base de conocimiento esté adulterada y solo los que lo han adulterado sepan entender las respuestas, mientras que para los demás será respuestas llenas de alucinaciones.

Figura 6: La propuesta es Adulterar el Knowledge Graph.

Como se puede ver en la imagen anterior, la propuesta del trabajo es Adulterar el Knowledge Graph de forma que sólo los usuarios legítimos saben cómo está adulterado, y por tanto, "desadulterar" la información proveniente del KG antes de que esta sea enviada por el servicio RAG (GraphRAG) al LLM.

Hay que tener en cuenta que el motivo por el que se crean las arquitecturas RAG es para que los LLM trabajen sobre el conocimiento privado de unos datos. Si esos datos están adulterados, trabajaran sobre información errónea. Así, los usuarios no autorizados, si no saben quitar los nodos adulteraros en el KG, lo que conseguirán es que el Prompt que se genere para el LLM del servicio no funcione y retorne información errónea, o directamente el LLM no sepa como responder.

Para ello, el proceso de adulteración busca cuáles son los nodos más clave del Knowledge Graph (Key Nodes), para conseguir que esos nodos estén presentes en el mayor número de respuestas de enriquecimiento de Prompts provenientes del KG y que tengan información adulterada para que sirvan ellos de adulterantes de todas las repuestas.

Figura 7: Prompt for Generating Nodos Adulterantes

Esos Key Nodes serán analizados y adulterados, por ejemplo, con valores que sean de la misma entidad, pero con valores diferentes semánticamente, como se ve en el Prompt de generación de nodos adulterantes de la imagen anterior. Este proceso podrá hacerse con diferentes nodos, y los cambios deben ser conocidos por los usuarios legítimos.

Figura 8: Proceso de Adulteración de Key Nodes

El framework se llama AURA

Como se ve en la imagen anterior, se buscan los módulos más relevantes, intentando que se consiga que corrompan el máximo posible de las respuestas. Eso implicará que haya que generar adulteraciones para cada uno de esos nodos adulterantes, pero el GraphRAG envíe el Prompt original enriquecido con datos que contiene alguno de los nodos adulterantes, entonces se conseguirán respuestas parciales, con alucinaciones o directamente no se obtendrá respuesta.

Figura 9: Resultados experimentales

En la tabla anterior tienes el HS "Harmfulness Score", que es el porcentaje de Prompts que antes de la adulteración eran contestados correctamente y después del adulterado de los nodos se contestan mal o no se contestan. Como se puede ver, con diferentes Datasets de prueba usando diferentes LLMs, los resultados son todos superiores al 94%.

El segundo indicador es el ARR "Adulterant Retrieval Rate", o lo que es lo mismo, en qué porcentaje de los Prompts se han incluido los nodos adulterantes. En este caso, en el 100% de los casos, ya que el algoritmo de selección de Key Nodes ha cubierto la totalidad de las rutas de respuestas.

Figura 10: Tipos de error inyectados con la adulteracíon

En el paper tenéis más tablas y mediciones, pero yo me he querido centrar solo en las que he considerado más relevantes para entender el estudio, y éste último gráfico representa los porcentajes de respuestas erróneas parcialmente, completamente, o que directamente el modelo LLM se ha negado a contestar.

El truco, para que el servicio digital legítimo sepa cuáles son los nodos adulterantes que debe eliminar antes de enviar el Prompt enriquecido con Nodos del Knoledge Graph, es que en el proceso de adulteración se marcan todos los nodos con metadatos cifrados, de tal manera que, como se ve en el apartado 4 de la Figura 8, si el metadato cifrado - con la clave de descifrado que solo tiene el servicio legítimo - dice que es un nodo adulterante, se retira y listo.

Figura 11: Marcado de nodos con metadatos cifrados

De esta forma, se evita tener que cifrar todo el Knowledge Graph - que lo haría computacionalmente inviable a día de hoy, y solo se cifran las marcas de aduletración -. Un tema muy interesante, sin duda, y si te gusta este mundo, te recomiendo que te compres el libro de "Hacking & Pentesting con Inteligencia Artificial" que te va a encantar.

Figura 12: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso,

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)