Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting

2026-07-28 22:51:09 -07:00 · 2025-05-17 05:01:08 +00:00
parent 2d3ac46906
commit d017c25e3f
2 changed files with 164 additions and 138 deletions
@@ -2,31 +2,31 @@

 {{#include ../../../banners/hacktricks-training.md}}

-## **GCP에서 GWS로**
+## **From GCP to GWS**

-### **도메인 전체 위임 기본 사항**
+### **Domain Wide Delegation basics**

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

 > [!NOTE]
-> 이는 기본적으로 **GCP 프로젝트** 내의 **서비스 계정**이 동일 조직의 **Workspace 사용자**를 **가장할 수 있을** 가능성이 있음을 의미합니다 (심지어 다른 조직의 사용자도 포함될 수 있습니다).
+> 이는 기본적으로 **GCP 프로젝트** 내의 **서비스 계정**이 동일 조직의 **Workspace 사용자**(또는 다른 조직의 사용자도 포함하여)를 **가장할 수 있을** 가능성이 있음을 의미합니다.

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

 {{#ref}}
 gcp-understanding-domain-wide-delegation.md
 {{#endref}}

-### 기존 위임 타격
+### Compromise existing delegation

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

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

-#### [GCP 위임 토큰 생성](https://github.com/carlospolop/gcp_gen_delegation_token)
+#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)

 이 간단한 스크립트는 **위임된 사용자로서 OAuth 토큰을 생성**하며, 이를 사용하여 `gcloud` 유무에 관계없이 다른 Google API에 접근할 수 있습니다:
 ```bash
@@ -36,22 +36,26 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
 # 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"
 ```
+#### [**DelePwn**](https://github.com/n0tspam/delepwn)
+
+다음 DeleFriend 도구를 기반으로 하며, 도메인, 드라이브, gmail, 캘린더를 열거하고 다른 작업을 수행할 수 있는 기능과 같은 몇 가지 추가 기능이 있습니다.
+
 #### [**DeleFriend**](https://github.com/axon-git/DeleFriend)

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

-1. **Resource Manager API**를 사용하여 GCP 프로젝트를 나열합니다.
-2. 각 프로젝트 리소스에 대해 반복하고, _GetIAMPolicy_를 사용하여 초기 IAM 사용자가 접근할 수 있는 **GCP 서비스 계정 리소스**를 나열합니다.
-3. **각 서비스 계정 역할**에 대해 반복하고, 대상 서비스 계정 리소스에서 _**serviceAccountKeys.create**_ 권한을 가진 내장, 기본 및 사용자 정의 역할을 찾습니다. Editor 역할은 본질적으로 이 권한을 가지고 있다는 점에 유의해야 합니다.
+1. **GCP 프로젝트 열거** Resource Manager API를 사용하여.
+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에 대해 토큰을 검증합니다.
+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 스크립트](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)

-Gitlab은 [이 Python 스크립트](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py)를 만들어 두 가지 작업을 수행할 수 있습니다 - 사용자 디렉토리를 나열하고 SA 자격 증명과 가장할 사용자를 포함한 json을 지정하면서 새 관리 계정을 생성합니다. 사용 방법은 다음과 같습니다:
+Gitlab은 [이 Python 스크립트](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py)를 생성하여 두 가지 작업을 수행할 수 있습니다 - 사용자 디렉토리를 나열하고 SA 자격 증명과 가장할 사용자를 포함한 json을 지정하면서 새 관리 계정을 생성합니다. 사용 방법은 다음과 같습니다:
 ```bash
 # Install requirements
 pip install --upgrade --user oauth2client
@@ -75,27 +79,27 @@ pip install --upgrade --user oauth2client
 ```
 ### 새 위임 생성 (지속성)

-**도메인 전체 위임을 확인할 수 있는 곳은** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**입니다.**
+**[**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**에서 도메인 전체 위임을 **확인할 수 있습니다.**

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

 1. **새 서비스 계정 및 해당 키 쌍 생성:** GCP에서 새로운 서비스 계정 리소스는 콘솔을 통해 대화식으로 또는 직접 API 호출 및 CLI 도구를 사용하여 프로그래밍 방식으로 생성할 수 있습니다. 이는 **`iam.serviceAccountAdmin`** 역할 또는 **`iam.serviceAccounts.create`** **권한**이 있는 사용자 정의 역할이 필요합니다. 서비스 계정이 생성되면 **관련 키 쌍**을 생성하는 단계로 진행합니다 (**`iam.serviceAccountKeys.create`** 권한).
 2. **새 위임 생성:** **Google Workspace에서 전역 도메인 전체 위임을 설정할 수 있는 능력은 오직 슈퍼 관리자 역할만이 가지고 있다는 점을 이해하는 것이 중요합니다.** 도메인 전체 위임은 **프로그래밍 방식으로 설정할 수 없으며,** Google Workspace **콘솔**을 통해 **수동으로** 생성 및 조정할 수 있습니다.
 - 규칙 생성은 **API 제어 → Google Workspace 관리 콘솔에서 도메인 전체 위임 관리** 페이지에서 찾을 수 있습니다.
-3. **OAuth 범위 권한 부여:** 새 위임을 구성할 때 Google은 클라이언트 ID, 즉 **GCP 서비스 계정** 리소스의 **OAuth ID**와 위임이 요구하는 API 호출을 정의하는 **OAuth 범위**라는 두 가지 매개변수만 필요합니다.
- **OAuth 범위의 전체 목록**은 [**여기**](https://developers.google.com/identity/protocols/oauth2/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`
+3. **OAuth 범위 권한 부여:** 새로운 위임을 구성할 때 Google은 클라이언트 ID, 즉 **GCP 서비스 계정** 리소스의 **OAuth ID**와 위임이 요구하는 API 호출을 정의하는 **OAuth 범위**의 두 가지 매개변수만 필요합니다.
+- **전체 OAuth 범위 목록**은 [**여기**](https://developers.google.com/identity/protocols/oauth2/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`
 4. **대상 신원을 대신하여 행동하기:** 이 시점에서 GWS에 기능하는 위임 객체가 있습니다. 이제 **GCP 서비스 계정 개인 키를 사용하여 API 호출을 수행할 수 있습니다** (OAuth 범위 매개변수에 정의된 범위 내에서) 이를 트리거하고 **Google Workspace에 존재하는 모든 신원을 대신하여 행동할 수 있습니다.** 서비스 계정은 필요에 따라 REST API 애플리케이션에 대한 권한에 따라 액세스 토큰을 생성합니다.
- 이 위임을 사용하기 위한 **도구**는 **이전 섹션**을 확인하십시오.
+- 이 위임을 사용하기 위한 **도구**는 **이전 섹션**을 확인하세요.

 #### 교차 조직 위임

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

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

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

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

 > [!CAUTION]
 > 사용자가 Workspace를 열거할 수 있으려면 충분한 Workspace 권한이 필요합니다 (모든 사용자가 디렉토리를 열거할 수 있는 것은 아닙니다).
@@ -116,7 +120,7 @@ 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>
 ```
-확인하십시오 **더 많은 열거**에서:
+확인하십시오 **더 많은 열거**:

 {{#ref}}
 ../gcp-services/gcp-iam-and-org-policies-enum.md
@@ -131,7 +135,7 @@ gcloud beta identity groups preview --customer <org-cust-id>
 {{#endref}}

 거기에서 설명한 바와 같이, gcloud는 사용자가 드라이브에 접근할 수 있도록 하는 **`https://www.googleapis.com/auth/drive`** 범위를 요청할 수 있습니다.\
-공격자로서, 사용자의 컴퓨터를 **물리적으로** 손상시키고 **사용자가 여전히** 자신의 계정으로 로그인한 경우, 다음을 사용하여 드라이브에 접근할 수 있는 토큰을 생성하여 로그인할 수 있습니다:
+공격자로서, 사용자의 컴퓨터를 **물리적으로** 침해하고 **사용자가 여전히** 자신의 계정으로 로그인한 경우, 다음을 사용하여 드라이브에 접근할 수 있는 토큰을 생성하여 로그인할 수 있습니다:
 ```bash
 gcloud auth login --enable-gdrive-access
 ```
@@ -140,7 +144,7 @@ gcloud auth login --enable-gdrive-access
 <figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>

 > [!WARNING]
-> 따라서 사용자가 다음에 로그인할 때 공격자가 드라이브에 접근할 수 있는 **토큰을 생성**하게 됩니다. 물론 브라우저는 생성된 토큰이 드라이브에 접근할 수 있음을 표시하지만, 사용자가 **`gcloud auth login`**을 호출할 것이기 때문에 아마도 **의심하지 않을 것입니다.**
+> 따라서 사용자가 다음에 로그인할 때 공격자가 드라이브에 접근할 수 있는 **토큰을 생성**하게 됩니다. 물론 브라우저는 생성된 토큰이 드라이브에 접근할 수 있음을 나타내지만, 사용자가 **`gcloud auth login`**을 호출할 것이기 때문에 아마도 **의심하지 않을 것입니다.**
 >
 > 드라이브 파일을 나열하려면: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**

@@ -148,7 +152,7 @@ gcloud auth login --enable-gdrive-access

 ### 권한이 있는 GCP 사용자 접근

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

 ### Google Groups 권한 상승