ghrc.io’nun kötü amaçlı bir site olduğundan şüpheleniliyor

• ghcr.io ile ghrc.io arasındaki basit bir yazım hatası karışıklığı, ciddi bir güvenlik tehdidine yol açıyor
• ghrc.io ilk bakışta varsayılan bir nginx sunucusu gibi görünse de, içeride OCI API’sini taklit eden davranışlar tespit edildi
• Bu site, www-authenticate başlığı üzerinden konteyner istemcilerini hassas kimlik doğrulama bilgilerini göndermeye yönlendiriyor
• docker login gibi komutlarla yanlışlıkla kimlik bilgileri girildiğinde veya hatalı bir registry kullanıldığında kimlik bilgisi sızıntısı yaşanabilir
• Yanlış sunucuda oturum açtıysanız parolanızı değiştirmek, PAT’i iptal etmek ve GitHub hesabındaki olağan dışı etkinlikleri kontrol etmek gerekir

---

Genel bakış

Basit bir yazım hatası nedeniyle sıkça yaşanabilecek ghcr.io ile ghrc.io karışıklığı, son derece tehlikeli bir güvenlik sorununa yol açan bir örnek. Birçok geliştirici ve ekibin kullandığı GitHub Container Registry (ghcr.io)’nun yazım hatalı sürümü olan ghrc.io üzerinde kimlik bilgisi çalma girişimi tespit edildi.

ghcr.io nedir?

• ghcr.io, konteyner imajları ve OCI artifact’leri için OCI uyumlu bir registry
• GitHub’ın bir parçası olarak, çok sayıda açık kaynak projede popüler bir registry olarak kullanılıyor

ghrc.io: Yüzeyde görünenler

• ghrc.io adresine girildiğinde sıradan bir varsayılan nginx sayfası görünüyor
• Tipik 404 hataları gibi temel davranışlar açısından normal bir nginx sunucusuyla aynı

Kötü amaçlı davranışın niteliği

• Temel sorun, /v2/ öneki altındaki OCI API çağrıları sırasında ortaya çıkıyor
• Bu yola erişildiğinde, www-authenticate başlığı ve 401 yanıtıyla resmî bir konteyner registry’sine çok benzeyen bir davranış sergiliyor
• www-authenticate: Bearer realm="https://ghrc.io/token"; başlığı bulunuyor
• Bu başlık nedeniyle Docker, containerd, podman, Kubernetes gibi istemciler kullanıcı kimlik bilgilerini https://ghrc.io/token adresine otomatik olarak iletmeye çalışıyor
• Varsayılan nginx yapılandırmasında bu başlık yer almadığından, bunun açıkça kasıtlı olarak yapılandırıldığı anlaşılıyor

Risk: kimlik bilgisi çalma senaryosu

• Bu örüntü, typo-squatting tabanlı bir kimlik bilgisi çalma saldırısı olarak değerlendiriliyor
• Risk yalnızca kullanıcı istemcisinin ghrc.io için kimlik bilgilerini girmesi veya kaydetmesi durumunda ortaya çıkıyor
• Gerçek kimlik bilgilerinin açığa çıkabileceği örnek durumlar
  • docker login ghrc.io çalıştırılması
  • GitHub Action içinde docker/login-action kullanılırken registry olarak ghrc.io’nun belirtilmesi
  • Kubernetes secret içinde ghrc.io için registry kimlik bilgilerinin saklanıp imaj çekme girişiminde bulunulması
• Yalnızca ghrc.io’ya imaj push/pull etmeye çalışmak, kimlik bilgilerini açığa çıkarmaz (anonim token denemesinden sonra hata döner)

Alınması gereken önlemler

• ghrc.io’da yanlışlıkla oturum açtıysanız, hemen parolanızı değiştirin ve kullandığınız PAT (Personal Access Token)’i iptal edin
• GitHub hesabınızda olağan dışı oturum açma veya kötü amaçlı etkinlikleri mutlaka kontrol edin
• Saldırganlar bunu kullanarak ghcr.io üzerindeki depolara kötü amaçlı imaj ekleyebilir veya hesaba erişim kazanabilir

Sonuç

• ghcr.io’ya benzeyen adresleri kullanan phishing sitelerine karşı dikkatli olunmalı
• Kimlik bilgileri, token’lar ve parolalar gibi güvenlik açısından hassas verilerin yönetiminde daha sıkı bir politika gerekiyor

[ndrgrd]

Bunu doğrudan github.com alt alan adına çevirmek daha iyi olmaz mı?

