Yazılım projelerinde zamandan tasarruf sağlamak ve her geliştiricinin kendi sürümünü yazmasına ihtiyaç duymadan başka bir geliştiricinin yazmış olduğu işlevselliğe erişebilmesini sağlamak için dahili ve harici kütüphaneler bulunur. Bu kütüphaneler, genellikle farklı kod tabanları arasında belli bir düzeyde tutarlık sağladıkları test edilerek kanıtlandığı için de tercih edilir. Bir yazılım'ın çalışması için artık o kütüphane mutlaka gerekli olduğunda, kod etkili bir şekilde çalışması için bu kütüphanelere ve frameworklara bağımlı olur.

Bu bağlamda "bağımlılıklar (dependencies)", projemizin bir production veya test ortamında çalışması için gerekli olan dahili veya harici üçüncü taraf kütüphaneleri ve diğer yardımcı programları ifade eder. Bu bağımlılıklar, projenin kullanıma sunulduğunda amaçlandığı gibi çalışması için gereklidir. Yazılım geliştirmede bağımlılıkları yönetmek, sistemin istikrarlı, sürdürülebilir ve genişletilebilir olmasını sağlamak için çok önemlidir o yüzden bu bağımlıkları içeren paketleri yönetmek için her ekosisteme özel farklı paket yönetim sistemleri bulunur.  

Birçok kuruluş, sundukları açık ve geniş ekosistemlerden yararlanmak için Maven Central, npm, NuGet Gallery ve Python Package Index (PyPI) gibi herkese açık paket yönetim sistemlerini kullanır. Birden fazla harici ve dahili paket yönetim sisteminden bağımlılık indiren projeler, bu hibrit yapılandırmalara özgü bazı tedarik zinciri güvenlik açıklarına maruz kalabilir ve bilinçli bir kuruluşu bile tehlikeye atabilecek yeni tehditler ortaya çıkar. Kuruluşlar bu küratörsüz beslemeleri potansiyel bir güvenlik tehditi olarak ele almadığında da tedarik zinciri güvenlik riskleri oluşur.

• Harici Bağımlılıklar: Üçüncü taraflardan satın alınan veya halka açık (open source) kaynaklardan indirilen paketler

• Dahili Bağımlılıklar: Şirket içinde geliştirilen bireysel paketler

"Dependency Confusion"

Paket yönetim sistemleri genellikle bağımlıklıkların indirileceği birden fazla kaynağın belirtilmesine izin vererek harici ve dahili dizinlerden ulaşılmasını kolaylaştırır. Bu hibrit yapılandırma, paket yönetim sistemlerinin bağımlılıkların adlarını birden fazla kaynakta nasıl çözümlediğine bağlı olarak saldırganların güvenli altyapı üzerinden sistemlerinize girmeleri için yeni yollar sağlayabilir.

Geliştiricilerin kullandığı yaygın hibrit yapılandırma, dahili bağımlıkları şirket için bir repository'de depolamak ancak aynı zamanda harici bir paket yönetim sistemine ait repository'den bağımlılıkların indirilmesine de izin vermektir.

Geliştiriciler bağımlıklıklarını bu özel repository'de yayınlar ve gerekli paketlerin en iyi ve yeni mevcut sürümleri için güncelleme yaparken hem dahili hem de harici repository'leri kontrol eder. Bu hatalı yapılandırma, "Dependency Confusion" adı verilen bir tedarik zinciri saldırı vektörü sunar.

Bu aşamada saldırganlar, genel paket registry’sinde normalde dahili olan paketle aynı isme sahip zararlı bir paket oluşturur. Saldırgan, dahili paketin daha yüksek bir sürümünü registry’e yükledikten sonra aynı isme sahip olduğu için otomatik olarak indirilir. Benzer etkiye sahip bir risk, paket yayıncısının (maintainer) kimlik bilgilerinin ele geçirilmesi durumunda da ortaya çıkabilir. Yazının devamında “Dependency Confusion” zafiyetini ve paket yayıncısının kimlik bilgilerinin ele geçirebilmesine izin veren diğer zafiyetlerin bir saldırganın gözünden nasıl keşfedeceğimizi, nasıl faydalanacağımızı, bunun için kullanabileceğimiz araçlardan ve bu zafiyetlere karşı kendimizi nasıl koruyabileceğimizden bahsedeceğiz. 

