Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

20 KiB
Raw Blame History

OAuth to Account takeover

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

{% embed url="https://websec.nl/" %}

Informazioni di base

OAuth offre varie versioni, con approfondimenti fondamentali accessibili alla documentazione OAuth 2.0. Questa discussione si concentra principalmente sul OAuth 2.0 authorization code grant type ampiamente utilizzato, fornendo un quadro 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 ottenere questo, 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. Dopo la tua autorizzazione, https://example.com ottiene la capacità 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 del resource owner, ad esempio https://socialmedia.com.
  • client application: L'applicazione che cerca l'autorizzazione dal resource owner, come https://example.com.
  • authorization server: Il server che emette access tokens all'applicazione client dopo l'autenticazione riuscita del resource 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 confidenziale, nota solo all'applicazione e al 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'applicazione client sta richiedendo dal resource owner.
  • redirect_uri: L'URL a cui l'utente viene reindirizzato dopo l'autorizzazione. Questo in genere deve 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 servire come meccanismo di protezione CSRF.
  • grant_type: Un parametro che indica il tipo di grant e il tipo di token da restituire.
  • code: Il codice di autorizzazione dal authorization server, utilizzato insieme a client_id e client_secret dall'applicazione client per acquisire un access_token.
  • access_token: Il token che l'applicazione client utilizza per le richieste API per conto del resource owner.
  • refresh_token: Consente all'applicazione di ottenere un nuovo access_token senza richiedere nuovamente all'utente.

Flusso

Il flusso OAuth effettivo procede come segue:

  1. Navighi su https://example.com e selezioni il pulsante “Integra con Social Media”.
  2. 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:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Ti viene quindi presentata una pagina di consenso.
  2. Dopo la tua approvazione, Social Media invia una risposta al redirect_uri con i parametri code e state:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com utilizza questo code, insieme al suo client_id e client_secret, per effettuare una richiesta lato server al fine di ottenere un access_token per tuo conto, consentendo l'accesso alle autorizzazioni a cui hai acconsentito:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. 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 OAuth e OpenID, poiché indirizza 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, permettendo il takeover dell'account.

Le tecniche di sfruttamento variano in base alla logica di validazione del server di autorizzazione. Possono andare dalla corrispondenza stretta del percorso all'accettazione di qualsiasi URL all'interno del dominio o sottodirectory specificati. I metodi di sfruttamento comuni includono reindirizzamenti aperti, traversal del percorso, sfruttamento di regex deboli e iniezione HTML per il furto di token.

Oltre a redirect_uri, altri parametri OAuth e OpenID come client_uri, policy_uri, tos_uri e initiate_login_uri sono anche suscettibili agli attacchi di reindirizzamento. Questi parametri sono opzionali e il loro supporto varia tra i server.

Per coloro che prendono di mira un server OpenID, l'endpoint di scoperta (**.well-known/openid-configuration**) spesso elenca 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 l'URL di reindirizzamento venga riflesso nella risposta del server dopo l'autenticazione dell'utente, risultando vulnerabile a XSS. Possibile payload da testare:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Improper handling of state parameter

Nelle implementazioni 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 state parameter è non utilizzato, utilizzato come valore statico o non correttamente validato, permettendo agli attaccanti di bypassare le protezioni CSRF.

Gli attaccanti possono sfruttare questo intercettando il processo di autorizzazione per collegare il loro account con quello della 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 vari 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 loro account.

La corretta gestione e validazione del state parameter sono cruciali per proteggersi contro CSRF e garantire la sicurezza del flusso OAuth.

Pre Account Takeover

  1. Senza verifica email alla 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 inavvertitamente collegare questo account di terze parti all'account pre-creato dall'attaccante, portando ad accessi non autorizzati.
  2. Sfruttamento della verifica email lassista di OAuth: Gli attaccanti possono sfruttare i servizi OAuth che non verificano le email registrandosi con il loro servizio e poi cambiando l'email dell'account con quella della vittima. Questo metodo comporta rischi simili di accesso non autorizzato, simile al primo scenario ma attraverso un diverso vettore di attacco.

Disclosure of Secrets

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 è compromesso, gli attaccanti possono sfruttare l'identità e la fiducia dell'applicazione per rubare 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, permettendo 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 status di fiducia dell'applicazione.

