Insiden Backdoor XZ: Hasil Analisis Awal

• Backdoor XZ Utils/liblzma diungkap di mailing list Openwall OSS-security pada 29 Maret 2024, dan kemungkinan besar tujuan akhir penyerang adalah menanamkan kemampuan eksekusi kode jarak jauh pada server OpenSSH sshd di distribusi berbasis systemd
• Rantai infeksi terdiri dari injeksi bertahap yang memanfaatkan file pengujian dan infrastruktur build di repositori XZ; melalui build-to-host.m4, bad-3-corrupt_lzma2.xz, dan good-large_compressed.lzma, file objek berbahaya ditautkan ke liblzma selama proses build
• XZ 5.6.0 dan 5.6.1 yang mengandung backdoor didistribusikan dalam build beta dan eksperimental dari beberapa vendor besar, dan CVE-2024-3094 diberi tingkat keparahan 10
• Backdoor biner dimuat dengan menyalahgunakan IFUNC GLIBC dan jalur pemanggilan cpuid, lalu mencoba memantau koneksi pada mesin yang terinfeksi dengan melakukan hooking pada fungsi terkait OpenSSL/libcrypto
• Kode berbahaya memeriksa apakah /usr/bin/sshd sedang berjalan serta variabel lingkungan kill switch, dan membuat analisis serta deteksi menjadi sulit lewat pemrosesan string berbasis trie, resolusi simbol dinamis, dan patch runtime rtdl-audit

---

Ringkasan insiden dan cakupan dampak

• Pada 29 Maret 2024, penemuan backdoor XZ diumumkan melalui pesan di mailing list Openwall OSS-security
• XZ adalah utilitas kompresi yang terintegrasi ke banyak distribusi Linux utama
• Inti risikonya adalah liblzma yang mengandung backdoor dapat terhubung dengan proses server OpenSSH sshd pada sebagian distribusi berbasis systemd
  • Ubuntu, Debian, dan RedHat/Fedora Linux mem-patch OpenSSH agar menggunakan fitur systemd, sehingga bergantung pada library ini
  • Arch Linux dan Gentoo disimpulkan tidak terdampak
• Kemungkinan besar tujuan akhir penyerang adalah memasukkan kemampuan eksekusi kode jarak jauh pada sshd yang tidak dapat digunakan orang lain
• Berbeda dari serangan supply chain lain yang berpusat pada satu patch berbahaya, paket palsu, atau paket typosquatting, insiden ini lebih menyerupai operasi bertahap yang nyaris berhasil membobol server SSH di seluruh dunia

Cara backdoor dimasukkan

• Backdoor liblzma disisipkan pada dua tingkat dengan memanfaatkan proses build dan file pengujian sekaligus
  • Kode sumber infrastruktur build yang membuat paket akhir dimodifikasi dengan penambahan build-to-host.m4
  • Skrip dan komponen biner yang disembunyikan di dalam file test case diekstrak selama build
• Alur infeksi berpusat pada tiga file
  • build-to-host.m4: skrip build yang mengekstrak skrip tahap berikutnya
  • bad-3-corrupt_lzma2.xz: file pengujian yang menyembunyikan skrip shell
  • good-large_compressed.lzma: file pengujian yang menyembunyikan objek biner berbahaya
• Komponen biner berbahaya yang diekstrak dapat ditautkan dengan library normal selama proses kompilasi, lalu diteruskan ke repositori Linux
• Vendor besar mendistribusikan komponen berbahaya ini dengan memasukkannya ke build beta dan eksperimental
• Kompromi XZ Utils diberi nomor CVE-2024-3094, dengan tingkat keparahan maksimum 10

Linimasa utama

