Incidente do backdoor no XZ: resultados da análise inicial

• O backdoor no XZ Utils/liblzma foi divulgado em 29 de março de 2024 na lista de e-mails OSS-security da Openwall, e é bastante provável que o objetivo final do invasor fosse implantar capacidade de execução remota de código no sshd, o servidor OpenSSH, em distribuições baseadas em systemd
• A cadeia de infecção foi composta por uma injeção em múltiplas etapas usando arquivos de teste e a infraestrutura de build do repositório XZ, passando por build-to-host.m4, bad-3-corrupt_lzma2.xz e good-large_compressed.lzma, até que um arquivo objeto malicioso fosse vinculado ao liblzma durante a compilação
• O XZ 5.6.0 e 5.6.1 com backdoor foi distribuído em builds beta e experimentais de alguns grandes fornecedores, e o CVE-2024-3094 recebeu severidade 10
• O backdoor binário é carregado abusando do IFUNC da GLIBC e do caminho de chamada de cpuid, e depois tenta monitorar conexões na máquina infectada por meio de hooks em funções relacionadas a OpenSSL/libcrypto
• O código malicioso verifica se /usr/bin/sshd está em execução e se existe uma variável de ambiente de kill switch, além de dificultar análise e detecção com processamento de strings baseado em trie, resolução dinâmica de símbolos e patch em tempo de execução de rtdl-audit

---

Visão geral do incidente e escopo do impacto

• Em 29 de março de 2024, a descoberta do backdoor no XZ foi divulgada por meio desta mensagem na lista de e-mails OSS-security da Openwall
• XZ é um utilitário de compressão integrado a várias distribuições Linux importantes
• O ponto central do risco é que o liblzma com backdoor podia se conectar ao processo sshd do servidor OpenSSH em algumas distribuições baseadas em systemd
  • Ubuntu, Debian e RedHat/Fedora Linux aplicam patches no OpenSSH para usar recursos do systemd, o que o faz depender dessa biblioteca
  • Arch Linux e Gentoo são considerados não afetados
• É bastante provável que o objetivo final do invasor fosse adicionar uma função de execução remota de código no sshd que outras pessoas não pudessem usar
• Ao contrário de outros ataques à cadeia de suprimentos centrados em um único patch malicioso, pacote falso ou pacote de typosquatting, este caso se aproxima de uma operação em múltiplas etapas que quase conseguiu comprometer servidores SSH no mundo todo

Como o backdoor foi inserido

• O backdoor no liblzma foi inserido em dois níveis, usando ao mesmo tempo o processo de build e arquivos de teste
  • O código-fonte da infraestrutura de build que gera o pacote final foi modificado com a adição de build-to-host.m4
  • Scripts ocultos e componentes binários escondidos dentro de arquivos de teste eram extraídos durante a compilação
• O fluxo de infecção gira em torno de três arquivos
  • build-to-host.m4: script de build que extrai o script da etapa seguinte
  • bad-3-corrupt_lzma2.xz: arquivo de teste com um shell script oculto
  • good-large_compressed.lzma: arquivo de teste com um objeto binário malicioso oculto
• O componente binário malicioso extraído era vinculado à biblioteca legítima durante a compilação e podia assim chegar aos repositórios Linux
• Grandes fornecedores distribuíram esse componente malicioso em builds beta e experimentais
• À invasão do XZ Utils foi atribuído o CVE-2024-3094, com severidade máxima de 10

Linha do tempo principal

• 19 de janeiro de 2024: o novo maintainer jiaT75 migra o site do XZ para GitHub Pages
• 15 de fevereiro de 2024: build-to-host.m4 é adicionado ao .gitignore
• 23 de fevereiro de 2024: são adicionados dois “arquivos de teste” contendo a etapa do script malicioso
• 24 de fevereiro de 2024: XZ 5.6.0 é lançado
• 26 de fevereiro de 2024: entra em CMakeLists.txt um commit que interfere no recurso de segurança Landlock
• 4 de março de 2024: o backdoor passa a causar problemas relacionados ao Valgrind
• 9 de março de 2024: os dois arquivos de teste são atualizados, a função CRC é modificada e o problema com o Valgrind é “corrigido”
• 9 de março de 2024: XZ 5.6.1 é lançado
• 28 de março de 2024: o bug é descoberto e Debian e RedHat são notificadas
• 28 de março de 2024: o Debian faz rollback do XZ 5.6.1 para a versão 5.4.5-0.2
• 29 de março de 2024: o e-mail público é publicado na lista OSS-security
• 29 de março de 2024: a RedHat confirma que uma versão do XZ com backdoor foi distribuída no Fedora Rawhide e no Fedora Linux 40 beta
• 30 de março de 2024: o Debian interrompe os builds e inicia o processo de rebuild
• 2 de abril de 2024: o principal desenvolvedor do XZ reconhece o incidente do backdoor

