Backdoor XZ: “Ini RCE, bukan bypass autentikasi; memiliki gate dan tidak dapat diputar ulang”

• Menurut analisis awal reverse engineering terhadap backdoor xz, perilaku ini bukan sekadar bypass autentikasi, melainkan lebih dekat ke eksekusi kode jarak jauh (RCE)
• Intinya adalah alur ketika RSA_public_decrypt yang di-hook memverifikasi tanda tangan host key server dengan kunci Ed448 tetap
• Jika verifikasi tanda tangan lolos, payload dapat diteruskan ke system() dan dieksekusi
• Analisis ini adalah hasil awal yang dibagikan dengan izin, dan postingan Bluesky mencakup postingan kutipan atau konten tersemat
• Backdoor ini diringkas sebagai bentuk yang memiliki gate dan tidak dapat diputar ulang, sehingga harus dilihat berbeda dari serangan yang sekadar menggunakan ulang input yang sama

---

Alur eksekusi backdoor xz

• Analisis awal reverse engineering yang dibagikan dengan izin berfokus pada RSA_public_decrypt yang di-hook
  • Memverifikasi tanda tangan untuk host key server dengan kunci Ed448 tetap
  • Setelah verifikasi, meneruskan payload ke system()

Klasifikasi dan batasan

• Perilaku ini diklasifikasikan sebagai eksekusi kode jarak jauh (RCE), bukan bypass autentikasi
• Backdoor ini diringkas memiliki karakteristik gated/unreplayable
• Postingan Bluesky asli mencakup postingan kutipan atau konten tersemat lain

[GN⁺]

Komentar Hacker News

• Ada hasil reverse engineering tambahan terkait perkara ini. Isinya mencakup informasi remapping simbol yang diekstrak dari prefix trie yang dipakai backdoor untuk menyembunyikan string, dan tampaknya ia juga berusaha bersembunyi dari reverse engineering/analisis itu sendiri
  https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
  Daftar lengkap string yang telah didekode ada di sini
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
  Dari sudut pandang orang yang tidak terlalu mengenal internal OpenSSL, nilai N tampaknya diambil dari field n pada rsa_st
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  Nilai ini adalah BIGNUM, dan tampaknya merupakan tipe dengan panjang variabel
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  Backdoor mengambil nilai ini dari sertifikat yang diterima dari penyerang jarak jauh, mencoba mendekripsinya dengan ChaCha20, dan jika berhasil, meneruskannya ke system(). system() pada dasarnya lebih mirip wrapper sederhana yang menjalankan satu baris skrip shell dengan hak pengguna yang sedang menjalankan proses saat ini
  Jika pemahaman saya benar, ini lebih buruk daripada bypass kunci publik. Kalau hanya bypass kunci publik, secara teori penyerang hanya mendapat hak pengguna yang ingin login, dan pada konfigurasi SSH yang diperketat, login root kemungkinan besar sudah diblokir
  Namun ini adalah remote code execution dalam konteks proses sshd itu sendiri, sehingga jika sshd berjalan sebagai root, payload juga bisa berjalan sebagai root. Untuk remote code execution yang tersebar luas, ini secara realistis nyaris skenario terburuk

  • Dengan sandboxing yang tepat, SELinux, dan teknik mitigasi, mungkin saja mencegah penyerang melakukan sesuatu dengan hak root. Namun menerapkan sandbox secara efektif pada daemon SSH sangat sulit
  • Luar biasa. Saya bahkan tidak bisa membayangkan bagaimana seseorang memutuskan apa yang akan dilakukan dengan hak atas 1 miliar komputer