Nuclei Template

Saldırgan package.json, manifest.json, requirements.txt, composer.json, pom.xml, package-lock.json, Gemfile.lock,nuget.config  dosyalarında bağımlılık adlarını bulabilir. Bu dosyaları web sunucularının kök dizinlerinde bulmak için aşağıdaki nuclei template’i kullanılabilir. 

id: dependency-configuration-file

info:
  name: Dependency Configuration File Detected
  author: cybersec.zip
  severity: medium
  description:
  reference:
	- https://github.com/visma-prodsec/confused
	- https://github.com/visma-prodsec/ConfusedDotnet
  tags: dependency,confusion,supply,chain

requests:
  - method: GET
	host-redirects: true
	max-redirects: 3
	path:
  	- "{{BaseURL}}/package.json"
  	- "{{BaseURL}}/manifest.json"
  	- "{{BaseURL}}/requirements.txt"
  	- "{{BaseURL}}/composer.json"
  	- "{{BaseURL}}/pom.xml"
  	- "{{BaseURL}}/package-lock.json"
  	- "{{BaseURL}}/Gemfile.lock"
  	- "{{BaseURL}}/nuget.config"

	matchers:
  	- type: word
    	words:
      	- "devDependencies"
      	- "dependencies"
      	- "<configuration>"
      	- "<packageSources>"
      	- "require"
      	- "version"
    	condition: or

  	- type: status
    	status:
      	- 200

Burp Eklentisi: JS Miner

Bağımlılık isimleri hata mesajlarında ve uygulamaya ait Javascript dosyalarında da bulunabilir. Javascript dosyalarından ve hata mesajlarından ayrıştırılan bu bağımlılıkları otomatik olarak kontrol etmek için Burp Suite'in JS Miner eklentisi kullanılabilir. Bu eklenti paketin ve kuruluşun kaydını kontrol eder.

Confused

Python (pypi) requirements.txt, JavaScript (npm) package.json, PHP (composer) composer.json veya MVN (maven) pom.xml için bağımlılık yapılandırmasında başvurulan özel bağımlılık adlarını Dependency Confusion zafiyetine karşı kontrol etmek için bir araçtır.

confused basitçe bir uygulamanın bağımlılık tanım dosyasını okur ve bu dosyadaki her bir bağımlılık girdisi için genel paket depolarını kontrol eder. Genel depolarda bulunmayan tüm paket adlarını bildirir - bu durum, bir paketin bu tür bir saldırıya karşı savunmasız olabileceğini ima eder, ancak bu vektör henüz istismar edilmemiştir.

.NET Projeleri Özelinde “Dependency Confusion” ve ConfusedDotnet Aracı

“Dependency Confusion” sadece JavaScript, Python ve Ruby'yi etkilemeyen çok ciddi bir konudur. MyGet gibi çoğu üçüncü taraf deposu nuget.org'u proxy olarak yapılandırmaya izin verdiği için .NET ekosistemi de bu zafiyete karşı savunmasızdır.

Zafiyetli nuget.config’e örnek 1 (varsayılan):

Örneğin Corporate.Private.Library adında bir bağımlılık var ancak, bu bağımlılık Nuget’de bulunmuyor. Nuget.config’e kaynak olarak sadece nuget eklendiğinde bağımlılık buradan yüklenmeye çalışacak. 

Zafiyetli nuget.config’e örnek 2 (Hibrit):

Örneğin Corporate.Private.Library adında bir bağımlılık var ancak, nuget.config’de sourcemapping yapılmadan kaynak olarak hibrit olarak hem nuget.org hem de dahili kaynak eklenmiş. 

ConfusedDotnet

