Quando GPTs personalizadas se tornam backdoors na nuvem: O hack do ChatGPT SSRF e o futuro da segurança de IA

Se você permanecer na área de segurança por tempo suficiente, acabará desenvolvendo um mau hábito: deixará de ver "recursos" e começará a ver possíveis caminhos de ataque. A história recente sobre "ChatGPT hackeado usando GPTs personalizados que exploram uma vulnerabilidade SSRF para expor segredos" é um exemplo clássico. O que parecia ser um conveniente recurso Actions para GPTs personalizados acabou se tornando um túnel direto para o ambiente de nuvem da OpenAI. Nada de feitiçaria exótica de prompt, nada de "mágica de IA" que deu errado - apenas um bug muito antigo, falsificação de solicitação do lado do servidor, redescoberto em uma plataforma muito nova.

É exatamente por isso que esse incidente é importante. Não se trata de mais uma manchete de propaganda sobre a IA se tornando desonesta. É um lembrete de que, quando você incorpora LLMs em uma infraestrutura real, as regras tradicionais de segurança de aplicativos e de nuvem voltam com força total. Os modelos podem ser novos, mas os erros subjacentes não são.

Reconstruindo a exploração: de "Add Action" a token de nuvem

Para entender o que aconteceu, é preciso ver como funcionam os GPTs personalizados. A interface do OpenAI permite que você defina Ações, que são essencialmente APIs HTTP externas que seu GPT pode chamar com base em um esquema OpenAPI. Para os usuários, isso é como dar ao seu GPT "superpoderes": ele pode buscar dados, acionar fluxos de trabalho, conectar-se a sistemas internos. Nos bastidores, isso significa que há um cliente HTTP de back-end, executado dentro da infraestrutura da OpenAI, que chamará alegremente os URLs que você descrever e alimentará as respostas de volta ao modelo.

Um pesquisador da Open Security percebeu exatamente isso. Ao brincar com GPTs personalizados, eles viram o padrão familiar: URLs controlados pelo usuário, um botão "Test" que envia solicitações ao vivo e um servidor que claramente é executado em um ambiente de nuvem. Qualquer pessoa que tenha feito testes de invasão na nuvem reconhecerá o instinto que se segue: verificar se você pode enganar esse servidor para que ele chame endereços internos em seu nome. Essa é a essência do SSRF.

Em ambientes de nuvem, o alvo interno mais valorizado é quase sempre o serviço de metadados. No Azure, como em outras nuvens, ele reside no endereço local do link 169.254.169.254. De dentro de uma VM ou contêiner, esse endpoint pode revelar detalhes sobre a instância e, o que é mais importante, emitir tokens de curta duração que permitem que as cargas de trabalho chamem as APIs de gerenciamento da nuvem. De fora da nuvem, não é possível acessá-lo. É exatamente por isso que o SSRF é tão importante: você sequestra o ponto de vantagem do servidor e o força a falar com coisas que você, como invasor externo, não pode.

O primeiro obstáculo do pesquisador foi que o Custom GPT Actions só permitia URLs HTTPS, enquanto o serviço de metadados é somente HTTP. À primeira vista, essa restrição parece uma defesa, mas, na prática, é apenas mais uma peça do quebra-cabeça. A solução foi simples: registrar um domínio HTTPS externo sob o controle do pesquisador, fazer com que ele respondesse com um redirecionamento 302 apontando para o http://169.254.169.254 e verificar se o backend do Actions seguiu o redirecionamento. Ele seguiu. De repente, uma chamada HTTPS de aparência inocente na configuração do GPT personalizado resultou em uma chamada HTTP para o endpoint de metadados da nuvem interna.

