¿Conversamos?

A semana de correções e a chave nunca revogada do LiteLLM

Ilustração abstrata em fundo creme: uma coluna de hexágonos cinza escuros, cada um no começo de uma fileira de hexágonos claros com um ou dois em vinho; numa só fileira, puxada por um hexágono vermelho em destaque, todos os hexágonos são vinho e a fileira segue além da borda da imagem

Na quarta passada saíram correções urgentes pra PHP, Node.js e GitLab, e quem usa o LiteLLM teve que conferir se não tinha instalado uma versão maliciosa.

A falha do Node.js, no decodificador de compressão Brotli, foi creditada ao Codex Security, da OpenAI. No PHP, três organizações acharam em agosto a mesma causa de duas falhas críticas, cada uma por conta própria, e as três dizem ter usado IA. Os primeiros sinais dessas falhas tinham aparecido numa auditoria externa em 2024, e a correção ficou meses parada esperando decisão. A PHP Foundation chamou isso de falha estrutural do processo de decisão do time de segurança.

Por precaução, vários governos tiraram serviços do ar nesses dias. O governo federal orientou os órgãos a desligar temporariamente os sistemas feitos em PHP. A Anatel deixou o SEI fora do ar da tarde até a noite de quarta, tribunais regionais federais cortaram o acesso externo ao SEI, e o TRF6 chegou a suspender o eproc e os prazos processuais. Aqui no Recife, a prefeitura tirou do ar o Conecta Recife, o Portal da Transparência e outros serviços, e até segunda a fiscalização da Zona Azul seguia suspensa. Na Finlândia, na Holanda, na Dinamarca e na França, órgãos de governo fizeram o mesmo. O Derick Rethans, do core do PHP, disse que o projeto não fez essa recomendação, mas que em alguns casos provavelmente é sensato.

Contra essas falhas do PHP já teve tentativa de ataque e código executado em servidores-isca. Na segunda, a CISA, agência de cibersegurança dos EUA, pôs as duas na lista de falhas exploradas na prática, mas até agora nenhuma empresa ou órgão confirmou publicamente uma invasão por elas.

O LiteLLM, um gateway de IA em Python, ficou com versões maliciosas no PyPI por cerca de duas horas na quarta. O atacante apontou a publicação pra um fork de nome parecido, disparou com um token roubado e aprovou com outro. Na mesma semana, o LiteLLM tinha afrouxado a regra de publicação pra soltar versões com mais frequência. Antes, publicar pedia aprovação de uma conta presa a um dispositivo físico no escritório, e passou a bastar a de quaisquer dois engenheiros.

Esses tokens vieram de uma chave exposta em maio. O LiteLLM tem uma plataforma interna que orquestra agentes que abrem PRs no GitHub, e a chave mestra dela foi parar num repositório público. O commit foi apagado rápido, e a chave foi marcada pra revogação, mas nunca foi revogada. Em 10 de outubro, o atacante usou essa chave e recebeu da própria plataforma o token com que ela abria os PRs. Era um token da conta do dono da organização no GitHub, sem conta de serviço e sem escopo reduzido. A partir dele, chegou aos tokens de mais dois mantenedores.

Por isso, numa operação com agentes que abrem PR, eu conferiria primeiro se toda chave que já apareceu em lugar público foi revogada, mesmo que o commit já tenha saído do histórico. Depois eu veria se cada agente tem identidade própria, com acesso só aos repositórios e às ações que usa, sem usar o token de alguém do time.

Fontes

O comunicado da PHP Foundation sobre as correções e o processo de segurança

A entrevista com o Derick Rethans sobre o que aconteceu no PHP

As correções de segurança do Node.js de outubro

A execução de código registrada nos servidores-isca

A CISA colocando as duas falhas na lista de exploradas

Como o ataque ao LiteLLM aconteceu, contado por eles

Os órgãos públicos que suspenderam o SEI e outros sistemas no Brasil

Os serviços da Prefeitura do Recife que seguem fora do ar

Os governos europeus que tiraram sites do ar

Tome asiento.

Cuéntenos el desafío de su negocio. Empezamos por él.

¿Conversamos?