• 19 Januari 2024: maintainer utama baru jiaT75 memindahkan situs web XZ ke GitHub Pages
• 15 Februari 2024: build-to-host.m4 ditambahkan ke .gitignore
• 23 Februari 2024: dua “file pengujian” yang memuat tahap skrip berbahaya ditambahkan
• 24 Februari 2024: XZ 5.6.0 dirilis
• 26 Februari 2024: commit yang mengganggu fitur keamanan Landlock dimasukkan ke CMakeLists.txt
• 4 Maret 2024: backdoor menimbulkan masalah terkait Valgrind
• 9 Maret 2024: dua file pengujian diperbarui, fungsi CRC dimodifikasi, dan masalah Valgrind “diperbaiki”
• 9 Maret 2024: XZ 5.6.1 dirilis
• 28 Maret 2024: bug ditemukan dan dilaporkan ke Debian serta RedHat
• 28 Maret 2024: Debian me-rollback XZ 5.6.1 ke versi 5.4.5-0.2
• 29 Maret 2024: email publik diposting ke mailing list OSS-security
• 29 Maret 2024: RedHat mengonfirmasi XZ yang mengandung backdoor telah didistribusikan di Fedora Rawhide dan Fedora Linux 40 beta
• 30 Maret 2024: Debian menghentikan build dan memulai prosedur rebuild
• 2 April 2024: pengembang utama XZ mengakui insiden backdoor tersebut

3 tahap rantai infeksi

• Tahap 1: build-to-host.m4 yang dimodifikasi

  • Rilis repositori GitHub resmi XZ berisi file pengujian berbahaya, tetapi pada awalnya tidak berbahaya karena file-file tersebut tidak mendapat kesempatan untuk dijalankan
  • Kode berbahaya yang mem-bootstrap infeksi tampaknya disertakan dalam rilis yang disediakan dari xz[.]tukaani.org, yang dikendalikan oleh jiaT75
  • Sebagian besar distribusi menggunakan URL ini, dan rilis yang diunduh berisi file build-to-host.m4 yang memuat kode berbahaya
  • build-to-host.m4 dijalankan selama proses build; ia memperbaiki data “rusak” dari bad-3-corrupt_lzma2.xz dengan tr, lalu mendekompresinya dengan xz -d
  • Hasil dekompresi berisi skrip shell yang nantinya akan dijalankan dengan /bin/bash

• Tahap 2: skrip shell yang disisipkan

  • Skrip yang disisipkan oleh file .m4 berbahaya memeriksa apakah ia berjalan di mesin Linux dan di dalam proses build yang dituju
  • Untuk menjalankan tahap berikutnya, digunakan good-large_compressed.lzma
  • File ini dikompresi secara normal dengan XZ, tetapi data hasil dekompresinya berisi data sampah
  • Skrip menjalankan pipeline head dengan eval untuk mengekstrak data
  • Setiap perintah head mengabaikan 1024 byte berikutnya atau mengekstrak 2048 byte atau 724 byte berikutnya
  • Total 33.492 byte diekstrak
  • tail mempertahankan 31.265 byte terakhir file dan mengabaikan sisanya
  • Setelah itu, substitusi dasar diterapkan dengan tr untuk melepas obfuscation, lalu perintah XZ kedua mendekompresi byte yang telah diubah sebagai stream lzma mentah dan meneruskan hasilnya ke shell

• Tahap 3: ekstraksi objek backdoor

  • Skrip shell tahap terakhir memeriksa berbagai kondisi untuk memastikan ia berjalan di lingkungan yang diharapkan
  • Ia memeriksa apakah proyek dikonfigurasi untuk menggunakan IFUNC
  • Ia memeriksa apakah kompilasi dilakukan dengan GCC
  • Setelah itu, skrip memeriksa apakah file tertentu yang akan digunakan ada di proyek
  • Tahap ini mengekstrak file objek yang tersembunyi pada offset lain di good-large_compressed.lzma
  • Prosedur ekstraksi menjalankan beberapa perintah secara berurutan dan meneruskan output setiap perintah sebagai input perintah berikutnya
  • Mengekstrak good-large_compressed.lzma dengan tool XZ
  • Menggunakan eval $i dan beberapa pemanggilan head
  • Mendekripsi data biner dengan algoritme kustom mirip RC4
  • Mengekstrak lagi file terkompresi yang telah didekripsi dengan XZ
  • Menghapus sebagian byte di awal, lalu menyimpan hasilnya sebagai liblzma_la-crc64-fast.o
  • Terakhir, skrip memodifikasi fungsi is_arch_extension_supported dalam file crc_x86_clmul.h milik liblzma
  • Mengubah pemanggilan __get_cpuid menjadi _get_cpuid dengan menghapus satu garis bawah
  • Perubahan ini memungkinkan objek backdoor ditautkan ke library

Cara backdoor biner dimuat