As 3 etapas da cadeia de infecção

• Etapa 1: build-to-host.m4 modificado

  • Os releases do repositório oficial do XZ no GitHub incluíam os arquivos de teste maliciosos, mas no início eles eram inofensivos porque não tinham chance de ser executados
  • O código malicioso que inicializa a infecção parece ter sido incluído no release fornecido por xz[.]tukaani.org, controlado por jiaT75
  • A maioria das distribuições usava essa URL, e o release baixado incluía o arquivo build-to-host.m4 com código malicioso
  • build-to-host.m4 é executado durante o processo de build, corrige os dados “corrompidos” de bad-3-corrupt_lzma2.xz com tr e depois descompacta com xz -d
  • O resultado da descompressão contém um shell script que depois será executado com /bin/bash

• Etapa 2: shell script inserido

  • O script inserido pelo arquivo .m4 malicioso verifica se está sendo executado em uma máquina Linux e dentro do processo de build pretendido
  • A execução da próxima etapa usa good-large_compressed.lzma
  • Esse arquivo está compactado normalmente com XZ, mas os dados descompactados contêm dados lixo
  • O script executa um pipeline de head com eval para extrair os dados
  • Cada comando head ignora os próximos 1024 bytes ou extrai os próximos 2048 bytes ou 724 bytes
  • No total, são extraídos 33.492 bytes
  • tail mantém os últimos 31.265 bytes do arquivo e ignora o restante
  • Em seguida, tr aplica substituições básicas para desfazer a ofuscação, e um segundo comando XZ descompacta os bytes transformados como um stream raw de lzma, enviando o resultado ao shell

• Etapa 3: extração do objeto do backdoor

  • O shell script da etapa final verifica várias condições para confirmar se está sendo executado no ambiente esperado
  • Ele verifica se o projeto está configurado para usar IFUNC
  • Verifica se a compilação está sendo feita com GCC
  • Depois confirma a existência, no projeto, de arquivos específicos que o script vai usar
  • Essa etapa extrai um arquivo objeto escondido em outro offset de good-large_compressed.lzma
  • O procedimento de extração executa vários comandos em sequência, passando a saída de cada um como entrada do próximo
  • Extrai good-large_compressed.lzma com a ferramenta XZ
  • Usa eval $i e várias chamadas a head
  • Descriptografa os dados binários com um algoritmo customizado semelhante a RC4
  • Extrai novamente o arquivo compactado já descriptografado com XZ
  • Remove alguns bytes do início e salva o resultado como liblzma_la-crc64-fast.o
  • Por fim, o script modifica a função is_arch_extension_supported no arquivo crc_x86_clmul.h do liblzma
  • Ele troca a chamada __get_cpuid por _get_cpuid, removendo um sublinhado
  • Essa mudança permite que o objeto do backdoor seja vinculado à biblioteca

Como o backdoor binário é carregado

• O código original do XZ tem funções especiais para cálculo de CRC, lzma_crc32 e lzma_crc64
• As duas funções são armazenadas na tabela de símbolos ELF com o tipo IFUNC da GLIBC
  • O IFUNC permite que o linker dinâmico escolha dinamicamente qual função usar ao carregar uma biblioteca compartilhada
  • O XZ usa esse mecanismo para decidir se deve usar funções CRC otimizadas depois de verificar recursos modernos do processador, como CLMUL, SSSE3 e SSE4.1
