From 155dbc32743c6c16339fe1849dc250bac72c6175 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 29 Mar 2025 22:58:22 +0000 Subject: [PATCH] Translated ['src/generic-methodologies-and-resources/external-recon-meth --- .../github-leaked-secrets.md | 10 ++-- .../oauth-to-account-takeover.md | 46 ++++++++++++++----- .../unicode-injection/README.md | 18 +++++++- 3 files changed, 54 insertions(+), 20 deletions(-) diff --git a/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md b/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md index 4b24ba629..2c95bb984 100644 --- a/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md +++ b/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md @@ -2,16 +2,14 @@ {{#include ../../banners/hacktricks-training.md}} -Ora che abbiamo costruito l'elenco delle risorse del nostro ambito, è tempo di cercare alcuni frutti a bassa difficoltà di OSINT. -### Piattaforme che hanno già cercato leak - -- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/) - -### Leak di chiavi API in github +### Strumenti per trovare segreti nei repository git e nel file system - [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog) - [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks) +- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker) +- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield) +- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository) - [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets) - [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) - [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit) diff --git a/src/pentesting-web/oauth-to-account-takeover.md b/src/pentesting-web/oauth-to-account-takeover.md index 6a058712c..e6f9a51d7 100644 --- a/src/pentesting-web/oauth-to-account-takeover.md +++ b/src/pentesting-web/oauth-to-account-takeover.md @@ -18,7 +18,7 @@ Considera un sito web ipotetico _**https://example.com**_, progettato per **most - **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'`applicazione client` sta richiedendo dal `proprietario della risorsa`. -- **redirect_uri**: L'**URL a cui l'utente viene reindirizzato dopo l'autorizzazione**. Questo deve tipicamente allinearsi con l'URL di reindirizzamento pre-registrato. +- **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 `server di autorizzazione`, utilizzato insieme a `client_id` e `client_secret` dall'applicazione client per acquisire un `access_token`. @@ -50,7 +50,7 @@ POST /oauth/access_token Host: socialmedia.com ...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"} ``` -6. Infine, il processo si conclude quando https://example.com utilizza il tuo `access_token` per effettuare una chiamata API ai Social Media per accedere +6. 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à @@ -72,20 +72,20 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard -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. +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 correttamente convalidato o associato alla sessione dell'utente** durante il login, consentendo agli attaccanti di bypassare 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**. +Gli attaccanti possono sfruttare questo intercettando il processo di autorizzazione per collegare il proprio account a quello della vittima, portando a potenziali **account takeovers** facendo in modo che un utente acceda con un flusso oauth quasi completato appartenente all'attaccante. 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. +Una corretta gestione e convalida del **`state` parameter** sono cruciali per proteggere contro CSRF e garantire la sicurezza del flusso OAuth. ### Pre Account Takeover -1. **Senza verifica dell'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 involontariamente collegare questo account di terze parti all'account pre-creato dall'attaccante, portando a un accesso non autorizzato. -2. **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 di attacco diverso. +1. **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 dall'attaccante, portando ad accessi non autorizzati. +2. **Sfruttamento della 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 +### Rivelazione di segreti Identificare e proteggere i parametri segreti di OAuth è cruciale. Mentre il **`client_id`** può essere divulgato in modo sicuro, 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. @@ -143,7 +143,7 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ ] } ``` -Per ulteriori informazioni dettagliate su come abusare di AWS cognito, controlla: +Per ulteriori informazioni dettagliate su come abusare di AWS cognito controlla: {{#ref}} https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html @@ -166,7 +166,7 @@ Per bypassare questo prompt, era possibile aprire una scheda per avviare il **fl ### Bypass dell'interazione del prompt -Come spiegato in [**questo video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), alcune implementazioni OAuth consentono di indicare il parametro **`prompt`** GET come None (**`&prompt=none`**) per **prevenire che gli utenti vengano chiesti di confermare** l'accesso dato in un prompt nel web se sono già loggati nella piattaforma. +Come spiegato in [**questo video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), alcune implementazioni OAuth consentono di indicare il parametro **`prompt`** GET come None (**`&prompt=none`**) per **prevenire che gli utenti vengano chiesti di confermare** l'accesso concesso in un prompt sul web se sono già loggati sulla piattaforma. ### response_mode @@ -179,7 +179,7 @@ Come [**spiegato in questo video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q) ### Flusso OAuth ROPC - bypass 2 FA -Secondo [**questo post del blog**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), questo è un flusso OAuth che consente di accedere in OAuth tramite **nome utente** e **password**. Se durante questo semplice flusso viene restituito un **token** con accesso a tutte le azioni che l'utente può eseguire, allora è possibile bypassare 2FA utilizzando quel token. +Secondo [**questo post del blog**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), questo è un flusso OAuth che consente di accedere a OAuth tramite **nome utente** e **password**. Se durante questo semplice flusso viene restituito un **token** con accesso a tutte le azioni che l'utente può eseguire, allora è possibile bypassare 2FA utilizzando quel token. ### ATO su pagina web che reindirizza in base a open redirect al referrer @@ -187,7 +187,7 @@ Questo [**post del blog**](https://blog.voorivex.team/oauth-non-happy-path-to-at 1. La vittima accede alla pagina web dell'attaccante 2. La vittima apre il link malevolo e un opener avvia il flusso OAuth di Google con `response_type=id_token,code&prompt=none` come parametri aggiuntivi utilizzando come **referrer il sito web dell'attaccante**. -3. Nell'opener, dopo che il provider autorizza la vittima, la rimanda al valore del parametro `redirect_uri` (web della vittima) con codice 30X che mantiene ancora il sito web dell'attaccante nel referer. +3. Nell'opener, dopo che il provider autorizza la vittima, la rimanda al valore del parametro `redirect_uri` (web della vittima) con codice 30X che mantiene ancora il sito web dell'attaccante nel referrer. 4. Il **sito web della vittima attiva l'open redirect basato sul referrer** reindirizzando l'utente vittima al sito web dell'attaccante, poiché il **`respose_type`** era **`id_token,code`**, il codice sarà inviato all'attaccante nel **frammento** dell'URL permettendogli di prendere il controllo dell'account dell'utente tramite Google nel sito della vittima. ### Parametri SSRFs @@ -215,9 +215,31 @@ La registrazione dinamica dei client in OAuth funge da vettore meno ovvio ma cri Se la piattaforma che stai testando è un fornitore OAuth [**leggi questo per testare possibili condizioni di gara**](race-condition.md). +## Attacco ai reclami mutabili + +In OAuth, il campo sub identifica univocamente un utente, ma il suo formato varia a seconda del server di autorizzazione. Per standardizzare l'identificazione degli utenti, alcuni client utilizzano email o handle utente. Tuttavia, questo è rischioso perché: + +- Alcuni server di autorizzazione non garantiscono che queste proprietà (come l'email) rimangano immutabili. +- In alcune implementazioni—come **"Accedi con Microsoft"**—il client si basa sul campo email, che è **controllato dall'utente in Entra ID** e non verificato. +- Un attaccante può sfruttare questo creando la propria organizzazione Azure AD (ad esempio, doyensectestorg) e utilizzandola per eseguire un accesso Microsoft. +- Anche se l'Object ID (memorizzato in sub) è immutabile e sicuro, la dipendenza da un campo email mutabile può consentire un takeover dell'account (ad esempio, dirottare un account come victim@gmail.com). + +## Attacco di confusione del client + +In un **Attacco di confusione del client**, un'applicazione che utilizza il flusso implicito OAuth non verifica che il token di accesso finale sia specificamente generato per il proprio Client ID. Un attaccante crea un sito web pubblico che utilizza il flusso implicito OAuth di Google, ingannando migliaia di utenti a effettuare il login e raccogliendo così i token di accesso destinati al sito dell'attaccante. Se questi utenti hanno anche account su un altro sito vulnerabile che non convalida il Client ID del token, l'attaccante può riutilizzare i token raccolti per impersonare le vittime e prendere il controllo dei loro account. + +## Attacco di aggiornamento dello scope + +Il tipo **Authorization Code Grant** implica una comunicazione sicura server-to-server per trasmettere i dati degli utenti. Tuttavia, se il **Server di Autorizzazione** si fida implicitamente di un parametro scope nella richiesta del token di accesso (un parametro non definito nell'RFC), un'applicazione malevola potrebbe aggiornare i privilegi di un codice di autorizzazione richiedendo uno scope più elevato. Dopo che il **Token di Accesso** è generato, il **Server delle Risorse** deve verificarlo: per i token JWT, questo comporta il controllo della firma JWT ed estrarre dati come client_id e scope, mentre per i token a stringa casuale, il server deve interrogare il Server di Autorizzazione per recuperare i dettagli del token. + +## Hijacking dello schema di reindirizzamento + +Nelle implementazioni mobile OAuth, le app utilizzano **schemi URI personalizzati** per ricevere reindirizzamenti con codici di autorizzazione. Tuttavia, poiché più app possono registrare lo stesso schema su un dispositivo, l'assunzione che solo il client legittimo controlli l'URI di reindirizzamento viene violata. Su Android, ad esempio, un URI Intent come `com.example.app://` oauth viene catturato in base allo schema e ai filtri opzionali definiti nel filtro dell'intento di un'app. Poiché la risoluzione degli intent di Android può essere ampia—soprattutto se viene specificato solo lo schema—un attaccante può registrare un'app malevola con un filtro di intento accuratamente progettato per dirottare il codice di autorizzazione. Questo può **abilitare un takeover dell'account** sia attraverso l'interazione dell'utente (quando più app sono idonee a gestire l'intento) sia tramite tecniche di bypass che sfruttano filtri eccessivamente specifici, come dettagliato dal diagramma di flusso di valutazione di Ostorlab. + ## Riferimenti - [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) - [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors) +- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/unicode-injection/README.md b/src/pentesting-web/unicode-injection/README.md index 44a93834d..9a587e1a0 100644 --- a/src/pentesting-web/unicode-injection/README.md +++ b/src/pentesting-web/unicode-injection/README.md @@ -29,7 +29,7 @@ Questa vulnerabilità proviene effettivamente da una vulnerabilità trovata da u I back-end si comportano in modo strano quando **ricevono emoji**. Questo è ciò che è successo in [**questo writeup**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) dove il ricercatore è riuscito a ottenere un XSS con un payload come: `💋img src=x onerror=alert(document.domain)//💛` -In questo caso, l'errore è stato che il server, dopo aver rimosso i caratteri dannosi, **ha convertito la stringa UTF-8 da Windows-1252 a UTF-8** (fondamentalmente l'encoding dell'input e la conversione dall'encoding non corrispondevano). Quindi questo non dà un < corretto, solo uno unicode strano: `‹`\ +In questo caso, l'errore è stato che il server, dopo aver rimosso i caratteri dannosi, **ha convertito la stringa UTF-8 da Windows-1252 a UTF-8** (fondamentalmente l'encoding dell'input e la conversione dall'encoding non corrispondevano). Quindi questo non dà un corretto < solo un unicode strano: `‹`\ ``Quindi hanno preso questo output e **convertito di nuovo ora da UTF-8 a ASCII**. Questo **ha normalizzato** il `‹` in `<`, ecco come l'exploit potrebbe funzionare su quel sistema.\ Questo è ciò che è successo: ```php @@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str); echo "String: " . $str; ``` -Liste di emoji: +Emoji lists: - [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv) - [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html) +## Windows Best-Fit/Worst-fit + +Come spiegato in **[questo ottimo post](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, Windows ha una funzione chiamata **Best-Fit** che **sostituisce i caratteri unicode** che non possono essere visualizzati in modalità ASCII con uno simile. Questo può portare a **comportamenti imprevisti** quando il backend **si aspetta un carattere specifico** ma riceve un carattere diverso. + +È possibile trovare caratteri best-fit in **[https://worst.fit/mapping/](https://worst.fit/mapping/)**. + +Poiché Windows di solito converte le stringhe unicode in stringhe ascii come una delle ultime parti dell'esecuzione (solitamente passando da un'API con suffisso "W" a un'API con suffisso "A" come `GetEnvironmentVariableA` e `GetEnvironmentVariableW`), questo permetterebbe agli attaccanti di eludere le protezioni inviando caratteri unicode che verranno convertiti infine in caratteri ASCII che eseguirebbero azioni inaspettate. + +Nel post del blog vengono proposti metodi per eludere vulnerabilità risolte utilizzando una **blacklist di caratteri**, sfruttare **path traversals** usando [caratteri mappati a “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) e [caratteri mappati a “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) o persino eludere le protezioni di escape della shell come `escapeshellarg` di PHP o `subprocess.run` di Python utilizzando un elenco; questo è stato fatto, ad esempio, utilizzando **virgolette doppie a larghezza piena (U+FF02)** invece di virgolette doppie, quindi alla fine ciò che sembrava un argomento è stato trasformato in 2 argomenti. + +**Nota che affinché un'app sia vulnerabile, deve utilizzare le API Windows "W" ma finire per chiamare un'API Windows "A" in modo che venga creato il "Best-fit" della stringa unicode.** + +**Diverse vulnerabilità scoperte non verranno risolte poiché le persone non sono d'accordo su chi dovrebbe risolvere questo problema.** + {{#include ../../banners/hacktricks-training.md}}