Az - Tokens & Public Applications
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)
Entra ID è la piattaforma di gestione delle identità e degli accessi (IAM) basata sul cloud di Microsoft, che funge da sistema fondamentale di autenticazione e autorizzazione per servizi come Microsoft 365 e Azure Resource Manager. Azure AD implementa il framework di autorizzazione OAuth 2.0 e il protocollo di autenticazione OpenID Connect (OIDC) per gestire l'accesso alle risorse.
Partecipanti chiave in OAuth 2.0:
Server delle risorse (RS): Protegge le risorse di proprietà del proprietario delle risorse.
Proprietario delle risorse (RO): Tipicamente un utente finale che possiede le risorse protette.
Applicazione client (CA): Un'applicazione che cerca di accedere alle risorse per conto del proprietario delle risorse.
Server di autorizzazione (AS): Emissione di token di accesso alle applicazioni client dopo averle autenticate e autorizzate.
Ambiti e Consenso:
Ambiti: Permessi granulari definiti sul server delle risorse che specificano i livelli di accesso.
Consenso: Il processo mediante il quale un proprietario delle risorse concede a un'applicazione client il permesso di accedere alle risorse con ambiti specifici.
Integrazione con Microsoft 365:
Microsoft 365 utilizza Azure AD per IAM ed è composto da più applicazioni OAuth "di prima parte".
Queste applicazioni sono profondamente integrate e spesso hanno relazioni di servizio interdipendenti.
Per semplificare l'esperienza dell'utente e mantenere la funzionalità, Microsoft concede "consenso implicito" o "pre-consenso" a queste applicazioni di prima parte.
Consenso Implicito: Alcune applicazioni sono automaticamente concesse accesso a specifici ambiti senza approvazione esplicita dell'utente o dell'amministratore.
Questi ambiti pre-consentiti sono tipicamente nascosti sia agli utenti che agli amministratori, rendendoli meno visibili nelle interfacce di gestione standard.
Tipi di Applicazioni Client:
Client Confidenziali:
Possiedono le proprie credenziali (ad es., password o certificati).
Possono autenticarsi in modo sicuro al server di autorizzazione.
Client Pubblici:
Non hanno credenziali uniche.
Non possono autenticarsi in modo sicuro al server di autorizzazione.
Implicazione di Sicurezza: Un attaccante può impersonare un'applicazione client pubblica quando richiede token, poiché non esiste un meccanismo per il server di autorizzazione per verificare la legittimità dell'applicazione.
Ci sono tre tipi di token utilizzati in OIDC:
Token di Accesso: Il client presenta questo token al server delle risorse per accedere alle risorse. Può essere utilizzato solo per una specifica combinazione di utente, client e risorsa e non può essere revocato fino alla scadenza - che è di 1 ora per impostazione predefinita.
Token ID: Il client riceve questo token dal server di autorizzazione. Contiene informazioni di base sull'utente. È legato a una specifica combinazione di utente e client.
Token di Aggiornamento: Forniti al client con il token di accesso. Utilizzati per ottenere nuovi token di accesso e ID. È legato a una specifica combinazione di utente e client e può essere revocato. La scadenza predefinita è 90 giorni per i token di aggiornamento inattivi e nessuna scadenza per i token attivi (da un token di aggiornamento è possibile ottenere nuovi token di aggiornamento).
Un token di aggiornamento dovrebbe essere legato a un aud, a alcuni ambiti, e a un tenant e dovrebbe essere in grado di generare token di accesso solo per quel aud, ambiti (e non di più) e tenant. Tuttavia, questo non è il caso con i token delle applicazioni FOCI.
Un token di aggiornamento è crittografato e solo Microsoft può decrittografarlo.
Ottenere un nuovo token di aggiornamento non revoca il token di aggiornamento precedente.
Le informazioni per il accesso condizionale sono memorizzate all'interno del JWT. Quindi, se richiedi il token da un indirizzo IP consentito, quell'IP sarà memorizzato nel token e poi puoi utilizzare quel token da un IP non consentito per accedere alle risorse.
Il campo indicato nel campo "aud" è il server delle risorse (l'applicazione) utilizzato per eseguire il login.
Il comando az account get-access-token --resource-type [...] supporta i seguenti tipi e ciascuno di essi aggiungerà un "aud" specifico nel token di accesso risultante:
Nota che i seguenti sono solo le API supportate da az account get-access-token ma ce ne sono di più.
L'ambito di un token di accesso è memorizzato all'interno della chiave scp all'interno del JWT del token di accesso. Questi ambiti definiscono a cosa ha accesso il token di accesso.
Se un JWT è autorizzato a contattare un'API specifica ma non ha l'ambito per eseguire l'azione richiesta, non sarà in grado di eseguire l'azione con quel JWT.
In precedenza è stato menzionato che i refresh token dovrebbero essere legati agli scopes con cui sono stati generati, all'applicazione e al tenant a cui sono stati generati. Se uno di questi confini viene violato, è possibile effettuare un'escursione dei privilegi poiché sarà possibile generare access token per altre risorse e tenant a cui l'utente ha accesso e con più scopes di quanto fosse originariamente previsto.
Inoltre, questo è possibile con tutti i refresh token nella Microsoft identity platform (account Microsoft Entra, account Microsoft personali e account social come Facebook e Google) perché come menzionano le docs: "I refresh token sono legati a una combinazione di utente e client, ma non sono legati a una risorsa o tenant. Un client può utilizzare un refresh token per acquisire access token attraverso qualsiasi combinazione di risorsa e tenant per cui ha il permesso di farlo. I refresh token sono crittografati e solo la Microsoft identity platform può leggerli."
Inoltre, nota che le applicazioni FOCI sono applicazioni pubbliche, quindi non è necessario alcun segreto per autenticarsi al server.
Poi i client FOCI noti riportati nella ricerca originale possono essere trovati qui.
Proseguendo con il codice dell'esempio precedente, in questo codice viene richiesto un nuovo token per uno scope diverso:
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
