Problema 5054

La proliferación de la IA ha introducido rápidamente muchas nuevas tecnologías de software, cada una con sus propias configuraciones erróneas que pueden comprometer la seguridad de la información. De ahí la misión de UpGuard Research: descubrir los vectores específicos de una nueva tecnología y medir su ciberriesgo.

Esta investigación analiza llama.cpp, un framework de código abierto para el uso de grandes modelos de lenguaje (LLM). Llama.cpp tiene el potencial de filtrar mensajes de usuario, pero debido a la escasa disponibilidad de servidores llama.cpp, el riesgo absoluto de una filtración debido a llama.cpp es bajo.

Sin embargo, al examinar los datos de los mensajes expuestos por servidores llama.cpp con poca seguridad, encontramos dos direcciones IP que generaban texto para juegos de rol sexualmente explícitos con personajes menores de edad. Si bien nuestro propósito al realizar esta investigación era comprender el riesgo asociado con los servidores llama.cpp expuestos, los datos particulares expuestos abordan algunas de las preocupaciones de seguridad más urgentes asociadas con la IA generativa.

¿Qué es llama.cpp?

Llama.cpp es un proyecto de código abierto para la “Inferencia del modelo LLaMA de Meta (y otros) en C/C++ puro”. En términos no técnicos, llama.cpp es software libre que facilita la ejecución de modelos de IA gratuitos. Los productos de IA más conocidos, como ChatGPT de OpenAI, Claude de Anthropic o Gemini de Google, utilizan modelos propietarios a los que se accede a través de una aplicación creada por el propietario (como la que se ve en chatgpt.com) o mediante API que proporcionan acceso de pago a los modelos. Pero también existen muchos modelos de lenguaje extensos, gratuitos y de código abierto, que los usuarios pueden descargar, modificar y ejecutar en sus propios entornos. Llama es una familia de modelos abiertos publicada por Meta y la razón por la que tanto software relacionado con IA incluye la palabra "llama" en su nombre. Proyectos como llama.cpp u Ollama proporcionan la interfaz para usar estos modelos.

Llama.cpp puede configurarse como un servidor HTTP con API que permiten a los usuarios remotos interactuar con llama.cpp. Si llama.cpp se configura para ejecutar un servidor y expone su interfaz a la internet pública, los usuarios remotos anónimos pueden detectar el servidor llama.cpp e interactuar con él. En general, no es buena idea exponer las API a internet a menos que estén realmente destinadas al acceso universal. Sin embargo, dado que llama.cpp es un software gratuito y abierto, es comúnmente utilizado por aficionados que no se preocupan por la seguridad de la información de una aplicación de juguete en su laboratorio personal.

Estas dos características (las API HTTP, que pueden hacerse públicas y ser utilizadas comúnmente por personas ajenas al gobierno corporativo), aumentan la probabilidad de que los usuarios configuren servidores llama.cpp con configuraciones poco seguras.

Riesgos de las API de llama.cpp expuestas

Para estudiar la prevalencia real de estos riesgos, utilizamos dos API GET de llama.cpp: `/props` y `/slots`. Llama.cpp también proporciona varias API POST que no intentamos utilizar debido a la posibilidad de interrumpir las operaciones del servidor. Para una auditoría de seguridad completa de una aplicación que utiliza llama.cpp, también debe asegurarse de que estas API POST no se puedan utilizar de forma abusiva.

El punto final /props proporciona metadatos sobre los parámetros del modelo. Esto es similar a los datos que las API de Ollama suelen exponer. Los puntos finales v1/models y /health proporcionan los mismos datos, accesibles a través de /props, separados para su compatibilidad con OpenAI o para simplificar la comprobación del estado, respectivamente. Dado que proporcionan datos redundantes, no nos molestamos en llamar a estos puntos finales.

El punto final /slots proporciona el texto real de las indicaciones junto con metadatos sobre su generación. Si /slots está habilitado y es accesible sin autenticación, los usuarios anónimos pueden leer los mensajes enviados al modelo. Si alguien utiliza el modelo de cualquier forma, no es recomendable exponer sus entradas. La documentación de llama.cpp incluye esta advertencia sobre /slots: "Este punto final está diseñado para la depuración y puede modificarse en futuras versiones. Por razones de seguridad, recomendamos encarecidamente no habilitarlo en entornos de producción". ¡Buen consejo, equipo de llama.cpp!

Prevalencia y distribución general de llama.cpp

Lo primero que hay que tener en cuenta es que hay un número relativamente pequeño de servidores llama.cpp expuestos en todo el mundo: solo unos 400 en cualquier momento durante nuestra investigación en marzo de 2025. En comparación, el número de servidores Ollama expuestos ronda actualmente los 20 000, casi el triple que hace dos meses. Sin embargo, la posibilidad de que usuarios anónimos lean las indicaciones de los servidores llama.cpp los hace potencialmente más impactantes y requieren menos esfuerzo para su explotación.

