Sahte Laravel Paketleri .env Dosyanızı Hedef Alıyor: Composer Bağımlılıklarını Nasıl Denetlersiniz

Özgün olarak hafiz.dev adresinde yayınlanmıştır.

4 Mart’ta her Laravel geliştiricisinin bilmesi gereken bir şey oldu.

Socket’teki güvenlik araştırmacıları, herhangi bir makinede kurulduğunda sessizce çapraz platform uzaktan erişim trojanı (RAT) dağıtan üç Packagist paketinin (nhattuanbl/lara-helper, nhattuanbl/simple-queue ve nhattuanbl/lara-swagger) bulgularını yayımladı. Paketler oldukça meşru görünüyordu. Yardımcı araçlar. Kuyruk araçları. Swagger entegrasyonu. Bunlar, ikinci kez düşünmeden kurduğunuz şeylerdir.

RAT, bir komut kontrol sunucusuna bağlanır, tam sistem profilini iletir ve talimatları bekler. Windows’ta. macOS’ta. Linux’ta. Umurunda değil. Ve aslında sizi endişelendiren şu: kurulduktan sonra, Laravel uygulamanızla aynı işlemde çalışır, bu da .env dosyanıza tam erişime sahip olduğu anlamına gelir. Veritabanı kimlik bilgileri, Stripe anahtarları, API gizli anahtarları. Tüm bunlar. Bu yazının yazıldığı sırada, paketler Packagist’te hâlâ canlıydı.

Bu bir tedarik zinciri saldırısıdır. Son olmayacak.

Gerçekten Ne Oldu

Saldırı, sıkıcı ve estetik olmayan bir şekilde zekiceydi. Tehdit aktörü, aynı yazar hesabı altında altı paket yayınladı, bunlardan üçü tamamen temizdi. Bu temiz paketler, güven inşa etmek için mevcutti. Bazıları, 2024 yılı ortalarında, birkaç ay önce yayımlandı, böylece hesabın geçmişi oldu.

Sonra kötü niyetli paketler geldi.

nhattuanbl/lara-helper ve nhattuanbl/simple-queue dosyaları, src/helper.php içinde gizli bir yük taşıyordu. Bu dosya, açılış etiketi sonrası sürekli bir hat halinde iletilen 27,000+ bayttan oluşmaktaydı. Bunu okumakta şansınız yok. Kod, üç katmanlı karmaşıklık içeriyor: anlamsız etiketlerle yüzlerce rastgele goto atlaması, hiçbir okunabilir şeyin düz metinde görünmemesi için tüm dizelerin hex veya oktal olarak kodlanması ve rastgele üretilmiş çöp dizeleri gibi değişken adları kullanıyor, örneğin: $riz07 ve BsYhQ().

nhattuanbl/lara-swagger ise hiç kötü niyetli kod içermiyordu. Sadece nhattuanbl/lara-helper'i zorunlu bir Composer bağımlılığı olarak listelemişti. Swagger'ı kur, RAT'ı al.

Aktivasyon mekanizması, bunu Laravel uygulamaları için özellikle kötü hale getiriyor. lara-helper paketinde, paket Composer’ın otomatik keşif özelliği aracılığıyla bir hizmet sağlayıcı kaydediyor. Bu, helper.php'nin her uygulama başlangıcında yüklenmesi anlamına geliyor. Sadece bir kez değil. Her. Başlatmada.

RAT, her 15 saniyede bir C2 bağlantısını tekrar deniyor. Saldırganın sunucusu çevrimdışı olsa bile, zaten enfekte olmuşsunuzdur. Onlar, kodunuza dokunmadan istediği zaman yeni bir ana bilgisayara yöneltebilirler.

Bu süreklilik, onu tipik bir süreliğine kimlik avı girişiminden daha kötü hale getiriyor. Geçmişte ve şimdi sona eren bir ihlal ile uğraşmıyorsunuz. Kapatmadığınız sürece açık kalan bir kapıyla uğraşıyorsunuz.