Client Secret Bruteforce

Puoi provare a bruteforce il client_secret di un service provider con l'identity provider per cercare di rubare account.
La richiesta per BF potrebbe essere simile a:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header che perde Codice + Stato

Una volta che il client ha il codice e lo stato, se sono riflessi all'interno dell'header Referer quando naviga verso una pagina diversa, allora è vulnerabile.

Access Token Salvato nella Cronologia del Browser

Vai alla cronologia del browser e verifica se l'access token è salvato lì.

Codice di Autorizzazione Permanente

Il codice di autorizzazione dovrebbe vivere solo per un certo periodo per limitare la finestra di tempo in cui un attaccante può rubarlo e usarlo.

Authorization/Refresh Token non legato al client

Se riesci a ottenere il codice di autorizzazione e usarlo con un client diverso, allora puoi prendere il controllo di altri account.

Happy Paths, XSS, Iframes & Post Messages per perdere valori di codice e stato

Controlla questo post

AWS Cognito

In questo report 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 abbastanza permessi per sovrascrivere i dati dell'utente. Pertanto, se riesci a cambiare l'email dell'utente con un'email diversa, potresti essere in grado di prendere il controllo di altri account.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Per ulteriori informazioni dettagliate su come abusare di AWS cognito, consulta:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

Abusare dei token di altre App

Come menzionato in questo writeup, i flussi OAuth che si aspettano di ricevere il token (e non un codice) potrebbero essere vulnerabili se non verificano che il token appartenga all'app.

Questo perché un attaccante potrebbe creare un'applicazione che supporta OAuth e accedere con Facebook (per 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 usando il token dell'utente della vittima.

{% hint style="danger" %} 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 verificano se il token è stato concesso al loro ID app. {% endhint %}

Due link & cookie

Secondo questo writeup, era possibile far aprire a una vittima una pagina con un returnUrl che punta all'host dell'attaccante. Questa informazione sarebbe memorizzata in un cookie (RU) e in un passaggio successivo il prompt chiederà all'utente se vuole dare accesso a quell'host dell'attaccante.

Per bypassare questo prompt, era possibile aprire una scheda per iniziare il flusso OAuth che avrebbe impostato questo cookie RU usando il returnUrl, chiudere la scheda prima che il prompt venga mostrato e aprire una nuova scheda senza quel valore. Quindi, il prompt non informerà sull'host dell'attaccante, ma il cookie sarà 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 permettono di indicare il parametro GET prompt come None (&prompt=none) per evitare che agli utenti venga chiesto di confermare l'accesso dato in un prompt nel web se sono già loggati nella 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 chiamato code e il valore
  • response_mode=web_message -> Il codice è inviato in un messaggio post: window.opener.postMessage({"code": "asdasdasd...

Parametri SSRFs

Consulta questa ricerca per ulteriori dettagli su questa tecnica.

La registrazione dinamica del client in OAuth serve come 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 del client è spesso mappata su /register e accetta dettagli come client_name, client_secret, redirect_uris e URL per loghi o set di chiavi JSON Web (JWKs) tramite richieste POST.
  • Questa funzionalità aderisce alle specifiche delineate in RFC7591 e OpenID Connect Registration 1.0, che includono parametri potenzialmente vulnerabili a SSRF.
  • Il processo di registrazione può esporre involontariamente i server a SSRF in diversi modi:
  • logo_uri: Un URL per il logo dell'applicazione client che potrebbe essere recuperato dal server, innescando 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 in uscita a un server controllato dall'attaccante.
  • sector_identifier_uri: Riferisce a un array JSON di redirect_uris, che il server potrebbe recuperare, creando un'opportunità di 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 innescato registrando un nuovo client con URL malevoli in parametri come logo_uri, jwks_uri o sector_identifier_uri.
  • Mentre lo sfruttamento diretto tramite request_uris può essere mitigato dai controlli della whitelist, fornire un request_uri pre-registrato e controllato dall'attaccante può facilitare SSRF durante la fase di autorizzazione.

Condizioni di gara dei provider OAuth

Se la piattaforma che stai testando è un provider OAuth, leggi questo per testare possibili condizioni di gara.

Riferimenti

{% embed url="https://websec.nl/" %}

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks: