Arch Linux, kötü amaçlı yazılım olayının artık kontrol altına alındığını düşünüyor: 1.500'den fazla paket etkilendi

 (phoronix.com/news)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Arch Linux'un AUR kullanıcı katkı deposunda kötü amaçlı yazılımla enfekte paketlerin sayısı önce 400'ün üzerinde olarak doğrulandı, ardından nihai olarak 1.500'ün üzerine çıktı
  • Birkaç saat önceki güncellemede bu haftaki olaydan etkilenen paket sayısının yaklaşık 900 olduğu belirtilmişti
  • Ardından Arch Linux geliştiricileri tespit ettikleri tüm kötü amaçlı commit'leri kaldırdı ve etkilenen paket sayısı 1.579 olarak hesaplandı
  • 1.579'luk liste de etkilenen paketlerin büyük ama tam olmayan bir listesi olarak işaretlendiğinden toplam kapsam daha geniş olabilir
  • Kullanıcılar tarafından sürdürülen depodaki çok sayıda yazılım bu güvenlik olayından etkilendi ve ayrı bir güncellemede daha sofistike bir kötü amaçlı yazılım saldırısının yeniden yaşandığı belirtildi

Olayın özeti

  • Arch Linux kullanıcılarına yönelik AUR kullanıcı katkı deposunda kötü amaçlı yazılımla enfekte 400'den fazla paketin bulunmasıyla olay başladı
  • Günün sonuna doğru Arch Linux tarafı etkilenen commit'lerin tamamının işlendiğini düşündü, ancak etkilenen paket sayısı 1.500'ün üzerine çıktı
  • Bu olay, kullanıcılar tarafından sürdürülen Arch Linux deposundaki çok sayıda yazılımı etkileyen bir güvenlik olayıydı

Etki kapsamındaki değişim

  • Birkaç saat önceki güncellemede bu haftaki olayda yaklaşık 900 paketin kötü amaçlı yazılımdan etkilendiği belirtilmişti
  • Sonrasında güvenlik olayı başlığındaki son mesaja göre Arch Linux geliştiricileri bilinen tüm kötü amaçlı commit'leri kaldırdı
  • Alıntılanan listede kötü amaçlı yazılımdan etkilenen paket sayısı 1.579 olarak gösterildi

Kalan belirsizlikler

  • 1.579 paketin yer aldığı liste de “etkilenen paketlerin büyük ama tam olmayan bir listesi” olarak işaretlendi
  • Bu nedenle açıklanan sayı, doğrulanmış büyük ölçekli etkiyi gösterse de listenin kendisi tüm paketleri kapsamıyor olabilir

