- Andres Freund dari Microsoft menemukan backdoor yang ditanam di xz Utils, yang digunakan di hampir semua lingkungan Linux/Unix, saat menelusuri anomali performa SSH pada sistem Debian
- Kode berbahaya dimasukkan ke xz Utils 5.6.0 dan 5.6.1, dan dirancang agar penyerang yang memiliki kunci privat tertentu dapat menyembunyikan kode di sertifikat login SSH lalu menjalankannya pada perangkat yang memiliki backdoor
- Penyerang mencoba menggunakan release tarball, file pengujian, skrip build, dan IFUNC glibc—bukan source GitHub—untuk melakukan hooking rutinitas autentikasi sshd melalui liblzma
- Backdoor memeriksa kondisi build paket amd64/x86_64, glibc, serta turunan Debian atau Red Hat, dan sempat masuk ke Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed/MicroOS, serta rilis Kali Linux pada sebagian periode
- Persona pengembang bernama Jia Tan terlibat dalam pemeliharaan xz Utils selama bertahun-tahun; insiden ini dilacak sebagai CVE-2024-3094, dan muncul alat deteksi serta analisis seperti halaman pemeriksaan Binarly dan xzbot
Penemuan dan cakupan dampak
- Andres Freund adalah developer dan engineer di Microsoft yang mengerjakan hal terkait PostgreSQL; ia menemukan gejala mencurigakan saat menyelidiki login SSH pada sistem Debian yang memakai CPU secara berlebihan dan memunculkan error valgrind
- Penyebabnya adalah pembaruan xz Utils, dan Freund mengungkapkan di Open Source Security List bahwa pembaruan ini adalah backdoor yang sengaja ditanam dalam perangkat lunak kompresi
- xz Utils menyediakan kompresi dan dekompresi data lossless di hampir semua sistem operasi mirip Unix, termasuk Linux, dan juga mendukung format .lzma lama
- Filippo Valsorda menilainya sebagai “mungkin salah satu contoh serangan supply chain yang dijalankan paling baik di antara yang pernah dijelaskan secara publik, skenario mimpi buruk berupa upstream yang berbahaya, kompeten, dan berwenang pada library yang digunakan luas”
Perilaku yang ditargetkan backdoor
- Kode berbahaya ditambahkan ke xz Utils 5.6.0 dan 5.6.1, sehingga mengubah cara kerja perangkat lunak
- Backdoor memanipulasi sshd, executable yang digunakan untuk koneksi SSH jarak jauh
- Orang yang memiliki kunci kriptografi yang telah ditentukan sebelumnya dapat menyembunyikan kode yang diinginkan di sertifikat login SSH, mengunggahnya, lalu menjalankannya pada perangkat yang memiliki backdoor
- Kode yang benar-benar diunggah belum teridentifikasi, sehingga belum diketahui kode apa yang hendak dijalankan penyerang
- Secara teori, hampir semua tindakan bisa dilakukan, termasuk mencuri kunci kriptografi atau memasang malware
Jalur library kompresi hingga menyentuh SSH
- Sebuah library dapat memanipulasi perilaku internal executable yang tertaut dengannya
- Implementasi sshd utama dari OpenSSH secara default tidak tertaut dengan liblzma
- Debian dan beberapa distribusi Linux menambahkan patch yang menghubungkan sshd dengan systemd
- systemd adalah program yang memuat berbagai layanan saat proses boot
- systemd tertaut dengan liblzma
- Karena jalur koneksi inilah xz Utils dapat memengaruhi sshd
Indikasi persiapan selama bertahun-tahun
- Pada 2021, pengguna bernama JiaT75 membuat commit pertama yang diketahui di proyek open source
- Perubahan itu mengganti fungsi safe_fprint di proyek libarchive dengan varian yang sudah lama dikenal kurang aman, dan saat itu tidak ada yang menyadarinya
- Pada 2022, JiaT75 mengirim patch ke mailing list xz Utils
- Tak lama kemudian, kontributor baru bernama Jigar Kumar menekan Lasse Collin karena dianggap tidak memperbarui xz Utils cukup sering atau cukup cepat
- Dennis Ens dan beberapa kontributor baru lainnya juga menekan Collin agar menambahkan maintainer tambahan
- Pada Januari 2023, JiaT75 membuat commit pertama di xz Utils dan, dengan nama Jia Tan, semakin terlibat dalam pekerjaan xz Utils
- Mengganti kontak Collin di oss-fuzz dengan kontaknya sendiri
- Meminta perubahan untuk menonaktifkan fitur IFUNC selama pengujian oss-fuzz, sehingga perubahan berbahaya yang kemudian masuk ke xz Utils tidak terdeteksi
- Pada Februari 2024, Tan membuat commit xz Utils 5.6.0 dan 5.6.1, dan pembaruan ini mengimplementasikan backdoor
- Setelah itu, Tan atau orang lain meminta developer Ubuntu, Red Hat, dan Debian untuk menggabungkan pembaruan tersebut ke sistem operasi mereka
Distribusi yang terdampak dan kondisi eksekusi
- Menurut Tenable, versi backdoor atau pembaruan terkait masuk ke rilis berikut
- Fedora Rawhide: distribusi pengembangan Fedora Linux
- Fedora 41
- Debian testing, unstable, experimental: dari 5.5.1alpha-0.1 hingga 5.6.1-1
- openSUSE Tumbleweed dan openSUSE MicroOS: menyertakan versi xz yang memiliki backdoor antara 7 Maret hingga 28 Maret
- Kali Linux: menyertakan xz-utils 5.6.0-0.2 antara 26 Maret hingga 28 Maret
- Menurut analisis Sam James, skrip berbahaya memeriksa apakah target build adalah amd64/x86_64, menggunakan nama linux-gnu, serta memakai GCC dan GNU ld
- Skrip juga memeriksa apakah itu build paket Debian atau apakah RPM_ARCH bernilai x86_64
- Serangan tampaknya menargetkan lingkungan yang menggunakan glibc pada sistem amd64 dan membangun distribusi turunan Debian atau Red Hat
- Saat itu belum diketahui apakah sistem lain rentan
Cara implementasi dan teknik penyamaran
- Sam James merangkum bahwa backdoor terdiri dari beberapa komponen
- Release tarball yang didistribusikan upstream tidak sama dengan kode di GitHub
- build-to-host.m4 dalam release tarball sangat berbeda dari milik upstream GitHub
- Di folder tests/ pada repositori git terdapat file pengujian yang dimanipulasi
tests/files/bad-3-corrupt_lzma2.xztests/files/good-large_compressed.lzma
- Skrip yang dipanggil oleh build-to-host.m4 mengekstrak data pengujian berbahaya dan memodifikasi proses build
- IFUNC milik glibc digunakan untuk melakukan hooking atau redirect rutinitas autentikasi OpenSSH saat runtime
- HD Moore mengonfirmasi bahwa tahap akhir backdoor hanya berjalan saat membangun library di amd64 dan membuat paket Debian atau RPM
- Menurut analisis para peneliti, jika fungsi fingerprint tertentu dan kunci publik cocok dalam proses verifikasi kunci publik SSH, isi kunci didekripsi menggunakan pre-shared key sebelum kunci publik benar-benar diverifikasi
- Isi yang didekripsi diteruskan langsung ke
systemjika sesuai dengan format tertentu - Jika fingerprint tidak cocok atau isi yang didekripsi tidak sesuai format, proses kembali ke verifikasi kunci biasa, sehingga pengguna sulit menyadari perbedaannya
Rantai eksekusi menurut Akamai
- Para peneliti Akamai menilai backdoor sengaja hanya dimasukkan ke rilis tarball source code, bukan repositori GitHub xz, untuk menghindari deteksi
- Backdoor dibangun melalui beberapa commit
- Dalam proses build, IFUNC digunakan agar malware dapat mencegat fungsi resolusi simbol
- Objek bersama yang diobfuskasi disembunyikan di dalam file pengujian
- Skrip untuk mengekstrak objek bersama dijalankan saat proses build library
- Landlocking, fitur keamanan yang membatasi hak akses proses, dinonaktifkan
- Rantai eksekusi berlanjut melalui beberapa tahap
build-to-host.m4dijalankan saat build library dan mendekodebad-3-corrupt_lzma2.xzmenjadi skrip bash- Skrip bash ini mendekode
good-large_compressed.lzmadengan cara yang lebih rumit untuk membuat skrip lain - Skrip tersebut mengekstrak objek bersama
liblzma_la-crc64-fast.odan menambahkannya ke proses kompilasi liblzma
- Objek bersama ini dikompilasi ke dalam liblzma dan menggantikan proses resolusi nama fungsi normal
- Library berbahaya dapat mengganti pointer fungsi
RSA_public_decryptmilik OpenSSH dengan fungsi berbahaya buatannya sendiri - Menurut analisis Filippo Valsorda, fungsi berbahaya ini mengekstrak perintah dari sertifikat milik klien autentikasi, memastikan bahwa klien tersebut adalah pelaku ancaman, lalu meneruskannya ke
system()untuk mencapai eksekusi kode jarak jauh sebelum autentikasi
Jia Tan dan pertanyaan yang tersisa
- Informasi yang diketahui tentang Jia Tan sangat sedikit
- Persona pengembang ini juga terlibat dalam puluhan perangkat lunak open source lain selama beberapa tahun terakhir
- Belum diketahui apakah ada orang nyata di balik nama pengguna Jia Tan, atau apakah itu persona yang sepenuhnya direkayasa
- Analisis teknis tambahan dapat dilihat di thread Bluesky Filippo Valsorda, analisis Kevin Beaumont, dan materi pengungkapan Freund pada hari Jumat
CVE dan alat pemeriksaan
- Identifier pelacakan untuk kerentanan ini adalah CVE-2024-3094
- Halaman xz.fail dari Binarly mendeteksi implementasi IFUNC dan berbasis pada analisis perilaku
- Kondisi invarian juga dapat dideteksi secara otomatis jika backdoor serupa ditanam di tempat lain
- xzbot menyediakan fitur untuk analisis dan eksperimen
- honeypot: server rentan palsu untuk mendeteksi upaya eksploitasi
- ed448 patch: patch
liblzma.soagar menggunakan kunci publik ED448 milik sendiri - backdoor format: format payload backdoor
- backdoor demo: CLI yang memicu RCE dengan asumsi mengetahui kunci privat ED448
1 komentar
Komentar Hacker News
Tujuannya adalah mempermudah penulisan pengujian XZ dengan memakai framework pengujian yang terstandar
Jia menulis pada 2022-06-17 bahwa masih banyak fitur yang belum diuji, dan ini akan membantu memperbanyak pengujian demi stabilitas proyek jangka panjang
Dengan kata lain, perubahan ini memang sudah disiapkan sejak lama
Sepertinya belum banyak dibahas mekanisme linking yang memungkinkan lib menyisip ke
RSA_public_decryptBanyak pembicaraan tentang pemisahan proses dan semacamnya, tetapi sedikit yang membahas redirect pada pemanggilan fungsi itu
Mungkin komponen inti seperti kode yang masuk lewat SSH bisa di-link dengan pustaka menggunakan cara kepercayaan berlapis, sehingga terbentuk model seperti “saya memercayainya di lokasi tempat saya memanggilnya, tetapi tidak mengizinkannya menyisipkan diri ke titik pemanggilan lain”
Ini mungkin memicu reaksi refleks “security through obscurity” karena ada cara untuk melewatinya, tetapi tetap bisa dilihat sebagai pengurangan permukaan serangan
Namun dalam sistem operasi ada banyak konteks keamanan yang saling bertumpuk. Terkait backdoor XZ, ini terutama soal keamanan berbasis capability di tingkat modul, tetapi ada juga capability di tingkat program, isolasi tingkat memori (paging), isolasi tingkat mikroarsitektur, dan lain-lain
Membuat semua unsur ini bekerja bersama sekaligus tetap berkinerja baik cukup sulit, dan perpindahan keluarga Unix ke model seperti ini tampaknya nyaris mustahil karena harus mengganti konsep proses itu sendiri
Ini merusak pengujian XZ, lalu tiba-tiba muncul akun-akun yang melobi agar pengujian itu dinonaktifkan, dan akibatnya exploit menjadi mungkin
./configure && makedijalankan), kode ini diam-diam memodifikasi berkas C untuk menambal ifunc resolver dan membuatnya memanggil objek berbahaya yang disediakanBerkas objek yang telah dikompromikan di-link bersama flag linker
now, sehingga ifunc langsung di-resolve saat pustaka dimuat; pada saat itu tabel link proses masih dapat ditulisi, sehingga resolver yang telah ditambal dipanggilBagian inilah yang penting: saat pustaka dimuat, fungsi
RSA_public_decryptdi memori bisa langsung dibajakTulisan yang menganalisis proses injeksi backdoor ini dengan sangat baik: https://research.swtch.com/xz-script
dlopen: https://github.com/systemd/systemd/pull/31550Dalam arti itu, ini adalah cara linking yang lebih aman
ltracememantau simbol yang dipanggil sudah cukupSaya tidak mengerti mengapa disebut “hampir” menginfeksi seluruh dunia
Setidaknya tiga distro Linux yang cukup populer, Arch, Gentoo, openSUSE Tumbleweed, mendistribusikan backdoor ini selama beberapa minggu, dan di Tumbleweed backdoor itu jelas berfungsi
Karena SSH yang mengandung backdoor itu ada selama beberapa minggu, kata “hampir” terasa terlalu lemah
Karena hanya bekerja pada target deb/rpm, secara praktis ini dicegat sebelum mencapai produksi
Bukan berarti itu baik-baik saja; seandainya ini tidak ditemukan cukup lama hingga masuk ke RHEL atau Debian/Ubuntu stable, tempat-tempat seperti bank atau lembaga kesehatan akan menerima peringatan
Dengan eksekusi kode jarak jauh sebelum autentikasi, akan sulit mengatakan “tidak terdampak” kecuali di tempat yang sangat membatasi jaringan dan memiliki pencatatan alur yang baik
Jika membandingkan
liblzma.so.5.6.1darixz-5.6.1-1danxz-5.6.1-2dengancmp -l, hanya ada perbedaan yang sangat kecilTampaknya hal ini belum diketahui sebelum advisory ditulis
https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...
Namun saya tidak tahu bagaimana cara mendapatkan data untuk mendukung hal ini
Saya berani bertaruh 101 dolar bahwa dalam 12 bulan ke depan sesuatu yang mirip akan ditemukan di lingkungan nyata
Karena para maintainer akan mulai saling mencurigai dan menelusuri commit lama satu sama lain
Lihat saja codebase yang penting tetapi tidak terlalu dikenal dan maintainer-nya sangat sedikit
Kalau saya punya hal seperti ini dan itu bekerja dengan baik, mungkin nanti saya akan “menemukannya” lewat akun lain dan membuatnya diperbaiki
Ada beberapa kesimpulan pribadi yang saya ambil dari kejadian ini
Pertama, tarball distribusi sumber yang berisi kode berbeda dari repositori sumber itu buruk, dan kita harus menjauh darinya. Serangan supply chain besar lainnya, event-stream, juga memanfaatkan hal serupa
Akibatnya, artefak yang dibuat otomatis harus selalu di-commit
Kedua, artefak yang dibuat otomatis, yang dalam code review biasanya dilewati semua orang dengan Page Down, adalah masalah. Jika file seperti ini ada di repositori, harus ada juga pengujian otomatis untuk memastikan tidak ada yang memanipulasinya, sekaligus mencegah file hasil generasi otomatis yang usang dibiarkan begitu saja
Ketiga, sebagai konsekuensi dari poin 1 dan 2, autotools itu buruk, dan budaya autotools juga buruk
Keempat, Libsystemd adalah masalah bagi ekosistem. Mengatakan ini akan membuat orang mencap saya pembenci systemd, tetapi ia besar, kompleks, punya banyak dependensi, dan sebagian besar program hanya memakai sebagian sangat kecil darinya. Mendorong semua service bergantung padanya hanya untuk notifikasi inisialisasi itu gila
Kelima, ada budaya yang menganggap penggunaan ulang kode selalu baik dan bergantung pada library besar demi fitur kecil pun tidak apa-apa, padahal itu tidak benar. Dependensi adalah beban pemeliharaan sekaligus risiko keamanan, dan harus ditimbang terhadap fungsi yang dibawanya
Keenam, maintainer distribusi yang menerapkan patch besar pada paket juga merupakan masalah. Itu menciptakan fork de facto yang banyak dipakai dari library dan aplikasi yang tidak diperiksa oleh maintainer sebenarnya
Ketujuh, dari sudut pandang developer, OSS harus menjadi berkelanjutan secara finansial. Liblzma dan xz-utils mungkin terpasang puluhan juta kali, tetapi bersandar pada satu maintainer yang mengalami masalah kesehatan mental
Kedelapan, saya tidak suka mengatakannya, tetapi sekarang pertimbangan geopolitik juga harus masuk dalam code review dan pengalihan hak pemeliharaan
Tidak ada bukti bahwa Jia Tan adalah nama asli, bahkan tidak ada bukti bahwa ia adalah orang sungguhan
Jika proyek-proyek mulai menolak kontribusi dari nama yang terdengar seperti orang Asia, serangan berikutnya cukup memakai nama Richard Jones
Jika berasal dari dunia BSD, systemd terasa mengejutkan, seperti monster, dan menjulurkan tentakelnya ke mana-mana
Konsumen memang naif, tetapi industri perangkat lunak sendiri juga naif terhadap ancaman keamanan
Eksploit sosial adalah bagian dari eksploit kode
Prinsip FOSS bahwa “semakin banyak mata yang melihat kode, semakin baik” itu benar, tetapi hanya bekerja jika mata-mata itu terlatih. FOSS membutuhkan dukungan material dari industri
Seorang engineer MSFT menemukan eksploit ini, tetapi tetap saja ia masuk ke rilis publik umum Fedora 41, openSUSE, dan Kali
Toolchain pengembangan dan proses pengujian tidak pernah dirancang untuk menguji keamanan. SolarWinds juga layak dijadikan rujukan: https://www.wired.com/story/the-untold-story-of-solarwinds-t...
Artefak rilis tidak hanya berisi skrip autoconf
Ada banyak alasan untuk memasukkan blob biner ke arsip rilis. Misalnya resource game, image firmware, test case, dan lain-lain. Pernah ada pembahasan bahwa mpv menyertakan beberapa file media yang dibuat dengan encoder proprietari sebagai test case, dan itu bukan hal buruk, melainkan hal baik
sqlite yang terpelihara baik dipakai di mana-mana dan juga punya test suite yang sangat bagus. Untuk setiap rilis, mereka mendistribusikan bukan satu tarball, melainkan dua, untuk tahap kompilasi yang berbeda. Menghentikan ini mungkin mudah, tetapi hanya akan menambah pekerjaan maintainer paket dan tidak membantu meningkatkan keamanan
Alasan Debian membangun dari tarball yang sudah dikurasi adalah karena tarball itu dikurasi manusia dan ditandatangani dengan key yang dikenal baik. Tentu saja bisa juga membangun dari git, tetapi belum jelas apakah itu akan memperbaiki keadaan. Tidak semua proyek menandatangani tag rilis, dan sekalipun menandatanganinya, kemungkinan besar prosesnya otomatis
Kita ingin perubahan ditinjau lebih dulu oleh maintainer upstream, lalu oleh maintainer paket, dan lebih disukai jika kedua pihak ini tidak saling terkait
Kali ini maintainer upstream yang korup menyerang proses itu, tetapi bukan berarti kita harus menyingkirkan maintainer upstream. Selama beberapa tahun terakhir, struktur ini telah mencegah beberapa percobaan backdoor, dan bukan proses yang layak dibuang tanpa peninjauan saksama
Arah perbaikan yang selama ini terus disampaikan tetap sama. Kejar lebih banyak build yang dapat direproduksi, kurangi attack surface dan kompleksitas build jika memungkinkan, serta percayai maintainer tetapi verifikasi pekerjaannya
Justru mereka kebingungan pada poin itu, dan sedang menambahkan dokumentasi tentang cara mengimplementasikan datagram sederhana tanpa libsystemd
Jumlah instalasi liblzma dan xz-utils kemungkinan jauh lebih besar daripada puluhan juta. Banyak bahasa seperti Python, PHP, Ruby, dan lainnya bergantung pada libxml2, dan libxml2 memakai liblzma. Ada banyak dependensi lain juga
Pertimbangan geopolitik bukan tugas maintainer. OSS disediakan tanpa jaminan
Selain itu, “Jia Tan” kemungkinan sepenuhnya palsu. Jika melihat timestamp commit, zona waktunya berubah dari Eropa Timur ke Asia bahkan pada hari yang sama. Setidaknya jelas bahwa ada permainan identitas yang sedang dilakukan
Saya tidak tahu bahwa orang yang menemukan masalah ini adalah engineer Microsoft yang bekerja di Azure Postgres
Terima kasih Microsoft, sekarang saya jadi lebih menyukai Azure
Karena masalah ini ditemukan dengan cara itu
Lalu lihat library yang bermasalah, dan cari outlier serupa di mana persona palsu mengambil alih proyek
Mengabaikan error seperti ini tampaknya praktik yang umum
Saya benar-benar tidak tahan dengan pengemasan narasi seperti ini
Tampaknya maintainer asli xz menyerahkan tanggung jawab kepada Jia Tan tanpa pernah bertemu langsung, atau setidaknya berbicara lewat telepon
Aku jadi penasaran apakah berkomunikasi hanya lewat email atau GitHub itu hal yang umum
Setelah kejadian ini, sebagian maintainer proyek open source sepertinya akan menjadi lebih berhati-hati
Aku juga pernah berkomunikasi hanya lewat teks tanpa tahu sama sekali siapa orang aslinya, lalu mengambil alih atau menyerahkan pemeliharaan library
Namun menurutku kesimpulan bahwa “maintainer harus lebih berhati-hati” dalam kasus ini sepenuhnya keliru
Tanggung jawab atas apa yang dimasukkan orang ke proyek mereka bukan berada pada maintainer, melainkan pada orang-orang yang bekerja di proyek tersebut
Entah kamu memercayai maintainer atau tidak, hanya ada dua pilihan itu; begitu mulai bergantung pada sebuah library, kamu secara implisit setuju untuk terus memperbarui siapa yang kamu percayai
Jutaan perusahaan menumpang gratis pada pekerjaan developer open source yang tidak dibayar
Jadi tidak mengejutkan jika mereka pergi dan masalah muncul
Apakah itu akan menambah kepercayaan apa pun terhadap niat orang tersebut?
Aku pernah berpartisipasi di sekitar enam proyek open source dengan skala beragam, dari 100 hingga 30 ribu star GitHub, tetapi tidak pernah menelepon siapa pun dan komunikasi berbasis teks adalah standarnya
Namun mengenal seseorang secara pribadi tidak selalu menyelesaikan masalah
Dulu sekali aku pernah bekerja secara anonim di sebuah proyek open source, dan aku tidak ingin menyebutkan namanya di sini. Programmer utamanya punya co-maintainer yang tampaknya ia kenal cukup baik
Co-maintainer itu terus melakukan gaslighting, merendahkan, dan menyalahkan aku serta maintainer-maintainer lain setelahnya atas bug yang sangat kecil sampai kami pergi. Kalau hinaannya disingkirkan, itu pun berbeda dari omelan ala Linus Torvalds yang bersifat mendidik
Lead maintainer justru menyemangatinya karena setuju dengan inti teknis dari klaimnya
Beberapa tahun kemudian co-maintainer itu mencoba mengambil alih proyek secara bermusuhan, dan hasilnya tidak berjalan seperti yang ia harapkan. Tak lama setelah itu, sejumlah korespondensi pribadi dipublikasikan, yang mengungkap bahwa ia memang selalu menginginkan hal itu dan gaslighting terhadap maintainer lain juga merupakan bagian dari tujuan tersebut
Semua ini terjadi meskipun keduanya saling mengenal
Semua orang mengira backdoor ini tertangkap lebih awal, tetapi bisa saja ia sudah mencapai tujuannya
Terutama jika targetnya adalah developer yang memakai distribusi rolling release seperti Kali atau Debian
Awal pekan aku sempat melihat sedikit traffic SSH, tetapi saat itu tidak terlalu memedulikannya
Tentu saja ini bisa saja salah sasaran: https://www.nubi-network.com/news.php?id=21
Meme semacam “Lasse Collin tidak memperbarui xz Utils cukup sering atau cukup cepat” adalah kekeliruan
Aku tidak tahu kenapa SSH memakai xz
Apakah memang harus begitu? Apakah itu benar-benar sepenting itu?
OpenSSH menarik libsystemd untuk menyediakan notifikasi startup, dan libsystemd menarik liblzma. Biasanya kode liblzma tidak masuk ke dalam OpenSSH
Namun karena dibangun sebagai dependensi libsystemd, skrip build berjalan di lingkungan yang sama dengan libsystemd dan OpenSSH
Payload serangan disembunyikan di direktori test liblzma sebagai blob biner yang diobfuscate, menyamar sebagai test case kompresi
Saat mengompilasi lzma dari source git dan membuat skrip build dengan autotools, tidak ada hal mencurigakan. Namun di source tarball yang dipakai para packager distro, autotools sudah dijalankan, dan penyerang menukar output skrip yang dihasilkan otomatis dan sulit dibaca itu
Skrip tersebut memeriksa apakah liblzma dikompilasi di lingkungan yang sama dengan OpenSSH, dan apakah dikompilasi untuk masuk ke paket
.debatau.rpm; jika keduanya benar, payload serangan ditanamkan ke OpenSSHSetelah itu payload melakukan berbagai pemeriksaan, seperti apakah OpenSSH dimulai secara normal lewat init script atau dijalankan manual, apakah ada tool debugging umum, dan hanya menempel ke proses yang sedang berjalan ketika tampak seperti boot “alami” tanpa tool debugging
Saat berjalan, ia memasang hook pada verifikasi private key, dan jika private key yang benar mencoba login, sisa paket yang masuk dipanggil melalui
systemuntuk menyediakan remote code execution dengan hak root