Milhares de empresas confiam na estrutura Ray para escalar e gerenciar cargas de trabalho de IA complexas e intensivas em computação. De fato, é difícil encontrar um modelo de linguagem de grande porte (LLM) que não tenha sido desenvolvido utilizando o Ray. No entanto, essas cargas de trabalho frequentemente contêm dados sensíveis, que foram identificados por pesquisadores como vulneráveis devido a uma falha crítica de segurança (CVE) dentro da estrutura de computação unificada de código aberto.
Nos últimos sete meses, essa vulnerabilidade permitiu que atacantes explorassem cargas de trabalho de produção de IA, acessando poder computacional, credenciais, senhas, chaves, tokens e uma multitude de outras informações sensíveis, segundo pesquisa da Oligo Security. Essa vulnerabilidade, chamada de "ShadowRay", permanece em disputa. É classificada como uma “vulnerabilidade sombra”, o que significa que não é reconhecida como uma ameaça e não possui um patch oficial. Como resultado, não aparece em processos de varredura padrão.
Essa situação marca a "primeira instância conhecida de cargas de trabalho de IA sendo ativamente exploradas por vulnerabilidades na infraestrutura contemporânea de IA", de acordo com pesquisadores como Avi Lumelsky, Guy Kaplan e Gal Elbaz. Eles afirmam: “Quando atacantes acessam um cluster de produção Ray, é um verdadeiro prêmio. Dados valiosos da empresa combinados com execução remota de código criam oportunidades de monetização, tudo isso sem serem detectados.”
Um Ponto Cego Significativo
Muitas organizações dependem do Ray para cargas de trabalho em larga escala de IA, dados e SaaS, incluindo Amazon, Instacart, Shopify, LinkedIn e OpenAI—todas cujos modelos GPT-3 foram treinados usando Ray. Essa estrutura é essencial para modelos com bilhões de parâmetros que exigem poder computacional substancial e não podem ser executados em uma única máquina. Mantido pela Anyscale, o Ray suporta cargas de trabalho distribuídas para treinamento, serviço e ajuste de diversos modelos de IA. Os usuários não precisam de amplo conhecimento em Python, e o processo de instalação é simples, com dependências mínimas.
Pesquisadores da Oligo se referem ao Ray como o “canivete suíço para Pythonistas e praticantes de IA”. Apesar de suas vantagens, a vulnerabilidade ShadowRay torna essa dependência do Ray ainda mais preocupante. Conhecida como CVE-2023-48022, a vulnerabilidade surge de autorização insuficiente na API Ray Jobs, expondo-a a ataques de execução remota de código. Qualquer pessoa com acesso ao painel pode executar trabalhos arbitrários sem permissão.
Embora essa vulnerabilidade tenha sido relatada à Anyscale junto com outras quatro no final de 2023, a única que ficou sem resposta é a CVE-2023-48022. A Anyscale contestou a vulnerabilidade, alegando que representa um comportamento esperado e uma característica do produto que facilita a programação de tarefas e a execução dinâmica de código dentro de um cluster.
A Anyscale afirma que os painéis não devem ser acessíveis publicamente ou devem ser restritos a usuários confiáveis; assim, a falta de autorização no Ray se baseia na suposição de operação em um ambiente seguro com “lógica de roteamento apropriada” através de isolamento de rede, namespaces do Kubernetes, regras de firewall ou grupos de segurança. Essa decisão ilustra "a complexidade de equilibrar segurança e usabilidade no desenvolvimento de software", observam os pesquisadores da Oligo, enfatizando a necessidade de consideração cuidadosa ao modificar sistemas críticos como o Ray.
Além disso, como vulnerabilidades contestadas muitas vezes não são detectadas, muitos scanners de segurança as ignoram. Pesquisadores da Oligo descobriram que a ShadowRay não apareceu em várias bases de dados, incluindo a Open Source Vulnerability Database (OSV) do Google, nem era visível para soluções de teste de segurança de aplicação estática (SAST) e análise de composição de software (SCA).
“Isso criou um ponto cego: as equipes de segurança não estavam cientes dos riscos potenciais”, destacaram os pesquisadores, observando que “especialistas em IA não são especialistas em segurança, o que os deixa vulneráveis a riscos apresentados por frameworks de IA”.
De Cargas de Trabalho de Produção a Tokens Críticos
Os pesquisadores revelaram que servidores comprometidos vazaram um "tesouro" de informações sensíveis, incluindo:
- Interrupção de cargas de trabalho de produção de IA, levando a compromissos na integridade ou precisão do modelo durante o treinamento.
- Acesso a ambientes de nuvem sensíveis (AWS, GCP, Azure), que poderiam expor bancos de dados de clientes e dados de produção sensíveis.
- Acesso à API do Kubernetes, possibilitando infecções de cargas de trabalho em nuvem ou extração de segredos do Kubernetes.
- Credenciais sensíveis para plataformas como OpenAI, Stripe e Slack.
- Credenciais de banco de dados que permitem downloads ou modificações silenciosas de bancos de dados inteiros.
- Chaves SSH privadas para acessar máquinas adicionais para atividades maliciosas.
- Tokens do OpenAI, potencialmente drenando créditos da conta.
- Tokens do Hugging Face, que fornecem acesso a repositórios privados, facilitando ataques à cadeia de suprimentos.
- Tokens do Stripe que poderiam ser explorados para esvaziar contas de pagamento.
- Tokens do Slack, que poderiam ser usados para mensagens não autorizadas ou leitura.
Os pesquisadores relataram que muitas GPUs comprometidas estão atualmente escassas e são caras. Eles identificaram "centenas" de clusters comprometidos, principalmente utilizados na mineração de criptomoedas. "Os atacantes direcionam esses sistemas não apenas por informações valiosas, mas também porque as GPUs são caras e difíceis de adquirir, especialmente hoje", observaram os pesquisadores, com alguns preços de GPU sob demanda na AWS atingindo um custo anual de $858,480.
Com os atacantes tendo sete meses para explorar esse hardware, as estimativas sugerem que máquinas e poder computacional comprometidos poderiam ter um valor de $1 bilhão.
Abordando Vulnerabilidades Sombra
Os pesquisadores da Oligo reconhecem que “vulnerabilidades sombra sempre existirão” e que os indicadores de exploração podem variar. Eles recomendam várias ações para organizações:
- Operar o Ray em um ambiente seguro e confiável.
- Implementar regras de firewall e grupos de segurança para prevenir acessos não autorizados.
- Monitorar continuamente clusters de IA e ambientes de produção em busca de anomalias.
- Usar um proxy que adicione uma camada de autorização se um painel do Ray precisar ser acessível publicamente.
- Nunca presumir que a segurança padrão é suficiente.
Por fim, enfatizam: “O ônus técnico de garantir a segurança de código aberto recai sobre você. Não confie apenas nos mantenedores.”
Classificação