• Saya penasaran seberapa besar kemungkinan backdoor ini ditemukan nanti jika tidak ketahuan karena masalah performa. Saya memahami masalah performa itu sebagai kesalahan/cacat dalam kode yang bisa diperbaiki, dan penting juga apakah ada alat yang bisa menangkapnya
  Pertanyaan seperti ini sangat relevan untuk memahami apakah backdoor jenis ini adalah yang pertama, atau hanya yang pertama terungkap

  • Dari pengalaman bekerja sekitar setahun di lingkungan dengan sangat banyak aktor IT jahat, saya menilai peluang ditemukannya selalu cukup tinggi. Menjaga rahasia membutuhkan energi yang sulit dibayangkan, begitu juga menjaga konsistensi kebenaran
    Satu kesalahan kecil bisa meruntuhkan semuanya, dan kadang satu kalimat saja bisa memicu reaksi berantai yang mengungkap rencana yang disusun dengan sangat rapi
    Investigasi kriminal terjadi seperti itu setiap hari. Pekerjaan kepolisian punya keterbatasan sumber daya, tetapi perangkat lunak diperiksa setiap hari oleh orang-orang yang menganalisisnya sebagai hobi, para ahli yang terus menganalisisnya seolah-olah sebagai hobi, dan para profesional yang menganalisisnya sebagai pekerjaan
    Pada akhirnya, kemungkinan besar ini akan ditemukan suatu saat
    Serangan XZ dieksekusi dengan sangat baik, nyaris seperti mahakarya. Saya tidak akan terkejut jika lembaga negara terlibat. Namun pada saat yang sama, mereka juga sangat beruntung. Jika salah satu saja dari hal-hal yang sekarang ditandai sebagai masalah ditemukan, saya dan banyak rekan lain pasti akan melakukan penelusuran panjang
    Satu kesimpulan yang bisa diambil adalah bahwa jika xz/liblzma bukan open source, mustahil menemukan masalah seperti ini. Tentu, karena open source juga ada sisi yang membuat ini mungkin terjadi sejak awal, tetapi bayangkan saja jika ini ada di dalam Windows atau MacOS
  • Jika exploit-nya tidak digunakan, peluang ditemukan mungkin cukup rendah. Lokasi persembunyiannya dipilih dengan tepat. Praktis berada di luar codebase, tempat yang tidak dilihat auditor
    Namun jika tidak dipakai, tujuan mereka tidak tercapai. Semakin sering dipakai, semakin besar pula kemungkinan terdeteksi di kemudian hari. Ini bisa dibandingkan dengan SolarWinds
  • Saya rasa selama beberapa bulan ke depan banyak orang akan memikirkan arah seperti ini secara serius. Apakah jawabannya code review, atau semacam analisis perilaku, itulah persoalannya
    Secara pribadi, pemanggilan system() terasa agak ceroboh, dan scanner fitur biner mungkin saja berpotensi menemukan jalur itu
  • Sepertinya ini akan sulit ditangkap. Patch pada sshd terjadi pada waktu linking, tahap yang masih bisa diterima, dan jika analisis ini benar, ini juga bukan backdoor master key sehingga tidak ada jejak audit login yang biasa. Selain itu, sshd memulai proses lain pada dasarnya bisa saja dianggap wajar
    Kebijakan SELinux yang sangat ketat mungkin bisa menangkap ketika sshd menjalankan sesuatu selain shell, tetapi pengerasan pada tingkat seperti itu kemungkinan sangat jarang
    Persoalan menemukannya dari luar target juga sebenarnya sudah teruji. Banyak orang melihat payload dengan valgrind dan semacamnya, tetapi tidak menemukannya. Payload juga cukup terlindungi agar tidak ditemukan di lingkungan debugging. Ini karena infrastruktur yang tampak di bawah payload tidak kompatibel dengan alat seperti ASan
    Bahkan kalaupun tertaut, kodenya berjalan jauh sebelum main(), sehingga meski menelusuri area sekitar liblzma dengan debugger, biasanya Anda tidak akan mengamati momen eksekusinya
    Dengan strace, semua system call dan perilaku linker setelah proses dibuat bisa terlihat. Namun sejauh yang dipahami sejauh ini, payload tampaknya tidak melakukan system call untuk menentukan apakah ia akan aktif pada tahap itu, melainkan melihat argv, environ, dan sejenisnya
  • Sebagai turunan yang menarik, saya teringat bahwa serangan Ken Thompson juga ditemukan di PWB karena bug performa memori
    [0] https://en.wikipedia.org/wiki/PWB/UNIX
    [1] https://news.ycombinator.com/item?id=38020792

• Tampaknya ada string yang dikodekan di dalam payload biner
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
  String ini berfungsi sebagai kill switch
  https://piaille.fr/@zeno/112185928685603910
  Jika memang demikian, salah satu mitigasinya bisa seperti berikut

  echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment  
  

  • Wajib menyertakan -a. Jika tidak, Anda bisa menghapus habis file environment. Dan secara umum, yang benar adalah upgrade ke versi tanpa kode berbahaya lalu restart
  • Terlalu aneh. Sangat terasa seperti aktor negara yang ingin meninggalkan cara untuk melindungi sistemnya sendiri

