Paket AUR terinfeksi infostealer dan rootkit

 (discourse.ifin.network)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Repositori paket AUR memiliki struktur di mana siapa pun dapat mengadopsi paket yang tidak dikelola dan mengajukan perubahan pada PKGBUILD serta file terkait, dan dalam insiden ini ada indikasi lebih dari 408 paket telah terinfeksi
  • Maintainer paket AUR baru menyamar sebagai maintainer tepercaya, mengadopsi paket-paket tersebut, dan maintainer AUR lain sedang melakukan penghapusan paket yang terinfeksi
  • Paket yang terinfeksi pada tahap awal diubah agar menjalankan npm melalui skrip preinstall untuk memasang payload berbahaya atomic-lockfile
  • Infeksi berikutnya memasang js-digest berbahaya dengan Bun, dan NPM telah menghapus paket tersebut
  • Sebagian besar paket jarang digunakan, tetapi cakupannya besar, dan penting karena ini merupakan serangan rantai pasok yang selain mencuri informasi juga menyertakan rootkit eBPF

Status insiden

  • Apa yang terjadi

    • Ada indikasi bahwa maintainer paket AUR baru menyamar sebagai maintainer tepercaya, lalu mengadopsi dan menginfeksi lebih dari 408 paket
    • Setelah kompromi dilaporkan, maintainer AUR lain melakukan pekerjaan untuk menghapus paket yang terinfeksi
    • Per 2026-06-12T17:30:00Z, maintainer AUR melaporkan bahwa semua commit berbahaya telah dihapus
    • Maintainer AUR memutuskan untuk menerapkan kontrol dan pembatasan pada beberapa fitur, termasuk fitur adopsi paket
    • Arch Linux merilis pengumuman Active AUR malicious packages incident

  • Dependensi berbahaya

    • Serangan ini mencakup setidaknya dua dependensi berbahaya yang terpisah
    • Paket yang terdampak pada tahap awal dimodifikasi agar menggunakan npm melalui skrip preinstall untuk memasang payload berbahaya berupa paket atomic-lockfile
    • Paket premake-git memiliki contoh commit dari perubahan tersebut
    • Infeksi berikutnya menggunakan Bun untuk memasang js-digest berbahaya, dan NPM telah menghapus js-digest
    • Analisis serangan dijelaskan lebih rinci dalam Preliminary analysis of AUR malware