Nuget (nuget) packages.config veya yeni PackageReference stili için bağımlılık yapılandırmasında başvurulan özel paket adları için boş adları kontrol etmek için bir araçtır. 

Kişisel E-postaların Kullanımının Oluşturduğu “Yeni” Güvenlik Boşlukları

Maintainer Hesaplarında Kendi Alan Adıyla Bir E-postaya Sahip Olma Eğilimi

Maintainer hesaplarının nasıl ele geçirileceğine dair dikkate değer bir örneği 2022 yılında güvenlik araştırmacısı Matthew Bryant tarafından açıklanmış ve saldırganların npm maintainer hesaplarını, bu hesaplarla ilişkili süresi dolmuş e-posta alan adlarından yararlanarak nasıl ele geçirebileceklerini anlatmıştır. Bir maintainer’ın e-posta alan adının süresi dolarsa, bir saldırgan bunu satın alarak parola sıfırlamayı tetikleyebilir ve hesaba erişim sağlayabilir. İçeri girdikten sonra saldırganlar, kullanıcıların bilmeden dahil edebileceği paketlere kötü amaçlı kod yükleyebilir.

Npm deposunda tüm kullanıcıların e-posta adresleri herkese açıktır. Örneğin, kendi kullanıcı kendi profil sayfasını çağırdığında o hesaba tanımlı e-posta adresi de döner. 

https://registry.npmjs.org/bagimlilikadi

Bir saldırgan bunu kullanarak bir npm paketinin tüm maintainer’larının e-postalarını listeleyebilir ve bunları örneğin hedefli bir oltalama kampanyasında kullanabilir. Ancak, araştırmacı burada dikkate alınması gereken yeni bir ihtimali ortaya çıkarmaktadır. 

Pek çok geliştirici, kendi alan adıyla bir e-postaya sahip olma eğilimindedir. Bu alan adı ile biten özel e-postalar, npm deposundaki geliştirici hesaplarında da kullanılır. Ana e-posta adresi olarak özel bir alan adı kaydettirip kullanan geliştiriciler, bu alan adına ve TLD'ye çevrimiçi hesaplarının çoğu üzerinde tam kontrol vermiş olurlar. Genellikle bir kişinin e-posta hesabını kontrol edebiliyorsak, npm’de dahil her site için parola sıfırlama işlemini başlatıp tamamlayarak çevrimiçi hesaplarına erişebilirsiniz. 

Süresi Dolmuş Alan Adlarında Barındırılan E-postaları Ele Geçirme ve Parola Sıfırlama Bağlantısı Alma

Alan adlarını tahsis etmek ücretsiz değildir ve onları kontrolümüz altında tutmak için sürekli olarak bir ücret ödememiz gerekir. Yeterince uzun bir süre boyunca bu durum sorun yaratabilir çünkü çoğu zaman bu alan adlarının süresi dolabilir ve başkaları tarafından tescil edilebilir hale gelebilir. npm paketlerinin maintainer’larından herhangi birinin süresi dolmuş alan adlarında barındırılan e-postaları varsa bu o hesabın ele geçirilebileceği anlamına gelir. 

GitHub’daki Yedek E-posta Adresi Varsayılan Ayarlarda Parola Sıfırlamaları İçin de Kullanılabiliyor

GitHub'ın çoklu e-posta özelliği, ikincil ve süresi dolmuş bir e-postanın hesaba bağlı kalmasına izin verir ve parola sıfırlama bağlantısı gönderiminin, birincil e-posta’ya erişim olmasa bile süresi dolmuş e-posta alan adı için çalışmasını sağlar. Bunun sebebi aşağıdaki şekilde Backup email adress ayarı için Allow all verified emails seçeneğinin ayarlanmasıdır. 

Aşağıdaki araçlar kullanarak şirketlerin GitHub contributor’larının e-posta adresleri toplanabilir ve süresi dolmuş alan adları tespit edilebilir. Süresi dolmuş bir e-posta alan adına sahip bir contributor hesabı ortaya çıktığı ve hesap kuruluş içinde aktif kaldığı durumlarda yukarıdaki mantık izlenerek parola sıfırlama bağlantısı elde edilerek şirketin Private repolarına erişilebilir. 

