Arch Linux menilai insiden malware kini telah terkendali: lebih dari 1.500 paket terdampak

 (phoronix.com/news)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Di repositori kontribusi pengguna AUR milik Arch Linux, paket yang terinfeksi malware awalnya terkonfirmasi lebih dari 400, lalu akhirnya bertambah menjadi lebih dari 1.500
  • Dalam pembaruan beberapa jam sebelumnya, paket yang terinfeksi dalam insiden minggu ini diperkirakan sekitar 900 paket
  • Setelah itu, pengembang Arch Linux menghapus semua commit berbahaya yang diketahui, dan jumlah paket terdampak dihitung sebanyak 1.579
  • Daftar 1.579 ini juga ditandai sebagai daftar yang besar tetapi bukan keseluruhan dari paket yang terdampak, sehingga cakupan totalnya bisa lebih luas
  • Banyak perangkat lunak di repositori yang dipelihara pengguna terdampak oleh insiden keamanan ini, dan dalam pembaruan terpisah terjadi lagi serangan malware yang lebih canggih

Ringkasan insiden

  • Insiden dimulai ketika lebih dari 400 paket yang terinfeksi malware ditemukan di repositori kontribusi pengguna AUR untuk pengguna Arch Linux
  • Menjelang akhir hari, pihak Arch Linux menilai semua commit yang terdampak telah ditangani, tetapi jumlah paket yang terdampak meningkat menjadi lebih dari 1.500
  • Insiden ini merupakan insiden keamanan yang memengaruhi banyak perangkat lunak di repositori Arch Linux yang dipelihara pengguna

Perubahan cakupan dampak

  • Dalam pembaruan beberapa jam sebelumnya, sekitar 900 paket diperkirakan telah terinfeksi malware dalam insiden minggu ini
  • Setelah itu, berdasarkan pesan terakhir di thread insiden keamanan, pengembang Arch Linux menghapus semua commit berbahaya yang diketahui
  • Daftar yang dikutip menampilkan jumlah paket yang terdampak malware sebanyak 1.579

Ketidakpastian yang tersisa

  • Daftar yang menampilkan 1.579 paket itu juga diberi keterangan sebagai “daftar yang besar tetapi bukan keseluruhan dari paket yang terdampak”
  • Karena itu, angka yang dipublikasikan menunjukkan besarnya dampak yang telah terkonfirmasi, tetapi daftar itu sendiri belum mencakup seluruh paket

