Abbiamo hackerato GitHub per un mese: ecco cosa abbiamo trovato

Dopo una lunga pausa, torniamo con un nuovo write-up. Anche se di solito non partecipiamo ai programmi di bug bounty a causa di altri impegni, abbiamo accettato la sfida di hackerare GitHub per un mese e siamo entusiasti di condividere i nostri risultati. Tutto è iniziato quando Shivam Singh (Mr. Rajput Hacker) mi ha contattato a novembre e mi ha incoraggiato a provare il bug bounty. Abbiamo deciso di concentrarci su npmjs.com, una controllata di GitHub. Nonostante GitHub sia una grande azienda e il programma di bug bounty fosse pubblico su HackerOne, abbiamo ritenuto che valesse la pena tentare.

Concentrarsi sulla logica di business

Mr. Rajput Hacker e io abbiamo deciso di concentrarci esclusivamente sui bug della logica di business dell’applicazione. Prima di iniziare la ricerca, ci siamo assicurati di comprendere l’applicazione nella sua interezza. Questo ha comportato un uso minimo di Burp Suite e l’attenzione rivolta alla comprensione delle funzionalità e dei processi fondamentali dell’applicazione. Il nostro obiettivo era individuare eventuali debolezze nella logica di business potenzialmente sfruttabili. Limitando il nostro set di strumenti e concentrandoci sulla comprensione dell’applicazione, puntavamo a scoprire vulnerabilità uniche o trascurate. Poiché npmjs.com era un’applicazione relativamente piccola, la nostra comprensione e i nostri appunti ci hanno richiesto meno di due ore.

Vulnerabilità scoperte

N.	Titolo del report H1	Obiettivo	Data di segnalazione (GG/MM/AA)	Gravità	Ricompensa
1	Rivendicare il nome utente di un account eliminato prima di 90 giorni può causare diversi problemi	https://github.com/	11/12/22	Informativa	NA
2	Le sessioni dell’account restano attive e collegate al vecchio nome utente dopo aver cambiato nome utente	https://education.github.com/	11/12/22	Bassa	$2000
3	Ingannare i membri di un’organizzazione vittima tramite una vulnerabilità di confusione di nomi nella funzione di invito membri dell’organizzazione	https://npmjs.com/	07/12/22	Media	Duplicato
4	La vittima può rivendicare il nome utente di un account eliminato – porta all’acquisizione dell’account controllando la sessione dell’account eliminato	https://npmjs.com/	02/12/22	Media	$4000
5	Eliminare l’account di chiunque su NPMJS sfruttando una configurazione errata del sistema di supporto	https://npmjs/com/	11/12/22	Bassa	Duplicato ($200)
6	Elusione della verifica di accesso su NPMJS.com	https://npmjs.com/	16/11/22	Media	$4000
	Ricompensa totale				$10000

Vulnerabilità segnalate al GitHub Security Program

Anche se abbiamo detto che in totale  sono state segnalate 9 vulnerabilità, oggi qui ne trattiamo 3, indicate di seguito:

1. Elusione della verifica di accesso su npmjs.com
2. Pre-Account Takeover su npmjs.com
3. Problema di controllo degli accessi su education.github.com

Elusione della verifica di accesso su NPMJS

Descrizione  –

Esaminando la parte di autenticazione di npmjs.com e le funzionalità comuni come l’aggiornamento dell’indirizzo e-mail e del profilo, abbiamo notato uno strano comportamento dell’applicazione che ha attirato la nostra attenzione: il formato del link di verifica dell’e-mail, del link di reimpostazione della password & del link inviato per aggiornare l’indirizzo e-mail . 

Il link aveva per tutte le funzionalità il formato https://npmjs.com/verify/{some_random_token_here} – che si trattasse della reimpostazione della password, del link di verifica dell’e-mail o di qualsiasi altro link del sito . Abbiamo poi osservato che, ogni volta che accedi all’applicazione, questa invia un codice di verifica all’indirizzo e-mail registrato, da inserire nell’ambito della verifica di accesso (una sorta di codice 2FA/MFA via e-mail) per accedere correttamente all’account .  Abbiamo quindi tentato di eludere questa funzionalità e ci siamo riusciti – avendo esaminato a fondo l’applicazione nelle ultime 2 ore, conoscevamo ogni funzionalità, abbiamo potuto collegarle e trovare l’elusione; leggi i passaggi per riprodurla qui sotto per vedere come abbiamo fatto .

