GCP - Basic Information

AWS Hacking öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!

• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da 🐦 @hacktricks_live'i takip edin.**

• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.

Kaynak hiyerarşisi

Google Cloud, geleneksel bir dosya sistemine kavramsal olarak benzer bir Kaynak hiyerarşisi kullanır. Bu, politikalar ve izinler için belirli ekleme noktaları ile mantıksal bir ebeveyn/çocuk iş akışı sağlar.

Yüksek seviyede, bu şekilde görünür:

Organization
--> Folders
--> Projects
--> Resources

Bir sanal makine (Compute Instance olarak adlandırılır) bir kaynaktır. Bir kaynak, muhtemelen diğer Compute Instance'lar, depolama kovaları vb. ile birlikte bir projede bulunur.

https://cloud.google.com/static/resource-manager/img/cloud-hierarchy.svg

Projelerin Taşınması

Bir projeyi herhangi bir organizasyondan roles/resourcemanager.projectCreator ve roles/resourcemanager.projectMover izinleri ile bir organizasyona taşımak mümkündür. Proje başka bir organizasyonun içindeyse, öncelikle organizasyondan çıkarmak için GCP desteği ile iletişime geçmek gerekir. Daha fazla bilgi için şurayı kontrol edin.

Organizasyon Politikaları

Organizasyonunuzun bulut kaynakları üzerinde merkezi kontrol sağlamaya olanak tanır:

• Organizasyonunuzun kaynaklarının nasıl kullanılabileceği üzerinde kısıtlamalar yapılandırmak için merkezi kontrol sağlayın.

• Geliştirme ekiplerinizin uyum sınırları içinde kalmasını sağlamak için koruma önlemleri tanımlayın ve oluşturun.

• Proje sahiplerine ve ekiplerine uyumu ihlal etme endişesi olmadan hızlı hareket etme konusunda yardımcı olun.

Bu politikalar, tüm organizasyonu, klasör(ler) veya proje(ler) etkilemek üzere oluşturulabilir. Hedeflenen kaynak hiyerarşi düğümünün altındaki varlıklar organizasyon politikasını miras alır.

Bir organizasyon politikasını tanımlamak için, bir kısıtlama seçersiniz; bu, belirli bir Google Cloud hizmetine veya bir grup Google Cloud hizmetine karşı bir kısıtlama türüdür. Bu kısıtlamayı istediğiniz kısıtlamalarla yapılandırırsınız.

https://cloud.google.com/resource-manager/img/org-policy-concepts.svg

Yaygın kullanım senaryoları

• Alan adına dayalı kaynak paylaşımını sınırlayın.

• Kimlik ve Erişim Yönetimi hizmet hesaplarının kullanımını sınırlayın.

• Yeni oluşturulan kaynakların fiziksel konumunu kısıtlayın.

• Hizmet hesabı oluşturmayı devre dışı bırakın.

Organizasyonunuzun kaynakları üzerinde ince ayar kontrolü sağlayan daha birçok kısıtlama vardır. Daha fazla bilgi için, Tüm Organizasyon Politikası Hizmeti kısıtlamalarının listesinigörebilirsiniz.

Varsayılan Organizasyon Politikaları

GCP organizasyonunuzu kurarken Google'ın varsayılan olarak ekleyeceği politikalar şunlardır:

Erişim Yönetimi Politikaları

• Alan kısıtlamalı kişiler: Belirtilen alanlarınızın dışındaki Temel İletişimlere kullanıcı eklemeyi engeller. Bu, Temel İletişimlerin yalnızca seçilen alanlarınızdaki yönetilen kullanıcı kimliklerinin platform bildirimlerini almasına izin verir.

• Alan kısıtlamalı paylaşım: Belirtilen alanlarınızın dışındaki IAM politikalarına kullanıcı eklemeyi engeller. Bu, IAM politikalarının yalnızca seçilen alanlarınızdaki yönetilen kullanıcı kimliklerinin bu organizasyondaki kaynaklara erişmesine izin vermesiyle sınırlıdır.

