O backdoor do XZ: CVE-2024-3094

Em 29 de março de 2024, um agente malicioso executou uma campanha prolongada e de alto investimento para inserir um backdoor na biblioteca de software liblzma, usada em distribuições Linux, a fim de obter acesso a vários sistemas operacionais — e, ao que tudo indica, teve sucesso até que um engenheiro atento percebeu uma falha.

Softwares upstream afetados conhecidos até o momento e medidas de mitigação propostas:

O que é XZ?

XZ, também conhecido como XZ Utils, oferece uma interface de linha de comando para compactação e descompactação e costuma vir incluído em distribuições Linux, como Debian, Ubuntu e muitas outras.

// Example usage of XZ for context:
$ xz llm_rag_context.json

// Results in a new compressed file on disk:
$ ls -al llm_tag_context.json.xz
.rw-r--r--   81k lirantal 31 Mar 10:29   -N  llm_tag_context.json.xz

O que é Liblzma?

Liblzma é a biblioteca de software que implementa o algoritmo de compactação e descompactação LZMA e oferece vinculações para que outras linguagens de programação possam usá-lo, como o programa de linha de comando xz.

O que é CVE-2024-3094?

O identificador da vulnerabilidade CVE-2024-3094 foi publicado em 29 de março de 2024 para registrar a pontuação crítica de gravidade 10,0 no pacote liblzma.

O relatório da CVE atribui o risco de segurança a um código malicioso encontrado na biblioteca de software liblzma, que permitia modificar dados ao interagir com o código da biblioteca, comprometendo a integridade e podendo levar a consequências ainda mais graves.

Qual é o impacto do backdoor do XZ?

O protocolo SSH e seu conjunto de ferramentas no Linux permitem o acesso remoto entre hosts. Como o backdoor do XZ permite interceptar e modificar dados, e algumas distribuições Linux disponibilizam liblzma para o programa SSH, podemos supor inicialmente que um dos impactos da CVE-2024-3094 poderia ser o desvio da autenticação no programa sshd.

Em termos simples, alguém com uma chave RSA poderia se autenticar remotamente em qualquer servidor SSH aberto e comprometido pelo backdoor.

Agora, especula-se que o backdoor do XZ possa permitir a execução remota de código. No entanto, uma investigação está em andamento para analisar o código do backdoor inserido em liblzma e rastrear todas as contribuições feitas pelo agente malicioso e relacionadas a ele.

Cronologia para contextualizar:

• O arquivo de build malicioso foi adicionado ao pacote Debian xz-utils em 24 de fevereiro de 2024.

• A versão 5.6.0 do tarball xz-utils foi lançada em 24 de fevereiro, e a versão 5.6.1, em 9 de março de 2024.

• A versão 5.6.0 foi adicionada ao Fedora em 27 de fevereiro de 2024.

A história do backdoor do XZ

Uma violação de segurança grave foi relatada em 29 de março de 2024, quando Andres Freund, colaborador da lista de discussão oss-security da Openwall, revelou um possível comprometimento da biblioteca liblzma, parte do amplamente usado pacote XZ Utils.

A descoberta ocorreu depois que Freund percebeu um uso de CPU excepcionalmente alto pelo processo sshd, o que levou a uma investigação mais aprofundada.

A origem do problema está em arquivos de teste compactados e maliciosos, incorporados às versões 5.6.0 e 5.6.1 de liblzma, com o objetivo de criar um backdoor por meio de alterações no script configure dos arquivos tar. Embora permaneça inativo em condições normais, o exploit é ativado em sistemas que usam um patch específico para o servidor SSH. Isso permite contornar a autenticação do sshd e obter acesso remoto não autorizado ao sistema.

A captura de tela a seguir foi retirada da análise do malware XZ feita por Andres e enviada à lista de discussão OSS-Security da Openwall:

Esse exploit sofisticado aproveita o mecanismo IFUNC da GNU C Library, conhecida como glibc, para adicionar um resolvedor ao método crc64_resolve. Ele instala um hook de auditoria para substituir a função RSA_public_decrypt do OpenSSH por uma versão comprometida. Em geral, o OpenSSH não precisa de liblzma. No entanto, o exploit tira proveito de uma situação de carregamento em cadeia: um patch de terceiros faz com que libsystemd seja carregada, o que, em seguida, carrega a biblioteca de software afetada liblzma. Até o momento, o backdoor afeta o sshd apenas em um subconjunto de distribuições Linux que aplicam esse patch para habilitar notificações do systemd