• Bisa jelaskan secara singkat apa sebenarnya yang dilakukan backdoor ini? Apakah sudah diketahui? Backdoor itu sendiri sepertinya bukan payload; saya penasaran apakah diperlukan file terkompresi berbahaya, atau apakah ia memasang hook pada proses sshd untuk mendengarkan paket berbahaya dari penyerang jarak jauh
  Teks aslinya terdengar seolah penyerang bisa mengirim payload berbahaya pada tahap sebelum autentikasi sesi SSH, tetapi saya juga tidak mengerti mengapa exploit mungkin tidak akan pernah muncul. Kalau kodenya bisa di-reverse engineer, bukankah proof of concept juga bisa ditulis?
  Pada akhirnya, bagaimana penyerang mengendalikan mesin yang memiliki backdoor ini?

  • Bayangkan pintu yang terbuka jika diketuk dengan tepat. Bagi orang yang tidak tahu ketukan rahasianya, ia terlihat dan berfungsi seperti dinding biasa. Tanpa ketukan rahasia, mungkin bahkan tidak ada cara untuk membuktikan bahwa itu bisa dibuka sejak awal
    Situasi di sini mirip. xz mencoba mendekripsi data tertentu sebelum melakukan hal yang mencurigakan. Karena metodenya asimetris, verifikasi dekripsi bisa dilakukan tanpa memberikan kunci enkripsi rahasia, sebab ia memiliki kunci publik pasangannya
    Karena menemukan kunci rahasia secara realistis mustahil, dan kegagalan mendekripsi payload tidak menghasilkan perilaku yang tampak berbeda, kode exploit mungkin tidak akan pernah dipublikasikan. Satu-satunya cara membuat kode exploit adalah jika kunci rahasianya entah bagaimana ditemukan, dan secara realistis itu hanya mungkin jika pengembang backdoor membocorkannya
  • Berdasarkan yang saya baca, vektor serangannya kira-kira begini. Saat sshd mulai, ia memuat libsystemd, yang kemudian memuat library XZ yang berisi kode peretasan
    Library XZ menyuntikkan versi buatannya sendiri dari fungsi-fungsi OpenSSL yang memverifikasi tanda tangan RSA
    Ketika seseorang login ke SSH dan menyajikan sertifikat SSH bertanda tangan untuk autentikasi, fungsi-fungsi yang telah dimodifikasi itu dipanggil
    Sertifikat dapat berisi informasi pernyataan seperti nama pengguna atau peran dalam proses login normal, dan informasi ini digunakan untuk menentukan apakah sertifikat valid untuk login pengguna tertentu. Namun jika fungsi yang dimodifikasi mendeteksi sertifikat yang ditandatangani dengan kunci penyerang tertentu, ia mengambil sebagian subfield sertifikat dan mengeksekusinya sebagai perintah sistem. Konteks eksekusinya adalah sshd, yaitu pengguna root
    Sayangnya kita tidak mengetahui kunci tanda tangan penyerang, hanya kunci publik yang digunakan kode peretasan untuk verifikasi. Pada dasarnya, penyerang dapat melakukan eksekusi perintah arbitrer sebagai root pada sistem yang terinfeksi, dan jejaknya paling-paling hanya berupa percobaan login yang gagal. Untuk sistem yang terekspos ke internet, percobaan seperti itu memang sudah banyak terjadi
  • Sepertinya belum diketahui persis apa yang dilakukannya. Namun bagian “tidak dapat direplay” saya pahami begini: jika payload salah atau tanda tangan kunci penyerang tidak terverifikasi, backdoor kembali ke perilaku normal
    Poin utamanya adalah dibutuhkan tanda tangan dari kunci penyerang. Selama kunci itu tidak bocor atau algoritma RSA tidak jebol, peneliti lain atau pihak ketiga tidak mungkin menyalahgunakan backdoor ini. Kalau RSA jebol, akan ada masalah yang jauh lebih besar daripada ini
  • Jika kriptografi kunci publik digunakan dengan benar dan tidak ada bug yang bisa dieksploitasi, reverse engineering pun tidak cukup untuk membuat proof of concept
  • Exploit yang didistribusikan berbentuk biner, bukan source, dan disembunyikan dengan cerdik di dalam data pengujian. Selain itu, payload diverifikasi dengan kunci privat yang tidak dipublikasikan
    Untuk saat ini hanya penyerang yang bisa menjalankan exploit, sehingga pemindaian juga tidak mungkin. Selain efek sekunder seperti penurunan performa, sulit dideteksi, dan memang dengan cara itulah ia ditemukan