• https://github.com/paulirish/github-email 

• https://github.com/vulnbe/github-osint 

• https://github.com/s0md3v/Zen

• https://github.com/x1sec/commit-stream 

• https://github.com/hodgesmr/FindGitHubEmail 

Outlook.com ve Hotmail.com İle Biten E-postalardaki Güvenlik Boşluğu

Microsoft, 270 günden uzun süredir aktif olmayan tüm Hotmail, Windows Live ve Outlook hesaplarını devre dışı bırakıyordu ve kullanıcının son oturum açmasının üzerinden bir yıl geçtikten sonra e-posta adresleri kalıcı olarak silinerek, yeni kullanıcılar tarafından kullanılabilir hale geliyordu. Halen geçerliliğini koruyup korumadığı bilinmeyen bir politika olmasıyla birlikte, bu durumdan 2013-2021 tarihleri arasında zaman aşımına uğrayan ve yukarıdaki koşulları sağlayan hesaplar tekrar kullanılabilir halde. 

• https://www.lifewire.com/hotmail-account-expiration-1174279

• https://blog.en.uptodown.com/microsoft-will-recycle-inactive-hotmail-outlook-and-live-email-accounts/ 

Eğer maintainer hesaplarından biri outlook.com veya hotmail.com ise, bu e-posta adresi de benzer durumdan etkileniyor olabilir ve maintainer hesabının ele geçirilmesine yine izin verebilir. 

"npm_domain_check" ve "hijagger" Araçları

Bu araçlar, belirli bir npm paketinin alan adı ele geçirmeye yani yukarıda bahsi geçen saldırılara açık olup olmadığını kontrol eder (doğrudan veya diğer bağımlılıklar üzerinde)

• https://github.com/firefart/hijagger

• https://github.com/jfrog/npm_domain_check

Çözüm Önerileri

• Genel kullanım için tasarlanmamış olsalar bile dahili paket adlarını genel depolara kaydedin. Bu, saldırganların bu adları talep etmesini ve kötü amaçlı paketler yayınlamasını önler.

• Paket yöneticisini tek bir paket deposuna başvuracak şekilde yapılandırın.

• “nuget restore - -locked-mode” komutunu kullanın  ve oluşturulan packages.lock.json dosyasını projenize ekleyin.

• package-lock.json dosyasını projenize ekleyin ve herhangi bir yükseltme yapmadan eşleşen paketleri yüklemek için “npm ci” kullanın.

Referanslar

1. https://www.lifewire.com/hotmail-account-expiration-1174279 (Know When Your Windows Live Hotmail Account Expires)

2. https://blog.en.uptodown.com/microsoft-will-recycle-inactive-hotmail-outlook-and-live-email-accounts/ (Microsoft will recycle inactive Hotmail, Outlook, and Live email accounts)

3. https://www.blazeinfosec.com/post/dependency-confusion-exploitation/

4. https://github.com/visma-prodsec/ConfusedDotnet

5. https://github.com/visma-prodsec/confused

6. https://speakerdeck.com/dotnetday/dot-net-day-22-dependency-confusion-and-its-cure-a-nuget-story-by-andrei-epure

7. https://web.archive.org/web/20240703220801/https://azure.microsoft.com/mediahandler/files/resourcefiles/3-ways-to-mitigate-risk-using-private-package-feeds/3%20Ways%20to%20Mitigate%20Risk%20When%20Using%20Private%20Package%20Feeds%20-%20v1.0.pdf

8. https://dhiyaneshgeek.github.io/web/security/2021/09/04/dependency-confusion/

9. https://thehackerblog.com/zero-days-without-incident-compromising-angular-via-expired-npm-publisher-email-domains-7kZplW4x/

10. https://www.landh.tech/blog/20241107-10-to-hack-millions-of-companies/

11. https://medium.com/@ibm_ptc_security/dependency-confusion-supply-chain-attacks-a4f4494619b0