GCP <--> Workspace Pivoting
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Google Workspace의 도메인 전체 위임은 Google Workspace Marketplace의 외부 앱 또는 내부 GCP 서비스 계정과 같은 신원 객체가 사용자를 대신하여 Workspace 전반의 데이터에 접근할 수 있도록 허용합니다.
이는 기본적으로 조직의 GCP 프로젝트 내 서비스 계정이 동일 조직의 Workspace 사용자(또는 다른 조직의 사용자도 포함하여)를 가장할 수 있을 가능성이 있음을 의미합니다.
이것이 정확히 어떻게 작동하는지에 대한 더 많은 정보는 다음을 확인하세요:
공격자가 GCP에 대한 일부 접근을 타협하고 회사의 유효한 Workspace 사용자 이메일(바람직하게는 슈퍼 관리자)을 알고 있다면, 그는 접근할 수 있는 모든 프로젝트를 나열하고, 프로젝트의 모든 SA를 나열하며, 접근할 수 있는 서비스 계정을 확인하고, 가장할 수 있는 각 SA에 대해 이러한 모든 단계를 반복할 수 있습니다. 그가 접근할 수 있는 모든 서비스 계정의 목록과 Workspace 이메일 목록을 가지고 있다면, 공격자는 각 서비스 계정으로 사용자를 가장하려고 시도할 수 있습니다.
도메인 전체 위임을 구성할 때 Workspace 사용자가 필요하지 않다는 점에 유의하세요. 따라서 유효한 사용자 하나만 알면 가장하는 데 충분하고 필요합니다. 그러나 가장한 사용자의 권한이 사용되므로, 만약 슈퍼 관리자라면 모든 것에 접근할 수 있습니다. 접근 권한이 없다면 이는 무의미할 것입니다.
이 간단한 스크립트는 위임된 사용자로서 OAuth 토큰을 생성하며, 이를 사용하여 gcloud 유무에 관계없이 다른 Google API에 접근할 수 있습니다:
이 도구는 다음 단계를 따라 공격을 수행할 수 있습니다:
Resource Manager API를 사용하여 GCP 프로젝트를 나열합니다.
각 프로젝트 리소스를 반복하고, 초기 IAM 사용자가 접근할 수 있는 GCP 서비스 계정 리소스를 _GetIAMPolicy_를 사용하여 나열합니다.
각 서비스 계정 역할을 반복하고, 대상 서비스 계정 리소스에서 serviceAccountKeys.create 권한을 가진 내장, 기본 및 사용자 정의 역할을 찾습니다. 편집자 역할은 본질적으로 이 권한을 가지고 있다는 점에 유의해야 합니다.
IAM 정책에서 관련 권한이 발견된 각 서비스 계정 리소스에 대해 새 KEY_ALG_RSA_2048 개인 키를 생성합니다.
각 새 서비스 계정을 반복하고 JWT 객체를 생성합니다. 이 객체는 SA 개인 키 자격 증명과 OAuth 범위로 구성됩니다. 새 JWT 객체를 생성하는 과정은 oauth_scopes.txt 목록의 모든 기존 OAuth 범위 조합을 반복하여 모든 위임 가능성을 찾습니다. 목록 oauth_scopes.txt는 Workspace ID를 악용하는 데 관련된 모든 OAuth 범위로 업데이트됩니다.
_make_authorization_grant_assertion 메서드는 DWD 하에서 JWT를 생성하기 위해 _subject_라고 하는 대상 워크스페이스 사용자를 선언해야 함을 나타냅니다. 특정 사용자가 필요할 것처럼 보일 수 있지만, DWD는 도메인 내 모든 ID에 영향을 미친다는 점을 인식하는 것이 중요합니다. 따라서 모든 도메인 사용자에 대한 JWT를 생성하는 것은 해당 도메인의 모든 ID에 영향을 미치며, 이는 우리의 조합 나열 확인과 일치합니다. 간단히 말해, 유효한 Workspace 사용자 하나면 충분합니다.
이 사용자는 DeleFriend의 config.yaml 파일에서 정의할 수 있습니다. 대상 워크스페이스 사용자가 이미 알려져 있지 않은 경우, 이 도구는 GCP 프로젝트에서 역할을 가진 도메인 사용자를 스캔하여 유효한 워크스페이스 사용자를 자동으로 식별하는 기능을 제공합니다. 다시 말하지만, JWT는 도메인 특정이며 모든 사용자에 대해 생성되지 않으므로 자동 프로세스는 도메인당 단일 고유 ID를 대상으로 합니다.
각 JWT에 대해 새로운 베어러 액세스 토큰을 나열하고 생성하며, tokeninfo API에 대해 토큰을 검증합니다.
Gitlab은 사용자 디렉토리를 나열하고 SA 자격 증명 및 가장할 사용자를 포함하는 json을 표시하면서 새 관리 계정을 생성할 수 있는 이 Python 스크립트를 만들었습니다. 사용 방법은 다음과 같습니다:
**https://admin.google.com/u/1/ac/owl/domainwidedelegation**에서 도메인 전체 위임을 확인할 수 있습니다.
GCP 프로젝트에서 서비스 계정을 생성할 수 있는 능력과 GWS에 대한 슈퍼 관리자 권한을 가진 공격자는 SAs가 일부 GWS 사용자를 가장할 수 있도록 하는 새로운 위임을 생성할 수 있습니다:
새 서비스 계정 및 해당 키 쌍 생성: GCP에서 새로운 서비스 계정 리소스는 콘솔을 통해 대화식으로 또는 직접 API 호출 및 CLI 도구를 사용하여 프로그래밍 방식으로 생성할 수 있습니다. 이는 iam.serviceAccountAdmin 역할 또는 iam.serviceAccounts.create 권한이 있는 사용자 정의 역할이 필요합니다. 서비스 계정이 생성되면 관련 키 쌍을 생성하는 단계로 진행합니다 (iam.serviceAccountKeys.create 권한).
새 위임 생성: Google Workspace에서 전역 도메인 전체 위임을 설정할 수 있는 능력은 오직 슈퍼 관리자 역할만이 가지고 있다는 점을 이해하는 것이 중요합니다. 도메인 전체 위임은 프로그래밍 방식으로 설정할 수 없으며, Google Workspace 콘솔을 통해 수동으로 생성 및 조정할 수 있습니다.
규칙 생성은 API 제어 → Google Workspace 관리 콘솔에서 도메인 전체 위임 관리 페이지에서 찾을 수 있습니다.
OAuth 범위 권한 부여: 새로운 위임을 구성할 때 Google은 GCP 서비스 계정 리소스의 OAuth ID인 클라이언트 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
대상 신원을 대신하여 행동하기: 이 시점에서 우리는 GWS에서 작동하는 위임된 객체를 가지고 있습니다. 이제 GCP 서비스 계정 개인 키를 사용하여 API 호출을 수행할 수 있습니다 (OAuth 범위 매개변수에 정의된 범위 내에서) 이를 트리거하고 Google Workspace에 존재하는 모든 신원을 대신하여 행동할 수 있습니다. 서비스 계정은 필요에 따라 REST API 애플리케이션에 대한 권한에 따라 액세스 토큰을 생성합니다.
이 위임을 사용하기 위한 도구는 이전 섹션을 확인하십시오.
OAuth SA ID는 전역적이며 교차 조직 위임에 사용할 수 있습니다. 교차 글로벌 위임을 방지하기 위한 제한이 구현되지 않았습니다. 간단히 말해, 다른 GCP 조직의 서비스 계정을 사용하여 다른 Workspace 조직에서 도메인 전체 위임을 구성할 수 있습니다. 이는 Workspace에 대한 슈퍼 관리자 액세스만 필요하고, 동일한 GCP 계정에 대한 액세스는 필요하지 않으며, 적대자는 개인적으로 제어하는 GCP 계정에서 서비스 계정 및 개인 키를 생성할 수 있습니다.
기본적으로 Workspace 사용자는 새 프로젝트를 생성할 수 있는 권한을 가지고 있으며, 새 프로젝트가 생성되면 생성자는 해당 프로젝트에 대한 소유자 역할을 부여받습니다.
따라서 사용자는 프로젝트를 생성하고, API를 활성화하여 새 프로젝트에서 Workspace를 열거하고 열거하려고 시도할 수 있습니다.
사용자가 Workspace를 열거할 수 있으려면 충분한 Workspace 권한이 필요합니다 (모든 사용자가 디렉토리를 열거할 수 있는 것은 아닙니다).
Check 더 많은 열거는:
gcloud 로그인 흐름에 대한 추가 정보를 찾을 수 있습니다:
거기에서 설명한 바와 같이, gcloud는 사용자가 자신의 드라이브에 접근할 수 있도록 하는 https://www.googleapis.com/auth/drive 범위를 요청할 수 있습니다.
공격자로서, 사용자의 컴퓨터를 물리적으로 침해하고 사용자가 여전히 자신의 계정으로 로그인한 경우, 다음을 사용하여 드라이브에 접근할 수 있는 토큰을 생성하여 로그인할 수 있습니다:
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"
공격자가 GWS에 완전한 접근 권한을 가지고 있다면 GCP에 대한 권한이 있는 그룹이나 사용자에 접근할 수 있습니다. 따라서 GWS에서 GCP로 이동하는 것은 일반적으로 GWS의 사용자들이 GCP에 대해 높은 권한을 가지고 있기 때문에 더 "간단"합니다.
기본적으로 사용자는 조직의 Workspace 그룹에 자유롭게 가입할 수 있으며 이러한 그룹은 GCP 권한이 할당될 수 있습니다 (자신의 그룹을 https://groups.google.com/에서 확인하세요).
google groups privesc를 악용하면 GCP에 대한 어떤 형태의 권한이 있는 그룹으로 상승할 수 있습니다.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
