Cuando las GPT personalizadas se convierten en puertas traseras en la nube: El pirateo de ChatGPT SSRF y el futuro de la seguridad de la IA

Si te dedicas a la seguridad el tiempo suficiente, acabas desarrollando un mal hábito: dejas de ver "características" y empiezas a ver posibles vías de ataque. La reciente historia sobre "ChatGPT hackeado usando Custom GPTs explotando una vulnerabilidad SSRF para exponer secretos" es un ejemplo de libro de texto. Lo que parecía una práctica función de acciones para las GPT personalizadas resultó ser un túnel directo al entorno en la nube de OpenAI. Nada de magia exótica, nada de "magia de IA" que haya salido mal, sólo un error muy antiguo, la falsificación de peticiones del lado del servidor, redescubierta en una plataforma muy nueva.

Precisamente por eso es importante este incidente. No se trata de otro titular exagerado sobre la IA que se vuelve rebelde. Es un recordatorio de que una vez que se integran los LLM en la infraestructura real, las reglas tradicionales de seguridad de las aplicaciones y la nube vuelven con fuerza. Los modelos pueden ser nuevos, pero los errores subyacentes no.

Reconstrucción del exploit: de "Añadir acción" al token en la nube

Para entender lo que ha pasado, hay que ver cómo funcionan las GPT personalizadas. La interfaz de OpenAI le permite definir acciones, que son esencialmente API HTTP externas a las que su GPT puede llamar basándose en un esquema OpenAPI. Para los usuarios, esto es como dar a su GPT "superpoderes": puede obtener datos, desencadenar flujos de trabajo, conectarse a sistemas internos. Bajo el capó, esto significa que hay un cliente HTTP backend, que se ejecuta dentro de la infraestructura de OpenAI, que felizmente llamará URLs que usted describa y alimentará las respuestas de nuevo en el modelo.

Un investigador de Open Security se dio cuenta exactamente de eso. Mientras jugaban con Custom GPTs, vieron el patrón familiar: URLs controladas por el usuario, un botón "Test" que envía peticiones en vivo, y un servidor que claramente se ejecuta dentro de un entorno de nube. Cualquiera que haya hecho pen-testing en la nube reconocerá el instinto que sigue: comprueba si puedes engañar a ese servidor para que llame a direcciones internas en tu nombre. Esa es la esencia de SSRF.

En los entornos en nube, el objetivo interno más preciado es casi siempre el servicio de metadatos. En Azure, como en otras nubes, vive en la dirección link-local 169.254.169.254. Desde el interior de una máquina virtual o contenedor, este punto final puede revelar detalles sobre la instancia y, lo que es más importante, emitir tokens de corta duración que permiten a las cargas de trabajo llamar a las API de gestión de la nube. Desde fuera de la nube, no se puede acceder a él. Precisamente por eso es tan importante la SSRF: secuestras el punto de vista del servidor y le obligas a hablar con cosas con las que tú, como atacante externo, no puedes.

El primer obstáculo del investigador fue que Custom GPT Actions sólo permitía URL HTTPS, mientras que el servicio de metadatos es sólo HTTP. A primera vista, esta restricción parece una defensa, pero en la práctica no es más que una pieza más del rompecabezas. La solución era sencilla: registrar un dominio HTTPS externo bajo el control del investigador, hacer que responda con una redirección 302 que apunte a la URL del servicio de metadatos. http://169.254.169.254 y ver si el backend de Acciones ha seguido la redirección. Y así fue. De repente, una llamada HTTPS de aspecto inocente en la configuración de GPT personalizada resultó en una llamada HTTP al punto final de metadatos de la nube interna.

