Backdoor SSH
Um mantenedor nefasto ou comprometido inseriu comportamento malicioso em uma biblioteca chamada liblzma, parte das ferramentas e bibliotecas de compactação xz, resultando em um backdoor no SSH. Este é um ataque avançado à cadeia de suprimentos de software, já que a biblioteca foi modificada intencionalmente para o backdoor, com técnicas de ofuscação e furtividade para ocultar a carga útil do ataque dos revisores. Foi descoberto e divulgado recentemente (no passado dia 29 de março), e o tratamento do ataque está em andamento. No entanto, foi rapidamente contido, pois parece afetar apenas versões de pré-lançamento de um conjunto limitado de ambientes (pacotes DEB e RPM, para a arquitetura x86_64, e construídos com GCC). De qualquer forma, o CVE foi dado um Pontuação base CVSS de 10, que é reservado para as vulnerabilidades de segurança cibernética mais críticas. Caso entre em distribuições estáveis, o impacto será avassalador. A análise técnica do ataque, incluindo a xz backdoor explicado em detalhes, foi analisado em outro lugar. Este post se concentrará na linha do tempo do ataque, como ele pode ser detectado, como o incidente foi tratado até o momento e quais lições podem ser extraídas do ataque.Como o backdoor XZ foi injetado
Nota: O repositório git está em git.tukaani.org. Porém, houve também um Repositório hospedado no GitHub (atualmente bloqueado) onde a conta GitHub estava postando as alterações que foram posteriormente integradas ao repositório Git. Uma parte do backdoor parece estar apenas nos tarballs distribuídos para as versões 5.6.0 e 5.6.1, não nos repositórios git e depende de um única linha no build-to-host.m4 arquivo de macro usado pelo autoconf. A outra parte estava em dois supostos testfiles bad-3-corrupt_lzma2.xz e no bom-grande_comprimido.lzma que foram committed pela conta GitHub “Jia Tan” (JiaT75) Na repositório xz em 23 de fevereiro. Foi uma mudança inócua adicionar testfiles (supostamente blocos compactados .lzma e .xz). Curiosamente, os arquivos de teste não foram usados pelos testes! A linha no arquivo .m4 injeta um script ofuscado (incluído no tarball) para ser executado no final da configuração se algumas condições corresponderem. Ele modifica o Makefile para o liblzma biblioteca para conter código que extrai dados do arquivo .xz, que após a desofuscação termina neste roteiro, é invocado no final do configure. Ele decide se modifica o processo de construção para injetar código: somente no GCC e no vinculador GCC, no Debian ou rpm, e somente no Linux x86_64. Quando correspondido, o código injetado intercepta a execução substituindo dois função resolvedores para que certas chamadas sejam substituídas. Isso faz com que as tabelas de símbolos sejam analisadas na memória (isso leva tempo, o que levou à detecção, conforme explicado posteriormente). Então as coisas ficam interessantes: o backdoor instala um gancho de auditoria no vinculador dinâmico, aguardando a chegada do símbolo da função RSA_public_decrypt, que é redirecionado para um ponto no código do backdoor, que por sua vez chama de volta libcrypto, presumivelmente para realizar a autenticação normal. E a carga útil é ativada se o programa em execução tiver o nome do processo / usr / sbin / sshd. Ficou claro que os servidores SSH eram o alvo. Tradicionalmente, sshd servidores como OpenSSH não estavam vinculados liblzma, mas sshd é frequentemente corrigido para oferecer suporte ao systemd-notify para que outros serviços possam ser iniciados quando o sshd estiver em execução. E então liblzma é indiretamente carregado por sistema, fechando o círculo. O backdoor ainda não foi totalmente analisado, mas parece estar permitindo a execução remota de comandos (RCE) com os privilégios do daemon sshd, executando em um contexto de pré-autenticação. As informações do certificado remoto, quando correspondidas pelo backdoor, são descriptografadas com ChaCha20 e, quando descriptografadas com sucesso, são passadas para o sistema(). Portanto, este é essencialmente um RCE fechado, muito pior do que um mero desvio de chave pública. Um tarball 5.6.1 posterior mostrou esforços adicionais para ocultar os rastros, adicionando mais ofuscação para nomes de símbolos e tentando corrigir os erros vistos. Um mecanismo de extensão onde arquivos de teste adicionais foram procurados, certas assinaturas para adicionar ao backdoor também foram implementadas. Este ataque bastante sofisticado pode passar despercebido até que distribuições Linux estáveis sejam alcançadas. Felizmente, algumas pessoas gostam de verificar por que coisas anormais acontecem.A descoberta do ataque de backdoor XZ
Muitas vezes, o comportamento malicioso injetado é descoberto por acaso ou acidente. Um bom exemplo foi um aviso de depreciação (“Quem se importa com avisos?”) que levou à descoberta do ataque de fluxo de eventos em outubro de 2018. Outro é o usuário que avisou codecov em abril de 2021 que seu script bash uploader não passou na soma de verificação (“Quem verifica a integridade dos artefatos com somas de verificação”?) Anomalias e sintomas estranhos com ssh Conecte-ses (Conecte-se(está consumindo muita CPU e aumentando o tempo decorrido, erros do valgrind) despertou a curiosidade de Andrés Freund, um desenvolvedor vigilante do PostgreSQL, mas não um analista de segurança (como ele afirmou). Após alguma investigação com OpenSSH no Debian Sid ele concluiu que um problema de tempo de resposta dependia de uma biblioteca liblzma, Parte da xz-utils biblioteca de compactação. A razão: "o repositório upstream xz e os tarballs xz foram backdoorados”. Este diagnóstico foi tão preciso! Em 29 de março de 2024 Andres postou no Openwall a primeira análise: “backdoor no upstream xz/liblzma levando ao comprometimento do servidor ssh”. O fato: os tarballs XZ Utils 5.6.0 e 5.6.1 contêm um backdoor. Esses tarballs foram criados e assinados pela conta Jia Tan mencionada acima. He postado em Mastodonte mais tarde naquele dia, reconhecendo que a descoberta foi acidental e exigiu muitas coincidências. Vale a pena ler os comentários de outros usuários. Usuário GitHub mesmo (também conhecido como Sam James) publicou um bom Gist Perguntas frequentes sobre o backdoor xz-utils onde o ataque foi resumido, ligando-se a mais análises aprofundadas da carga útil do ataque. Essas análises foram tecnicamente interessantes e nos ajudaram a entender melhor a injeção, que foi altamente elaborada:- xz/liblzma: Explicação da ofuscação do estágio Bash. Bela análise sobre a desofuscação pelo script de injeção, em quatro “etapas”.
- O fio azul de Filippo Valsorda Análise do próprio backdoor em RSA_public_decrypt, que mostra sua natureza: um RCE, não um bypass de autenticação, e fechado (aceita a chave privada do autor e se não, reverte ao comportamento normal)/irreembolsável. O autor pretendia ser discreto para evitar a detecção!
- Análise de backdoor XZ por @smx-smx (WIP) – Análise adicional do backdoor (me perdi quase no começo 😀)
- wiki de documentação de backdoor xz, outra análise do script de injeção 5.6.1.
Como o incidente foi tratado
A divulgação de Andreas Freund foi cautelosa porque, em suas próprias palavras:“Dado o envolvimento aparente do upstream, não relatei um bug do upstream. Como inicialmente pensei que fosse um problema específico do Debian, enviei um relatório mais preliminar para security@...ian.org. Posteriormente, relatei o problema para distros@. CISA foi notificada por uma distribuição.”
A Red Hat atribuiu este problema CVE-2024-3094. Então a palavra circulou como um incêndio.
Lasse Collin, o outro mantenedor do XZ, adicionou um novo commit no sábado, 30 de março, intitulado “CMake: Corrigir verificação sabotada do sandbox Landlock”. Um dos métodos de sandbox da biblioteca foi sabotado, pelo menos durante a construção com CMake. Ele prontamente divulgou o assunto no Porta dos fundos dos utilitários XZ.
A Red Hat atribuiu este problema CVE-2024-3094 (veja também em CVE, NVD, Ubuntu). Foi atribuído um enorme Pontuação básica CVSS de 10. Essas pontuações sempre surpreendem a Internet.
CISNo mesmo dia 29 de março foi lançado um alerta, talvez muito simplista devido à urgência, recomendando aos usuários que façam o downgrade para a versão estável 5.4.6.
Os repositórios GitHub sob a organização Tukaani foram desabilitados (isso é bom ou ruim? Eu acho bom: muitas distros e organizações ainda estavam vinculando aos lançamentos do GitHub para obter os tarballs infectados para construção. Desabilitar o repositório evita isso. De qualquer forma, existe uma cópia ou os repositórios em git.tukaani.org). As contas GitHub JiaTan75 e Lasse Collins (Larhzu) também foram suspensas. Isso faz parte contenção, mesmo quando pode afetar pessoas inocentes. JiaT75 atividade em repositórios não desabilitados ainda não pode ser visto.
A indústria reagiu prontamente. Muitos fornecedores publicaram regras para detectar sistemas vulneráveis, como Regras de Yaraou suporte em ferramentas comerciais de sysdig, PAN, e outros. Especialistas em segurança como James Berthoty postou sobre a revisão de como abordamos o software de código aberto.
Estamos agora na fase de Erradicação e Recuperação do incidente. Outros projetos mantidos pela JiaTan75 estão sob análise cuidadosa, nomeadamente o libarchive/libarchive (onde JiaTan75 era um contribuidor regular) e o fuzzer oss-fuzz (onde isso commit feito por JiaTan75 tentou evitar oss-fuzz, que na verdade não foi capaz de detectar o backdoor). Essas tentativas de ocultação acrescentam mais evidências.
Quem está sob ataque?
Ou a conta GitHub JiaT75 foi comprometida (lembre-se de que o GitHub exigiu 2FA recentemente) ou o usuário físico que devia a conta foi para o lado negro. Mas existem razões convincentes para pensar numa ameaça persistente avançada (APT), talvez apoiada pelo Estado, devido à sofisticação técnica do ataque. Uma investigação mais aprofundada por parte das agências de segurança cibernética e das autoridades policiais dirá… Esta entrada em YCombinator Hacker News sobre Jia Tan lança alguma luz sobre “quem” e sua atividade. Recomendado! Fornece muitas informações sobre como os bandidos tentam enganar outros usuários, usando engenharia social.“Muito irritante - o autor aparente do backdoor estava em comunicação comigo (rwmj) por várias semanas tentando adicionar o xz 5.6.x ao Fedora 40 e 41 por causa de seus "ótimos novos recursos". Nós até trabalhamos com ele para consertar o problema do valgrind (que agora descobrimos que foi causado pelo backdoor que ele adicionou). Tivemos que correr ontem à noite para consertar o problema após uma quebra inadvertida do embargo. Ele faz parte do projeto xz há 2 anos, adicionando todos os tipos de arquivos de teste binários e, para ser honesto com esse nível de sofisticação, eu desconfiaria até mesmo de versões mais antigas do xz até que se prove o contrário.”
Jia Tan tomou medidas para evitar ser rastreado: parece ter usado VPN (vpn.singapore.witopia.net) para se conectar – o que é bom por si só. E muitas mudanças parecem ser apoiadas por e-mails temporais de uso único (do ProtonMail, neste caso), solicitando a mesclagem das alterações.
O ator pode pretender ir ainda mais fundo, até o kernel Linux, como contribuidor do incorporado em xy projeto. Uma análise inicial não encontrou nenhuma evidência de aborto espontâneo até hoje.
Obs: outro contribuidor discreto do XZ “Hans Jansen“ (usuário do GitHub “hansjans162”) é sob escrutínio. Sua conta no debian agora é bloqueado. Ele fez muitas atualizações no Debian Games para esconder o que ele queria no debian/xz-utils, uma atualização para o upstream 5.6.1 para acelerar a distribuição do backdoor para debian/instável.
Tudo o que podemos dizer, por enquanto, é que se trata de um APT (ainda não identificado) que utiliza contas diferentes, trabalha há pelo menos dois anos nesta campanha e trabalha pacientemente para implantar um RCE em SSH.
O ataque de backdoor do XZ poderia ter sido evitado?
Bastante difícil. Primeiro, parte do backdoor injetado veio em arquivos de teste compactados que não foram usados pelos testes. Retrospectivamente, isso poderia disparar alguns alarmes (ruidosos), mas quem se importa em verificar se todos os arquivos de teste são usados por testes reais no mundo real? Segundo, parte do backdoor injetado veio em arquivos de macro nos tarballs de lançamento, e é difícil verificar manualmente se há diferenças com os tarballs esperados. A automação também é complexa, pois o resultado esperado da própria compilação (para quem sabe como o automake/autoconf funciona) é difícil de modelar para analisar se o tarball real corresponde às expectativas. Alguns colocaram isso as “A incompatibilidade dos tarballs da árvore git é um recurso, não um bug”. A proveniência dos tarballs binários de seu código-fonte é um problema não resolvido. Reputação do usuário? Bem, a conta JiaTan75 GitHub não estava fazendo coisas desonestas de acordo com o passado commitS. Foi suspenso somente após o acúmulo de evidências, mas até 29 de março era um usuário regular realizando negócios normais. Bem, não é tão normal. Mais tarde commits (esse, esse, esse e esse que ajustou o código de exploração) tentou corrigir os erros e travamentos do valgrind em algumas configurações, devido a diferenças com o layout da pilha esperado pelo backdoor. Commit revisões poderiam detectar isso, mas quem tem paciência para analisar alterações em um arquivo de teste binário ou a real motivação para uma alteração nos atributos do GCC no código-fonte C? Deve-se disparar alarmes quando um SSH Conecte-se leva 800 ms em vez de 300 ms? Provavelmente apenas pessoas hiperprudentes prestariam atenção. Cícero disse: “A precipitação pertence à juventude; prudência até a velhice.” A infraestrutura ifunc foi adicionada em junho de 2023 por “Hans Jansen” e “Jia Tan”. Este é o primeiro commit adicionando suporte ifunc a crc64_fast.c (mais tarde usado para injetar o backdoor). Meses antes de injetar os binários backdoor nos arquivos de teste!
Nota: Autor e commitpodem ser diferentes aqui, mas isso é normal: Lasse Collin é o mantenedor do projeto e ele mesclou as alterações. Ele até agradece a “Hans Jansen”…
Ninguém levantou preocupações antes da postagem de Andres Freund e do CVE criado pela RedHat. Se você vir uma série de ferramentas que detectam isso, elas detectam o componente afetado agora, ex post facto.
Provavelmente, a melhor prevenção veio da natureza das distribuições Linux e de como as versões instáveis e de última geração só passam para distribuições estáveis a jusante após um processo acelerado.
Lições aprendidas com o ataque XZ bBackdoor
Notamos como é difícil detectar intencional portas dos fundos. Os backdoors devem ser considerados uma ameaça interna, pois são plantados por funcionários internos ou através de contas internas comprometidas. E esses caras são mais confiáveis. E quando o backdoor é implantado no artefato distribuído, fica mais difícil de ser detectado.
Alguns autores como Kevin Beaumont apontado para sistema., o que abre uma grande superfície de ataque de serviços de terceiros para backdoor. Foi disso que o mau ator abusou aqui. Systemd tem muitos olhos, mas XZ é uma biblioteca obscura na cadeia. “Quando a montante está contaminada, todo mundo bebe água envenenada rio abaixo”.
Uma solicitação de mudança não relacionada no sistema para carregando dinamicamente bibliotecas de compactação, que removeria o backdoor, já foi incorporado ao sistema, mas ainda não foi entregue. As dependências extras introduzidas pelo libsystemd podem ser a fonte de vulnerabilidadese ontem esta solicitação foi aberta.
A comentar no “xz: Desative ifunc para corrigir o problema” commit deu uma visão precisa sobre onde colocar o foco se quisermos evitar tal atividade (a ênfase é minha):
“A lição que devemos aprender como comunidade é mais para garantir software supply chain security holisticamente, auditar sistemas de construção além do código-fonte. Como a violação da SolarWinds, onde os invasores modificaram as atualizações de software para a oferta de software de monitoramento de código fechado da SolarWinds.”
A descoberta precoce e a reação imediata limitaram muito o impacto. Se você se lembra do cena final de Homens de Preto III: "Aquela passou perto". Mais uma vez K não esqueceu de deixar a gorjeta. E nenhum boglodita entrou nas distribuições estáveis do Linux.
1. "Não sou um pesquisador de segurança, nem um engenheiro reverso." 2. Jia é um nome chinês comum. Tan também é um sobrenome comum que significa "magnífico". Muitas pessoas sem parentesco compartilham esse nome. Por favor, não condenem ninguém por esse nome!
