Uma análise aprofundada do compromisso xz

Vá direto para um resumo gerado por IA desta postagem do blog

O xz é um pacote amplamente distribuído que oferece compressão sem perdas tanto para usuários quanto para desenvolvedores, e está incluído por padrão na maioria, se não em todas, as distribuições Linux. Criado em 2009, já teve inúmeras versões lançadas desde então.

Por ser um projeto de código aberto, ele está disponível no GitHub. No entanto, até o momento da redação deste artigo, ao tentar acessar a página do projeto é recebido com uma mensagem informando que “este repositório foi desativado devido a uma violação dos termos de serviço”, em vez da página tradicional do GitHub. Essa violação ocorreu devido à distribuição de malware. Neste artigo, vamos investigar o que, o porquê, o como e, talvez, até mesmo o “quem” está por trás desse incidente.

Quando a notícia veio à tona no final da semana, pouco antes da Páscoa, o meio de segurança cibernética do Twitter entrou em polvorosa, com os detetives da internet obcecados por cada detalhe. Este artigo se baseia amplamente nas informações coletadas e publicadas por essas investigações, grande parte das quais está reunida aqui, além de informações obtidas por meio da própria pesquisa do autor. A atribuição é feita por meio de links para as fontes originais, sempre que possível; nos casos em que não há link direto para a fonte, o leitor pode presumir que a informação provém do resumo do GitHub que resume o evento ou desta linha do tempo.

Tenha em mente que essa história é muito recente. Ainda há alguns aspectos não esclarecidos e algumas indicações da (improvável) possibilidade de que a pessoa inicialmente considerada responsável pelo incidente possa não ser, necessariamente, a culpada. Isso é discutido mais detalhadamente na seção de ressalvas deste artigo.

Preparem-se, a história vai bem fundo nessa.

Contexto histórico

O projeto xz, assim como muitos outros projetos de código aberto, surgiu como um projeto pessoal de um único desenvolvedor que teve uma ideia e a compartilhou com o mundo. Em 2009, Lasse Collins, que anteriormente era responsável pela manutenção do lzma-utils, outro projeto relacionado à compactação, criou o xz. Ele foi projetado como uma extensão, ou evolução, do lzma, a ponto de a liblzma agora ser fornecida como parte do pacote xz por padrão.

Como é comum na maioria dos projetos conduzidos por uma única pessoa, o autor foi responsável pela maior parte do código e por gerenciar os commits ocasionais de terceiros, integrar o código ao repositório e publicar novas versões. À medida que o projeto ganhou destaque, a carga de gerenciamento tornou-se mais pesada e, por fim, outros colaboradores foram reconhecidos por seus esforços e receberam permissões para gerenciar tarefas como revisar código, aceitar ou rejeitar envios e gerenciar o repositório.

Jia Tan, um desenvolvedor que já havia contribuído para o projeto, recebeu permissões para fazer commits e, posteriormente, para gerenciar lançamentos há pouco mais de dois anos. Em retrospecto, o processo de adição de um novo mantenedor parece ter feito parte de uma campanha de engenharia social dirigida a Lasse Collins. A linha do tempo dessas trocas de e-mails pode ser vista aqui.

Devido à pressão e às acusações de abandono do projeto ou de perda de interesse, vários usuários diferentes (ou talvez uma única pessoa por trás de vários nomes de usuário) enviaram mensagens para a lista de discussão do projeto. Eles reclamaram dos atrasos na aceitação de patches, no lançamento de novas versões e na adoção de métodos diferentes, até que o líder do projeto passou a contar com um colaborador novo, mas entusiasmado. As contas de e-mail por trás dessas táticas de pressão parecem não ter nenhuma presença na Internet além dessa lista de discussão.

Dizer que o xz é amplamente utilizado é um eufemismo. O xz é um dos formatos de compactação que você pode usar para empacotar o kernel do Linux em um sistema, tornando-o indispensável para a inicialização desse sistema. As taxas de compactação alcançadas e a velocidade de descompactação fazem dele uma opção perfeita para versões que economizam espaço, imagens do kernel e outros componentes.

O Tempo Perdido

Em uma reviravolta irônica do destino, um engenheiro de software da Microsoft, Andrés Freund, estava realizando medições de tempo em máquinas virtuais Linux para estabelecer uma linha de base para uma tarefa não relacionada. Ele começou a notar algum “ruído” nas leituras. O processo sshd, responsável por aceitar conexões remotas via Secure Shell, estava consumindo uma quantidade excessiva de CPU mesmo em tentativas de conexão malsucedidas, com um atraso de 500 ms afetando as conexões. Esse atraso inexplicável levou Freund a investigar mais a fundo, utilizando ferramentas de monitoramento de desempenho (perf) e depuração (dbg) para identificar o problema.