• Sulit dipahami bahwa paket penting yang dipakai begitu banyak server Linux setiap hari bisa sampai tidak dapat dipelihara oleh penulis aslinya karena kekurangan dana. Ada sesuatu yang harus berubah dalam open source
  Salah satu solusinya mungkin lisensi yang mewajibkan perusahaan atau badan usaha di atas ukuran tertentu membayar biaya pemeliharaan

  • Orang-orang akan sangat menentang lisensi seperti itu. Akan muncul penolakan besar bahwa “ini tidak lagi bebas”, lalu pihak tersebut akan dibatalkan
  • Saya penasaran apakah ini benar-benar kekurangan dana, atau justru burnout
  • Cyber Resilience Act Uni Eropa yang diusulkan mengklaim dirinya sebagai solusi. Singkatnya, vendor bertanggung jawab atas kerentanan selama masa hidup produk, entah itu firewall maupun toaster
    Karena itu vendor akan memiliki insentif untuk menjaga open source tetap aman. Misalnya dengan membayar maintainer, memesan audit kode, atau mempekerjakan pegawai tetap untuk berkontribusi
  • Penting dan diperlukan itu berbeda. Paket ini lebih tepat disebut diperlukan daripada penting
  • Sulit memahami mengapa sesuatu serumit xz diperlukan. Kode bzip2 kecil, dan kemungkinan bisa dipelihara hanya dengan sebagian sangat kecil waktu satu orang

• Kalau sekarang masuk ke repositori xz, repositorinya dinonaktifkan karena melanggar Ketentuan Layanan GitHub. Penonaktifan itu sendiri wajar, tetapi saya berharap GitHub membiarkan kode dan riwayatnya tetap ada, menampilkan banner, dan hanya memblokir fungsi yang bisa disalahgunakan
  Dengan begitu peneliti dan orang lain bisa mempelajari exploit-nya. Dalam situasi yang lebih sepele, jika sebuah library meng-host kode berbahaya lalu repositorinya diturunkan, orang bisa saja menganggapnya bukan masalah besar

  • Sepertinya mereka tidak ingin alat otomatis mengunduhnya
  • Event GitHub untuk repositori tersebut dapat dilihat dalam CSV di sini: https://github.com/emirkmo/xz-backdoor-github
    Jika tertarik pada source code, mudah menemukannya. Kode ini dan repositori Git-nya terhubung ke berbagai repositori Git di seluruh dunia, dan source-nya juga beberapa kali dibundel dalam rilis
  • xz memiliki mirror Git sendiri, jadi semua commit bisa dilihat