Adım 1: Şu An Etkilendiniz mi Kontrol Edin

Eğer daha önce paketleri dikkatlice denetlemeden yüklediyseniz, projenizin kök dizininde bunu çalıştırın:

grep -r "nhattuanbl" composer.json composer.lock

Eğer hiçbir şey dönmezse, bu özellikle bu saldırıdan temizsiniz demektir. Ama bu komutu, yalnızca şu an açık olan projeye değil, yönettiğiniz her proje için çalıştırın.

Ayrıca doğrudan vendor dizininizi kontrol edin:

find vendor -name "helper.php" -path "*/nhattuanbl/*"

Eğer bir şey bulursanız, sadece dosyaları silmekle kalmayın. Hizmet sağlayıcı zaten kaydedilmiş ve çalıştırılmış olabilir. Tam bir ihlal durumuyla muhatap olduğunuzu varsayın: .env dosyanızdaki her sırrı döndürün, tüm API anahtarlarını iptal edin ve sunucu günlüklerinizi helper.leuleu.net bağlantısına doğru inceleyin.

Adım 2: composer audit Komutunu Tüm Projelerde Çalıştırın

Çoğu Laravel geliştiricisi hiç composer audit komutunu çalıştırmamıştır. Bu, bu yazıyı okuyan kişilerin en az %70'inin geçerli olduğunu tahmin ediyorum. 2022'de yayımlanan Composer 2.4'ten beri mevcut, fakat çoğu insan bunu hâlâ kullanmıyor.

İşte bu kadar basit:

composer audit

İşte bu kadar. Composer, Packagist Güvenlik Danışmanı API'sini sorgular ve yüklediğiniz paketleri bilinen CVE'ler ve topluluk tarafından rapor edilmiş güvenlik açıklarıyla karşılaştırır. Eğer bir şey yanlışsa, şu şekilde bir çıktı alırsınız:

Found 1 security vulnerability advisory affecting 1 package.
Package: vendor/package-name
CVE: CVE-2024-XXXX
Title: Remote code execution via crafted input
Affected versions: >=2.0.0,

Eğer temizseniz: "No security vulnerability advisories found" ve çıkış kodu 0'dır.

Bir şeyi anlamak önemlidir: composer audit yalnızca bilinen açığı olan paketleri kapsar. Bu saldırıdaki sahte paketler hiçbir güvenlik danışmanı veritabanında yoktu. Yük, Socket'in kendi statik analizi ile tespit edildi, CVE raporları aracılığıyla değil. Dolayısıyla composer audit tek başına her tehdidi yakalayamaz. Bu, bir alt taban, değil üst tabandır.

Ama çoğu geliştirici henüz bu alt tabanın üstünde durmuyor.

Bir diğer önemli detay şudur: composer audit varsayılan olarak yüklenmiş paketleri kontrol eder. Eğer composer.lock dosyasını yüklemeden denetlemek isterseniz, şunu kullanın:

composer audit --locked

Bu, CI ortamlarında tam yükleme adımı çalıştırmadan önce kilit dosyasını doğrulamak istediğinizde kullanışlıdır.

Yükleme sırasında da çalıştırabilirsiniz:

composer install --audit

Composer 2.4+ zaten composer require ve composer update komutlarında otomatik olarak kısmi denetimler gerçekleştiriyor. Bağımsız composer audit komutu, halihazırda yüklenmiş her şey için tam raporu verir.

Adım 3: Her Yeni Projeye roave/security-advisories Ekleyin

composer audit size kurulum sonrası sorunları bildirir. roave/security-advisories ise bunların ilk başta yüklenmesini engeller.

Bu, PHP kodu içermeyen bir meta-pakettir. Sadece bilinen güvenlik danışmanlarına sahip her paket versiyonu için bir çakışma listesi içerir. Tehlikeli bir versiyonu yüklemeye çalıştığınızda, Composer hata verir:

