Korean - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP <--> Workspace Pivoting

Support HackTricks

From GCP to GWS

Domain Wide Delegation basics

Google Workspace의 도메인 전체 위임은 Google Workspace Marketplace의 외부 앱 또는 내부 GCP 서비스 계정과 같은 신원 객체가 사용자를 대신하여 Workspace 전반의 데이터에 접근할 수 있도록 허용합니다.

이는 기본적으로 조직의 GCP 프로젝트 내 서비스 계정이 동일 조직의 Workspace 사용자(또는 다른 조직의 사용자)를 가장할 수 있을 가능성이 있음을 의미합니다.

이것이 정확히 어떻게 작동하는지에 대한 더 많은 정보는 다음을 확인하세요:

GCP - Understanding Domain-Wide Delegation

Compromise existing delegation

공격자가 GCP에 대한 일부 접근을 타협하고 회사의 유효한 Workspace 사용자 이메일(가능하면 슈퍼 관리자)을 알고 있다면, 그는 접근할 수 있는 모든 프로젝트를 나열하고, 프로젝트의 모든 SA를 나열하며, 접근할 수 있는 서비스 계정을 확인하고, 가장할 수 있는 각 SA로 이 모든 단계를 반복할 수 있습니다. 그가 접근할 수 있는 모든 서비스 계정의 목록과 Workspace 이메일 목록을 가지고 있다면, 공격자는 각 서비스 계정으로 사용자를 가장하려고 시도할 수 있습니다.

도메인 전체 위임을 구성할 때 Workspace 사용자가 필요하지 않으므로, 유효한 사용자 하나만 알면 가장하는 데 충분하고 필요합니다. 그러나 가장한 사용자의 권한이 사용되므로, 만약 슈퍼 관리자라면 모든 것에 접근할 수 있습니다. 접근 권한이 없다면 이는 무의미할 것입니다.

GCP Generate Delegation Token

이 간단한 스크립트는 위임된 사용자로서 OAuth 토큰을 생성하며, 이를 사용하여 gcloud 유무에 관계없이 다른 Google API에 접근할 수 있습니다:

# 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"

DeleFriend

이 도구는 다음 단계를 따라 공격을 수행할 수 있습니다:

  1. 리소스 관리자 API를 사용하여 GCP 프로젝트를 나열합니다.

  2. 각 프로젝트 리소스를 반복하고, 초기 IAM 사용자가 접근할 수 있는 GCP 서비스 계정 리소스를 _GetIAMPolicy_를 사용하여 나열합니다.

  3. 각 서비스 계정 역할을 반복하고, 대상 서비스 계정 리소스에서 serviceAccountKeys.create 권한을 가진 내장, 기본 및 사용자 정의 역할을 찾습니다. 편집자 역할은 본질적으로 이 권한을 가지고 있다는 점에 유의해야 합니다.

  4. IAM 정책에서 관련 권한이 발견된 각 서비스 계정 리소스에 대해 새 KEY_ALG_RSA_2048 개인 키를 생성합니다.

  5. 각 새 서비스 계정에 대해 JWT 객체를 생성하는데, 이는 SA 개인 키 자격 증명과 OAuth 범위로 구성됩니다. 새 JWT 객체를 생성하는 과정은 oauth_scopes.txt 목록의 모든 기존 OAuth 범위 조합을 반복하여 모든 위임 가능성을 찾습니다. 목록 oauth_scopes.txt는 Workspace ID를 악용하는 데 관련된 모든 OAuth 범위로 업데이트됩니다.

  6. _make_authorization_grant_assertion 메서드는 DWD 하에 JWT를 생성하기 위해 _subject_라고 하는 대상 워크스페이스 사용자를 선언해야 함을 드러냅니다. 특정 사용자가 필요할 것처럼 보일 수 있지만, DWD는 도메인 내 모든 ID에 영향을 미친다는 점을 인식하는 것이 중요합니다. 따라서 도메인 사용자에 대한 JWT를 생성하는 것은 해당 도메인의 모든 ID에 영향을 미치며, 이는 우리의 조합 나열 확인과 일치합니다. 간단히 말해, 유효한 Workspace 사용자 하나면 충분합니다. 이 사용자는 DeleFriend의 config.yaml 파일에서 정의할 수 있습니다. 대상 워크스페이스 사용자가 이미 알려져 있지 않은 경우, 이 도구는 GCP 프로젝트에서 역할을 가진 도메인 사용자를 스캔하여 유효한 워크스페이스 사용자를 자동으로 식별하는 기능을 제공합니다. 다시 말하지만, JWT는 도메인 특정이며 모든 사용자에 대해 생성되지 않으므로, 자동 프로세스는 도메인당 단일 고유 ID를 대상으로 합니다.

  7. 각 JWT에 대해 새로운 베어러 액세스 토큰을 나열하고 생성하며, tokeninfo API에 대해 토큰을 검증합니다.