Respons dan indikator kompromi

  • Tindakan yang direkomendasikan

    • Jika tidak menggunakan Arch, Anda bukan target yang terdampak langsung oleh kompromi paket AUR ini
    • Pengguna Arch harus meninjau daftar paket yang terdampak dan memeriksa sistem menggunakan skrip verifikasi paparan
    • aur_check.sh yang ditautkan pada sumber asli adalah versi lama, dan target pemeriksaan terbaru harus mengikuti panduan pada Gist tersebut
    • Jika indikator kompromi ditemukan, sistem harus dipertahankan untuk investigasi forensik yang sesuai
    • Jika paket terinfeksi ditemukan, ikuti prosedur respons insiden standar, ganti semua kredensial, dan pertimbangkan pemasangan ulang Arch
    • Karena kemungkinan adanya rootkit, keandalan sistem tidak lagi dapat dijamin
    • Semua pengguna harus mengambil langkah untuk memblokir lalu lintas Tor keluar pada jaringan

  • Indikator kompromi

    • SHA256 dari executable Linux berbahaya yang tertanam dalam js-digest adalah 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
    • eBPF Maps yang mencurigakan dapat dideteksi dengan bpftool map list
    • Nama map yang mencurigakan antara lain hidden_pids, hidden_names, hidden_inodes

  • Hal tambahan untuk diperiksa

    • Bukan akun maintainer lama yang melakukan commit berbahaya, melainkan akun maintainer yang dikenal ditiru identitasnya
    • Sebagian besar paket jarang digunakan, tetapi cakupan infeksi yang melebihi 408 paket sangat besar
    • Serangan rantai pasok yang selain mencuri informasi juga menyertakan rootkit eBPF adalah kasus yang jarang terjadi
    • Halaman Socket.dev untuk atomic-lockfile menunjukkan jumlah unduhan paket NPM berbahaya itu sebanyak 134 kali
    • Paket NPM tersebut dikelola oleh pengguna herbsobering
    • Jika mencari nama pengguna herbsobering di GitHub, ada sebuah image container tunggal yang tampak seperti alat reverse shell/proxy, yaitu herbsobering430
    • Repositori paket AUR memungkinkan siapa pun mengadopsi paket ketika paket tersebut ditandai tidak dikelola, lalu mengajukan perubahan pada PKGBUILD dan file terkait
    • Mencari dan mengadopsi paket yang ditinggalkan secara otomatis bukan hal yang jarang, dan latar belakang terkait tersedia di thread Mastodon

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Harus diterima bahwa AUR hanyalah kumpulan PKGBUILD buatan pengguna
    Sumber dari semua PKGBUILD yang dipasang dari AUR wajib ditinjau, dan pembaruan pun tidak terkecuali. Ini adalah asumsi yang sudah dibahas terus selama lebih dari 10 tahun, dan itulah juga alasan tidak ada helper AUR resmi seperti yay
    Banyak juga keluhan bahwa Arch Linux itu elitis, tetapi secara realistis ini adalah distro untuk orang yang tahu apa yang mereka lakukan dan tidak ingin dituntun di setiap langkah. Itu juga berarti jika Anda memasang paket AUR acak lalu merusak atau mengkompromikan sistem Anda, itu menjadi tanggung jawab Anda sendiri
    Namun, era membiarkan siapa pun mengambil alih paket AUR mungkin akan berakhir. Hanya dari biaya untuk membalikkan paket yang terdampak setiap kali saja sudah terlalu besar. Alternatifnya, meninjau semua permintaan pengambilalihan terlalu membebani, dan tidak ada jaminan itu akan membantu setiap saat

    • Jika semua sumber PKGBUILD yang dipasang dari AUR harus ditinjau, bukankah hal yang sama juga berlaku untuk ekstensi browser, ekstensi VSCode, paket NuGet, crate Cargo, paket Python, paket npm, dan sebagainya?
      Saya rasa iya, kecuali itu tidak dijalankan di tempat yang punya akses internet atau hanya mengakses hal-hal yang tidak masalah jika dipublikasikan
      Mungkin bukan di AUR, tetapi ekosistem lain secara teori bisa diperbaiki lewat model izin atau sandboxing. Ekstensi browser sudah punya opsi seperti itu, tetapi pengguna “umum” hampir tidak memakainya
      Sayangnya, 99,99% orang tidak bisa meninjau semuanya atau tidak punya waktu untuk itu. Paket distro dengan maintainer tepercaya, atau tempat seperti iOS App Store yang punya izin dan tingkat peninjauan tertentu, tampak paling aman
    • Sulit melihat ini sebagai solusi yang nyata. Alur umum serangan seperti ini adalah menyembunyikan payload di suatu tempat dalam dependensi
      Kasus ini agak tidak biasa karena PKGBUILD-nya dengan sangat ceroboh melakukan npm install. Sekarang hampir semua repositori paket di luar AUR juga punya masalah yang sama, dan mengaudit seluruh rantai dependensi secara manual itu tidak realistis
      Tentu saja saya juga tidak punya solusinya
    • Mengira bahkan sebagian kecil pengguna benar-benar melakukan ini adalah pandangan yang sangat tidak nyambung dengan kenyataan
    • Saya bertanya-tanya seberapa berbedanya fakta bahwa AUR adalah kumpulan PKGBUILD buatan pengguna dibandingkan ekosistem PyPI, npm, atau seluruh Docker Hub
      Orang mematikan SELinux, --privileged mematikan seccomp dan AppArmor, dan CVE untuk pelarian sandbox juga ada
    • Fakta bahwa siapa pun bisa mengambil alih paket AUR seharusnya memang tidak pernah ada sejak awal
      Pada akhirnya saya berharap strukturnya menjadi seperti username/packagename-bin|git. Dengan begitu akan jauh lebih jelas apa yang sebenarnya dipasang orang dan dari siapa

  • Kampanye ini masih berlangsung. Barusan saya menerima email bahwa salah satu paket lama saya diambil alih; paket itu sudah bertahun-tahun tidak berfungsi dan sudah lama menjadi paket yatim. Tepat setelah pengambilalihan, commit berbahaya diunggah
    Sekarang tampaknya mereka memakai bun alih-alih npm, jadi solusi sementara berbasis npm kemungkinan tidak efektif
    https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

    • Pada titik ini saya jadi bertanya-tanya apakah konsep pengambilalihan paket yatim itu sendiri sudah rusak dan seharusnya dihapus saja
      Memang akan merepotkan, tetapi mungkin lebih baik jika AUR mewajibkan pengajuan baru alih-alih membiarkan orang mengambil alih paket yang ditinggalkan pihak lain, lalu secara berkala menghapus paket yatim setelah jangka waktu tertentu
    • Saya juga baru saja mendapat pemberitahuan bahwa salah satu paket AUR yang saya pantau berpindah ke orang yang tidak saya kenal hanya karena itu paket yatim

  • Wajar kalau kita harus berhati-hati saat memasang sesuatu dari AUR, dan sebelumnya pun selalu ada paket mencurigakan, yaitu yang dibangun atau dikemas dengan buruk, tetapi melihat penyisipan berbahaya yang aktif tetap mengkhawatirkan
    Menurut saya ada dua masalah besar di AUR. Pertama, ini adalah sisa dari era open source yang sedikit lebih egaliter ketika kode pihak ketiga umumnya masih bisa dipercaya. Kedua, siapa pun bisa mengambil alih paket yatim sambil tetap mewarisi riwayat dan jejak verifikasi yang ada
    Era pertama itu sudah lewat, dan yang kedua bisa dikurangi dengan kontrol yang lebih ketat pada akun AUR atau perlindungan tambahan di sisi helper AUR. Misalnya, menampilkan peringatan besar yang menakutkan jika sebuah paket baru saja berganti pemilik. Tetap saja akan ada orang yang langsung menekan y dan lanjut, tetapi itu tetap lebih baik daripada tidak ada sama sekali
    Atau Anda bisa menghindari helper AUR sepenuhnya dan meninjau serta membangun sendiri paket yang diperlukan langsung dari PKGBUILD

    • Kebijakan pengambilalihan paket tidak pernah masuk akal, bahkan tidak sekali pun
    • Menurut saya helper AUR justru memudahkan integrasi langkah peninjauan ke dalam alur kerja
      Ia secara aktif bertanya agar Anda meninjau, lalu terakhir memberi tahu apakah ada perubahan setelah Anda menerima risikonya
      Namun, sudut pandang bahwa “AUR itu berbahaya” bukan hal baru. Orang yang memakai AUR harus memahami risikonya, dan pada dasarnya ini hanya satu tingkat lebih baik daripada melakukan curl | bash terhadap sesuatu yang ditemukan di StackOverflow

  • Sudah lebih dari 7 jam berlalu sejak kejadian ini, tetapi masih belum ada penyebutan apa pun di archlinux.org atau aur.archlinux.org. Tidak tahu kenapa. AUR seharusnya ditutup sampai ada tindakan yang membuktikan bahwa pengguna mengetahui kejadian ini
    Misalnya, URL API AUR bisa sedikit diubah agar pengguna yay/yaourt terdorong mencari tahu apa yang terjadi. API baru itu harus punya infrastruktur untuk memberi tahu pengguna, dan memastikan mereka telah membaca pesannya sebelum melanjutkan. Ini terutama lebih diperlukan saat bahkan belum jelas apakah semua malware sudah ditemukan
    Selain itu, harus ada basis data commit AUR yang ditarik kembali atau telah dikompromikan, serta mekanisme untuk memperingatkan pengguna jika mereka pernah memasang paket tersebut

    • Suka atau tidak, peringatan itu selalu ada di AUR
      Sudah ada di namanya sendiri, dan materi wiki juga dengan jelas menjelaskan bahwa AUR adalah repositori pengguna dan tidak boleh dipercaya secara membabi buta
      Tertulis persis begitu di kotak merah besar tepat di bagian atas: https://wiki.archlinux.org/title/Arch_User_Repository
      Ada banyak hal di AUR yang memang tidak akan pernah saya pasang, dan saya rasa bukan ide terbaik untuk menyebarkan semuanya ke mailing list
      Saya tidak keberatan dengan ide memperingatkan pengguna yang memasang paket berbahaya, tetapi kemungkinan implementasinya rendah. AUR tidak punya pelacakan instalasi seperti pada alat komersial. Bagaimana bisa tahu siapa yang memasang paket apa? Pada dasarnya AUR lebih mirip buku telepon lokasi paket, dan bahkan tidak meminta login atau informasi autentikasi
      Jadi peringatannya harus datang dari alat yang dapat dijalankan pengguna jika mereka memperhatikan, dan memang menuntut mereka untuk memperhatikan. Contoh: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
    • Tidak seharusnya begitu. Hanya karena sebagian orang tidak menganggap serius saran keamanan dasar, bukan berarti alur kerja semua orang harus dirusak
      Sebenarnya bagaimana API baru yang memberi tahu pengguna dan memastikan mereka sudah membacanya itu akan bekerja? Paket AUR hanyalah repositori git, dan apa yang dilakukan atau tidak dilakukan AUR helper tidak bisa dikendalikan oleh maintainer Arch
    • Saya rasa memang seharusnya ada pengumuman di halaman depan AUR. Secara pribadi, saya juga merasa panduan singkat di situs Arch beserta tautan ke pengumuman halaman AUR akan membantu
      Jika tidak ingin mencantumkan semua paket yang diketahui terdampak, setidaknya harus ada anjuran sebagai posisi resmi bahwa siapa pun yang memakai paket AUR harus membaca semua file dari semua paket yang mereka gunakan
    • Sekarang pengumumannya sudah dipasang: https://archlinux.org/news/active-aur-malicious-packages-inc...
    • Jika angka dari Socket.dev bisa dipercaya, dampaknya untungnya tampak cukup kecil
      Itu juga masuk akal. Saya mengenal beberapa paket dalam daftar terdampak, dan paket-paket itu sudah sangat tua serta proyek upstream-nya juga sudah tidak dipelihara lagi
      Saya tidak tahu total korbannya berapa, tetapi kemungkinan besar tim AUR memiliki angka yang akurat. Saya kira mereka sedang menanganinya sebaik mungkin sesuai tingkat dampaknya

  • Pada akhirnya hal seperti ini memang tak terelakkan, dan jika tidak ada perubahan kemungkinan akan lebih sering terjadi. Saya sangat menyukai sistem PKGBUILD AUR, dan sering memakainya juga saat menulis sendiri
    Masalah yang paling serius sekaligus paling mudah diperbaiki adalah bahwa paket yatim dapat diambil alih oleh siapa saja, tetapi fakta itu sama sekali tidak diberitahukan kepada pengguna akhir
    Menghapus paket tidak memberi banyak hasil dibanding usaha yang dibutuhkan, jadi cara optimal untuk melepaskan kendali adalah menjadikannya paket yatim. Menurut saya ini seharusnya kebalikannya. Setidaknya pengguna harus diberi tahu dengan jelas bahwa sebuah paket telah menjadi yatim
    Beban ini mungkin lebih cocok ada di sisi AUR helper seperti paru atau yay, dan saya mendorong agar perubahan seperti itu dilakukan

  • Ada skrip sederhana untuk memindai paket yang terkompromi
    https://cscs.pastes.sh/aurvulntest20260611.sh
    Ini bukan skrip saya, dan mudah dibaca serta dipahami. Jangan pernah langsung mem-pipe skrip ke bash

    • Ada alternatif yang lebih cepat
      comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
      Tidak pernah ada waktu yang buruk untuk belajar comm(1)
    • Ini hanya memeriksa apakah paketnya terpasang, bukan apakah versi yang terpasang itu yang terinfeksi
      Mungkin kalau seperti saya, sudah cukup lama, berbulan-bulan, tidak menjalankan yay -Syu, berarti aman ya? …kan?
      Sial, jangan sampai saya harus memasang ulang Arch. Terakhir kali butuh seminggu
      Pembaruan: archinstall bagus. Saya pulih lagi dalam sekitar 15 menit
    • Tidak ada jaminan bahwa daftar itu lengkap
      Selalu periksa PKGBUILD dan sumbernya. AUR pada dasarnya bukan sesuatu yang layak dipercaya. Malah lebih mengejutkan kalau kompromi seperti ini tidak terjadi lebih awal
    • pacman mendukung locale tanggal, jadi cara mencari 9 Jun hanya akan berfungsi pada locale Inggris atau locale lain yang memakai format serupa
      Setelah saya perbaiki agar sesuai dengan lingkungan saya, jd-gui ikut terdeteksi, tetapi sebenarnya saya memasang jd-gui-bin sekitar dua jam sebelum kompromi terjadi. Sepertinya saya beruntung karena malam itu saya malas menunggu kompilasi sumber dan memilih paket -bin

  • Komunitas Arch sedang cepat merilis skrip dan alat.
    Saat ini, utilitas terpadu paling mutakhir untuk memeriksa apakah sistem terdampak adalah ini:
    https://github.com/lenucksi/aur-malware-check
    Selain itu, di milis aur-request juga banyak muncul permintaan penghapusan dan peng-yatim-an untuk membatalkan commit berbahaya:
    https://lists.archlinux.org/archives/list/aur-requests@lists...

    • Ini pertanyaan pemula, tapi karena ini bukan berasal dari Arch atau sumber resmi, bagaimana kita bisa tahu bahwa ini dapat dipercaya?
      Ada banyak bagian dalam skrip itu yang sulit dipahami, jadi tidak mudah menilai apakah aman hanya dengan membaca kodenya
      Jadinya berharap ada respons atau solusi dari pihak pengembang resmi Arch
    • Saya suka grafik bintang di bagian bawah README repositorinya
      Itu menyampaikan rasa genting dan pentingnya situasi yang terkait dengan serangan malware besar seperti ini

  • Saya ingat sekitar 10 tahun lalu pernah memasang Mednafen, emulator, di Arch Linux. Programnya tidak berjalan karena tertaut ke library yang tidak ada di sistem saya
    Ternyata maintainer membangun perangkat lunak itu di sistemnya sendiri, dan library yang ada di sistem tersebut ikut terpakai tetapi tidak tercantum sebagai dependensi
    Itu adalah paket resmi yang dikelola, dan saya selalu mengira hal seperti ini dibuat di server build khusus, bukan dibangun oleh relawan acak atau di komputer rumah. Saya tidak tahu apakah Arch masih membangun dengan cara yang sama, tetapi kejadian itu cukup menakutkan sampai membuat saya pindah distribusi

    • Ini tetap bisa terjadi meski memakai pkgctl build. Kasusnya adalah makedepends= secara transitif menarik shared library ke lingkungan build, tetapi depends= tidak mencantumkannya
      Jika dependensi .so terdeteksi memang ada peringatan, tetapi melihat dan menindaklanjutinya tetap menjadi tanggung jawab maintainer
      Dari sisi safety dan keamanan, Arch Linux adalah salah satu pilar yang memimpin proyek reproducible builds, dan untuk cukup banyak bagian sistem operasi, orang bisa memverifikasi secara independen apakah biner tersebut benar-benar dibangun dari source code. Skema audit untuk paket resmi lebih kuat daripada NixOS dan kurang lebih setara dengan Debian:
      https://reproducible.archlinux.org/
      Namun semua ini sama sekali terpisah dari insiden AUR kali ini
    • Ada alat untuk membangun dan memasang paket dari image bersih agar hal seperti ini bisa terdeteksi. Misalnya pkgctl
      Jika Anda maintainer, alat seperti ini wajib dipakai sebelum memublikasikan
    • Sampai relatif baru-baru ini, cara seperti ini memang umum. Debian juga lama beroperasi seperti itu, dan baru sepenuhnya melarangnya pada 2019

  • Apa solusi untuk masalah ini? Haruskah paket seperti ini dipasang di dalam kontainer Docker tanpa akses jaringan? Saya rasa kita tidak boleh berasumsi bahwa ini terbatas hanya pada AUR
    Pada 2026, kita harus curiga terhadap semua sumber perangkat lunak. Apalagi dengan meluasnya vibe coding, dan perangkat lunak tertutup adalah black box sehingga kekacauannya lebih parah daripada open source

    • “App store” yang tidak tepercaya, termasuk AUR dan Flatpak, seharusnya berada di dalam sandbox. Sebagai default atau opsi, rasanya minimal perlu mesin virtual
    • Tidak enak mengatakannya, tetapi orang-orang Qubes OS benar. Solusinya adalah mengisolasi aplikasi secara agresif ke dalam mesin virtual
      Kalau benar-benar pindah, adakah yang tahu seberapa buruk dampaknya terhadap daya tahan baterai?
    • Perlu adopsi SLSA
    • Flatpak

  • Ada kabar lanjutan yang terus muncul
    https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
    Saya pernah memikirkan ide untuk membuat binary canary yang kalau dijalankan hanya mengirim email atau menampilkan notifikasi, lalu menamainya npm
    Pada titik ini, tidak mengganti nama biner npm adalah risiko besar