• Sebagai maintainer de facto dari sebuah game open source yang tidak begitu dikenal, saya sudah melihat developer datang dan pergi. Kontribusi yang bernilai langsung saya merge semuanya
  Sebagian kolaborator mendalami fitur cukup jauh dalam kondisi C dan C++ bercampur dengan berbagai gaya coding. Saya tidak selalu memahami semua detail implementasinya, tetapi di sudut hati selalu ada pikiran bahwa kalau ada orang memasukkan backdoor yang benar-benar jahat, proyek ini bisa hancur
  Untungnya game ini sangat obscure dan attack surface-nya juga sangat kecil. Meski begitu, godaan untuk menandatangani binary Windows dengan niat baik jadi berhenti
  Backdoor xz ini benar-benar mimpi buruk raksasa, dan saya prihatin kepada para developer asli serta semua orang yang terseret di dalamnya

  • Tentu itu benar, tetapi ini bukan masalah software saja. Bahkan saya tidak yakin apakah ini bisa disebut “masalah” dalam arti yang bermakna
    Saat berjalan di jalur hutan, mobil yang lewat bisa saja langsung menabrakmu. Pengemudinya kemungkinan besar tidak akan tertangkap, tidak ada cara untuk mencegahnya, dan polisi juga tidak ada di sampingmu. Skenario ini, yang jauh lebih menakutkan daripada backdoor software, sebenarnya adalah risiko minimum yang harus diterima agar bisa tetap hidup sambil melakukan sesuatu. Hal seperti itu memang benar-benar terjadi
    Namun pada akhirnya, sebagian besar orang tidak secara aktif berusaha menyakiti orang lain. Semua hal yang dilakukan manusia selalu berdiri di atas asumsi itu, dan sekarang pun begitu
    Ilusi bahwa hal seperti ini akan bisa dicegah dengan sedikit memperketat code review, lebih banyak memakai linter, CI, dan pattern matching, memperluas code signing, serta memverifikasi identitas orang-orang, justru merupakan masalah yang sebenarnya. Itu gejala delusi ala Silicon Valley bahwa dunia bisa dan harus dikelola serta dikendalikan hingga ke setiap tingkat detail. “Obat” semacam itu bisa jauh lebih buruk daripada penyakit apa pun yang ingin dicegahnya
  • Mendiang Pieter Hintjens dari ZeroMQ pernah mendukung praktik bernama Optimistic Merging. Caranya adalah langsung me-merge kontribusi tanpa menunggu code review atau hasil CI. Pendekatan dengan kriteria merge yang longgar ini tidak sepenuhnya tidak masuk akal
    [1]: http://hintjens.com/blog:106
    Saya memahami manfaat membangun komunitas tempat kontributor senang berpartisipasi dalam proyek. Namun bagi saya, cara itu terasa seperti membuat proyek tumbuh tanpa visi atau arah yang jelas, dan pada akhirnya membebani maintainer secara berlebihan untuk menyesuaikan kontribusi orang lain dengan standar bersama
    Code review yang sebenarnya terdorong ke titik waktu yang tidak diketahui di masa depan; saat itu belum tentu review-nya menyeluruh, dan tidak jelas siapa yang bertanggung jawab melakukannya atau memperbaiki masalah. Pada akhirnya, ini terdengar seperti resep kekacauan yang membuat kita tidak bisa mengontrol apa yang dikirimkan kepada pengguna
    Ada juga masalah distribusi kode berbahaya. Masalah ini juga muncul di komentar posting blog tersebut, dan Pieter menjelaskan skenario yang persis sama dengan kasus xz
    “Misalkan Mallory sabar, manipulatif, dan bertindak seperti kontributor sah untuk waktu yang cukup lama hingga memperoleh kendali atas proyek, lalu perlahan menanam backdoor. Maka code review yang hati-hati pun tidak membantu. Mallory hanya perlu mendapatkan kepercayaan yang cukup untuk menjadi maintainer, dan itu bukan soal bisa atau tidak, melainkan soal bagaimana.”
    Ia menyimpulkan bahwa “pertahanan terbaik adalah ukuran dan keberagaman komunitas”
    Namun saya berpendapat code review yang hati-hati memang bisa menurunkan kemungkinan hal seperti ini terjadi. Jika semua kontribusi, baik dari kontributor tepercaya maupun kontributor luar, direview secara menyeluruh, peluang menemukan perilaku aneh atau commit yang mengklaim “melakukan A” tetapi sebenarnya melakukan B akan lebih besar dan lebih dini
    Apakah Optimistic Merging benar-benar mengarah pada komunitas yang lebih besar dan lebih beragam juga masih bisa diperdebatkan. Banyak proyek memiliki komunitas aktif meski dengan panduan kontribusi yang ketat. Dan pendekatan itu tidak menjawab kapan dan bagaimana patch berbahaya akan ditangkap
    Masalah xz bukanlah komunitas yang kecil, melainkan tidak ada komunitas. Satu pelaku jahat memperoleh kendali atas proyek, dan hampir tidak ada pengawasan dari orang lain. Panduan kontribusi bukan faktor ukuran komunitas, dan entah memakai Optimistic Merging atau tidak, hal seperti ini tetap akan terjadi
    [2]: http://hintjens.com/blog:106/comments/show#post-2409627
  • Saya selalu terkejut melihat perusahaan mengerahkan upaya besar untuk keamanan perimeter jaringan, sementara di organisasi development mereka secara rutin memasang brew install cask atau ekstensi vi/emacs/vscode
    Rust bisa dibilang bahasa pemrograman/komunitas dengan default paling aman, dengan desain yang mengutamakan keamanan sampai hampir tidak memungkinkan permainan pointer sembarangan. Namun jalur instalasi yang paling umum dan direkomendasikan adalah seperti ini, dan saya sendiri, sebagai orang yang sepenuhnya munafik, juga sering melakukannya
    https://www.rust-lang.org/tools/install
    Ini hanya satu contoh. Kebiasaan membuka remote code execution sendiri dengan pola “curl ini lalu pipe ke sh”, sementara di saat yang sama berdebat soal blok unsafe milik seseorang, sudah menjadi muscle memory bagi terlalu banyak orang
  • Jujur saja, hanya soal waktu sampai kita menyadari bahwa niat baik kita bisa dieksploitasi. Perilaku seperti “break fast and fix fast” atau “ada yang mau mengambil alih kepemilikan proyek saya?” memang mengundang masalah, tetapi selama open source masih berupa kerja cinta tanpa bayaran terhadap coding, sulit membayangkan hidup tanpanya
    Menyedihkan hal seperti ini terjadi, tetapi tidak mengejutkan. Saya berharap muncul alat yang lebih baik untuk melawan aktor jahat seperti ini, dan semoga itu juga open source