• Halka açık erişim önleme: Cloud Storage kovalarının halka açılmasını engeller. Bu, bir geliştiricinin Cloud Storage kovalarını kimlik doğrulaması yapılmamış internet erişimine sahip olacak şekilde yapılandırmasını engeller.

• Eşit düzeyde kova erişimi: Cloud Storage kovalarında nesne düzeyinde erişim kontrol listelerini (ACL'ler) engeller. Bu, IAM politikalarını Cloud Storage kovalarındaki tüm nesneler üzerinde tutarlı bir şekilde uygulayarak erişim yönetiminizi basitleştirir.

• OS girişini zorunlu kıl: Yeni projelerde oluşturulan VM'lerde OS Girişi etkin olacaktır. Bu, SSH erişimini IAM kullanarak yönetmenizi sağlar; bireysel SSH anahtarları oluşturup yönetmenize gerek kalmaz.

Hizmet hesapları için ek güvenlik politikaları

• Otomatik IAM atamalarını devre dışı bırak: Varsayılan App Engine ve Compute Engine hizmet hesaplarının oluşturulurken projeye Editor IAM rolü otomatik olarak verilmesini engeller. Bu, hizmet hesaplarının oluşturulurken aşırı izinli IAM rolleri almasını engeller.

• Hizmet hesabı anahtarı oluşturmayı devre dışı bırak: Kamuya açık hizmet hesabı anahtarlarının oluşturulmasını engeller. Bu, kalıcı kimlik bilgilerini açığa çıkarma riskini azaltmaya yardımcı olur.

• Hizmet hesabı anahtarı yüklemeyi devre dışı bırak: Kamuya açık hizmet hesabı anahtarlarının yüklenmesini engeller. Bu, sızdırılan veya yeniden kullanılan anahtar materyali riskini azaltmaya yardımcı olur.

Güvenli VPC ağ yapılandırma politikaları

• VM örnekleri için izin verilen dış IP'leri tanımlayın: Kamu IP'sine sahip Compute örneklerinin oluşturulmasını engeller; bu, onları internet trafiğine maruz bırakabilir.

• VM iç içe sanallaştırmayı devre dışı bırak: Compute Engine VM'lerinde iç içe VM'lerin oluşturulmasını engeller. Bu, izlenmeyen iç içe VM'lerin güvenlik riskini azaltır.

• VM seri portunu devre dışı bırak: Compute Engine VM'lerine seri port erişimini engeller. Bu, Compute Engine API'sini kullanarak bir sunucunun seri portuna giriş yapılmasını engeller.

• Cloud SQL örneklerinde yetkilendirilmiş ağları kısıtla: Kamuya açık veya iç ağ aralıklarının Cloud SQL veritabanlarınıza erişmesini engeller.

• IP adresinin türüne göre Protokol Yönlendirmeyi kısıtla: Dış IP adresleri için VM protokol yönlendirmesini engeller.

• Cloud SQL örneklerinde Kamu IP erişimini kısıtla: Kamu IP'sine sahip Cloud SQL örneklerinin oluşturulmasını engeller; bu, onları internet trafiğine maruz bırakabilir.

• Paylaşılan VPC proje iptalini kısıtla: Paylaşılan VPC ana projelerinin kazara silinmesini engeller.

• Yeni projeler için iç DNS ayarını Zonal DNS Sadece olarak ayarlayın: Hizmet kullanılabilirliğini azaltan eski bir DNS ayarının kullanılmasını engeller.

• Varsayılan ağ oluşturmayı atla: Varsayılan VPC ağının ve ilgili kaynakların otomatik olarak oluşturulmasını engeller. Bu, aşırı izinli varsayılan güvenlik duvarı kurallarını önler.

• VPC Dış IPv6 kullanımını devre dışı bırak: Yetkisiz internet erişimine maruz kalabilecek dış IPv6 alt ağlarının oluşturulmasını engeller.

IAM Rolleri

Bunlar, her rolün bir dizi izin içerdiği AWS'deki IAM politikalarına benzer.

Ancak, AWS'deki gibi, rollerin merkezi bir deposu yoktur. Bunun yerine, kaynaklar Y'ye X erişim rolleri verir ve bir kaynağa kimin erişimi olduğunu öğrenmenin tek yolu, o kaynak üzerinde get-iam-policy yöntemini kullanmaktır. Bu bir sorun olabilir çünkü bu, bir ilkenin hangi izinlere sahip olduğunu öğrenmenin tek yolunun, her kaynağa kimin izin verdiğini sormak olduğunu gösterir ve bir kullanıcının tüm kaynaklardan izinleri alma yetkisi olmayabilir.

IAM'de üç tür rol vardır:

• Temel/Primitif roller, Sahip, Düzenleyici ve Görüntüleyici rollerini içerir; bu roller IAM'ın tanıtılmasından önce mevcuttu.

• Ön tanımlı roller, belirli bir hizmet için ayrıntılı erişim sağlar ve Google Cloud tarafından yönetilir. Birçok ön tanımlı rol vardır, hepsini sahip oldukları ayrıcalıklarla birlikte buradan görebilirsiniz.
• Özel roller, kullanıcı tarafından belirtilen bir izin listesine göre ayrıntılı erişim sağlar.

GCP'de binlerce izin vardır. Bir rolün izinlere sahip olup olmadığını kontrol etmek için buradan izni arayabilirsiniz ve hangi rollerin buna sahip olduğunu görebilirsiniz.

Ayrıca, buradan ön tanımlı rolleri arayabilirsiniz her ürün tarafından sunulan. Bazı rollerin kullanıcılara eklenemeyeceğini ve yalnızca SA'lara eklenebileceğini unutmayın; çünkü içerdiği bazı izinler nedeniyle. Ayrıca, izinlerin yalnızca ilgili hizmete eklenirse geçerli olacağını unutmayın.

Veya bir özel rolün burada belirli bir izni kullanıp kullanamayacağını kontrol edin.

GCP - IAM, Principals & Org Policies Enum

Kullanıcılar

GCP konsolunda Kullanıcılar veya Gruplar yönetimi yoktur; bu, Google Workspace'te yapılır. Ancak, Google Workspace'te farklı bir kimlik sağlayıcısını senkronize edebilirsiniz.

Workspace kullanıcıları ve gruplarına https://admin.google.com adresinden erişebilirsiniz.

MFA, Workspace kullanıcılarına zorlanabilir, ancak bir saldırgan, GCP'ye cli üzerinden erişmek için bir token kullanabilir; bu, MFA ile korunmayacaktır (sadece kullanıcı giriş yaptığında oluşturulurken MFA ile korunacaktır: gcloud auth login).

Gruplar

Bir organizasyon oluşturulduğunda birkaç grup oluşturulması şiddetle önerilir. Bunlardan herhangi birini yönetiyorsanız, organizasyonun tamamını veya önemli bir kısmını tehlikeye atmış olabilirsiniz:

Grup	Fonksiyon
gcp-organization-admins (kontrol listesi için grup veya bireysel hesaplar gereklidir)	Organizasyona ait herhangi bir kaynağı yönetmek. Bu rolü dikkatli bir şekilde atayın; organizasyon yöneticileri, tüm Google Cloud kaynaklarınıza erişim sağlar. Alternatif olarak, bu işlev yüksek ayrıcalıklı olduğundan, bir grup oluşturmak yerine bireysel hesaplar kullanmayı düşünün.
gcp-network-admins (kontrol listesi için gereklidir)	Ağlar, alt ağlar, güvenlik duvarı kuralları ve Cloud Router, Cloud VPN ve bulut yük dengeleyicileri gibi ağ cihazları oluşturma.
gcp-billing-admins (kontrol listesi için gereklidir)	Faturalama hesaplarını ayarlama ve kullanımını izleme.
gcp-developers (kontrol listesi için gereklidir)	Uygulamaları tasarlama, kodlama ve test etme.
gcp-security-admins	Tüm organizasyon için erişim yönetimi ve organizasyon kısıtlama politikaları dahil olmak üzere güvenlik politikalarını oluşturma ve yönetme. Google Cloud güvenlik altyapınızı planlamak için daha fazla bilgi için Google Cloud güvenlik temelleri kılavuzuna bakın.
gcp-devops	Sürekli entegrasyon ve teslimatı destekleyen uçtan uca boru hatları oluşturma veya yönetme, izleme ve sistem sağlama.
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer (artık varsayılan olarak yok)	Projelerdeki harcamaları izleme. Tipik üyeler finans ekibinin bir parçasıdır.
gcp-platform-viewer (artık varsayılan olarak yok)	Google Cloud organizasyonu genelinde kaynak bilgilerini gözden geçirme.
gcp-security-reviewer (artık varsayılan olarak yok)	Bulut güvenliğini gözden geçirme.
gcp-network-viewer (artık varsayılan olarak yok)	Ağ yapılandırmalarını gözden geçirme.
grp-gcp-audit-viewer (artık varsayılan olarak yok)	Denetim günlüklerini görüntüleme.
gcp-scc-admin (artık varsayılan olarak yok)	Güvenlik Komut Merkezi'ni yönetme.
gcp-secrets-admin (artık varsayılan olarak yok)	Secret Manager'da gizli bilgileri yönetme.

Varsayılan Şifre Politikası

• Güçlü şifreleri zorunlu kıl

• 8 ile 100 karakter arasında

• Yeniden kullanım yok

• Süre sona erme yok

• İnsanlar Workspace'e üçüncü taraf bir sağlayıcı aracılığıyla erişiyorsa, bu gereksinimler uygulanmaz.

Hizmet hesapları

Bunlar, kaynakların bağlı olabileceği ve GCP ile kolayca etkileşimde bulunabilmesi için erişim sağladığı ilkelerdir. Örneğin, bir VM'ye bağlı bir Hizmet Hesabının kimlik doğrulama token'ına metadata'da erişmek mümkündür. IAM ve erişim kapsamlarını kullanırken bazı çelişkilerle karşılaşmak mümkündür. Örneğin, hizmet hesabınızın compute.instanceAdmin IAM rolü olabilir, ancak ihlal ettiğiniz örnek, https://www.googleapis.com/auth/compute.readonly kapsam kısıtlaması ile sınırlı olabilir. Bu, örneğinize otomatik olarak atanan OAuth token'ını kullanarak herhangi bir değişiklik yapmanızı engeller.

Bu, AWS'deki IAM rollerine benzer. Ancak AWS'deki gibi, herhangi bir hizmet hesabı herhangi bir hizmete bağlanabilir (bunu bir politika aracılığıyla izin vermesi gerekmez).

Bulacağınız birçok hizmet hesabı aslında, bir hizmet kullanmaya başladığınızda GCP tarafından otomatik olarak oluşturulur, örneğin:

[e-mail]
[e-mail]

Ancak, özel hizmet hesapları oluşturmak ve bunlara eklemek de mümkündür, bu da şöyle görünecektir:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Anahtarlar ve Tokenlar

GCP'ye bir hizmet hesabı olarak erişmenin 2 ana yolu vardır:

• OAuth tokenları aracılığıyla: Bunlar, metadata uç noktaları gibi yerlerden veya http isteklerini çalarak elde edeceğiniz tokenlardır ve erişim kapsamları ile sınırlıdır.

• Anahtarlar: Bunlar, hizmet hesabı olarak istekleri imzalamanıza ve hatta hizmet hesabı olarak eylemler gerçekleştirmek için OAuth tokenları oluşturmanıza olanak tanıyan genel ve özel anahtar çiftleridir. Bu anahtarlar tehlikelidir çünkü sınırlamak ve kontrol etmek daha karmaşıktır, bu yüzden GCP bunları oluşturmanızı önermemektedir.

• Her seferinde bir SA oluşturulduğunda, GCP hizmet hesabı için bir anahtar oluşturur ve kullanıcı bu anahtara erişemez (ve web uygulamasında listelenmez). bu başlığa göre bu anahtar, GCP tarafından dahili olarak erişilebilir OAuth tokenları oluşturmak için metadata uç noktalarına erişim vermek amacıyla kullanılmaktadır.

Erişim Kapsamları

Erişim kapsamları, GCP API uç noktalarına erişmek için oluşturulan OAuth tokenlarına eklenir. Bunlar, OAuth tokenının izinlerini kısıtlar. Bu, bir token bir kaynağın sahibi olsa bile, o kaynağa erişim sağlamak için token kapsamına sahip değilse, tokenın bu ayrıcalıkları (kötüye) kullanmak için kullanılamayacağı anlamına gelir.

Google aslında önerir ki erişim kapsamları kullanılmasın ve tamamen IAM'e güvenilsin. Web yönetim portalı aslında bunu zorunlu kılar, ancak erişim kapsamları yine de özel hizmet hesapları kullanılarak programlı olarak örneklere uygulanabilir.

Hangi kapsamların atanmış olduğunu sorgulayarak görebilirsiniz:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "[e-mail]",
"verified_email": true,
"access_type": "offline"
}