Um aspecto particularmente insidioso do ataque foi a inclusão de um arquivo build-to-host.m4 modificado no lançamento do tar hospedado no GitHub. Esse arquivo não estava no repositório Git e, portanto, não era possível rastrear sua origem no controle de versão.

Esse arquivo de build M4 extrai e injeta o código malicioso durante o processo de build em sistemas específicos: plataformas x86-64 Linux que usam glibc e GCC, compiladas com dpkg ou rpm, ferramentas populares de build de pacotes para as distribuições Linux Debian e Red Hat.

Como consequência dessa violação, o GitHub arquivou o repositório que hospedava o XZ Utils por violação dos termos de serviço. A investigação sobre a origem do backdoor aponta para Jia Tan, mantenedor do projeto xz, mas ainda não está claro se o ato foi intencional ou se a conta do mantenedor foi comprometida. A verdadeira identidade por trás dessa conta ainda precisa ser determinada.

Esse ataque à cadeia de suprimentos afetou várias distribuições Linux, incluindo Debian 13 e unstable, Fedora Rawhide, Fedora 40, Kali Linux e OpenSUSE Tumbleweed. O Arch Linux pediu aos usuários que atualizassem o sistema o quanto antes. A maioria das distribuições que seguem um protocolo de atualização para versões estáveis não foi afetada, pois usava versões antigas do XZ. O FreeBSD também não foi afetado, graças ao uso de versões do XZ anteriores ao incidente e ao fato de o ataque ter como alvo a glibc do Linux. Por outro lado, se você automatizou a implantação de imagens de contêiner usando as atualizações mais recentes disponíveis do Fedora ou Debian, por exemplo, pode ter distribuído o programa XZ vulnerável.

Rastreado como CVE-2024-3094 e classificado com pontuação CVSS 10, a mais alta possível, esse incidente ressalta a importância crítica da segurança da cadeia de suprimentos e a complexidade de confiar em contribuições de código aberto e verificá-las.

Revertendo os danos: a operação de limpeza do XZ

Quando o caso veio à tona, Lasse Collin, mantenedor original da biblioteca XZ Utils, correu para enviar uma correção de código à configuração de build da biblioteca. Esse diff de código mostra o trabalho ardiloso e elaborado do agente malicioso para executar sua campanha de backdoor. O caractere ponto (.) provocava uma falha na ferramenta de build, fazendo com que ela desativasse um sandbox de segurança e contornasse os controles de segurança.

Como detectar a vulnerabilidade do XZ com a Snyk

Há várias maneiras de detectar a vulnerabilidade do XZ — gratuitamente — com a Snyk. Com a Snyk CLI, você pode testar seus projetos localmente:

• Para aplicações, execute snyk test --unmanaged pela Snyk CLI para comparar as dependências não gerenciadas do seu repositório e detectar pacotes individuais e suas vulnerabilidades.

• Para contêineres, execute snyk container test para detectar pacotes de sistemas operacionais compatíveis que dependem de versões vulneráveis do XZ.

Você também pode fazer uma varredura em todos os projetos dos seus repositórios Git para gerar um relatório de todas as dependências diretas e transitivas que você usa. 

Nesse relatório, você verá se usa o XZ e quantos caminhos do seu grafo de dependências passam por ele. Você também pode pesquisar rapidamente por "CVE-2024-3094" em todos os projetos. 

O encontro entre a segurança da cadeia de suprimentos e o código aberto

O backdoor do XZ repercutiu nas comunidades de código aberto e cibersegurança, gerando debates e preocupações sobre a integridade dos softwares de código aberto e o risco constante de ataques à cadeia de suprimentos. O incidente é um alerta contundente, que remete à violação da SolarWinds e aos diversos pacotes maliciosos encontrados em repositórios de software como npm e PyPI, evidenciando um padrão de vulnerabilidades na cadeia de suprimentos com graves implicações para a cibersegurança global.

