主页 / unix / 问题 / 788637
Accepted
Ketho
Asked: 2024-12-25 00:27:16 +0800 CST

在 Kali Linux 上重现 XZ Utils 后门

  • 772

我想通过遵循xzbot漏洞演示并设置环境来了解 XZ Utils 后门。我知道xz-utils 5.6.1版本应该有后门，但我无法安装这个被感染的软件包。

从干净的 Kali Linux 2024.4 环境开始，它具有 liblzma 5.6.3，并且sshd似乎不依赖于 libsystemd 和 liblzma。显然，无论是原装还是便携式 OpenSSH 都没有提供 systemd 支持。我对所有指南都期望sshd已经链接到 liblzma 感到困惑，但它不适合我。

└─$ 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)

当降级到 liblzma 5.6.1 包并ldd再次检查时，似乎没有任何变化。

└─$ 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)

然后我尝试构建 OpenSSH 9.7p1，因为那是在后门公开之前，如果这也许有帮助的话。这需要重新启动才能sshd -V显示 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

但是 libsystemd 和 liblzma 仍然没有链接到 sshd。

到目前为止，我甚至不知道如何安装或构建易受攻击的 xz-utils 包。当我在 Ubuntu 24.04 上尝试同样的步骤时，也遇到了类似的问题

systemd

1 个回答

  1. Best Answer

    根据此

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

    来自 Debian 的 OpenSSH更新日志

    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

    他们重构了代码以支持 systemd 通知，而无需在某个版本之后进行链接。

    您可以使用容器重现易受攻击的设置debian:12。就我个人而言，我喜欢使用容器重现设置，因为它们在重现工作负载方面更加可靠（不再是“但它在我的机器上有效”）。
    而且学习曲线也不太糟糕：

    隔离进程。隔离发生在内核级别。为所述进程创建不同的抽象，称为命名空间。所述进程被分配给它们。
    命名空间，例如网络命名空间、挂载命名空间和 PID 命名空间，是最重要的命名空间。子
    进程继承相同的命名空间（因此，如果我们在容器中使用 bash，我们运行的任何东西都将在相同的命名空间中）

    反正：

    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!"

    我们明确要求提供有漏洞的 openssh-server 版本

    最后一行的输出：

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

    容器的sshd版本和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:~#

    让我们来分析一下这些docker run论点：

    • --publish 127.0.0.1:22:22- 在主机上127.0.0.1:22发布容器的:22端口。换句话说，将流量（iptables在后台使用）从 127.0.0.1:22 路由到容器的 22。
    • --rm- 一旦容器的入口进程（基本上是其自身 pid 命名空间中的 pid 1）退出，就销毁容器。在本例中是bash。换句话说，当我们用完容器后。
    • --interactive- 附加到容器的标准输入，这样我们就可以告诉 bash 该做什么。 的合法版本nc -l -p <port> -e /bin/bash。
    • --tty- 使用--interactive将容器附加到我们的 tty，以防我们运行的任何东西需要终端。
    • --entrypoint=bash- 用我们自己的选择覆盖容器镜像的入口点bash。可能是默认的，但习惯使然。

    此时，您可以在容器中启动 sshd（其默认监听端口为 22），并且在主机上，任何发往 localhost:22（因此，它未在您的 LAN 及之后打开）的流量都将被路由到容器。您可以在 iptables（由 docker）中看到此路由定义。

    抱歉之前误导了你。

    • 3

相关问题