Google OAuth oturumu açma, başarısız olmuş bir startup’ın alan adını satın alma durumunda korunamıyor

• Google OAuth’taki bir güvenlik açığı, "Google ile oturum aç" kimlik doğrulama sürecinde ciddi bir zafiyet bulunduğunu gösteriyor
  • Başarısız olmuş bir startup’ın alan adını satın aldıktan sonra, o alan adının e-posta hesaplarını yeniden yapılandırarak SaaS hizmetlerinde oturum açmak mümkün
  • Hassas veriler içeren hizmetlere erişim mümkün:
    • Slack, ChatGPT, Notion, Zoom, İK sistemleri (sosyal güvenlik numarası dahil)
  • Google, ilk bildirimde bunu "amaçlanan davranış" olarak niteleyip düzeltmeyi reddetti
• Sorunun temel nedeni: Google OAuth, alan adı sahipliği değişimini algılayamıyor
  • Alan adı değiştiğinde, yeni sahip önceki çalışan hesaplarına aynı claim’lerle giriş yapabiliyor
• Kullanılan temel kimlik bilgileri:
  • hd (barındırılan alan adı): alan adı bilgisini içerir (ör. example.com)
  • email: kullanıcının e-posta adresini içerir (ör. [e-mail])
• Hizmet sağlayıcı bu iki bilgiye dayanıyorsa, alan adı sahipliği değiştiğinde aynı hesap erişimine izin veriliyor
• Sorunun ölçeği
  • ABD’de 6 milyon kişi startup’larda çalışıyor
  • Startup’ların %90’ı başarısız oluyor
  • Başarısız olan startup’ların %50’si Google Workspaces kullanıyor
• Yaklaşık 100.000 başarısız startup alan adı satın alınabilir durumda
• Ortalama olarak alan adı başına 10 çalışan ve 10 SaaS hizmeti kullanımı → 10 milyondan fazla hesapta hassas veri bulunma ihtimali

Çözüm önerileri ve Google’ın yanıtı

• Google’a önerilen çözümler:
  1. Kullanıcıya özgü benzersiz kimlik: zaman geçse de değişmeyen benzersiz bir kullanıcı tanımlayıcısı eklemek
  2. Workspace’e özgü benzersiz kimlik: alan adıyla bağlantılı benzersiz bir Workspace tanımlayıcısı eklemek
• Google’ın ilk yanıtı:
  • Eylül 2024’te bildirildi → "düzeltilemez" denilerek kapatıldı
  • Aralık 2024’te Shmoocon konferansındaki sunumun ardından Google sorunu yeniden incelemeye aldı
  • 1.337 dolarlık bug bounty ödülü verildi ve düzeltme çalışmaları başladı
• Şu an için Google düzeltme yapmadan sorunun kökten çözülmesi mümkün değil
• Bazı hizmetler, alan adı eşleştiğinde tüm kullanıcı listesini döndürdüğü için zafiyet daha da büyüyor
• Google ile giriş yerine parola kullanılsa bile sıfırlama mümkün
  • Startup’lar parola tabanlı kimlik doğrulama yerine SSO ve 2FA’yı zorunlu kılıyor
  • Hizmet sağlayıcılar parola sıfırlamada ek doğrulama istemeli (SMS kodu, kredi kartı doğrulaması)

Sonuç: Google OAuth güvenliğinde temel bir sorun

• Google’ın OAuth uygulamasındaki kusur nedeniyle alan adı sahipliği değiştiğinde hesap ele geçirme mümkün
• Google’ın düzeltme çalışmaları başlamış olsa da temel çözüm henüz tamamlanmış değil
• Şu anda milyonlarca Amerikalının verileri ve hesapları risk altında

[sixmen]

Bana göre burada, alan adını içeren e-postayı kimlik doğrulama aracı olarak kullanıp sonra alan adından vazgeçerken buna bağlı SaaS'ları düzgün şekilde devre dışı bırakmayan kullanıcı tarafının bir hatası var; yine de buna bir güvenlik açığı demek gerekir mi?

[kargnas]

Benim geliştirdiğim hizmette bu sorunu önceden engellemiştim, ama buna rağmen bu görüşe katılıyorum.
Bu bir sorunsa, normal e-posta ile giriş ve kayıt da baştan sona sorunlu sayılmalı. Sonuçta herkes e-postayı benzersiz kimlik olarak kullanıyor ve şifre sıfırlama doğrulaması da tamamen e-posta üzerinden sahipliği teyit ediyor.

Uç bir örnek olarak, gmail.com veya hotmail.com gibi ünlü alan adlarının ele geçirildiğini ve alan adının DNS ayarlarını yönetme yetkisinin saldırganın eline geçtiğini varsayarsak, doğal olarak dünya çapındaki tüm SaaS hesaplarının riske girmesi son derece olağandır.

[GN⁺]

Hacker News görüşü

• DankStartup faaliyetlerini durdurup alan adı başka biri tarafından devralındığında, mevcut hesaplara erişilebilmesi durumu DankStartup, Microsoft ve OpenAI’nin sorumluluk meselesi gibi görünüyor

  • Bunu OAuth açığı olarak açıklamak uygun değil

• Google’ın OpenID uygulamasında kimlik doğrulama için sub claim’ini kullanmak doğru yöntemdir

  • sub claim’inin değişmesi durumuna karşı bir akış gerekli
  • Önerilen “değişmeyen benzersiz kullanıcı kimliği”, sub claim’inden farklı değil

• Bu, DNS’e bağımlı yöntemlerin temel sorunu; alan adının süresi dolduktan sonra yeni sahibi önceki sahibin yetkilerine sahip olabilir

  • E-posta adresine veya DNS’e dayanan kimlik doğrulama sistemlerinde ortaya çıkabilecek bir sorun

• Google OAuth’ta bir açık yok; bir alan adını devralırsanız o alan adındaki tüm e-posta adreslerine de sahip olursunuz

  • Google OAuth kullanılmasa bile aynı sonuç ortaya çıkabilir

• Geçmişte thehunt.com vakasında alan adı devralındıktan sonra tüm hizmetlere erişilebildiğine dair deneyim paylaşılmış

  • Alan adı durumunu izleyerek güvenlik tehditlerini önleyen bir startup fikri önerilmiş

• Sorun, sub alanını kullanmayan hizmetlerde; kullanıcı tanımlamada sub alanı kullanılmalı

  • sub alanını kullanmayan hizmetlere güvenlik açığı raporu göndererek gelir elde edilebilir

• Google’ın OpenID Connect’te iki değişmez tanımlayıcı uygulaması öneriliyor

  • sub claim’i ve alan adına bağlı benzersiz workspace ID

• Google OAuth’ta sub claim’inin değişmesi nadirdir ve sorun büyük olasılıkla hizmetin implementasyonundadır

• Alan adı devralındıktan sonra e-postaya erişim sağlanan bir örnek paylaşılmış

  • Google ile olan iç bağlantılar üzerinden sorun çözülmüş

• “Milyonlarca hesap” iddiası, başarısız olmuş startup’ların SaaS hesaplarını devre dışı bırakmadığı varsayımına dayanıyor