Jia Tan, que surgiu no GitHub com o nome de usuário JiaT75, e personas associadas, como Jigar Kumar e Dennis Ens, demonstraram uma campanha sofisticada de vários anos para inserir código malicioso no XZ Utils, um utilitário de software essencial usado em inúmeras distribuições Linux. A estratégia começou com contribuições aparentemente inofensivas e evoluiu para pressionar diretamente os mantenedores do projeto a conceder acesso para fazer commits. As táticas foram ardilosas e combinaram técnicas de engenharia social e de exploração técnica para tirar proveito da confiança e da colaboração características da comunidade de código aberto.

O histórico do envolvimento de Jia Tan com o XZ Utils, que começou com atividades suspeitas em outros projetos, como libarchive, revela uma trama complexa de ações premeditadas que culminaram na descoberta da CVE-2024-3094. Essas ações incluíram a criação de uma infraestrutura de testes e tentativas deliberadas de ocultar a intenção maliciosa por meio do uso indevido de implementações ifunc, demonstrando um nível assustador de premeditação e manipulação.

Esse incidente levanta questões fundamentais sobre a sustentabilidade da confiança e da segurança em softwares de código aberto. A própria natureza do código aberto — sua transparência e dependência das contribuições da comunidade — pode se tornar seu calcanhar de Aquiles quando agentes maliciosos se infiltram com a intenção de causar danos. O incidente também evidencia o estresse intenso e os desafios de saúde mental enfrentados pelos mantenedores, que muitas vezes dedicam seu tempo e conhecimento voluntariamente, sob enorme pressão para manter os projetos seguros e atualizados.

Não podemos ignorar as semelhanças com incidentes anteriores, como a violação em larga escala da SolarWinds ou o fluxo constante de pacotes contaminados em repositórios públicos de software. Todos esses casos têm algo em comum: a exploração da confiança e a complexidade das cadeias de suprimentos de software modernas. Eles nos lembram da sofisticação dos adversários cibernéticos e das vulnerabilidades nas infraestruturas digitais das quais dependemos cada vez mais.

Diante da CVE-2024-3094 e dos precedentes históricos, a comunidade de código aberto e o setor de tecnologia como um todo precisam reavaliar e reforçar as práticas de segurança relacionadas ao desenvolvimento e à distribuição de software. Isso inclui analisar as contribuições com mais rigor, implementar processos de verificação mais robustos para os mantenedores e promover uma colaboração maior em torno das boas práticas de segurança. Além disso, é urgente criar modelos sustentáveis de financiamento para projetos de código aberto, garantindo que os mantenedores tenham os recursos e as ferramentas necessários para proteger seus softwares com eficácia.

Ao lidar com as consequências deste e de outros incidentes semelhantes, precisamos promover discussões abertas e críticas sobre o equilíbrio entre os princípios do código aberto e a necessidade de segurança. A resiliência dos softwares de código aberto e do ecossistema digital depende da nossa capacidade coletiva de nos adaptar e reforçar as defesas contra quem tenta comprometê-los.

Quem é Jia Tan? É uma pessoa ou um agente patrocinado por um Estado-nação? Que outros projetos essa pessoa pode ter comprometido e infectado com backdoors? Pesquisadores de segurança e desenvolvedores estão rastreando ativamente os commits de Jia Tan no Git, sua origem, seu fuso horário e quaisquer outras informações que possam encontrar para reunir as peças.

Como os SBOMs podem ajudar a reduzir os riscos da CVE-2024-3094

• A lista de materiais de software (SBOM) oferece visibilidade sobre os componentes e as versões do software, inclusive nas dependências transitivas.

• Os SBOMs ajudam a acompanhar o andamento das correções e garantir que todos os projetos afetados sejam corrigidos.

• Depois de atualizadas, as SBOMs podem ser usadas para demonstrar que os patches ou correções necessários foram aplicados com sucesso.

O que fazer agora?

• Siga as orientações de este relatório da Cybersecurity & Infrastructure Security Agency (CISA) sobre as atualizações para a CVE-2024-3094

• Teste sua SBOM com o SBOM Checker da Snyk

• Confira esta atualização da Dark Reading