GCP <--> Workspace Pivoting
GCP에서 GWS로
도메인 와이드 위임 기본 사항
Google Workspace의 도메인 와이드 위임은 Google Workspace Marketplace의 외부 앱 또는 내부 GCP 서비스 계정을 통해 사용자를 대신하여 Workspace 전체의 데이터에 액세스할 수 있게 합니다.
이는 기본적으로 조직의 GCP 프로젝트 내의 서비스 계정이 동일한 조직의 Workspace 사용자 (또는 다른 조직의 사용자)를 가장할 수 있음을 의미합니다.
이것이 정확히 어떻게 작동하는지에 대한 자세한 정보는 다음을 확인하세요:
GCP - Understanding Domain-Wide Delegation기존 위임 침해
공격자가 GCP에서 일부 액세스를 침해하고 회사의 유효한 Workspace 사용자 이메일을 알고 있다면 (가능하면 슈퍼 관리자), 그는 액세스할 수 있는 모든 프로젝트를 열거, 프로젝트의 모든 서비스 계정을 열거, 액세스할 수 있는 서비스 계정을 확인하고 각 서비스 계정으로 이러한 단계를 반복할 수 있습니다. 액세스할 수 있는 모든 서비스 계정 목록과 Workspace 이메일 목록을 가지고 있는 공격자는 각 서비스 계정으로 사용자를 가장해 볼 수 있습니다.
도메인 와이드 위임을 구성할 때 Workspace 사용자가 필요하지 않으므로 하나의 유효한 사용자만 알고 있으면 가장할 수 있도록 필요합니다. 그러나 가장한 사용자의 권한이 사용되므로, 만약 슈퍼 관리자라면 모든 것에 액세스할 수 있습니다. 액세스 권한이 없으면 이것은 쓸모가 없을 것입니다.
이 간단한 스크립트는 위임된 사용자로 OAuth 토큰을 생성하여 이를 사용하여 gcloud
로 다른 Google API에 액세스할 수 있습니다.
이 도구는 다음 단계를 따라 공격을 수행할 수 있는 도구입니다:
리소스 관리자 API를 사용하여 GCP 프로젝트를 열거합니다.
각 프로젝트 리소스를 반복하고 초기 IAM 사용자가 액세스 권한을 가진 GCP 서비스 계정 리소스를 열거합니다. 이는 _GetIAMPolicy_를 사용합니다.
각 서비스 계정 역할을 반복하고 IAM 정책에서 serviceAccountKeys.create 권한이 있는 대상 서비스 계정 리소스를 찾습니다. 이 권한은 기본적으로 Editor 역할이 이 권한을 가지고 있음을 유의해야 합니다.
IAM 정책에서 관련 권한을 가진 각 서비스 계정 리소스에 대해 새로운
KEY_ALG_RSA_2048
개인 키를 생성합니다.각 새로운 서비스 계정을 반복하고 해당 서비스 계정의 JWT 객체를 생성합니다. 이는 SA 개인 키 자격 증명과 OAuth 스코프로 구성된 것이며, 새로운 JWT 객체를 생성하는 과정은 모든 기존 OAuth 스코프 조합을 반복하여 모든 위임 가능성을 찾습니다. 목록 oauth_scopes.txt는 Workspace 신원을 남용하기 위해 관련이 있는 OAuth 스코프를 모두 찾은 것으로 업데이트됩니다.
_make_authorization_grant_assertion
메서드는 DWD 하에서 JWT를 생성하기 위해 _subject_로 지정된 대상 Workspace 사용자를 선언해야 함을 보여줍니다. 이는 특정 사용자를 필요로 할 수 있지만, DWD는 도메인 내 모든 신원에 영향을 미침을 깨달아야 합니다. 따라서 어떤 도메인 사용자에 대한 JWT를 생성하면 해당 도메인의 모든 신원에 영향을 미치며, 조합 열거 검사와 일관됩니다. 간단히 말해, 하나의 유효한 Workspace 사용자만으로 전진할 수 있습니다. 이 사용자는 DeleFriend의 config.yaml 파일에서 정의할 수 있습니다. 대상 Workspace 사용자가 이미 알려지지 않은 경우, 이 도구는 GCP 프로젝트에서 역할을 가진 도메인 사용자를 스캔하여 유효한 Workspace 사용자를 자동으로 식별하는 것을 용이하게 합니다. 다시 한 번 강조하지만, JWT는 도메인별이며 모든 사용자에 대해 생성되지 않으므로, 자동 프로세스는 도메인당 단일 고유 신원을 대상으로 합니다.각 JWT에 대해 새로운 베어러 액세스 토큰을 열거하고 생성하며, 토큰을 tokeninfo API에 대해 유효성을 검사합니다.
Gitlab은 이 Python 스크립트를 만들었으며, 사용자 디렉토리를 나열하고 SA 자격 증명 및 표시할 사용자를 나타내는 json을 지정하면서 새로운 관리 계정을 생성할 수 있는 두 가지 기능을 수행할 수 있습니다. 사용 방법은 다음과 같습니다:
새 위임 생성 (지속성)
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은 클라이언트 ID와 OAuth 스코프 두 가지 매개변수만 필요로 합니다. 클라이언트 ID는 GCP 서비스 계정 리소스의 OAuth ID이며, 스코프는 위임이 필요로 하는 API 호출을 정의합니다.
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 서비스 계정 개인 키를 사용하여 (OAuth 스코프 매개변수에서 정의된 범위 내에서) API 호출을 수행하여 Google Workspace에 존재하는 모든 신원을 대신하여 작동할 수 있습니다. 서비스 계정은 REST API 애플리케이션에 대한 권한에 따라 필요에 따라 액세스 토큰을 생성할 것입니다.
이 위임을 사용하는 도구에 대한 정보는 이전 섹션을 확인하세요.
조직 간 위임
OAuth SA ID는 전역적이며 조직 간 위임에 사용할 수 있습니다. 교차 글로벌 위임을 방지하기 위한 제한이 없습니다. 간단히 말해, 다른 GCP 조직의 서비스 계정을 사용하여 다른 Workspace 조직에 대한 도메인 와이드 위임을 구성할 수 있습니다. 이로 인해 Workspace에 대한 슈퍼 관리자 액세스만 필요하며, 동일한 GCP 계정에 대한 액세스는 필요하지 않습니다. 공격자는 서비스 계정 및 개인 키를 자신이 제어하는 GCP 계정에서 생성할 수 있습니다.
Workspace 열거를 위한 프로젝트 생성
기본적으로 Workspace 사용자는 새 프로젝트를 생성할 수 있는 권한을 가지며, 새 프로젝트가 생성되면 생성자가 해당 프로젝트에 소유자 역할을 부여받습니다.
따라서 사용자는 프로젝트를 생성하고, 새 프로젝트에서 Workspace를 열거하기 위해 API를 활성화하고 시도할 수 있습니다.
사용자가 Workspace를 열거할 수 있도록 하려면 충분한 Workspace 권한이 필요합니다 (모든 사용자가 디렉터리를 열거할 수 있는 것은 아닙니다).
더 많은 열거를 확인하십시오:
GCP - IAM, Principals & Org Policies EnumGcloud 남용
gcloud
흐름에 대한 자세한 정보를 찾을 수 있습니다:
거기에서 설명한대로, gcloud는 사용자가 드라이브에 액세스할 수 있도록 하는 https://www.googleapis.com/auth/drive
범위를 요청할 수 있습니다.
공격자로서, 사용자의 컴퓨터를 물리적으로 침투했고 사용자가 계정에 로그인된 상태인 경우에는 드라이브에 액세스할 수 있는 토큰을 생성하여 로그인할 수 있습니다:
만약 공격자가 사용자의 컴퓨터를 침입하면 google-cloud-sdk/lib/googlecloudsdk/core/config.py
파일을 수정하여 **CLOUDSDK_SCOPES
**에 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로
특권 있는 GCP 사용자에 액세스
공격자가 GWS에 완전한 액세스 권한을 가지고 있다면 GCP에 대한 특권 액세스를 가진 그룹 또는 사용자에게 액세스할 수 있으므로 GWS에서 GCP로 이동하는 것은 일반적으로 더 "간단"합니다. GWS의 사용자는 GCP에 대한 높은 권한을 가지고 있기 때문입니다.
Google 그룹 특권 상승
기본적으로 사용자는 조직의 Workspace 그룹에 자유롭게 가입할 수 있으며 해당 그룹에는 할당된 GCP 권한이 있을 수 있습니다(https://groups.google.com/에서 그룹을 확인하세요).
google 그룹 특권 상승을 악용하여 특권 있는 GCP 그룹으로 상승할 수 있습니다.
참고 자료
Last updated