mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 14:47:17 -07:00
Translated ['', 'src/pentesting-cloud/workspace-security/gws-google-plat
This commit is contained in:
Translator
+16
-16
@@ -4,44 +4,44 @@
|
||||
|
||||
## Informazioni di base
|
||||
|
||||
Nelle architetture Exchange Hybrid legacy, la distribuzione Exchange on-prem poteva autenticarsi come la stessa identità applicativa Entra utilizzata da Exchange Online. Se un attaccante comprometteva il server Exchange, estraeva la chiave privata del certificato hybrid e eseguiva un OAuth client-credentials flow, poteva ottenere token first-party con il contesto di privilegi di Exchange Online.
|
||||
Nelle architetture legacy di Exchange Hybrid, la deployment on-prem di Exchange poteva autenticarsi come la stessa identità dell'applicazione Entra usata da Exchange Online. Se un attaccante comprometteva il server Exchange, estraeva la chiave privata del certificato hybrid e eseguiva un OAuth client-credentials flow, poteva ottenere token first-party con il contesto di privilegi di Exchange Online.
|
||||
|
||||
Il rischio pratico non si limitava all'accesso alle caselle. Poiché Exchange Online aveva ampie relazioni di trust back-end, questa identità poteva interagire con altri servizi Microsoft 365 e, nei comportamenti più vecchi, poteva essere sfruttata per un compromesso più profondo del tenant.
|
||||
Il rischio pratico non si limitava all'accesso alle cassette postali. Poiché Exchange Online aveva ampie relazioni di trust back-end, questa identità poteva interagire con altri servizi Microsoft 365 e, nei comportamenti più vecchi, poteva essere sfruttata per un compromesso più profondo del tenant.
|
||||
|
||||
## Percorsi d'attacco e flusso tecnico
|
||||
|
||||
### Modificare la configurazione di federazione tramite Exchange
|
||||
### Modificare la configurazione di federation tramite Exchange
|
||||
|
||||
Storicamente i token di Exchange avevano permessi per scrivere le impostazioni di dominio/federazione. Dal punto di vista dell'attaccante, questo permetteva la manipolazione diretta dei dati di trust del dominio federato, incluse le liste di certificati per la firma dei token e i flag di configurazione che controllavano l'accettazione delle MFA-claim dall'infrastruttura di federazione on-prem.
|
||||
Storicamente, i token di Exchange avevano permessi per scrivere le impostazioni di dominio/federation. Dal punto di vista di un attaccante, questo permetteva la manipolazione diretta dei dati di trust dei domini federati, incluse le liste dei certificati per la firma dei token e i flag di configurazione che controllavano l'accettazione delle MFA-claim dall'infrastruttura di federation on-prem.
|
||||
|
||||
Ciò significa che un server Exchange Hybrid compromesso poteva essere usato per avviare o rafforzare un'impersonazione in stile ADFS modificando la config di federazione dalla parte cloud, anche quando l'attaccante era partito solo da una compromissione di Exchange on-prem.
|
||||
Ciò significa che un server Exchange Hybrid compromesso poteva essere usato per orchestrare o rafforzare un'impersonazione in stile ADFS modificando la config di federation dalla parte cloud, anche quando l'attaccante era partito solo da una compromissione di Exchange on-prem.
|
||||
|
||||
### ACS Actor Tokens e impersonazione servizio-a-servizio
|
||||
### ACS Actor Tokens and Service-to-Service Impersonation
|
||||
|
||||
Il percorso di autenticazione hybrid di Exchange usava Access Control Service (ACS) actor tokens con `trustedfordelegation=true`. Questi actor token venivano poi incorporati in un secondo service token non firmato che trasportava l'identità dell'utente target in una sezione controllata dall'attaccante. Poiché il token esterno non era firmato e l'actor token delegava ampiamente, il chiamante poteva sostituire gli utenti target senza ri-autenticarsi.
|
||||
Il percorso di auth hybrid di Exchange usava Access Control Service (ACS) actor tokens con `trustedfordelegation=true`. Quei actor token venivano poi incorporati in un secondo service token non firmato che portava l'identità dell'utente target in una sezione controllata dall'attaccante. Poiché il token esterno non era firmato e l'actor token delegava ampiamente, il chiamante poteva scambiare utenti target senza ri-autenticarsi.
|
||||
|
||||
In pratica, una volta ottenuto l'actor token, l'attaccante disponeva di una primitiva di impersonazione a lunga durata (tipicamente circa 24 ore) difficile da revocare a metà vita. Ciò abilitava l'impersonazione di utenti attraverso le API di Exchange Online e SharePoint/OneDrive, includendo esfiltrazione di dati ad alto valore.
|
||||
In pratica, una volta ottenuto l'actor token, l'attaccante disponeva di una primitiva di impersonazione a lunga durata (tipicamente circa 24 ore) difficile da revocare a metà vita. Questo consentiva l'impersonazione di utenti attraverso le API di Exchange Online e SharePoint/OneDrive, inclusa l'esfiltrazione di dati ad alto valore.
|
||||
|
||||
Storicamente, lo stesso pattern funzionava anche contro `graph.windows.net` costruendo un token di impersonazione con il valore `netId` della vittima. Questo forniva azioni amministrative dirette su Entra come utenti arbitrari e permetteva workflow di takeover completo del tenant (per esempio, la creazione di un nuovo account Global Administrator).
|
||||
Storicamente, lo stesso schema funzionava anche contro `graph.windows.net` costruendo un token di impersonazione con il `netId` della vittima. Ciò permetteva azioni amministrative dirette in Entra come utenti arbitrari e abilitava workflow di takeover dell'intero tenant (per esempio, la creazione di un nuovo account Global Administrator).
|
||||
|
||||
## Cosa non funziona più
|
||||
|
||||
Il percorso di impersonazione `graph.windows.net` via Exchange Hybrid actor tokens è stato corretto. La vecchia catena "Exchange to arbitrary Entra admin over Graph" dovrebbe essere considerata rimossa per questa specifica via di token.
|
||||
Il percorso di impersonazione `graph.windows.net` via Exchange Hybrid actor tokens è stato corretto. La vecchia catena "Exchange to arbitrary Entra admin over Graph" dovrebbe essere considerata rimossa per questa specifica route di token.
|
||||
|
||||
Questa è la correzione più importante da evidenziare nella documentazione dell'attacco: mantenere il rischio di impersonazione Exchange/SharePoint separato dall'escalation di impersonazione Graph ora patchata.
|
||||
Questa è la correzione più importante da documentare per l'attacco: mantenere separato il rischio di impersonazione Exchange/SharePoint dall'escalation di impersonazione su Graph ora patchata.
|
||||
|
||||
## Cosa può ancora essere rilevante in pratica
|
||||
## Ciò che può ancora avere importanza nella pratica
|
||||
|
||||
Se un'organizzazione esegue ancora una configurazione hybrid vecchia o incompleta con trust condiviso e materiale di certificato esposto, l'impatto dell'impersonazione Exchange/SharePoint può rimanere severo. L'angolo di abuso della configurazione di federazione può anche rimanere rilevante a seconda della configurazione del tenant e dello stato di migrazione.
|
||||
Se un'organizzazione esegue ancora una configurazione hybrid vecchia o incompleta con trust condiviso e materiale dei certificati esposto, l'impatto dell'impersonazione Exchange/SharePoint può rimanere grave. L'angolo di abuso della configurazione di federation può anche restare rilevante a seconda della configurazione del tenant e dello stato della migrazione.
|
||||
|
||||
La mitigazione a lungo termine di Microsoft è separare le identità on-prem e Exchange Online in modo che il percorso di trust del shared-service-principal non esista più. Gli ambienti che hanno completato quella migrazione riducono materialmente questa superficie d'attacco.
|
||||
La mitigazione a lungo termine di Microsoft è separare le identità on-prem e di Exchange Online in modo che il percorso di trust del shared-service-principal non esista più. Gli ambienti che hanno completato quella migrazione riducono materialmente questa superficie d'attacco.
|
||||
|
||||
## Note di rilevamento
|
||||
|
||||
Quando questa tecnica viene abusata, gli eventi di audit possono mostrare mismatch di identità in cui lo user principal name corrisponde a un utente impersonato mentre il contesto di display/sorgente indica attività di Exchange Online. Quel pattern di identità mista è un segnale di hunting di alto valore, sebbene i difensori debbano basare una baseline dei workflow legittimi degli Exchange-admin per ridurre i falsi positivi.
|
||||
Quando questa tecnica viene abusata, gli eventi di audit possono mostrare mismatch di identità in cui lo user principal name corrisponde a un utente impersonato mentre il contesto display/source punta ad attività di Exchange Online. Quel pattern di identità mista è un segnale di hunting ad alto valore, sebbene i defender dovrebbero definire una baseline dei workflow legittimi degli Exchange-admin per ridurre i falsi positivi.
|
||||
|
||||
## Riferimenti
|
||||
|
||||
- https://www.youtube.com/watch?v=rzfAutv6sB8
|
||||
- [https://www.youtube.com/watch?v=rzfAutv6sB8](https://www.youtube.com/watch?v=rzfAutv6sB8)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Generic Phishing Methodology
|
||||
## Metodologia Generica di Phishing
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html
|
||||
@@ -10,51 +10,51 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
|
||||
## Google Groups Phishing
|
||||
|
||||
A quanto pare, per impostazione predefinita, nei workspace i membri [**possono creare gruppi**](https://groups.google.com/all-groups) **e invitare persone a farne parte**. Puoi quindi modificare l'email che verrà inviata all'utente **aggiungendo alcuni link.** L'**email verrà inviata da un indirizzo google**, quindi sembrerà **legittima** e le persone potrebbero cliccare sul link.
|
||||
Apparentemente, di default, in Workspace i membri [**possono creare gruppi**](https://groups.google.com/all-groups) **e invitare persone in essi**. Puoi poi modificare l'email che sarà inviata all'utente **aggiungendo alcuni link.** L'**email arriverà da un indirizzo Google**, quindi sembrerà **legittima** e le persone potrebbero cliccare sul link.
|
||||
|
||||
È anche possibile impostare l'indirizzo **FROM** come l'**email del gruppo Google** per inviare **ulteriori email agli utenti all'interno del gruppo**, come nell'immagine seguente dove il gruppo **`google--support@googlegroups.com`** è stato creato e un'**email è stata inviata a tutti i membri** del gruppo (che sono stati aggiunti senza alcun consenso)
|
||||
È anche possibile impostare l'indirizzo **FROM** come la **Google group email** per inviare **più email agli utenti all'interno del gruppo**, come nell'immagine seguente dove il gruppo **`google--support@googlegroups.com`** è stato creato e un **email è stata inviata a tutti i membri** del gruppo (aggiunti senza alcun consenso)
|
||||
|
||||
<figure><img src="../../../images/image (5) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Google Chat Phishing
|
||||
|
||||
Potresti essere in grado di **iniziare una chat** con una persona semplicemente avendo il suo indirizzo email o inviare un'**invito a parlare**. Inoltre, è possibile **creare uno Spazio** che può avere qualsiasi nome (ad es. "Google Support") e **invitare** membri a farne parte. Se accettano, potrebbero pensare di stare parlando con il supporto Google:
|
||||
Potresti riuscire a iniziare una chat con una persona avendo solo il suo indirizzo email o inviare un **invito a parlare**. Inoltre, è possibile creare uno Space che può avere qualsiasi nome (es. "Google Support") e **invitare** membri. Se accettano potrebbero pensare di stare parlando con Google Support:
|
||||
|
||||
<figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!TIP]
|
||||
> **Tuttavia, nei miei test i membri invitati non hanno nemmeno ricevuto un invito.**
|
||||
> Nei miei test, però, i membri invitati non hanno nemmeno ricevuto l'invito.
|
||||
|
||||
Puoi controllare come questo ha funzionato in passato in: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s)
|
||||
Puoi vedere come funzionava in passato su: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s)
|
||||
|
||||
## Google Doc Phishing
|
||||
|
||||
In passato era possibile creare un **documento apparentemente legittimo** e in un commento **menzionare un'email (come @user@gmail.com)**. Google **inviava un'email a quell'indirizzo email** notificando che era stato menzionato nel documento.\
|
||||
Oggigiorno, questo non funziona più, ma se **dai accesso al documento alla vittima** Google invierà un'email che lo indica. Questo è il messaggio che appare quando menzioni qualcuno:
|
||||
In passato era possibile creare un documento apparentemente legittimo e poi in un commento menzionare un'email (es. @user@gmail.com). Google inviava un'email a quell'indirizzo notificando che erano stati menzionati nel documento.\
|
||||
Oggi questo non funziona, ma se dai all'email della vittima l'accesso al documento Google invierà un'email che lo indica. Questo è il messaggio che appare quando menzioni qualcuno:
|
||||
|
||||
<figure><img src="../../../images/image (7).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!TIP]
|
||||
> Le vittime potrebbero avere meccanismi di protezione che non permettono che le email che indicano che un documento esterno è stato condiviso con loro raggiungano la loro email.
|
||||
> Le vittime potrebbero avere meccanismi di protezione che non permettono che le email che indicano che un documento esterno è stato condiviso con loro arrivino alla loro casella.
|
||||
|
||||
## Google Calendar Phishing
|
||||
|
||||
Puoi **creare un evento di calendario** e aggiungere quanti più indirizzi email dell'azienda che stai attaccando. Pianifica questo evento di calendario in **5 o 15 minuti** dall'orario attuale. Fai sembrare l'evento legittimo e **metti un commento e un titolo che indicano che devono leggere qualcosa** (con il **link di phishing**).
|
||||
Puoi creare un evento del calendario e aggiungere quanti indirizzi email dell'azienda che stai attaccando vuoi. Pianifica questo evento del calendario tra 5 o 15 minuti dall'orario corrente. Fai sembrare l'evento legittimo e **inserisci un commento e un titolo che indichino che devono leggere qualcosa** (con il **phishing link**).
|
||||
|
||||
Questo è l'avviso che apparirà nel browser con un titolo di riunione "Licenziare persone", quindi potresti impostare un titolo più simile al phishing (e persino cambiare il nome associato alla tua email).
|
||||
Questo è l'avviso che apparirà nel browser con un titolo della riunione "Firing People", quindi potresti impostare un titolo più da phishing (e persino cambiare il nome associato alla tua email).
|
||||
|
||||
<figure><img src="../../../images/image (8).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Per farlo sembrare meno sospetto:
|
||||
Per renderlo meno sospetto:
|
||||
|
||||
- Impostalo in modo che **i destinatari non possano vedere le altre persone invitate**
|
||||
- **NON inviare email che notificano l'evento**. Così, le persone vedranno solo il loro avviso riguardo a una riunione tra 5 minuti e che devono leggere quel link.
|
||||
- A quanto pare, utilizzando l'API puoi impostare su **True** che **le persone** hanno **accettato** l'evento e persino creare **commenti a loro nome**.
|
||||
- Configuralo in modo che **i destinatari non possano vedere le altre persone invitate**
|
||||
- **NON** inviare email di notifica dell'evento. Così, le persone vedranno solo l'avviso della riunione tra 5 minuti e che devono leggere quel link.
|
||||
- Apparentemente usando l'API puoi impostare a **True** che **le persone** hanno **accettato** l'evento e persino creare **commenti per conto loro**.
|
||||
|
||||
## App Scripts Redirect Phishing
|
||||
|
||||
È possibile creare uno script in [https://script.google.com/](https://script.google.com/) e **esporlo come un'applicazione web accessibile a tutti** che utilizzerà il dominio legittimo **`script.google.com`**.\
|
||||
Con un codice come il seguente, un attaccante potrebbe far caricare contenuti arbitrari in questa pagina senza smettere di accedere al dominio:
|
||||
È possibile creare uno script su [https://script.google.com/](https://script.google.com/) ed esporlo come web application accessibile da chiunque che utilizzerà il dominio legittimo **`script.google.com`**.\
|
||||
Con un codice come il seguente un attacker potrebbe far caricare contenuto arbitrario in questa pagina senza smettere di accedere al dominio:
|
||||
```javascript
|
||||
function doGet() {
|
||||
return HtmlService.createHtmlOutput(
|
||||
@@ -62,16 +62,16 @@ return HtmlService.createHtmlOutput(
|
||||
).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL)
|
||||
}
|
||||
```
|
||||
Per esempio, accedendo a [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) vedrai:
|
||||
For example accessing [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) you will see:
|
||||
|
||||
<figure><img src="../../../images/image (4) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!TIP]
|
||||
> Nota che apparirà un avviso mentre il contenuto viene caricato all'interno di un iframe.
|
||||
> Nota che apparirà un avviso poiché il contenuto viene caricato all'interno di un iframe.
|
||||
|
||||
## App Scripts OAuth Phishing
|
||||
|
||||
È possibile creare App Scripts collegati a documenti per cercare di ottenere accesso al token OAuth di una vittima, per ulteriori informazioni controlla:
|
||||
È possibile creare App Scripts collegati ai documenti per cercare di ottenere accesso al token OAuth di una vittima; per maggiori informazioni consulta:
|
||||
|
||||
{{#ref}}
|
||||
gws-app-scripts.md
|
||||
@@ -79,83 +79,142 @@ gws-app-scripts.md
|
||||
|
||||
## OAuth Apps Phishing
|
||||
|
||||
Qualsiasi delle tecniche precedenti potrebbe essere utilizzata per far accedere l'utente a un **Google OAuth application** che **richiederà** all'utente alcuni **accessi**. Se l'utente **si fida** della **fonte**, potrebbe **fidarsi** dell'**applicazione** (anche se sta chiedendo permessi ad alta privilegio).
|
||||
Qualsiasi delle tecniche precedenti potrebbe essere usata per far sì che l'utente acceda a una **Google OAuth application** che **richiederà** all'utente alcuni **accessi**. Se l'utente **si fida** della **sorgente**, potrebbe **fidarsi** dell'**application** (anche se sta chiedendo permessi con elevati privilegi).
|
||||
|
||||
> [!NOTE]
|
||||
> Nota che Google presenta un brutto avviso che avvisa che l'applicazione non è affidabile in diversi casi e gli amministratori di Workspace possono persino impedire alle persone di accettare le applicazioni OAuth.
|
||||
> Nota che Google mostra un prompt poco chiaro che avverte che l'applicazione non è attendibile in diversi casi e gli amministratori di Workspace possono anche impedire agli utenti di accettare applicazioni OAuth.
|
||||
|
||||
**Google** consente di creare applicazioni che possono **interagire per conto degli utenti** con diversi **servizi Google**: Gmail, Drive, GCP...
|
||||
**Google** permette di creare applicazioni che possono **agire per conto degli utenti** su diversi **servizi Google**: Gmail, Drive, GCP...
|
||||
|
||||
Quando si crea un'applicazione per **agire per conto di altri utenti**, lo sviluppatore deve creare un **OAuth app all'interno di GCP** e indicare gli ambiti (permessi) di cui l'app ha bisogno per accedere ai dati degli utenti.\
|
||||
Quando un **utente** desidera **utilizzare** quell'**applicazione**, verrà **richiesto** di **accettare** che l'applicazione avrà accesso ai propri dati specificati negli ambiti.
|
||||
Quando si crea un'applicazione per **agire per conto di altri utenti**, lo sviluppatore deve creare un **OAuth app inside GCP** e indicare gli scope (permessi) di cui l'app ha bisogno per accedere ai dati degli utenti.\
|
||||
Quando un **utente** vuole **usare** quell'**applicazione**, gli verrà **chiesto** di **accettare** che l'app abbia accesso ai dati specificati negli scope.
|
||||
|
||||
Questo è un modo molto allettante per **phishare** utenti non tecnici nell'utilizzo di **applicazioni che accedono a informazioni sensibili** perché potrebbero non comprendere le conseguenze. Tuttavia, negli account delle organizzazioni, ci sono modi per prevenire che ciò accada.
|
||||
Questo è un modo molto ghiotto per **phishare** utenti non tecnici inducendoli a usare **application che accedono a informazioni sensibili**, perché potrebbero non comprendere le conseguenze. Tuttavia, negli account organizzativi ci sono modi per prevenire che ciò accada.
|
||||
|
||||
### Avviso di App non verificate
|
||||
### Unverified App prompt
|
||||
|
||||
Come è stato menzionato, Google presenterà sempre un **avviso all'utente per accettare** i permessi che stanno dando all'applicazione per conto loro. Tuttavia, se l'applicazione è considerata **pericolosa**, Google mostrerà **prima** un **avviso** che indica che è **pericolosa** e **rende più difficile** per l'utente concedere i permessi all'app.
|
||||
Come già accennato, Google presenterà sempre un **prompt all'utente per accettare** i permessi che sta concedendo all'applicazione per suo conto. Tuttavia, se l'app viene considerata **pericolosa**, Google mostrerà **prima** un **prompt** che indica che è **pericolosa** e rende **più difficile** per l'utente concedere i permessi all'app.
|
||||
|
||||
Questo avviso appare nelle app che:
|
||||
Questo prompt appare in app che:
|
||||
|
||||
- Usano qualsiasi ambito che può accedere a dati privati (Gmail, Drive, GCP, BigQuery...)
|
||||
- App con meno di 100 utenti (per app > 100 è necessario anche un processo di revisione per smettere di mostrare l'avviso di non verifica)
|
||||
- Usano qualsiasi scope che possa accedere a dati privati (Gmail, Drive, GCP, BigQuery...)
|
||||
- App con meno di 100 utenti (per app > 100 è richiesto anche un processo di review per smettere di mostrare l'unverified prompt)
|
||||
|
||||
### Ambiti Interessanti
|
||||
### Interesting Scopes
|
||||
|
||||
[**Qui**](https://developers.google.com/identity/protocols/oauth2/scopes) puoi trovare un elenco di tutti gli ambiti OAuth di Google.
|
||||
[**Here**](https://developers.google.com/identity/protocols/oauth2/scopes) you can find a list of all the Google OAuth scopes.
|
||||
|
||||
- **cloud-platform**: Visualizza e gestisci i tuoi dati attraverso i servizi di **Google Cloud Platform**. Puoi impersonare l'utente in GCP.
|
||||
- **admin.directory.user.readonly**: Vedi e scarica la directory GSuite della tua organizzazione. Ottieni nomi, telefoni, URL del calendario di tutti gli utenti.
|
||||
- **cloud-platform**: View and manage your data across **Google Cloud Platform** services. You can impersonate the user in GCP.
|
||||
- **admin.directory.user.readonly**: See and download your organization's GSuite directory. Get names, phones, calendar URLs of all the users.
|
||||
|
||||
### Crea un OAuth App
|
||||
### Create an OAuth App
|
||||
|
||||
**Inizia a creare un OAuth Client ID**
|
||||
**Start creating an OAuth Client ID**
|
||||
|
||||
1. Vai a [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) e clicca su configura la schermata di consenso.
|
||||
2. Poi, ti verrà chiesto se il **tipo di utente** è **interno** (solo per le persone nella tua organizzazione) o **esterno**. Seleziona quello che si adatta alle tue esigenze
|
||||
- Interno potrebbe essere interessante se hai già compromesso un utente dell'organizzazione e stai creando questa App per phishingare un altro.
|
||||
3. Dai un **nome** all'app, un **email di supporto** (nota che puoi impostare un'email di googlegroup per cercare di anonimizzarti un po' di più), un **logo**, **domini autorizzati** e un'altra **email** per **aggiornamenti**.
|
||||
4. **Seleziona** gli **ambiti OAuth**.
|
||||
- Questa pagina è divisa in permessi non sensibili, permessi sensibili e permessi ristretti. Ogni volta che aggiungi un nuovo permesso, viene aggiunto alla sua categoria. A seconda dei permessi richiesti, appariranno diversi avvisi all'utente indicando quanto siano sensibili questi permessi.
|
||||
1. Go to [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) and click on configure the consent screen.
|
||||
2. Then, you will be asked if the **user type** is **internal** (only for people in your org) or **external**. Select the one that suits your needs
|
||||
- **Internal** potrebbe essere interessante se hai già compromesso un utente dell'organizzazione e stai creando questa App per phishare un altro.
|
||||
3. Give a **name** to the app, a **support email** (nota che puoi impostare un indirizzo googlegroup per cercare di anonimizzarti un po' di più), un **logo**, **authorized domains** e un altro **email** per **updates**.
|
||||
4. **Select** the **OAuth scopes**.
|
||||
- Questa pagina è divisa in permessi non sensibili, permessi sensibili e permessi restricted. Ogni volta che aggiungi un nuovo permission viene inserito nella sua categoria. A seconda dei permessi richiesti appariranno prompt diversi all'utente che indicano quanto sono sensibili questi permessi.
|
||||
- Sia **`admin.directory.user.readonly`** che **`cloud-platform`** sono permessi sensibili.
|
||||
5. **Aggiungi gli utenti di test.** Finché lo stato dell'app è in fase di test, solo questi utenti potranno accedere all'app, quindi assicurati di **aggiungere l'email che stai per phishingare**.
|
||||
5. **Add the test users.** Finché lo stato dell'app è testing, solo questi utenti potranno accedere all'app, quindi assicurati di **aggiungere l'email che intendi phishare**.
|
||||
|
||||
Ora otteniamo **credenziali per un'applicazione web** utilizzando il **precedentemente creato OAuth Client ID**:
|
||||
Ora otteniamo le **credentials for a web application** usando il **precedentemente creato OAuth Client ID**:
|
||||
|
||||
1. Torna a [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), questa volta apparirà un'opzione diversa.
|
||||
2. Seleziona di **creare credenziali per un'applicazione web**
|
||||
3. Imposta i necessari **origini Javascript** e **URI di reindirizzamento**
|
||||
- Puoi impostare in entrambi qualcosa come **`http://localhost:8000/callback`** per testare
|
||||
4. Ottieni le **credenziali** della tua applicazione
|
||||
2. Seleziona di **create credentials for a Web application**
|
||||
3. Imposta i necessari **Javascript origins** e **redirect URIs**
|
||||
- Per i test puoi impostare in entrambi qualcosa come **`http://localhost:8000/callback`**
|
||||
4. Ottieni le **credentials** della tua applicazione
|
||||
|
||||
Infine, eseguiamo **un'applicazione web che utilizzerà le credenziali dell'applicazione OAuth**. Puoi trovare un esempio in [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
|
||||
Infine, esegui una web application che utilizzi le credenziali dell'OAuth application. Puoi trovare un esempio in [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
|
||||
```bash
|
||||
git clone ttps://github.com/carlospolop/gcp_oauth_phishing_example
|
||||
cd gcp_oauth_phishing_example
|
||||
pip install flask requests google-auth-oauthlib
|
||||
python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"
|
||||
```
|
||||
Vai su **`http://localhost:8000`**, clicca sul pulsante Accedi con Google, ti verrà **richiesto** un messaggio come questo:
|
||||
Vai su **`http://localhost:8000`**, clicca sul pulsante Login with Google, ti verrà **mostrato** un messaggio come questo:
|
||||
|
||||
<figure><img src="../../../images/image (333).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
L'applicazione mostrerà il **token di accesso e il token di aggiornamento** che possono essere facilmente utilizzati. Per ulteriori informazioni su **come utilizzare questi token controlla**:
|
||||
L'applicazione mostrerà gli **access and refresh token** che possono essere facilmente utilizzati. Per maggiori informazioni su **how to use these tokens check**:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
#### Utilizzando `glcoud`
|
||||
#### Using `glcoud`
|
||||
|
||||
È possibile fare qualcosa utilizzando gcloud invece della console web, controlla:
|
||||
È possibile fare alcune operazioni usando gcloud invece della console web, consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
#### OAuth app protections
|
||||
|
||||
Per impostazione predefinita è configurato che qualsiasi utente all'interno di un'organizzazione Workspace **can accecpt any OAuth app with any permissions**, ma è possibile limitarle solo alle app che richiedono le informazioni di base necessarie per Sign in with Google o non consentire alcuna third-party app.
|
||||
|
||||
Inoltre, anche non permettendo la fiducia verso external third-party apps, è possibile consentire di **trust any internal apps** (app create all'interno dell'organizzazione). Questa trust è configurata di **default**.
|
||||
|
||||
<figure><img src="../../../images/workspace_oauth.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### OAuth Consent Grant Abuse: Detection & Response (Admin Reports)
|
||||
|
||||
Quando un utente autorizza un OAuth app, Google Workspace lo registra in **Admin Reports OAuth Token Audit Activity** (application name `token`) con `events.name` impostato su `authorize`. Questi eventi sono la migliore telemetria per rilevare consent phishing e tracciare il client ID e gli scopes che sono stati concessi.
|
||||
|
||||
Campi chiave da estrarre dall'evento di audit:
|
||||
|
||||
- `id.time`, `id.customerId`
|
||||
- `actor.email`, `actor.profileId`
|
||||
- `ipAddress`, `networkInfo.regionCode`, `networkInfo.subdivisionCode`
|
||||
- `events[0]['parameters']` valori per `client_id`, `app_name`, `scope`, `scope_data`
|
||||
|
||||
**Baseline first (reduce noise):** costruisci un inventario dei client IDs e degli scopes esistenti, poi genera alert su consents nuovi/raramente usati.
|
||||
```bash
|
||||
gam all users print tokens todrive
|
||||
```
|
||||
**Idee per il rilevamento (new/rare app + risky scopes):**
|
||||
|
||||
- Avvisa se un `client_id` è **non in una allowlist approvata** e **non è stato visto negli ultimi X giorni** (es., 90).
|
||||
- Avvisa se il `scope` concesso include scope **ad alto rischio o rari**, specialmente quelli che permettono accesso massivo ai dati o impatto sulla supply-chain, come:
|
||||
- `https://mail.google.com/`
|
||||
- `https://www.googleapis.com/auth/gmail.readonly`
|
||||
- `https://www.googleapis.com/auth/drive`
|
||||
- `https://www.googleapis.com/auth/drive.readonly`
|
||||
- `https://www.googleapis.com/auth/chat.messages`
|
||||
- `https://www.googleapis.com/auth/chromewebstore`
|
||||
```text
|
||||
client_id NOT IN approved_client_ids
|
||||
AND client_id NOT IN last_seen_90d
|
||||
AND scope CONTAINS any(high_risk_scopes OR rare_scopes)
|
||||
```
|
||||
**Risposta / contenimento:**
|
||||
|
||||
- Revoca i token per l'OAuth client ID malevolo:
|
||||
```bash
|
||||
gam all users delete tokens clientId <client_id>
|
||||
```
|
||||
- Bloccare l'OAuth client ID nella Admin Console revocando l'accesso dell'applicazione ai dati Google.
|
||||
|
||||
**Pivot di threat hunting:**
|
||||
|
||||
- Elenca le app esterne a cui hanno acconsentito meno di N utenti (adozione rara).
|
||||
- Esamina il nome dell'app, il publisher, i permessi/scopes e l'ID univoco dell'applicazione.
|
||||
- Cerca app inattive che improvvisamente utilizzano permessi rischiosi (possibili azioni successive come internal phishing o data theft).
|
||||
|
||||
**Mitigazioni:**
|
||||
|
||||
- Limitare l'accesso di tutte le app di terze parti (consentite solo se approvate dall'amministratore).
|
||||
- Consentire accesso limitato in modo che gli utenti possano acconsentire solo alle informazioni di base del profilo "Sign in with Google".
|
||||
|
||||
## Riferimenti
|
||||
|
||||
- [https://www.youtube-nocookie.com/embed/6AsVUS79gLw](https://www.youtube-nocookie.com/embed/6AsVUS79gLw) - Matthew Bryant - Hacking G Suite: The Power of Dark Apps Script Magic
|
||||
- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch e Beau Bullock - OK Google, come faccio a Red Team GSuite?
|
||||
- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch and Beau Bullock - OK Google, How do I Red Team GSuite?
|
||||
- [https://redcanary.com/blog/threat-detection/google-workspace-oauth-attack/](https://redcanary.com/blog/threat-detection/google-workspace-oauth-attack/)
|
||||
- [https://github.com/GAM-team/GAM](https://github.com/GAM-team/GAM)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user