• Kode XZ asli memiliki fungsi khusus lzma_crc32 dan lzma_crc64 untuk perhitungan CRC
• Kedua fungsi ini disimpan di tabel simbol ELF sebagai tipe IFUNC milik GLIBC
  • IFUNC memungkinkan dynamic linker memilih fungsi yang akan digunakan secara dinamis ketika shared library dimuat
  • XZ menggunakan fitur ini untuk memeriksa fitur prosesor modern seperti CLMUL, SSSE3, dan SSE4.1, lalu menentukan apakah fungsi CRC yang dioptimalkan akan digunakan
• Pemeriksaan fitur prosesor membutuhkan instruksi cpuid, dan wrapper __get_cpuid yang disediakan GLIBC dipanggil
• Saat skrip berbahaya mengubah __get_cpuid menjadi _get_cpuid, pemanggilan kode terhubung ke simbol _get_cpuid di dalam file objek backdoor
• Kode backdoor awal dipanggil dua kali karena lzma_crc32 dan lzma_crc64 menggunakan fungsi modifikasi _get_cpuid yang sama
  • Ia menggunakan counter sederhana untuk memeriksa apakah sudah pernah dijalankan
  • Jika IFUNC lzma_crc64 memanggil _get_cpuid dan nilai counter adalah 1, tahap pengalihan ke entry point akhir dimulai

Perilaku runtime dan target hooking

• Backdoor menginisialisasi struktur yang berisi informasi inti dari proses yang sedang berjalan
• Ia menemukan alamat Global Offset Table (GOT) menggunakan offset hard-coded, lalu menemukan pointer cpuid di dalamnya
• Setelah itu, pointer diganti dengan fungsi berbahaya utama, sehingga fungsi berbahaya dipanggil seolah-olah memanggil cpuid
• Target utamanya adalah melakukan hooking pada fungsi tertentu agar dapat memantau koneksi yang masuk ke mesin terinfeksi
• Fungsi target terkait dengan libcrypto
  • RSA_public_decrypt: digunakan saat mendekripsi ciphertext yang ditandatangani dengan private key
  • EVP_PKEY_set1_RSA: digunakan saat menetapkan kunci RSA untuk konteks tertentu
    • Tidak ada pada versi server SSH terbaru, tetapi digunakan di tool pembuatan kunci SSH mandiri
  • RSA_get0_key: digunakan saat mengambil kunci RSA
• Proses hooking memerlukan akses ke beberapa struktur internal dan manipulasi struktur per proses, dan kode berbahaya juga menjalankan pemeriksaan untuk menghindari analisis

Pemeriksaan lingkungan eksekusi dan teknik penghindaran analisis

• Pemeriksaan sshd dan kill switch

  • Backdoor pertama-tama mem-parse dynamic linker ld-linux yang menyelesaikan alamat simbol secara dinamis
  • Ia memeriksa apakah lingkungan eksekusi saat ini sesuai kriteria
  • Ia memeriksa apakah proses saat ini adalah /usr/bin/sshd
  • Ia memeriksa apakah kill switch ada
  • Nama proses saat ini diekstrak dari argv[0]
  • Semua variabel lingkungan proses di-parse dan diperiksa apakah cocok dengan nilai dalam tabel string internal
  • Jika ada variabel lingkungan yang cocok atau prosesnya bukan sshd, kode berbahaya berhenti berjalan
  • Satu-satunya variabel dalam tabel internal, yolAbejyiejuvnup=Evjtgvsh5okmkAvj, berfungsi sebagai kill switch dalam konteks ini

• Pemrosesan string berbasis trie

  • Salah satu ciri backdoor ini adalah penggunaan satu struktur trie untuk operasi string
  • Alih-alih membandingkan konstanta seperti nama fungsi secara langsung atau menggunakan hash string, ia memeriksa apakah hasil lookup trie sama dengan nilai konstanta tertentu
  • Nilai magic pada header ELF mengembalikan 0x300 dari trie
  • Nama fungsi system dicocokkan dengan nilai kembali 0x9F8
  • Trie tidak hanya digunakan untuk perbandingan, tetapi juga untuk mencari string di dalam biner host
  • Sebagai contoh, fungsi yang menggunakan pointer string seperti ssh-2.0 mencari string tersebut di biner host agar tidak meninggalkan data mencurigakan dalam body backdoor
  • Implementasinya menggunakan bitmask 16 byte
  • Setiap setengahnya sesuai dengan rentang byte input 0x00-0x3F dan 0x40-0x7F
  • Node daun trie berukuran 2 byte; 3 bit digunakan sebagai flag, sementara sisanya dicadangkan untuk nilai atau lokasi node berikutnya