Gitlab의 Python 스크립트

Gitlab은 이 Python 스크립트를 만들어 두 가지 작업을 수행할 수 있습니다 - 사용자 디렉토리를 나열하고 SA 자격 증명과 가장할 사용자를 나타내는 json을 지정하면서 새 관리 계정을 생성합니다. 사용 방법은 다음과 같습니다:

# 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

새 위임 생성 (지속성)

**https://admin.google.com/u/1/ac/owl/domainwidedelegation**에서 도메인 전체 위임을 확인할 수 있습니다.

GCP 프로젝트에서 서비스 계정을 생성할 수 있는 공격자와 GWS에 대한 슈퍼 관리자 권한을 가진 공격자는 SAs가 일부 GWS 사용자를 가장할 수 있도록 하는 새로운 위임을 생성할 수 있습니다:

  1. 새 서비스 계정 및 해당 키 쌍 생성: GCP에서 새로운 서비스 계정 리소스는 콘솔을 통해 대화식으로 또는 직접 API 호출 및 CLI 도구를 사용하여 프로그래밍 방식으로 생성할 수 있습니다. 이는 iam.serviceAccountAdmin 역할 또는 iam.serviceAccounts.create 권한이 있는 사용자 정의 역할이 필요합니다. 서비스 계정이 생성되면 관련 키 쌍을 생성하는 단계로 진행합니다 (iam.serviceAccountKeys.create 권한).

  2. 새 위임 생성: Google Workspace에서 전역 도메인 전체 위임을 설정할 수 있는 능력은 오직 슈퍼 관리자 역할만이 가지고 있다는 점을 이해하는 것이 중요합니다. 도메인 전체 위임은 프로그래밍 방식으로 설정할 수 없으며, Google Workspace 콘솔을 통해 수동으로 생성 및 조정할 수 있습니다.

  • 규칙 생성은 API 제어 → Google Workspace 관리 콘솔에서 도메인 전체 위임 관리 페이지에서 찾을 수 있습니다.

  1. OAuth 범위 권한 부여: 새 위임을 구성할 때 Google은 클라이언트 ID, 즉 GCP 서비스 계정 리소스의 OAuth ID와 위임이 요구하는 API 호출을 정의하는 OAuth 범위라는 두 가지 매개변수만 필요합니다.

  • OAuth 범위의 전체 목록은 여기에서 찾을 수 있지만, 다음과 같은 추천이 있습니다: 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. 대상 신원을 대신하여 행동하기: 이 시점에서 우리는 GWS에서 작동하는 위임된 객체를 가지고 있습니다. 이제 GCP 서비스 계정 개인 키를 사용하여 API 호출을 수행할 수 있습니다 (OAuth 범위 매개변수에 정의된 범위 내에서) 이를 트리거하고 Google Workspace에 존재하는 모든 신원을 대신하여 행동할 수 있습니다. 서비스 계정은 필요에 따라 REST API 애플리케이션에 대한 권한에 따라 액세스 토큰을 생성합니다.

  • 이 위임을 사용하기 위한 도구는 이전 섹션을 확인하십시오.