composer require --dev roave/security-advisories:dev-latest

Bu, her yeni Laravel projesinde require-dev alanına eklemeniz gereken bir şeydir. Sıfır gün veya yeni kötü yazılım gibi durumlar için koruma sağlamasa da, bilinen birçok kötü paket kategori için otomatik olarak engeller.

dev-latest sürümü bilinçli olarak ayarlanmıştır. Sürekli güncellenen bir güvenlik açığı listesi olduğu için etiketli sürüm yoktur. En yenisini almak istersiniz.

Adım 4: Herhangi Bir Paketi Yüklemeden Önce Kırmızı Bayrakları Bilin

Bu saldırıdaki paketler meşru görünmek üzere tasarlanmıştı. Ama öne çıkması gereken sinyaller vardı.

İndirme sayısını kontrol edin. nhattuanbl/lara-helper yalnızca 37 kez indirildi. nhattuanbl/lara-swagger 49 kez. Gerçek işlevselliğe sahip meşru Laravel yardımcı paketler binlerce indirme alır. 49 indirme ile bir Swagger entegrasyonu, hemen sorular doğurmalıdır. Tanımadığınız bir şeyi yüklemeden önce packagist.org/packages/vendor/package-name adresini kontrol edin.

Koşmadan önce kaynağı kontrol edin. Bu, sıkıcı hissettirebilir ama gerçekten önemlidir. composer require komutunu çalıştırmadan önce, GitHub reposuna gidin ve src/'de neler olduğunu görün. Küçük yardımcı paketler için bu iki dakikanızı alır. 27,000 baytlık tek satırlık bir PHP dosyası normal değil. Bunu yakalarsınız.

Hesap geçmişini ve yayımlama tarihlerine bakın. nhattuanbl hesabı 2015 yılından beri vardı ama tüm kötü niyetli paketler 2024 yılı sonunda yayınlandı. Eski bir hesap aniden kısa bir süre içinde birkaç paket yayımlıyorsa, bu dikkate değer bir patern. Daha önce görünmeyen bir yazarın geldiğini göremezsiniz.

Otomatik keşif hizmet sağlayıcılarına şüpheyle yaklaşın. Otomatik keşif kullanışlıdır, ama bunun anlamı paketin kodunun, açıkça çağrıda bulunmadan her başlangıçta çalışmasıdır. Spatie gibi tanınmış yazarlardan gelen paketler için bu sorun değildir. 37 indirme olan bir paket için, önce hizmet sağlayıcıyı okuyun. Bağımlılıklarınızdaki yükü hafif ve dikkatli tutarsanız (bu, diğer yollarla da faydalı bir alışkanlık) endişelenecek yüzey alanınızı azaltırsınız.

Ayrıca burada daha geniş bir ilke bulunuyor. Açık gelişim geçmişine sahip yazarların paketleri ile daha önce hiç duymadığınız hesaplardan gelen paketler arasında gerçek bir fark var. Spatie, temel Laravel ekibi, Livewire, Filament, Pest: bunlar, açık gelişim geçmişine, bilinen bakıcılara ve gerçek topluluk denetimine sahiptir. Tanımadığınız bir hesaptan 49 indirme olan bir paket bunların hiçbirine sahip değildir. Bu, küçük veya niş bir paketi asla kurmamanız gerektiği anlamına gelmez. Bu, dikkatle okumanız gereken eşiğin daha yüksek olması gerektiği anlamına gelir, daha düşük değil.

Adım 5: Eğer Etkilendiyseniz, İşte Dönüştürmeniz Gerekenler

Eğer şüpheli bir şey bulursanız, .env dosyanızın tamamen açıldığını varsaymalısınız. Tahmin etmeyin. Her şeyi döndürün.

Laravel uygulama anahtarı: bu, şifreli çerezleri ve oturum verilerini korur:

php artisan key:generate