Resolusi simbol dan hooking rtdl-audit

• Rutin resolusi simbol

  • Backdoor memiliki setidaknya 3 rutin resolusi simbol untuk menemukan struktur ELF Symbol
  • Semua fungsi resolusi simbol menerima key yang akan dicari di trie sebagai input
  • Salah satu fungsi resolusi menelusuri semua simbol untuk mencari simbol dengan key yang diinginkan, dan jika ditemukan, mengembalikan struktur Elf64_Sym
  • Struktur ini kemudian digunakan untuk mengisi struktur internal backdoor dan menyimpan function pointer yang diperlukan
  • Proses ini mirip dengan rutin API hashing yang umum terlihat pada ancaman Windows
  • Backdoor kemudian mencari banyak fungsi OpenSSL libcrypto yang akan digunakan dalam rutin kriptografi
  • Ia melacak jumlah fungsi yang ditemukan dan di-resolve, lalu menggunakan nilai ini untuk menentukan apakah eksekusi normal atau harus dihentikan

• Allocator palsu yang menyalahgunakan lzma_alloc

  • Resolver simbol lain menyalahgunakan fungsi lzma_alloc milik liblzma sendiri
  • lzma_alloc adalah fungsi yang membantu mengalokasikan memori secara efisien dengan menggunakan allocator default malloc atau allocator kustom
  • Dalam backdoor XZ, fungsi ini bertindak seperti resolver simbol lain melalui allocator palsu
  • Parameter yang semula digunakan sebagai “ukuran alokasi” sebenarnya digunakan sebagai key simbol di dalam trie
  • Trik ini bertujuan membuat analisis backdoor lebih sulit
  • Backdoor me-resolve simbol secara dinamis saat berjalan, dan tidak dibatasi pada pola me-resolve semua simbol sekaligus atau hanya saat diperlukan
  • Target resolusi mencakup fungsi OpenSSL normal hingga fungsi seperti system yang mengeksekusi perintah di mesin

• Patch runtime rtdl-audit

  • Backdoor menggunakan fitur rtdl-audit milik dynamic linker untuk hooking fungsi
  • Umumnya, rtdl-audit adalah fitur yang memungkinkan developer membuat shared library kustom untuk menerima notifikasi event linker seperti resolusi simbol
  • Alih-alih membuat shared library terpisah, backdoor XZ mem-patch saat runtime interface dasar yang sudah terdaftar di memori untuk mengambil alih rutin resolusi simbol
  • Struktur audit_iface berbahaya yang disimpan pada variabel global dl_audit di area memori dynamic linker berisi alamat callback symbind64
  • Ketika dynamic linker memanggil callback ini, semua informasi simbol berpindah ke kendali backdoor, dan hooking tercapai dengan mengembalikan alamat berbahaya untuk fungsi target
  • Alamat dl_audit dan dl_naudit diperoleh dengan membongkar instruksi fungsi dl_main dan dl_audit_symbind_alt
  • Backdoor menyertakan disassembler minimal internal untuk decoding instruksi, dan digunakan secara luas saat mencari nilai tertentu seperti alamat *audit

Distribusi yang dikonfirmasi mengandung backdoor dan informasi deteksi

• Distribusi sumber yang mengandung backdoor

  • xz-5.6.0
    • MD5: c518d573a716b2b2bc2413e6c9b5dbde
    • SHA1: e7bbec6f99b6b06c46420d4b6e5b6daa86948d3b
    • SHA256: 0f5c81f14171b74fcc9777d302304d964e63ffc2d7b634ef023a7249d9b5d875
  • xz-5.6.1
    • MD5: 5aeddab53ee2cbd694f901a080f84bf1
    • SHA1: 675fd58f48dba5eceaf8bfc259d0ea1aab7ad0a7
    • SHA256: 2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8

