Chaves de provedores de IA armazenadas por clientes na Railway foram roubadas em uma violação ocorrida em outubro e usadas para gerar cerca de US$ 740 mil em gastos não autorizados, informou a plataforma como serviço. A empresa prometeu cobrir as cobranças caso os provedores de IA não ofereçam reembolso.
A Railway desenvolve e executa aplicativos para seus clientes e armazena informações confidenciais, como chaves de API e credenciais de bancos de dados, em variáveis de ambiente. O invasor descriptografou variáveis em até 1,85% dos espaços de trabalho, cerca de 100 mil, e fez consultas ao banco de dados para localizar chaves de provedores de IA.
Em uma atualização de 26 de outubro, a empresa respondeu a clientes que perguntaram sobre o reembolso dos gastos não autorizados com IA: “A Railway não pode reembolsar clientes por gastos realizados com chaves de API comprometidas”. A empresa recomendou que eles procurassem diretamente os provedores de IA e se ofereceu para encaminhar as solicitações.
Segundo o relatório do incidente, os dados descriptografados também incluíam tokens de contas vinculadas de 1.852 usuários: chaves de agentes BYOK e tokens OAuth do GitHub. Todas as chaves e os tokens foram redefinidos, os usuários afetados foram notificados e a empresa não encontrou registros de acessos às contas dos clientes com credenciais roubadas.
Além das chaves de IA, uma das consultas feitas pelo invasor ao banco de dados buscava credenciais de serviços de nuvem, bancos de dados e pagamentos. A análise forense da empresa não encontrou evidências de acesso a bancos de dados de clientes nem indícios de que repositórios de código tenham sido baixados.
O invasor também leu históricos armazenados de 353 compilações, incluindo variáveis e informações confidenciais fornecidas a esses processos.
Os registros da empresa mostram quais ambientes foram expostos, mas não identificam quais variáveis foram acessadas. Por isso, a estimativa de cerca de 100 mil espaços de trabalho é um limite máximo. A Railway enviou mensagens aos clientes que considerou estar sob maior risco.
De acordo com a empresa, qualquer dado copiado pelo invasor, mas não descriptografado, não pode mais ser descriptografado, porque a credencial usada para isso foi desativada.
O que os clientes da Railway podem fazer
As condições para reembolso variam conforme o provedor de IA, segundo o relatório do incidente:
- **AWS Bedrock:** a política de reembolso da AWS já cobre fraudes, e as equipes de atendimento a contas começaram a processar reembolsos.
- **Google Gemini:** a política de reembolso do Google já cobre fraudes, e as equipes de atendimento a contas começaram a processar reembolsos.
- **OpenAI:** os pedidos são avaliados caso a caso. Os clientes devem registrar uma solicitação na OpenAI e, depois, enviar o número do caso à equipe de suporte da Railway.
- **SpaceXSI:** os pedidos são avaliados caso a caso e devem ser enviados à mesma equipe de suporte.
- **Anthropic:** as negociações continuam. Enquanto isso, a plataforma cobrirá os custos relacionados a chaves da Anthropic expostas na violação.
- **OpenRouter:** a empresa mantém em seus termos de serviço a política de não reembolsar os clientes. Por isso, a Railway cobrirá todos os custos relacionados à OpenRouter decorrentes da violação.
A Railway pede que os clientes informem cobranças que não reconhecerem por meio de um formulário de contestação. O formulário afirma que a empresa “não é responsável pelo uso dessas chaves”, mas está investigando o roubo e trabalhando com os provedores.
O relatório não explica como a estimativa de US$ 740 mil foi calculada nem a que período se refere. O documento e o formulário também não estabelecem um limite ou prazo para as solicitações, nem esclarecem se os clientes precisam pagar cobranças contestadas enquanto o pedido está em análise.
A empresa recomenda que os clientes revoguem e substituam qualquer variável confidencial armazenada na plataforma antes de 21 de outubro. As chaves devem ser revogadas ou substituídas junto ao provedor que as emitiu, já que preencher o formulário de contestação não revoga uma chave.
A Railway também recomenda desativar o acesso público aos bancos de dados, verificar os registros de auditoria do GitHub e quais aplicativos podem acessar as contas, além de conferir os registros de auditoria de repositórios de imagens, como o Docker Hub. A maior parte dessas orientações foi publicada junto com o comunicado da empresa em outubro e em um relatório divulgado no dia seguinte.
Por precaução, a empresa também forneceu a alguns provedores todas as chaves que mantinha para os serviços deles. Como resultado, mais de 100 mil usuários receberam solicitações de redefinição. Uma notificação de revogação enviada por um provedor não significa, por si só, que uma chave tenha sido exposta.
Como ocorreu a violação da Railway
O ataque começou no sistema de compilação da empresa, segundo o relatório do incidente. Às 7h28 UTC de 20 de outubro, o invasor explorou uma falha até então desconhecida para escapar parcialmente do isolamento do sistema de arquivos de um processo de compilação e ler alguns arquivos na máquina virtual hospedeira.
Com isso, o invasor obteve uma credencial usada pelos servidores de compilação para enviar imagens finalizadas e acessar alguns sistemas internos. O engenheiro de plantão recebeu um alerta às 13h58 UTC, cerca de seis horas e meia após a primeira exploração, quando uma notificação sinalizou chamadas incomuns a um serviço de registro.
A credencial deveria ser usada apenas em tarefas de compilação. No entanto, o sistema interno Temporal, responsável por partes desse processo, a aceitou como pertencente a um cliente confiável. Por meio dele, o invasor leu históricos armazenados de outros processos de compilação.
A mesma credencial também permitia obter cópias em cache do código. Assim, o invasor conseguiu uma cópia do repositório monolítico interno da empresa, a base de código a partir da qual muitos de seus serviços são implantados. A Railway afirma que essa cópia ajudou o invasor a entender o funcionamento da plataforma, identificar falhas exploráveis e se deslocar rapidamente entre sistemas.
Depois de analisar o código, o invasor encontrou uma relação de confiança OIDC configurada incorretamente em um dos ambientes de nuvem da empresa. Essa relação faz parte do processo pelo qual o sistema de implantação obtém credenciais temporárias de nuvem. Às 3h26 UTC de 21 de outubro, o invasor explorou a configuração incorreta para obter uma dessas credenciais.
Com ela, o invasor obteve outras duas credenciais no ambiente de nuvem. Uma permitia ler variáveis criptografadas em um banco de dados de produção quando usada dentro da rede interna. A outra era uma chave SSH.
A chave SSH dava acesso a uma máquina que executa tarefas de orquestração para a infraestrutura da empresa. Essa máquina armazenava uma credencial capaz de descriptografar as variáveis dos clientes, necessária para iniciar as cargas de trabalho deles.
As variáveis de cada ambiente são criptografadas com uma chave própria, que, por sua vez, é criptografada por uma chave raiz armazenada no serviço de gerenciamento de chaves de um provedor de nuvem (KMS).
Entre 4h07 e 5h21 UTC de 21 de outubro, o invasor extraiu variáveis criptografadas do banco de dados e procurou nomes que correspondessem a chaves de provedores de IA. Com as credenciais da máquina de orquestração e o KMS, descriptografou algumas delas entre 4h42 e 5h14 UTC e, novamente, entre 6h36 e 7h15 UTC.
O invasor foi completamente removido dos sistemas da empresa às 9h24 UTC daquele dia.
Esses horários diferem dos apresentados no relatório preliminar de 22 de outubro. Na ocasião, a empresa situou o início do ataque às 13h58 UTC de 20 de outubro e informou que a descriptografia ocorreu depois das 5h27 UTC.
Agora, cada processo de compilação é executado em sua própria máquina virtual de curta duração, além da camada de isolamento anterior. As credenciais usadas nesses processos só podem enviar uma imagem específica ao registro da empresa.
Em menos de uma hora após a aplicação de um patch para corrigir a falha original de escape, a equipe interna de segurança da Railway criou uma segunda forma de explorar a falha, modificando o ataque inicial. Esse foi um dos motivos para a empresa transferir todos os usuários de uma só vez para o novo sistema de compilação.
A empresa afirma que todas as falhas exploradas pelo invasor foram corrigidas. A Railway apresentou uma queixa ao IC3, centro de denúncias de crimes na internet do FBI, e trabalha com uma empresa especializada em perícia, cuja investigação continua.
Por enquanto, a empresa compartilha indicadores de comprometimento em caráter privado e planeja publicá-los quando as autoridades policiais autorizarem.
A Railway acredita que as credenciais roubadas foram usadas por serviços que encaminham ou revendem acesso a provedores de IA para uso em destilação. A empresa não determinou se o invasor operava esses serviços e não identificou quem foi o responsável pelo ataque.
Em uma análise publicada durante o “Outubro Negro”, pesquisadores da Wiz incluem a violação da Railway entre os incidentes divulgados em outubro por pelo menos nove plataformas de desenvolvimento de IA, entre elas a violação anterior do OpenCode.
Segundo os pesquisadores, todos os relatos públicos descrevem invasores à procura de variáveis de ambiente armazenadas, sobretudo aquelas que concedem acesso a serviços de IA. Eles afirmam que não há uma única falha ou dependência de software que conecte os ataques.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...