GCP <--> Workspace Pivoting
GCP'den GWS'ye
Alan Geniş Yetkilendirme Temelleri
Google Workspace'in Alan Geniş Yetkilendirme özelliği, bir harici uygulama (Google Workspace Marketplace'den) veya iç GCP Hizmet Hesabı kimlik nesnesinin, kullanıcılar adına Workspace üzerindeki verilere erişmesine izin verir.
Bu temelde, bir organizasyonun GCP projelerindeki hizmet hesapları, aynı organizasyonun (veya farklı bir organizasyonun) Workspace kullanıcılarını taklit edebilir demektir.
Bu nasıl çalıştığı hakkında daha fazla bilgi için şuraya bakın:
GCP - Understanding Domain-Wide DelegationMevcut yetkilendirmeyi ele geçirme
Eğer bir saldırgan GCP üzerinde bazı erişimleri ele geçirdiyse ve şirketin geçerli bir Workspace kullanıcı e-postasını (tercihen süper yönetici) bildiği durumda, erişimi olan tüm projeleri sıralayabilir, projelerin tüm hizmet hesaplarını sıralayabilir, hangi hizmet hesaplarına erişimi olduğunu kontrol edebilir ve her bir hizmet hesabı ile bu adımları tekrarlayabilir. Erişime sahip olduğu tüm hizmet hesaplarının listesi ve Workspace e-postalarının listesi ile saldırgan, her bir hizmet hesabı ile kullanıcıyı taklit etmeyi deneyebilir.
Alan geniş yetkilendirme yapılandırılırken bir Workspace kullanıcısına ihtiyaç duyulmaz, bu nedenle sadece geçerli bir tanesini bilmek yeterli ve taklit için gereklidir. Ancak, taklit edilen kullanıcının yetkileri kullanılacaktır, bu nedenle Süper Yönetici ise her şeye erişebilirsiniz. Eğer hiçbir erişimi yoksa bu işe yaramaz olacaktır.
Bu basit betik, delege edilen kullanıcı olarak bir OAuth jetonu oluşturacak ve ardından bu jetonu gcloud
ile veya olmadan diğer Google API'larına erişmek için kullanabilirsiniz:
Bu, aşağıdaki adımları izleyerek saldırı gerçekleştirebilen bir araçtır:
Kaynak Yöneticisi API'sını kullanarak GCP Projelerini Numaralandırın.
Her proje kaynağında döngü oluşturun ve başlangıç IAM kullanıcısının erişimi olan GCP Hizmet hesabı kaynaklarını numaralandırın.
Her hizmet hesabı rolünde döngü oluşturun ve hedef hizmet hesabı kaynağında serviceAccountKeys.create iznine sahip yerleşik, temel ve özel rolleri bulun. Editör rolünün bu izne sahip olduğu unutulmamalıdır.
IAM politikasında ilgili izne sahip bulunan her hizmet hesabı kaynağı için yeni bir
KEY_ALG_RSA_2048
özel anahtarı oluşturun.Her yeni hizmet hesabı üzerinde döngü oluşturun ve onun için bir
JWT
nesnesi oluşturun. Bu, hedeflenen hizmet hesabı kaynağında serviceAccountKeys.create iznine sahip bulunan tüm OAuth kapsamı kombinasyonlarını bulmak için oauth_scopes.txt listesinden tüm mevcut OAuth kapsamlarında döngü oluşturacak. oauth_scopes.txt listesi, Workspace kimliklerini kötüye kullanmak için uygun bulduğumuz tüm OAuth kapsamları ile güncellenir._make_authorization_grant_assertion
yöntemi, DWD altında JWT'ler oluşturmak için bir hedef çalışma alanı kullanıcısını belirtme gerekliliğini ortaya çıkarır. Bu belirli bir kullanıcı gerektiriyor gibi görünse de, DWD, bir alan içindeki her kimliği etkiler. Dolayısıyla, herhangi bir alan kullanıcısı için bir JWT oluşturmak, kombinasyon numaralama kontrolümüzle tutarlı olarak, o alanın tüm kimliklerini etkiler. Basitçe söylemek gerekirse, ilerlemek için tek geçerli bir Workspace kullanıcısı yeterlidir. Bu kullanıcı, DeleFriend'in config.yaml dosyasında tanımlanabilir. Eğer hedef çalışma alanı kullanıcısı zaten bilinmiyorsa, araç, GCP projelerinde rolleri olan alan kullanıcılarını tarayarak geçerli çalışma alanı kullanıcılarını otomatik olarak tanımlamayı kolaylaştırır. (Tekrar belirtmek gerekirse) JWT'ler alan özgülüğünde olup her kullanıcı için oluşturulmaz; bu nedenle otomatik süreç, her alan için tek bir benzersiz kimliği hedefler.Her JWT için yeni bir taşıyıcı erişim belirteci numaralandırın ve oluşturun ve belirteci tokeninfo API'sine karşı doğrulayın.
Gitlab, kullanıcı dizinini listelemek ve bir json ile SA kimlik bilgilerini ve taklit edilecek kullanıcıyı belirterek yeni bir yönetici hesabı oluşturmak için bu Python betiğini oluşturmuştur. İşte nasıl kullanacağınız:
Yeni bir yetkilendirme oluşturun (Kalıcılık)
https://admin.google.com/u/1/ac/owl/domainwidedelegation adresinde Alan Geniş Yetkilendirmelerini kontrol etmek mümkündür.
Bir saldırgan, bir GCP projesinde hizmet hesapları oluşturma yeteneğine ve GWS'de süper yönetici ayrıcalığına sahipse, SAs'lerin bazı GWS kullanıcılarını taklit etmelerine izin veren yeni bir yetkilendirme 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 veya doğrudan API çağrıları ve CLI araçları kullanılarak programlı olarak üretilebilir. Bu,
iam.serviceAccountAdmin
rolünü veyaiam.serviceAccounts.create
izinini içeren herhangi bir özel rolü gerektirir. Hizmet hesabı oluşturulduktan sonra, ilgili bir anahtar çifti oluşturacağız (iam.serviceAccountKeys.create
izni).Yeni yetkilendirme oluşturma: Yalnızca Süper Yönetici rolünün, Google Workspace'de küresel Alan Geniş yetkilendirmesini kurma yeteneğine sahip olduğunu ve Alan Geniş yetkilendirmenin programlı olarak kurulamayacağını, yalnızca Google Workspace konsolu aracılığıyla manuel olarak oluşturulup ayarlanabileceğini anlamak önemlidir.
Kuralın oluşturulması, API kontrolleri → Google Workspace Yönetici konsolunda Alan Geniş yetkilendirmeyi Yönet sayfasında bulunabilir.
OAuth kapsam ayrıcalığını eklemek: Yeni bir yetkilendirme yapılandırılırken, Google'ın yalnızca 2 parametreye ihtiyacı vardır: İstemci Kimliği, yani GCP Hizmet Hesabının OAuth Kimliği kaynağı ve OAuth kapsamları ki bu, yetkilendirmenin hangi API çağrılarını gerektirdiğini tanımlar.
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 kimlik adına hareket etme: Bu noktada, GWS'de işlevsel bir yetkilendirilmiş nesnemiz var. Şimdi, GCP Hizmet Hesabı özel anahtarı kullanarak API çağrıları yapabiliriz (OAuth kapsam parametresinde tanımlanan kapsamda) ve Google Workspace'de var olan herhangi bir kimlik adına hareket edebiliriz. Hizmet hesabının ihtiyaçlarına göre erişim belirteçleri oluşturacağını ve REST API uygulamalarına sahip olduğu izinlere göre hareket edeceğini öğrendik.
Bu yetkilendirmeyi kullanmak için bazı araçlar için önceki bölüme bakın.
Kurumsal Çapta Yetkilendirme
OAuth SA Kimliği küreseldir ve kurumsal çapta yetkilendirme için kullanılabilir. Çapraz küresel yetkilendirme engellemek 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 alan geniş yetkilendirmeyi yapılandırmak için kullanılabilir. Bu, yalnızca Workspace'e Süper Yönetici erişimine ihtiyaç duyulacağı anlamına gelir ve saldırgan, Hizmet Hesapları ve özel anahtarları kendi kontrolündeki GCP hesabında oluşturabilir.
Workspace'ı numaralandırmak için bir Proje oluşturma
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'ı numaralandırmak için API'leri etkinleştirebilir ve onu numaralandırmaya çalışabilir.
Bir kullanıcının Workspace'ı numaralandırabilmesi için yeterli Workspace iznine de ihtiyacı vardır (her kullanıcı dizini numaralandıramayabilir).
Daha fazla numaralandırma için şunu kontrol edin:
GCP - IAM, Principals & Org Policies EnumGcloud Kötüye Kullanımı
gcloud
akışı hakkında daha fazla bilgiyi şurada bulabilirsiniz:
Orada açıklandığı gibi, gcloud, kullanıcının sürücüsüne erişim izni verecek olan https://www.googleapis.com/auth/drive
kapsamını isteyebilir.
Bir saldırgan olarak, bir kullanıcının bilgisayarını fiziksel olarak ele geçirdiyseniz ve kullanıcı hala oturum açık ise, kullanıcı hesabıyla oturum açarak sürücüye erişim izni olan bir belge oluşturabilirsiniz:
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ı değiştirip CLOUDSDK_SCOPES
içine 'https://www.googleapis.com/auth/drive'
kapsamını ekleyebilir:
Bu nedenle, kullanıcı bir sonraki oturum açtığında, saldırganın sürücüye erişim sağlayabileceği bir jeton oluşturacak. Açıkçası, tarayıcı oluşturulan jetonun sürücüye erişim sağlayacağını belirtecektir, ancak kullanıcı gcloud auth login
çağrısını kendisi yapacağından dolayı muhtemelen şüphelenmeyecektir.
Sürücü dosyalarını listelemek için: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
GWS'den GCP'ye
Ayrıcalıklı GCP kullanıcılarına erişim
Bir saldırganın GWS üzerinde tam erişimi varsa, genellikle GWS'deki kullanıcılar GCP üzerinde yüksek ayrıcalıklara sahip olduklarından GWS'den GCP'ye geçmek daha "basit" olacaktır.
Google Grupları Ayrıcalık Yükseltme
Varsayılan olarak kullanıcılar Kuruluşun Workspace gruplarına serbestçe katılabilir ve bu gruplar GCP izinleri atamış olabilir (gruplarınızı https://groups.google.com/ adresinden kontrol edin).
Google grupları ayrıcalık yükseltmesi kötüye kullanarak, GCP'ye ayrıcalıklı erişime sahip bir gruba yükseltebilirsiniz.
Referanslar
Last updated