• A checagem dos recursos do processador exige a instrução cpuid, e o wrapper __get_cpuid fornecido pela GLIBC é chamado
• Quando o script malicioso troca __get_cpuid por _get_cpuid, a chamada do código passa a ser ligada ao símbolo _get_cpuid dentro do arquivo objeto do backdoor
• O código inicial do backdoor é chamado duas vezes porque lzma_crc32 e lzma_crc64 usam a mesma função modificada _get_cpuid
  • Um contador simples verifica se ele já foi executado
  • Quando o IFUNC de lzma_crc64 chama _get_cpuid e o contador vale 1, começa a etapa que redireciona para o ponto de entrada final

Comportamento em tempo de execução e alvos dos hooks

• O backdoor inicializa estruturas que contêm informações essenciais sobre o processo em execução
• Ele encontra o endereço da Global Offset Table(GOT) por offsets hardcoded e localiza ali o ponteiro de cpuid
• Em seguida, troca esse ponteiro pela função maliciosa principal, fazendo com que a função maliciosa seja chamada como se estivesse chamando cpuid
• O objetivo principal é aplicar hooks em funções específicas para poder monitorar conexões que chegam à máquina infectada
• As funções-alvo estão relacionadas ao libcrypto
  • RSA_public_decrypt: usada para descriptografar um texto cifrado assinado com chave privada
  • EVP_PKEY_set1_RSA: usada para definir uma chave RSA em um contexto específico
    • Não aparece em versões mais novas do servidor SSH, mas é usada em uma ferramenta independente de geração de chaves SSH
  • RSA_get0_key: usada para obter uma chave RSA
• O processo de hook exige acesso a várias estruturas internas e manipulação de estruturas específicas do processo, e o código malicioso também executa checagens para evitar análise

Verificações do ambiente de execução e técnicas de evasão de análise

• Verificação de sshd e kill switch

  • O backdoor começa fazendo parsing do linker dinâmico ld-linux, que resolve endereços de símbolos dinamicamente
  • Ele verifica se o ambiente de execução atual atende aos critérios
  • Confirma se o processo atual é /usr/bin/sshd
  • Verifica se existe um kill switch
  • O nome do processo atual é extraído de argv[0]
  • Todas as variáveis de ambiente do processo são analisadas para verificar se correspondem a valores da tabela interna de strings
  • Se houver uma variável de ambiente correspondente ou se o processo não for sshd, o código malicioso interrompe a execução
  • A única variável da tabela interna, yolAbejyiejuvnup=Evjtgvsh5okmkAvj, funciona neste contexto como kill switch

• Processamento de strings baseado em trie

  • Uma das características do backdoor é usar uma única estrutura trie para operações com strings
  • Em vez de comparar diretamente constantes como nomes de função ou usar hash de strings, ele verifica se o resultado da busca na trie é igual a um valor constante específico
  • O valor mágico do cabeçalho ELF retorna 0x300 na trie
  • O nome da função system corresponde ao valor retornado 0x9F8
  • A trie é usada não só para comparação, mas também para encontrar strings dentro do binário hospedeiro
  • Por exemplo, funções que usam ponteiros para strings como ssh-2.0 procuram essas strings no binário hospedeiro para não deixar dados suspeitos no corpo do backdoor
  • A implementação usa uma máscara de bits de 16 bytes
  • Cada metade corresponde aos intervalos de bytes de entrada 0x00-0x3F e 0x40-0x7F
  • Os nós-folha da trie têm 2 bytes; 3 bits são usados como flags e o restante é reservado para o valor ou para a posição do próximo nó

Resolução de símbolos e hook de rtdl-audit

• Rotinas de resolução de símbolos

  • O backdoor tem pelo menos 3 rotinas de resolução de símbolos para encontrar estruturas ELF Symbol
  • Todas as funções de resolução recebem como entrada uma chave a ser buscada na trie
  • Uma das funções percorre todos os símbolos até encontrar o símbolo com a chave desejada e, ao encontrá-lo, retorna a estrutura Elf64_Sym
  • Essa estrutura é então usada para preencher estruturas internas do backdoor e armazenar os ponteiros de função necessários
  • Esse processo é semelhante às rotinas de hash de API comuns em ameaças para Windows
  • Depois, o backdoor procura várias funções OpenSSL libcrypto que serão usadas em rotinas criptográficas
  • Ele acompanha a quantidade de funções encontradas e resolvidas, e usa esse valor para decidir se a execução segue normalmente ou é interrompida

