Sürüm Sabitleme Eksikliği ve Bağımlılık Karmaşası

Yazılım geliştirme sürecinde hem kendi bileşenlerine hem de üçüncü taraf bileşenlere veya yapılara bağımlıyız. Esnek bir Bağımlılık Yönetimi, modern yazılımlar için olmazsa olmazdır. NPM gibi paket yöneticileri, Maven, bip or Nuget Genellikle yazılım bağımlılıklarını belirtmek için kullanılırlar. Bu araçlar güvenlikten ziyade kolaylık ve kullanım kolaylığı göz önünde bulundurularak tasarlanmıştır.

 

Sorun

Sorun şu ki, geliştiriciler için esneklik ve kullanım kolaylığı, yazılım bağımlılıklarını işleri için karşı konulmaz bir cazibe olarak gören kötü niyetli kişileri cezbediyor. Sonuç: Kötü niyetli kişiler burada gösterilen tüm olası saldırı yollarını izledi. Kaynak: “Arkadan Bıçaklayanın Bıçağı Koleksiyonu: Açık Kaynak Yazılım Tedarik Zinciri Saldırılarının Bir İncelemesi”

Bu yazıda, indirilen sürümün sabit olmadığı, belirli bir aralığa ait olması gerektiği anlamında açık sürüm bildirimlerinin kullanımına odaklanacağız. Derleme sırasında, belirtilen sürüm aralığıyla uyumlu en yüksek mevcut sürüm seçilir ve paket yöneticisi tarafından indirilir/kurulur.

Farklı paket yöneticileri için bağımlılık bildirimlerindeki açık bildirimleri örneklerle açıklayalım:

• • NPM: paket.json

{

 

   ...

   "bağımlılıklar": {
      ...
      “kabul eder”: “>=1.3.8”,
      “lodash”: “~4.16.0”,
      ...
   },
   ...
}

Accepts paketinin 1.3.8'den düşük olmayan en büyük sürümü ve lodash için 4.16.x aralığındaki en büyük 'yama' güncellemesi yüklenecektir.

• • Uzman: pom.xml

Kendi ID’n ile mağazalarını oluştur

Kendi ID’n ile mağazalarını oluştur

     ortak-io
     ortak-io
     SERBEST BIRAKMAK

Kendi ID’n ile mağazalarını oluştur

Kendi ID’n ile mağazalarını oluştur

Commons-io'nun (jar dosyası) en son sürümü bağımlılık olarak eklenecektir.

• • pip: kurulum.py

Kendi ID’n ile mağazalarını oluştur
kurmak(
    Kendi ID’n ile mağazalarını oluştur
    install_requires=['peppercorn', 'launchpadlib'],
    Kendi ID’n ile mağazalarını oluştur
)
Kendi ID’n ile mağazalarını oluştur

Bu tür açık kaynaklı sürüm şemalarının iyi ve kötü yanları var. İyi yanı, daha yeni sürümlerin mevcut olmasıdır. genellikle İşlevsel ve kalite iyileştirmeleri, hata düzeltmeleri ve güvenlik yamaları içerir ve bunlar otomatik olarak güncellenir. Lütfen çoğu gerçek dünya projesi için, felaket niteliğindeki güvenlik açıkları dışında, düzeltmelerin önceki küçük sürümlere geri aktarılmadığını unutmayın. Açık kaynaklı sürümler, tüm bağımlılıklar çözüldüğünde kurulması gereken sürüm sayısını azaltmak için kütüphanelerde kullanım için de uygundur.

Ancak açık sürüm aralıklarının kötü bir yanı da var. Derleme sırasında hangi sürümlerin yükleneceğini tam olarak bilemezsiniz ve derlemeler tekrarlanabilir değildir. Ayrıca bir de şu var: karanlık Açık kaynaklı sürümleri tercih edin. Kötü niyetli bir kişi, açık kaynak kodlu depoda, açık kaynak kodlu aralığınızla uyumlu yüksek bir sürümle zararlı bir bileşen yayınlamayı başarırsa, bir sonraki derlemeniz bu zararlı bileşeni içerecek, hatta otomatik olarak çalıştırılabilecek kurulum komut dosyalarında kötü amaçlı yazılımı çalıştırabilir. Saldırı yükünü gizlemek bir sanat işidir.