• Artefak utama yang dianalisis

  • bad-3-corrupt_lzma2.xz: 86fc2c94f8fa3938e3261d0b9eb4836be289f8ae
  • build-to-host.m4: b4dd2661a7c69e85f19216a6dbbb1664
  • good-large_compressed.lzma: 540c665dfcd4e5cfba5b72b4787fec4f
  • liblzma_la-crc64-fast.o: 212ffa0b24bb7d749532425a46764433

• Library yang diketahui mengandung backdoor

  • Debian Sid liblzma.so.5.6.0
    • MD5: 4f0cf1d2a2d44b75079b3ea5ed28fe54
    • SHA1: 72e8163734d586b6360b24167a3aff2a3c961efb
    • SHA256: 319feb5a9cddd81955d915b5632b4a5f8f9080281fb46e2f6d69d53f693c23ae
  • Debian Sid liblzma.so.5.6.1
    • MD5: 53d82bb511b71a5d4794cf2d8a2072c1
    • SHA1: 8a75968834fc11ba774d7bbdc566d272ff45476c
    • SHA256: 605861f833fc181c7cdcabd5577ddb8989bea332648a8f498b4eef89b8f85ad4

• Nama deteksi

  • Produk Kaspersky mendeteksi objek berbahaya terkait serangan sebagai HEUR:Trojan.Script.XZ dan Trojan.Shell.XZ
  • Kaspersky Endpoint Security for Linux mendeteksi kode berbahaya di memori proses SSHD sebagai MEM:Trojan.Linux.XZ sebagai bagian dari tugas Critical Areas Scan
  • Aturan Yara yang disediakan adalah aturan liblzma_get_cpuid_function untuk menemukan fungsi get_cpuid berbahaya yang terkait dengan CVE-2024-3094

[GN⁺]

Pendapat Hacker News

• Kalimat ini justru terasa mengecilkan apa yang sebenarnya terjadi
  Yang lebih menakutkan daripada sisi teknis backdoor ini adalah jumlah dan tingkat rekayasa sosialnya. Backdoor hanyalah hasil akhirnya, dan itu bisa disisipkan karena pada saat itu seluruh proyek xz sudah lama dikuasai oleh pelaku jahat, yaitu “Jia Tan” dan pihak-pihak di sekitarnya. Mereka melakukan perang psikologis terhadap maintainer selama lebih dari setahun, dan baik maintainer maupun siapa pun yang lain tidak menyadarinya
  Ini seperti cerita novel spionase, dan kalau hal seperti ini bisa terjadi, jadi bertanya-tanya apa lagi yang sedang terjadi di proyek-proyek lain saat ini
  Pola pikir yang sama juga terlihat di kode backdoor itu sendiri. Bukan sekadar berusaha tampak tidak berbahaya, tetapi secara aktif membangun narasi tentang apa yang tampaknya dilakukan melalui commit message, komentar, nama variabel, pemilihan perintah, dan sebagainya, padahal kenyataannya melakukan hal yang sama sekali berbeda. Strukturnya dibuat agar orang yang pertama meninjau kodenya meragukan pemahamannya sendiri, lalu mencurigai bug, dan baru lama setelah itu mencurigai adanya niat jahat

  • Levelnya benar-benar sulit dipercaya. Ini bisa terdengar seperti teori konspirasi, tetapi saya juga penasaran apakah ada operasi psikologis di dunia nyata yang membuat penulis aslinya tidak bisa meluangkan waktu, lalu akhirnya menyerahkan kepemilikan kepada pelaku jahat
    Saya berharap badan intelijen mana pun sedang menyelidiki kasus ini lebih dalam
  • Semoga ini dijadikan pelajaran. Memang banyak hal seperti ini yang terjadi. Di antara lembaga yang didukung pemerintah di seluruh dunia dan organisasi pasar gelap, ada banyak yang menjadikan memperoleh backdoor sebagai misi, dan mereka punya dana yang cukup. Memang itulah pekerjaan mereka
    Setiap kali melihat thread HN tentang backdoor, rasanya frustrasi melihat kemungkinan seperti ini ditepis sebagai paranoia atau topi aluminium foil. Diperlakukan seolah-olah hal seperti ini tidak pernah terjadi, padahal kali ini hanya contoh konkret yang tertangkap, dan yang belum tertangkap jumlahnya tak terhitung
    Kali ini kebetulan proyek open source, jadi relatif lebih mudah ditemukan, dan itu pun karena beruntung. Sekarang coba pikirkan produk closed source, penyisipan backdoor di sana pada dasarnya menjadi soal menyusup atau menekan satu organisasi. Hal seperti ini sering terjadi. Tidak ada yang ingin mempercayainya, tetapi ini umum. Siapa pun yang pernah bekerja di perusahaan infrastruktur teknologi pasti punya beberapa cerita. Sulit dibicarakan karena NDA atau alasan yang lebih berat, tetapi ini benar-benar terjadi
  • Saya sepenuhnya setuju bahwa orang yang meninjau kode dibuat meragukan pemahamannya sendiri. Manipulasi, ketelitian, kesabaran, dan kegigihan yang masuk ke dalam kasus ini sungguh mengejutkan
    Ini bisa jadi hasil obsesi seseorang, atau pekerjaan perusahaan keamanan swasta maupun aktor negara yang menjalankan hal seperti ini terhadap banyak proyek sebagai pekerjaan rutin dari jam 9 sampai 5

