Início / unix / Perguntas / 788637
Accepted
Ketho
Asked: 2024-12-25 00:27:16 +0800 CST

Reproduzindo o backdoor XZ Utils no Kali Linux

  • 772

Quero aprender sobre o backdoor do XZ Utils seguindo a demonstração do exploit xzbot e configurando o ambiente . Sei que a versão 5.6.1 do xz-utils deve ter o backdoor, mas não consigo instalar esse pacote comprometido.

Começando com um ambiente limpo Kali Linux 2024.4, ele tem liblzma 5.6.3 e sshdnão parece depender de libsystemd e liblzma. Aparentemente, nem o OpenSSH de estoque nem o portátil vêm com suporte ao systemd. Estou confuso com todos os guias que esperam sshdjá estar vinculados ao liblzma, enquanto ele simplesmente não é para mim.

└─$ dpkg -l | grep liblzma5
ii  liblzma5:amd64                                 5.6.3-1+b1                               amd64        XZ-format compression library

└─$ ldconfig -p | grep liblzma
        liblzma.so.5 (libc6,x86-64) => /lib/x86_64-linux-gnu/liblzma.so.5

└─$ sshd -V
OpenSSH_9.9p1 Debian-3, OpenSSL 3.3.2 3 Sep 2024

└─$ ldd $(which sshd)
        linux-vdso.so.1 (0x00007fc3de0b8000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fc3ddfde000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fc3dda00000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc3dd80a000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fc3dd768000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc3de0ba000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc3ddfbe000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fc3dd6a7000)

Ao fazer o downgrade para o pacote liblzma 5.6.1 e verificar lddnovamente, nada parece ter mudado.

└─$ wget https://snapshot.debian.org/archive/debian/20240328T025657Z/pool/main/x/xz-utils/liblzma5_5.6.1-1_amd64.deb             
2024-12-24 00:45:29 (4.72 MB/s) - ‘liblzma5_5.6.1-1_amd64.deb’ saved [252188/252188]

└─$ sudo dpkg -i ./liblzma5_5.6.1-1_amd64.deb
dpkg: warning: downgrading liblzma5:amd64 from 5.6.3-1+b1 to 5.6.1-1
(Reading database ... 425071 files and directories currently installed.)
Preparing to unpack ./liblzma5_5.6.1-1_amd64.deb ...
Unpacking liblzma5:amd64 (5.6.1-1) over (5.6.3-1+b1) ...
Setting up liblzma5:amd64 (5.6.1-1) ...
Processing triggers for libc-bin (2.40-3) ...

└─$ dpkg -l | grep liblzma5
ii  liblzma5:amd64                                 5.6.1-1                                  amd64        XZ-format compression library
                                                                                          
└─$ sudo systemctl restart ssh

└─$ ldd $(which sshd)                                                                                               
        linux-vdso.so.1 (0x00007f705e59b000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f705e4c1000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f705de00000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f705dc0a000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f705e41f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f705e59d000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f705e3ff000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f705db49000)

Então eu tentei construir o OpenSSH 9.7p1, já que isso foi antes do backdoor se tornar público, se isso talvez ajudasse. Isso exigiu uma reinicialização antes de sshd -Vmostrar 9.7p1

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz
tar -xvf openssh-9.7p1.tar.gz
cd openssh-9.7p1
sudo apt install libssl-dev
./configure
make
sudo make install

Mas tanto o libsystemd quanto o liblzma ainda não estavam vinculados ao sshd.

Neste ponto, não tenho a mínima ideia de como instalar ou construir o pacote vulnerável xz-utils. Tive problemas semelhantes ao tentar os mesmos passos com o Ubuntu 24.04

systemd

1 respostas

  1. Best Answer

    De acordo com isso

    openssh does not directly use liblzma. 