Pembaruan lanjutan

  • Dalam pembaruan terpisah, disebutkan bahwa Arch Linux AUR menghadapi gelombang lain dari serangan malware yang lebih canggih

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Opini Hacker News

  • Penasaran apakah tim AUR pernah menerbitkan postmortem
    Respons kali ini sangat cepat dan mengesankan, tetapi jujur saja tampaknya perlu ada perubahan, baik pada kebijakan AUR maupun wrapper
    Harus ada kemampuan menetapkan usia minimum paket seperti di pnpm, dan paket yatim tidak boleh bisa diadopsi oleh sembarang orang
    Adopsi juga bisa diberi pembatasan laju global sehingga dapat dijadikan sinyal serangan, dan seperti yang dilakukan banyak perusahaan di NPM, pemindaian kerentanan saat publikasi juga diperlukan
    Namun sebagian besar perubahan ini tampaknya lebih merupakan pekerjaan untuk helper packaging dan pihak ketiga daripada maintainer AUR itu sendiri

    • Akan lebih baik jika paket AUR dibagi berdasarkan namespace
      Dengan begitu kepemilikan tidak akan hilang sehingga proses menjadi yatim itu sendiri tidak diperlukan
    • Tidak ada alat resmi untuk mengunduh repositori AUR, jadi bagian itu tergantung cara yang dipakai masing-masing orang
    • Terinspirasi dari pnpm, saya baru-baru ini membuat patch untuk pakku yang menambahkan usia minimum AUR [1]
      [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
      [2] https://github.com/zqqw/pakku
    • Jika adopsi paket yatim terlalu dibatasi, paket yang sebenarnya bisa dipelihara dengan baik juga bisa malah terbengkalai
      Batasan tetap diperlukan, tetapi misalnya dibatasi menjadi 1 adopsi per bulan untuk pengguna yang mendaftar sebelum periode tertentu tampaknya cukup masuk akal
      Lagi pula, hampir tidak ada orang yang menerapkan pembaruan otomatis tanpa peninjauan ke paket AUR yang terpasang secara lokal, jadi permukaan serangannya sebenarnya sudah cukup kecil
    • Pemindaian kerentanan sederhana kemungkinan besar tidak akan menangkap ini
      Inti dari worm miasma justru bahwa tanda tangan dan pola helper berubah terlalu cepat
      Implan berbahaya yang dienkripsi mendekripsi payload dengan kunci AES-128-GCM yang berbeda untuk setiap lokasi GitHub tempat ia diunggah, nama metode dalam kode juga berubah secara dinamis, dan offset simbol terenkripsi pun dicampur serta digunakan ulang
      Karena ini malware polimorfik, ia adalah lawan terburuk bagi alat berbasis signature
      APT28/29 tampaknya sampai taraf tertentu bergantung pada lambatnya Microsoft memblokir otomatis pengguna dan repositori yang dipakai sebagai infrastruktur C2 di GitHub
      Perlu dipikirkan apa arti hal ini bagi strategi keamanan
      Saat Anda sudah bisa memindai signature atau string, Anda sebenarnya sudah berada pada tahap bermain kucing-kucingan dengan botnet yang sepenuhnya otomatis, dan itu tidak bisa dimenangkan
      Selama minggu lalu, tampaknya hanya alat supply chain seperti socket.dev yang mengikuti perubahan implan ini, sementara alat lain bahkan tidak mengenali Miasma dan malah menemukannya lagi sebagai kampanye baru
      Kurang ada tenaga dan toolchain yang mampu merekayasa balik payload secepat laju munculnya adapter baru untuk ekosistem lain setiap 24 jam
      Yang dimaksud sepenuhnya otomatis di sini adalah bahwa di ekosistem paket lain, kredensial curian sudah dipakai bahkan sebelum 48 jam berlalu
      Alamat email dan nama yang sama terus muncul, dan tampaknya itu adalah orang-orang yang kemungkinan besar belum memahami dampak worm yang menyebar sendiri ini
      Misalnya, indikator kompromi yang mencari paket yang bergantung pada bun juga tidak terlalu membantu
      Malware cukup mengunduh ulang dirinya lewat sarana eksternal
      Dalam kampanye PyPI kedua, setelah gelombang pertama dropper berbahaya dari kampanye RedHat ditandai ke maintainer PyPI, mereka beralih ke file WHL terkompresi dan file setup.pth yang dieksekusi otomatis untuk mengunduh dropper
      Kecuali manajer paket di ekosistem-ekosistem ini ditulis ulang dari nol dengan asumsi adanya chroot, sandbox, log jaringan dan domain, serta allowlist per entri, strategi distribusi malware melalui serangan supply chain akan tetap realistis
      Repositori alat mitigasinya ada di [1], dan detail teknisnya ada di tulisan blog [2]
      Ini masalah di semua package manager, termasuk Composer, Rubygems, NPM, PyPI, dan Go yang semuanya terdampak
      Kita perlu mendiskusikan dengan lebih terbuka betapa banyak kecerobohan dan kepercayaan eksternal yang ditumpukan ke package manager secara umum, dan ini benar-benar harus berubah
      [1] https://github.com/cookiengineer/antimiasma
      [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

  • Saat wrapper pacman yang bisa langsung menginstal dari AUR mulai bermunculan, itu terasa sangat tidak nyaman
    Saya pernah menginstal sesuatu dari AUR, tetapi untuk sebagian besar hal saya lebih memilih melewati langkah tengah dan langsung ke situs web proyek
    PKGBUILD yang sudah jadi tidak cukup praktis hingga layak menanggung risiko typosquatting atau penyalahgunaan dependensi npm·pip

    • Wrapper seperti yay menampilkan perbedaan PKGBUILD setiap kali pembaruan
      Saat instalasi pertama, Anda memeriksa URL dan melihat apakah skrip instalasi serta lainnya masuk akal, lalu pada pembaruan berikutnya biasanya yang berubah hanya nomor versi dan checksum
      Serangan typosquatting akan terlihat cukup jelas
      Instalasi pertama memang agak rentan, tetapi pergi ke situs web proyek lalu menekan download pada dasarnya sama saja
    • Arch terus dikritik karena elitis atau menghalangi pengguna biasa, tetapi jelas ada keuntungan dari tidak membuat hal berbahaya menjadi mudah
      Hal yang sama juga berlaku di banyak aspek kehidupan
      Setelah memakai Void Linux, saya beralih ke aurutils di Arch untuk pemisahan serupa
      Dengan begitu saya bisa membangun sendiri, dengan mudah memelihara repositori AUR lokal, lalu menginstal dan mengelolanya lewat pacman, sehingga seluruh proses upgrade menjadi lebih baik
    • Kompromi ini tidak bernilai bagi saya
      Alasan saya pindah ke Linux bukan untuk membuang waktu seperti pengguna Windows dengan membuka situs web dan menekan “download” demi memperbarui program
      Namun wrapper pacman yang disebut tadi memang terlihat berisiko
    • AUR dan repositori serupa di distro lain terasa benar-benar menakutkan
      Tutorial yang memakai repositori semacam ini terlalu tersebar luas, sampai-sampai saya merasa seperti orang aneh karena tidak ingin memberi hak root tanpa batas kepada orang asing yang nyaris tidak melalui peer review
      Semua risiko itu diambil hanya untuk memasang satu versi paket yang mungkin tidak perlu diperbarui atau hanya jarang diperbarui

  • Sekilas setelah saya baca, tampaknya mereka memasang atomic-lockfile, js-digest, dan lockfile-js dari npm
    Daftar paket yang terdampak ada di [1]
    Saya tidak langsung menemukan cara memeriksa sistem, jadi saya menjalankan pacman -Qmi untuk mencari informasi terkait paket eksternal dan tanggal
    Hasil keluarannya tinggal dicocokkan dengan daftar paket yang terdampak
    Anda juga bisa mencari file di beberapa lokasi seperti berikut
    grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
    grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
    grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
    Saya tidak tahu apakah paket tersebut menghapus dirinya sendiri setelah dijalankan
    Karena informasi lain tidak terlalu membantu, saya ingin membagikan setidaknya perintah dasar ini
    [1] https://md.archlinux.org/s/SxbqukK6IA

    • Cara yang saya lakukan seperti ini
      Dapatkan daftar paket terpasang yang berasal dari AUR dengan yay: yay -Qam > packages_aur.last
      Unduh daftar dari https://md.archlinux.org/s/SxbqukK6IA#: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
      Lalu jalankan grep -wFf compromised.txt packages_aur.last, maka seharusnya akan keluar paket yang ada di kedua file tersebut, yaitu paket yang pernah terkompromi pada suatu waktu
    • Penyerang menggunakan setidaknya tiga dependensi Node, jadi memeriksa hanya atomic-lockfile saja tidak cukup
      js-digest dan lockfile-js juga dipakai, dan pada suatu titik mereka beralih dari npm ke bun
    • Ini juga layak dijadikan referensi: https://github.com/lenucksi/aur-malware-check
    • Lucunya, bahkan dalam situasi mencoba menyisipkan malware ke Arch Linux AUR, malware itu tetap didistribusikan lewat NPM
      Platform legendaris
    • Saya tidak paham bagaimana emacs-magit bisa terdampak
      Setahu saya tidak ada JavaScript sama sekali

  • Ini lagi-lagi menjadi pengingat yang wajar untuk tidak memasang paket, library, atau aplikasi pihak ketiga secara sembarangan tanpa meninjaunya
    Untungnya kali ini terbatas pada AUR, dan AUR pada dasarnya adalah repositori paket yang bisa diunggah siapa saja; berbeda dari repositori resmi, sudah berkali-kali ada peringatan bahwa peninjauan sebelum instalasi itu wajib
    Alat baris perintah seperti rua memudahkan peninjauan paket sebelum dipasang dari AUR
    Jika Anda melakukan urusan perbankan di komputer yang sama, tidak ada alasan untuk tidak meninjau perangkat lunak yang Anda andalkan
    Menjaga jumlah paket tetap sedikit dan hanya memakai yang dibutuhkan juga membuat proses upgrade jauh lebih sederhana

    • “Meninjau” itu maksudnya bagaimana
      Apakah artinya membaca setiap baris kode sepenuhnya sebelum instalasi
      Bagaimana kalau paketnya biner
      Apakah semua yang dipasang harus dibuatkan build yang reproducible, atau harus pindah ke distro berbasis source
      Melempar tanggung jawab ini ke pengguna bukan solusi yang berkelanjutan
      Ada ruang untuk akal sehat, tetapi menyalahkan pengguna untuk hal ini tetap tidak masuk akal
    • Kedengarannya masuk akal, tetapi pada akhirnya itu saran yang tidak bisa dijalankan; bukan cuma tak berguna, malah merugikan
      Ada jauh lebih banyak kode di dunia daripada yang bisa dibaca seseorang sepanjang hidupnya
      Kemungkinan besar Anda sendiri belum membaca bahkan 1% dari source code yang sedang berjalan di komputer Anda saat ini
      Lalu, apakah Anda berhenti memakai komputer
      Bagaimana Anda bisa memercayai apa yang terjadi di dalamnya
    • Saya rasa sikap “wajib tinjau sebelum instalasi” perlu dievaluasi ulang
      Para pengembang Arch Linux melakukan pekerjaan yang luar biasa dan saya pribadi berterima kasih, tetapi di masa ketika serangan rantai pasok meningkat seperti sekarang, rasanya peringatan kepada pengguna saja sudah lama mencapai batasnya
      Solusi mudah tidak terlihat, tetapi kontrol seperti peninjauan sejawat sebelum publikasi atau masa tunggu mungkin bisa sedikit meredakan masalah
    • AUR sejak lama dipuji sebagai salah satu keunggulan besar Arch, tetapi kenyamanan itu memang ada harganya
      Situasi di mana paket bisa ditandai sebagai yatim, lalu setelah menunggu 2 minggu penanggung jawab asli tidak merespons karena sedang liburan, penyerang bisa ditetapkan sebagai maintainer dan merilis pembaruan berbahaya, itu benar-benar tidak masuk akal
    • Saya melihat ini sebagai contoh kuat yang mendukung kombinasi file sistem yang immutable, instalasi lokal pengguna secara default, dan pemberian hak akses minimum saja kepada komponen serta program
      Distro immutable, Wayland, dan Flatpak memang sudah menyediakan sebagian bagiannya, tetapi masih ada celah penting yang tersisa
      Masalah terbesarnya adalah sandboxing terikat pada format paket, dan menurut saya itu adalah kekeliruan
      Sandboxing dan hak akses seharusnya menjadi fitur di tingkat sistem agar biner arbitrer pun tidak mudah lolos dari celah
      Walau tidak menyelesaikan masalah sepenuhnya, ini bisa sangat mengurangi cakupan kerusakan dan membuat pengguna distro menjadi target yang kurang menarik

  • Bagi yang khawatir, saya menemukan repositori yang mengumpulkan skrip terbaru dan daftar paket untuk membantu memeriksa apakah ada infeksi: https://github.com/lenucksi/aur-malware-check

    • Saya juga memberikan daftar yang sama (https://md.archlinux.org/s/SxbqukK6IA) ke Claude untuk melakukan pemeriksaan malware, dan hasilnya pada dasarnya menjalankan verifikasi yang sama seperti yang dilakukan skrip ini
      Salah satu dari keduanya tampaknya sudah cukup

  • Saya bukan pengguna Arch Linux, tetapi cukup sering memakai NodeJS, dan di sana juga cukup sering terjadi serangan serupa
    Akhir-akhir ini saya jadi penasaran, sebenarnya di mana manajemen paket dilakukan dengan benar dan aman

    • AUR berbasis dukungan pengguna, jadi malware kadang tercampur ke dalam paket
      Skalanya memang tidak sebesar kali ini, tetapi sejak awal sudah jelas tidak aman, dan peringatan risiko ada di mana-mana
    • Distro Linux menanganinya dengan baik
      Semuanya punya pengelola yang meninjau paket dan bertanggung jawab atasnya
      Arch Linux juga sama
      Sifat AUR yang pada dasarnya tidak tepercaya selalu dinyatakan secara eksplisit di Arch Wiki dan budaya sekitarnya, dan ini berbeda dari manajer paket bahasa pemrograman seperti npm atau pip
    • Kalau tidak memakai AUR, Arch baik-baik saja
      Kalau memakai AUR, semuanya harus diperiksa
      Kebanyakan distro juga baik-baik saja, dan distro besar punya rekam jejak yang cukup bagus
    • Sepertinya ada sesuatu di ekosistem Node yang membuatnya sangat rentan
      Mungkin karena budaya DRY yang berlebihan, atau mungkin karena alasan lain
      Dari semua yang pernah saya pakai, saya belum pernah melihat mimpi buruk dependency tree pada tingkat yang sebanding

  • Di AUR ada 15 ribu paket yatim
    Pagi ini saya mengurutkan berdasarkan popularitas, lalu mengadopsi dan membangun 3 paket yang hampir tidak pernah diperbarui
    Kalau Anda memakai paket yatim, mungkin layak dipertimbangkan untuk mengadopsinya sendiri sebelum diambil orang jahat

  • Bisa jadi saya salah, tetapi situasi kali ini tampak seperti sinyal meningkatnya adopsi Linux desktop

  • Saya belum pernah membutuhkan AUR
    Jika butuh paket yang tidak ada di repositori resmi, saya membangunnya sendiri, atau kalau ada rilis biner saya unduh itu
    Dengan cara ini, saat build tidak perlu memakai root, dan program bisa diinstal secara lokal untuk satu pengguna, jadi untuk kebanyakan penggunaan desktop justru ini pendekatan yang lebih cocok
    Setidaknya, dibanding jalur pengembang → pengguna, ada satu tahap kemungkinan penyisipan malware yang berkurang, yaitu menjadi pengembang → pemelihara → pengguna

    • makepkg secara aktif menolak dijalankan sebagai root
      Kecuali sengaja diakali dengan cara seperti env EUID=123 makepkg ..., itu tidak akan berjalan sebagai root
      Namun akan bagus kalau pacman mendukung instalasi tingkat pengguna
      Saat ini ia menolak instalasi jika bukan root, meski bisa diakali dengan namespace pengguna yang memetakan dirinya sebagai root

  • Saya paham bahwa kali ini yang terlibat adalah AUR
    Terlepas ini AUR atau bukan, akan bagus kalau ada yang membagikan langkah-langkah apa saja yang mereka lakukan saat memasang paket, dan bagaimana mereka memastikan paket serta dependensi yang akan dipasang bukan malware
    Setelah memasang paket berbahaya, rasanya memang sangat sulit untuk benar-benar memulihkannya