GCP <--> Workspace Pivoting

Sıfırdan kahraman olmak için AWS hackleme öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'ı desteklemenin diğer yolları:

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:

pageGCP - Understanding Domain-Wide Delegation

Mevcut 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:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "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"

Bu, aşağıdaki adımları izleyerek saldırı gerçekleştirebilen bir araçtır:

  1. Kaynak Yöneticisi API'sını kullanarak GCP Projelerini Numaralandırın.

  2. 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.

  3. 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.

  4. IAM politikasında ilgili izne sahip bulunan her hizmet hesabı kaynağı için yeni bir KEY_ALG_RSA_2048 özel anahtarı oluşturun.

  5. 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.

  6. _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.

  7. 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:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

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:

  1. 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ü veya iam.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).

  2. 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.

  1. 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

  1. 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).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Daha fazla numaralandırma için şunu kontrol edin:

pageGCP - IAM, Principals & Org Policies Enum

Gcloud Kötüye Kullanımı

gcloud akışı hakkında daha fazla bilgiyi şurada bulabilirsiniz:

pageGCP - Non-svc Persistance

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:

gcloud auth login --enable-gdrive-access

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

AWS hacklemeyi sıfırdan kahramana kadar öğrenin htARTE (HackTricks AWS Red Team Expert) ile!

HackTricks'ı desteklemenin diğer yolları:

Last updated