Esta semana se ha publicado un estudio sobre cómo robar las API Keys de las plataformas de LLM como Anthropic, OpenAI o Gemini, desde las apps - en este estudio - publicadas para iPhone e iPad en AppStore, pero el funcionamiento es similar para las apps de Android, así que si estás usando servicios de LLM en tus apps y has introducido unas API Keys en tu app, toma nota.
El objetivo del estudio es ver cuánto de fácil es
hackear un servio digital basado en servicios de inteligencia artificial para robarle las
API Keys, o para lograr utilizarlas a través de un servicio
Proxy LLM mal configurado. Es decir, un poco de
Hacking de IA.
Al final, lo que han hecho es identificar primero apps con capacidades LLM - asistentes, funciones de chatbot, etcétera - que han sido un total de 444 aplicaciones. Esas son las que se han descargado para ver si podían extraer las API Keys o acceder a un servidor que hiciera de Proxy LLM.
Después, metiéndola en un dispositivo con Jailbreak, hacer una manipulación introduciendo un Proxy para hacer Mitm con un certificado metido en el terminal para confiar en los certificados falsos que se crean on-the-fly para suplantar al backend del servicio digital, o el backend de los proveedores de LLM.
Éste es un proceso de
mitm de libro, donde sólo te vas a salvar si la aplicación está haciendo uso de técnicas de
Certificate Pinning para asegurarse de que no se manipula la conexión, o si existe un proceso de autenticación robusta entre en la
app y el servicio
Proxy LLM. Si no es así, las
API Keys caerán.
Como podéis ver en la tabla anterior, se estudian tres formas de hacerse con las claves de manera diferentes. La primera es para entornos donde las API Keys están en el código y la app la envía al Proxy malicioso que hace mitm.
Esta es la más peligrosa, porque al final se filtra la API KEY del backend del LLM. En los otros casos tenemos un Proxy LLM que autentica - o no -la petición del cliente y enruta - protegiendo el API KEY - hacia el backend del LLM. En este caso, utilizando una autenticación con JWT (Json Web Token), que tienen otro tipo de problemas.
El primero de los problemas es el que vemos anteriormente, donde no existe ninguna autenticación, con lo que con capturar la petición, se tiene un servicio que gestiona las API Keys para hacer las llamadas al backend del LLM sin ningún control.
Esto es un problema no sólo de consumo de tokens - que también - sino también de envenenamiento de sesiones, robo de información de la misma sesión, etcétera. Es decir un problema dejar abierto tu Proxy LLM a cualquiera que pase por allí.
Claro, si lo que tenemos es un JWT (Json Web Token), pero éste es estático y no tiene caducidad, pues entonces tendríamos el mismo problema.
Estos tokens deberían negociarse en un proceso seguro de autenticación contra el Proxy LLM y tener un periodo de vida limitado.
Si tu proceso de autenticación es inexistente, los JWT tienen un periodo de duración muy largo o si se aceptan JWT sin comprobar si están caducados, entonces el sistema es igual de inseguro.
Y por supuesto, si el JWT sigue funcionando aunque esté caducado porque no se comprueba en el Proxy LLM, entonces es como si no hubiera ninguna protección válida.
La solución, pues utilizar un Proxy LLM con autenticación robusta, JWT con periodo de vida razonable y Certificate Pinning para verificar el certificado del servidor. No obstante, el uso de Certificate Pinning está siendo una práctica cada vez menos extendida debido a los problemas que a veces acarrea. Pero... de lo contrario esto es lo que pasa.
¡Saludos Malignos!
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
