PKGBUILD enjeksiyonu ile npm tedarik zincirine sızan saldırı
11 Haziran 2026'da, Arch Linux'un AUR deposundaki 400'den fazla paket, terk edilmiş projeleri devralan saldırganlar tarafından sessizce ele geçirildi. Saldırganlar, build scriptlerine npm install atomic-lockfile komutunu enjekte ederek, paket kurulumunun kendisini tehlike vektörüne dönüştürdü. Saldırının asıl hedefi geliştirici kimlik bilgileri: GitHub token'ları, npm yayın anahtarları, SSH key dosyaları, HashiCorp Vault secret'ları, tarayıcı cookie'leri ve Slack, Discord, Teams, Telegram oturum verileri.
Saldırı iki katmanda işliyordu: bir Rust payload'u kimlik bilgilerini toplarken, bir eBPF rootkit kernel seviyesinde process'leri gizliyordu. Normal /proc dosya sistemi ve ps, netstat gibi araçlar çalışan process'leri gösterir. Bu rootkit getdents64() sistem çağrısını kernel katmanında keserek kötü amaçlı process'leri, dosyaları ve network bağlantılarını gizler. Sadece root ayrıcalıklarıyla aktif hale geldiğinde standart güvenlik araçları maskelenmiş bilgi rapor eder.
Sonatype analizine göre, atomic-lockfile npm paketi kaldırılmadan önce haftalık 134 indirme gösteriyordu. Gerçek maruz kalma AUR build sistemindeki otomatik çalışmada meydana geldi. Paket indirildiğinde değil, PKGBUILD'in post-install hook'u tetiklendiğinde kod çalıştı. Bu da npm registry'deki indirme sayısının gerçek etkiyi yansıtmadığı anlamına geliyor.
İlk keşfin ardından 24 saat içinde saldırı ikinci dalgayla genişledi: bu kez bun install js-digest komutu kullanıldı, farklı bir payload binary ile. Etkilenen paket sayısı ilk raporlardaki birkaç düzineden yaklaşık 1.500'e yükseldi.
AUR'ın güven modelindeki zafiyet: terk edilmiş paketler nasıl ele geçirildi
Arch Linux'un AUR deposu, kullanıcı tarafından yönetilen bir paket arşividir. Resmi depodaki paketlerden farklı olarak, AUR paketleri topluluk tarafından bakımı yapılan build scriptleridir. Bir bakımcı projesini terk ettiğinde, başka bir kullanıcı adopt edebilir. Bu mekanizma genellikle sorunsuz işler, ancak yeni bakımcının niyetinin iyi olduğu varsayımına dayanır.
Saldırganlar bu süreci kullanarak uzun süredir terk edilmiş projeleri devraldı. Böylece sıfırdan güven inşa etmelerine gerek kalmadı; zaten sistemde yerleşmiş, kullanıcı sayısı olan paketlerin kontrolünü ele geçirdiler. Sonra git commit meta verilerini sahteleştirerek, değişikliklerin eski meşru bakımcılardan geliyormuş gibi görünmesini sağladılar. PKGBUILD ve .install dosyalarına üç satır eklenen patch büyük fark yaratmadı:
`` post_install() { npm install atomic-lockfile minimist chalk } ``
PKGBUILD standart Arch paket build süreci içinde çalıştığında, bu komutlar build ortamında çalışır. Kurulum script'i build işlemini başlatan kullanıcı haklarıyla koştuğundan, ~/.ssh, ~/.config, tarayıcı profillerindeki dosyalara erişim vardır. Payload bu noktada yerel dosya sistemindeki kimlik bilgilerini tarayıp dışarıya gönderir.
eBPF rootkit neden standart araçlardan kaçabilir
eBPF (extended Berkeley Packet Filter), kernel seviyesinde program çalıştırmayı sağlayan bir Linux özelliğidir. Normalde ağ trafiği analizi, performans izleme ve güvenlik kontrolleri için kullanılır. Bu saldırıda getdents64() sistem çağrısına bir hook eklenerek kötü amaçlı process'ler gizlendi.
getdents64() dizin içindeki dosyaları listeleyen sistem çağrısıdır. /proc dosya sistemindeki her process bir dizin olarak görünür (örneğin /proc/12345). ps, top, htop gibi araçlar bu dizin girdilerini okuyarak çalışan süreçleri raporlar. eBPF rootkit bu sistem çağrısını kernel katmanında keserek belirli process ID'lerini veya dosya adlarını sonuçlardan çıkarır. Böylece standart araçlar kötü amaçlı process'i görmez.
Payload'un gerçekten görünmez olmadığını belirtmek gerekir. Kernel seviyesi izleme araçları (perf, strace, BPF tabanlı güvenlik araçları) bu rootkit'i tespit edebilir. Çoğu kullanıcı ve sistem yöneticisi günlük iş akışında bu araçları kullanmaz. Sonatype'ın raporu, payload'un PTRACE_ATTACH ve PTRACE_SEIZE gibi debugger sinyallerini tespit ettiğini ve analiz ortamlarında davranışını değiştirdiğini belirtiyor.
eBPF rootkit sadece root ayrıcalıklarıyla etkinleşir. AUR paketi kurarken sudo kullanmadıysanız bu katman aktif değildir. Ancak birçok Arch kullanıcısı sistem güncellemesi sırasında build sonucu oluşan paketi sudo pacman -U ile kurar. Bu aşamada root ayrıcalığı sağlanır ve eBPF modülü yüklenebilir.
Geliştirici kimlik bilgileri neden bu kadar cazip hedef
Saldırının odağı genel kullanıcı değil, geliştirici ortamıdır. AUR paketlerini build eden ve kuran kişiler yazılım geliştiricileri, sistem yöneticileri, güvenlik araştırmacıları veya ileri düzey Linux kullanıcılarıdır. Bu profiller GitHub'da kod yayınlama yetkisine, npm'de paket publish etme haklarına, cloud ortamlarına API key erişimine, production sunucularına SSH bağlantısına sahiptir.
Bir GitHub token'ı ele geçiren saldırgan ortak projelere commit yapabilir, yeni release yayınlayabilir, hatta başka bir tedarik zinciri saldırısını tetikleyebilir. Bir npm token binlerce downstream bağımlılığa yayılan kötü amaçlı paket güncellemesine olanak tanır. HashiCorp Vault erişimi production ortamlarındaki secret'ları açığa çıkarır. Slack ve Discord gibi araçlardaki oturum token'ları sosyal mühendislik saldırılarına kapı açar.
Payload analizinde tespit edilen hedefler şunlardır:
- GitHub ve GitLab credential'ları: .git-credentials, .gitconfig, environment variable'larda saklanmış token'lar - SSH key'leri: ~/.ssh altındaki private key dosyaları - npm token'ları: .npmrc dosyasındaki publish key'leri - HashiCorp Vault: ~/.vault-token ve ortam değişkenleri - Tarayıcı cookie'leri: Chrome, Firefox, Edge profil dizinlerindeki session cookie'leri - Messaging platformları: Slack, Discord, Microsoft Teams, Telegram local storage'daki token'lar
Topladığı bilgileri bir remote server'a şifreli kanal üzerinden gönderen binary dosyası, anti-debugging mekanizmaları ve process gizleme rutinleri ile savunma araçlarından kaçmak üzere tasarlanmış.
AUR'ın güven modeli ve yapısal zayıflıklar
Arch Linux kullanıcıları AUR'un "hiçbir güvenlik garantisi olmayan topluluk deposu" olduğunu biliyorlar. Pratikte, uzun süredir bakımı yapılan ve popüler paketler için bir güven varsayımı oluşuyor. Kullanıcılar PKGBUILD dosyasını her güncellemede satır satır incelemiyorlar. Özellikle dependency kurulum satırları (npm, pip, cargo gibi) sıradan görünüyor ve göz ardı ediliyor.
Saldırı AUR'ın mimari zayıflığından ziyade insan merkezli güven modelinin kırılganlığını gösteriyor. Terk edilmiş paketlerin yeniden sahiplenilmesi mekanizması topluluk bakımı için gereklidir. Ancak adopt sürecinde kimlik doğrulama veya niyet değerlendirmesi yoktur. Bir paket 6 ay boyunca güncellenmemişse herhangi bir kullanıcı adopt edebilir ve hemen push yapabilir.
Arch Linux'un yapısı tamamen dağıtık ve self-service olduğundan, resmi depo dışındaki paketleri merkezi olarak taramak mümkün değildir. Resmi depo dışındaki paketler güvenlik denetiminden geçmez. Dolayısıyla bu tür saldırıyı önlemek için yapısal güvenlik mekanizması yoktur; kullanıcı sorumluluğu ve topluluk denetimi esastır.
Sistem temizliği ve recovery adımları
Saldırının keşfinden sonra etkilenen paketler AUR'dan kaldırıldı ve atomic-lockfile npm paketi npm registry'den çıkartıldı. Ancak Sonatype uyarısına göre, paketin kaldırılması sisteminize zaten yüklenmiş payload'u otomatik olarak temizlemez.
İkinci aşama payload'un çalışıp çalışmadığını tespit etmek zordur, çünkü rootkit standart process listelerinde görünmez. Eğer 11 Haziran 2026 ile kısa süre sonra etkilenen AUR paketlerinden birini build edip root yetkileriyle kurulum yaptıysanız, sistem kötü amaçlı binary barındırıyor olabilir.
Tam temizlik için şu adımlar alınmalıdır:
- Kernel seviyesi eBPF programlarını kontrol edin: cat /proc/kallsyms | grep bpf gibi düşük seviye komutlarla eBPF program listesini inceleyebilirsiniz, ancak bu adım uzman yardımını gerektirebilir. - Tüm kimlik bilgilerini döndürün: GitHub, GitLab, npm, cloud provider API key'lerini, SSH key'lerini hemen değiştirin ve eski key'leri iptal edin. Tüm web hizmetlerinden çıkış yapın ve tekrar giriş yaparak session token'larını geçersiz kılın. - Vault ve secret manager'ları sıfırlayın: HashiCorp Vault kullanıyorsanız mevcut token'ları revoke edin ve yeni policy oluşturun. - Messaging platformu oturumlarını kapatın: Slack, Discord, Teams'de tüm cihazlardan çıkış yapın ve iki faktörlü doğrulama ayarlarını gözden geçirin.
Etkilenen sistemin tam yeniden kurulması kesin korunma sağlar, ancak pratik olmayabilir. Eğer kritik production sistemlerine erişim hakkınız varsa yeniden kurulum tercih edilmelidir. Kişisel projelerle sınırlı çalışıyorsanız credential döndürme ve kernel seviyesi tarama yeterli olabilir.