Ele descobriu um backdoor no xz. Especificamente, ele identificou a porta dos fundos e o código injetado, já que a porta dos fundos operava aproveitando certas funções chamadas pelo sshd. É importante observar — e leitores mais atentos talvez já saibam disso — que o sshd não depende do xz nem da liblzma. No entanto, em sistemas que usam o systemd para carregar o sshd, o systemd inclui a liblzma como dependência. Essa conexão permitiu que o código do backdoor fosse introduzido no sshd. Os sistemas que se enquadram nessa categoria incluem o Fedora, o Ubuntu, o Debian e a maioria de suas distribuições derivadas.

A porta dos fundos

O método pelo qual o código foi introduzido no xz (e na liblzma) envolveu a adição de alguns arquivos binários ao repositório do xz e um processo de compilação comprometido. Esses arquivos, originalmente enviados por Jia Tan como parte de um “conjunto de testes” para o xz, eram blobs binários “criados manualmente com um editor hexadecimal”. Ler código-fonte já é uma tarefa complexa, mas ler código binário é quase impossível. Há um comentário irônico de que “não há código-fonte melhor do que os próprios arquivos”. De fato.

O commit que incluía os arquivos maliciosos foi feito em 23 de fevereiro de 2024. Pelo que se sabe até o momento, o código malicioso está presente em apenas dois dos arquivos binários, enquanto os demais parecem executar as funções para as quais foram criados — testar diferentes condições de falha no processo de compactação ou descompactação do xz e da liblzma.

Um dos aspectos notáveis do backdoor é que, se um usuário aleatório baixasse o código do repositório xz e o compilasse após a inclusão do backdoor, ele não obteria um binário comprometido (pelo menos é o que se supõe atualmente, embora isso possa ser refutado posteriormente). O código de injeção propriamente dito só seria incluído na saída se um arquivo específico chamado “build-to-host.m4” estivesse presente durante a compilação, mas esse arquivo também foi adicionado ao “.gitignore”, tornando-o inacessível às operações comuns do Git normalmente utilizadas pelos usuários finais. No entanto, ele é utilizado durante o processo de compilação de um pacote de uma distribuição Linux.

Essa abordagem tinha como objetivo principal fazer com que o código fosse incorporado a distribuições reais do Linux, ao mesmo tempo em que tornava mais difícil para os pesquisadores de segurança reproduzirem o incidente em um ambiente controlado.

Em 24 de fevereiro, um dia após a adição dos arquivos maliciosos, o mesmo usuário marcou (ou seja, apresentou como a próxima versão) o xz-5.6.0. As distribuições Linux costumam adotar novas versões dos pacotes e, por exemplo, o Debian incluiu essa versão no repositório “unstable” alguns dias depois.

No dia 28, foi adicionado um patch adicional de Jia Tan que interferia na detecção do landlock durante o processo de compilação. O “landlock” é um recurso de segurança que impede (entre outras coisas) a vinculação e a importação indevidas de código, o que seria acionado se estivesse habilitado durante a compilação; portanto, ele precisou ser contornado para que o ataque fosse bem-sucedido.

Isso foi feito de maneira muito sutil. Um único “.” (ponto) adicionado ao arquivo “CMakeLists.txt” interrompeu a compilação da verificação da sandbox, fazendo com que a detecção de landlock sempre retornasse falso, o que, por sua vez, sempre a desativava para o código malicioso. Essa alteração não foi detectada quando enviada. É importante ressaltar que Lasse Collins (e não Jia Tan) é creditado por esse commit, o que pode ter sido falsificado, ou a alteração muito sutil não foi percebida antes da adição do código.

Vale destacar que, em 29 de fevereiro, uma solicitação de pull no projeto systemd pediu que se parasse de vincular a liblzma para reduzir o tamanho das imagens. Isso teria impedido o ataque. Esse evento parece não ter relação com o ataque em si e é considerado uma coincidência que pode ter acelerado o cronograma; não se sabe se conversas anteriores sobre o assunto eram públicas e do conhecimento do invasor.

A função que invoca o código malicioso é a _get_cpuid. Pode haver outras funções ainda a serem descobertas. Essa função executaria o código malicioso antes de realizar a tarefa original da _get_cpuid e retornar o resultado, adicionando a latência observada pelo engenheiro da Microsoft. Mais especificamente, essa função é chamada no início do processo de validação do certificado, ao iniciar uma conexão.

Algumas distribuições começaram a observar erros do Valgrind nessa função durante a análise. Em 8 de março, Jia Tan enviou um código para corrigir as detecções do Valgrind, o que, em retrospecto, parece simplesmente desativar a análise do código malicioso.

