Rabbit hole do backdoor xz no sshd é muito mais profundo do que se esperava

• O backdoor xz no sshd vai além do hook RSA_public_decrypt revelado inicialmente e aciona parcialmente caminhos de código adicionais mais difíceis de acessar
• O fluxo do ataque instala um hook em mm_answer_keyallowed por meio de um comando manipulado e, em seguida, monta um buffer de comandos usando várias chaves públicas ssh-rsa falsas
• Esse “magic buffer” contém comandos adicionais do backdoor e 2 assinaturas ed448; as assinaturas incorporam o digest SHA256 da chave do host e o session_id do KEX
• O PoC atual usa uma biblioteca cliente SSH paramiko fortemente modificada, e o comando 0x03 permite RCE baseada em system() e configuração de uid/gid
• O bypass de autenticação também foi confirmado; ao sobrescrever a resposta de mm_answer_authpassword com mm_keyallowed_backdoor cmd 1, é possível fazer login com qualquer senha

---

Caminho de backdoor conectado em maior profundidade

• O backdoor xz no sshd inclui funcionalidades mais profundas do que o comportamento inicialmente conhecido, e algumas delas já foram acionadas diretamente
• O principal ponto de entrada é o hook RSA_public_decrypt
  • Ao enviar um comando criado corretamente, outro hook é instalado na função mm_answer_keyallowed do sshd
  • Depois disso, várias chaves públicas ssh-rsa falsas são fornecidas para fragmentar e combinar o “magic buffer”
• O “magic buffer” é um buffer que contém comandos adicionais do backdoor
  • Ele também inclui 2 assinaturas ed448
  • Essas assinaturas recebem salt com o digest SHA256 da chave do host, como a assinatura do backdoor no lado de RSA_public_decrypt
  • A assinatura final também incorpora o session_id de 0x20 bytes derivado da troca inicial de chaves SSH (KEX)

PoC e bypass de autenticação

• O PoC atual foi implementado com uma biblioteca cliente SSH paramiko fortemente modificada
• O comando acionado atualmente nesse caminho de código é 0x03
  • Ele permite novamente RCE básica por meio de system()
  • Também oferece suporte à configuração de uid/gid
• Ainda há mais código a entender e, como um dos comandos do backdoor em mm_answer_keyallowed acaba também aplicando um hook em mm_answer_keyverify, parece possível realizar um bypass completo de autenticação em sessões interativas
• O bypass de autenticação foi confirmado posteriormente
  • mm_keyallowed_backdoor cmd 1 pode sobrescrever a resposta de mm_answer_authpassword com um valor definido pelo usuário
  • Ao definir a resposta como { u32(9), u8(13), u32(1), u32(0) }, é possível fazer login com qualquer senha

[GN⁺]

Opiniões do Hacker News

• https://threadreaderapp.com/thread/1776691497506623562.html

