GWS - Admin Directory Sync
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)
GCDS와 사용자를 동기화하는 이 방법의 주요 차이점은 GCDS가 다운로드하여 실행해야 하는 일부 바이너리로 수동으로 수행되는 반면, Admin Directory Sync는 서버리스로 Google에서 관리된다는 것입니다. https://admin.google.com/ac/sync/externaldirectories에서 확인할 수 있습니다.
이 글을 작성하는 시점에서 이 서비스는 베타 상태이며 두 가지 유형의 동기화를 지원합니다: Active Directory와 Azure Entra ID에서:
Active Directory: 이를 설정하려면 Google에 Active Directory 환경에 대한 액세스 권한을 부여해야 합니다. Google은 GCP 네트워크에만 액세스할 수 있으므로(VPC 커넥터를 통해) 커넥터를 생성한 다음 GCP 네트워크의 VM에 AD를 두거나 Cloud VPN 또는 Cloud Interconnect를 사용하여 해당 커넥터에서 AD를 사용할 수 있도록 해야 합니다. 그런 다음 디렉토리에 대한 읽기 액세스 권한이 있는 계정의 자격 증명과 LDAPS를 통해 연락하기 위한 인증서를 제공해야 합니다.
Azure Entra ID: 이를 구성하려면 Google이 표시하는 팝업에서 읽기 액세스 권한이 있는 사용자로 Azure에 로그인하기만 하면 되며, Google은 Entra ID에 대한 읽기 액세스 권한이 있는 토큰을 유지합니다.
올바르게 구성되면 두 옵션 모두 사용자 및 그룹을 Workspace와 동기화할 수 있지만, Workspace에서 AD 또는 EntraID로 사용자 및 그룹을 구성할 수는 없습니다.
이 동기화 중에 허용되는 다른 옵션은 다음과 같습니다:
새 사용자에게 로그인하라는 이메일 전송
Workspace에서 사용하는 이메일 주소로 자동으로 변경. 따라서 Workspace가 @hacktricks.xyz
를 사용하고 EntraID 사용자가 @carloshacktricks.onmicrosoft.com
을 사용하는 경우, @hacktricks.xyz
가 계정에 생성된 사용자에게 사용됩니다.
동기화할 사용자가 포함된 그룹 선택.
Workspace에서 동기화하고 생성할 그룹 선택(또는 모든 그룹을 동기화하도록 지정).
AD 또는 EntraID를 손상시키면 Google Workspace와 동기화될 사용자 및 그룹에 대한 전체 제어를 갖게 됩니다. 그러나 사용자가 Workspace에서 사용할 수 있는 비밀번호는 같을 수도 있고 다를 수도 있습니다.
동기화가 발생하면 AD의 모든 사용자 또는 특정 OU의 사용자만 동기화되거나 EntraID의 특정 그룹의 사용자만 동기화될 수 있습니다. 이는 동기화된 사용자(또는 동기화되는 새 사용자)를 공격하려면 먼저 어떤 사용자가 동기화되고 있는지 파악해야 함을 의미합니다.
사용자는 AD 또는 EntraID에서 비밀번호를 재사용할 수도 있고 아닐 수도 있지만, 이는 사용자의 비밀번호를 손상시켜 로그인해야 함을 의미합니다.
사용자의 메일에 액세스할 수 있다면, 기존 사용자의 Workspace 비밀번호를 변경하거나 새 사용자를 생성하고, 동기화될 때까지 기다려 계정을 설정할 수 있습니다.
Workspace 내에서 사용자에 액세스하면 기본적으로 일부 권한이 부여될 수 있습니다.
어떤 그룹이 동기화되고 있는지 먼저 파악해야 합니다. 모든 그룹이 동기화될 가능성이 있지만(Workspace가 이를 허용하므로).
그룹 및 구성원이 Workspace로 가져와지더라도, 사용자 동기화에서 동기화되지 않은 사용자는 그룹 동기화 중에 생성되지 않습니다. 비록 그들이 동기화된 그룹의 구성원일지라도 말입니다.
Azure에서 어떤 그룹이 Workspace 또는 GCP에서 권한을 부여받고 있는지 알고 있다면, 손상된 사용자(또는 새로 생성된 사용자)를 해당 그룹에 추가하여 그 권한을 얻을 수 있습니다.
Workspace에서 기존의 특권 그룹을 악용할 수 있는 또 다른 옵션이 있습니다. 예를 들어, 그룹 gcp-organization-admins@<workspace.email>
는 일반적으로 GCP에 대한 높은 권한을 가지고 있습니다.
예를 들어 EntraID에서 Workspace로의 동기화가 가져온 객체의 도메인을 Workspace의 이메일로 대체하도록 구성된 경우, 공격자가 EntraID에서 gcp-organization-admins@<entraid.email>
그룹을 생성하고 이 그룹에 사용자를 추가한 다음 모든 그룹의 동기화가 발생할 때까지 기다릴 수 있습니다.
사용자는 gcp-organization-admins@<workspace.email>
그룹에 추가되어 GCP에서 권한이 상승하게 됩니다.
Workspace는 사용자 및 그룹을 동기화하기 위해 AD 또는 EntraID에 대한 읽기 전용 액세스 권한이 있는 자격 증명을 요구합니다. 따라서 Google Workspace를 악용하여 AD 또는 EntraID에서 변경을 수행하는 것은 불가능합니다. 따라서 현재로서는 불가능합니다.
Google이 AD 자격 증명이나 EntraID 토큰을 어디에 저장하는지 모르며, 동기화를 재구성하여 복구할 수 없습니다(웹 양식에 나타나지 않으며, 다시 제공해야 합니다). 그러나 웹에서 현재 기능을 악용하여 사용자 및 그룹 목록을 나열할 수 있을지도 모릅니다.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)