• Allocator falso abusando de lzma_alloc

  • Outro resolvedor de símbolos abusa da própria função lzma_alloc do liblzma
  • lzma_alloc ajuda a alocar memória com eficiência usando o allocator padrão malloc ou um allocator customizado
  • No backdoor do XZ, essa função passa a operar como outro resolvedor de símbolos por meio de um allocator falso
  • O parâmetro originalmente usado como “tamanho da alocação” é na verdade usado como chave de símbolo dentro da trie
  • Esse truque tem como objetivo dificultar a análise do backdoor
  • O backdoor resolve símbolos dinamicamente em tempo de execução, sem ficar limitado a resolver tudo de uma vez ou apenas quando necessário
  • Os alvos incluem desde funções OpenSSL legítimas até system, usada para executar comandos na máquina

• Patch em tempo de execução de rtdl-audit

  • Para fazer hook de funções, o backdoor usa o recurso rtdl-audit do linker dinâmico
  • Em geral, o rtdl-audit permite que desenvolvedores criem uma biblioteca compartilhada customizada para receber notificações de eventos do linker, como resolução de símbolos
  • Em vez de criar uma biblioteca compartilhada separada, o backdoor do XZ faz um patch em tempo de execução na interface padrão já registrada na memória para sequestrar a rotina de resolução de símbolos
  • A estrutura maliciosa audit_iface armazenada na variável global dl_audit da área de memória do linker dinâmico contém o endereço do callback symbind64
  • Quando o linker dinâmico chama esse callback, todas as informações de símbolo passam para o controle do backdoor, que retorna endereços maliciosos para as funções-alvo e assim conclui o hook
  • Os endereços de dl_audit e dl_naudit são obtidos por desassemblagem das funções dl_main e dl_audit_symbind_alt
  • O backdoor inclui um desmontador interno mínimo para decodificar instruções, amplamente usado ao procurar valores específicos como endereços *audit

Distribuições com backdoor confirmadas e informações de detecção

• Distribuições de código-fonte com backdoor

  • xz-5.6.0
    • MD5: c518d573a716b2b2bc2413e6c9b5dbde
    • SHA1: e7bbec6f99b6b06c46420d4b6e5b6daa86948d3b
    • SHA256: 0f5c81f14171b74fcc9777d302304d964e63ffc2d7b634ef023a7249d9b5d875
  • xz-5.6.1
    • MD5: 5aeddab53ee2cbd694f901a080f84bf1
    • SHA1: 675fd58f48dba5eceaf8bfc259d0ea1aab7ad0a7
    • SHA256: 2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8

• Principais artefatos analisados

  • bad-3-corrupt_lzma2.xz: 86fc2c94f8fa3938e3261d0b9eb4836be289f8ae
  • build-to-host.m4: b4dd2661a7c69e85f19216a6dbbb1664
  • good-large_compressed.lzma: 540c665dfcd4e5cfba5b72b4787fec4f
  • liblzma_la-crc64-fast.o: 212ffa0b24bb7d749532425a46764433

• Bibliotecas conhecidas com backdoor

  • Debian Sid liblzma.so.5.6.0
    • MD5: 4f0cf1d2a2d44b75079b3ea5ed28fe54
    • SHA1: 72e8163734d586b6360b24167a3aff2a3c961efb
    • SHA256: 319feb5a9cddd81955d915b5632b4a5f8f9080281fb46e2f6d69d53f693c23ae
  • Debian Sid liblzma.so.5.6.1
    • MD5: 53d82bb511b71a5d4794cf2d8a2072c1
    • SHA1: 8a75968834fc11ba774d7bbdc566d272ff45476c
    • SHA256: 605861f833fc181c7cdcabd5577ddb8989bea332648a8f498b4eef89b8f85ad4

• Nomes de detecção

  • Produtos da Kaspersky detectam objetos maliciosos relacionados ao ataque como HEUR:Trojan.Script.XZ e Trojan.Shell.XZ
  • O Kaspersky Endpoint Security for Linux detecta o código malicioso na memória do processo SSHD como MEM:Trojan.Linux.XZ como parte da tarefa Critical Areas Scan
  • A regra Yara fornecida é liblzma_get_cpuid_function, voltada a encontrar a função maliciosa get_cpuid relacionada ao CVE-2024-3094

[GN⁺]

Opiniões do Hacker News