O serviço de metadados do Azure, no entanto, não é totalmente ingênuo. Para evitar abusos casuais, ele exige um cabeçalho especial, Metadados: trueem cada solicitação. Se o cabeçalho estiver ausente, o serviço se recusará a divulgar dados reais. Nesse ponto, pode parecer que o sistema está seguro novamente, porque a interface do esquema OpenAPI usada para definir ações não expõe a configuração arbitrária do cabeçalho. Mas sistemas grandes raramente têm apenas uma superfície de configuração. Nesse caso, o recurso Actions também suporta a ideia de "chaves de API" e outros cabeçalhos de autenticação que você pode definir ao conectar um serviço externo. Esses cabeçalhos são então anexados automaticamente às solicitações de saída.

Isso foi suficiente para completar a cadeia. Ao definir uma "chave de API" falsa cujo nome de cabeçalho era literalmente Metadados e cujo valor era verdadeiroEm uma pesquisa de campo, o pesquisador convenceu o backend a incluir o cabeçalho exato que o Azure IMDS espera. Combine isso com o truque de redirecionamento e agora você tem um canal SSRF do backend do Custom GPT Actions para o serviço de metadados, com um Metadados: true cabeçalho.

Depois que esse canal foi estabelecido, o resto foi quase mecânico. O pesquisador solicitou ao serviço de metadados um token OAuth2 destinado à API de gerenciamento do Azure, usando o conhecido caminho IMDS. A resposta continha um token de acesso vinculado à identidade da nuvem que a infraestrutura do ChatGPT estava usando. Esse token poderia, no mínimo, consultar pontos de extremidade de gerenciamento e, potencialmente, acessar recursos confidenciais, dependendo de quanto privilégio a identidade tinha. Nesse ponto, o pesquisador parou, relatou as descobertas por meio do programa de recompensa por bugs da OpenAI, e a OpenAI classificou a falha como de alta gravidade e passou a corrigi-la.

O que torna essa cadeia impressionante é que o invasor nunca precisou de acesso ao shell, código-fonte ou qualquer bug clássico na pilha HTTP. Tudo aconteceu dentro de telas de configuração normais: URLs, configurações de autenticação e um botão de teste que executou devidamente a travessura.

Um pequeno esboço de código de uma sonda no estilo SSRF

Para tornar isso mais concreto, imagine um script auxiliar interno muito pequeno que um engenheiro de segurança possa usar para verificar a sanidade de um cliente HTTP "estilo Actions". O objetivo não é atingir serviços de metadados reais na produção, mas codificar o hábito de sondar redirecionamentos inesperados e saltos de IP internos em ambientes de teste ou de laboratório:

importar solicitações
from urllib.parse import urljoin

def trace_request(base_url: str, path: str = "/"):
    url = urljoin(base_url, path)
    print(f"[+] Requesting {url}")
    try:
        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"[+] Status: {resp.status_code}")
    print("[+] Cadeia de redirecionamento:")
    for h in resp.history:
        print(f" {h.status_code} -> {h.headers.get('Location')}")

    # Heurística muito grosseira: avisar se alguma vez aterrissarmos em um IP interno
    if resp.raw._connection and hasattr(resp.raw._connection, "sock"):
        peer = resp.raw._connection.sock.getpeername()[0]
        print(f"[+] IP do par: {peer}")
        if peer.startswith("10.") or peer.startswith("192.168.") or peer.startswith("169.254."):
            print("[!] Aviso: o backend seguiu um redirecionamento para um endereço interno")

if __name__ == "__main__":
    Exemplo #: substitua por um endpoint de teste controlado em seu próprio laboratório
    trace_request("")

Um script como esse não "explora o ChatGPT", mas captura a mesma forma de investigação: comece a partir de um URL externo supostamente seguro, siga os redirecionamentos e reclame em voz alta se o seu cliente HTTP de repente se encontrar falando com intervalos de IP internos ou locais de link. Transformar esse padrão em automação - e executá-lo em relação aos componentes que alimentam suas próprias ações de IA - é muito mais útil do que apenas ler sobre o incidente.