• Wajar kalau sejauh ini perhatian terfokus pada bagaimana backdoor itu berhasil bekerja dan mencapai tujuannya
  Meski begitu, saya juga ingin melihat analisis yang lebih mendalam tentang kesalahan dan bagian-bagian yang terlalu direkayasa. Dalam wawancara Bryan Cantril [1], Andrés mengatakan bahwa ini tampak seperti komponen backdoor jadi yang tidak dibuat dengan benar-benar memahami hingga ke cara distribusinya, sehingga ada banyak bagian bodoh. Contohnya adalah pencarian tabel simbol yang membuatnya mulai menyelidiki
  Demikian pula, saya penasaran mengapa 48 byte itu dipotong dengan RC4 [2]
  Saya ingin mendengar pembahasan tentang bagaimana ini bisa dibuat lebih baik seandainya mereka punya lebih banyak waktu atau tim yang lebih bagus, atau di bagian mana mereka justru melakukan kesalahan yang lebih besar
  [1] https://youtu.be/jg5F9UupL6I?si=gvXsYFXgagkGOMd4
  [2] https://twitter.com/matthew_d_green/status/17744729080201014...

• Kalau saya memahaminya dengan benar, langkah penguatan yang berguna tampaknya adalah membuat setiap dynamic link library memiliki GOT-nya sendiri, lalu menandai tabel itu sebagai read-only setelah dynamic linking selesai. Artinya, ini akan mencegah patching entri ifunc milik pihak lain melintasi batas dynamic linking
  Dengan begitu, keamanan supply chain untuk kode yang tertaut di suatu tempat tetapi tidak dieksekusi bisa ditingkatkan
  Lebih jauh lagi, mungkin akan lebih baik jika ifunc diimplementasikan secara deklaratif, sehingga tiap library yang ditautkan tidak bisa memicu eksekusi kode arbitrer. Implementasinya sekarang mungkin sulit diubah karena kompatibilitas mundur, tetapi dalam jangka panjang tampaknya bisa diperkenalkan secara bertahap. Misalnya, jika sebuah library dibangun dengan bit fitur “declarative link ifunc”, dynamic linker akan gagal mengeksekusi jika tidak semua library yang terhubung memiliki flag fitur yang sama

  • Dari sudut lain, masalahnya ada pada sistem build
    Saat ini kebanyakan build library dilakukan dengan menjalankan skrip yang sangat rumit dan sulit dipahami, yang membutuhkan lingkungan Turing-complete. Ini memberi penyerang permukaan serangan tanpa batas, dan ketika proses build diambil alih, peluang pun terbuka
    Akan membantu jika berpindah ke proses build deklaratif yang menjaga executor tetap sekadar mesin status terbatas. Persyaratan bahwa semua potongan source harus dapat direproduksi juga layak dipertimbangkan
  • Benar juga, tapi juga tidak, dan pada umumnya tidak. Pendekatan seperti ini memang akan mencegah penggunaan ifunc secara sesederhana ini, tetapi yang penting adalah bahwa penulis backdoor ini mampu menyuntikkan kode arbitrer ke library yang masuk ke address space proses sensitif
    Begitu sampai di titik itu, semua pertahanan runtuh. Jika mau, mereka bisa memetakan ulang GOT agar bisa ditulisi lagi, dan walaupun tindakan seperti itu mungkin terdeteksi sebagai “mencurigakan” atau sistem operasi bisa mencegah perubahan itu, kode yang disuntikkan tetap bisa membalik alur kontrol dengan ratusan cara lain. Arbitrary read/write, eksekusi kode, semuanya mungkin. Tidak ada mitigasi keamanan yang bisa mencegah kompromi pada tahap ini. Kalau mau, mereka bahkan bisa membocorkan private key dan mengirimkannya langsung ke penyerang, atau menjalankan shell. Mencoba merancang perlindungan pada tahap ini adalah usaha yang sia-sia
  • Menandai tabel sebagai read-only setelah dynamic linking selesai sayangnya tidak akan berhasil. Dynamic linking bersifat lazy, jadi tidak pernah ada momen ketika ia benar-benar “selesai”
    Function pointer yang benar dimuat saat pertama kali dipanggil dan kemudian dimasukkan ke tabel menggantikan stub, dan waktu itu bisa terjadi di masa depan yang sangat jauh secara arbitrer. Bahkan dalam ekosistem library besar seperti aplikasi gtk, sebagian besar fungsi yang ditautkan pada kenyataannya tidak pernah dipanggil sama sekali
  • Jika dibangun untuk arsitektur host, ifunc bisa dimatikan sepenuhnya tanpa kerugian. Di Gentoo, build dengan -march=native itu umum, dan menonaktifkan ifunc cukup mudah dengan menyetel -multiarch pada USE flag glibc. Saya belum melihat dampak negatifnya
  • Apakah ada bahasa pemrograman yang bisa melakukan sandbox pada import library?