• Ada sejumlah pertanyaan yang dilontarkan oleh backdoor ini. Backdoor lain apa lagi yang ditanam oleh tim yang sama atau tim serupa? Berapa banyak tim seperti ini yang beroperasi? Seberapa banyak dependensi yang rentan terhadap serangan infiltrasi seperti ini? Seberapa besar attack surface industri kita yang menjadi sasaran operasi terselubung semacam ini?
  Membuat graf untuk layanan jaringan utama seperti apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid, postfix, beserta semua dependensinya, dan seluruh graf committer dari dependensi-dependensi itu, bisa menjadi langkah pertama untuk mengetahui area mana yang paling bernilai tinggi dan paling kurang diawasi.
  Ini pasti bukan pertama kalinya seseorang mencoba hal seperti ini. Ini hanya kasus pertama yang gagal lalu terungkap. Kita tahu ada backdoor yang dicoba dimasukkan ke kernel Linux lalu ditemukan, tetapi ini adalah serangan jarak jauh dan sifatnya sepenuhnya berbeda.

  • Mengapa mereka memutuskan membuat backdoor, alih-alih memakai zero-day seperti orang lain?
    Mengapa tidak menyebarkan sesuatu yang tampak tidak berbahaya dan bisa terlihat seperti bug jika terdeteksi, tetapi justru mengimplementasikan backdoor berfitur lengkap dan bahkan menyembunyikan cara distribusinya?
    Ini pasti keputusan yang disadari. Alasannya bisa memberi petunjuk tentang apa sebenarnya target mereka.
  • Debian juga perlu ditanya mengapa mereka menambal layanan yang berjalan sebagai root dan menerima koneksi dari internet agar memuat library yang tidak diperlukan.