No dia seguinte, 9 de março, Jia Tan atualizou os arquivos com backdoor, sob o pretexto de que “eles foram criados com aleatoriedade local à sua máquina e, para reproduzi-los melhor no futuro, deveria ser usado um valor de semente constante”. Mais uma vez, os arquivos binários são difíceis de analisar, especialmente quando o código do backdoor se limita a selecionar valores de locais predefinidos dentro do blob binário, tornando a detecção praticamente impossível. No mesmo dia, ele marcou e lançou a versão xz-5.6.1.

Em 25 de março, uma das contas de e-mail usadas para pressionar o mantenedor original do xz reapareceu, agora pressionando o projeto Debian a incluir a nova versão do xz. Outras contas aparentemente fantasmas se juntaram para aumentar a pressão.

Em 28 de março, Jia Tan enviou um relatório de bug ao Ubuntu solicitando a inclusão do xz-5.6.1, já que o Debian já o havia incluído.

O comportamento malicioso é direcionado especificamente a sistemas x86-64 que executam a glibc (depende de uma função fornecida pela glibc) e que executam o sshd por meio do systemd. Esse conjunto de condições corresponde às distribuições baseadas no Debian e no Red Hat.

A desofuscação e a análise do código malicioso revelaram que ele era ativado sempre que uma conexão de entrada era recebida no sshd. Só recentemente se descobriu que o código espera uma chave pública específica ao receber uma conexão. Se essa chave não estiver presente, o sshd funcionará normalmente. No entanto, quando uma chave controlada pelo invasor está presente, o código aciona um comportamento diferente, controlado remotamente.

Detecção, e o mundo do código aberto fica abalado

Em 28 de março, a investigação de Andrés Freund levou à identificação da porta dos fundos. As distribuições foram notificadas, e foram lançadas atualizações que, essencialmente, reverteram os pacotes para uma versão anterior ao envolvimento de Jia Tan no projeto xz. Isso significa que agora existe uma “5.6.1+na verdade 5.4.5” do xz disponível nos repositórios de várias distribuições.

Até o momento, as distribuições que reconheceram a presença do pacote comprometido incluem o Fedora Rawhide, o Fedora 40 beta e o Debian.

Como o xz desempenhava um papel crucial no próprio processo de compilação de pacotes, o projeto Debian optou por reconstruir todo o seu sistema de compilação, já que vinha utilizando uma versão do xz que incluía os patches de Jia Tan (antes da suposta inclusão do backdoor).

Um ataque à cadeia de suprimentos pode ter um alcance impressionante. Embora isso seja frequentemente mencionado, só se torna realmente evidente com provas claras e inequívocas, como neste ataque.

Ao analisar essa situação, várias questões se tornam evidentes:

Em primeiro lugar, a forma como os projetos de código aberto são conduzidos, sem financiamento e recursos adequados, leva a situações em que os mantenedores podem ficar sobrecarregados e serem levados a aceitar compromissos que estão aquém do ideal. Essa vulnerabilidade permite que agentes mal-intencionados se infiltrem e, eventualmente, assumam o controle de projetos-chave.

Em segundo lugar, o xz foi apenas o projeto que foi afetado. Se não fosse pelo atraso causado pelo código malicioso — que provavelmente poderia ter sido otimizado com mais tempo —, esse ataque talvez nem tivesse sido detectado, e todos acabariam executando uma versão comprometida do xz em seus sistemas baseados no Debian e no Red Hat. Ao reverter o xz, presume-se que essa ameaça específica tenha sido neutralizada. No entanto, a certeza dessa afirmação ainda não está clara neste momento.

Em terceiro lugar, código é adicionado a projetos de código aberto a cada minuto de todos os dias, em inúmeros projetos diferentes. A forma como as dependências são utilizadas e verificadas permite que uma cascata de desvíos alcance o alvo pretendido, mesmo que nenhum código malicioso chegue a tocar diretamente no pacote que o invasor pretendia atingir.

Em quarto lugar, o argumento de que o código-fonte aberto é mais seguro simplesmente por ser aberto é um falacioso. Esse argumento só se sustenta enquanto houver um número suficiente de pessoas, devidamente motivadas, examinando minuciosamente cada linha de código, de cada projeto, em cada commit. Isso requer um grande número de profissionais altamente qualificados, realizando uma quantidade significativa de trabalho não remunerado, por tempo indeterminado. A capacidade de verificar e avaliar o código só é eficaz se essas verificações e avaliações estiverem realmente sendo realizadas. Mesmo assim, devido à sua própria natureza e aos métodos disponíveis para ofuscação, é possível introduzir código malicioso em projetos desavisados. Na verdade, pode-se argumentar que, do ponto de vista da segurança, a disponibilidade do código-fonte também pode ajudar — e talvez de forma significativa — agentes mal-intencionados que buscam identificar vulnerabilidades, mais do que ajuda os usuários finais. Embora o código-fonte ofereça muitos benefícios inegáveis, a segurança intrínseca nem sempre é um deles. Essa porta dos fundos foi descoberta inteiramente por acaso, e não porque alguém estivesse revisando ativamente o código.