Bu bilinen Sürüm Sabitleme Eksikliği konu.

Kötü niyetli kişiler her zaman popüler açık kaynaklı paketlerin zararlı sürümlerini yerleştirmeye çalışırlar. Paket depolarının anahtarlarına gizli bir sızıntı yoluyla erişebilirler; genellikle sosyal mühendislik kullanırlar veya görünüşte faydalı bir bağımlılığın içine gizlenmiş zararlı bir bağımlılık saklarlar. pull requestHatta bazı yazarlar bile bir gün dünyanın adil olmadığını düşünüp müşterilerini bu şekilde cezalandırıyorlar. protesto yazılımı Kendi ambalajlarında!

Şimdi de hem dahili bileşenler hem de açık kaynaklı bileşenler kullanan bir kuruluşta çalıştığınızı hayal edin.
Kötü niyetli bir kişi bu tür dahili bileşenlerin adını biliyorsa, aynı ada sahip bir bileşeni genel depoda yayınlamayı başarabilir. Birçok paket yöneticisi önce genel bileşenleri alır ve eğer sürüm doğru seçilmişse ve bağımlılığınızda belirtilen sürüm açıksa, işte o zaman sorun ortaya çıkar! Bu soruna bu isim verilmiştir. Bağımlılık Karmaşası.

Bir örnek gösterelim. NPM projemizde özel bir bileşene bağımlılığımız olduğunu varsayalım:

• • NPM: paket.json

{
  "isim": "benim-projem",

 

  ...
  "bağımlılıklar": {

    ...
    “my-private-dep”: “>=1.0.0”,

    ...

   }

   ...

}

 

Saldırgan, özel bağımlılığımın yüksek bir sürümünü (örneğin 99.0.0) oluşturabilir ve kendi sahte hesabıyla bunu herkese açık npm deposunda yayınlayabilir (saldırganın kuruluşumla herhangi bir bağlantısı olmasına gerek yoktur). NPM paket yöneticisi, genellikle yıkıcı sonuçlarla birlikte, kötü amaçlı bağımlılığı kuracaktır.

çözüm

Yazılım geliştirme sürecimizde bu sorunlardan kaçınmak için, kullanılan teknolojiye bağlı olarak bileşen sürümlerinin nasıl bildirileceğine dair katı kurallara uymalıyız. Önemli olan, bir paketin belirli bir sürümünün, bir depoda yayınlandıktan sonra, (sadece güvenlik nedenleriyle değil, bağımlı bileşenlerin bozulmasını önlemek için de) değiştirilemez olmasıdır.

Genel fikir sabitlemektir (toplu iğne) sürümleri, bileşenlerin (tüm geçişli bağımlılıklar dahil) düzeltilmiş sürümlerinin kötü amaçlı yazılımlardan arındırılmış olduğunu her zaman kontrol eder ve bu, sayesinde mümkündür. kilit dosyaları Birçok paket yöneticisinin sunduğu bir özellik. Farklı paket yöneticileri için sürüm sabitlemenin nasıl çalıştığına bakalım. Burada hassas bir denge söz konusu. sık sık sürüm güncellemeleri bilinen güvenlik açıklarını gidermek için ve sürüm sabitleme Belirsiz üretim süreçlerini ve olası tedarik zinciri saldırılarını önlemek için.