Sin embargo, el servicio de metadatos de Azure no es completamente ingenuo. Para evitar abusos casuales, exige una cabecera especial, Metadatos: trueen cada solicitud. Si falta la cabecera, el servicio se niega a revelar datos reales. En este punto podría parecer que el sistema vuelve a estar seguro, porque la interfaz del esquema OpenAPI utilizada para definir las Acciones no expone una configuración arbitraria de las cabeceras. Pero los grandes sistemas rara vez tienen una única superficie de configuración. En este caso, la función Acciones también soporta la idea de "claves API" y otras cabeceras de autenticación que puedes definir al cablear un servicio externo. Estas cabeceras se adjuntan automáticamente a las peticiones salientes.

Eso fue suficiente para completar la cadena. Definiendo una "clave API" falsa cuyo nombre de cabecera era literalmente Metadatos y cuyo valor era verdaderoEl investigador convenció al backend para que incluyera el encabezado exacto que Azure IMDS espera. Combine eso con el truco de redirección y ahora tiene un canal SSRF desde el backend Custom GPT Actions al servicio de metadatos, con una cabecera válida. Metadatos: true de cabeza.

Una vez establecido este canal, el resto fue casi mecánico. El investigador solicitó al servicio de metadatos un token OAuth2 destinado a la API de gestión de Azure, utilizando la conocida ruta IMDS. La respuesta contenía un token de acceso vinculado a la identidad en la nube que utilizaba la infraestructura ChatGPT. Ese token podía, como mínimo, consultar puntos finales de gestión y potencialmente llegar a recursos sensibles, dependiendo de cuántos privilegios tuviera la identidad. En ese momento, el investigador se detuvo, informó de los hallazgos a través del programa de recompensas por fallos de OpenAI, y OpenAI clasificó el fallo como de alta gravedad y procedió a parchearlo.

Lo que hace llamativa a esta cadena es que el atacante nunca necesitó acceso shell, código fuente ni ningún fallo clásico en la pila HTTP. Todo ocurrió dentro de pantallas de configuración normales: URLs, ajustes de autenticación y un botón de prueba que ejecutaba obedientemente la travesura.

Un pequeño boceto de código de una sonda estilo SSRF

Para hacer esto más concreto, imagina un pequeño script de ayuda interno que un ingeniero de seguridad podría utilizar para comprobar la sanidad de un cliente HTTP "estilo Acciones". El objetivo no es atacar servicios de metadatos reales en producción, sino codificar el hábito de sondear redirecciones inesperadas y saltos de IP internos en entornos de ensayo o laboratorio:

importar peticiones
from urllib.parse import urljoin

def trace_request(url_base: str, ruta: str = "/"):
    url = urljoin(url_base, ruta)
    print(f"[+] Solicitando {url}")
    intente:
        resp = requests.get(url, timeout=3, allow_redirects=True)
    except Exception as e:
        print(f"[!] Error: {e}")
        return

    print(f"[+] URL final: {resp.url}")
    print(f"[+] Estado: {resp.status_code}")
    print("[+] Cadena de redireccionamiento:")
    para h en resp.historial:
        print(f" {h.status_code} -> {h.headers.get('Location')}")

    # Heurística muy aproximada: avisar si alguna vez aterrizamos en una IP interna
    if resp.raw._connection and hasattr(resp.raw._connection, "sock"):
        peer = resp.raw._connection.sock.getpeername()[0]
        print(f"[+] IP del par: {par}")
        if peer.startswith("10.") or peer.startswith("192.168.") or peer.startswith("169.254."):
            print("[!] Advertencia: el backend ha seguido una redirección a una dirección interna")

if __name__ == "__main__":
    # Ejemplo: sustitúyalo por un endpoint de prueba controlado en su propio laboratorio
    trace_request("")

Un script como este no "explota ChatGPT", pero captura la misma forma de investigación: empezar desde una URL externa supuestamente segura, seguir las redirecciones y quejarse en voz alta si su cliente HTTP se encuentra de repente hablando con rangos de IP internos o de enlace local. Convertir ese patrón en automatización -y ejecutarlo contra los componentes que potencian sus propias acciones de IA- es mucho más útil que limitarse a leer sobre el incidente.

