OAuth to Account takeover
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Basic Information
OAuth offre varie versioni, con informazioni fondamentali accessibili nella documentazione OAuth 2.0. Questa discussione si concentra principalmente sul tipo di concessione del codice di autorizzazione OAuth 2.0, fornendo un framework di autorizzazione che consente a un'applicazione di accedere o eseguire azioni su un account utente in un'altra applicazione (il server di autorizzazione).
Considera un sito web ipotetico https://example.com, progettato per mostrare tutti i tuoi post sui social media, inclusi quelli privati. Per raggiungere questo obiettivo, viene impiegato OAuth 2.0. https://example.com richiederà il tuo permesso per accedere ai tuoi post sui social media. Di conseguenza, apparirà una schermata di consenso su https://socialmedia.com, delineando le autorizzazioni richieste e lo sviluppatore che effettua la richiesta. Una volta autorizzato, https://example.com ottiene la possibilità di accedere ai tuoi post per tuo conto.
È essenziale comprendere i seguenti componenti all'interno del framework OAuth 2.0:
resource owner: Tu, come utente/entità, autorizzi l'accesso alla tua risorsa, come i post del tuo account sui social media.
resource server: Il server che gestisce le richieste autenticate dopo che l'applicazione ha ottenuto un
access token
per conto delresource owner
, ad esempio, https://socialmedia.com.client application: L'applicazione che richiede autorizzazione dal
resource owner
, come https://example.com.authorization server: Il server che emette
access tokens
all'client application
dopo l'autenticazione riuscita delresource owner
e l'ottenimento dell'autorizzazione, ad esempio, https://socialmedia.com.client_id: Un identificatore pubblico e unico per l'applicazione.
client_secret: Una chiave riservata, conosciuta solo dall'applicazione e dal server di autorizzazione, utilizzata per generare
access_tokens
.response_type: Un valore che specifica il tipo di token richiesto, come
code
.scope: Il livello di accesso che l'
client application
sta richiedendo dalresource owner
.redirect_uri: L'URL a cui l'utente viene reindirizzato dopo l'autorizzazione. Questo deve generalmente allinearsi con l'URL di reindirizzamento pre-registrato.
state: Un parametro per mantenere i dati durante il reindirizzamento dell'utente verso e dal server di autorizzazione. La sua unicità è fondamentale per fungere da meccanismo di protezione CSRF.
grant_type: Un parametro che indica il tipo di concessione e il tipo di token da restituire.
code: Il codice di autorizzazione dal
authorization server
, utilizzato insieme aclient_id
eclient_secret
dall'client application
per acquisire unaccess_token
.access_token: Il token che l'
client application
utilizza per le richieste API per conto delresource owner
.refresh_token: Consente all'applicazione di ottenere un nuovo
access_token
senza richiedere nuovamente all'utente.
Flow
Il flusso OAuth effettivo procede come segue:
Naviga su https://example.com e seleziona il pulsante “Integra con i social media”.
Il sito invia quindi una richiesta a https://socialmedia.com chiedendo la tua autorizzazione per consentire all'applicazione di https://example.com di accedere ai tuoi post. La richiesta è strutturata come:
Ti viene quindi presentata una pagina di consenso.
Dopo la tua approvazione, i Social Media inviano una risposta al
redirect_uri
con i parametricode
estate
:
https://example.com utilizza questo
code
, insieme al suoclient_id
eclient_secret
, per effettuare una richiesta lato server per ottenere unaccess_token
per tuo conto, abilitando l'accesso alle autorizzazioni a cui hai acconsentito:
Infine, il processo si conclude quando https://example.com utilizza il tuo
access_token
per effettuare una chiamata API a Social Media per accedere
Vulnerabilità
Open redirect_uri
Il redirect_uri
è cruciale per la sicurezza nelle implementazioni di OAuth e OpenID, poiché indica dove vengono inviati i dati sensibili, come i codici di autorizzazione, dopo l'autorizzazione. Se configurato in modo errato, potrebbe consentire agli attaccanti di reindirizzare queste richieste a server malevoli, abilitando il takeover dell'account.
Le tecniche di sfruttamento variano in base alla logica di convalida del server di autorizzazione. Possono variare da un abbinamento di percorso rigoroso all'accettazione di qualsiasi URL all'interno del dominio o sottodirectory specificati. I metodi di sfruttamento comuni includono reindirizzamenti aperti, traversata di percorso, sfruttamento di regex deboli e iniezione HTML per il furto di token.
Oltre a redirect_uri
, altri parametri di OAuth e OpenID come client_uri
, policy_uri
, tos_uri
e initiate_login_uri
sono anch'essi suscettibili ad attacchi di reindirizzamento. Questi parametri sono facoltativi e il loro supporto varia tra i server.
Per coloro che mirano a un server OpenID, l'endpoint di discovery (**.well-known/openid-configuration**
) elenca spesso dettagli di configurazione preziosi come registration_endpoint
, request_uri_parameter_supported
e "require_request_uri_registration
. Questi dettagli possono aiutare a identificare l'endpoint di registrazione e altre specifiche di configurazione del server.
XSS nell'implementazione del reindirizzamento
Come menzionato in questo rapporto di bug bounty https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, potrebbe essere possibile che il URL di reindirizzamento venga riflesso nella risposta del server dopo che l'utente si autentica, risultando vulnerabile a XSS. Payload possibile da testare:
CSRF - Gestione impropria del parametro di stato
Nelle implementazioni di OAuth, l'uso improprio o l'omissione del state
parameter può aumentare significativamente il rischio di attacchi di Cross-Site Request Forgery (CSRF). Questa vulnerabilità si verifica quando il parametro state
è non utilizzato, utilizzato come valore statico o non validato correttamente, consentendo agli attaccanti di eludere le protezioni CSRF.
Gli attaccanti possono sfruttare questo intercettando il processo di autorizzazione per collegare il proprio account a quello di una vittima, portando a potenziali account takeovers. Questo è particolarmente critico nelle applicazioni in cui OAuth è utilizzato per scopi di autenticazione.
Esempi reali di questa vulnerabilità sono stati documentati in varie CTF challenges e hacking platforms, evidenziando le sue implicazioni pratiche. Il problema si estende anche alle integrazioni con servizi di terze parti come Slack, Stripe e PayPal, dove gli attaccanti possono reindirizzare notifiche o pagamenti ai propri account.
Una corretta gestione e validazione del state
parameter sono cruciali per proteggere contro CSRF e garantire la sicurezza del flusso OAuth.
Pre Account Takeover
Senza verifica dell'email nella creazione dell'account: Gli attaccanti possono creare preventivamente un account utilizzando l'email della vittima. Se la vittima successivamente utilizza un servizio di terze parti per il login, l'applicazione potrebbe involontariamente collegare questo account di terze parti all'account pre-creato dell'attaccante, portando a un accesso non autorizzato.
Sfruttare la verifica dell'email OAuth poco rigorosa: Gli attaccanti possono sfruttare i servizi OAuth che non verificano le email registrandosi con il loro servizio e poi cambiando l'email dell'account in quella della vittima. Questo metodo comporta un rischio simile di accesso non autorizzato all'account, simile al primo scenario ma attraverso un vettore d'attacco diverso.
Divulgazione di segreti
Identificare e proteggere i parametri segreti di OAuth è cruciale. Mentre il client_id
può essere divulgato in sicurezza, rivelare il client_secret
comporta rischi significativi. Se il client_secret
viene compromesso, gli attaccanti possono sfruttare l'identità e la fiducia dell'applicazione per rubare i access_tokens
degli utenti e informazioni private.
Una vulnerabilità comune si verifica quando le applicazioni gestiscono erroneamente lo scambio del code
di autorizzazione per un access_token
sul lato client anziché sul lato server. Questo errore porta all'esposizione del client_secret
, consentendo agli attaccanti di generare access_tokens
sotto le spoglie dell'applicazione. Inoltre, attraverso l'ingegneria sociale, gli attaccanti potrebbero aumentare i privilegi aggiungendo ulteriori scope all'autorizzazione OAuth, sfruttando ulteriormente lo stato di fiducia dell'applicazione.
Bruteforce del Client Secret
Puoi provare a bruteforce il client_secret di un fornitore di servizi con il provider di identità per cercare di rubare account. La richiesta per BF potrebbe apparire simile a:
Referer Header leaking Code + State
Una volta che il client ha il code e state, se è riflesso all'interno dell'header Referer quando naviga su un'altra pagina, allora è vulnerabile.
Access Token Stored in Browser History
Vai alla cronologia del browser e controlla se l'access token è salvato lì.
Everlasting Authorization Code
Il authorization code dovrebbe vivere solo per un certo periodo per limitare la finestra temporale in cui un attaccante può rubarlo e usarlo.
Authorization/Refresh Token not bound to client
Se riesci a ottenere il authorization code e usarlo con un client diverso, allora puoi prendere il controllo di altri account.
Happy Paths, XSS, Iframes & Post Messages to leak code & state values
AWS Cognito
In questo rapporto di bug bounty: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ puoi vedere che il token che AWS Cognito restituisce all'utente potrebbe avere sufficienti permessi per sovrascrivere i dati dell'utente. Pertanto, se puoi cambiare l'email dell'utente con un'altra email, potresti essere in grado di prendere il controllo di altri account.
Per ulteriori informazioni dettagliate su come abusare di AWS Cognito, controlla:
Abusare di altri token delle app
Come menzionato in questo articolo, i flussi OAuth che si aspettano di ricevere il token (e non un codice) potrebbero essere vulnerabili se non controllano che il token appartenga all'app.
Questo perché un attaccante potrebbe creare un applicazione che supporta OAuth e accedere con Facebook (ad esempio) nella propria applicazione. Poi, una volta che una vittima accede con Facebook nell'applicazione dell'attaccante, l'attaccante potrebbe ottenere il token OAuth dell'utente dato alla sua applicazione e usarlo per accedere all'applicazione OAuth della vittima utilizzando il token utente della vittima.
Pertanto, se l'attaccante riesce a far accedere l'utente alla propria applicazione OAuth, sarà in grado di prendere il controllo dell'account della vittima in applicazioni che si aspettano un token e non controllano se il token è stato concesso al loro ID app.
Due link & cookie
Secondo questo articolo, era possibile far aprire a una vittima una pagina con un returnUrl che punta all'host dell'attaccante. Queste informazioni sarebbero state memorizzate in un cookie (RU) e in un passaggio successivo il prompt chiederà all'utente se desidera concedere accesso a quell'host dell'attaccante.
Per bypassare questo prompt, era possibile aprire una scheda per avviare il flusso Oauth che imposterebbe questo cookie RU utilizzando il returnUrl, chiudere la scheda prima che venga mostrato il prompt e aprire una nuova scheda senza quel valore. Quindi, il prompt non informerà riguardo all'host dell'attaccante, ma il cookie sarebbe impostato su di esso, quindi il token sarà inviato all'host dell'attaccante nella redirezione.
Bypass dell'interazione del prompt
Come spiegato in questo video, alcune implementazioni OAuth consentono di indicare il parametro GET prompt
come None (&prompt=none
) per prevenire che gli utenti vengano chiesti di confermare l'accesso concesso in un prompt nel web se sono già loggati sulla piattaforma.
response_mode
Come spiegato in questo video, potrebbe essere possibile indicare il parametro response_mode
per indicare dove si desidera che il codice venga fornito nell'URL finale:
response_mode=query
-> Il codice è fornito all'interno di un parametro GET:?code=2397rf3gu93f
response_mode=fragment
-> Il codice è fornito all'interno del parametro frammento dell'URL#code=2397rf3gu93f
response_mode=form_post
-> Il codice è fornito all'interno di un modulo POST con un input chiamatocode
e il valoreresponse_mode=web_message
-> Il codice è inviato in un messaggio post:window.opener.postMessage({"code": "asdasdasd...
Parametri SSRFs
Controlla questa ricerca Per ulteriori dettagli su questa tecnica.
La registrazione dinamica dei client in OAuth funge da vettore meno ovvio ma critico per le vulnerabilità di sicurezza, specificamente per gli attacchi di Server-Side Request Forgery (SSRF). Questo endpoint consente ai server OAuth di ricevere dettagli sulle applicazioni client, inclusi URL sensibili che potrebbero essere sfruttati.
Punti chiave:
La registrazione dinamica dei client è spesso mappata su
/register
e accetta dettagli comeclient_name
,client_secret
,redirect_uris
e URL per loghi o JSON Web Key Sets (JWKs) tramite richieste POST.Questa funzionalità aderisce alle specifiche stabilite in RFC7591 e OpenID Connect Registration 1.0, che includono parametri potenzialmente vulnerabili a SSRF.
Il processo di registrazione può involontariamente esporre i server a SSRF in diversi modi:
logo_uri
: Un URL per il logo dell'applicazione client che potrebbe essere recuperato dal server, attivando SSRF o portando a XSS se l'URL è gestito in modo errato.jwks_uri
: Un URL al documento JWK del client, che se creato in modo malevolo, può causare al server di effettuare richieste outbound a un server controllato dall'attaccante.sector_identifier_uri
: Riferisce a un array JSON diredirect_uris
, che il server potrebbe recuperare, creando un'opportunità SSRF.request_uris
: Elenca gli URI di richiesta consentiti per il client, che possono essere sfruttati se il server recupera questi URI all'inizio del processo di autorizzazione.
Strategia di sfruttamento:
SSRF può essere attivato registrando un nuovo client con URL malevoli in parametri come
logo_uri
,jwks_uri
osector_identifier_uri
.Sebbene lo sfruttamento diretto tramite
request_uris
possa essere mitigato da controlli di whitelist, fornire unrequest_uri
pre-registrato e controllato dall'attaccante può facilitare SSRF durante la fase di autorizzazione.
Condizioni di gara dei fornitori OAuth
Se la piattaforma che stai testando è un fornitore OAuth leggi questo per testare possibili condizioni di gara.
Riferimenti
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
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)
Last updated