Em quinto lugar, construir uma reputação na comunidade de código aberto muitas vezes depende exclusivamente do histórico de commits no GitHub e de nada mais. Demonstrar interesse em um projeto e contribuir com algumas correções de código costuma ser suficiente para ser aceito. Demonstrar vontade de ajudar pode ser facilmente simulado. Isso torna muito difícil identificar indivíduos específicos por trás de contas essencialmente anônimas. Um usuário pode ter várias contas ou criar contas falsas quando uma conta se torna suspeita ou é identificada como maliciosa. Uma organização com recursos suficientes pode criar e manter um exército dessas contas.

Em sexto lugar, muitas vezes não há um plano de recuperação de desastres claramente definido para a maioria dos projetos de código aberto. Retornar a um estado conhecido como seguro é um desafio se for difícil até mesmo determinar qual é esse estado. Embora uma conta esteja sendo responsabilizada por esse ataque, não se sabe ao certo se foi a única utilizada.

A possível ressalva

A partir da análise do desenrolar desse incidente, tudo parece indicar o envolvimento de um agente ou grupo malicioso com recursos financeiros consideráveis e altamente qualificado. Algumas observações dignas de destaque incluem:

Jia Tan parece seguir um horário de trabalho das 9h às 17h (ou 18h). As atividades de commit e no GitHub sugerem esse padrão, sendo que os fins de semana e feriados, consistentes com os de certos países, ficam evidentes à primeira vista. No entanto, é importante observar que os carimbos de data e hora nos commits do Git podem ser manipulados à vontade e — comparado ao nível de especialização demonstrado no código da backdoor — alterar a hora de um commit é algo trivial.
Jia Tan contribuiu com código para vários projetos além do xz. Na verdade, a conta chegou a enviar código para o OSS-Fuzz, uma ferramenta projetada para identificar comportamentos maliciosos ou com falhas em projetos de código aberto, bem como para vários outros projetos relacionados à compactação. Todo esse código está agora sob análise e não é mais considerado confiável.
Curiosamente, o fuso horário dos commits em que os arquivos maliciosos foram enviados difere do fuso horário normalmente associado à conta de Jia Tan. Uma análise detalhada dessa inconsistência pode ser encontrada aqui, mas isso levantou a possibilidade de que a conta do desenvolvedor tivesse sido comprometida, em vez de ter sido usada intencionalmente. Embora essa continue sendo uma possibilidade, outros aspectos do incidente tornam essa hipótese menos plausível. No entanto, é um ponto a ser considerado.

Considerações finais

É provável que essa história esteja longe de chegar ao fim. As medidas tomadas até o momento incluíram o fechamento do repositório do xz no GitHub, a reversão dos pacotes de distribuição para uma versão anterior e a reavaliação de outros commits do usuário supostamente responsável.

As questões em aberto incluem:

Este é um dos ataques à cadeia de suprimentos mais sofisticados já registrados. É difícil imaginar que tenha sido obra de um único hacker. Quem estava por trás disso? Se Jia Tan seguia um cronograma de trabalho, qual país, organização ou grupo pagava seu salário?
Manter uma operação por mais de dois anos exige recursos e esforços consideráveis. Qual era o objetivo final? Eventualmente, todos os sistemas baseados no Debian e no Red Hat teriam sido comprometidos. Quem teria a ganhar com o acesso a todos os sistemas que rodam essas distribuições?
A hora e os fusos horários são facilmente alterados nas mensagens de commit. Eles foram definidos intencionalmente para indicar fusos horários específicos?
Todo o código malicioso já foi identificado? Ainda há mais carga maliciosa a ser descoberta?
O sshd era o único processo alvo?
Quais outros projetos foram afetados pelo ataque?

Na segurança cibernética, estamos constantemente nos esquivando dos ataques. Até que isso não aconteça mais. E o curioso é que nem sequer veremos aquele que vai nos acertar até que seja tarde demais.

Quer saber mais sobre as Vulnerabilidades e Exposições Comuns (CVEs) e, ao mesmo tempo, entender a importância delas na segurança de TI? Assista ao episódio 2 da nossa série “LinuxTalk com a Tuxcare” no YouTube.

Mergulhe no recente incidente de segurança do xz, descubra o que aconteceu, como aconteceu e quais são as implicações para a comunidade de código aberto em nosso episódio 4 da série “Linux Talk with TuxCare” no YouTube

Resumo