Red Hat Cloud Services genelinde kötü amaçlı npm paketleri tespit edildi

 (github.com/RedHatInsights)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Konu açık durumda ve metin itibarıyla atanan kişi, kilometre taşı, bağlı branch veya PR bulunmuyor
  • @redhat-cloud-services/ kapsamındaki birden fazla npm sürümünde kötü amaçlı sürümlerin bulunduğuna dair bir güvenlik sorunu olarak kaydedildi
  • Referans olarak StepSecurity'nin analiz yazısı ve OSS Security Feed arama sonuçları sunuluyor
  • Güncellenen etki listesinde @redhat-cloud-services/chrome, frontend-components, rbac-client, types, vulnerabilities-client dahil 32 paket yer alıyor
  • Tabloda yer alan zarar görmüş sürümler çoğu paket için 3 adet; @redhat-cloud-services/vulnerabilities-client ise yalnızca 2.1.9 ve 2.1.11 sürümlerini içeriyor
  • Tablonun tamamına göre zarar görmüş sürümler 95 adet olarak sayılabiliyor; ayrıca ayrı olarak anılan harici PR başlığı da 95 versions ifadesine işaret ediyor
  • @redhat-cloud-services/frontend-components-* ailesi ve çeşitli *-client paketleri birlikte yer aldığından, mesele tek bir paketten değil aynı scope genelindeki sürüm sorunundan oluşuyor
  • Yorumlarda “What are these?” sorusuna “all that module is pwned” yanıtı verilerek, listedeki her şeyin ihlal edildiği yönünde ortak bir anlayış paylaşılıyor
  • DanielRuf, bu olayı supply-chain-incidents listesine eklediğini belirtti
  • GitHub etkinliğinde bu issue'ya referans veren içerik özeti ve tespitle ilgili PR'lar görülüyor; ancak metinde Red Hat tarafının teşhisi, azaltma adımları, kaldırma durumu veya düzeltilmiş sürümler henüz sunulmuyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • cooldown ayarları konusundaki başlığı yeniden canlandırmamda sakınca yoktur umarım. axios, tanstack, @redhat-cloud-services ve yakın dönemdeki birçok npm tedarik zinciri saldırısı, cooldown olsaydı engellenebilirdi
    Artifactory/Nexus kullanıyorsanız muhtemelen zaten vardır; yoksa da ayarlaması kolaydır. npm veya PyPI ihlallerinin çoğu birkaç saat içinde kaldırıldığı için, yayımlanmasının üzerinden N gün geçmemiş paketleri yok saymak yeterlidir. 1 gün bile etkilidir, 3 gün iyidir, 7 gün biraz abartılıdır ama işe yarar
    En güncel pnpm sürümü varsayılan olarak 1 günlük cooldown ekledi: https://pnpm.io/supply-chain-security
    Bunu tek tıkla halletmek isterseniz https://depsguard.com kullanabilirsiniz. npm, pnpm, yarn, bun, uv ve dependabot için cooldown ve önerilen ayarları ekleyen bir CLI; bakımını ben yapıyorum
    Cooldown’a daha çok odaklanan https://cooldowns.dev de var; yerel yapılandırmaya yardımcı olan betikler de içeriyor. Hepsi açık kaynak / ücretsiz
    ~/.npmrc gibi dosyaları elle düzenlemeyi biliyorsanız buna pek gerek yok, ama çevrenizde sadece tek tıkla düzeltmeye ihtiyaç duyan insanlar varsa bir sonraki saldırıdan kaçınmalarına yardımcı olabilir
    Tabii yeni kritik bir CVE’yi yamalamanız gerektiğinde cooldown’ı aşmanız gerekir; her araçta bunu yapmanın bir yolu vardır. Son birkaç aya dair elimde net sayılar yok ama Mythos tarzı açık bulma çağında bile, yeni zero-day CVE’lerden ziyade kötü amaçlı sürüm dağıtımı gibi yazılım tedarik zinciri saldırılarının daha büyük risk oluşturduğu görülüyor

    • Gömülü yazılım geliştiricisi olarak araç zincirini ve bağımlılıkları yıllarca sabitlemeye alışkın olduğum için, web geliştirme kültürü birçok açıdan şok edici geliyor
    • Daha mantıklı ve biraz daha güvenli yapılandırma yöntemlerini toplayan bir arkadaşın GitHub deposu var: https://github.com/jordanconway/package-manager-hardening
    • Docker/Podman image pull işlemlerine de cooldown eklemenin mantıklı bir yolu var mı?
    • ~/.npmrc dosyasını açıp tek satır ekleyebilen biri olsanız bile, tek tıkla düzeltmeye ihtiyaç duyanların oldukça küçük bir grup olduğunu düşünüyorum
    • Cooldown’a ek olarak, daha fazla paket yöneticisinin güvenlik düzeltmeleri ile normal sürümleri (hata düzeltmeleri / performans iyileştirmeleri / yeni özellikler) farklı ele alması iyi olurdu
      “Güvenlik düzeltmeleri yalnızca güvenlik düzeltmeleri içermeli, başka özellik taşımamalı” demek gayet makul. Böylece hem güvenlik araştırmacıları hem de araçlar için denetim daha kolay olur
      Normal sürümlere cooldown uygulanabilir; güvenlik düzeltmelerinde ise cooldown kaldırılabilir ya da çok daha kısa tutulabilir
      Debian gibi çok istikrarlı sunuculara sahip olup unattended upgrades’i yalnızca güvenlik düzeltmelerine uygulayacak şekilde ayarlayabildiğiniz sistemler iyi bir referans. Bu tür yeni paket sürümlerini güvenlik araştırmacılarının denetlemesi de daha kolaydır

  • Bu tür başlıklarda her seferinde, bu saldırı türü sanki yalnızca npm'de varmış gibi davranan ya da hiçbir önlem alınmamış gibi alay eden çok yorum oluyor; ama bunun adil olduğunu düşünmüyorum
    Paket tüketicilerini korumak için delay line ve pnpm gibi araçların getirdiği iyi özelliklerden bahseden yorumlar da çok
    Daha az konuşulan kısım ise paket bakımcılarına yönelik araçlar. Yayınlama için MFA: https://docs.npmjs.com/requiring-2fa-for-package-publishing-..., yaklaşık 1 yıl önce sunulan trusted publishers: https://docs.npmjs.com/trusted-publishers
    Son dönemde bu iki özelliğin avantajlarını birleştiren staged publishing de çıktı: https://docs.npmjs.com/staged-publishing
    Artık statik kimlik bilgileri olmadan CI içinden yayın yapabilir ve kayıt defterinde gerçekten herkese açılmadan önce bakımcının bunu MFA ile onaylamasını zorunlu kılabilirsiniz. İsterseniz GitHub Actions Environments korumasıyla CI tarafında çoklu onay ya da zaman gecikmesi de zorunlu tutulabilir
    Topluluğu bu tür yayınlama korumalarını benimsemeye teşvik etmeliyiz; aksi halde bu sorun sürüp gidecek

    • [1]'e göre “etkilenen tüm paketler RedHatInsights/javascript-clients deposundan GitHub Actions OIDC üzerinden yayımlandı; bu da üst CI/CD ardışık düzeninin kendisinin tehlikeye atıldığını gösteriyor” deniyor
      O halde kötü amaçlı paketler de yeşil yıldızı almış ve kullanıcılara “kaynak kanıtıyla derlenip imzalandı” diye güven vermiş olacaktı
      [1] https://lwn.net/Articles/1075742/
    • Sürekli yaşandığı için komik aslında. npm saldırıları neredeyse takvime işaretlenebilecek kadar düzenli; hatta biri The Onion'ın klasik “kaçış yok” haberinin npm sürümü gibi bir parodi bile yapmıştı
      Bunu önlemek için çalışma yürütülmesi harika, ama yine de olmaya devam ediyor. “Yine mi başladı” anlamında komik
    • Herkes için zorunlu hale getirilince ancak o zaman gerçekten bir şey yapılmış olur
    • Mekanik değişikliklerden çok etkilenmiyorum; bu sorunu kültürel bir sorun olarak gören bir kesim var gibi geliyor
      Dışarıdan bakınca web geliştirme, çılgın bir Vahşi Batı enerjisine sahip. Değişkenlik, dinamik tipler, sürekli değişen standartlar ve framework'ler, sürekli dağıtım, CDN'ler, gerçek zamanlı A/B kampanyaları, çok sayıda bağımlılık ve farklı altyapılara yayılmış hassas kullanıcı verileri var
      Bu bakış açısının doğru olduğunu ya da “bakın işte” tavrının yerinde olduğunu söylemiyorum, ama nereden geldiğini anlıyorum
    • Bence ikisi de domuza ruj sürmek gibi çözümler. Sonuçta hepsi “sürümleri yayımlamayı daha zor hale getirelim” yaklaşımının bir çeşidi ve insanlara sadece etrafından dolaşmayı öğretir
      Özellikle bu ikisinin hiçbiri xz-utils arka kapısının paket yayınına girmesini engelleyemezdi. xz-utils, sofistike bir üst kaynak ele geçirilmesinin ölçütü olarak duruyor
      Buradaki hata, zaten güvendiğiniz üst kaynağı daha iyi doğrulamanız gerektiği değil; üst kaynağa güvenliğin tek kaynağı olarak güvenememenizdir. Üst kaynak, sağlam sürüm mühendisliğine ne çok ilgi duyan ne de bunda çok iyi olan hackerlardan oluşan bir topluluk
      Ama bunu iyi yapan insanlar da var. Linux dünyasının çözümü ve xz-utils olayında bizi kurtaran şey, hackerların ürettiği üst kaynağı kullanıcılar için inceleyen, denetleyen, paketleyen ve özelleştiren ikinci bir insan katmanının varlığıdır
      Bu insanlar farklı gözlere, farklı tüketici ihtiyaçlarına ve farklı kalite ölçütlerine sahip; üst kaynağın yakalamaya hazır olmadığı hataları ve kötü niyeti yakalıyorlar
      NPM, cargo, PyPI ve benzerleri, bu insan emeği gereksinimini aşabileceklerini düşünmeye devam ediyor, ama aşamazlar. NPM ekosisteminde bu durumun özellikle sık görülmesinin nedeni, çok hızlı sürümler, gevşek uyumluluk beklentileri ve aşırı yeniden kullanıma alışkın çok sayıda web geliştiricisinin bulunması; bu yüzden node paketlerinde bunu Python ya da Rust'a kıyasla daha sık görüyoruz

  • Şirketimiz yarn 4 kullanıyor ve npm paketi yayımlandıktan sonraki ilk birkaç gün kurulumunu engelleyen bir seçenek var. Bu tür saldırıların çoğu bu süre içinde (1–3 gün) yakalanıyor gibi görünüyor
    https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

  • Birkaç öneri var. Bağımlılık cooldown süresinin 1–2 gün olması, CVE yama kabiliyetine zarar vermeden çok etkili görünüyor
    npm install, npm test gibi kodun çalıştırıldığı her yer yetkisiz bir ortamda çalışmalı. GitHub Actions kullanıyorsanız, artifact build/test işleriyle deployment/imzalama gibi işleri ayırmak nispeten kolay. AI kullanıyorsanız, bu deseni zorunlu kılan bir skill/rehber ekleyebilirsiniz
    GitHub Actions kullanıyorsanız, güncel zizmor kurmak güvenlik duruşunu ciddi biçimde iyileştirir
    İkinci önlem, bunun artık “worm gibi yayılabilir” olmamasını sağlar ve mevcut sorunun büyük bir kısmını azaltır. Birincisi ise şirketlere saldırıya yanıt vermek için zaman kazandırır. Bu alandaki bazı vendor'ları da değerlendirmeye değer

    • Ya zizmor ele geçirilirse?
      Yeni paketlerin geciktirilmesi gerektiğini söyledikten hemen sonra bunun söylenmesi komik bir şaka gibiydi
    • Bu cooldown yerine build'leri izole bir context içinde çalıştırmak yeterli değil mi?
      Lokalde bir Maven proxy çalıştırıyorum ve tüm build'leri container içinde yapıyorum. Python, npm ve Go yalnızca herkese açık depolar kullandığı için bu build'ler de container içinde yapılıyor, ancak depo proxy'sine ihtiyaç duymuyor
    • Kodun çalıştığı her yerde, codex ve claude-code gibi ajan tipi orkestratörler bunu zaten varsayılan olarak yapıyor gibi görünüyor

  • Red Hat ve IBM'in tedarik zinciri zafiyetlerini tespit etmeye ve düzeltmeye yardımcı olan Project Lightwell'i duyurduğu günle aynı günmüş
    https://www.redhat.com/en/lightwell

  • Birkaç gün önce şu ilginç rant’ı gördüm: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
    Doğru yaklaşımın, kullandığınız tüm bağımlılıkları fork’layıp gerektiğinde upstream’i inceleyip birleştirerek kendi deponuzdan kurmak olduğu yönündeki sözde bir haklılık payı var. Yine de inanılmaz derecede uğraştırıcı görünüyor

    • Otomatikleştirilemeyecek bir iş değil. Go tarafında buna vendoring denebilir: https://go.dev/ref/mod#vendoring
      Üçüncü taraf bağımlılık barındırma sağlayıcılarına olan bağımlılığı azaltmak veya ortadan kaldırmak, bağımlılıkları kendi code review aracınızın içine almak ve uzun vadede tekrarlanabilir derlemeler sağlamak için iyi
    • Sorun şu ki bu, bağımlılıkların bağımlılıklarına ve onların da birkaç kat altına kadar uzanıyor
    • CLI’de bağımlılıkları kolayca denetlemek için Packj’yi yaptım
      Packj(https://github.com/ossillate-inc/packj) davranış analiziyle kötü amaçlı PyPI/NPM/Ruby/PHP vb. bağımlılıkları tespit ediyor. Statik+dinamik kod analiziyle shell çalıştırma, SSH anahtarı kullanımı, ağ iletişimi, decode+eval kullanımı gibi ihlal göstergelerini tarıyor. Ayrıca typosquatting gibi kötü niyetli aktörleri bulmak için çeşitli metadata özelliklerini de kontrol ediyor
    • Olasılıkları değiştirebilirsiniz ama özenle fork’layıp gelecekteki tüm açıkları monkeypatch’lemezseniz ele geçirilmiş bir fork’u sonsuza kadar dağıtıyor olabilirsiniz
    • Paketleri sadece güncel tutmak değil, sürüm numaralarını da kısıtlamak gerekmiyor mu?

  • Yaklaşık bir hafta önce dizüstü bilgisayarımdan Node’u sildim ve bu iyi hissettirdi
    Şanssız şekilde bir exploit’e yakalansam bile etki alanını küçültmek için her şeyi geliştirme konteynerleri ya da başka sandbox’larda yapmaya çalışıyorum. Saldırgan Claude token’larını alabilir ama konteynerden kolayca çıkıp home dizinimi tarayamaz
    Cooldown ve kurulum script’i izin listeleri, özellikle CI’da katmanlı güvenlik için iyi ek önlemler. Ama temelde değişmesi gereken şeyin işletim sisteminin yetki modeli olduğunu düşünüyorum. Üçüncü taraf yazılıma varsayılan olarak tam kullanıcı yetkisiyle güvenmek artık işlemiyor

    • Bubblewrap/Firejail/Flatpak gibi şeyler kullanıp kullanmadığınızı ya da böyle bir kurulumun nasıl görüneceğini merak ediyorum. Benzer bir fikri bir süredir düşünüyorum ama henüz uygulayamadım

  • Sanırım asıl duyuru bağlantısını vermek gerekiyor
    https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

    • Evet. Ayrıca başlıkta Red Hat’ın yazımı da yanlış

  • Paket kurarken artık --before=2026-05-30 bayrağını kullanmayı alışkanlık haline getirdim. Belirtilen tarihten önce yayımlanan bir sürümü seçtiriyor; ben genelde yaklaşık 5 gün öncesini seçiyorum

  • NPM tasarım gereği bozuktu ve toplulukta yaygın olan NIH sendromu yüzünden basit önlemler bile alınamıyor

    • İkinci cümleyi pek anlayamadım. npm, “burada üretilmediyse kullanmayız” yaklaşımının tam tersi bir sorun değil mi?
      Kendi geliştirmek yerine dış paketleri çok fazla benimsemek, npm projelerinin büyük ve karmaşık bağımlılık ağaçlarına sahip olma eğiliminde olmasına yol açıyor. https://www.npmjs.com/package/is-windows gibi paketler için, aynı kodu doğrudan yazmak çok kolayken bile potansiyel açıklar ve bakım dertleri yarattığı yönünde uzun süredir şikâyet var
    • NIH tarafında yaygın hata, X paketini yeniden yapmanın çok zaman alacağını düşünmek
      Oysa elbette tüm işlevselliği yeniden oluşturmanız gerekmiyor; sadece ihtiyaç duyduğunuz kısmı yapmanız yeterli
      Ayrıca tek bir işlevi kodlarken soyutlama ya da ek fonksiyon arayüzleri oluşturmanız da gerekmiyor. Bu yüzden daha ucuza gelir ve muhtemelen daha iyi entegre olur
      Bir başka hata da hata ve açık üreteceğini düşünmek. Kötü bir programcıysanız olabilir ama tam olarak birbiriyle uyumlu olacak şekilde tasarlanmamış iki kütüphanenin entegrasyon sınırında ortaya çıkan açık kategorisinden kaçınabilirsiniz. Böyle durumlar çok oluyor