Xzbot: Catatan, honeypot, dan demo exploit untuk backdoor xz

 (github.com/amlweems)
1 poin oleh GN⁺ 2024-04-02 | 1 komentar | Bagikan ke WhatsApp
  • xzbot adalah repositori untuk mengeksplorasi backdoor xz (CVE-2024-3094), yang menyediakan honeypot, patch kunci publik ED448, format payload backdoor, dan demo eksekusi kode jarak jauh
  • Honeypot menerapkan patch sederhana pada OpenSSH untuk mencatat upaya koneksi yang masuk dengan nilai N kunci publik yang sesuai dengan format backdoor ke log sshd
  • Patch ED448 mengganti kunci publik hardcoded yang dipakai backdoor untuk verifikasi tanda tangan dan dekripsi payload dengan kunci yang dibuat pengguna, sehingga backdoor dapat dipicu
  • Payload backdoor dimasukkan ke nilai N kunci tanda tangan CA pada sertifikat SSH; tipe permintaan dibuat dengan a * b + c, dan Type 2 menjalankan perintah null-terminated dengan system()
  • CLI demo menunjukkan alur menyambung ke server SSH yang rentan dan menjalankan perintah; eksploitasi yang berhasil tidak menghasilkan log INFO atau yang lebih tinggi

Cakupan dan komponen xzbot

  • xzbot adalah proyek untuk mengeksplorasi CVE-2024-3094, yaitu backdoor xz
  • Komponen yang disertakan ada empat
    • honeypot: server rentan palsu untuk mendeteksi percobaan exploit
    • ed448 patch: mem-patch liblzma.so agar memakai kunci publik ED448 sendiri
    • backdoor format: ringkasan format payload backdoor
    • backdoor demo: CLI untuk memicu RCE dengan asumsi kunci privat ED448 diketahui

Honeypot: mendeteksi percobaan melalui patch OpenSSH

  • openssh.patch adalah patch sederhana untuk OpenSSH yang mencatat upaya koneksi yang masuk dengan nilai N kunci publik yang sesuai dengan format backdoor
  • Alurnya adalah meng-clone openssh-portable, menerapkan patch, lalu menjalankan autoreconf, configure, dan make
  • Upaya koneksi muncul di log sshd sebagai xzbot: magic 1 [preauth] beserta deretan byte payload

Patch kunci publik ED448

  • Backdoor memakai kunci publik ED448 hardcoded untuk verifikasi tanda tangan dan dekripsi payload
  • Jika kunci publik ini diganti dengan kunci milik pengguna, backdoor dapat dipicu
  • Repositori ini menyajikan kunci publik ED448 milik penyerang serta nilai kunci publik pengganti yang dibuat dengan seed=0
  • Langkah awalnya adalah menyiapkan shared object liblzma.so.5.6.1 yang berisi backdoor
    • Sebagai contoh sumber, disajikan snapshot Debian xz-utils 5.6.1-1
    • Setelah memasang pwntools, jalankan patch.py liblzma.so.5.6.1 untuk menghasilkan liblzma.so.5.6.1.patch
    • Setelah itu jalankan sshd menggunakan shared object liblzma.so.5.6.1.patch yang telah dimodifikasi
  • assets berisi contoh

Format payload backdoor

  • Backdoor dapat dipicu saat terhubung dengan sertifikat SSH dengan memasukkan payload ke dalam nilai N kunci tanda tangan CA
  • Payload ini harus dienkripsi dan ditandatangani dengan kunci ED448 penyerang
  • Struktur luarnya terdiri dari field berikut
    • a: 32-bit
    • b: 32-bit
    • c: 64-bit
    • ciphertext: 240 byte
  • Tipe permintaan diturunkan dari a * b + c
    • Jika nilainya lebih besar dari 3, backdoor melewati pemrosesan
    • Type 1: kegunaannya tidak diketahui dan mengharapkan 0 byte
    • Type 2: menjalankan payload null-terminated dengan system()
    • Type 3: kegunaannya tidak diketahui dan mengharapkan data tanda tangan 48 byte
  • ciphertext dienkripsi dengan chacha20 menggunakan 32 byte pertama kunci publik ED448 sebagai kunci simetris
    • Karena itu, percobaan exploit dapat didekripsi dengan kunci 32 byte yang disajikan
  • Di dalam ciphertext yang telah didekripsi terdapat tanda tangan 114 byte, field 1-bit x dan y, panjang, string perintah, dan lainnya
    • Jika x atau y diatur, alurnya menuju jalur kode yang sedikit berbeda
  • Tanda tangannya adalah tanda tangan ED448 RFC-8032
    • Input mencakup nilai magic 32-bit, field 5 byte sebelum perintah, secara opsional length byte dari perintah, serta 32 byte pertama hash SHA-256 hostkey server

