Executando verificação de segurança...
24
gpoleszuk
9 min de leitura ·

CVE-2024-3094 (Severidade: 10) 🌡️

Easter Egg or Easter Bug

Olá, boa tarde!

Ontem, 29.03.2024, veio a público uma falha grave que pode afetar o sshd (deamon responsável pelo serviço SSH em um servidor). Reportada com nível máximo de severidade (rated 10 out of 10 in CVSS severity), o que se sabe até agora é que foi descoberta por acaso e, aparentemente, deve-se a um supply chain_attack afetando versões da biblioteca liblzma.

A mecânica do exploit

Segundo Thomas Roccia, aka @fr0gger on X,

Thomas Roccia 🤘
@fr0gger_
🤯 The level of sophistication of the XZ attack is very impressive! I tried to make sense of the analysis in a single page (which was quite complicated)!

I hope it helps to make sense of the information out there. Please treat the information "as is" while the analysis progresses! 🧐 #infosec #xz

image
Source: https://twitter.com/fr0gger_/status/1774342248437813525

Detecção

Na thread que reporta a descoberta, um pequeno bash script detect_sh.bin auxilia verificar se um sistema pode estar comprometido. Um outro script xz_cve-2024-3094-detect.sh é disponibilizado em outra postagem (vale a pena conferir).

Segundo xeiaso, um teste rápido (não muito efetivo) seria inspecionar a versão do xz digitando a linha de comando seguinte e esperar encontrar algo diferente de versões 5.6.0 ou 5.6.1.

qualquer distro

$ xz --version
xz (XZ Utils) 5.6.1
liblzma 5.6.1

A saída acima indica um sistema possivelmente vulnerável.

apt (Debian/Ubuntu)

$apt list --installed 2>&1 | grep xz

yum (Fedora)

$yum list installed

Source: https://www.tecmint.com/list-installed-packages-in-rhel-centos-fedora

Correção

Atente-se, pois em breve um patch será oficialmente oferecido.

20240401T1514Z: Update com relação a sistemas Fedora: TabNews

alokemajumder postou um script CVE-2024-3094.sh que detecta a vulnerabilidade e a fixa com a instalação de uma versão anterior da lib (xz-5.4.6), contudo depende do repositório tukaani-project/xz que se encontra temporariamente desativado pelo GitHub (no momento da escrita deste post).

This repository has been disabled.
Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service. If you are the owner of the repository, you may reach out to GitHub Support for more information.

Efeito colateral suspeito

Um analista notou que a execução do sshd -h tomava mais tempo que o normal comparado a outra versão não afetada pelo exploit (na imagem, usaram, possivelmente, uma kill-switch recentemente descoberta).

image
Source: https://piaille.fr/@zeno/112185928685603910

Outras aplicações com ligação dinâmica e que fazem uso da lib podem ser avaliadas. Para saber todas as dependências de uma aplicação Linux, o comando ldd <app_fullpath_name> fornece uma breve listagem.

Suplemento

Matérias e informes têm sido publicados a respeito deste Easter Flaw.
https://tukaani.org/xz-backdoor
https://nvd.nist.gov/vuln/detail/CVE-2024-3094
https://www.theregister.com/2024/03/29/malicious_backdoor_xz
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

Evan Bohes mantém uma timeline sobre os eventos (notar que o assunto DNS é citado)
https://boehs.org/node/everything-i-know-about-the-xz-backdoor

Uma breve explicação e outra receita para conferir se seu sistema pode estar vulnerável foi apresenta em
https://xeiaso.net/notes/2024/xz-vuln

Neste link há uma TL;DR a respeito do exploit
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 ✳️

Mais detalhes sobre o código malicioso em

PS:
Ainda não entendo como o mecanismo desta vulnerabilidade afeta o sshd por meio do xz ou suas bibliotecas. Se alguém souber se realmente é possível um ataque ao sshd, vale a pena reforçar o comunicado para toda equipe de TI se preocupar e evitar que seus servidores sejam utilizados para fins ilegais. Segundo os emails phishings que recebemos, nota-se que o mecanismo atual de certos grupos é explorar (não destruir) servidores HTTP (com SSH) em nome/domínio de empresas de boa fé. De posse do servidor, os grupos passam a armazenar de códigos e ferramentas utilizadas para fins ilícitos (tracking pixels log, loggers payloads, disparos e recebimento de email, entre outras).

echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment

\int dx

Fonte: https://www.openwall.com/lists/oss-security/2024/03/29/4

5
1
gpoleszuk
Autor
Autor

Com certeza Pilati. O mundo mudou bastante!

Numa auditoria, quando vemos que há uma porta SSH aberta para a internet, pensamos em algumas possíveis hipóteses:

  • a porta realmente está aberta para manutenção. O admin tem alguma estratégia de segurança interna para prevenir possíveis ataques;
  • a porta está intencionalmente aberta para servir como honey pot. É incrível avaliar, pela captura dos logs, as tentativas de senha, o padrão de tentativas e os possíveis locais de origem. Caso o acesso ocorra, daí os comandos intentados são valiosos para uma avaliação de possíveis ataques 0-day (ainda desconhecidos);
  • a porta está acidentalmente aberta por inexperiência ou desconhecimento do administrador (aberta por default, esquecimento, etc.).

Também acredito que manutenção remota nos dias de hoje só por meio de uma camada extra de segurança proporcionada por uma VPN e/ou limitação por IP de acesso com solicitação programada para uso. No passado usava-se o Port Knocking, mas ...

2
1
gpoleszuk
Autor
Autor

Gostei do termo "Psicologia reversa!" adotado pelo Pedro Pessoa! Valeu pelos links, user1. Safesrc:Peter e Pedro procuram explicar esse fato relevante e o Pedro, inclusive, referencia outro vídeo com mais detalhes a respeito do exploit.

Se o indivíduo responsável por essas injeções de código trabalhou em projetos que são ferramentas base/bibliotecas, suspeito que até compiladores podem estar comprometidos. Atacar o kernel, como comenta o Pedro Pessoa, seria uma situação bastante desastrosa para os próximos dias, pois usamos um sistema (sobre um kernel) que já não saberemos se está em nivel 0 ou sobre uma virtualização controlada causada por outra vulnerabilidade já conhecida.

Espero que o iptables também não esteja comprometido. Ainda acredito na efetividade das regras do firewall. Enquanto não há um patch para o que está vulnerável, a "segurança por obscuridade" força git managers esconder as evidências.

2
2
gpoleszuk
Autor
Autor

Muito bem explicado rafael! Segundo a tabela na matéria, uma das versões do Kali Linux também não "escapou" :\

De acordo com uma das citações nos comentários:

"This developer persona has touched dozens of other pieces of open-source software in the past few years.". Well, I guess the Opensource community have some codes to review. Maybe the xz incident is only the tips of the iceberg."

Vejo que é um fato relevante e a impressão que passa, pelas evidências que estão surgindo, é que o "projeto" foi colocado em prática usando um pouco de engenharia social com a escalada paciente de privilégios na cadeia de confiança de desenvolvimento de uma das libs utilizadas pelo sshd. Esta aplicação geralmente tem outras dependências se compilada, por exemplo, sem ligação dinâmica. Uma listagem das dependências pode ser obtida pelo comando ldd.

2
samukarb

vou deixar meu . para um playbook ansible.
1- wget https://raw.githubusercontent.com/byinarie/CVE-2024-3094-info/main/xz_cve-2024-3094-detect.sh
2- adicionar a var ao script: export TERM=xterm-256color

# tasks file for roles/cve
- name: Create cve directory if it does not exist
  ansible.builtin.file:
    path: /etc/cve
    state: directory
    mode: '0755'

- name: Copy vulnerability check script to remote host
  ansible.builtin.copy:
    src: xz_cve-2024-3094-detect.sh
    dest: /etc/cve/xz_cve-2024-3094-detect.sh
    mode: '0755'

- name: Display vulnerability check output (stdout_lines)
  ansible.builtin.debug:
    var: vulnerability_output.stdout_lines