However debian and several other distributions 
patch openssh to support systemd notification, 
and libsystemd does depend on lzma.

    E do changelog do OpenSSH do Debian

    openssh (1:9.7p1-4) unstable; urgency=medium

  * Rework systemd readiness notification and socket activation patches to
    not link against libsystemd (the former via an upstream patch).
  * Force -fzero-call-used-regs=used not to be used on ppc64el (it's
    unsupported, but configure fails to detect this).

 -- Colin Watson <[email protected]>  Wed, 03 Apr 2024 12:06:08 +0100

    Eles refatoraram o código para dar suporte a notificações do systemd sem vincular a ele após uma determinada versão.

    Você pode reproduzir a configuração vulnerável usando o debian:12contêiner. Pessoalmente, eu adoro reproduzir configurações com contêineres, pois eles são muito mais confiáveis ​​na reprodução de uma carga de trabalho (não mais "mas funciona na minha máquina").
    E a curva de aprendizado não é tão ruim:

    Processo isolado. O isolamento acontece no nível do kernel. Diferentes abstratos chamados namespaces são criados para o dito processo. O dito processo é atribuído a eles.
    Namespaces como Network Namespace, Mount Namespace e PID Namespace, para citar os mais importantes.
    Subprocessos herdam os mesmos namespaces (então, se começarmos com bash em um contêiner, qualquer coisa que executarmos estará nos mesmos namespaces)

    De qualquer forma:

    docker run --publish 127.0.0.1:22:22 --rm --interactive --tty --entrypoint=bash \
  docker.io/library/debian:12  

    apt update
apt install -y wget "openssh-server=1:9.2*" bsdmainutils  # Last one is for `hexdump`
wget https://snapshot.debian.org/archive/debian/20240328T025657Z/pool/main/x/xz-utils/liblzma5_5.6.1-1_amd64.deb
apt-get install --allow-downgrades --yes ./liblzma5_5.6.1-1_amd64.deb
path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')"
  
hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410 \
  && echo "Found!"

    Solicitamos explicitamente uma versão vulnerável do openssh-server

    Saída da última linha:

    root@7f1a3034bee9:~# hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410 && echo "Found!"
Found!

    sshdVersão e saída do contêiner ldd.

    root@7f1a3034bee9:~# sshd -V
OpenSSH_9.2, OpenSSL 3.0.15 3 Sep 2024

root@7f1a3034bee9:~# ldd $(which sshd)
    linux-vdso.so.1 (0x00007fff38da2000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fce9e57a000)
    libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fce9e56e000)
    libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fce9e53d000)
    libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fce9e52b000)
    libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fce9e45b000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fce9e42b000)
    libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fce9e3d8000)
    libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fce9e2fe000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fce9e2f8000)
    libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fce9de72000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fce9de53000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fce9dc70000)
    libnsl.so.2 => /lib/x86_64-linux-gnu/libnsl.so.2 (0x00007fce9dc55000)
    libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007fce9dc4d000)
    libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007fce9dc41000)
    libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fce9dafa000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fce9dabb000)
    libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fce9d9ff000)
    liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fce9d9d9000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fce9e6f3000)
    libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fce9d93f000)
    libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fce9d912000)
    libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fce9d904000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fce9d8fb000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fce9d8ea000)
    libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007fce9d8bc000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fce9d894000)
root@7f1a3034bee9:~#

    Vamos analisar os docker runargumentos:

    • --publish 127.0.0.1:22:22- No host, 127.0.0.1:22publique a :22porta do contêiner. Em outras palavras, roteie o tráfego (usando iptables, sob o capô) de 127.0.0.1:22 para o contêiner 22.
    • --rm- Destrua o contêiner assim que seu processo de entrada (basicamente, seu pid 1 em seu próprio namespace pid) sair. Neste caso bash. Em outras palavras, quando terminarmos com o contêiner.
    • --interactive- Anexar ao stdin do contêiner para que possamos dizer ao bash o que fazer. A versão legítima de nc -l -p <port> -e /bin/bash.
    • --tty- Com o --interactive, anexamos o contêiner ao nosso tty caso algo que executamos precise de um terminal.
    • --entrypoint=bash- Substituir o ponto de entrada da imagem do contêiner com nossa própria seleção, bash. Provavelmente o padrão, mas força do hábito.

    Neste ponto, você pode iniciar, no contêiner, o sshd (com sua porta de escuta padrão de 22) e, no seu host, qualquer tráfego que vá para localhost:22 (portanto, não está aberto na sua LAN e em diante), será roteado para o contêiner. Você pode ver esse roteamento definido no iptables (pelo docker).

    Desculpe por ter enganado você antes.

    • 3

relate perguntas