• • NPM:
    npm veya yarn paket yöneticileri, tüm bağımlılıklar için (doğrudan ve dolaylı) sabit sürümleri listeleyen farklı kilit dosyaları (sırasıyla npm-shrinkwrap.json / package-lock.json veya yarn.lock) kullanır. Kilit dosyaları sürüm kontrolü altında olmalıdır, aksi takdirde diğer geliştiriciler/derleme düğümleri farklı sürümlerle sonuçlanabilir. Geliştirme aşamasında bağımlılıkları güncellemeniz gerekmedikçe (örneğin güvenlik yamalarını yüklemek için) npm install kullanmaktan kaçının. Genel olarak daha belirleyici olan npm ci (Temiz Kurulum) kullanın, böylece paket yöneticisi kilit dosyasını kullanır veya kilit dosyası yoksa veya package.json ile eşleşmiyorsa hata ile sonlanır. Listelenen sürümler kötü amaçlı yazılımlara karşı kontrol edildiyse, kilit dosyası derleme zamanında kötü bir şey olmayacağından emin olmanızı sağlar.

    Dahili bileşenler için bir tane oluşturulması önerilir. NPM kapsamı Kuruluş tarafından yönetilen (örneğin @myorg) ve bu kapsamı yalnızca özel görünürlüğe sahip olabilecek bağımlılıkta (örneğin @myorg/my-private-dep) kullanan bir durum söz konusu olabilir. Bu, engelleme yapar. bağımlılık karışıklığı Saldırılar söz konusu olabilir, çünkü bu kapsamda paket yayınlayabilme yetkisi yalnızca yazma erişimine sahip kuruluş üyelerine aittir.

• • Maven:
    Maven/Gradle'ın kilit dosyaları yoktur (ancak bkz. bu StackOverflow makalesi).

    Maven/Gradle'da sürüm aralıkları diğer ekosistemlerdeki kadar sık ​​kullanılmaz. Sadece kullanmaktan kaçının. sürüm aralıkları ve EN SON veya YAYIN meta sürümleri. Dolaylı sürümler de kontrol edilmelidir. Versions Maven Eklentisi Sürüm kontrolü için güzel bir araçtır.

    Lütfen Maven'ın her zaman organizasyon kapsamı kavramına (bağımlılığın groupId kısmı) sahip olduğunu ve bağımlılık karışıklığının bu ekosistem için hiç sorun teşkil etmediğini unutmayın.

• • Ölmek:
    Python'da kilit dosyalarıyla başa çıkmak için farklı araçlar mevcuttur:

    - boruBu işlem, Pipfile.lock adlı bir kilit dosyası oluşturur.
    - şiirBu da poetry.lock dosyasını oluşturur.
    - pip dondurmaBu komut, kilit dosyası görevi gören bir requirements.txt dosyası oluşturur. Tüm bağımlılıkların sabit sürümlerini kullanıp kullanmadığını == operatörüyle kontrol edin. Ardından, pip install -r requirements.txt komutu sabit bağımlılıkları kullanır.

Yukarıdaki kilit dosyalarının sürüm kontrolü altında olması ve seçilen derleme komutunun kilit dosyasını kullanması gerektiğini hatırlatalım.

Pip ile birlikte kullanılan standart paket deposu (PyPI) isimlendirme kapsamına sahip değildir ve bağımlılık karışıklığı saldırılarına karşı savunmasızdır. Python ekosisteminde bağımlılık karmaşasından kaçınmak Bu kolay değil ve bazı yazarlar, PyPI'dan alınan genel bağımlılıklar için bir vekil görevi görecek şekilde dahili bir depo kullanmayı, ancak özel bağımlılıkları önce dahili depodan almayı önermektedir (-index-url, PyPI'ya değil, dahili depoya işaret etmeli ve –extra-index-url kaldırılmalıdır).

Bazı gerçek saldırılar

Getcookies saldırısıOyuncu dustin87, popüler npm mailparser paketine, uzaktan kod yürütme (RCE) arka kapısı içeren kötü amaçlı bir pakete (gCOMMANDhDATAi) dolaylı bir bağımlılık ekledi:

JSON.stringify(req.headers).replace(/g([a-f0-9]{4})h((?:[a-f0-9]{2})+)i/gi, (o, p, v) => {})

Kullanımdan kaldırılmış olmasına rağmen (hiçbir incelemesi yok!), mailparser hala haftalık yaklaşık 64,000 indirme alıyordu. Bu, neredeyse bir saldırıdan kurtulma vakasıydı, çünkü uzaktan kod yürütme (RCE) aslında uygulanmadı.cised.