• Untuk 3 tahap pertama, tulisan ini tidak banyak menambahkan hal baru dibanding yang sudah diketahui selama 2 minggu terakhir. Paling tidak, ini semacam tulisan rangkuman yang bagus dengan diagram alur.
  Namun bagian yang menganalisis biner sedetail itu tampak baru.
  Bagaimana kode sumber yang ditampilkan di sana dibuat? Apakah mereka menjalankan disassembler, memahami apa yang dilakukan kodenya, lalu mengganti semua nama menjadi nama yang deskriptif? Jika itu dicapai hanya dalam 2 minggu, hasilnya terlihat sangat mengesankan.

  • Penulisnya adalah GReAT.
    Global Research & Analysis Team, Kaspersky Lab
    https://securelist.com/author/great/
    Penulis artikel itu tampaknya adalah tim analisis malware dari Kaspersky Lab, jadi kemungkinan besar mereka sangat ahli dalam rekayasa balik biner.
  • Alat yang digunakan pada tangkapan layar putih itu adalah decompiler IDA Pro.
    https://hex-rays.com/ida-pro/

• Yang benar-benar membuat penasaran adalah apa tepatnya yang menyebabkan penundaan awal SSH yang memicu penyelidikan xz. Siapa yang berhasil menemukannya?

  • Mereka memang melakukan operasi ECC tambahan untuk setiap koneksi, tetapi pada CPU modern mestinya itu tidak sampai memakan waktu 500 ms.
    Menurut orang-orang yang merekayasa balik kodenya, pesan perintah juga harus diikat ke kunci host SSH. Jadi jika kunci host-nya adalah kunci RSA, mungkin ada tambahan operasi dekripsi RSA pada setiap koneksi.
    Jika begitu, itu sudah cukup masuk akal sebagai penyebab keterlambatan.
  • Bisa jadi memang disengaja.
    Itu cara mudah untuk mengetahui dari luar apakah sebuah server terinfeksi, tanpa harus lebih dulu mencoba menyuntikkan kode.

• Para penulisnya memahami struktur internal glibc dengan sangat mendalam. Ini jenis hal yang hanya bisa diketahui kalau benar-benar tenggelam sampai leher dalam kode sumbernya, dan ada banyak teknik baru juga.
  Parser ELF kustom dan disassembler-nya terlalu rumit, sehingga sulit membayangkan kode itu tidak pernah dipakai di tempat lain sebelumnya atau tidak akan dipakai lagi di masa depan.
  Saya penasaran apakah kasus ini akan mendapatkan penyelidikan serius yang semestinya, tetapi rasanya tidak.