Não se trata de um "bug de IA"; é o abuso da nuvem da velha guarda em um novo estágio

É muito tentador ler isso como "o ChatGPT foi hackeado" e seguir em frente. Esse enquadramento perde a lição mais profunda. Nada no modelo em si apresentou comportamento inadequado. Não houve nenhum prompt que, de alguma forma, liberasse recursos proibidos. O LLM fez o que lhe foi solicitado: chamou uma ação, leu o resultado e o resumiu. A vulnerabilidade estava inteiramente na conexão entre o LLM e o mundo externo.

É exatamente nessa cola que as equipes de segurança precisam se concentrar. Sempre que você dá a um LLM a capacidade de chamar ferramentas, ações ou plug-ins, você está efetivamente transformando-o em um cliente programável na sua infraestrutura. No passado, um usuário chamava manualmente sua API e você analisava a entrada. Agora, um usuário dá instruções a um modelo, e o modelo traduz isso em chamadas de API em seu nome. O modelo se torna outra maneira de a intenção hostil chegar ao seu back-end.

Visto por essa lente, esse incidente é simplesmente o OWASP SSRF em uma roupagem diferente. Todas as condições são familiares: URLs influenciadas pelo usuário, um servidor que pode alcançar endpoints internos ou privilegiados, controles de saída ausentes ou incompletos e um serviço de metadados na nuvem que é muito acessível a cargas de trabalho regulares. A diferença é que o ponto de entrada não é mais um formulário da Web clássico ou um campo JSON; é um bloco de configuração que foi projetado para tornar os GPTs personalizados mais avançados.

É também por isso que o raio da explosão é importante. O servidor afetado não era um microsserviço aleatório; ele fazia parte da infraestrutura multilocatária do ChatGPT, localizada no ambiente Azure da OpenAI. Qualquer token obtido por meio do IMDS pertencia a uma carga de trabalho que já tinha acesso significativo. Mesmo que as defesas locais limitassem o que o invasor poderia fazer, o perfil de risco é fundamentalmente diferente de uma VM de teste esquecida.

IA como um hub de integração: ampliando as superfícies de ataque e movendo os limites de confiança

A história mais interessante por trás desse bug é arquitetônica. As plataformas de IA estão se tornando rapidamente centros de integração. Um GPT personalizado para uma equipe de vendas pode se comunicar com um CRM, um sistema de faturamento e um armazenamento de documentos. Um GPT focado em segurança pode se comunicar com scanners, sistemas de emissão de tíquetes e CI/CD. Em cada caso, o LLM não é o ativo; os dados e as ações por trás desses conectores é que são.

Quando você aceita essa realidade, seu modelo mental de ameaça precisa mudar. Você não pode continuar pensando em "segurança de IA" apenas como injeção imediata, vazamento de dados ou resultados tóxicos. Você também precisa fazer perguntas nada glamourosas sobre limites de rede, identidade de nuvem e isolamento de locatários.

Com o que a infraestrutura que executa suas ações pode realmente conversar na rede? O padrão em muitos ambientes de nuvem é "qualquer coisa de saída é permitida, desde que o DNS resolva". Isso fazia sentido quando os serviços eram relativamente simples e os engenheiros queriam flexibilidade. No entanto, coloque uma plataforma LLM no meio e, de repente, cada locatário terá uma maneira de propor novos destinos de saída por meio de configuração, em vez de código. Se não houver uma política de saída forte, você criou efetivamente um lançador de SSRF programável.

Quanto privilégio as identidades usadas por essas cargas de trabalho realmente têm? No caso do ChatGPT, os pesquisadores conseguiram solicitar um token para a API de gerenciamento do Azure. Mesmo que esse token tenha sido limitado por atribuições de funções, ele ainda representa um segredo de alto valor. Em muitas organizações, a tentação de conceder permissões amplas à "infraestrutura da plataforma" é grande, pois isso simplifica a implantação. Essa tentação é perigosa para qualquer coisa que possa ser acionada indiretamente pela entrada do usuário, especialmente por meio de IA.