• Esta frase parece, na verdade, minimizar o que aconteceu
  Mais assustador do que o aspecto técnico do backdoor é a quantidade e o nível de engenharia social envolvidos. O backdoor foi o produto final, e ele só pôde ser inserido porque, naquele momento, todo o projeto xz já estava sob controle de agentes maliciosos, isto é, “Jia Tan” e seu entorno, havia um longo tempo. Eles travaram uma guerra psicológica contra o mantenedor por mais de um ano, e nem o mantenedor nem ninguém mais percebeu
  Parece coisa de romance de espionagem, e se algo assim é possível, dá vontade de pensar no que mais pode estar acontecendo em outros projetos neste exato momento
  O próprio código do backdoor revela a mesma forma de pensar. Não se trata apenas de parecer inofensivo; ele constrói ativamente uma narrativa sobre o que aparenta fazer por meio de mensagens de commit, comentários, nomes de variáveis e escolhas de comandos, enquanto na prática faz algo completamente diferente. A estrutura foi feita para levar quem analisa o código primeiro a duvidar da própria compreensão, depois a suspeitar de um bug, e só muito mais tarde a suspeitar de má-fé

  • É um nível realmente difícil de acreditar. Pode soar como teoria da conspiração, mas fico me perguntando se não houve também alguma operação psicológica no mundo real para impedir que o autor original pudesse dedicar tempo ao projeto e acabasse transferindo o controle para um agente malicioso
    Espero que alguma agência de inteligência esteja investigando esse caso mais a fundo
  • Espero que isso sirva de lição. Muita coisa realmente está acontecendo. Entre agências financiadas por governos do mundo todo e grupos do mercado clandestino, há muitos cuja missão é justamente obter backdoors, e eles têm dinheiro de sobra. Esse é o trabalho deles
    É frustrante ver, em toda thread do HN sobre backdoors, gente descartando essa possibilidade como paranoia ou chapéu de papel-alumínio. Tratam como se isso não acontecesse, mas desta vez foi apenas um caso concreto que foi pego; os que ainda não foram descobertos são incontáveis
    Neste caso, por ser um projeto open source, foi relativamente mais fácil detectar, e ainda assim foi preciso sorte. Agora pense em produtos de código fechado: inserir um backdoor passa a ser apenas uma questão de infiltrar ou pressionar uma organização. Isso acontece com frequência. Ninguém quer acreditar, mas é comum. Quem já trabalhou em empresas de infraestrutura tecnológica provavelmente tem algumas histórias. É difícil falar por causa de NDA ou motivos ainda piores, mas isso de fato acontece
  • Concordo totalmente com a ideia de que quem examina o código acaba duvidando da própria compreensão. A manipulação, o cuidado meticuloso, a paciência e a persistência investidos nisso são impressionantes
    Pode ser o resultado da obsessão de alguém, ou o trabalho de uma empresa privada de segurança ou de um agente estatal que faz esse tipo de coisa como trabalho de escritório, das 9 às 5, em vários projetos

• Até agora, é natural que a atenção tenha se concentrado no sucesso operacional do backdoor e em como ele atingia seu objetivo
  Ainda assim, eu gostaria de ver uma análise mais profunda dos erros e das partes excessivamente engenheiradas. Na entrevista de Bryan Cantrill [1], Andrés diz que isso parece um componente de backdoor pronto, que nem foi feito com pleno conhecimento do modo de distribuição, e por isso há várias partes burras. Por exemplo, a busca na tabela de símbolos que o levou à investigação
  Da mesma forma, também queria entender por que cortaram 48 bytes com RC4 [2]
  Gostaria de ouvir discussões sobre como isso poderia ter sido feito melhor, se tivessem mais tempo ou uma equipe melhor, ou em que pontos eles erraram de forma mais grave
  [1] https://youtu.be/jg5F9UupL6I?si=gvXsYFXgagkGOMd4
  [2] https://twitter.com/matthew_d_green/status/17744729080201014...

