O desenvolvimento de software tem muitos desafios e o suporte é uma tarefa complexa que, em teoria, deveria ter uma equipe totalmente direcionada a corrigir bugs e garantir que não haja vulnerabilidades. É bem sabido que duas ou mais cabeças são melhores do que uma. Em um ciclo de desenvolvimento de software liderado por uma única pessoa, há uma tendência de cometer erros ao lançar uma nova atualização, mas e se alguém, do nada, decidisse ajudar nesse processo?

No início de abril, Andred Freund, engenheiro da Microsoft e desenvolvedor do PostgreSQL, divulgou uma vulnerabilidade crítica que afetava a cadeia de suprimentos de um utilitário de compactação de dados XZ implementado em todos os sistemas operacionais baseados em Linux/UNIX. Isso permitiria que um invasor contornasse a autenticação segura do shell e obtivesse acesso total ao sistema afetado.

A descoberta desse ataque à cadeia de suprimentos, um dos mais significativos até o momento, foi acidental. O que teria acontecido se a nova atualização tivesse chegado a milhares de servidores em todo o mundo? Poderia ter sido um grande desastre de segurança se tivesse sido integrado às versões estáveis das distribuições Linux?

A seguir, analisamos, de acordo com o histórico da versão (logs do GitHub), o passo a passo de como o invasor usou diferentes técnicas para se infiltrar no projeto e colocar em risco a segurança de milhares de servidores em todo o mundo.

A arte da guerra é baseada no engano: os "Sock Puppets" mal utilizados

Publicações anteriores mencionaram a importância dos Sock Puppets como ferramentas de OSINT que permitem que pesquisadores atuem sem serem descobertos ou deixarem rastros de seu trabalho; esses perfis evitam fazer login em contas pessoais e serem rastreados. No entanto, quando a intenção é invadir grandes projetos de software e ganhar a confiança dos desenvolvedores para introduzir códigos maliciosos, não há limites.

Foi o que aconteceu com aqueles que apoiam o XZ Utils. Analisando mais de perto a pessoa responsável por introduzir deliberadamente esse código malicioso nas versões 5.6.0 e 5.6.1, está o usuário do GitHub cujo pseudônimo é Jia Tan (também conhecido como Jia Cheong Tan ou JiaT75).

Logo-proyecto-xz
Imagem 1: Logotipo do projeto XZ.

A história de como Jia Tan (JiaT75) conseguiu se infiltrar no projeto XZ é a seguinte:

No ano de 2021, JiaT75 criou sua conta no GitHub e suas primeiras contribuições não foram para o projeto do utilitário de compactação, mas para outros de menor impacto, ou seja, ele fingiu ser alguém desinteressado em buscar o "bem da comunidade", de forma bastante discreta, mas com bastante conhecimento.

No início de 2022, JiaT75 conseguiu fazer seu primeiro commit na biblioteca XZ: essa contribuição foi devido ao envio de um patch por meio de uma lista de discussão, e foi aqui que ele começou a pressionar a equipe de desenvolvedores para incorporar o patch lançado por JiaT75.

Alguns dias depois e após a pressão, Lasse Collin (atual e único desenvolvedor que apoia o projeto XZ) admitiu o JiaT75 para testar os recursos de hardware.

project-contribution
Imagem 2: Primeira contribuição de JiaT75 como parte da equipe de desenvolvimento do XZ. Fonte: GitHub.

Em junho de 2023, JiaT75 testa a biblioteca "liblzma" e implementa no método "ifunic" o ponteiro chamado "crc64_fast.c".

JiaT7-codigo-incorporado-proyecto
Imagem 3: JiaT75 começa a incorporar o código ao projeto XZ. Fonte: GitHub.

Em julho de 2023, um Pull Request é aberto no OSS-FUZZ (um projeto que visa tornar o software de código aberto comum mais seguro e estável combinando técnicas modernas de fuzzing) e o método "ifunc" é desativado devido a problemas introduzidos pelas alterações anteriores. Isso parece ter sido deliberado para mascarar as alterações maliciosas que serão introduzidas em breve.

No início de 2024, o Google alterou a URL do projeto de "tukaani.org/xz/" para "xz.tukaani.org/xz-utils/", este último hospedado na Finlândia e dando ao JiaT75 mais controle sobre o projeto a partir da versão "5.44.245.25xz".

Em fevereiro de 2024, o JiaT75 adiciona o primeiro arquivo malicioso "build-to-host.m4" para ser incorporado posteriormente ao pacote de atualização.

Pouco tempo depois, em março de 2024, o JiaT75 adicionou dois arquivos de teste ofuscados e criptografados (bad-3-corrupt_lzma2.xz e good-large_compressed.lzma), nos quais Andres Freund encontrou o backdoor.

A descoberta, assim como aconteceu com Alexander Fleming e a penicilina, ocorreu quando Andres Freund estava fazendo alguns testes de microdesempenho e percebeu que a CPU e a biblioteca "liblzma" estavam consumindo mais recursos do que nas versões anteriores.

Assim, em 29 de março de 2024, Andres Freund decide relatar esse incidente no openwall para que imediatamente a biblioteca e as versões 5.6.0 e 5.6.1 do XZ sejam removidos do GitHub.

Lições aprendidas

Para resumir o que você pode aprender com esse ataque, podemos dizer que:

  • Quando cibercriminosos têm um alvo, eles podem se esforçar ao máximo para se infiltrar em projetos, empresas ou cadeias de suprimentos;
  • Como Sun Tzu disse na Arte da Guerra: A paciência é a virtude do guerreiro. A dedicação e a paciência de JiaT75 para ganhar a confiança de Lasse Collin e se tornar uma das referências no projeto XZ é algo com que você deve ter muito cuidado;
  • Esse não é o primeiro e nem o último incidente, há também o Apache Log4j, no qual, mais uma vez, há uma dependência de software de código aberto e projetos executados por voluntários e comunidades cujas intenções são, em sua maioria, o bem-estar digital, mas, como vimos, há também aqueles que buscam o oposto;
  • As organizações, os desenvolvedores e as comunidades devem ter ferramentas e processos que lhes permitam identificar a manipulação e a inserção de códigos maliciosos no desenvolvimento de software, evitando que eles afetem um grande número de dispositivos.