Chaves de provedores de inteligência artificial (IA) armazenadas por clientes na Railway foram roubadas em uma invasão em outubro e usadas em gastos não autorizados estimados em US$ 740 mil, afirmou a provedora de plataforma como serviço (PaaS, na sigla em inglês) na véspera. A empresa prometeu pagar ela mesma essas cobranças caso um provedor de IA não as reembolse.
A empresa cria e executa aplicativos para seus clientes e armazena segredos deles, como chaves de API (interface de programação de aplicações) e credenciais de banco de dados, na forma de variáveis de ambiente. O invasor descriptografou variáveis em no máximo 1,85% dos espaços de trabalho, cerca de 100 mil, e suas consultas ao banco de dados buscavam chaves de provedores de IA.
Em uma atualização de 26 de outubro, a empresa disse a clientes que pediam reembolso por gastos não autorizados com IA que “a Railway não consegue reembolsar clientes por gastos realizados com chaves de API comprometidas”. Ela recomendou que eles entrassem em contato diretamente com os provedores de IA e se ofereceu para levar os pedidos adiante.
De acordo com o relatório de incidente da empresa, os dados descriptografados também incluíam tokens de contas vinculadas de 1.852 usuários: chaves de agente BYOK (sigla de “bring your own key”, ou “traga sua própria chave”) e tokens OAuth (protocolo de autorização). Todos foram redefinidos, cada usuário foi notificado e não foram encontrados logins em contas de clientes usando credenciais roubadas.
Além das chaves de IA, uma das consultas do invasor ao banco de dados encontrou credenciais de serviços de nuvem, de banco de dados e de pagamento. A análise forense da empresa não mostrou acesso a nenhum banco de dados de clientes, e não há indícios de que repositórios de código dos clientes tenham sido baixados.
O invasor também leu o histórico armazenado de 353 compilações (builds), incluindo as variáveis e os segredos transmitidos a essas compilações.
Os registros da empresa mostram quais ambientes foram expostos, mas não quais variáveis, por isso o número de cerca de 100 mil espaços de trabalho é um limite superior. A empresa enviou e-mails aos clientes que considerou em alto risco.
Qualquer dado copiado pelo invasor, mas não descriptografado, não pode mais ser descriptografado, porque a credencial usada por ele foi desativada, segundo a empresa.
O que os clientes da Railway podem fazer
As regras de reembolso variam de acordo com o provedor de IA, segundo o relatório de incidente da empresa:
- AWS Bedrock: a política de reembolso existente da AWS (Amazon Web Services) cobre fraudes, e suas equipes de conta começaram a fazer reembolsos.
- Google Gemini: a política de reembolso existente do Google cobre fraudes, e suas equipes de conta começaram a fazer reembolsos.
- OpenAI: os reembolsos são analisados caso a caso. Os clientes abrem um pedido de reembolso com a OpenAI e depois repassam o número do caso à equipe de suporte da Railway.
- SpaceXSI: os reembolsos são analisados caso a caso, e os clientes enviam seus pedidos à mesma equipe de suporte.
- Anthropic: as negociações ainda estão em andamento, e a plataforma vai cobrir os custos de chaves Anthropic comprometidas enquanto isso.
- OpenRouter: a empresa mantém a política de não reembolso em seus termos de serviço, por isso a plataforma vai cobrir todos os custos relacionados à OpenRouter decorrentes da invasão.
Os clientes são orientados a informar cobranças que não fizeram por meio de um formulário para relatar cobranças. O formulário diz 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 diz como o valor de US$ 740 mil foi estimado nem qual período ele abrange. Nem o relatório nem o formulário definem um teto ou um prazo para os pedidos, ou informam se os clientes devem pagar as cobranças contestadas enquanto um pedido estiver em análise.
A empresa aconselha os clientes a revogar e substituir qualquer variável sensível armazenada na plataforma antes de 21 de outubro. As chaves devem ser revogadas ou rotacionadas junto ao provedor que as emitiu, já que registrar um relatório de cobrança não revoga uma chave.
A empresa também recomenda remover o acesso público à rede para bancos de dados, verificar os logs de auditoria do GitHub e quais aplicativos podem acessar a conta, e conferir os logs de auditoria em registros como o Docker Hub. A maior parte dessas orientações vem do comunicado de outubro da empresa e de um relatório publicado no dia seguinte.
Por precaução, a empresa também entregou a alguns provedores todas as chaves que mantinha para os serviços deles, de modo que as solicitações de redefinição chegaram a mais de 100 mil usuários. Um aviso de revogação de um provedor não significa, por si só, que uma chave foi exposta.
Como ocorreu a invasão à Railway
O ataque começou no sistema de compilação (build) da empresa, segundo seu relatório de incidente. Às 07:28 UTC (Tempo Universal Coordenado) de 20 de outubro, o invasor explorou uma falha até então desconhecida para escapar parcialmente do isolamento do sistema de arquivos em torno de uma compilação e ler alguns arquivos da máquina virtual (VM) hospedeira.
Isso deu ao invasor uma credencial que os servidores de compilação usam para enviar imagens finalizadas e acessar alguns sistemas internos. O engenheiro de plantão foi acionado às 13:58 UTC, cerca de seis horas e meia após a primeira exploração, quando um alerta sinalizou chamadas incomuns a um serviço de registro.
A credencial servia apenas para trabalhos de compilação, mas o Temporal, sistema interno da empresa que controla partes do processo de build, aceitou-a como cliente confiável. Por meio dele, o invasor leu alguns históricos armazenados de outras compilações.
A mesma credencial também podia buscar snapshots em cache do código. Isso deu ao invasor uma cópia do monorepo interno da empresa, a base de código de onde muitos de seus serviços são implantados. A empresa afirma que a cópia mostrou ao invasor como a plataforma funciona e ajudou a encontrar explorações e a se mover rapidamente entre sistemas.
Depois de analisar esse código, o invasor encontrou uma vinculação OIDC (OpenID Connect) configurada de forma incorreta em um dos ambientes de nuvem da empresa. A vinculação faz parte do modo como o sistema de implantação obtém credenciais de nuvem de curta duração, e às 03:26 UTC de 21 de outubro o invasor explorou o erro para obter uma delas.
Com essa credencial, o invasor obteve outras duas no ambiente de nuvem. Uma podia ler variáveis criptografadas de um banco de dados de produção quando usada dentro da rede interna, e a outra era uma chave SSH (protocolo Secure Shell).
A chave SSH deu acesso a uma máquina que executa tarefas de orquestração da frota de servidores da empresa. Essa máquina armazenava uma credencial capaz de descriptografar variáveis de clientes, necessária para iniciar as cargas de trabalho dos clientes.
As variáveis de cada ambiente são criptografadas com a chave própria desse ambiente, e essas chaves, por sua vez, são criptografadas por uma chave-raiz armazenada no serviço de gerenciamento de chaves (KMS) de um provedor de nuvem.
Entre 04:07 e 05:21 UTC de 21 de outubro, o invasor extraiu variáveis criptografadas do banco de dados, procurando nomes correspondentes a chaves de provedores de IA. Usando as credenciais da máquina de orquestração junto ao KMS, ele descriptografou algumas delas entre 04:42 e 05:14 UTC e novamente entre 06:36 e 07:15 UTC.
O invasor foi totalmente removido dos sistemas da empresa às 09:24 UTC naquele dia.
Esses horários diferem do relatório preliminar da empresa, publicado em 22 de outubro, que datava o ataque a partir das 13:58 UTC de 20 de outubro e situava a descriptografia após as 05:27 UTC.
Cada compilação agora roda em sua própria máquina virtual (VM) de curta duração, sobre o isolamento anterior. Suas credenciais só podem enviar uma imagem específica para o registro da empresa.
Em menos de uma hora após a empresa corrigir a falha original de escape, sua própria equipe de endurecimento de segurança (hardening) criou uma segunda exploração alterando esse ataque. Esse foi um dos motivos pelos quais a empresa migrou todos os usuários para o novo sistema de compilação de uma só vez.
A empresa afirma que todas as falhas usadas pelo invasor já foram corrigidas. Ela registrou uma denúncia no IC3 (Centro de Denúncias de Crimes pela Internet, do FBI) e trabalha com uma empresa especializada em perícia forense, cuja investigação continua.
Por enquanto, a empresa compartilha de forma reservada os indicadores de comprometimento (IoCs) e planeja publicá-los quando as autoridades policiais concordarem.
A empresa acredita que as credenciais roubadas foram usadas por serviços que repassam ou revendem acesso a provedores de IA para uso em destilação de modelos. Ela não confirmou se o invasor operava esses serviços, nem identificou o invasor.
No relatório Black October, os pesquisadores da Wiz citam esta invasão entre os incidentes divulgados em outubro por pelo menos nove plataformas de desenvolvimento de IA, incluindo a violação anterior da OpenCode.
Todos os relatos públicos descrevem invasores em busca de variáveis de ambiente armazenadas, especialmente as que concedem acesso a IA, afirmam os pesquisadores. Nenhuma falha única ou dependência de software conecta os ataques.