Geográficamente, los servidores llama.cpp se concentran en EE. UU., con Alemania y China claramente en segundo lugar. Comparando la distribución de los servidores llama.cpp con la de Ollama, llama.cpp es proporcionalmente menos común en China y más común en Alemania. Al igual que con Ollama, las organizaciones propietarias de las direcciones IP son dispersas, lo que indica que se trata de usuarios aficionados en lugar de implementaciones corporativas que tienden a agruparse en los principales proveedores de nube como AWS, Azure y Google.

Distribución de los endpoints /slots y /props

Dado que /slots expone información más sensible que `/props` (y se advierte explícitamente contra ello en la documentación), esperábamos encontrar muchas menos instancias de /slots que de /props. Si bien este fue el caso, el número de instancias de llama.cpp que expusieron sus datos de solicitud fue mayor de lo esperado: aproximadamente un tercio de todos los servidores.

Por el contrario, el número de instancias que expusieron propiedades del sistema (poco más de la mitad) es relativamente bajo en comparación con las miles de IP que expusieron datos similares a través de las API de Ollama.

¿Qué contienen las solicitudes?

De las 117 direcciones IP que expusieron sus solicitudes, muy pocas se considerarían de uso "en producción". Cincuenta servidores mostraron la última solicitud como pregunta predeterminada para probar LLM: "¿Cómo afecta el principio de incertidumbre al comportamiento de las partículas?". Cuarenta y cuatro no tenían ninguna indicación grabada. Un puñado contenía análisis repetitivos de vulnerabilidades de software, indicaciones idénticas para crear cuestionarios de opción múltiple o documentos públicos (evidencia de pruebas del modelo, pero no información confidencial, y sin uso continuo).

Los servidores de llama con, por mucho, las indicaciones más largas (aquellos cuyo contenido podría indicar un uso "en producción") eran tres chatbots con indicaciones para juegos de rol eróticos elaborados y de larga duración. Cada una de esas IP únicas usaba un modelo diferente (Midnight-Rose-70B, Magnum-72b y L3.3-Nevoria-R1-70b), lo que indica que probablemente se trataba de proyectos separados que, casualmente, compartían una función similar.

Dos de esas IP se actualizaban frecuentemente con nuevas indicaciones de diferentes escenarios o personajes. Para medir su actividad, recopilamos las indicaciones en esas IP desde /slots una vez por minuto durante 24 horas. Utilizando un hash del texto de la indicación, deduplicamos las indicaciones para un total de 952 mensajes únicos en ese período, o alrededor de 40 indicaciones por hora. No enviamos ni interactuamos con la interfaz de indicaciones, solo observamos las indicaciones expuestas públicamente, accesibles mediante escaneo pasivo.

Tras revisar los datos, la principal preocupación fue que parte del contenido creado por los LLM describía a niños (ficticios) de entre 7 y 12 años manteniendo relaciones sexuales.

Para contabilizar el número de escenarios únicos, cortamos los primeros 100 caracteres de cada mensaje para obtener una muestra representativa de la indicación del sistema para cada escenario. Este método identificó 108 indicaciones del sistema o escenarios narrativos únicos. El escenario con el chat más largo tuvo 150 mensajes en un período de 24 horas. De los 108 escenarios, cinco involucraban a niños.

Si bien este contenido no involucra a niños reales, la prevalencia de CSAM generado por IA, incluso en una pequeña porción de estos datos, muestra cuánto han reducido las LLM la barrera de entrada para generar dicho contenido. Además, el contenido no es solo texto estático, sino un juego de rol interactivo de CSAM basado en texto, algo repulsivo, si no ilegal, y cuya creación es muy sencilla gracias a la tecnología LLM. De hecho, ya existen numerosos sitios que funcionan como plataformas para que los usuarios creen "personajes" para juegos de rol "sin censura" en cientos de miles de escenarios.

Conclusión

Los equipos de seguridad de la información deben ser conscientes de que llama.cpp es una tecnología que puede configurarse incorrectamente y exponer datos confidenciales. El análisis de riesgos cibernéticos de UpGuard detecta las direcciones IP que ejecutan llama.cpp para evitar filtraciones de datos de terceros. Al usar llama.cpp, los implementadores deben estar familiarizados con las pautas de configuración segura, especialmente al no habilitar el endpoint /slots. En esta encuesta, no detectamos ninguna exposición de datos corporativos, pero el potencial existe, y los programas de seguridad informática deberían seguir monitoreando este tipo de eventos.

Los detalles de los datos accesibles a través de las API de llama.cpp no son especialmente relevantes para los equipos de seguridad de la información corporativa, pero son aplicables al debate más amplio sobre la seguridad de la IA. La observación empírica de la ejecución de LLM mediante encuestas de investigación formará parte del proyecto continuo para comprender el impacto de la IA en la sociedad y las medidas de protección necesarias.