[GN⁺]

Hacker News yorumu

• GitHub Container registry'nin, ayrıntılı izinlere sahip token'lar yerine yalnızca eski klasik token'ları desteklemesinin ciddi olduğu vurgulanıyor
  İlgili belge ve issue bağlantıları da eklenmiş
  Resmi belge
  Topluluk tartışması
  Roadmap issue'su

  • Bu sorun yüzünden klasik PAT'i tamamen devre dışı bırakmak mümkün değil
    Ek önlem olarak oturum süresini kısa tutup enterprise SSO ile yeniden kimlik doğrulamayı zorunlu kılmak mümkün, ancak gerçekten gereken tek bir klasik PAT için bu zahmetli bir seçenek

  • Birinin iyi niyetle tüm typo domain'leri satın alıp Microsoft'a devretmesi güzel olurdu
    Microsoft'un registry adını değiştirmesi gerektiği düşünülüyor
    İsim o kadar kafa karıştırıcı ki ben de birçok kez yazım hatası yaptım

• Domain meselesini birkaç kez okuduktan sonra ancak sorunun ne olduğunu anlayabildim; oldukça ikna edici bir saldırı vektörü

  • Sadece ben değil, birçok kişi için de durum benzer
    Defalarca denedikten sonra başarısız olunuyor, hatta bilgisayar yeniden başlatılsa bile aynı sorun yaşanıyor
    Referans olabilecek örnekler olarak Stack Overflow yanıtı ve Docker forum tartışması da verilmiş

• ghrc.io ile ilgili kod arama sonuçları bağlantı olarak sunuluyor

• Yazıda c ile r'nin yer değiştirdiği doğrudan belirtilene kadar sorunu fark etmemiştim

  • Bu, günde neredeyse 10 kereden fazla yaptığım türden bir yazım hatası

  • Buradaki sorun GitHub'ın domain adlandırmasının berbat olması
    Container registry adı gerçekten çok kötü

• Geçmiş bir Hacker News tartışma bağlantısı paylaşılıyor

• Whois ile bu domain'in dynadot üzerinden kaydedildiği görülebiliyor
  Bu nedenle [e-mail] adresine bildirmek faydalı olabilir

• Birçok açık kaynak projenin bu domain'i kullandığından bahsedilirken kod arama sonuçları da bir kez daha paylaşılıyor

  • GitHub'ın dahili olarak toplu şekilde otomatik düzeltme önerip dağıtabilecek araçlara ihtiyacı var

  • Gerçekten de GitHub kod arama sonuçlarının oldukça büyük ölçekte olduğu belirtiliyor

• CI işlerinde böyle bir yazım hatasının büyük sorunlara yol açabileceği endişesi dile getiriliyor

• Güvenlik değeri düşük TLD'lerden (üst seviye alan adları) mümkün olduğunca kaçınılması tavsiye ediliyor
  Sevimli görünme çabasından önce güvenlik gelmeli
  Kötü amaçlı domain kayıtlarının kaldırılması .com kadar hızlı olmayabilir; bu yüzden ABD'li Verisign tarafından yönetilen .comun daha güven verdiği düşünülüyor
  Britanya Hint Okyanusu Toprakları, Kolombiya veya Anguilla'ya bağımlı olmak uygun görülmüyor

  • .io TLD'sinin ABD şirketi Afilias tarafından yönetildiği de ekleniyor

• Buradaki asıl riskin token yeniden kullanımı olup olmadığı soruluyor
  Bearer token doğrudan parolayı vermiyor; RFC ve Mozilla belgelerine atıfla, sorunun aslında kimlik doğrulama token'ının kendisi değil, yeniden token alma süreci olup olmadığı merak ediliyor
  Domain'ler arası OAuth token'ı yeniden kullanmıyorsa, sonuçta sahte domain'de token alınamıyor olması gerekmez mi diye sorgulanıyor

  • Blog yazarı ve OCI maintainer'ı olarak yanıt veriyor
    Bearer token almak için yapılan istekte parola ya da PAT, Basic Authentication header'ında base64 ile kodlanarak gönderiliyor, ama fiilen düz metin gibi iletilmiş oluyor
    İstek alındığında www-authenticate header'ı dönüyor, erişim doğrulaması için kimlik doğrulama token'ı alınıyor ve bu token daha sonra süre aşımına uğruyor
    Ancak saldırganın gerçekten ele geçirdiği şey asıl token değil, Bearer token almak için istenen kimlik bilgileri oluyor