• Se entendi corretamente, uma medida útil seria fazer com que cada biblioteca de linkagem dinâmica tenha sua própria GOT e marcar a tabela como somente leitura quando a linkagem dinâmica terminar. Em outras palavras, impedir que se faça patch em entradas ifunc do outro lado da fronteira dinâmica
  Isso poderia melhorar a segurança da cadeia de suprimentos para código que é linkado em algum lugar, mas não chega a ser executado
  Indo além, talvez fosse melhor implementar ifunc de forma declarativa, para que não fosse possível disparar execução arbitrária de código em cada biblioteca durante a linkagem. A implementação atual deve ser difícil de mudar por causa da compatibilidade retroativa, mas no longo prazo isso parece algo que poderia ser introduzido em camadas. Por exemplo, se uma certa biblioteca fosse compilada com um bit de recurso “ifunc de linkagem declarativa”, o linker dinâmico falharia na execução caso nem todas as bibliotecas conectadas tivessem o mesmo flag de recurso

  • De outro ângulo, o problema é o sistema de build
    Hoje, a maioria das builds de bibliotecas funciona executando scripts extremamente complexos e obscuros, que exigem ambientes Turing-completos. Isso dá ao atacante uma superfície de ataque praticamente infinita, e quando o processo de build é comprometido, surgem oportunidades
    Ajudaria migrar para um processo de build declarativo em que o executor fosse apenas uma máquina de estados restrita. Também valeria considerar a exigência de que todo bloco de código-fonte fosse reproduzível
  • Sim e não, mas em geral não. Essa abordagem impediria esse uso simples de ifunc desse jeito, mas o ponto importante é que o autor desse backdoor conseguiu injetar código arbitrário em uma biblioteca que entrava no espaço de endereçamento de um processo sensível
    A partir desse momento, todas as defesas perdem o sentido. Se quiser, ele pode remapear a GOT como gravável de novo, e mesmo que esse tipo de ação seja detectado como “suspeito” ou que o sistema operacional impeça essa transição, o código injetado ainda pode inverter o fluxo de controle de centenas de outras maneiras. Leitura/escrita arbitrária, execução de código, tudo é possível. Não existe mitigação de segurança que impeça uma invasão nesse estágio. Se quiser, ele pode até exfiltrar a chave privada e enviá-la diretamente ao atacante, ou abrir um shell. Tentar projetar proteção nesse estágio é perda de tempo
  • Marcar a tabela como somente leitura após o fim da linkagem dinâmica infelizmente não funciona. A linkagem dinâmica é preguiçosa; não existe um momento em que ela “termina”
    O ponteiro de função correto é carregado na primeira chamada e inserido na tabela no lugar do stub, e isso pode acontecer em um futuro arbitrariamente distante. De fato, em ecossistemas grandes de bibliotecas, como apps gtk, a maioria das funções linkadas nunca chega a ser chamada
  • Se você compila para a arquitetura do host, dá para desativar ifunc completamente sem perdas. No Gentoo, compilar com -march=native é comum, e definir -multiarch nos USE flags da glibc torna simples desabilitar ifunc. Não vi impactos negativos
  • Existe alguma linguagem de programação que permita colocar em sandbox a importação de bibliotecas?

• Em relação às 3 primeiras etapas, este texto não acrescenta muito ao que já se sabia nas últimas 2 semanas. É mais um bom texto de organização com fluxograma
  Mas a parte que analisa o binário nesse nível de detalhe parece nova
  Como será que o código-fonte mostrado ali foi produzido? Rodaram um disassembler, entenderam o que o código fazia e depois trocaram todos os nomes por nomes descritivos? Para algo feito em 2 semanas, parece um resultado bem impressionante

  • O autor é o GReAT
    Global Research & Analysis Team, Kaspersky Lab
    https://securelist.com/author/great/
    Como quem escreveu parece ser a equipe de análise de malware da Kaspersky Lab, é bem provável que sejam muito bons em engenharia reversa de binários
  • A ferramenta usada na captura de tela com fundo branco é o decompilador IDA Pro
    https://hex-rays.com/ida-pro/

• O que eu realmente queria saber é o que exatamente causou o atraso inicial no SSH que desencadeou a investigação do xz. Quem descobriu isso?

  • Ele faz uma operação ECC extra por conexão, mas isso não deveria levar 500 ms em uma CPU moderna
    Segundo quem fez a engenharia reversa do código, a mensagem de comando também precisava ser vinculada à chave de host do SSH. Então, se a chave de host fosse uma chave RSA, ele talvez também executasse uma operação adicional de descriptografia RSA por conexão
    Se for isso, parece suficiente para explicar a latência
  • Pode ter sido de propósito
    É uma forma fácil de descobrir de fora se um servidor foi infectado, sem nem tentar injetar código primeiro