No se trata de un "error de la IA", sino del abuso de la nube de la vieja escuela en un nuevo escenario.

Es muy tentador leer esto como "ChatGPT fue hackeado" y seguir adelante. Ese encuadre pierde la lección más profunda. Nada en el modelo en sí se comportó mal. No hubo ningún aviso que de alguna manera desbloqueara capacidades prohibidas. El LLM hizo lo que se le dijo: llamar a una acción, leer el resultado y resumirlo. La vulnerabilidad vivía enteramente en el pegamento entre el LLM y el mundo exterior.

Ese pegamento es exactamente donde los equipos de seguridad necesitan mover su enfoque. Cada vez que le das a un LLM la capacidad de llamar a herramientas, Acciones o plugins, lo estás convirtiendo efectivamente en un cliente programable en tu infraestructura. En el pasado, un usuario llamaba manualmente a su API y usted revisaba su entrada. Ahora, un usuario da instrucciones a un modelo, y el modelo lo traduce en llamadas a la API en su nombre. El modelo se convierte en otra forma de que la intención hostil llegue a su backend.

Visto a través de esa lente, este incidente es simplemente OWASP SSRF con un disfraz diferente. Las condiciones son todas familiares: URLs influenciadas por el usuario, un servidor que puede alcanzar endpoints internos o privilegiados, controles de salida ausentes o incompletos, y un servicio de metadatos en la nube que es demasiado accesible desde cargas de trabajo regulares. La diferencia es que el punto de entrada ya no es un formulario web clásico o un campo JSON; es un bloque de configuración diseñado para hacer que los GPT personalizados sean más potentes.

Por eso también es importante el radio de la explosión. El servidor afectado no era un microservicio aleatorio; formaba parte de la infraestructura multiusuario de ChatGPT, dentro del entorno Azure de OpenAI. Cualquier token obtenido a través de IMDS pertenecía a una carga de trabajo que ya tenía un acceso significativo. Incluso si las defensas locales limitaban lo que el atacante podía hacer, el perfil de riesgo es fundamentalmente diferente del de una máquina virtual de prueba olvidada.

La IA como centro de integración: ampliar las superficies de ataque y desplazar los límites de la confianza

La historia más interesante detrás de este fallo es arquitectónica. Las plataformas de IA se están convirtiendo rápidamente en centros de integración. Una GPT personalizada para un equipo de ventas puede comunicarse con un CRM, un sistema de facturación y un almacén de documentos. Una GPT centrada en la seguridad podría hablar con escáneres, sistemas de tickets y CI/CD. En cada caso, el LLM no es el activo; lo son los datos y las acciones que hay detrás de esos conectores.

Una vez que aceptas esa realidad, tu modelo mental de amenaza tiene que cambiar. No puedes seguir pensando que la "seguridad de la IA" se limita a la inyección puntual, la fuga de datos o los resultados tóxicos. También hay que plantearse cuestiones poco glamurosas sobre los límites de la red, la identidad en la nube y el aislamiento de los inquilinos.

¿Con qué puede hablar realmente en la red la infraestructura que ejecuta sus Acciones? Por defecto, en muchos entornos de nube se permite "cualquier salida siempre que se resuelva DNS". Eso tenía sentido cuando los servicios eran relativamente sencillos y los ingenieros querían flexibilidad. Sin embargo, si se pone una plataforma LLM en medio, de repente todos los inquilinos tienen una forma de proponer nuevos destinos salientes a través de la configuración, en lugar del código. Si no existe una política de salida sólida, se habrá creado un lanzador SSRF programable.

¿Cuántos privilegios tienen realmente las identidades utilizadas por estas cargas de trabajo? En el caso de ChatGPT, los investigadores pudieron solicitar un token para la API de gestión de Azure. Incluso si ese token estaba limitado por la asignación de roles, sigue representando un secreto de alto valor. En muchas organizaciones, la tentación de dar amplios permisos a la "infraestructura de plataforma" es fuerte, porque simplifica el despliegue. Para cualquier cosa que pueda ser controlada indirectamente por el usuario, especialmente a través de la IA, esta tentación es peligrosa.

