Pierre-Loup 770348d041
Avoid OWASP Top 10 security-standard mismatch between metadata and description links (RULEAPI-798) (#3537)
* Add check for security standard mismatch

* Fix security standard mismatches

* Fix Resources/Standards links for secrets rules

* Fix check

* Fix links and update security standard mapping

* Fix maintanability issue

* Apply review suggestions

* Apply suggestions from code review

Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com>

* Fix typo

Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com>

---------

Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com>
2024-01-17 17:20:28 +01:00

168 lines
5.5 KiB
Plaintext

Creating custom roles that allow privilege escalation can allow attackers to
maliciously exploit an organization's cloud resources.
Certain GCP permissions allow impersonation of one or more privileged principals
within a GCP infrastructure. +
To prevent privilege escalation after an account has been compromised,
proactively follow GCP Security Insights and ensure that custom roles contain
as few privileges as possible that allow direct or indirect impersonation.
For example, privileges like `deploymentmanager.deployments.create` allow
impersonation of service accounts, even if the name does not sound like it. +
Other privileges like `setIamPolicy`, which are more explicit, directly allow
their holder to extend their privileges.
After gaining a foothold in the target infrastructure, sophisticated attackers
typically map their newfound roles to understand what is exploitable.
The riskiest privileges are either:
* At the infrastructure level: privileges to perform project, folder, or
organization-wide administrative tasks.
* At the resource level: privileges to perform resource-wide administrative tasks.
In either case, the following privileges should be avoided or granted only with
caution:
* `*.*.setIamPolicy`
* `cloudbuilds.builds.create`
* `cloudfunctions.functions.create`
* `cloudfunctions.functions.update`
* `cloudscheduler.jobs.create`
* `composer.environments.create`
* `compute.instances.create`
* `dataflow.jobs.create`
* `dataproc.clusters.create`
* `deploymentmanager.deployments.create`
* `iam.roles.update`
* `iam.serviceAccountKeys.create`
* `iam.serviceAccounts.actAs`
* `iam.serviceAccounts.getAccessToken`
* `iam.serviceAccounts.getOpenIdToken`
* `iam.serviceAccounts.implicitDelegation`
* `iam.serviceAccounts.signBlob`
* `iam.serviceAccounts.signJwt`
* `orgpolicy.policy.set`
* `run.services.create`
* `serviceusage.apiKeys.create`
* `serviceusage.apiKeys.list`
* `storage.hmacKeys.create`
== Ask Yourself Whether
* This role requires impersonation to perform specific tasks with different
privileges.
* This custom role is intended for a small group of administrators.
There is a risk if you answered no to these questions.
== Recommended Secure Coding Practices
Use a permission that does not allow privilege escalation.
== Sensitive Code Example
Lightweight custom role intended for a developer:
[source,terraform]
----
resource "google_organization_iam_custom_role" "example" {
permissions = [
"iam.serviceAccounts.getAccessToken", # Sensitive
"iam.serviceAccounts.getOpenIdToken", # Sensitive
"iam.serviceAccounts.actAs", # Sensitive
"iam.serviceAccounts.implicitDelegation", # Sensitive
"resourcemanager.projects.get",
"resourcemanager.projects.list",
"run.services.create",
"run.services.delete",
"run.services.get",
"run.services.getIamPolicy",
"run.services.list",
"run.services.update",
]
}
----
Lightweight custom role intended for a read-only user:
[source,terraform]
----
resource "google_project_iam_custom_role" "example" {
permissions = [
"iam.serviceAccountKeys.create", # Sensitive
"iam.serviceAccountKeys.get", # Sensitive
"deploymentmanager.deployments.create", # Sensitive
"cloudbuild.builds.create", # Sensitive
"resourcemanager.projects.get",
"resourcemanager.projects.list",
"run.services.get",
"run.services.getIamPolicy",
"run.services.list",
]
}
----
== Compliant Solution
Lightweight custom role intended for a developer:
[source,terraform]
----
resource "google_project_iam_custom_role" "example" {
permissions = [
"resourcemanager.projects.get",
"resourcemanager.projects.list",
"run.services.create",
"run.services.delete",
"run.services.get",
"run.services.getIamPolicy",
"run.services.list",
"run.services.update",
]
}
----
Lightweight custom role intended for a read-only user:
[source,terraform]
----
resource "google_project_iam_custom_role" "example" {
permissions = [
"resourcemanager.projects.get",
"resourcemanager.projects.list",
"run.services.get",
"run.services.getIamPolicy",
"run.services.list",
]
}
----
== See
* https://cloud.google.com/iam/docs/custom-roles-permissions-support[GCP IAM Docs] - Support levels for permissions in custom roles
* https://cloud.google.com/iam/docs/understanding-custom-roles[GCP IAM Docs] - Understanding IAM custom roles
* https://www.youtube.com/watch?v=Z-JFVJZ-HDA[DEFONConference Youtube Video] - DEF CON Safe Mode - Dylan Ayrey and Allison Donovan - Lateral Movement & Privilege Escalation in GCP
* https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/[Rhino Security Labs] - Privilege Escalation in Google Cloud Platform - Part 1 (IAM)
* https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/[Rhino Security Labs] - Privilege Escalation in Google Cloud Platform - Part 2 (Non-IAM)
* https://www.praetorian.com/blog/google-cloud-platform-gcp-service-account-based-privilege-escalation-paths/[Praetorian] - Google Cloud Platform (GCP) Service Account-based Privilege Escalation paths
* https://cloud.google.com/iam/docs/manage-policy-insights[GCP Docs] - Security Insights
* CWE - https://cwe.mitre.org/data/definitions/668[CWE-668 - Exposure of Resource to Wrong Sphere]
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
=== Message
Make sure that using a permission that allows privilege escalation is safe here.
=== Highlighting
Highlight the sensitive list item.
endif::env-github,rspecator-view[]