• Os autores conhecem as estruturas internas da glibc em um nível muito profundo. É o tipo de coisa que você só sabe estando mergulhado até o pescoço no código-fonte, e há muitas técnicas novas também
  O parser ELF customizado e o disassembler são complexos demais; é difícil imaginar que esse código não tenha sido usado antes em outro lugar ou que nunca mais venha a ser reutilizado
  Fico me perguntando se esse caso vai receber uma investigação séria no nível que merece, mas não parece que vai

• Alguém analisou o bug no backdoor que acabou causando o erro no Valgrind e a lentidão no SSH, e que no fim revelou tudo isso?

  • Aparentemente foi uma gravação de memória claramente incorreta: https://www.mail-archive.com/[e-mail]...
    A “correção” do Valgrind foi desativar o ifunc, e com isso o backdoor foi desativado, então o erro desapareceu
    Pelo que sei, a lentidão vinha de todas as consultas de símbolos e instruções executadas pelo backdoor

• Vendo por outro ângulo, considerando o esforço que o atacante colocou em evitar detecção nos scripts e no código, o projeto inteiro pode ter sido uma distração ou uma contingência enquanto várias tentativas aconteciam ao mesmo tempo
  Como ficar um passo à frente de algo assim? O foco da comunidade no SSHD afeta outras partes do sistema como um todo? E outros aspectos técnicos ou sociais?
  O chapéu de papel-alumínio é divertido

  • Não sou otimista. Quase ninguém audita de fato o conteúdo dos binários flatpak do Flathub. Será que eles realmente foram compilados a partir do código-fonte? É mais na base de o autor dizer que sim. Talvez nem seja necessário um mecanismo de entrega tão sofisticado quanto o deste backdoor
  • Você pode escrever tudo por conta própria e ter uma equipe dedicada formada por desenvolvedores confiáveis
    Ou comprar código fechado de algum lugar como a Microsoft e torcer para que eles tenham os recursos e a disposição para revisar o código de forma mais rigorosa
    E sempre existe a abordagem de ter uma ótima equipe de operações de segurança para detectar atividade de rede estranha e tentativas de elevação de privilégio
  • Como forma de ficar um passo à frente de backdoors semelhantes, penso em encapsular o tráfego do sshd em um túnel spiped. O Spiped pode ser compilado a partir do código-fonte, é estaticamente linkado, e a última versão estável é de 2021
  • Minha ideia de chapéu de papel-alumínio é desconfiar de contribuidores de open source. Não por serem de algum país específico, nem por parecer que você nunca os encontrou pessoalmente
    Mas contribuidores que não têm histórico nem pegadas fora do projeto em que estão trabalhando deveriam passar a ser vistos como um sinal de alerta
  • Não precisa de chapéu de papel-alumínio. Projetos FOSS recebem backdoors desde antes de ficarem famosos, e a diferença desta vez é que isso está sendo feito por um ator com apoio estatal
    Grupos antigos como GOBBLES, ADM, ac1db1tch3z, ~el8 já faziam esse tipo de coisa, e “pesquisadores de segurança” privados como a isec.pl também
    O problema agora é que atores estatais estão explorando o capitalismo corporativo que criou uma era em que projetos de infraestrutura são sustentados por trabalho mal remunerado. Os agentes maliciosos têm recursos praticamente ilimitados para atingir seus objetivos
    Isso acabou gerando a demanda e o surgimento de organizações como NSO e Zerodium
    Antes disso, exploits e backdoors quase não tinham valor, e hackers esperavam patrocínio ou contratação por empresas como a Qualys

• Já vi algumas análises do Google sobre hacks de vulnerabilidades zero-day, e elas também eram absurdamente impressionantes, mas este ataque parece ser um dos maiores de todos os tempos

• Vi que o repositório do xz voltou ao GitHub, e o Lasse com um novo contribuidor estavam organizando as coisas. Removeram o suporte a ifunc e fizeram commit no repositório do código de geração dos arquivos de teste para que os arquivos de teste possam ser criados sem blobs. Parece que estão trabalhando na direção certa