Onde exatamente estão os limites de confiança entre os locatários, entre o plano de controle e o plano de dados, e entre o tempo de execução da IA e o restante da nuvem? Um sistema bem projetado deve presumir que a configuração de qualquer locatário pode se tornar adversária, que qualquer chamada de saída em nome desse locatário pode ser hostil e que qualquer elevação de ação para metadados para APIs de gerenciamento é um objetivo realista do invasor. Essa perspectiva faz com que padrões como segmentação rigorosa da rede, sidecars complementares que aplicam políticas e identidades de serviço dedicadas não sejam negociáveis, em vez de serem "bons de ter".

De um incidente a uma metodologia de teste repetível

Para defensores e criadores, o valor real dessa história não é o bug específico; é a mentalidade de teste que ela ilustra. Basicamente, o pesquisador tratou as ações personalizadas do GPT como um novo e estranho tipo de cliente HTTP e, em seguida, percorreu uma lista de verificação familiar: posso controlar o URL, posso acessar hosts internos, posso abusar de redirecionamentos, posso injetar cabeçalhos, posso atingir metadados, posso transformar isso em um token de nuvem?

Essa lista de verificação mental é exatamente o que deve ser automatizado nos fluxos de trabalho modernos de testes de penetração para plataformas de IA. Em vez de esperar por uma manchete e um relatório de recompensa, as equipes devem transformar rotineiramente sua própria infraestrutura de GPT personalizada, ecossistemas de plugins e cadeias de ferramentas em alvos.

Para tornar isso um pouco mais tangível, você pode pensar em uma "revisão do AI Actions SSRF" como uma sequência simples e repetitiva como esta:

Quando você tiver esse tipo de tabela escrita para o seu ambiente, será muito mais fácil automatizar e explicar os testes que você faz. Você pode conectá-la a manuais internos, compartilhá-la com fornecedores e garantir que os futuros recursos de IA sejam mantidos no mesmo padrão.

É nesse ponto que as ferramentas de segurança especializadas e com reconhecimento de IA começam a ser importantes. Um scanner da Web genérico pode não saber como navegar em uma interface de usuário que oculta chamadas de rede por trás de ações ou como raciocinar sobre esquemas OpenAPI usados em uma definição de GPT. Em contrapartida, uma plataforma de pentest orientada por IA, como a Penligent, pode tratar esses esquemas e configurações como entradas de primeira classe. É possível imaginar um fluxo de trabalho em que você exporta a configuração de Actions para um conjunto de GPTs personalizados ou outras ferramentas de IA, alimenta-os em um pipeline de testes de agentes e permite que ele sistematicamente analise as condições de SSRF, redirecionamentos inseguros, acesso ilimitado à rede e exposição de metadados.

A filosofia da Penligent de combinar automação com controle humano no circuito se encaixa bem nesse padrão. Um agente pode enumerar todas as definições de ferramentas, gerar cargas candidatas para pontos de extremidade que aceitam URLs ou nomes de host e conduzir tráfego com script que simula o que um invasor curioso tentaria. Quando o sistema descobre um comportamento promissor - por exemplo, que um endpoint HTTPS aparentemente externo segue redirecionamentos para intervalos de IP internos -, ele pode apresentar isso como evidência: registros de solicitações, trechos de respostas e topologia interna inferida. Um operador humano pode, então, orientar as próximas etapas, por exemplo, solicitando ao sistema que se volte especificamente para as rotas de metadados da nuvem ou que verifique se os tokens retornados são válidos em relação às APIs de gerenciamento.