교차 조직 위임

OAuth SA ID는 전역적이며 교차 조직 위임에 사용할 수 있습니다. 교차 글로벌 위임을 방지하기 위한 제한이 구현되지 않았습니다. 간단히 말해, 다른 GCP 조직의 서비스 계정을 사용하여 다른 Workspace 조직에서 도메인 전체 위임을 구성할 수 있습니다. 이는 Workspace에 대한 슈퍼 관리자 액세스만 필요하고, 동일한 GCP 계정에 대한 액세스는 필요하지 않으며, 적대자는 개인적으로 제어하는 GCP 계정에서 서비스 계정 및 개인 키를 생성할 수 있습니다.

Workspace를 열거하기 위한 프로젝트 생성

기본적으로 Workspace 사용자는 새 프로젝트를 생성할 수 있는 권한을 가지고 있으며, 새 프로젝트가 생성되면 생성자는 해당 프로젝트에 대한 소유자 역할을 부여받습니다.

따라서 사용자는 프로젝트를 생성하고, API를 활성화하여 새 프로젝트에서 Workspace를 열거하고 열거하려고 시도할 수 있습니다.

사용자가 Workspace를 열거할 수 있으려면 충분한 Workspace 권한이 필요합니다 (모든 사용자가 디렉토리를 열거할 수 있는 것은 아닙니다).

# 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>

Check 더 많은 열거는:

GCP - IAM, Principals & Org Policies Enum

Gcloud 자격 증명 악용

gcloud 로그인 흐름에 대한 추가 정보는 다음에서 확인할 수 있습니다:

GCP - Token Persistance

거기에서 설명한 바와 같이, gcloud는 사용자가 자신의 드라이브에 접근할 수 있도록 하는 https://www.googleapis.com/auth/drive 범위를 요청할 수 있습니다. 공격자로서, 사용자의 컴퓨터를 물리적으로 침해하고 사용자가 여전히 자신의 계정으로 로그인한 상태라면, 다음을 사용하여 드라이브에 접근할 수 있는 토큰을 생성하여 로그인할 수 있습니다:

gcloud auth login --enable-gdrive-access

If an attacker compromises the computer of a user he could also modify the file google-cloud-sdk/lib/googlecloudsdk/core/config.py and add in the CLOUDSDK_SCOPES the scope 'https://www.googleapis.com/auth/drive':

따라서 사용자가 다음에 로그인할 때 공격자가 드라이브에 접근할 수 있는 토큰을 생성하게 됩니다. 물론 브라우저는 생성된 토큰이 드라이브에 접근할 수 있다고 표시하지만, 사용자가 **gcloud auth login**을 호출하기 때문에 아마도 의심하지 않을 것입니다.

드라이브 파일을 나열하려면: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

From GWS to GCP

Access privileged GCP users

공격자가 GWS에 완전한 접근 권한을 가지고 있다면 GCP에 대한 권한이 있는 그룹이나 사용자에 접근할 수 있습니다. 따라서 GWS에서 GCP로 이동하는 것은 일반적으로 GWS의 사용자들이 GCP에 대해 높은 권한을 가지고 있기 때문에 더 "간단"합니다.

Google Groups Privilege Escalation

기본적으로 사용자는 조직의 Workspace 그룹에 자유롭게 가입할 수 있으며 이러한 그룹은 GCP 권한이 부여될 수 있습니다 (자신의 그룹을 https://groups.google.com/에서 확인하세요).

google groups privesc를 악용하면 GCP에 대한 어떤 형태의 권한이 있는 그룹으로 상승할 수 있습니다.

References

Support HackTricks
PreviousGCP - Workflows EnumNextGCP - Understanding Domain-Wide Delegation

Last updated