• Apakah ada yang sudah menganalisis bug backdoor yang pada akhirnya memunculkan kesalahan Valgrind dan perlambatan SSH?

  • Tampaknya itu adalah penulisan memori yang jelas-jelas salah: https://www.mail-archive.com/[e-mail]...
    “Perbaikan” Valgrind adalah menonaktifkan ifunc, dan akibatnya backdoor ikut nonaktif sehingga kesalahannya hilang.
    Setahu saya, perlambatan itu berasal dari semua pencarian simbol dan instruksi yang dilakukan oleh backdoor.

• Kalau dilihat sebagai sebuah kejutan, mengingat upaya yang dilakukan penyerang untuk menghindari deteksi lewat skrip dan kode, bisa saja keseluruhan proyek ini adalah pengalih perhatian atau cadangan sementara beberapa upaya lain berjalan bersamaan.
  Bagaimana cara untuk tetap selangkah lebih maju dari hal seperti ini? Apakah fokus komunitas pada SSHD akan memengaruhi bagian lain dari sistem secara keseluruhan? Bagaimana dengan sisi teknis atau sosial lainnya?
  Topi aluminium foil itu menyenangkan.

  • Saya tidak optimistis. Hampir tidak ada yang benar-benar mengaudit isi biner flatpak di Flathub. Apakah benar-benar dibangun dari source? Intinya hanya percaya pada klaim pembuatnya. Untuk hal seperti ini, mungkin bahkan tidak perlu mekanisme distribusi yang secanggih backdoor ini.
  • Kita bisa menulis semuanya sendiri, lalu punya tim khusus yang terdiri dari pengembang terverifikasi.
    Atau membeli closed source dari tempat seperti Microsoft, lalu berharap mereka punya sumber daya dan kemauan untuk meninjau kode dengan lebih ketat.
    Dan selalu ada juga pendekatan memiliki tim operasi keamanan yang hebat untuk mendeteksi aktivitas jaringan aneh dan upaya eskalasi hak akses.
  • Salah satu cara untuk selangkah lebih maju dari backdoor serupa adalah membungkus trafik sshd dengan tunnel spiped. Spiped bisa dikompilasi dari source dan ditautkan secara statis, dan versi stabil terakhirnya berasal dari 2021.
  • Ide topi aluminium foil saya adalah agar kita mencurigai kontributor open source. Bukan karena mereka berasal dari negara tertentu, dan juga bukan karena tampaknya belum pernah ditemui langsung.
    Namun kontributor yang tidak punya riwayat atau jejak apa pun di luar proyek yang sedang mereka kerjakan, ke depannya harus dianggap sebagai tanda bahaya.
  • Tidak perlu topi aluminium foil. Proyek FOSS sudah lama disusupi backdoor bahkan sebelum menjadi terkenal, dan perbedaan kali ini adalah bahwa pelakunya adalah aktor yang didukung negara.
    Grup-grup lama seperti GOBBLES, ADM, ac1db1tch3z, ~el8 juga pernah melakukan hal seperti ini, dan “peneliti keamanan” swasta seperti isec.pl juga demikian.
    Yang membuat ini jadi masalah adalah para aktor negara memanfaatkan kapitalisme korporat yang telah menciptakan era proyek-proyek fondasi ditopang oleh tenaga kerja bergaji rendah. Para pelaku jahat pada dasarnya memiliki sumber daya yang nyaris tak terbatas untuk mencapai tujuan mereka.
    Pada akhirnya, itulah yang menciptakan permintaan dan melahirkan organisasi seperti NSO dan Zerodium.
    Sebelumnya, eksploit dan backdoor nyaris tidak punya nilai, dan para hacker berharap mendapat sponsor atau direkrut oleh perusahaan seperti Qualys.

• Saya sudah beberapa kali melihat analisis peretasan zero-day dari Google, dan itu pun terasa luar biasa sampai tidak realistis, tetapi peretasan kali ini tampaknya akan menjadi salah satu yang terbesar sepanjang masa.

• Saya melihat repositori xz sudah kembali ada di GitHub, dan Lasse bersama kontributor baru sedang membereskannya. Mereka menghapus dukungan ifunc, dan meng-commit kode pembuatan file uji ke repositori agar file uji bisa dibuat tanpa blob. Tampaknya mereka bergerak ke arah yang baik.