GCP <--> Workspace Pivoting
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Google Workspace'in Alan Genel delegasyonu, bir kimlik nesnesinin, ya bir harici uygulama (Google Workspace Marketplace'ten) ya da bir iç GCP Hizmet Hesabı olarak, kullanıcılar adına Workspace genelinde verilere erişmesine olanak tanır.
Bu, temelde GCP projeleri içindeki hizmet hesaplarının, aynı organizasyondaki (veya farklı bir organizasyondaki) Workspace kullanıcılarını taklit edebilme yeteneğine sahip olabileceği anlamına gelir.
Bu işlemin tam olarak nasıl çalıştığı hakkında daha fazla bilgi için kontrol edin:
GCP - Understanding Domain-Wide DelegationEğer bir saldırgan GCP üzerinde bazı erişimleri ele geçirmişse ve şirketin geçerli bir Workspace kullanıcı e-posta adresini (tercihen süper admin) biliyorsa, erişim sağladığı tüm projeleri listeleyebilir, projelerin tüm SA'lerini listeleyebilir, hangi hizmet hesaplarına erişimi olduğunu kontrol edebilir ve her SA ile bu adımları tekrarlayabilir. Elde ettiği tüm hizmet hesaplarının listesi ve Workspace e-posta adresleri ile, saldırgan her hizmet hesabı ile kullanıcıyı taklit etmeye çalışabilir.
Alan genel delegasyonu yapılandırılırken hiçbir Workspace kullanıcısına ihtiyaç olmadığını unutmayın, bu nedenle sadece bir geçerli kullanıcı bilmek yeterlidir ve taklit için gereklidir. Ancak, taklit edilen kullanıcının ayrıcalıkları kullanılacaktır, bu nedenle eğer Süper Admin ise her şeye erişebileceksiniz. Eğer hiçbir erişimi yoksa bu işe yaramaz.
Bu basit script, delegasyon yapılmış kullanıcı olarak bir OAuth token'ı oluşturacaktır ve bunu gcloud ile ya da onsuz diğer Google API'lerine erişmek için kullanabilirsiniz:
Bu, aşağıdaki adımları izleyerek saldırı gerçekleştirebilen bir araçtır:
GCP Projelerini Sayma Resource Manager API kullanarak.
Her proje kaynağı üzerinde yineleme yaparak, ilk IAM kullanıcısının erişim sağladığı GCP Hizmet hesabı kaynaklarını sayma GetIAMPolicy kullanarak.
Her hizmet hesabı rolü üzerinde yineleme yaparak, hedef hizmet hesabı kaynağında serviceAccountKeys.create iznine sahip yerleşik, temel ve özel rolleri bulma. Editor rolünün bu izne doğal olarak sahip olduğu belirtilmelidir.
IAM politikasında ilgili izne sahip bulunan her hizmet hesabı kaynağı için yeni bir KEY_ALG_RSA_2048 özel anahtar oluşturma.
Her yeni hizmet hesabı üzerinde yineleme yaparak ve bunun için bir JWT nesnesi oluşturma; bu nesne SA özel anahtar kimlik bilgileri ve bir OAuth kapsamından oluşur. Yeni bir JWT nesnesi oluşturma süreci, oauth_scopes.txt listesindeki tüm mevcut OAuth kapsamı kombinasyonları üzerinde yineleme yaparak tüm delege etme olasılıklarını bulacaktır. oauth_scopes.txt listesi, Workspace kimliklerini kötüye kullanmak için ilgili bulduğumuz tüm OAuth kapsamlarıyla güncellenmiştir.
_make_authorization_grant_assertion metodu, DWD altında JWT'ler oluşturmak için bir target workspace user olarak adlandırılan subject tanımlamanın gerekliliğini ortaya koyar. Bu, belirli bir kullanıcı gerektiriyormuş gibi görünse de, DWD'nin bir alan içindeki her kimliği etkilediğini anlamak önemlidir. Sonuç olarak, herhangi bir alan kullanıcısı için bir JWT oluşturmak, o alandaki tüm kimlikleri etkiler; bu, kombinasyon sayma kontrolümüzle tutarlıdır. Kısacası, ilerlemek için bir geçerli Workspace kullanıcısı yeterlidir.
Bu kullanıcı, DeleFriend’in config.yaml dosyasında tanımlanabilir. Hedef bir workspace kullanıcısı henüz bilinmiyorsa, araç, GCP projelerinde rolleri olan alan kullanıcılarını tarayarak geçerli workspace kullanıcılarının otomatik olarak tanımlanmasını kolaylaştırır. JWT'lerin alan spesifik olduğunu ve her kullanıcı için üretilmediğini (tekrar) belirtmek önemlidir; bu nedenle, otomatik süreç her alan için tek bir benzersiz kimliği hedef alır.
Her JWT için yeni bir bearer erişim token'ı sayma ve token'ı tokeninfo API'sine karşı doğrulama.
Gitlab, SA kimlik bilgileri ve taklit edilecek kullanıcı ile birlikte bir json belirterek kullanıcı dizinini listeleyip yeni bir yönetici hesabı oluşturabilen bu Python scriptini oluşturmuştur. İşte nasıl kullanacağınız:
Domain Wide Delegations'ı kontrol etmek mümkündür https://admin.google.com/u/1/ac/owl/domainwidedelegation.
GCP projesinde hizmet hesapları oluşturma yeteneğine ve GWS için süper yönetici ayrıcalığına sahip bir saldırgan, SAs'ın bazı GWS kullanıcılarını taklit etmesine izin veren yeni bir delegasyon oluşturabilir:
Yeni Bir Hizmet Hesabı ve İlgili Anahtar Çifti Oluşturma: GCP'de, yeni hizmet hesabı kaynakları ya konsol aracılığıyla etkileşimli olarak ya da doğrudan API çağrıları ve CLI araçları kullanılarak programlı olarak üretilebilir. Bu, iam.serviceAccountAdmin rolünü veya iam.serviceAccounts.create izinine sahip herhangi bir özel rolü gerektirir. Hizmet hesabı oluşturulduktan sonra, ilişkili bir anahtar çifti oluşturmak için ilerleyeceğiz (iam.serviceAccountKeys.create izni).
Yeni delegasyonun oluşturulması: Sadece Süper Yönetici rolünün Google Workspace'te küresel Domain-Wide delegasyonu kurma yeteneğine sahip olduğunu anlamak önemlidir ve Domain-Wide delegasyonu programlı olarak kurulamaz, yalnızca Google Workspace konsolu aracılığıyla manuel olarak oluşturulabilir ve ayarlanabilir.
Kuralın oluşturulması, API kontrolleri → Google Workspace Yönetici konsolunda Domain-Wide delegasyonu yönet sayfasında bulunabilir.
OAuth kapsamı ayrıcalıklarının eklenmesi: Yeni bir delegasyon yapılandırırken, Google yalnızca 2 parametre gerektirir: GCP Hizmet Hesabı kaynağının OAuth ID'si olan İstemci Kimliği ve delegasyonun gerektirdiği API çağrılarını tanımlayan OAuth kapsamları.
OAuth kapsamlarının tam listesi burada bulunabilir, ancak burada bir öneri: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Hedef kimliği adına hareket etme: Bu noktada, GWS'de işlevsel bir delegasyon nesnesine sahibiz. Artık, GCP Hizmet Hesabı özel anahtarını kullanarak API çağrıları gerçekleştirebiliriz (OAuth kapsamı parametresinde tanımlanan kapsamda) ve Google Workspace'te mevcut olan herhangi bir kimlik adına hareket edebiliriz. Öğrendiğimiz gibi, hizmet hesabı ihtiyaçlarına göre ve REST API uygulamalarına sahip olduğu izinlere göre erişim belirteçleri üretecektir.
Bu delegasyonu kullanmak için bazı araçlar için önceki bölüme bakın.
OAuth SA ID'si küreseldir ve kurumsal dışı delegasyon için kullanılabilir. Küresel delegasyonu önlemek için herhangi bir kısıtlama uygulanmamıştır. Basitçe ifade etmek gerekirse, farklı GCP organizasyonlarından hizmet hesapları, diğer Workspace organizasyonlarında domain-wide delegasyonu yapılandırmak için kullanılabilir. Bu, sadece Workspace'e Süper Yönetici erişimi gerektirecektir ve aynı GCP hesabına erişim gerektirmeyecektir, çünkü saldırgan kendi kontrolündeki GCP hesabında Hizmet Hesapları ve özel anahtarlar oluşturabilir.
Varsayılan olarak Workspace kullanıcıları yeni projeler oluşturma iznine sahiptir ve yeni bir proje oluşturulduğunda oluşturucu, üzerinde Sahip rolü alır.
Bu nedenle, bir kullanıcı bir proje oluşturabilir, yeni projesinde Workspace'i listelemek için API'leri etkinleştirebilir ve listelemeye çalışabilir.
Bir kullanıcının Workspace'i listeleyebilmesi için yeterli Workspace izinlerine de sahip olması gerekir (her kullanıcı dizini listeleyemez).
Daha fazla numaralandırma için kontrol edin:
GCP - IAM, Principals & Org Policies EnumGiriş yapmak için gcloud akışı hakkında daha fazla bilgi bulabilirsiniz:
Orada açıklandığı gibi, gcloud https://www.googleapis.com/auth/drive kapsamını talep edebilir, bu da bir kullanıcının sürücüsüne erişmesine izin verir.
Bir saldırgan olarak, eğer bir kullanıcının bilgisayarını fiziksel olarak ele geçirdiyseniz ve kullanıcı hala hesabıyla oturum açmışsa, sürücüye erişim sağlayan bir token oluşturarak giriş yapabilirsiniz:
Eğer bir saldırgan bir kullanıcının bilgisayarını ele geçirirse, google-cloud-sdk/lib/googlecloudsdk/core/config.py dosyasını da değiştirebilir ve CLOUDSDK_SCOPES içine 'https://www.googleapis.com/auth/drive' kapsamını ekleyebilir:
Bu nedenle, kullanıcı bir sonraki giriş yaptığında, saldırganın drive'a erişmek için kötüye kullanabileceği drive erişimine sahip bir token oluşturacaktır. Açıkça, tarayıcı oluşturulan token'ın drive'a erişimi olacağını gösterecektir, ancak kullanıcı kendisi gcloud auth login çağrısını yapacağı için muhtemelen hiçbir şeyden şüphelenmeyecektir.
Drive dosyalarını listelemek için: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Eğer bir saldırgan GWS üzerinde tam erişime sahipse, GCP üzerinde ayrıcalıklı erişime sahip gruplara veya kullanıcılara erişebilecektir, bu nedenle GWS'den GCP'ye geçiş genellikle daha "basit"dir çünkü GWS'deki kullanıcılar GCP üzerinde yüksek ayrıcalıklara sahiptir.
Varsayılan olarak kullanıcılar Organizasyonun Workspace gruplarına serbestçe katılabilir ve bu gruplar GCP izinlerine sahip olabilir (gruplarınızı https://groups.google.com/ adresinde kontrol edin).
google groups privesc'i kötüye kullanarak, GCP'ye bazı türde ayrıcalıklı erişimi olan bir gruba yükseltme yapabilirsiniz.
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
