- GitHub'da silinmiş fork'ların, silinmiş depoların ve hatta özel depoların verilerine erişmek mümkün
- Bu durum GitHub tarafından biliniyor ve kasıtlı olarak bu şekilde tasarlanmış
- GitHub kullanan tüm kuruluşlar için devasa bir saldırı vektörü oluşturduğu için "cross-fork object references (CFOR)" adında yeni bir terim ortaya atılıyor
- Bir depodaki fork'un, başka bir fork'taki kritik verilere (özel ve silinmiş fork'lardaki veriler dahil) erişebilmesi durumunda CFOR zafiyeti ortaya çıkıyor
Silinmiş fork verilerine erişmek
- GitHub'daki tipik bir iş akışını düşünün: herkese açık bir depoyu fork'luyorsunuz, fork üzerinde koda commit atıyorsunuz ve ardından fork'u siliyorsunuz
- Fork'a commit edilen kod hâlâ erişilebilir durumda kalıyor ve sonsuza kadar erişilebilir olabiliyor
- Commit hash'ini bilmenin bir koruma sağladığı düşünülebilir, ancak bu hash bulunabiliyor
- Silinmiş fork'lardan veri bulmak oldukça sık yaşanan bir durum
Silinmiş depo verilerine erişmek
- GitHub'da herkese açık bir deponuz olduğunu, bir kullanıcının bu depoyu fork'ladığını, fork'tan sonra veri commit ettiğini ve ardından tüm depoyu sildiğini düşünün
- Fork sonrasında commit edilen kod hâlâ erişilebilir durumda kalıyor
- GitHub, depoları ve fork'ları bir depo ağı içinde tutuyor ve orijinal "upstream" depo kök düğüm görevi görüyor
- Fork'lanmış herkese açık "upstream" depo "silindiğinde", GitHub kök düğüm rolünü aşağı akıştaki fork'lardan birine yeniden atıyor
- Ancak "upstream" deponun tüm commit'leri hâlâ varlığını sürdürüyor ve tüm fork'lar üzerinden erişilebiliyor
Özel depo verilerine erişmek
- GitHub'da yeni bir aracı açık kaynak yapmaya yönelik tipik bir iş akışını düşünün
- Sonunda herkese açılacak özel bir depo oluşturuluyor, ardından bu deponun özel bir iç sürümü (fork üzerinden) oluşturuluyor, yayımlanmayacak özellikler için ek kod commit ediliyor, sonra da "upstream" depo herkese açılıp fork özel tutuluyor
- Özel özellikler ve ilişkili kodun (2. adımdaki) herkese açık şekilde görülebilir olup olmadığı, herkese açık depo üzerinden erişilerek anlaşılabiliyor
- "Upstream" depo herkese açıldıktan sonra özel fork'a commit edilen hiçbir şey görülemiyor
Verilere pratikte nasıl erişiliyor?
- Doğrudan commit'e erişerek
- GitHub'ın depo ağındaki yıkıcı işlemler (yukarıda bahsedilen 3 senaryo gibi), standart GitHub arayüzünde ve normal
git işlemlerinde commit verisine olan referansları kaldırıyor
- Ancak bu veriler hâlâ mevcut ve (commit hash'i biliniyorsa) erişilebiliyor
- Commit hash'i bir SHA-1 değeridir; kullanıcı görmek istediği belirli commit'in SHA-1 commit hash'ini biliyorsa,
https://github.com/<user/org>/…; uç noktası üzerinden doğrudan o commit'e gidebilir
- Commit hash'leri GitHub arayüzü üzerinden brute-force ile bulunabiliyor
- Commit hash'leri GitHub'ın public events API uç noktası üzerinden de sorgulanabiliyor
GitHub'ın politikası
- Bu bulgular kısa süre önce GitHub'ın VDP programı üzerinden bildirildi ve GitHub, depoların bu şekilde çalışmasının tasarım gereği olduğunu açıkça belirtti
- Dokümantasyon incelendiğinde, GitHub'ın yukarıda belgelenen durumlarda kullanıcıların ne beklemesi gerektiğini açık biçimde dokümante ettiği görülüyor
Etkiler
- En az bir fork var olduğu sürece, o depo ağındaki tüm commit'ler ("upstream" depodaki veya "downstream" fork'lardaki commit'ler) sonsuza kadar var olmaya devam edecek
- GitHub'ın depo mimarisi bu tasarım kusurunu zorunlu kılıyor ve GitHub kullanıcılarının büyük çoğunluğu depo ağlarının gerçekte nasıl çalıştığını anlamadığı için daha az güvende olacak
- Secret scanning geliştikçe ve depo ağındaki tüm commit'ler taranabilir hâle geldikçe, kullanıcılar kendilerine ait olmayan secret'lar için uyarı alabilecek
- Bu 3 senaryo çarpıcı olsa da GitHub'ın depolardan silinmiş verileri saklayabildiği tüm yolları kapsamıyor
GN⁺'ün görüşü
- Bu yazı, GitHub kullanan kuruluşlar için önemli bir güvenlik sorununu gündeme getiriyor. Silinmiş veya özel olarak ayarlanmış depolardaki verilerin hâlâ erişilebilir olması sarsıcı. Bu, GitHub'ın depo ağı mimarisinden kaynaklanan temel bir tasarım kusuru gibi görünüyor
- Geliştiriciler bu sorunun farkında olmalı ve GitHub'a kritik veri ya da secret commit ederken dikkatli davranmalı. Bir kez herkese açık bir depoya push edildiğinde, sonsuza kadar erişilebilir olabilir. Kritik bir secret sızdırıldıysa, bu durum ancak anahtar rotasyonu ile tamamen çözülebilir
- GitHub bu sorunu şeffaf biçimde açıklıyor ve dokümante ediyor, ancak kullanıcıların büyük çoğunluğu depo ağlarının nasıl çalıştığını tam olarak anlamayacak. GitHub, bu konuda farkındalık yaratmak ve kullanıcıları eğitmek için daha fazla çaba göstermeli
- Benzer sorunlar başka sürüm kontrol sistemlerinde de bulunabilir. Geliştiriciler ve kuruluşlar, kritik verileri yönetirken kullandıkları araçların mimarisini ve sınırlarını iyi anlamalı
- Kritik verilerin sızmasını önlemek için sıkı erişim kontrolü, en az ayrıcalık ilkesinin uygulanması, düzenli secret scanning ve izleme gibi çok katmanlı güvenlik önlemleri gerekiyor. Her şeyden önce geliştiricilerin yüksek güvenlik farkındalığı kritik önem taşıyor
1 yorum
Hacker News görüşleri