Xzbot: notas, honeypot e demonstração de exploit para o backdoor do xz

Explorando o backdoor do xz (CVE-2024-3094)

• honeypot: fornece detecção de tentativas de invasão por meio de um servidor vulnerável falso
• ed448 patch: aplica patch no liblzma.so para usar sua própria chave pública ED448
• backdoor format: formato do payload do backdoor
• backdoor demo: CLI que aciona RCE assumindo que a chave privada ED448 é conhecida

honeypot

• fornece um patch simples para o OpenSSH que registra todas as tentativas de conexão cujo valor N da chave pública corresponde ao formato do backdoor
• as tentativas de conexão aparecem no log do sshd da seguinte forma

ed448 patch

• o backdoor usa uma chave pública ED448 embutida para verificar assinaturas e descriptografar o payload
• ao substituir essa chave pela sua, é possível acionar o backdoor
• baixe o objeto compartilhado libxzma com o backdoor e execute o script de patch para substituir a chave

backdoor format

• é possível acionar o backdoor conectando-se com certificados SSH e incluindo o payload no valor N da chave de assinatura da CA
• esse payload deve ser criptografado e assinado com a chave ED448 do atacante
• a estrutura do payload segue o formato especificado

backdoor demo

• mostra como se conectar a um servidor SSH vulnerável e executar o comando id > /tmp/.xz
• é possível monitorar a chamada system() no servidor vulnerável e observar a execução do comando
• a árvore de processos de um sshd normal e a árvore de processos via backdoor têm aparências diferentes

Opinião do GN⁺

• este artigo trata de uma exploração aprofundada da vulnerabilidade do backdoor do xz identificada como CVE-2024-3094 e fornece informações muito úteis para pesquisadores de segurança e administradores de sistemas.
• ao apresentar formas de detectar e responder ao backdoor, pode ajudar a proteger sistemas vulneráveis.
• como esse tipo de vulnerabilidade pode contornar os mecanismos fundamentais de segurança do sistema, desenvolvedores de software e profissionais de segurança precisam entender esse tipo de falha e adotar medidas para preveni-la.
• outras ferramentas ou projetos de segurança com funcionalidades semelhantes incluem OpenSSH, Fail2Ban e Snort, que podem fornecer camadas adicionais de defesa para proteger sistemas.
• como o artigo fornece detalhes técnicos sobre uma nova vulnerabilidade, ele pode ajudar a comunidade de segurança a desenvolver estratégias de defesa mais robustas.

[GN⁺]

Comentários no Hacker News

• Resumo dos comentários do Hacker News:
  • Uma observação interessante sobre uma vulnerabilidade de RCE (Remote Code Execution) que exigiria a chave privada do atacante. Correção: o link foi mal interpretado, e o comentário original foi mantido para registro.

    • A vulnerabilidade, ironicamente, parece ter sido pensada com foco em segurança. Além disso, a pessoa que fez o commit do backdoor, na mesma thread de e-mails, também teria contribuído recentemente para o kernel.

  • Admiração pela rapidez com que a comunidade hacker, e especialmente amlweems, implementou e documentou o PoC (Proof of Concept). Correção: o próximo passo é descobrir como identificar distribuições vulneráveis e como monitorar sondagens ativas em servidores SSH.

    • Elogio à resposta e à análise rápidas da comunidade.

  • Curiosidade sobre se o PoC já foi testado contra ferramentas que detectam comportamento anômalo, como Carbon Black, AWS GuardDuty e SysDig, e se isso permitiria uma detecção rápida.

    • Curiosidade sobre testes do PoC com ferramentas de detecção de comportamento anômalo.

  • Dúvida sobre se funcionava mesmo sem uma conexão SSH. A lista de strings no GitHub inclui "DISPLAY" e "WAYLAND_DISPLAY".

    • Especulação sobre um possível escopo adicional de impacto devido à presença de strings sem relação direta com SSH.

  • Pergunta sobre como o patch em openssh.patch não era necessário em runtime e como liblzma.so.5.6.1 aplicava um patch em openssh_RSA_verify ao ser carregado na memória.

    • Pergunta técnica sobre o processo de exploração da vulnerabilidade em runtime.

  • O fato de que um ataque bem-sucedido não deixaria logs. Isso levantou a questão de se o atacante poderia executar comandos arbitrários sem deixar registros.

    • Preocupação com a possibilidade de ataque sem geração de logs.

  • Opiniões sobre como os mantenedores dos projetos xz, OpenSSH e Linux reagiram a essa vulnerabilidade e sobre formas de evitar esse tipo de problema no futuro.

    • Interesse na resposta dos mantenedores e em medidas preventivas futuras.

  • Discussão sobre espionagem em nível estatal e backdoors. Os EUA tenderiam a preferir intervenções em hardware, enquanto outros países, como Israel, focariam em backdoors de software de longo prazo.

    • Análise das estratégias de backdoor por país.

  • Dúvida sobre o motivo do uso de ED448, apesar de curve 25519 normalmente ser recomendada.

    • Questionamento sobre a escolha de um algoritmo criptográfico específico.