Not: uygulama anahtarını döndürmek, veritabanınızda depolanan şifreli değerleri geçersiz kılacaktır (herhangi bir Crypt::encrypt ile çalıştırılan değer). Hashlanmış şifreler ise iyidir; bunlar uygulama anahtarını kullanmaz. Planlamanızı dikkatlice yapın.

Veritabanı parolası: bunu veritabanı konsolunuzda değiştirin, ardından .env dosyasını güncelleyin. Gerçekten güçlü bir şey kullanın; hızlı bir şekilde ihtiyacınız varsa şifre oluşturucu kriptografik olarak rastgele dizeler üretir.

Stripe ve ödeme kimlik bilgileri: Stripe kontrol panelinize girin ve API anahtarlarını yenileyin. Bunu, her şeyden önce yapın. Ödeme kimlik bilgileri en yüksek değerli hedeflerdir.

OAuth istemci gizli anahtarları ve sosyal kimlik doğrulama: Google, GitHub, kullanıyorsanız bunları yeniden üretin ve .env dosyasını güncelleyin. Eğer API kimlik doğrulama için Sanctum veya Passport kullanıyorsanız, veritabanından tüm token’ları silin ve aktif oturumları geçersiz kılın. Her birinin token depolama şekilleri arasındaki farkları anlamak önemlidir. Eğer zaten yapmadıysanız, Passport ile Sanctum arasındaki analizi incelemek faydalı olacaktır.

.env dosyanızdaki diğer tüm API anahtarları: satır satır gidin. Her dış hizmet için bir kimlik bilgisi yeniden üretilmelidir. Uygulamanız kendi token’larını oluşturuyorsa, hash oluşturucu yeni imza anahtarları hızlı bir şekilde üretmenize yardımcı olabilir.

Dönüştürdükten sonra, aşağıdaki beklenmedik dış bağlantılar için sunucu günlüklerinizi kontrol edin:

grep "helper.leuleu.net" /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null

Adım 6: Bunu CI/CD Ortamında Kapatın

Hassas bir bağımlılığı üretime ulaşmadan önce yakalamak için en iyi zaman, bir güvenlik danışmanını okumak değil, geliştirmedir.

İşte composer audit herhangi bir şey bulursa derlemenizi başarısız kılan minimum düzeyde bir GitHub Eylemi iş akışı:

name: Güvenlik Denetimi
on: [push, pull_request]
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Bağımlılıkları Yükle
run: composer install --no-interaction --prefer-dist --no-progress
- name: Güvenlik denetimini çalıştır
run: composer audit

Çünkü composer audit bir güvenlik açığı bulunduğunda sıfırdan farklı bir kod ile çıkış yapar, pipeline’ınız otomatik olarak başarısız olur. Ek bir yapılandırmaya gerek yoktur.

Hemen düzeltmeyecek şekilde bilinen güvenlik açıklarınız varsa (örneğin, uyumluluk nedenleriyle eski bir paket sürümüne takılıp kaldıysanız) geçici olarak belirli danışmanlıkları yok sayabilirsiniz:

composer audit --ignore=CVE-2024-XXXX

Ancak bu konuda dikkatli olun. Yok sayılan danışmanlıkların, sonsuza kadar yok sayılması gibi bir durumu vardır.

Rahatsız Edici Gerçek

Benim dürüst görüşüm şu: Packagist çevresindeki güvenlik araçları oldukça iyi. composer audit çalışıyor. roave/security-advisories çalışıyor. Danışmanlık veritabanı aktif olarak korunmakta. Composer 2.9, bilinen danışmanlığa sahip paketin otomatik olarak engellenmesini varsayılan olarak ekledi.

Problem, araçların kendisi değil. Sorun, çoğu geliştiricinin bağımlılıklarına bir saldırı vektörü olarak ulaşmayı düşünecek kadar geç hareket etmesidir.