Takip güncellemesi

  • Ayrı bir güncellemede Arch Linux AUR'un daha sofistike hale gelmiş kötü amaçlı yazılım saldırılarının bir başka dalgasıyla karşı karşıya kaldığı belirtildi

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • AUR ekibinin hiç olay sonrası analiz yayımlayıp yayımlamadığını merak ediyorum
    Bu müdahale etkileyici derecede hızlıydı ama açıkçası gerek AUR politikalarında gerek wrapper tarafında değişiklik gerekiyor gibi görünüyor
    pnpm gibi minimum paket yaşı ayarlanabilmeli ve sahipsiz paketler herkes tarafından sahiplenilememeli
    Sahiplenmeye genel bir hız sınırı konulup bu da saldırı sinyali olarak kullanılabilir; ayrıca NPM’de birçok şirketin yaptığı gibi yayımlama anında güvenlik açığı taraması da gerekli
    Yine de bu değişikliklerin çoğu, AUR bakımcılarından çok paketleme yardımcıları ve üçüncü tarafların yapması gereken işler gibi duruyor

    • AUR paketlerini isim alanlarına ayırmak daha iyi olurdu
      Böylece sahiplik ortadan kaybolmaz ve sahipsiz bırakma sürecinin kendisine gerek kalmaz
    • AUR deposunu indirmek için resmî bir araç yok; dolayısıyla o kısım herkesin kullandığı yönteme bağlı
    • pnpm’den ilham alarak pakku için minimum AUR yaşı ekleyen bir yama [1] yakın zamanda hazırladım
      [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
      [2] https://github.com/zqqw/pakku
    • Sahipsiz paketlerin sahiplenilmesini fazla kısıtlamak, düzgün biçimde bakım alabilecek olanların da ortada kalmasına yol açabilir
      Bir sınır gerekli ama örneğin belli bir süreden önce kayıt olmuş kullanıcılara ayda 1 sahiplenme hakkı vermek makul görünüyor
      Zaten yerelde kurulu AUR paketlerine otomatik ve gözden geçirilmemiş güncellemeleri uygulayan pek kimse yoktur; dolayısıyla saldırı yüzeyi zaten epey küçük
    • Basit bir güvenlik açığı taraması muhtemelen bunu yakalayamazdı
      miasma solucanının özü, imza ve yardımcı yaklaşımının çok hızlı değişmesi zaten
      Şifrelenmiş kötü amaçlı implant, yüklenen her GitHub konumu için değişen bir AES-128-GCM anahtarıyla payload’u çözüyor; koddaki metot adları da dinamik olarak değişiyor ve şifrelenmiş sembol ofsetleri de karıştırılıp yeniden kullanılıyor
      Bu, imza tabanlı araçlar için en kötü türden bir polimorfik kötü amaçlı yazılım
      APT28/29’un, GitHub’da C2 altyapısı olarak kullanılan kullanıcı ve depoları Microsoft’un otomatik engellemede yavaş kalmasına bir ölçüde güvendiği görülüyor
      Bunun güvenlik stratejisi açısından ne anlama geldiğini düşünmek gerekiyor
      İmzaları ya da dizeleri tarayabildiğiniz noktada zaten tamamen otomatikleşmiş bir botnet’le kedi-fare oyununa girmiş oluyorsunuz ve bunu kazanamazsınız
      Geçen hafta boyunca bu implant değişimini takip eden tedarik zinciri aracı yalnızca socket.dev gibiydi; diğer araçlar ise Miasma’dan habersiz şekilde bunu yeni bir kampanya olarak yeniden keşfetti
      Yeni ekosistem adaptörlerinin 24 saatte bir çıktığı hızda payload’u tersine mühendislikle çözebilecek insan gücü ve araç zinciri yoktu
      Buradaki tam otomasyon, başka paket ekosistemlerinde 48 saat bile geçmeden çalınmış kimlik bilgilerinin zaten kullanılmaya başlanmış olması demek
      E-posta adresleri ve isimler tekrar tekrar ortaya çıkıyor ama bunlar büyük olasılıkla bu kendini yayan solucanın etkisini anlamamış kişiler
      Örneğin bun’a bağımlı paketleri arayan uzlaşma göstergeleri de pek işe yaramıyor
      Kötü amaçlı yazılım, dışarıdan başka bir yöntemle yeniden indirilebilir
      İkinci PyPI kampanyasında, RedHat kampanyasının ilk kötü amaçlı dropper dalgası PyPI bakımcılarının dikkatine sunulduktan sonra, sıkıştırılmış WHL dosyaları ve otomatik çalışan setup.pth dosyalarıyla dropper indirmeye geçildi
      Bu ekosistemlerin paket yöneticileri, chroot, sandbox, ağ ve alan adı logları ile öğe bazlı izin listelerini temel alacak şekilde baştan yeniden yazılmadıkça, tedarik zinciri saldırıları üzerinden kötü amaçlı yazılım dağıtma stratejisi gerçekçi olmaya devam edecek
      Hafifletme araç deposu [1], teknik ayrıntılar ise blog yazısında [2] yer alıyor
      Composer, Rubygems, NPM, PyPI ve Go’nun da etkilenmesi gibi, bu tüm paket yöneticilerini kapsayan bir sorun
      Paket yöneticilerinin geneline ne kadar çok özensizlik ve dış güven yüklediğimizi daha açık biçimde tartışmamız gerekiyor; bunun gerçekten değişmesi lazım
      [1] https://github.com/cookiengineer/antimiasma
      [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

  • AUR’dan doğrudan kurulabilen pacman wrapper’ları çıkmaya başladığında bundan gerçekten rahatsız olmuştum
    AUR’dan bir şeyler kurduğum oldu ama çoğu zaman ara adımları atlayıp doğrudan projenin web sitesine gitmeyi tercih ediyorum
    Hazır PKGBUILD’ler, typo-squatting ya da npm/pip bağımlılıklarının kötüye kullanılması riskini almaya değecek kadar büyük bir kolaylık sağlamıyor

    • yay gibi wrapper’lar her güncellemede PKGBUILD farkını gösteriyor
      İlk kurulumda URL’yi kontrol edip kurulum betiklerinin vb. makul olup olmadığına bakarsınız; sonraki güncellemelerde ise çoğu zaman yalnızca sürüm numarası ve checksum değişir
      Typo-squatting saldırısı oldukça açık biçimde fark edilir
      İlk kurulum biraz daha zayıf nokta ama proje web sitesine gidip indirme düğmesine basma yöntemi de aynı derecede öyle
    • Arch’ın elitist olduğu ya da sıradan kullanıcıları dışladığı yönündeki eleştiriler sürüp gidiyor ama tehlikeli işleri kolaylaştırmamanın net bir avantajı var
      Hayatın başka alanlarında da durum aynı
      Void Linux kullandıktan sonra, Arch’ta da benzer bir ayrım için aurutils’e geçtim
      Doğrudan derleme yapıp yerel AUR deposunu kolayca koruyabiliyorum ve pacman ile kurup yönetebildiğim için genel yükseltme süreci daha iyi hale geliyor
    • Bu ödünleşim benim için değerli değil
      Linux’a geçme nedenim, Windows kullanıcısı gibi web sitelerine gidip “download” düğmesine basarak program güncellemelerine zaman harcamak değildi
      Yine de adı geçen pacman wrapper’ları tehlikeli görünüyor
    • AUR ve diğer dağıtımlardaki benzer depolar gerçekten ürkütücü geliyor
      Bu tür depoları kullanan eğitimler o kadar yaygın ki, neredeyse hiç akran incelemesinden geçmemiş yabancılara süresiz root yetkisi vermek istemeyen ben tuhaf biriymişim gibi hissettiriyor
      Sırf güncelleme gerektirmeyen ya da nadiren güncellenen bir paketin tek bir sürümünü kurmak için böyle bir riski göze almış oluyorsunuz

  • Hızlıca okuyunca npm üzerinden atomic-lockfile, js-digest, lockfile-js kurulmuş gibi görünüyor
    Etkilenen paketlerin listesi [1]'de var
    Sistemi kontrol etmenin doğrudan bir yolunu hemen bulamadığım için, harici paketler ve tarihle ilgili bilgileri aramak amacıyla pacman -Qmi çalıştırdım
    Çıktıyı etkilenen paketler listesiyle karşılaştırabilirsiniz
    Ayrıca çeşitli konumlarda aşağıdaki gibi dosya araması yapabilirsiniz
    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
    Çalıştıktan sonra paketin kendisini silip silmediğini bilmiyorum
    Diğer bilgiler pek yardımcı olmadığı için, en azından temel komutları paylaşmak istedim
    [1] https://md.archlinux.org/s/SxbqukK6IA

    • Benim yaptığım yöntem şöyleydi
      AUR'den gelen kurulu paketlerin listesini yay ile aldım: yay -Qam > packages_aur.last
      Listeyi https://md.archlinux.org/s/SxbqukK6IA# adresinden indirdim: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
      Sonra grep -wFf compromised.txt packages_aur.last çalıştırırsanız, iki dosyada da bulunan, yani bir noktada bozulmuş olan paketler çıkacaktır
    • Saldırgan en az üç Node bağımlılığı kullandığı için yalnızca atomic-lockfile kontrol etmek yeterli değil
      js-digest ve lockfile-js de kullanıldı, ayrıca bir noktada npm yerine bun'a geçildi
    • Şu da faydalı olabilir: https://github.com/lenucksi/aur-malware-check
    • Arch Linux AUR'ye kötü amaçlı yazılım sokmaya çalışılan bir durumda bile kötü amaçlı yazılımın hâlâ NPM üzerinden dağıtılması komik
      Efsanevi bir platform
    • emacs-magit'in nasıl etkilendiğini anlamıyorum
      Bildiğim kadarıyla hiç JavaScript yok

  • Her zamanki gibi, incelemeden rastgele üçüncü taraf paketleri, kütüphaneleri ve uygulamaları kurmamak gerektiğini hatırlatan adil bir uyarı
    Neyse ki bu olay AUR ile sınırlıydı ve AUR, fiilen herkesin paket yükleyebildiği bir depo; kurulumdan önce inceleme gerektiği, resmi depoların aksine, defalarca uyarılmış bir şey
    rua ve benzeri komut satırı araçları, AUR'den kurmadan önce paketleri incelemeyi kolaylaştırıyor
    Aynı bilgisayarda bankacılık işi yapıyorsanız, bağımlı olduğunuz yazılımları incelememek için bir mazeretiniz yok
    Paket sayısını düşük tutup yalnızca ihtiyacınız olanı kullanırsanız yükseltmeler de çok daha basit olur

    • “İnceleme”yi tam olarak nasıl yapmamız bekleniyor
      Kurmadan önce kodun her satırını tek tek okumamız mı gerekiyor
      İkili paketse ne olacak
      Kurduğunuz her şey için yeniden üretilebilir derleme mi yapmanız bekleniyor, yoksa kaynak tabanlı bir dağıtıma mı geçmelisiniz
      Bu sorumluluğu kullanıcıya yıkmak sürdürülebilir bir çözüm değil
      Sağduyunun bir yeri olabilir, ama bunu kullanıcı suçuymuş gibi göstermek mantıklı değil
    • Kulağa makul gelse de sonunda uygulanamaz bir tavsiye olduğu için, faydasız olmanın ötesinde zararlı bile olabilir
      Dünyada, tek bir insanın ömrü boyunca okuyabileceğinden çok daha fazla kod var
      Muhtemelen siz de şu anda kendi bilgisayarınızda çalışan kaynak kodunun %1'ini bile okumamışsınızdır
      Peki o zaman bilgisayar kullanmayı bıraktınız mı
      İçinde olan bitene nasıl güvenebilirsiniz
    • “Kurulumdan önce mutlaka inceleyin” yaklaşımının yeniden değerlendirilmesi gerektiğini düşünüyorum
      Arch Linux geliştiricileri harika bir iş çıkarıyor ve kişisel olarak minnettarım, ama tedarik zinciri saldırılarının bu kadar arttığı günümüzde kullanıcı uyarılarının sınırına çoktan gelindiğini hissediyorum
      Kolay bir çözüm görünmüyor, ancak yayımlamadan önce akran incelemesi veya bekleme süresi gibi kontroller sorunu bir ölçüde hafifletebilir
    • AUR uzun zamandır Arch'ın büyük bir avantajı olarak övülüyordu, ancak bu rahatlığın bir bedeli vardı
      Bir paketi yetim olarak işaretleyip 2 hafta bekledikten sonra, asıl bakımcısı tatilde olduğu için yanıt veremezse saldırganın bakımcı olarak atanıp kötü niyetli bir güncelleme yayımlayabilmesi saçma
    • Bunun, değiştirilemez sistem dosyaları, varsayılan kullanıcı yerel kurulumları ve bileşenlerle programlara yalnızca en az yetki verilmesi kombinasyonunu güçlü biçimde destekleyen bir örnek olduğunu düşünüyorum
      Değiştirilemez dağıtımlar, Wayland ve Flatpak bunun bazı parçalarını sunuyor, ama önemli açıklar hâlâ var
      En büyük sorun, sandboxing'in paket biçimine bağlı olması; bence bu bir hata
      Sandboxing ve erişim izinleri sistem düzeyi özellikler olmalı ki rastgele ikili dosyalar boşluklardan kolayca sıyrılamasın
      Bu sorunu tamamen çözmese bile etki alanını büyük ölçüde azaltabilir ve dağıtım kullanıcılarını daha az cazip hedefler hâline getirebilir

  • Endişelenenler için, enfekte olup olmadığını kontrol etmeye yardımcı olacak güncel betikleri ve paket listesini toplayan bir depo buldum: https://github.com/lenucksi/aur-malware-check

    • Aynı listeyi (https://md.archlinux.org/s/SxbqukK6IA) Claude'a verip kötü amaçlı yazılım kontrolü yaptırdım; bu betiğin yaptığıyla özünde aynı doğrulamayı yaptı
      İkisinden biri de yeterli olacaktır

  • Arch Linux kullanıcısı değilim ama NodeJS’yi çok kullanıyorum; burada da benzer saldırılar sık yaşanıyor
    Bu günlerde paket yönetimini düzgün ve güvenli yapan yerin neresi olduğunu merak ediyorum

    • AUR, kullanıcı destekli bir yapı olduğu için kötü amaçlı yazılımlar bazen paketlerin arasına karışıyor
      Bu seferki kadar büyük ölçekli olmasa da, baştan beri güvenli olmadığı açıktı ve pek çok yerde risk uyarıları vardı
    • Linux dağıtımları bu işi iyi yapıyor
      Hepsinde paketleri inceleyen ve sorumluluğunu üstlenen bakımcılar var
      Arch Linux da buna dahil
      AUR’un özünde güvenilmez oluşu, Arch Wiki’de ve çevresindeki kültürde hep açıkça belirtiliyordu; npm veya pip gibi programlama dili paket yöneticilerinden farklı
    • AUR kullanmıyorsanız Arch sorun değil
      AUR kullanıyorsanız her şeyi kontrol etmeniz gerekir
      Dağıtımların çoğu da sorun değil ve büyük dağıtımların oldukça iyi bir geçmişi var
    • Node ekosisteminde onu özellikle kırılgan hâle getiren bir şey var gibi görünüyor
      Bunun nedeni aşırı DRY kültürü olabilir ya da başka bir şey
      Benim kullandıklarım arasında buna benzer düzeyde bir bağımlılık ağacı kâbusu görmedim

  • AUR’da 15 bin yetim paket var
    Bu sabah popülerliğe göre sıralayıp neredeyse hiç güncellenmeyen 3 tanesini sahiplenip derledim
    Yetim paket kullanıyorsanız, kötü niyetli kişiler ele geçirmeden önce kendiniz sahiplenmeyi düşünebilirsiniz

  • Yanılıyor olabilirim ama bu durum, masaüstü Linux benimsenmesindeki artışın bir işareti gibi görünüyor

  • Hiç AUR’a ihtiyaç duymadım
    Resmî depolarda olmayan bir pakete ihtiyacım olursa kendim derliyorum ya da ikili sürüm varsa indiriyorum
    Böyle yapınca derleme sırasında root kullanmak gerekmiyor ve programı yerel olarak tek kullanıcı için kurabiliyorsunuz; bu da çoğu masaüstü kullanım senaryosu için aslında daha uygun bir yöntem
    En azından geliştirici → kullanıcı yoluna kıyasla, geliştirici → bakımcı → kullanıcı şeklindeki ek adımda kötü amaçlı kod ekleme ihtimali ortadan kalkıyor

    • makepkg, root olarak çalıştırıldığında bunu aktif biçimde reddediyor
      Özellikle env EUID=123 makepkg ... gibi bir yolla dolaşmadıkça root olarak çalışmaz
      Yine de pacman’ın kullanıcı düzeyinde kurulumu desteklemesi iyi olurdu
      Şu anda root değilseniz kurulumu reddediyor; kullanıcı ad alanıyla kendinizi root’a eşleyerek bunu aşmak mümkün

  • Bunun bu kez AUR olması anlaşılır
    Ama AUR olsun ya da olmasın, paket kurarken hangi adımlardan geçtiğinizi ve kuracağınız paket ile bağımlılıklarının kötü amaçlı yazılım olmadığını nasıl garanti ettiğinizi paylaşmanız iyi olur
    Kötü bir paketi kurduktan sonra gerçekten geri dönmek çok zor görünüyor