¿Dónde están exactamente los límites de confianza entre los inquilinos, entre el plano de control y el plano de datos, y entre el tiempo de ejecución de la IA y el resto de la nube? Un sistema bien diseñado debería asumir que la configuración de cualquier inquilino podría convertirse en adversaria, que cualquier llamada saliente en nombre de ese inquilino podría ser hostil, y que cualquier elevación desde la acción a los metadatos y a las API de gestión es un objetivo realista del atacante. Esta perspectiva hace que patrones como la segmentación estricta de la red, los sidecars complementarios que aplican políticas y las identidades de servicio dedicadas no sean negociables en lugar de "agradables de tener".

De un incidente a una metodología de ensayo repetible

Para los defensores y constructores, el valor real de esta historia no es el fallo específico, sino la mentalidad de prueba que ilustra. En esencia, el investigador trató las Custom GPT Actions como un nuevo y extraño tipo de cliente HTTP y luego pasó por una lista de comprobación familiar: ¿puedo controlar la URL, puedo llegar a hosts internos, puedo abusar de las redirecciones, puedo inyectar cabeceras, puedo golpear metadatos, puedo convertir eso en un token de nube?

Esa lista de comprobación mental es exactamente lo que debería automatizarse dentro de los flujos de trabajo modernos de pruebas de penetración para plataformas de IA. En lugar de esperar un titular y un informe de recompensa, los equipos deberían convertir rutinariamente su propia infraestructura GPT personalizada, ecosistemas de plugins y cadenas de herramientas en objetivos.

Para hacerlo un poco más tangible, se puede pensar en una "revisión del SSRF de las acciones de la IA" como una secuencia simple y repetible como ésta:

Una vez que tenga este tipo de tabla escrita para su entorno, será mucho más fácil automatizar y explicar las pruebas que realice. Puedes incluirla en los libros de jugadas internos, compartirla con los proveedores y asegurarte de que las futuras funciones de IA se ajusten al mismo estándar.

Aquí es donde las herramientas de seguridad especializadas y conscientes de la IA empiezan a ser importantes. Un escáner web genérico podría no saber cómo navegar por una interfaz de usuario que oculta llamadas de red detrás de acciones o cómo razonar sobre esquemas OpenAPI utilizados dentro de una definición GPT. En cambio, una plataforma de pentest basada en IA como Penligent puede tratar esos esquemas y configuraciones como entradas de primera clase. Puede imaginarse un flujo de trabajo en el que exporte la configuración de acciones para un conjunto de GPT personalizadas u otras herramientas de IA, las introduzca en una canalización de pruebas agénticas y deje que examine sistemáticamente las condiciones SSRF, las redirecciones no seguras, el acceso a la red sin límites y la exposición de metadatos.

La filosofía de Penligent de combinar la automatización con el control humano se ajusta bien a este patrón. Un agente puede enumerar todas las definiciones de herramientas, generar cargas útiles candidatas para puntos finales que acepten URL o nombres de host, y dirigir tráfico de secuencias de comandos que simule lo que intentaría un atacante curioso. Una vez que el sistema descubre un comportamiento prometedor -por ejemplo, que un punto final HTTPS aparentemente externo sigue redireccionamientos a rangos de IP internos- puede mostrarlo como prueba: registros de solicitudes, fragmentos de respuestas y topología interna inferida. Un operador humano puede entonces dirigir los siguientes pasos, por ejemplo, pidiendo al sistema que se dirija específicamente a las rutas de metadatos de la nube o que verifique si los tokens devueltos son válidos para las API de gestión.

