Ultima modifica:
GitHub Security: un bug relativo a un'errata gestione delle sessioni permetteva di autenticarsi nell'account di altri utenti
Tradotto dal blog ufficiale di githubTempo di lettura stimato: 3 minuti
La sera dell'8 marzo sono state invalidate tutte le sessioni attive su GitHub.com create prima delle 12:03 UTC dello stesso giorno in maniera preventiva, con lo scopo di proteggere gli utenti da una vulnerabilità di sicurezza estremamente rara, ma potenzialmente grave, che colpiva un numero molto ristretto di sessioni su GitHub.
ll 2 marzo, GitHub ha ricevuto una segnalazione di un comportamento anomalo in merito alla ad una sessione autenticata di un utente. Dopo aver ricevuto la segnalazione, GitHub Security e GitHub Engineering hanno immediatamente iniziato a indagare per comprenderne l'origine, la causa principale, l'impatto e l'urgenza di questo problema sul sito. E' stata apportata un' iniziale patch per la vulnerabilità il 5 marzo, mentre le analisi sono continuate anche durante il fine settimana.
ll 2 marzo, GitHub ha ricevuto una segnalazione di un comportamento anomalo in merito alla ad una sessione autenticata di un utente. Dopo aver ricevuto la segnalazione, GitHub Security e GitHub Engineering hanno immediatamente iniziato a indagare per comprenderne l'origine, la causa principale, l'impatto e l'urgenza di questo problema sul sito. E' stata apportata un' iniziale patch per la vulnerabilità il 5 marzo, mentre le analisi sono continuate anche durante il fine settimana.
"La patch per risolvere il bug e l'invalidazione delle sessioni attive ha risolto il problema ed ora si può nuovamente accedere in qualsiasi momento" fanno sapere dal sito.
Cosa è successo e quali azioni sono state intraprese?
In circostanze estremamente rare, una race condition in un processo di gestione delle richieste di backend potrebbe aver instradato erroneamente la sessione di un utente verso quella di un altro utente autenticato, assegnandoli un cookie di sessione valido e autenticato attivo per un altro utente. È importante sottolineare che questo problema però non era il risultato della compromissione di dati di accesso personali (come password o chiavi SSH), e non ci sono prove che suggeriscano che si tratti di una compromissione di qualsiasi altro sistema di GitHub. La risposta più plausibile è che questo problema fosse dovuto alla rara e isolata gestione impropria delle sessioni degli utenti in fase di autenticazione. Inoltre bisogna anche evidenziare che questo problema non poteva essere intenzionalmente exploitato o controllato in maniera diretta da un utente malintenzionato, ma era frutto di una casualità applicativa.
Il bug è esistito su GitHub.com per un periodo cumulativo di meno di due settimane, in diversi momenti tra l'8 febbraio 2021 e il 5 marzo 2021. Una volta identificata la causa principale e sviluppata una remediation, è stata immediatamente patchata la vulnerabilità, in data 5 marzo. Una seconda patch è stata inoltre distribuita l'8 marzo per implementare ulteriori misure di sicurezza e per rafforzare ulteriormente l'applicazione risetto questa tipologia di bug. Non ci sono indicazioni che altri prodotti ricollegati a GitHub siano affetti da questo problema, incluso GitHub Enterprise Server. Si crede che questo "misrouting" delle sessioni si sia verificato in meno dello 0,001% delle sessioni autenticate sul sito.
Il bug è esistito su GitHub.com per un periodo cumulativo di meno di due settimane, in diversi momenti tra l'8 febbraio 2021 e il 5 marzo 2021. Una volta identificata la causa principale e sviluppata una remediation, è stata immediatamente patchata la vulnerabilità, in data 5 marzo. Una seconda patch è stata inoltre distribuita l'8 marzo per implementare ulteriori misure di sicurezza e per rafforzare ulteriormente l'applicazione risetto questa tipologia di bug. Non ci sono indicazioni che altri prodotti ricollegati a GitHub siano affetti da questo problema, incluso GitHub Enterprise Server. Si crede che questo "misrouting" delle sessioni si sia verificato in meno dello 0,001% delle sessioni autenticate sul sito.
Per eccesso di cautela, e con una forte inclinazione verso la sicurezza degli account, è stata invalidata ogni sessione create prima delle 12:03 UTC dell'8 marzo per evitare anche la più remota possibilità che delle sessioni compromesse e non rilevate possano ancora esistere dopo che la vulnerabilità è stata patchata. Per il numero ristretto di account che si conosce esser stati affetti da questo problema, è stato contattato il diretto interessato, riportando ulteriori informazioni e indicazioni di prevenzione.
Cosa posso fare?
Sebbene non sia necessaria alcuna azione da parte dell'utente, per chi non si fidasse si raccomanda di eseguire nuovamente il logout dall'applicazione e successivamente rieffettuare il login. In generale inoltre si incoraggia a seguire le best practice di sicurezza pubblicate per utenti e aziende.Se si verifica un blocco dell'account a causa dell'impossibilità di completare la 2FA in fase di login, è necessario fare riferimento al processo di recupero dell'account.