Bu saldırıdaki paketlerin indirme sayısı çok düşüktü. Bu, zayıf bir sinyal, ama çoğu kimsenin kontrol etmediği bir sinyal. İşin sonu, faydalı görünen bir paket ismi görmek, README’yi gözden geçirmek ve composer require demektir. Bunu ben de yaptım. Muhtemelen siz de yaptınız.

Çözüm, her pakette paranoid hale gelmek veya Packagist kullanmayı bırakmak değil. Çalışma akışınıza yalnızca bir komut eklemektir. composer audit çalıştırın. Yeni projelere roave/security-advisories ekleyin. Tanımadığınız bir şeyi yüklemeden önce indirme sayılarını kontrol edin.

Bu sadece beş dakikalık alışkanlıklardır. Şubat ayında birinin sunucusunda çalışan RAT değildir.

Kimlik doğrulama tarafında daha ileri gitmek isterseniz (uygulama katmanında kredi çalınmasının etkisini azaltmak için), anahtar kılavuzuna göz atmak faydalı olabilir.

Sıkça Sorulan Sorular

Bu paketler Packagist'te hâlâ mevcut mu?

Bu yazının yazıldığı sırada, Socket'in kaldırma talepleri sunmasına rağmen paketler hâlâ mevcuttu. Packagist'in paketleri kaldırma süreci zaman alır. Bunun mevcut durumunu kontrol edin; packagist.org/packages/nhattuanbl adresini kontrol edin, kaldırıldıklarını varsaymayın.

Gelecekte composer audit bu tür saldırıları yakalayacak mı?

Hayır, otomatik olarak değil. composer audit, Packagist veritabanındaki bilinen danışmanlıkları kontrol eder. Yeniden keşfedilen kötü yazılımlar orada görünmeyecek, danışmanlık verene kadar. Yakalamakta olduğu, açıklanan CVE’lere sahip paketlerin çok daha büyük evrenidir. Bunu, çok katmanlı bir savunma yaklaşımında bir katman olarak düşünün; tüm savunma değil.

roave/security-advisories’nin çalıştığını nasıl doğrulabilirim?

composer require laravel/framework:8.22.1 komutunu deneyin. O sürümde bilinen bir güvenlik açığı vardır ve paket yüklemeyi engelleyip hata vermesi gerekir. Eğer öyleyse, doğru çalışıyordur.

Bu durum, paylaşımlı hostingdeki Laravel uygulamalarını etkiliyor mu?

Evet. RAT yükü çapraz-platformdur ve Laravel’in hizmet sağlayıcı otomatik keşfi aracılığıyla etkinleşir. Root erişimine ihtiyaç duymazlar. Paylaşımlı barındırma ortamları varsayılan olarak korunmaz.

Eski projelerimi de denetlemeli miyim?

Evet, özellikle son bir yılda aktif olarak güncellenmiş veya paket eklenmiş projeler. Proje dizinlerinizde grep -r "nhattuanbl" composer.lock komutunu çalıştırın. Hepsini bir kerede taramak istiyorsanız: find ~/projects -name "composer.lock" -exec grep -l "nhattuanbl" {} \;.

Bugün Başlayın, Bir Sonraki Olaydan Sonra Değil

Paket kayıtlarında tedarik zinciri saldırılarının her ekosistemde arttığını görüyoruz: npm, PyPI, RubyGems ve şimdi Packagist daha hedefli bir şekilde. Laravel ekosistemi oldukça büyük, dolayısıyla buna değer bir hedef olacak ve bu son saldırı olmayacak.

İyi haber şu ki, araçlar mevcut ve bunlar oldukça basit. composer audit üç saniyenizi alır. roave/security-advisories için bir satır yeter. Bunlar, tam bir güvenlik incelemesini geçmez ama mevcut çoğu Laravel projesinin kapattığı açığı oldukça düşük çaba ile kapatır.

Projelerinizi denetimden geçirin.

Bir üretim Laravel uygulaması oluşturuyorsanız ve en başından itibaren güvenlik odaklı bir geliştiriciyle çalışmak istiyorsanız, iletişime geçin.