AUR paketleri bilgi hırsızı ve rootkit ile enfekte edildi

 (discourse.ifin.network)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • AUR paket deposu, bakımı yapılmayan paketlerin herkes tarafından devralınabildiği ve PKGBUILD ile ilgili dosya değişikliklerinin gönderilebildiği bir yapıya sahip; bu olayda 408'den fazla paketin enfekte olduğuna dair bulgular var
  • Yeni bir AUR paket maintainer'ı, güvenilir bir maintainer'ı taklit ederek paketleri devraldı ve diğer AUR maintainer'ları enfekte paketleri kaldırma çalışmalarını yürüttü
  • İlk enfekte paketler, preinstall betiğiyle npm çalıştırarak kötü amaçlı yük olan atomic-lockfile paketini kuracak şekilde değiştirildi
  • Daha sonraki enfeksiyonlarda Bun kullanılarak kötü amaçlı js-digest kuruldu; NPM bu paketi kaldırdı
  • Paketlerin çoğu nadiren kullanılsa da kapsamın geniş olması ve bilgi hırsızlığı davranışına ek olarak eBPF rootkit de içeren bir tedarik zinciri saldırısı olması önemli

Olayın durumu

  • Ne oldu

    • Yeni bir AUR paket maintainer'ının, güvenilir bir maintainer'ı taklit ederek 408'den fazla paketi devralıp enfekte ettiğine dair bulgular var
    • İhlal bildirildikten sonra diğer AUR maintainer'ları enfekte paketleri kaldırma çalışmalarını yürüttü
    • 2026-06-12T17:30:00Z itibarıyla AUR maintainer'ları tüm kötü amaçlı commit'lerin kaldırıldığını bildirdi
    • AUR maintainer'ları, paket devralma özelliği dahil bazı işlevlere kontrol ve kısıtlama uygulamaya karar verdi
    • Arch Linux, Active AUR malicious packages incident duyurusunu yayımladı

  • Kötü amaçlı bağımlılıklar

    • Saldırı en az iki ayrı kötü amaçlı bağımlılık içeriyor
    • İlk etkilenen paketler, preinstall betiğiyle npm kullanarak kötü amaçlı yük olan atomic-lockfile paketini kuracak şekilde değiştirildi
    • premake-git paketinde bu değişikliğin örnek commit'i bulunuyor
    • Daha sonraki enfeksiyonlarda Bun kullanılarak kötü amaçlı js-digest kuruldu ve NPM js-digest paketini kaldırdı
    • Saldırının ayrıntılı analizi Preliminary analysis of AUR malware içinde yer alıyor

