L'azienda Truffle Security ha pubblicato degli scenari di attacco su diversi approcci comuni all'utilizzo di repository su GitHub, che consentono di estrarre dati da repository remoti che hanno fork pubblici o che sono stati creati come fork.
La possibilità di accedere ai commit tramite hash in tutti i fork collegati del repository è dovuta al fatto che GitHub, per motivi di ottimizzazione e per evitare duplicati, memorizza insieme tutti gli oggetti del repository principale e dei fork, separando logicamente solo la proprietà dei commit. Tale memorizzazione consente di visualizzare nel repository principale qualsiasi commit di un fork specificandone esplicitamente l'hash nell'URL. Ad esempio, un utente può creare un fork del repository ‘/torvalds/linux’ e aggiungere qualsiasi codice, dopo di che questo codice diventa accessibile tramite un link diretto all'hash nel repository ‘/torvalds/linux’. In caso di eliminazione del repository, se esiste almeno un fork pubblico, i dati del repository rimosso rimangono accessibili tramite l'hash del commit.
Vengono proposti tre scenari che rappresentano una minaccia alla sicurezza:
- Il primo scenario riguarda situazioni in cui gli sviluppatori creano fork di repository pubblici, apportano modifiche, fanno esperimenti e poi eliminano il fork. Oltre alla fuga di codice non destinato alla pubblicazione, una situazione pericolosa si verifica quando negli esperimenti nel codice dei file di esempio vengono aggiunte chiavi di accesso API funzionanti. In questo caso, un attaccante potrebbe accedere alla modifica tramite l'hash del commit, anche dopo l'eliminazione del fork tramite il repository principale. Ad esempio, utilizzando il metodo proposto, i ricercatori sono riusciti a identificare 30 chiavi di accesso API funzionanti, esaminando tre repository legati all'apprendimento automatico con un numero elevato di fork.
- Il secondo scenario riguarda la possibilità di accedere ai dati dopo l'eliminazione del repository principale, se per quel repository sono stati creati fork. Un esempio è il caso in cui in un repository pubblico di una società siano stati accidentalmente pubblicati le chiavi private di un dipendente, che consentono l'accesso completo a tutti i repository di tale società su GitHub. La società ha rimosso il repository tramite il quale si è verificata la fuga di dati, ma le chiavi sono comunque rimaste accessibili per il recupero tramite richieste basate sull'hash del commit nei repository con fork.
- Il terzo scenario è legato al modello di sviluppo di progetti che sviluppano una versione open source di base in un repository pubblico e una versione proprietaria estesa in uno privato. Se una società ha inizialmente sviluppato un progetto in un repository privato e poi, dopo aver aperto il codice del progetto, lo ha trasferito in pubblico, continuando però lo sviluppo di una versione interna o estesa chiusa in un fork privato, esiste la possibilità di accedere alle modifiche aggiunte al fork privato tramite gli hash dei commit attraverso il repository pubblico. Si noti che l'accesso è possibile solo alle modifiche aggiunte al fork privato prima della trasformazione del repository principale in pubblico (i depositi dei repository privati e pubblici sono separati, ma quando due repository erano privati, i commit erano memorizzati insieme, quindi sono rimasti nel repository dopo la sua trasformazione in pubblico).
Il trucco che consente di accedere ai commit nei fork di un repository tramite il link al repository principale è conosciuto da molti anni ed è periodicamente utilizzato per vari scherzi e per ingannare gli sviluppatori (ad esempio, gli scherzosi creano occasionalmente una falsa impressione di backdoor nel repository del kernel Linux su GitHub in questo modo). Come misura per contrastare tali scherzi, GitHub ha aggiunto un avviso che informa che il commit richiesto non appartiene ai rami nel repository attuale e potrebbe appartenere a un fork. Tuttavia, la possibilità di accedere ai commit tramite l'hash in qualsiasi repository collegato ai fork è stata considerata innocua, poiché per accedere ai dati nei fork remoti e privati è necessario conoscere l'hash del commit.
Trovare un hash di commit generato dall'algoritmo SHA-1 e comprendente 32 caratteri non è possibile, ma si è scoperto che non è nemmeno necessario. GitHub supporta una forma abbreviata di riferimento ai commit, che consente di indirizzare le modifiche utilizzando i primi caratteri dell'hash, a patto che non ci siano sovrapposizioni con altri commit. Il numero minimo di caratteri per il riferimento abbreviato all'hash è 4, il che corrisponde all'esplorazione di circa 65.000 combinazioni (16^4). Inoltre, l'esplorazione potrebbe non essere necessaria, poiché l'API di GitHub consente di collegare gestori per intercettare eventi, utilizzati da progetti di terze parti che mantengono un archivio con il log completo di tutte le operazioni, in cui le informazioni sugli hash dei commit rimangono anche dopo l'eliminazione dei repository.
Fonte: opennet.ru
