- Por mais de 2 anos, um invasor usando o nome "Jia Tan" atuou como um colaborador dedicado e eficaz da biblioteca de compressão xz, até receber permissões de commit e, por fim, privilégios de administrador.
- Usando essas permissões, instalou um backdoor extremamente sutil e cuidadosamente oculto em
liblzma, parte do xz, que também é uma dependência do OpenSSH sshd em Debian, Ubuntu, Fedora e outros sistemas Linux baseados em systemd.
- Esse backdoor monitorava o início de sessões SSH em busca de comandos ocultos enviados pelo invasor, dando a ele a capacidade de executar comandos arbitrários no sistema-alvo sem fazer login. Trata-se de execução remota de código sem autenticação no alvo.
- O ataque foi revelado publicamente em 29 de março de 2024 e parece ser o primeiro ataque grave de cadeia de suprimentos contra um software open source amplamente utilizado.
- É um marco divisor de águas para a segurança da cadeia de suprimentos de open source.
- Este post é uma linha do tempo detalhada dos aspectos de engenharia social desse ataque, que aparentemente remonta ao fim de 2021.
Prólogo
- Entre 2005 e 2008, Lasse Collin, com a ajuda de outras pessoas, projetou o formato de arquivo
.xz usando o algoritmo de compressão LZMA, que comprime arquivos para cerca de 70% do tamanho obtido com gzip.
- Com o tempo, esse formato passou a ser amplamente usado para comprimir arquivos tar, imagens de kernel Linux e outros itens.
O surgimento de Jia Tan e dos apoiadores
- 2021-10-29: Jia Tan envia seu primeiro patch inofensivo para a lista de discussão xz-devel.
- 2021-11-29: Jia Tan envia um segundo patch inofensivo.
- 2022-04-19: Jia Tan envia outro patch inofensivo.
- 2022-04-22: "Jigar Kumar" reclama que o patch de Jia Tan ainda não foi mesclado.
- 2022-05-19: "Dennis Ens" pergunta sobre o status de manutenção do XZ for Java.
- 2022-05-19: Lasse Collin pede desculpas pela lentidão nas respostas e responde que "Jia Tan está ajudando com o XZ Utils fora da lista e talvez possa assumir um papel maior no XZ Utils".
- 2022-05-27: Jigar Kumar envia um e-mail de pressão na thread do patch.
- 2022-06-07: Jigar Kumar envia um e-mail de pressão na thread sobre Java.
- 2022-06-08: Lasse Collin responde que não perdeu o interesse, mas está limitado por questões de saúde mental.
- 2022-06-10: Lasse Collin mescla o primeiro commit escrito por Jia Tan.
- 2022-06-14: Jugar Kumar envia outro e-mail de pressão.
- 2022-06-21: Dennis Ens envia um e-mail de pressão sugerindo passar a manutenção para outra pessoa.
- 2022-06-22: Jigar Kumar envia um e-mail de pressão na thread do patch em C.
- 2022-06-29: Lasse Collin responde sugerindo que "Jia Tan pode assumir um papel maior no projeto".
Jia Tan se torna mantenedor
- Lasse parece ter começado a trabalhar mais de perto com Jia Tan. Jigar Kumar e Dennis Ens provavelmente eram personas falsas.
- 2022-09-27: Jia Tan fornece o resumo de lançamento da versão 5.4.0.
- 2022-11-30: Lasse Collin muda o e-mail de relatórios de bugs de seu endereço pessoal para um alias compartilhado com Jia Tan.
- 2022-12-30: Jia Tan mescla diretamente seu primeiro commit no repositório xz.
- 2023-01-11: Lasse Collin marca e compila sua última release, v5.4.1.
- 2023-03-18: Jia Tan marca e compila sua primeira release, v5.4.2.
- 2023-03-20: Jia Tan atualiza a configuração do Google oss-fuzz para que os bugs sejam enviados para ele.
- 2023-06-22: Hans Jansen envia um par de patches usando o recurso "GNU indirect function"; Lasse Collin retrabalha o código e Jia Tan faz o merge.
- 2023-07-07: Jia Tan desativa o suporte a ifunc durante builds do oss-fuzz.
- 2024-01-19: Jia Tan migra o site para GitHub Pages e passa a controlar a página do XZ Utils.
Início do ataque
- 2024-02-23: Jia Tan mescla código binário de backdoor oculto dentro de arquivos de entrada de teste.
- 2024-02-24: Jia Tan marca a v5.6.0 e publica o pacote de distribuição
xz-5.6.0.tar.gz, incluindo o build-to-host.m4 malicioso.
- 2024-02-24: O Gentoo começa a registrar travamentos na 5.6.0.
- 2024-02-26: Debian adiciona
xz-utils 5.6.0-0.1 ao unstable.
- 2024-02-28: Debian adiciona
xz-utils 5.6.0-0.2 ao unstable.
- 2024-02-29: No GitHub, @teknoraver envia um pull request para impedir que
liblzma seja ligada a libsystemd.
- 2024-02-28: Jia Tan adiciona um erro de digitação sutil a um programa em C usado para verificar suporte a Landlock, quebrando a detecção de Landlock no script
configure.
- 2024-03-04: Distribuições da RedHat começam a apresentar erros do Valgrind em
_get_cpuid da liblzma.
- 2024-03-05: O PR do
libsystemd é mesclado e liblzma é removida.
- 2024-03-05: Debian adiciona
xz-utils 5.6.0-0.2 ao testing.
- 2024-03-05: Jia Tan faz commit de uma correção de bug de ifunc.
- 2024-03-08: Jia Tan faz um commit com correção para o Valgrind.
- 2024-03-09: Jia Tan faz um commit atualizando os arquivos do backdoor.
- 2024-03-09: Jia Tan marca a v5.6.1 e publica a distribuição do xz 5.6.1.
- 2024-03-20: Lasse Collin envia à LKML uma série de patches adicionando ele mesmo e Jia Tan como mantenedores do código de compressão xz no kernel.
- 2024-03-25: Hans Jansen abre um bug no Debian para atualizar o
xz-utils para 5.6.1.
- 2024-03-28: Jia Tan abre um bug no Ubuntu para atualizar o
xz-utils do Debian para 5.6.1.
Detecção do ataque
- 2024-03-28: Andres Freund encontra o bug e alerta de forma privada o Debian e
distros@openwall. A RedHat atribui o CVE-2024-3094.
- 2024-03-28: Debian faz rollback da 5.6.1 e introduz
5.6.1+really5.4.5-1.
- 2024-03-29: Andres Freund publica um alerta sobre o backdoor na lista pública
oss-security@openwall, dizendo que o encontrou "nas últimas semanas".
- 2024-03-29: A RedHat anuncia que uma versão do xz com backdoor foi distribuída no Fedora Rawhide e no Fedora Linux 40 beta.
- 2024-03-30: Debian interrompe as builds e reconstrói as máquinas de build usando o Debian stable.
Opinião do GN⁺
- Este incidente tende a se tornar um ponto de virada importante para ataques à cadeia de suprimentos em software open source. Isso porque, por meio de uma abordagem de engenharia social de longo prazo por parte dos cúmplices, foi conquistada confiança e obtido acesso, para então instalar discretamente um backdoor em uma biblioteca central amplamente usada.
- É necessário repensar a governança de projetos open source e os processos de transferência de autoridade. Vale considerar modelos de governança distribuída para que circunstâncias pessoais de um mantenedor central não determinem o destino do projeto.
- Auditorias de segurança e revisão de código em grandes projetos open source se tornarão ainda mais importantes. Também são necessárias ferramentas automatizadas de verificação para detectar mudanças suspeitas e impedir abuso de privilégios, como alertas sobre inclusão de dados binários, por exemplo.
- Sem prejudicar as vantagens do modelo open source, em que o desenvolvimento é público e qualquer pessoa pode contribuir, será preciso criar medidas técnicas e institucionais capazes de filtrar colaboradores maliciosos e bloquear ataques precocemente.
- Quanto mais um projeto open source usar linguagens ou ferramentas frágeis em termos de segurança, maior tende a ser o risco. Além de esforços para elevar a segurança por vários ângulos, como segurança de memória, análise estática e fuzzing, também será exigida a migração para ferramentas modernas.
- Deve haver grande interesse por análises detalhadas sobre as condições ocultas de ativação do backdoor, a rota de disseminação e o escopo do impacto. Isso poderá trazer insights para defender ataques semelhantes no futuro.
7 comentários
O que me preocupa por causa desse caso é...
Hackearem o PC de um desenvolvedor de open source, ou sequestrarem/confinarem a pessoa, ou subornarem com dinheiro para inserir código malicioso...
Pensando em dinheiro, isso também me faz pensar se os desenvolvedores de open source estão conseguindo viver bem, sabe?
Eu trabalho com segurança, e quando encontro um bug durante code review, sempre sai aquela piada: “você entrou aqui há 5 anos só para plantar esse código, foi?” kkk
O Collin Lesser deve ter passado por maus bocados de várias formas...
Sim, o Arch Linux já corrigiu isso faz tempo~ pode vir, pode vir, isso mesmo, backdoor fora, o Arch mais recente é bom demais~
pacman -SyuParece que o Lasse Collin deixou um texto organizando esse caso
https://tukaani.org/xz-backdoor/
Comentários do Hacker News
Um excelente resumo do incidente, com todos os links reunidos em um só lugar, sendo um material perfeito para quem quer aprender como ataques de engenharia social realmente se desenrolam.
Aponta que a linha do tempo do Fedora foi omitida.
Defende que não deveríamos mais tolerar código difícil de entender dentro do sistema.
Isso parece ser um dos possíveis resultados positivos: uma postura mais conservadora em relação a upgrades.
Sugere que a comunidade FOSS pode passar a banir sistematicamente usuários grosseiros, ou promover uma mudança cultural que aumente a consciência da comunidade e reaja com mais firmeza a comportamentos rudes.
Aponta que a observação sobre o formato dos endereços de e-mail estava errada.
sockpuppets).Expressa preocupação com o quão facilmente a pressão social leva as pessoas a abrir mão do controle.
Como mantenedor, enfatiza que quanto mais insistente for um colaborador ou usuário em suas exigências, menor a chance de que esse pedido seja atendido.
Cita a opinião de Joe Cooper e compartilha sua visão sobre a pressão exercida sobre mantenedores de projetos.
Explica que o código binário oculto do backdoor estava muito bem escondido dentro de arquivos binários de entrada de teste, e como esses arquivos foram em sua maioria criados manualmente com um editor hexadecimal, os próprios arquivos são o melhor "código-fonte".