NPM yayınlandı Bu mesaj Getcookies saldırısıyla ilgili ayrıntılarla birlikte.

Bağımlılık Karmaşası:

Alex Birsan 2021 yılında bağımlılık karmaşası sorununu keşfetti ve " başlıklı bir yazı yayınladıApple, Microsoft ve Diğer Birçok Şirkete Nasıl Sızdım? anlayışının sonucu olarak, buzdolabında iki üç günden fazla durmayan küçük şişeler elinizin altında bulunur.

Unutmayın ki npm için @myorg gibi kuruluş kapsamı ayrılmalıdır ve dahili paketler bu kapsamı kullanacak şekilde değiştirilmelidir.

Pip ile, ortak kamu kayıt defteri PyPI'da kapsamlar/ad alanları bulunmamaktadır. Her özel paket, dahili paketle aynı ada sahip ancak boş ve belki de kullanıldığında hata üretebilen bir kamu paketine sahip olabilir; böylece yanlışlıkla indirildiğinde tanımlanabilir.

Düğüm-ipc:

Rusya-Ukrayna savaşı başladığında, paket sahibi, Rus ve Belarus sunucularına yüklendiğinde rastgele dosyaları silen kötü amaçlı bir kod enjekte etti. ssl-geospec.js dosyası bu tür coğrafi ayrımı yapıyordu:

İlginç bir şekilde, popüler Vue.js çerçevesi gibi diğer paketler de node-ipc bağımlılığı için açık kaynaklı sürümler kullandı ve bunların geliştiricileri bir ödül aldı. acil çağrı node-ipc bağımlılığını güvenli bir sürüme sabitlemek.

Bu Gönderi daha fazla ayrıntı içeriyor. Bu sabotaj, diğerlerinden bir adım öteye gidiyor. Protestware sorunlar.

 

Son Sözler

Açık sürümler olmalıdır asla Konsolide yazılım projelerinde kullanılırlar. Derlemeleri tekrarlanamaz hale getirirler ve saldırganlar bunları istismar ederek, yukarıda bahsedilen bağımlılık karışıklığı gibi bağımlılık ağaçlarına yönelik saldırılar yoluyla kötü amaçlı yazılım enjekte etmeyi başarabilirler.

Yanlış yapılandırmalar gibi açık sürümler, sürüm sabitlemesinin olmaması veya kapsam dışı dahili bileşenler Bundan kaçınılmalıdır. İlk olarak, bu tür sorunları tespit etmek, hatta bulunduklarında derlemeyi engellemek ve harekete geçmek için standart bir protokol oluşturmak gerekir.

Bağımlılıklardaki hataların ve yanlış yapılandırmaların otomatik olarak tespiti, belirli tedarik zinciri saldırılarına karşı savunmasız olabilecek şüpheli bağımlılıkların raporlanması gibi. bağımlılık karışıklığıEyleme geçirilebilir düzeltme araçlarıyla birlikte, bu yaklaşımın temel hedeflerinden biri de budur. Xygeni platformu.

Daha fazla okumak için

Ohm M., Plate H., Sykosch A., Meier M.: “Arkadan Bıçaklayanın Bıçak Koleksiyonu: Açık Kaynak Yazılım Tedarik Zinciri Saldırılarının Bir İncelemesi”. DIMVA 2020. Bilgisayar Bilimleri Ders Notları, cilt 12223. Springer – 2020 (bağımlılık saldırı ağacı şeklinin kaynağı.)

@adam-npm: “Bildirilen zararlı modül: getcookiesnpm Blogu (arşivlenmiş) – 2 Mayıs 2018.

Alex Birsan: “Apple, Microsoft ve Diğer Birçok Şirkete Nasıl Sızdım?Medium – 9 Şubat 2021.

Ax Sharma: “Büyük sabotaj: Ünlü npm paketi, Ukrayna savaşına protesto amacıyla dosyaları siliyor.BleepingComputer – 17 Mart 2022