CLI demo exploit

  • CLI dipasang dengan Go
    • go install github.com/amlweems/xzbot@latest
  • xzbot -h menampilkan tiga opsi utama
    • -addr: alamat server SSH, default 127.0.0.1:2222
    • -seed: seed ED448 yang harus cocok dengan kunci backdoor xz, default 0
    • -cmd: perintah yang akan dijalankan dengan system(), default id > /tmp/.xz
  • Contohnya terhubung ke server SSH rentan di 127.0.0.1:2222 dan menjalankan perintah id > /tmp/.xz
  • Jika watchpoint dipasang pada lokasi pemanggilan system() di server rentan, terlihat proses sshd menjalankan id > /tmp/.xz
  • Setelah eksekusi, disajikan contoh bahwa /tmp/.xz berisi output uid=0(root) gid=0(root) groups=0(root)

Pohon proses dan karakteristik log

  • Pohon proses untuk koneksi SSH normal berlanjut ke sesi pengguna dan shell dari sshd
  • Contoh eksekusi backdoor berbentuk munculnya sshd: root [priv], sshd: root [net], sh -c sleep 60, dan sleep 60 setelah xzbot -cmd 'sleep 60'
  • Eksploitasi yang berhasil tidak menghasilkan entri log INFO atau yang lebih tinggi