Müdahale ve ihlal göstergeleri

  • Önerilen adımlar

    • Arch kullanmıyorsanız bu AUR paket ihlalinden doğrudan etkilenmiyorsunuz
    • Arch kullanıcıları, etkilenen paketler listesini incelemeli ve maruziyet kontrol betiğiyle sistemlerini denetlemeli
    • Asıl metne bağlı aur_check.sh eski bir sürüm; en güncel kontrol yöntemi için ilgili Gist yönergeleri izlenmeli
    • İhlal göstergeleri bulunursa uygun adli inceleme için sistem korunmalı
    • Enfekte paket tespit edilirse olağan ihlal müdahale prosedürleri izlenmeli, tüm kimlik bilgileri değiştirilip Arch'ın yeniden kurulması değerlendirilmelidir
    • Rootkit ihtimali nedeniyle sistemin güvenilirliği artık garanti edilemez
    • Tüm kullanıcılar ağ üzerinde dışa giden Tor trafiğini engelleyecek önlemler almalı

  • İhlal göstergeleri

    • js-digest içine gömülü kötü amaçlı Linux çalıştırılabilir dosyasının SHA256 değeri 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
    • bpftool map list ile şüpheli eBPF Maps tespit edilebilir
    • Şüpheli map adları arasında hidden_pids, hidden_names, hidden_inodes yer alıyor

  • Ek doğrulamalar

    • Kötü amaçlı commit'leri mevcut maintainer hesapları yapmadı; bunun yerine bilinen maintainer hesapları taklit edildi
    • Paketlerin çoğu nadiren kullanılsa da 408'den fazla paketi kapsayan enfeksiyonun kapsamı büyük
    • Bilgi hırsızlığı davranışına ek olarak eBPF rootkit de içeren tedarik zinciri saldırıları nadir görülüyor
    • Socket.dev üzerindeki atomic-lockfile sayfası, kötü amaçlı NPM paketinin 134 indirmeye ulaştığını gösteriyor
    • NPM paketi, herbsobering kullanıcısı tarafından maintain ediliyor
    • GitHub'da herbsobering kullanıcı adı aratıldığında, reverse shell/proxy aracı gibi görünen tek bir container image olan herbsobering430 bulunuyor
    • AUR paket deposunda, bir paket bakımsız olarak işaretlendiğinde herkes bu paketi devralıp PKGBUILD ve ilgili dosyalarda değişiklik gönderebilir
    • Terk edilmiş paketleri otomatik olarak bulup devralma yöntemi nadir değildir; ilgili arka plan Mastodon dizisinde yer alıyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • AUR'un yalnızca kullanıcıların oluşturduğu bir PKGBUILD koleksiyonu olduğunu kabul etmek gerekiyor
    AUR'dan kurduğunuz her PKGBUILD'nin kaynağını mutlaka incelemelisiniz; güncellemeler de bunun istisnası değil. Bu, 10 yıldan uzun süredir sürekli tartışılan bir ön kabul ve yay gibi resmî bir AUR helper'ının olmamasının nedeni de bu
    Arch Linux'un elitist olduğuna dair çok şikâyet var ama pratikte bu, ne yaptığını bilen ve her adımda elinden tutulmasını istemeyen insanlar için bir dağıtım. Rastgele AUR paketleri kurup sisteminizi bozduysanız ya da ele geçirilmesine yol açtıysanız, bu aynı zamanda sizin sorumluluğunuz demek
    Yine de herkesin AUR paketlerini devralabildiği dönem sona erebilir. Her seferinde etkilenen paketleri geri almanın maliyetine bakınca bu çok büyük. Alternatif olarak tüm devralma taleplerini incelemek de fazla yük getirir ve her seferinde işe yarayacağının garantisi yok

    • AUR'dan kurulan tüm PKGBUILD kaynaklarını incelemek gerekiyorsa, aynı şey tarayıcı eklentileri, VSCode eklentileri, NuGet paketleri, Cargo crate'leri, Python paketleri, npm paketleri vb. için de geçerli değil mi diye düşünüyorum
      İnternet erişimi olmayan ya da açığa çıkmasının sorun olmayacağı şeylere erişen yerlerde çalıştırmıyorsanız, bence evet
      AUR için geçerli olmayabilir ama diğer ekosistemler izin modeli veya sandboxing ile teorik olarak iyileştirilebilir. Tarayıcı eklentilerinde böyle seçenekler zaten var ama “ortalama” kullanıcı bunları neredeyse hiç kullanmıyor
      Ne yazık ki insanların %99,99'u her şeyi inceleyemez ya da buna vakit ayıramaz. Güvenilir bakımcılara sahip dağıtım paketleri ya da izinler ve belli ölçüde inceleme bulunan iOS App Store gibi yerler en güvenlisi gibi görünüyor
    • Bunun gerçek bir çözüm olduğunu sanmıyorum. Bu tür saldırıların tipik akışı payload'ı bağımlılıkların bir yerine gizlemek oldu
      Bu olay, PKGBUILD içinde oldukça özensiz biçimde npm install çalıştırılması nedeniyle biraz sıra dışı. Artık AUR dışındaki neredeyse tüm paket depoları da aynı soruna sahip ve tüm bağımlılık zincirini elle denetlemek gerçekçi değil
      Elbette benim de bir çözümüm yok
    • Kullanıcıların küçük bir kısmının bile bunu gerçekten yaptığına inanmak gerçeklikten ciddi biçimde kopuk bir düşünce
    • AUR'un kullanıcı yapımı PKGBUILD koleksiyonu olması, PyPI ekosistemi, npm ya da Docker Hub'ın tamamından ne kadar farklı diye merak ediyorum
      İnsanlar SELinux'u kapatıyor, --privileged seccomp ve AppArmor'u devre dışı bırakıyor, sandbox'tan kaçış CVE'leri de var
    • Herkesin AUR paketlerini devralabilmesi en başta hiç olmaması gereken bir şeydi
      Sonuçta keşke username/packagename-bin|git gibi bir yapıya geçilse. O zaman insanların gerçekte neyi kimden kurduğu çok daha açık olurdu

  • Bu kampanya hâlâ sürüyor. Az önce eski paketlerimden birinin devralındığını söyleyen bir e-posta aldım; yıllardır çalışmıyordu ve bir süredir yetim paketti. Devralındıktan hemen sonra kötü amaçlı commit eklendi
    Görünüşe göre artık npm yerine bun kullanılıyor, bu yüzden npm tabanlı geçici önlemler etkisiz kalabilir
    https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

    • Bu noktada yetim paket devralma kavramının baştan bozuk olup olmadığını, hatta tamamen kaldırılması gerekip gerekmediğini merak ediyorum
      Rahatsız edici olurdu ama AUR'un başka birinin terk ettiği paketin devralınmasına izin vermek yerine yeni gönderim zorunlu kılması ve belli bir süreden sonra yetim paketleri düzenli olarak silmesi belki daha iyi olurdu
    • Ben de az önce izlediğim AUR paketlerinden birinin, yetim paket olduğu gerekçesiyle tanımadığım birine geçtiğine dair bildirim aldım

  • AUR'dan bir şey kurarken dikkatli olmak gerektiği zaten açık ve geçmişte de hatalı derlenen ya da yanlış paketlenen şüpheli paketler hep vardı; ama aktif kötü amaçlı ekleme görmek endişe verici
    Bence AUR'un iki büyük sorunu var. Birincisi, üçüncü taraf koduna genel olarak güvenilebildiği daha eşitlikçi bir açık kaynak döneminden kalma bir miras olması. İkincisi ise yetim paketlerin, mevcut geçmiş ve doğrulama izi aynen korunarak herkes tarafından devralınabilmesi
    İlk dönem zaten kapandı; ikinci sorun ise AUR hesapları üzerinde daha sıkı denetim kurularak veya AUR helper tarafına ek korumalar eklenerek hafifletilebilir. Örneğin yakın zamanda sahibi değişmiş paketler için büyük ve korkutucu bir uyarı gösterilebilir. İnsanların bir kısmı yine sadece y tuşlayıp geçer ama bu, hiç olmamasından iyidir
    Ya da AUR helper'lardan tamamen kaçınıp ihtiyaç duyulan paketi doğrudan PKGBUILD'den inceleyip derlemek de mümkün

    • Paket devralma politikası hiçbir zaman makul olduğu bir döneme sahip olmadı
    • Bence AUR helper'lar tam tersine inceleme adımını iş akışına entegre etmeyi kolaylaştırıyor
      İnceleme yapmanız için aktif biçimde soruyorlar ve son olarak riski kabul ettikten sonra değişiklik olup olmadığını da bildiriyorlar
      Ancak “AUR zararlıdır” bakış açısı yeni değil. AUR kullananların buradaki riskleri anlaması gerekir ve pratikte bu, StackOverflow'da bulunan bir şeyi curl | bash yapmaktan sadece bir kademe daha iyi

  • Bu olayın üzerinden 7 saatten fazla geçti ama archlinux.org ya da aur.archlinux.org üzerinde hâlâ hiçbir açıklama yok. Nedenini anlamıyorum. Kullanıcıların bu olaydan haberdar olduğunu gösteren bir önlem alınana kadar AUR kapatılmalıydı
    Örneğin AUR API URL’si ufakça değiştirilerek yay/yaourt kullanıcılarının neler olduğunu araştırması sağlanabilirdi. Yeni API’de kullanıcıyı bilgilendirecek ve devam etmeden önce mesajı okuduğunu doğrulatacak bir altyapı olmalıydı. Özellikle de tüm kötü amaçlı yazılımların bulunup bulunmadığı bile net değilken bu daha da gerekli
    Ayrıca geri çekilmiş ya da ihlal edilmiş AUR commit’leri için bir veritabanı olmalı ve kullanıcı bu paketleri daha önce kurduysa uyarı verecek bir mekanizma da bulunmalı

    • İyi ya da kötü, AUR’da bu uyarı zaten her zaman var
      Adının içinde bile var ve wiki belgelerinde de AUR’un bir kullanıcı deposu olduğu, körü körüne güvenilmemesi gerektiği açıkça belirtiliyor
      Hemen üst taraftaki büyük kırmızı kutuda aynen yazıyor: https://wiki.archlinux.org/title/Arch_User_Repository
      AUR’da asla kurmayacağım pek çok şey var ve bunların hepsini mailing list’e yaymanın en iyi çözüm olduğunu da düşünmüyorum
      Kötü niyetli paketleri kurmuş kullanıcılara uyarı gönderme fikrine karşı değilim ama uygulanabilirliği düşük. Çünkü AUR’da ticari araçlardaki gibi kurulum takibi yok. Kimin hangi paketi kurduğunu nasıl bileceksiniz? AUR temelde bir paket konum rehberine daha yakın ve giriş ya da kimlik doğrulama bilgisi de istemiyor
      Bu yüzden uyarı, dikkat eden kullanıcının çalıştırabileceği araçlardan gelmeli ve gerçekten dikkat etmesini gerektirmeli. Örn: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
    • Bu yapılmamalı. Bazı insanların temel güvenlik tavsiyelerini ciddiye almaması yüzünden herkesin iş akışı bozulmamalı
      Yeni API’nin kullanıcıyı bilgilendirip okuduğunu doğrulatması tam olarak nasıl işleyecek? AUR paketleri sonuçta sadece git deposu ve AUR helper’ların ne yapıp ne yapmadığını Arch maintainers kontrol edemez
    • AUR ana sayfasında bir duyuru yayınlanması gerektiğini düşünüyorum. Bana kalırsa Arch ana sayfasındaki kısa bir bilgilendirme ve AUR sayfasındaki duyuruya bağlantı da faydalı olurdu
      Bilinen etkilenen paketlerin hepsini listelemek istemiyorlarsa, en azından AUR paketi kullananların kullandıkları tüm paketlerdeki tüm dosyaları okumaları gerektiğinin resmî görüş olarak tavsiye edilmesi gerek
    • Duyuru şimdi yayınlandı: https://archlinux.org/news/active-aur-malicious-packages-inc...
    • Socket.dev’in sayılarına güvenilebiliyorsa etki alanı neyse ki oldukça küçük görünüyor
      Bu bir bakıma mantıklı. Etkilenenler listesindeki bazı paketleri biliyorum; aşırı eski paketler ve upstream projeleri de artık sürdürülmüyor
      Toplam kaç kurban olduğunu bilmiyorum ama AUR ekibinin elinde kesin sayılar olma ihtimali yüksek. Etki düzeyine uygun şekilde ellerinden geleni yapıyorlardır diye düşünüyorum

  • Böyle bir şeyin eninde sonunda kaçınılmaz olduğu belliydi ve bir değişiklik olmazsa daha sık yaşanması muhtemel. AUR PKGBUILD sistemini gerçekten seviyorum ve kendim yazarken de sık kullanıyorum
    En ciddi ama düzeltmesi en kolay sorun, yetim paketlerin herkes tarafından devralınabilmesi ama bunun son kullanıcıya hiç bildirilmemesi
    Paketi sildirtmenin getirisi, harcanan emeğe kıyasla düşük olduğundan, kontrolü bırakmanın en iyi yolu paketi yetim bırakmak oluyor. Bence bunun tersi olmalı. En azından kullanıcı, paketin yetim kaldığını açıkça görebilmeli
    Bu yük belki de daha çok paru ya da yay gibi AUR helper’lara düşüyor olabilir ve böyle bir değişiklik yapmaları teşvik edilmeli

  • İhlal edilmiş paketleri tarayan basit bir script var
    https://cscs.pastes.sh/aurvulntest20260611.sh
    Script bana ait değil ve okuyup anlaması kolay. Script’leri asla doğrudan bash’e pipe etmemek gerekir

    • Daha hızlı bir alternatif de var
      comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
      comm(1) öğrenmek için kötü bir zaman diye bir şey yoktur
    • Bu sadece paketin kurulu olup olmadığını kontrol ediyor; kurulu sürümün enfekte olup olmadığını kontrol etmiyor
      Muhtemelen benim gibi bir süredir, hatta birkaç aydır yay -Syu çalıştırmadıysanız güvendesinizdir, değil mi? …değil mi?
      Kahretsin, beni yeniden Arch kurmak zorunda bırakmayın. Geçen sefer bir haftamı almıştı
      Güncelleme: archinstall iyiymiş. Yaklaşık 15 dakikada yeniden ayağa kalktım
    • O listenin eksiksiz olduğuna dair hiçbir garanti yok
      Her zaman PKGBUILD ve kaynakları kontrol etmek gerekir. AUR genel olarak güvenilecek bir yer değil. Hatta asıl şaşırtıcı olan, böyle bir ihlalin daha önce yaşanmamış olması
    • pacman tarih locale’ini destekliyor, bu yüzden 9 Jun aramak yalnızca İngilizce locale’de ya da benzer tarih biçimi kullanan locale’lerde çalışır
      Kendi ortamıma göre düzelttikten sonra jd-gui eşleşti ama ben aslında ihlalden yaklaşık iki saat önce jd-gui-bin kurmuştum. Sanırım o gece tembellik edip kaynaktan derlemeyi beklemek istemeyerek -bin paketini seçmem sayesinde şanslıydım

  • Arch topluluğu script’leri ve araçları hızla çıkarıyor
    Şu anda bulaşma durumunu kontrol etmek için en güncel birleşik yardımcı araç şu:
    https://github.com/lenucksi/aur-malware-check
    Ayrıca aur-request posta listesinde de kötü niyetli commit’leri geri almak için silme ve yetim bırakma talepleri yoğun şekilde geliyor:
    https://lists.archlinux.org/archives/list/aur-requests@lists...

    • Acemice bir soru ama bu Arch’tan ya da resmi bir kaynaktan gelmiyorsa buna nasıl güvenilebileceğini anlayabiliriz?
      O script’te anlaması zor birçok kısım var, bu yüzden sadece kodu okuyarak güvenli olup olmadığını kolayca değerlendirmek mümkün değil
      Resmi Arch geliştiricilerinden bir tepki ya da çözüm bekleniyor
    • Depodaki README’nin alt kısmındaki yıldız grafiğini beğendim
      Böyle büyük bir zararlı yazılım saldırısına eşlik eden aciliyet ve önemi iyi yansıtıyor

  • Yaklaşık 10 yıl önce Arch Linux’ta emülatör Mednafen’i kurduğumu hatırlıyorum. Program çalışmıyordu çünkü sistemimde olmayan bir kütüphaneye linklenmişti
    Meğer bakımını yapan kişi yazılımı kendi sisteminde derlemiş ve o sistemde bulunan bir kütüphane kullanılmış ama bağımlılıklar arasında belirtilmemiş
    Bu resmi olarak bakımı yapılan bir paketti ve ben bunların her zaman özel build sunucularında üretildiğini sanıyordum; rastgele gönüllülerin ya da ev bilgisayarlarının üzerinde derlendiğini düşünmemiştim. Arch’ın hâlâ aynı şekilde derleme yapıp yapmadığını bilmiyorum ama bu olay beni dağıtım değiştirecek kadar korkutmuştu

    • pkgctl build kullansanız bile bu yaşanabilir. makedepends= geçişli olarak build ortamına paylaşımlı kütüphaneler çekmiş olabilir ama depends= içinde eksik kalmıştır
      .so bağımlılığı tespit edilirse uyarı verilir ama bunu görüp gereğini yapmak bakımcıya kalır
      Güvenlik ve emniyet açısından Arch Linux, reproducible builds projesini ileri taşıyan ana aktörlerden biriydi ve işletim sisteminin kayda değer bir kısmında o ikili dosyaların gerçekten kaynak koddan üretildiği bağımsız olarak doğrulanabiliyor. Resmi paketlerin denetim yapısı NixOS’tan daha güçlü ve Debian’la benzer düzeyde:
      https://reproducible.archlinux.org/
      Yine de tüm bunların bu AUR olayıyla hiçbir ilgisi yok
    • Bunun gibi şeyleri yakalamak için paketi temiz bir imaj içinde derleyip kurmayı deneyebilen araçlar var. Örneğin pkgctl
      Bir bakımcı, yayımlamadan önce bu tür araçları mutlaka kullanmalı
    • Görece yakın zamana kadar bu yaklaşım yaygındı. Debian da uzun süre böyle çalıştı ve bunu ancak 2019’da tamamen yasakladı

  • Bunun çözümü ne? Böyle paketleri ağ erişimi olmayan bir Docker konteyneri içinde mi kurmak gerekiyor? Bunun yalnızca AUR’la sınırlı olduğunu varsaymamak gerektiğini düşünüyorum
    2026’da tüm yazılım kaynaklarından şüphe etmek gerekecek. Özellikle vibe coding yaygınlaşmışken ve kapalı kaynak yazılımlar birer kara kutu olduğu için açık kaynaktan da büyük bir kaos barındırırken

    • Güvenilmeyen “app store” kaynakları, AUR ve Flatpak dahil, bir sandbox içinde olmalı. Varsayılan ya da seçenek olarak en azından bir sanal makine gerekli gibi görünüyor
    • Söylemek istemiyorum ama Qubes OS tarafı haklıydı. Çözüm, uygulamaları sanal makinelerle agresif şekilde izole etmek
      Ciddi ciddi geçmeye kalkarsam pil ömrünün ne kadar kötüleşeceğini bilen var mı?
    • SLSA benimsenmeli
    • Flatpak

  • Konuyla ilgili daha fazla haber çıkıyor
    https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
    Çalıştırıldığında sadece e-posta gönderen ya da bildirim gösteren bir canary binary üretip buna npm deme fikrini düşünmüştüm
    Bu noktada npm ikili dosyasının adını değiştirmemek büyük bir risk