Este tipo de flujo de trabajo consigue dos cosas. Introduce las plataformas de IA en el mismo bucle de seguridad basado en pruebas del que ya disfrutan las aplicaciones web y las API, y aprovecha las mismas capacidades LLM que los atacantes utilizarán inevitablemente, pero al servicio de los defensores. El error que afectó a ChatGPT ya no es una sorpresa puntual; se convierte en un caso de prueba en un conjunto de regresión que puede ejecutar cada vez que introduzca una nueva integración o cambie su infraestructura de Acciones.

Lecciones prácticas para los equipos que construyen sobre plataformas de IA

Si eres un ingeniero o arquitecto de seguridad que consume servicios de IA en lugar de construirlos, este incidente sigue siendo muy relevante. Incluso si nunca tocas GPTs personalizadas internamente, probablemente expones APIs internas, cuadros de mando o almacenes de documentos a agentes de IA o copilotos de algún tipo. Las ideas son transferibles.

El primer paso es dejar de tratar el LLM como lo único que necesita una revisión de seguridad. Cualquier característica que permita a los modelos volver a llamar a su entorno, ya sea a través de herramientas explícitas, acciones o webhooks indirectos, debe considerarse como un posible gráfico de ataque. Deberías ser capaz de responder, con cierta confianza, con qué servicios internos puede hablar un componente de IA, qué identidades utiliza y qué ocurre si un usuario hostil intenta deliberadamente estirar esas capacidades.

El segundo paso consiste en ampliar sus programas de pruebas para que abarquen el código cola de la IA. Cuando encargue una prueba de penetración o realice un ejercicio interno de equipo rojo, asegúrese de que el alcance incluye explícitamente las integraciones de IA: las superficies de configuración de las herramientas, la forma en que se construyen las URL y las cabeceras, las rutas de red entre los tiempos de ejecución de IA y los servicios sensibles, y las protecciones en torno a los puntos finales de metadatos. Pida pruebas de que alguien, en algún lugar, intentó abusar de estos elementos como lo haría un atacante real.

El tercer paso es aceptar que esta superficie de ataque no se reducirá. A medida que más procesos empresariales se conecten a los LLM, habrá más Acciones, más plugins, más servicios en segundo plano que realicen tareas en nombre de las peticiones. Puede atornillar la seguridad como una serie de parches impulsados por incidentes, o puede construir un programa repetible: modelos de amenazas claros, patrones de arquitectura de referencia, flujos de pruebas automatizados y herramientas -potencialmente impulsadas por sistemas como Penligent- que sigan sondeando a medida que evoluciona su entorno.

Más allá del titular

Es fácil malinterpretar el hack Custom GPT SSRF como una vergüenza puntual para un único proveedor. Es más productivo interpretarlo como un avance. Las plataformas de IA se están convirtiendo rápidamente en capas de orquestación que conectan usuarios, modelos, API e infraestructura en la nube. Ese papel conlleva poder, y el poder siempre conlleva un radio de explosión mayor cuando algo sale mal.

Lo alentador de esta historia es que también muestra el camino a seguir. La vulnerabilidad fue descubierta por un investigador que siguió viejos instintos en un nuevo contexto. Se informó de ella a través de un canal estándar de recompensas por fallos. Se corrigió. El resto de nosotros podemos ahora tomar el mismo libro de jugadas y aplicarlo de forma proactiva a nuestros propios sistemas, idealmente con la ayuda de herramientas que entiendan tanto de seguridad como de IA.

Si lo hacemos, el legado de este incidente no será solo "ChatGPT tuvo una vez un SSRF". Se convierte en un caso de estudio sobre cómo pensar en la seguridad de la IA: tratar los modelos como un componente de un sistema más grande, tratar las integraciones como superficies de ataque serias, y utilizar la automatización más el conocimiento humano -ya sea a través de plataformas como Penligent o sus propias tuberías internas- para convertir continuamente una vaga preocupación en una garantía concreta, comprobable y respaldada por pruebas. Este es el tipo de historia que vale la pena contar en Medium, y aún más la que vale la pena vivir dentro de su organización de ingeniería.