Backdoor no XZ Utils: tudo que você precisa saber e o que você pode fazer
Resumo executivo
O CVE-2024-3094 corresponde a uma vulnerabilidade descoberta na biblioteca de código aberto XZ Utils que deriva de código mal-intencionado enviado para a biblioteca por um de seus mantenedores.
Ele foi originalmente relatado como uma backdoor de contorno de autenticação SSH, mas uma análise adicional indicou que a backdoor realmente permite a execução remota de código (RCE).
O agente de ameaça começou a contribuir com o projeto XZ há quase dois anos, criando credibilidade lentamente até receber responsabilidades de mantenedor. Essas operações de longo prazo geralmente são a área de domínio de agentes de ameaça patrocinados por estados, mas não existe uma atribuição específica atualmente.
Como a backdoor afeta as versões mais recentes da XZ Utils, o curso de ação recomendado é fazer downgrade para uma versão não comprometida. Nesta postagem do blog, ofereceremos outras possíveis mitigação para limitar o alcance do ataque.
Contexto
XZ Utils, e sua biblioteca subjacente liblzma, são projetos de código aberto que implementam a compactação e a descompactação de lzma. Eles estão incluídos em muitas distribuições do Linux prontas para uso, são muito populares entre os desenvolvedores e são amplamente usados em todo o ecossistema Linux.
Há quase dois anos, um desenvolvedor com o nome de Jia Tan ingressou no projeto e começou a abrir solicitações pull de várias correções de bugs ou melhorias. Até aqui, não há nada errado; é assim que as coisas funcionam no mundo de código aberto. Eventualmente, depois de ganhar confiança e credibilidade, Jia Tan começou a receber permissões para o repositório: primeiro, permissões de commit; depois, direitos de gerenciamento de versões.
Parece que, como parte do esforço para obter essas permissões, Jia Tan usou uma forma interessante de engenharia social: ele usou contas falsas para enviar inúmeras solicitações de recursos e reclamações sobre bugs para pressionar o mantenedor original, eventualmente causando a necessidade de adicionar outro mantenedor ao repositório.
Depois de contribuir com o código por aproximadamente dois anos, em 2023 Jia Tan introduziu algumas alterações no XZ que foram incluídas como parte da versão 5.6.0. Entre essas mudanças estava uma sofisticada backdoor.
A backdoor
A backdoor é muito complexa. Para começar, você não a encontrará no repositório do GitHub do XS (que está desativado no momento, mas isso é outra coisa). No que parece uma tentativa de evitar a detecção, em vez de empurrar partes da backdoor para o repositório Git público, o mantenedor mal-intencionado incluiu-a apenas nas versões tarball do código fonte. Isso fez com que partes da backdoor permanecessem relativamente ocultas, enquanto ainda estavam sendo usadas durante o processo de desenvolvimento de projetos dependentes.
A backdoor é composta por muitas partes introduzidas em vários commits:
Usar IFUNCs no processo de criação, que serão usadas para sequestrar as funções de resolução de símbolo pelo malware
Incluir um objeto compartilhado ofuscado oculto em arquivos de teste
Executar um conjunto de scripts durante o processo de criação da biblioteca que extrai o objeto compartilhado (não incluído no repositório, apenas em versões, mas adicionado ao .gitignore)
Desativar o landlocking, que é um recurso de segurança para restringir privilégios de processo
A cadeia de execução também consiste em vários estágios:
O script mal-intencionado build-to-host.m4 é executado durante o processo de criação da biblioteca e decodifica o arquivo de "teste" bad-3-corrupt_lzma2.xz em um script de bash
Em seguida, o script de bash executa um processo de decodificação mais complicado em outro arquivo de "teste", good-large_compressed.lzma, decodificando-o em outro script
Em seguida, esse script extrai um objeto compartilhado liblzma_la-crc64-fast.o, que é adicionado ao processo de compilação da liblzma
É muito difícil seguir esse processo. Recomendamos o infográfico deThomas Roccia como uma excelente referência visual e análise aprofundada.
O objeto compartilhado em si é compilado na liblzma e substitui o processo normal de resolução de nome de função. Durante o carregamento do processo, os nomes das funções são resolvidos em indicadores reais para a memória do processo, apontando para o código binário. A biblioteca mal-intencionada interfere no processo de resolução de funções, de modo que pode substituir o ponteiro de função da função OpenSSH RSA_public_decrypt (Figura 1).
Em seguida, ela direciona essa função para outra mal-intencionada, que, de acordo com a pesquisa publicada por Filippo Valsorda, extrai um comando do certificado do cliente de autenticação (depois de verificar se é o agente de ameaça) e o repassa para a função system() para execução, alcançando a RCE antes da autenticação.
Fig. 1: O processo de fisgagem da liblzma
Para uma explicação mais detalhada das partes da backdoor, você pode ler a publicação de Andres Freundno Openwall.
Possível impacto
Atualmente, é como se a backdoor fosse adicionada ao daemon SSH na máquina vulnerável, permitindo que um invasor remoto execute código arbitrário. Isso significa que qualquer máquina com o pacote vulnerável que expõe o SSH à Internet está potencialmente vulnerável.
Essa backdoor quase se tornou um dos mais importantes ativadores de invasão de todos os tempos, podendo ser pior que a backdoor do SolarWinds. Os invasores quase conseguiram obter acesso imediato a qualquer máquina Linux executando uma distro infectada, que inclui Fedora, Ubuntu e Debian. Quase.
Houve apenas uma coisa que impediu que isso acontecesse: Andres Freund. Depois de investigar um problema de latência de 500 ms que foi introduzido após uma atualização de software, Andres conseguiu rastrear o problema de volta ao pacote xz e, por fim, identificar a backdoor.
Isso, obviamente, levanta muitas preocupações. Tivemos sorte. Se essa backdoor não fosse detectada por um engenheiro curioso, por quanto tempo ela teria permanecido ativa?
E talvez ainda mais preocupante: E se isso já tiver acontecido?
Detecção e mitigação
Controle de versão
A Agência de Segurança de Infraestrutura e Cibersegurança (CISA) recomendou o downgrade para uma versão não comprometida, como a 5.4.6.
Para saber qual versão do XZ Utils ou liblzma você tem atualmente em seus sistemas, você pode executar a seguinte consulta na Akamai Guardicore Segmentation Insight que procurará instâncias carregadas da biblioteca liblzma (Figura 2).
SELECT DISTINCT path AS liblzma_path
FROM process_memory_map
WHERE LOWER(path) LIKE "%liblzma%"
Fig. 2: Consultas de instâncias carregadas da liblzma
Como alternativa, você pode executar a seguinte consulta para localizar o gerenciador de pacotes da versão instalada.
SELECT name AS vulnerable_item, 'DEB' AS type, version
FROM deb_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
UNION
SELECT name AS vulnerable_item, 'RPM' AS type, version
FROM rpm_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
É claro que você também pode filtrar para mostrar apenas ativos vulneráveis.
SELECT path AS vulnerable_item, "Loaded Library" AS type, '5.6%' AS version
FROM process_memory_map
WHERE LOWER(path) LIKE "%liblzma%5.6%"
SELECT name AS vulnerable_item, 'DEB' AS type, version
FROM deb_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
AND version LIKE '5.6.%'
UNION
SELECT name AS vulnerable_item, 'RPM' AS type, version
FROM rpm_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
AND version LIKE '5.6.%'
Busca por ameaças
Como a backdoor executa comandos do sistema e não está apenas permitindo a autenticação, talvez seja possível detectar esse comportamento por meio do rastreamento de processos.
Normalmente, durante o logon, um novo shell é criado para o usuário de registro e executa o processo de shell padrão (como bash). No entanto, com essa backdoor, o comando mal-intencionado é executado pelo processo daemon SSH, sshd, que pode acionar uma anomalia.
Nosso serviço de busca de ameaças, o Akamai Hunt, tem métodos para detectar tais anomalias; por exemplo, ao constantemente rastrear uma linha de base da atividade de processo e seus processos secundários.
Mitigador
De acordo com algumas análises da backdoor, ela parece ter um mitigador que varia de acordo com o ambiente. A adição da chave yolAbejyiejuvnup=Evjtgvsh5okmkAvj às variáveis de ambiente do sistema pode desativar a backdoor.
Referências