Önceki scopes, veriye erişmek için gcloud kullanılarak varsayılan olarak oluşturulanlardır. Bunun nedeni, gcloud kullandığınızda önce bir OAuth token'ı oluşturmanız ve ardından bunu uç noktalarla iletişim kurmak için kullanmanızdır.

Bu potansiyel scopes arasında en önemli olanı cloud-platform'dur, bu temelde GCP'deki herhangi bir hizmete erişmenin mümkün olduğu anlamına gelir.

Burada tüm olası scopes listesini bulabilirsiniz.

Eğer gcloud tarayıcı kimlik bilgilerine sahipseniz, diğer scopes ile bir token elde etmek mümkündür, şöyle bir şey yaparak:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM Politikaları, Bağlantıları ve Üyelikleri

Terraform tarafından tanımlandığı gibi https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam GCP ile terraform kullanarak bir kaynağa erişim vermenin farklı yolları vardır:

• Üyelikler: Prensipleri rollerin üyeleri olarak kısıtlama olmaksızın belirlersiniz. Bir kullanıcıyı bir rolün üyesi olarak koyabilir ve ardından aynı rolün bir üyesi olarak bir grubu koyabilir ve ayrıca bu prensipleri (kullanıcı ve grup) diğer rollerin üyesi olarak ayarlayabilirsiniz.

• Bağlantılar: Birden fazla prensip bir role bağlanabilir. Bu prensipler hala diğer rollerin üyeleri veya bağlanmış olabilir. Ancak, bir role bağlı olmayan bir prensip bağlı bir rolün üyesi olarak ayarlandığında, bağlantı uygulandığında, üyelik kaybolacaktır.

• Politikalar: Bir politika otoritativdir, roller ve prensipleri belirtir ve ardından, bu prensiplerin daha fazla rolü olamaz ve bu rollerin daha fazla prensibi olamaz, bu politika değiştirilmedikçe (diğer politikalar, bağlantılar veya üyeliklerde bile değil). Bu nedenle, bir rol veya prensip politika içinde belirtildiğinde, tüm ayrıcalıkları o politika ile sınırlıdır. Açıkça, bu, prensibe politikayı değiştirme veya ayrıcalık yükseltme izinleri (yeni bir prensip oluşturma ve ona yeni bir rol bağlama gibi) verildiğinde aşılabilir.

Referanslar

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/
• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

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)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!
• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da 🐦 @hacktricks_live'i takip edin.**
• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.