Durante il nostro esame del processo di autenticazione e delle funzionalità comuni di npmjs.com, come l’aggiornamento degli indirizzi e-mail e dei profili, abbiamo scoperto un comportamento particolare nel formato dei link di verifica dell’e-mail, dei link di reimpostazione della password e dei link inviati per aggiornare gli indirizzi e-mail. Questi link avevano il formato https://npmjs.com/verify/{random_token} ed erano usati per tutte le funzionalità, tra cui la reimpostazione della password, la verifica dell’e-mail e altre.

Abbiamo inoltre notato che, ogni volta che un utente accedeva all’applicazione, veniva inviato un codice di verifica all’indirizzo e-mail registrato. Questo codice di verifica era necessario per completare il processo di accesso, fungendo da forma di autenticazione a due fattori. La seconda cosa che abbiamo notato: aggiornando un indirizzo e-mail su npmjs, la modifica avveniva senza richiedere la conferma della password. Un’e-mail veniva inviata sia al vecchio sia al nuovo indirizzo. L’e-mail inviata al vecchio indirizzo informava il destinatario che, se la modifica non era stata fatta da lui, poteva fare clic su un link (https://npmjs.com/verify/{some_random_token_here}) per annullare la modifica e ripristinare il suo vecchio indirizzo come quello attuale. L’e-mail inviata al nuovo indirizzo conteneva un link per verificare la nuova e-mail e collegarla all’account appena aggiornato.

Ci siamo imbattuti in un problema sorprendente mentre cercavamo di accedere a un account dopo aver aggiornato l’indirizzo e-mail nella pagina del profilo. Pur non avendo confermato né cliccato alcun link né nella vecchia né nella nuova e-mail, il sistema mostrava un messaggio che indicava che era stato inviato un codice di verifica al nuovo indirizzo non verificato. Questo sembrava suggerire che non saremmo riusciti ad accedere.  Tuttavia, osservando più da vicino, abbiamo scoperto un’e-mail inviata al nostro vecchio indirizzo, che ci chiedeva di annullare la modifica per evitare il blocco dell’account. Cliccando sul link fornito (https://npmjs.com/verify/{random_token}) per annullare la modifica dell’e-mail, siamo stati reindirizzati alla pagina di accesso. Con nostra sorpresa, quando abbiamo inserito le credenziali, il sistema non ha chiesto il codice di verifica e ci ha invece permesso di accedere e annullare la modifica dell’e-mail.

Tuttavia, dopo un’indagine più approfondita, siamo riusciti a eludere con successo questa funzionalità. La nostra profonda conoscenza dell’applicazione, acquisita trascorrendo due ore a familiarizzare con le sue funzioni, ci ha permesso di collegare diverse funzionalità e trovare l’elusione. I passaggi per riprodurre l’elusione sono riportati qui sotto.

Passaggi per riprodurre –

1. Registrazione con [email protected] (nome utente attacker1)
2. Accedere ad attacker1 con login e password (poiché il login di npmjs funziona solo con nome utente e password)
3. Andare su Account > Update Email > [email protected]
4. Controlla la casella di posta di [email protected], vedrai un’e-mail da npmjs.com

5.Apri il link https://www.npmjs.com/verify/{some_random_token_here} Reindirizzerà all’accesso > Prova ad accedere con il nome utente & la password della vittima
6.Verrai reindirizzato alla pagina 404 & avrai effettuato l’accesso all’account senza codice di verifica! (Anche se la pagina ti mostrerà un messaggio che ti dice che non hai effettuato l’accesso con l’utente giusto)

POC –

https://youtube.com/watch?v=ox6np-b3nyI%3Ffeature%3Doembed

Impatto –

Un attaccante può sfruttare una vulnerabilità di npmjs per eludere il processo di verifica di accesso, pensato per proteggere dagli attacchi di raccolta e fuga di credenziali. In pratica, ciò consente all’attaccante di ottenere un accesso non autorizzato all’account senza superare i controlli di sicurezza previsti. Questa vulnerabilità è essenzialmente un’elusione del processo di verifica di accesso, che funge da misura temporanea fino all’attivazione dell’autenticazione a due fattori.

La nostra conclusione –

In conclusione, per quanto ci sia piaciuto scoprire una vulnerabilità su GitHub, siamo rimasti delusi dalla ricompensa ricevuta. Nonostante avessimo soddisfatto i criteri di una vulnerabilità critica elencati nella pagina delle policy Hackerone di GitHub – tra cui l’elusione del processo di accesso, l’accesso a dati utente sensibili e l’accesso ai dati di un altro utente -, siamo stati classificati come gravità media e non abbiamo ricevuto alcuna giustificazione chiara da parte di GitHub. Nonostante il tentativo di dialogare con il team di GitHub tramite la mediazione H1, i nostri sforzi sono stati vani. Riteniamo che questa situazione sollevi dubbi sull’equità del sistema di ricompense di GitHub e sul rispetto delle sue stesse policy.

Criteri di vulnerabilità critica indicati nella pagina delle policy Hackerone di GitHub

• esecuzione arbitraria di codice/comandi su un server della nostra rete di produzione
• query SQL arbitrarie su un database di produzione
• elusione del processo di accesso, che si tratti della password o della 2FA
• accesso a dati utente di produzione sensibili o accesso a sistemi interni di produzione
• accesso ai dati di un altro utente nel servizio GitHub Actions

SCREENSHOT DELLA POLICY DI GITHUB

Richiesta di riscontro da parte del team di GitHub:

Se un membro del team di GitHub ha una qualche giustificazione per la classificazione della vulnerabilità, gradiremmo una risposta sul report o un contatto tramite i nostri handle H1 @th3pr0xyb0y e @mrrajputhacker2

Pre-Account Takeover su npmjs.com 

Descrizione  –

Dopo aver esaminato a fondo l’applicazione, abbiamo deciso di concentrarci sulla ricerca di bug logici. Durante la nostra osservazione, abbiamo notato che il processo di autenticazione usava solo un nome utente per accedere e che l’indirizzo e-mail poteva essere facilmente aggiornato senza verifica della password. Questo ci ha portato a ritenere che il nome utente fosse un aspetto critico del backend di npmjs.com.

Abbiamo testato la funzionalità di eliminazione dell’account ed esplorato i seguenti scenari:

1. Potevamo ancora accedere alla sessione dell’account se era connesso da un browser diverso?
   Abbiamo riscontrato che l’eliminazione dell’account da un browser disconnette immediatamente l’utente da tutte le altre sessioni.
2. Potevamo registrarci usando lo stesso nome utente di un account eliminato di recente?
   I nostri test hanno mostrato che non era possibile registrarsi con un nome utente esistente o eliminato in precedenza.
3. C’era un modo per cambiare il nome utente o rivendicare un nome utente nuovo/eliminato? Abbiamo scoperto un’opzione per rivendicare o cambiare un nome utente nell’applicazione – creando un’organizzazione nell’account npmjs. Questo ci permetteva di scegliere un nuovo nome utente per l’organizzazione o di convertire il nostro account in un’organizzazione, cambiando di fatto il nostro nome utente. Tuttavia, nemmeno questa opzione permetteva di passare a un nome utente eliminato in precedenza.

Nonostante i vicoli ciechi in tutti e tre gli scenari, eravamo determinati a trovare una soluzione e siamo riusciti a eludere il sistema con successo grazie alla nostra tenacia. Abbiamo documentato i passaggi nel nostro report per mostrare come siamo riusciti a creare un pre-account takeover.

Nuove osservazioni nella nostra ricerca –

Sapevamo già che potevamo richiedere l’eliminazione del nostro account inviando un ticket di supporto. Abbiamo quindi testato questo metodo ed eliminato il nostro account. Dopo aver ricevuto l’e-mail di conferma, abbiamo scoperto che, anche se l’account era stato eliminato, risultavamo ancora connessi con il nostro nome utente mostrato in alto a destra, ma non potevamo eseguire alcuna azione.

Abbiamo provato a rivendicare di nuovo il nome utente eliminato registrandoci in un browser diverso, ma non era possibile. Tuttavia, avendo trovato un modo per cambiare il nostro nome utente, abbiamo provato a rivendicarlo di nuovo in un altro browser. Con nostra sorpresa, ci siamo riusciti, e non appena abbiamo rivendicato il nome utente, la sessione è stata trasferita alla nostra sessione precedente, in cui vedevamo solo una pagina di errore 404. In questo modo, siamo riusciti ad acquisire l’account di una persona che cercava di cambiare il proprio nome utente con quello di un account eliminato, perché avevamo i cookie e la sessione ci è stata trasferita.

Se la spiegazione sembra confusa, fai riferimento ai passaggi per riprodurre il problema e alla proof of concept per comprendere meglio questa vulnerabilità.

Passaggi per riprodurre –

1. Registrati come attaccante con un nome utente comune (ad esempio commonusername123) usando il browser Google Chrome.
2. Richiedi l’eliminazione dell’account al supporto.
3. Una volta che il supporto ha eliminato l’account, aggiorna il browser in cui l’account era connesso. Vedrai che tutte le pagine tranne quella del profilo mostrano il tuo nome utente (il link della pagina sarebbe https://npmjs.com/~username).
4. Prova a visitare https://www.npmjs.com/settings/commonusername123/profile. Vedrai una pagina 404.
5. Registrati come vittima con un nome utente diverso (ad esempio victimusername123) usando il browser Firefox.
6. Converti l’account della vittima in un’organizzazione. Questo renderà il nome utente dell’organizzazione victimusername123 e ti chiederà di scegliere un nuovo nome utente. Scegli commonusername123 come nuovo nome utente per l’account.
7. Aggiorna la pagina della sessione dell’attaccante https://npmjs.com/~username usando il browser Google Chrome.
8. Prova a visitare https://www.npmjs.com/settings/commonusername123/profile. Ora vedrai l’e-mail della vittima (ad esempio [email protected]) e avrai accesso all’account della vittima e all’organizzazione che ha creato.

POC –

https://youtube.com/watch?v=5039T3y8yFw%3Ffeature%3Doembed

Impatto –

Un malintenzionato può creare più account con nomi utente comuni su npmjs.com, eliminarli inviando un ticket di supporto e conservare i cookie. Di conseguenza, ha la possibilità di acquisire un account se qualcun altro rivendica quei nomi utente.

La nostra conclusione – 

In conclusione, per quanto fossimo entusiasti di scoprire una vulnerabilità su GitHub, siamo rimasti delusi dalla ricompensa ricevuta. Si trattava di un’acquisizione di account complessa ma possibile, che avrebbe potuto colpire una grande organizzazione. Per chiarire l’impatto, avevamo ancora un account con cookie memorizzati e sessioni attive da oltre tre mesi, poiché la sessione di un account eliminato non scade mai su npmjs. Tuttavia, GitHub ha considerato questa vulnerabilità come “media” e ci ha concesso solo una ricompensa di $4000 in tutto.

Problema di controllo degli accessi su education.github.com

Descrizione  –

Insoddisfatti della risposta di GitHub alle nostre precedenti vulnerabilità segnalate su npmjs e della ricompensa, abbiamo deciso di concentrarci su altri sottodomini di GitHub. Abbiamo scoperto che education.github.com utilizzava il Single Sign-On (SSO) di GitHub per il suo processo di accesso. Ispirati dai bug trovati su npmjs, abbiamo sperimentato un approccio simile usando nomi utente di account eliminati.

Con nostra sorpresa, abbiamo scoperto che l’eliminazione di un account GitHub non comportava la scadenza della sessione su education.github.com, e ogni pagina mostrava un errore 404, anche restando connessi. In un altro browser, abbiamo tentato di creare un nuovo account GitHub con lo stesso nome utente eliminato, ma, secondo la policy di GitHub, i nomi utente non possono essere rivendicati per 90 giorni dopo l’eliminazione .

Tuttavia, nonostante questi vicoli ciechi, siamo riusciti a eludere il problema e a ottenere il controllo degli accessi . 

Elusione del controllo degli accessi –

Abbiamo osservato che, anche dopo aver cambiato un nome utente in GitHub e aggiornato la nostra sessione di education.github.com, il nome utente restava lo stesso – non cambiava, nonostante lo avessimo modificato nel nostro profilo GitHub. Questo accade perché il token di sessione è legato al nome utente e l’SSO lo aggiorna solo quando accediamo di nuovo tramite GitHub. Abbiamo quindi rapidamente rivendicato l’account GitHub eliminato e poi il vecchio nome utente, che era ancora associato a https://education.github.com  con quell’account, usando un nuovo account GitHub in un browser diverso, e abbiamo effettuato l’accesso a https://education.github.com su un nuovo browser.  A quel punto abbiamo osservato che entrambi gli account avevano lo stesso nome utente ma un’e-mail diversa associata ed erano perfettamente funzionanti; quindi, se inviavamo un modulo educativo o attivavamo qualche funzione, poteva causare danni all’integrità dei dati su entrambi i lati, perciò lo abbiamo segnalato come problema ed è stato accettato come problema valido .

Abbiamo notato che, anche dopo aver cambiato il nostro nome utente GitHub, la sessione su education.github.com restava invariata. Questo era dovuto al fatto che il token di sessione era legato al nome utente e l’SSO lo aggiornava solo all’accesso tramite GitHub. Per sfruttarlo, abbiamo rapidamente rivendicato un account GitHub eliminato e poi il vecchio nome utente, che era ancora associato all’account education.github.com. Abbiamo poi effettuato l’accesso a education.github.com in un browser diverso con un nuovo account GitHub, e abbiamo constatato che entrambi gli account avevano ora lo stesso nome utente ma indirizzi e-mail diversi ed erano pienamente funzionanti.

Questo significava che, se inviavamo un modulo educativo o attivavamo qualche funzione, poteva causare danni all’integrità dei dati su entrambi i lati. Abbiamo segnalato prontamente questo problema ed è stato accettato come vulnerabilità valida.

Passaggi per riprodurre – 

1. Accedi al tuo account GitHub
2. Vai su https://education.github.com/schools
3. Cambia il nome utente del tuo account GitHub
4. Aggiorna la pagina o vai di nuovo su https://education.github.com/schools e controlla il nome utente dall’icona del profilo a destra
5. Vedrai che il vecchio nome utente è ancora attivo su education.github.com
6. Poiché il vecchio nome utente è rivendicabile, sembra che sia possibile un’acquisizione di account su education.github.com rivendicandolo.
7. Se non hai un’e-mail universitaria, non puoi verificare se le azioni eseguite sulla vecchia sessione influiranno su un nuovo account registrato con il vecchio nome utente.
8. Accedi a education.github.com in una nuova finestra di Chrome con un account appena creato che abbia lo stesso nome utente della vecchia sessione.
9. Vedrai che ora hai due sessioni attive con lo stesso nome utente.

Impatto –

L’impatto di questo problema dovrebbe essere valutato dal team di GitHub. Ha il potenziale di compromettere informazioni sensibili dei nuovi utenti, come il loro istituto o il loro indirizzo e-mail e le loro informazioni di identificazione personale (PII), se si registrano con il nome utente per cui esiste una sessione attiva. Questo potrebbe portare a un’acquisizione di account e alla fuga di PII.

La nostra conclusione – 

Siamo stati contenti di scoprire questa vulnerabilità su GitHub, anche se era simile a quella che avevamo trovato su npmjs. Questa volta non siamo riusciti a valutare l’impatto completo del problema. Ciononostante, siamo stati soddisfatti della ricompensa concessa.

Hai imparato qualcosa da noi?

Aiutaci condividendo questo articolo con i tuoi amici, la tua famiglia e i tuoi colleghi, e seguendoci sui nostri account social. Puoi anche iscriverti alla nostra mailing list per ricevere altri write-up informativi sulle nostre scoperte. Mostra il tuo sostegno twittando su questo articolo e condividendolo il più possibile con la community.

Dai un’occhiata al nostro nuovo prodotto, Blind XSS Hunter, pensato per sostenere la community, solo su https://bxsshunter.com.

Preparati a un entusiasmante lancio di CyberXplore! Negli ultimi due anni abbiamo lavorato sodo per perfezionare un prodotto che non vediamo l’ora di condividere con te. Sii tra i primi a provarlo restando in contatto con noi o seguendoci nel nostro percorso. E per tutti gli ultimi aggiornamenti, non dimenticare di iscriverti alla nostra newsletter! Questo è un lancio da non perdere!