- 8 Eylül'de, popüler npm paketlerine zararlı kod enjekte edildiği tespit edildi
- Etkilenen paket sayısı toplam 18 olup, dünya genelinde haftada 2 milyardan fazla indirme alıyor
- Saldırganların, web sitesi ziyaretçilerinin tarayıcılarında kripto para ve Web3 işlemlerini gizlice ele geçirip, cüzdan içindeki onayları ve para akışını saldırgan hesaplarına yönlendiren kod eklediği belirlendi
- Ana paket dosyalarına (
index.js) obfuscate edilmiş JavaScript kodu eklendiği doğrulandı
- Olayın, hedef paket güncellemeleriyle aynı anda başladığı ve topluluğun şu anda müdahale ettiği aktarılıyor
Olayın özeti
- 8 Eylül saat 13:16 UTC itibarıyla, Aikido'nun güvenlik izleme akışında npm'e zararlı kod içeren birden fazla paketin yüklendiği görüldü
- Bu paketler npm üzerinde son derece popüler ve haftada 2 milyardan fazla indirme alıyor
Saldırı yöntemi ve içeriği
- Zararlı güncellemeden sonra, ilgili paketi kullanan web sitelerinde ziyaretçilerin tarayıcılarında JavaScript zararlı yazılımının gizlice çalıştığı bir yapı tespit edildi
- Bu kodun amacı, kripto para ve Web3 etkinliklerini izlemek, cüzdan etkileşimlerini manipüle etmek ve ödeme hedef adreslerini izinsiz değiştirmek
- Kullanıcı ekranda belirgin bir değişiklik görmeden, fonlar ve onay yetkileri saldırganın belirlediği kripto para adreslerine gönderilebilir
Zararlı kodun ayrıntılı analizi
- Örneğin
is-arrayish paketinde index.js dosyası değiştirilerek obfuscate edilmiş karmaşık JavaScript eklendi
- Kod içinde
window.ethereum arayüzü kullanılarak cüzdan hesap bilgileri kontrol ediliyor ve saldırı kodunun tetiklenme koşulları doğrulanıyor
- Dahili olarak çok sayıda kripto para adresi (Bitcoin, Ethereum vb.) ve fonksiyon mantığı bulunuyor; ayrıca cüzdan adreslerini ve işlem ayrıntılarını saldırgan adresleriyle değiştiren işlevler uygulanmış
- Bu nedenle gerçek kullanıcıların kripto varlıklarının haberleri olmadan sızdırılması ve izinsiz aktarılması riski ortaya çıkıyor
Mevcut durum ve topluluğun tepkisi
- Sorunlu zararlı paket sürümleri, başlıca npm depolarından hızla kaldırılıyor
- IT/açık kaynak topluluğu, ilgili paketlerin kullanımının durdurulması ve yükseltilmesine yönelik bilgilendirmeleri, ayrıca ek bulaşma tespiti ve önlem çalışmalarını yoğun biçimde sürdürüyor
- Bu olay, paket tedarik zinciri güvenliği, kod obfuscation tespiti ve Web3 tarayıcı eklentilerinin korunması konusunda farkındalığı ciddi biçimde artırmış durumda
2 yorum
> 8 Eylül 2023'te,
Halüsinasyon nedeniyle tarih yanlış görünmüş. 2023'ten değil, şu anki bir olaymış.
Görünüşe göre npm hakkında epey sık hacklenme haberleri duyuluyor. Ortada bir sorun var gibi görünüyor.
Hacker News görüşleri
Evet, hacklendim. Gerçekten utanç verici ve herkesten özür dilerim. Ayrıntılar için lütfen buraya ve buraya bakın. Etkilenen paketlerin listesini paylaştım. Bu saldırı hedefli bir saldırı gibi görünüyor. Yorum düzenleme süresi bitene kadar sürekli güncelleme yapacağım. Chalk paketini geri aldım ama geri kalanlar hâlâ ele geçirilmiş durumda (8 Eylül 17:50 CEST). NPM'den ise hâlâ ses yok. NPM hesabıma erişemiyorum ve parola kurtarma özelliği de çalışmıyor. Şu an yapabileceğim tek şey beklemek. Destek ekibi e-postası npmjs dot help adresinden geldi ve oldukça inandırıcı görünüyordu. Bahane değil ama yorgun bir sabahtı; yapılacaklardan birini aradan çıkarmaya çalışırken her zamanki gibi resmi siteye doğrudan girmek yerine linke tıklamam hataydı (sanırım mobilde olduğum için). Bu saldırı yalnızca NPM'i etkiledi,
/debug-jsbağlantısında güncellemeye devam edeceğim. Tekrar gerçekten özür dilerimBu kadar stresli bir durumda hızlı ve şeffaf davranman gerçekten örnek alınacak düzeyde. Artık phishing'e kanmam sanıyordum ama birkaç ipucu ekleyeyim: 1) E-postadaki bağlantılar üzerinden asla giriş yapmayın. Phishing ile meşru e-postaları ayırt etmek o kadar zor ki, kandırılmamanın tek kesin yolu hiç denememek. 2) U2F/Webauthn güvenlik anahtarını ikinci faktör olarak kullanırsanız phishing'e karşı neredeyse kusursuz koruma sağlar. TOTP böyle değil, bunu da not edin. Sonuçta insan yorgunken ya da meşgulken her zaman hata yapabilir. Bu kez hedef olan kişi sendin. Tekrar, çok iyi yönettiğini söylemek istiyorum
sindresorhus'un yönlendirmesine göre, bağımlılık ağacınızda zararlı kod olup olmadığını şu komutla kontrol edebilirsiniz:
rg -u --max-columns=80 _0x112fa8(ripgrep gerekir, kurulum:brew install rg). Orijinal yorum da faydalı olabilirÜniversitedeyken bir keresinde sarhoşken phishing kurbanı olmuştum (gerçi çok eski bir olay). Herkes kurban olabilir. Ama NPM'in tepkisinin bu kadar yavaş olması şaşırtıcı. Bu tür şeylerin saldırganların işine daha çok yarayacağını düşünüyorum
Socket bu olayı hemen tespit etti. İlgili blogda da ele alınıyor. Olanlar üzücü ama açık kaynak ekosisteminin gerçekten çok hızlı tepki vermesini olumlu buluyorum. Böyle olaylar paket taramanın neden önemli olduğunu bir kez daha gösteriyor
Bu uyarıyı hızlı geçtiğin için teşekkürler. porkbun'a alan adının engellenmesi için e-posta gönderdim
Bu zararlı yükte yeterince dikkat çekmeyen sinsi bir kısım var. Cüzdan adresini rastgele değiştirmek yerine, doğru adresle kendi listesindeki adreslerin her biri arasındaki Levenshtein mesafesini hesaplayıp en benzer saldırgan cüzdanını seçiyor. Yani insanların adresin başına ve sonuna kabaca bakma alışkanlığını aşmak için tasarlanmış. Bu özel işlev de dahil olmak üzere tüm payload'ı deobfuscate edip analiz eden ve ayrıntılı anlatan bir yazı var. Herkes dikkatli olsun
Yazıda bir nokta kafamı karıştırdı; benim bildiğim
package-lock.jsonbelirli sürümleri "tam olarak" sabitler.package.jsoniçinde "x sürümü ve üstü" gibi tanımlar mümkün ama lockfile'da her bağımlılığın seçilen sürümü ve tarball URL'si doğrudan yer alır. Lockfile varken CI ortamında paketlerin otomatik güncellenmemesi gerekir diye biliyordum; yoksa npm/yarn/pnpm lockfile çalışma mantığını ben mi yanlış anlıyorum bilmiyorum. npm resmi dokümanındaki alıntı da incelenebilirHash değerini, her karakteri hash ve indeksine göre belirlenmiş bir renk şemasıyla renklendirerek (ön plan/arka plan) gösterirsek, görsel olarak benzetilerek üretilmiş hash'leri ayırt etmek çok daha kolay olabilir diye düşünüyorum
Acaba bu tekniğin belirli bir hacking grubuyla bağlantılı olduğuna dair bir bilgi var mı merak ediyorum
Bu saldırı kodu yaratıcı olabilir ama aslında web dünyası benzer adres saldırılarıyla onlarca yıldır uğraşıyor; bu sadece daha dinamik bir versiyon. Bunu aşırı övmeye katılmıyorum. Dürüst olmak gerekirse bu analiz yazısının tamamı bana daha çok AI yazmış gibi geldi, dikkatli bir analiz gibi durmuyor
12 gün önce Nx tarafı da aynı şeyi yaşadığında benzer bir yorum yazmıştım. Bu tek bir kişinin hatası değil, sektörün tamamının başarısızlığı. Tedarik zinciri saldırılarının etkisi çok büyük ve aslında bunlar zaten çözülmüş olması gereken problemler. Sonuçta biz yazılım geliştiricileriz; standart güvenlik önlemlerini (kod imzalama, artifact imzalama, hesap anomali tespiti, 2FA vb.) kapsamlı biçimde uygularsak bunları önleyebiliriz. Hâlâ tüm paketleme platformlarının bunları yapmıyor olması teknik sınırlar yüzünden değil, kimsenin zorlamıyor olması yüzünden. AI'ın ilerlemesi ve gerçek saldırıların tekrar tekrar başarıya ulaşması nedeniyle bu iş daha da kötüleşecek. Artık güçlü güvenlik standartlarını 'zorunlu' hâle getirmemiz gerektiğini düşünüyorum
Bu güvenlik önlemlerinin bazı trade-off'ları var. Örneğin heuristik ya da ispat temelli mekanizmalar uygulanırsa epey fazla otomasyon sistemi veya sıradan kullanıcı dışarıda kalabilir. SMS tabanlı 2FA'nın güvenliği zayıf, e-posta da phishing riski taşıyor. TOTP ancak açık standart olarak kullanıldığında anlamlı ama o bile phishing'i tamamen engellemiyor. Gerçekten etkili olan tek şey donanım tabanlı kimlik doğrulama, fakat bunun da büyük ölçekli platformlarda uygulanması pratikte zor
"Güvenlik standartlarına uysak her şeyi önleriz" demek bu kadar basit değil. Ne kadar kusursuz güvenlik önlemi uygularsanız uygulayın, insan hata yaptığında tüm sistem savunmasız kalır. Tamamen güvenli sistem diye bir şey yok. AI'ın gelişmesiyle phishing e-postaları gerçeğinden ayırt edilemez hâle geliyor ama öte yandan AI ile bu saldırıları daha iyi tespit etmek de mümkün olabilir. Sonunda savunmayı da AI ile yapmak zorunda kalacağız
Eskiden hack saldırıları daha çok Windows'u hedef alıyordu, şimdi ise JavaScript ve Python geliştiricilerinin sayısı çok daha fazla. Bu tür saldırılar giderek daha da kötüleşecek
Bence NPM'in de bir miktar sorumluluğu var. Çeşitli dış güvenlik sağlayıcıları ve startup'lar bu tür zararlı faaliyetleri hızla fark edebiliyor ama tüm paketleri ve güvenlik olaylarını gerçek zamanlı görebilen NPM'in bunu tekrar tekrar engelleyememesi anlaşılır gibi değil. Neredeyse bilerek görmezden geliyor gibiler
NPM artık GitHub'ın, yani Microsoft'un. Belli ki Copilot gibi üretken AI ürünlerini her uygulamaya sokmakla meşguller
Birden fazla kişinin yönettiği paketlerde, en azından başka bir yöneticinin onayı olmadan publish edilememesi için bir seçenek sunulmalı bence
Aynı saldırgan uzun süre atıl kalmış 22'den fazla pakete obfuscate edilmiş (üstelik çok şüpheli görünen) payload'ı aynı anda enjekte edip eşzamanlı olarak yayınladı. NPM'in bunu yakalamasını beklemek bana neredeyse imkânsız geliyor. Ben de başka yazılım platformlarına uygulama/eklenti dağıtmış biri olarak bazen günlerce, haftalarca beklemek zorunda kalındığını biliyorum. Ama NPM'de, MS ve GitHub her türlü güvenlik çözümünü satarken, hizmete gerçekten yatırım yapıldığına dair bir iz olmaması şaşırtıcı
NPM'in bir şeyi değiştirmesi için pek nedeni de yok bence. 10 yıldan uzun süredir malware dağıtımının kaynaklarından biri ama kimse kullanmayı bırakmadığı için iş açısından bir darbe de almıyor
Sebeplerden biri paket yöneticilerinin aşırı yaygınlaşması. En başından beri bu kadar önemsiz paketlere bağımlı olunmasından hoşlanmıyordum. En güncel sürümü rastgele çekip ortamın bozulması deneyiminden de nefret ediyorum. Yalnızca npm değil, genel olarak paket yöneticilerinin hepsi aynı derecede can sıkıcı
Artık bir şifre yöneticisi olmadan, resmi alan adıyla eşleşmeyen bir sitede elle parola giren birinin internette önemli işler yapmaya hakkı olmadığını düşünüyorum
Şifre yöneticisi/tarayıcı otomatik doldurma bu tür sahte alan adları için uyarı vermiş olurdu; bu NPM phishing vakasındaki gibi
npmjs.helpile resmi alan adının eşleşmemesini de engellerdiBu doğru ama pratikte resmi uygulama ile web sitesinin tamamen farklı alan adları kullandığı durumlarla da birkaç kez karşılaştım. Mobil uygulama ile web'in tamamen farklı alan adlarında olması en kötüsü. Böyle bir şeyi kim tasarlar bilmiyorum
Böyle olaylar tekrarlandıkça, paket kayıtlarının neden tüm paketlerin kriptografik olarak imzalanmasını zorunlu kılmadığını anlamıyorum. Elbette CI/CD içinde otomatik imzalama yapılıp o sistem de ele geçirilirse yine aşılabilir ama sorunların büyük kısmını önler. Geliştiricilerin artifact indirme, imzalama, yükleme gibi ek manuel adımlardan geçmesi gerekebilir
Gerçek bir registry olsa Debian'da olduğu gibi bunu zaten yapardı. npm amatörce, bu yüzden büyük şirket ortamlarında kullanımı çoğu zaman yasaklanıyor
Benim sevdiğim yöntem sonradan doğrulama. CI/CD otomatik yüklemeyi yaptıktan sonra, web arayüzünde bir insanın bir kez daha tıklamasıyla gerçek yayınlama gerçekleşirse, release sürecindeki sürtünme azalır ama yine de bir insan onayı alınmış olur
Ama o zaman da "hangi imza anahtarına güveneceğiz" gibi zor bir soru kalıyor. 2FA'sı ele geçirilmiş biri yeni bir anahtar yükleyip imzalayabilir, bu yüzden şüpheli hesap etkinliği tespit edildiğinde yeni imza anahtarlarının eklenmesini geciktirmek gibi bir yöntem gerekebilir
npm registry'den kaçınmanın çok daha iyi olduğu sonucuna vardım. Onun yerine paketleri doğrudan (git) repository'den almak daha mantıklı görünüyor. npm registry tedarik zinciri saldırılarının ana geçitlerinden biri ve ayrıca kaynak kod ile dağıtılan kod tamamen ayrılmış durumda.
npm publish, yereldeki herhangi bir kodu doğrudan yükleyebildiği için kötü niyetli bir kullanıcının zararlı kod eklemesini kolaylaştırıyorGitHub builds üzerinden npm'e dağıtım yapılırken özgünlük doğrulaması gibi bir özellik var ama yine de başka ortamlardan publish edilebiliyor gibi görünüyor; o yüzden tam olarak anlayabilmiş değilim
Bir C geliştiricisi olarak, zamanında bağımlılıkları minimumda tutmak, tek başlık dosyalı kütüphaneler kullanmak ve vendor etmek eski kafalılık diye eleştirilirken, şimdi herkesin bunların yine gerekli olduğunu fark etmesi çok tuhaf hissettiriyor
npm'in son provenance özelliği bu sorunu çözüyor. Kurulumu da oldukça kolay ve bu tür saldırıları önlemeye yardımcı olur. Büyük paketlerin bunu peş peşe benimsemesini görmek sevindirici
Bunun CI ortamlarında da kullanılıp kullanılmadığını merak ediyorum. Normalde sunucuda
npm installile alınan şeyin yerinegit clonemu kullanılıyor, öğrenmek isterim"Paketleri doğrudan git deposundan almak" teoride güzel görünüyor ama pratikte npm'de çok fazla bug var ve bunlar git dependency kurulumunu da etkiliyor. Açtığım issue'da belirttiğim gibi, build step sorunları yüzünden 2020'ye kadar düzgün çalışmadı ve
npm install'ı global çalıştırırken hâlâ sorun var. Hattaprepackscript'i npm dokümanında açıkça yazıyor olsa bile, gerçekte git tabanlı bağımlılıklarda çalışmıyor. TypeScript compiler ekibi de bu bug yüzünden tuhaf workaround'lar kullanmak zorunda kaldı; çözüm kodu ve bug kaydı hâlâ duruyor.prepackbaşarısız olsa bile exit code'u iletilmediği içinnpm installbozuk hâlde tamamlanıyor, bu da başka bir sorun. Bütün bunları görünce npm'in ciddi bir işletim gözetimine ihtiyaç duyduğunu ya da tamamen yeni bir paket yöneticisiyle değiştirilmesi gerektiğini düşünüyorumnpm ekosisteminin dışından biri olarak bakınca, bu kadar çok paketin bu kadar ufak işler için bile neden bu kadar yoğun kullanıldığına şaşırıyorum
Bunun nedeni standart kütüphanenin çok zayıf olması ve temel işlevler için bile harici paket gerekmesi. Kendin yazmaya kalkınca en ufak şeyde bile inanılmaz fazla implementasyon gerekiyor
15 yıllık geliştirme deneyimime dayanarak söyleyeyim: ücretli çalışan JavaScript geliştiricilerinin büyük bir kısmı pratikte kod yazmakta oldukça zayıf. Bu zekâ meselesi değil, eğitim ve kültür meselesi. Kendi başına kod yazmaya karşı aşırı bir korku var ve sonuç olarak en ufak parça için bile dış bağımlılıklara yaslanılıyor. Hobi projeleri yapan geliştiricilerde ise bu daha az görülüyor ve kodları çoğu zaman daha sağlam oluyor. Merak eden varsa iş arkadaşlarına büyük framework'ler olmadan bir şey inşa ettirsin, hemen anlaşılır
Küçük ve trivial modüller hâlinde almak, gereksiz kodun istemciye gitmesini önlemeyi amaçlıyor. Kapsamlı kütüphaneler daha temiz bir DX sağlayabilir ama istemediğiniz kodları da taşır (tree-shaking var ama her şeyi çözmüyor)
leftpad olayından beri bu tartışma sürüyor. Bunun nedeni JS standart kütüphanesinin fazla küçük olması olabilir
Kod değişikliği PR'ında tek satırlık, "güvenilir" görünen bir modülü import etmek, büyük bir kod değişikliğine göre inceleyen kişiye çok daha kolay görünebilir. Gerçekte daha güvenli olmayabilir ama yorgunken daha makul hissettirebilir
Geçen nx olayında da aynı şeyi söylemiştim: paket yöneticisinin yeni paketleri belli bir süre (ör. 24 saat) zorunlu olarak atladığı bir 'grace period' olması gerektiğini düşünüyorum. Bu tür saldırıların çoğu yayımlandıktan kısa süre sonra tespit edilip engellendiği için, kullanıcılar bu süre içinde en güncel sürümü otomatik kurmazsa gerçek zarar azaltılabilir
Yazarın yaşadığı acı ve stresi tahmin edebiliyorum. Tek bir hata yüzünden sürekli açıklama yapmak zorunda kalmak çok yıpratıcı olmalı. Bu aynı zamanda açık kaynak ekosisteminin fiilen tek bir kişinin sahip olduğu paketlere ne kadar bağımlı olduğunu da gösteriyor. Herkesin hata yapıp hacklenebileceğini kabul etmemiz gerekiyor. Teknik açıdan bakınca, AI'ın bu kadar yaygın kullanıldığı bir dönemde deno/node/bun gibi ortamlarda şüpheli kod için uyarılar gösterilmesi, Debian benzeri bir doğrulama temelli
@verifieddağıtım modeliyle güvenin artırılması ve en son sürüm yerine doğrulanmış sürümlerin tercih edilmesi gibi bir kültürel değişime ihtiyaç var gibi görünüyor. Yazar da insan ve hepimizin nazik olması gerekiyor. Durum yatışınca daha teknik ayrıntılar içeren bir analiz ya da postmortem de görmek isterim