Referensi

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-02
Opini Hacker News

  • Cukup menarik bahwa ini bukan eksekusi kode jarak jauh yang bisa disalahgunakan siapa saja, melainkan dibuat agar membutuhkan kunci privat penyerang
    Ironisnya, ini tampak seperti kerentanan yang sangat sadar keamanan

    • Niat awalnya kemungkinan untuk mempertahankan masa hidup backdoor selama mungkin
      Kalau mereka membuat lubang besar yang bisa dimasuki siapa saja, itu akan cepat ditemukan dan ditutup; dan jika tidak ada penurunan performa, mungkin saja backdoor ini bertahan lama secara diam-diam karena tidak bisa dieksploitasi secara luas
    • Jika dilihat sebagai serangan yang disponsori negara, cukup masuk akal untuk menanam kerentanan yang aman pada sistem yang juga bisa dipakai warga negaranya sendiri
      Seluruh kontribusi terhadap xz pada akhirnya tampak seperti pekerjaan untuk memasukkan backdoor ini; misalnya, mereka bahkan membuat framework pengujian yang bisa menyembunyikan payload berbahaya
      Sebelum mengerjakan xz, mereka juga berkontribusi ke libarchive milik BSD, dan di sana muncul kerentanan
    • Ini benar-benar terlihat seperti eksploit yang disponsori negara
      Desain dan eksekusinya sangat canggih, dan rasanya hampir murni keberuntungan bahwa masalah performa menjadi pemicu penemuannya
    • Ini disebut NOBUS: https://en.wikipedia.org/wiki/NOBUS
    • Saya membacanya seolah tanda tangan payload menyertakan kunci host SSH target; apakah itu benar?
      Jika demikian, payload tidak bisa disebar sembarangan ke banyak server, dan mengirimkannya ke satu host saja merupakan struktur yang cukup mahal secara komputasi

  • Kejadian ini tidak lepas dari pikiran saya sepanjang akhir pekan
    Mekanismenya menarik dan merupakan kumpulan obfuscation yang hebat, sementara bagian rekayasa sosialnya adalah cerita yang sangat familier—sampai memalukan—bagi maintainer open source
    Hal yang paling menarik adalah pemilihan data uji yang buruk sebagai vektor serangan: jika menyiapkan arsip yang baik, memanipulasinya secara struktural, lalu memakainya sebagai data buruk untuk fuzz testing, tahap-tahap berikutnya menjadi sangat mudah
    Untuk nanti, manipulasi seperti ini seharusnya terlihat pada grafik pola biner
    Teknik selebihnya, setelah payload ditentukan, umumnya lebih mirip obfuscation biasa; tetapi langkah paling brilian adalah bahwa dengan pola yang sama mereka bisa menambahkan “patch” atau bahkan backdoor baru ke file uji lain tanpa ketahuan
    GitHub menyembunyikan dan menghapus repositori sama sekali tidak membantu, malah menghambat analisis insiden ini

    • Saya jadi mencurigai dependensi saat build dari alat open source yang kami gunakan
      Saya menemukan bahwa dependensi itu secara khusus lebih menyukai xz, dan jika belum terpasang, ia bahkan memasang xz di mesin host seolah-olah itu fitur kemudahan
      Dependensi lain tidak berperilaku seperti itu, jadi agak aneh
      Strategi jangka panjang seperti ini menakutkan, dan sampai “kejahatan” benar-benar dieksekusi, kita tidak bisa tahu mana yang berbahaya dan mana yang sekadar aneh
    • Salah satu akar masalahnya tampaknya adalah penambahan file biner ke repositori untuk digunakan sebagai input pengujian
      Apalagi jika itu file “sampah biner” untuk membuktikan kegagalan pengujian, tempat itu sangat cocok untuk menyembunyikan konten berbahaya
    • Dengan menghapus repositori, pada akhirnya hanya penyerang yang memiliki akses ke kode dan know-how

  • Sangat mengesankan bahwa komunitas, terutama amlweems, bisa mengimplementasikan dan mendokumentasikan kode proof-of-concept secepat ini
    Jika tidak ada kerentanan tambahan pada fungsi kriptografi atau pemuatan payload, mungkin saja ini bahkan tidak membuka celah keamanan bagi semua penyerang lain sampai kuncinya berhasil dipecahkan
    Langkah berikutnya adalah menemukan cara mendeteksi distribusi yang rentan, tetapi itu tampaknya tidak mudah; mungkin juga upstream bisa memasukkan cara untuk memantau apakah ada yang secara aktif memindai server SSH dengan kunci hardcoded

    • Itu bukan eksploit asli, melainkan proof-of-concept untuk versi dengan kunci yang diganti
      Proof-of-concept untuk versi asli membutuhkan kunci privat penyerang yang tidak dipublikasikan
    • Mendeteksi deployment yang rentan melalui jaringan tanpa kunci privat penyerang tampaknya bukan sekadar sulit, melainkan mustahil
      Hal terbaik yang bisa dilakukan hanyalah benchmarking yang lebih halus, tetapi kita tidak bisa tahu apakah host internet sembarang lambat karena rentan, karena lokasinya jauh, atau karena komputernya sendiri lambat
      Kita juga tidak punya akses ke berapa lama percobaan koneksi ke host itu di masa lalu, dan ada pula perubahan routing

  • Saya penasaran apakah ada yang sudah menjalankan proof-of-concept ini pada alat pendeteksi perilaku proses yang tidak normal
    Produk seperti Carbon Black, AWS GuardDuty, dan Sysdig termasuk di sini; kasus ini tampak sangat cocok untuk kategori produk tersebut guna menguji apakah, saat benar-benar dideploy, ada kemungkinan seseorang menyadarinya relatif cepat

    • Menurut saya itu bergantung pada seberapa mirip eksploit ini meniru perilaku kompresi normal atau bersembunyi di dalamnya
      GuardDuty tidak mengintip ke dalam proses seperti EDR semacam CrowdStrike atau Carbon Black, jadi sepertinya sulit tertangkap; Sysdig memantau container dan infrastruktur cloud, jadi sulit juga menangkap eksploit itu sendiri
      Namun setelah eskalasi privilese, ada kemungkinan menangkap anomali dari tindakan lanjutan pelaku ancaman
      Pada akhirnya, yang paling mungkin menangkap eksploit itu sendiri adalah EDR yang memantau proses endpoint, atau evaluasi rantai pasok perangkat lunak yang memantau masalah keamanan pada perangkat lunak bebas dan open source upstream
      Menariknya, ini mengarah ke topik keamanan yang lebih besar
      Tim pengembang bisa tidak suka memasang EDR di server karena penurunan performa dan masalah pengalaman pengguna saat tindakan isolasi dilakukan, dan mereka juga bisa tidak suka kebijakan yang membatasi penggunaan perangkat lunak bebas dan open source
      Eksploit ini menusuk tepat di tengah “kerentanan” tingkat organisasi, dan tergantung posisinya, bisa muncul argumen untuk tetap mempertahankan paparan maupun untuk memperbaikinya
    • Sysdig menerbitkan blog pada hari Jumat
      Mereka mengatakan, “Salah satu metode deteksi runtime adalah memantau apakah SSHD memuat library berbahaya. Shared library semacam ini sering menyertakan versi dalam nama file”
      Blog itu juga memuat aturan deteksi nyata yang belum saya lihat dari vendor keamanan lain
      https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-bac...
    • Menurut saya seluruh kategori produk itu kebanyakan lebih dekat ke produk keamanan omong kosong

  • Saya salah membaca tautan di bawah, dan isi aslinya saya tinggalkan untuk catatan
    Kalau melihat bagian bawah thread email yang sama, disebutkan bahwa orang yang meng-commit backdoor itu belakangan juga tampak melakukan kontribusi kernel, tetapi analisis aslinya sendiri benar-benar bagus, jadi tulisan seperti ini layak dibaca
    https://www.openwall.com/lists/oss-security/2024/03/29/10

    • Seri patch itu diunggah oleh Lasse, bukan Jia Tan
      Lasse sendiri juga mengatakan bahwa itu sama sekali tidak mendesak dan tidak akan masuk ke merge window kali ini, dan orang yang waras tidak menuduh Lasse sebagai pelaku jahat
    • Sampai ada bukti sebaliknya, Lasse Collin bukan Jia Tan
    • Seri patch yang dirujuk itu juga belum masuk ke kernel
    • Mungkin kebetulan, tetapi JiaT75 cukup mirip dengan kode transponder 7500 yang dalam dunia penerbangan berarti pembajakan

  • Insiden ini punya kemiripan yang luar biasa banyak dengan insiden Audacity beberapa tahun lalu
    Cookie guy mengklaim dirinya ditikam dan polisi federal terlibat dalam kasus itu, yang menyiratkan kemungkinan insiden tersebut terkait dengan aktor yang jauh lebih besar daripada 4chan
    Saat itu banyak orang mengira hanya Muse Group yang terlibat, tetapi mungkin saja itu aktor negara Rusia
    Sebelumnya ia mengklaim Audacity memiliki banyak telemetri dan backdoor, lalu menghapusnya pada commit pertama setelah melakukan fork
    Mungkin saja Audacity memang benar-benar memiliki backdoor, jadi sepertinya perlu memeriksa kode sumbernya

    • Harus berhati-hati, APT28 cukup berbahaya
      Belakangan mereka sedang menggabungkan operasi dengan APT29, dan kalau saya, saya tidak akan membangunkan cozy bear
    • Siapa Cookie guy?

  • Saya penasaran bagaimana eksploit sebenarnya melakukan ini saat runtime, tanpa openssh.patch honeypot pada waktu kompilasi https://github.com/amlweems/xzbot/blob/main/openssh.patch
    Rantainya adalah opensshd -> notifikasi systemd -> xz yang disertakan sebagai dependensi sementara, dan saya ingin tahu bagaimana setelah liblzma.so.5.6.1 dimuat ke memori, ia bisa menelusuri balik sampai openssh_RSA_verify untuk memasang hook atau patch

    • Saat memuat liblzma, alamat kode berbahaya di-patch ke GOT ELF
      Jika dimuat sebelum libcrypto, ia mendaftarkan handler audit simbol; ini tampaknya fitur khusus glibc, dan dapat menerima notifikasi saat simbol libcrypto di-resolve sehingga patch GOT bisa ditunda
    • Itu ifunc

  • Saya penasaran apakah ada yang tahu eksploit ini hanya berjalan ketika ada koneksi SSH masuk
    Daftar string di GitHub memuat DISPLAY dan WAYLAND_DISPLAY
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
    Keduanya tidak punya kaitan jelas dengan SSH, jadi mungkin ada sesuatu yang dilakukan bahkan ketika tidak ada koneksi
    Ini bisa penting bagi orang yang menjalankan kode tersebut tetapi menganggap dirinya aman karena tidak mengekspos server SSH ke internet

    • Kemungkinan besar itu kill switch agar eksploit tidak berjalan jika terminal sedang terbuka atau sedang berjalan dalam sesi GUI
      Dengan kata lain, mekanisme untuk menghindari situasi ketika seseorang mencoba mendeteksi, mereproduksi, atau men-debug-nya
    • Bisa juga terkait dengan forwarding sesi X11
      Jika tidak dimatikan saat terhubung ke mesin yang tidak tepercaya, itu menjadi celah keamanan umum di sisi orang yang terhubung

  • Saya penasaran apakah pernyataan “eksploitasi yang berhasil tidak membuat entri log” berarti, jika eksploit ini tidak ketahuan, penyerang bisa menjalankan perintah arbitrer sebagai root di host yang sudah dikompromikan tanpa satu pun log sshd untuk “koneksi” tersebut

    • Benar
      Eksekusi kode jarak jauh terjadi pada tahap koneksi, sebelum log dicatat
    • Meski begitu, trafik SSH tanpa login yang sesuai tetap akan tersisa
      Saya penasaran deteksi anomali seperti apa yang bisa menangkap ini

  • Saya penasaran apakah serangan ini bisa dibuat lebih sulit jika file pengujian dipisahkan ke repositori terpisah sehingga tidak dapat digunakan pada waktu build
    Logikanya, apa pun yang terlibat dalam build harus dapat dibaca manusia

    • “Apa pun yang terlibat dalam build harus dapat dibaca manusia” secara umum adalah prinsip yang bagus untuk diadopsi
      Serangan ini harus diperlakukan seperti kecelakaan pesawat, dan aturan baru perlu diperkenalkan untuk mengurangi kemungkinan keberhasilannya lagi
      Meski kita tidak bisa memverifikasi setiap kontributor satu per satu, data pengujian yang berisik seharusnya mudah dipisahkan