• Ini sepertinya berarti, untuk memindai exploit dari jarak jauh, kita memerlukan private key milik penyerang yang tidak kita miliki. Pilihan lainnya hanya menjalankan skrip deteksi secara lokal.

  • Cara yang benar-benar buruk yang mungkin dipilih sebagian scanner adalah menandai server sebagai “berpotensi rentan” jika menyediakan autentikasi RSA. Sebagian besar server SSH menyediakan autentikasi RSA, dan memang SecSH RFC juga menyebutnya wajib diimplementasikan. Itu bisa mendorong orang kembali memakai autentikasi password.
    Kecuali terbukti bahwa masalah ini tersebar luas di sistem nyata, pendekatan seperti itu tampak lebih buruk daripada kejadian ketika “pakar” serupa dulu menuntut orang mengganti password setiap tahun, yang justru menurunkan keamanan nyata dan hanya membuat keamanan di atas kertas tampak lebih baik.
  • Karena kode verifikasi tanda tangan tampaknya hanya dijalankan ketika public key klien cocok dengan fingerprint tertentu, mungkin ini bisa dideteksi lewat informasi timing.
    Verifikasi tanda tangan backdoor kira-kira akan memakan waktu sekitar 100µs, jadi key dengan fingerprint yang cocok seharusnya diproses selama itu lebih lama dibanding key yang tidak cocok. Selisih waktu ini setidaknya realistis untuk dideteksi di LAN, dan mungkin juga melalui internet jika scanner dijalankan dari lokasi yang dekat dengan target.
    Sistem yang memblokir IP klien setelah kegagalan autentikasi berulang akan membuat pemindaian lebih sulit.
    (https://bench.cr.yp.to/results-sign.html mencantumkan verifikasi Ed448 sekitar 400 ribu siklus, yang setara dengan 100µs pada 4GHz)
  • Tweet itu menyebut “tidak dapat diputar ulang”. Saya penasaran mengapa tidak bisa diputar ulang. Apakah sshd yang berisi backdoor mengeluarkan challenge tertentu, lalu penyerang harus menandatanganinya?

• Ini mungkin opini yang tidak populer, tetapi saya tidak bisa tidak mengagumi keseluruhan operasi ini. Tentu saja saya mengecamnya, tetapi tetap saja mengagumkan. Dari konsepsi hingga eksekusi, ini benar-benar seperti karya seni, dan kita sangat beruntung ini tertangkap begitu dini.

  • Jika payload-nya tidak menyebabkan jeda acak 0,5 detik saat login SSH, mungkin ini tidak akan ditemukan untuk waktu yang lama.
    Lain kali, kemungkinan para penyerang akan membuat payload yang tidak menimbulkan lonjakan latensi aneh pada pekerjaan yang ditunggu manusia.
    Entah kenapa ini mengingatkan saya pada kejadian ketika Kim Dotcom mengetahui dirinya menjadi target penyadapan ilegal. Ping-nya tiba-tiba melonjak besar di MW3. Setelah diselidiki, hanya paket miliknya yang dirutekan secara fisik melalui kantor GCSB yang sangat jauh. GCSB tidak berwenang menyadap penduduk tetap Selandia Baru. Pada akhirnya, ia menerima permintaan maaf pribadi dari Perdana Menteri Selandia Baru.
  • “Bagaimanapun, orang yang seharusnya tidak pernah digabungkan itu melakukan sesuatu yang hebat. Mengerikan, tetapi hebat.”
    Menurut saya bagian paling cerdik adalah pemilihan proyek yang akan diinfiltrasi. Membaca ulang diskusi pull request IFUNC dari “Hans” setelah kejadian terasa menyakitkan, tetapi benar-benar menunjukkan mengapa proyek ini dipilih.
    Saya ingin tahu berapa banyak orang di balik “Jia” dan “Hans”, serta bagaimana mereka menganalisis dan menyusun strategi untuk komunikasi dan kontribusi kode. Beberapa aspek, seperti persona ketiga di mailing list yang berpura-pura memberi tekanan, tampak agak asal dibuat.
    Jadi masih mungkin ini dilakukan oleh tim kecil yang canggih, atau bahkan seorang individu tunggal. Jika pelakunya aktor negara, saya membayangkan akan ada orang-orang yang sepanjang hari membuat dan memelihara persona palsu untuk operasi semacam ini.
    Akan jadi masalah jika ada seseorang berpikir, “Aneh, tiga pengguna ini agak kasar dan memaksa, siapa mereka? Semua akunnya dibuat sekitar waktu yang sama. Mencurigakan. Mengapa ada orang yang repot-repot memakai akun palsu untuk mendorong ini sekuat itu? Ini perlu diselidiki.” Dibanding seluruh upaya yang dicurahkan, bagian itu ceroboh, atau perencanaannya buruk, atau anggarannya kurang.
  • Saya setuju, tetapi bagian rekayasa sosial terasa sangat kejam.
  • Saya rasa itu bukan opini yang terlalu tidak populer. Dalam banyak hal, ini serangan yang sangat mengesankan. Serangannya halus, dibangun selama bertahun-tahun, dan jika penyerang tidak melakukan kesalahan berupa penurunan performa aneh yang memicu penyelidikan, mungkin kita tidak akan pernah tahu.
    Kalau menambahkan hipotesis dramatis, mungkin penyerangnya takut dengan “bom nuklir informasi” yang akan ia ledakkan sendiri lalu sengaja menggagalkannya.
    Kita bisa membenci hasil akhirnya sambil tetap mengakui kompleksitas serangannya.
  • Saya tidak yakin “kagum” adalah kata yang tepat, tetapi memang ini operasi yang cukup mengesankan.