Esse tipo de fluxo de trabalho realiza duas coisas. Ele traz as plataformas de IA para o mesmo ciclo de segurança orientado por evidências que os aplicativos da Web e as APIs já desfrutam e aproveita os mesmos recursos de LLM que os invasores inevitavelmente usarão, mas a serviço dos defensores. O bug que atingiu o ChatGPT não é mais uma surpresa única; ele se torna um caso de teste em um conjunto de regressão que pode ser executado sempre que você introduzir uma nova integração ou alterar sua infraestrutura de ações.

Lições práticas para equipes que desenvolvem sobre plataformas de IA

Se você é um engenheiro ou arquiteto de segurança que consome serviços de IA em vez de criá-los, esse incidente ainda é altamente relevante. Mesmo que nunca toque em GPTs personalizados internamente, você provavelmente expõe APIs internas, painéis ou armazenamentos de documentos a agentes de IA ou co-pilotos de algum tipo. As ideias são transferíveis.

O primeiro passo é parar de tratar o LLM como a única coisa que precisa de revisão de segurança. Qualquer recurso que permita que os modelos retornem ao seu ambiente - seja por meio de ferramentas explícitas, ações ou webhooks indiretos - deve ser visto como um gráfico de ataque em potencial. Você deve ser capaz de responder, com alguma confiança, a quais serviços internos um componente de IA pode se comunicar, quais identidades ele usa e o que acontece se um usuário hostil tentar deliberadamente ampliar esses recursos.

A segunda etapa é estender seus programas de teste para abranger o código de cola de IA. Ao encomendar um teste de penetração ou executar um exercício interno de equipe vermelha, certifique-se de que o escopo inclua explicitamente as integrações de IA: as superfícies de configuração das ferramentas, a forma como os URLs e os cabeçalhos são construídos, os caminhos de rede entre os tempos de execução de IA e os serviços confidenciais e as proteções em torno dos endpoints de metadados. Solicite evidências de que alguém, em algum lugar, tentou abusar delas como um verdadeiro invasor faria.

A terceira etapa é aceitar que essa superfície de ataque não diminuirá. À medida que mais processos de negócios se conectarem aos LLMs, haverá mais ações, mais plug-ins e mais serviços em segundo plano executando trabalhos em nome dos prompts. Você pode incluir a segurança como uma série de patches orientados por incidentes ou pode criar um programa repetível: modelos claros de ameaças, padrões de arquitetura de linha de base, fluxos de testes automatizados e ferramentas - potencialmente alimentadas por sistemas como o Penligent - que continuam sondando à medida que seu ambiente evolui.

Além da manchete

O hack do SSRF do GPT personalizado é fácil de ser interpretado erroneamente como uma vergonha única para um único fornecedor. É mais produtivo interpretá-lo como uma prévia. As plataformas de IA estão se transformando rapidamente em camadas de orquestração que conectam usuários, modelos, APIs e infraestrutura de nuvem. Essa função vem acompanhada de poder, e o poder sempre vem acompanhado de um raio de explosão maior quando algo dá errado.

A parte animadora dessa história é que ela também mostra o caminho a seguir. A vulnerabilidade foi encontrada por um pesquisador que seguiu antigos instintos em um novo contexto. Ela foi relatada por meio de um canal padrão de recompensa por bugs. Ela foi corrigida. Agora, todos nós podemos usar o mesmo manual e aplicá-lo proativamente em nossos próprios sistemas, de preferência com a ajuda de ferramentas que entendam de segurança e IA.

Se fizermos isso, o legado desse incidente não será apenas "o ChatGPT já teve um SSRF". Ele se torna um estudo de caso sobre como pensar em segurança de IA: trate os modelos como um componente de um sistema maior, trate as integrações como superfícies de ataque sérias e use a automação mais o insight humano - seja por meio de plataformas como a Penligent ou de seus próprios pipelines internos - para transformar continuamente uma preocupação vaga em uma garantia concreta, testável e apoiada em evidências. Esse é o tipo de história que vale a pena contar no Medium e que vale ainda mais a pena viver dentro de sua organização de engenharia.