• Este caso é estranho porque, em alguns aspectos, parece muito profissional e, em outros, bastante amador
  Eles construíram por muito tempo uma identidade confiável o bastante para virar mantenedores de um pacote importante, conduziram um ataque de engenharia social que parece ter envolvido várias pessoas, não expuseram sua identidade real nem a origem do ataque, e a ofuscação também era sofisticada
  Ainda assim, o fato de bugs e uma regressão de desempenho terem chegado à versão de produção parece descuidado. Se uma organização patrocinada por um Estado fosse realmente competente, eu imaginaria que ela testaria bastante em privado antes de submeter a um projeto público, eliminando degradações de desempenho que levantariam suspeitas

  • Acho que as expectativas ficam altas demais quando se ouve “patrocinado por Estado”. Grandes organizações acabam se tornando parecidas com outras grandes organizações e sofrem com burocracia, prazos, ciclos de lançamento e problemas de comunicação entre equipes
    O caso recente no iOS, “talvez uma backdoor”, também mostra que organizações que acumulam muitas vulnerabilidades nem sempre se preocupam em queimar algumas delas
  • Não é difícil acreditar que as pessoas que desenvolveram o código não estivessem ao mesmo tempo rodando Valgrind e observando o desempenho
    O alvo eram servidores e appliances, e quantos servidores ou appliances rodam Valgrind na imagem padrão? Em retrospecto, dá para pensar “como não pensaram nisso?”, mas é bem provável que tenham testado nas imagens de sistema que miravam, não em imagens customizadas de desenvolvedores comuns
  • Em 2024-02-29, foi aberto um PR para deixar de linkar a liblzma na libsystemd [0]
    Kevin Beaumont especulou que “Jia Tan” viu isso e percebeu imediatamente que a backdoor poderia ser neutralizada, então teria se apressado para não desperdiçar o enorme trabalho investido nesse exploit [1], e isso parece fazer sentido
    Essa pressão de prazo provavelmente causou o crash na 5.6.0 e deixou pouco tempo para polir o código a fim de reduzir ou eliminar a regressão de desempenho, que foi o principal motivo pelo qual o caso foi descoberto
    [0]: https://github.com/systemd/systemd/pull/31550
    [1]: https://doublepulsar.com/inside-the-failed-attempt-to-backdo...
  • Se o Google conseguiu lançar o Gemini como se nada fosse, é tão difícil acreditar que uma organização nas sombras possa falhar de maneiras mais sutis?
    Como Patrick McKenzie observa em outros lugares, organizações criminosas também funcionam de modo parecido com organizações não criminosas, por meio de comitês e consenso. Visto assim, dá para entender um navio afundando por degradação de desempenho causada por excesso de funcionalidades. Empresas em que trabalhei cometeram erros ainda mais amadores
  • Acidentes podem acontecer mesmo em organizações competentes patrocinadas por Estados. Agências de inteligência às vezes não são tão friamente competentes quanto imaginamos. As tentativas de assassinato do Kremlin no Reino Unido foram quase uma comédia de erros [1]
    Talvez alguma outra backdoor ou meio alternativo de acesso que eles usavam tenha sido bloqueado, e eles tenham precisado às pressas de uma nova via
    [1] https://en.wikipedia.org/wiki/Poisoning_of_Alexander_Litvine...

• O nível de sofisticação aqui é realmente interessante, mas no fim foi descoberto por uma regressão de desempenho bastante perceptível
  Isso me lembra uma citação que ouvi em um programa policial real: “Há um milhão de maneiras de ser pego por assassinato; se você conseguir pensar em metade delas, é um gênio”

  • Faz sentido se considerarmos que havia uma equipe por trás da conta. Alguém pode ter desenvolvido a funcionalidade, e outra pessoa, mais descuidada ou menos experiente, pode tê-la integrado
    Outra pessoa ainda pode ter gerenciado as contas falsas e interagido em comentários e PRs
  • Talvez eu seja ingênuo ou crédulo demais, mas toda vez que me preocupo que backdoors como essa já estejam amplamente disseminadas, penso nisso
    Não sei se esta simplesmente teve o azar de ser descoberta, ou se ataques desse tipo são de fato difíceis demais para serem bem-sucedidos. Espero que seja a segunda opção, mas na verdade não dá para saber
  • Se me lembro bem, a regressão de desempenho só ocorria quando o código era compilado com -fno-omit-frame-pointer, que não era o padrão. https://mastodon.social/@AndresFreundTec/112187000944648334
  • Com tempo suficiente e mais testes locais, é bem provável que teriam tido sucesso
    Tenho certeza de que o patch de @teknoraver na libsystemd mudou o prazo deles
  • A frase “se você conseguir pensar em metade delas” também se aplica a quem tenta resolver casos de assassinato?

• Quando aparecem muitos textos técnicos que se aprofundam nos detalhes de casos assim, frequentemente fico me perguntando por que todo mundo diz “isso com certeza tem patrocínio estatal”, “olhe os timestamps, é uma prova irrefutável”
  É verdade que o caso do xz foi um ataque furtivo e preparado por muito tempo, mas será que ele realmente exige algo além de uma única pessoa competente? O fato de pessoas aleatórias na internet conseguirem analisar e entender também significa que está dentro do escopo do que uma pessoa consegue compreender
  Por que não pode ter sido simplesmente uma pessoa inteligente, porém ressentida, agindo sozinha?

  • O maior fator que faz pensar em um ator estatal é o tamanho da recompensa esperada em relação ao tempo investido no ataque de engenharia social
    Um plano com fins lucrativos desse tipo é irracional. Isso não exclui a possibilidade de um ator irracional ou de um indivíduo com motivações que não sejam dinheiro, mas faz um ator estatal parecer o candidato mais provável
    Se tivesse dado certo, o valor vendável teria sido enorme, mas a probabilidade de inserir um exploit em infraestrutura crítica e não ser descoberto por tempo suficiente para clientes comprarem e usarem é muito baixa. Estados conseguem bancar moonshots, mas acho que indivíduos tendem a procurar alvos com valor esperado maior
    Claro que isso não significa que tenha sido um ator estatal competente, nem que tenham alocado muitos recursos
  • Concordo. Esse hack exigiu muita habilidade, determinação e tempo
    Mas isso não se aplica também a uma boa parte dos desenvolvedores open source? A motivação também é clara. Esse exploit provavelmente valeria milhões de dólares no mercado negro
  • Nada. Ninguém sabe quem ele é
  • Fico curioso sobre a base para dizer “prova irrefutável”; onde você viu isso?
    Vi muitas conjecturas de pessoas bem informadas, mas não vi essa expressão

• Existe algum texto que organize a ofuscação do backdoor em si? Não o script de build para instalação, mas o backdoor de fato
  Coloquei o binário no Ghidra e passei os olhos pelas funções encontradas, mas não estou familiarizado com o mecanismo ifunc usado para interceptar a execução, então desisti e deixei para outras pessoas
  Como há recurso anti-debugging, imagino que o código também tenha sido ofuscado. Como foi distribuído como um binário opaco, pensei que pelo menos parte do código tivesse sido criptografada com uma chave que não temos. Como partes do payload do STUXNET

  • Ainda não saiu uma análise completa do backdoor em si. Há tipos de anti-debugging que podem ser contornados com flags, mas neste caso isso foi tratado na etapa de compilação, o que o torna um pouco mais complicado
    O fato de haver recursos anti-debugging não significa necessariamente que o código tenha sido ofuscado. Como dito acima, isso aconteceu em tempo de build. É como se a armadilha já tivesse sido instalada dentro da própria casa
    Este caso mostra o problema que surge quando um mantenedor de pacote não usa o código-fonte da origem correta

• Não acompanhei este caso em detalhes, mas acho muito estranho que quase não se ouça discussão sobre o autor do ataque

  • “No entanto, acredito que ele na verdade seja da região de fuso UTC+02 no inverno/UTC+03 no horário de verão, ou seja, uma área que inclui a Europa Oriental (EET) ou Israel (IST)”
    https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
  • Houve muita especulação. É mais provável que tenha sido mais de uma pessoa do que uma só, e parece possível que tenha sido um grupo de ransomware ou uma agência de inteligência estatal
  • Como na análise do Satoshi, seria interessante fazer uma análise semântica das comunicações das personas online relacionadas para tentar inferir uma direção cultural
    Observando se houve diferenças de estilo ao longo do tempo, também daria para ver se várias pessoas atuaram sob a mesma persona. Há bastante código commitado também, então valeria examinar diferenças de estilo de código para ver se mais de uma pessoa esteve envolvida
  • Discutir o quê? Não se sabe absolutamente nada

• Foi muita sorte isso ter sido descoberto antes de se espalhar amplamente
  Não é apenas pelo motivo óbvio de não querermos que uma entidade desconhecida tenha execução remota de código na nossa infraestrutura. Se as pessoas continuarem investigando, é possível que eventualmente produzam um payload que permita que qualquer um use o backdoor
  Já é ruim uma entidade ter acesso, mas permitir que qualquer pessoa tenha acesso é muito pior

  • Se o payload for uma chave RSA privada, isso não é praticamente impossível?

• Link para ver no lugar de thereaderapp.com:
  https://nitter.poast.org/bl4sty/status/1776691497506623562

• É surpreendente que, passados alguns dias, isso ainda não tenha sido completamente desvendado
  Com os olhos do mundo inteiro voltados para o caso e com as peças centrais teoricamente públicas, resistir desse jeito significa que a ofuscação foi muito bem feita

• O caráter de jogo de longo prazo deste caso me preocupa
  Primeiro, esperaram por muito tempo para construir a “infraestrutura” que permitiria criar o backdoor. Segundo, mesmo depois que o exploit se espalhasse para produção de verdade, provavelmente teriam preparado outro jogo de longo prazo. O jeito certo de gastar um prêmio de loteria é investir
  Terceiro, fico me perguntando se esse tipo de jogo continua acontecendo agora. Assustador