L'azienda Truffle Security ha pubblicato scenari di attacco su diverse metodologie comuni di lavoro con i repository di GitHub, che consentono di estrarre dati da repository remoti con fork pubblici o creati come fork.
La possibilità di accedere ai commit tramite hash in tutti i fork correlati del repository è dovuta al fatto che GitHub, per ottimizzare e ridurre le duplicazioni, memorizza tutti gli oggetti del repository principale e dei fork insieme, separando solo logicamente la proprietà dei commit. Questa modalità di archiviazione permette di visualizzare nel repository principale qualsiasi commit da qualsiasi fork, specificando chiaramente il suo hash nell'URL. Ad esempio, un utente può creare un fork del repository ‘/torvalds/linux’ e aggiungere del codice, dopodiché questo codice sarà accessibile tramite un link hash diretto nel repository ‘/torvalds/linux’. Se il repository viene eliminato, se esiste almeno un fork pubblico, i dati del repository rimosso rimangono accessibili tramite l'hash del commit.
Sono proposti tre scenari che rappresentano una minaccia alla sicurezza:
- Il primo scenario riguarda situazioni in cui gli sviluppatori creano fork di repository pubblici, aggiungono modifiche, sperimentano e poi eliminano. Oltre alla fuoriuscita di codice che non è destinato alla pubblicazione, la situazione pericolosa si presenta quando nei esperimenti si aggiungono chiavi di accesso API funzionanti ai file di esempio. In questo caso, un attaccante potrebbe acquisire l'accesso alle modifiche tramite l'hash del commit, riferito dopo la rimozione del fork attraverso il repository principale. Ad esempio, in un modo suggerito, i ricercatori sono riusciti a identificare 30 chiavi di accesso API funzionanti, esaminando tre repository correlati all'apprendimento automatico con un elevato numero di fork.
- Il secondo scenario riguarda la possibilità di accedere ai dati dopo l'eliminazione del repository primario, se sono stati creati fork per quel repository. Come esempio, viene citato un caso in cui in un repository pubblico di un'azienda sono stati accidentalmente pubblicati le chiavi private di un dipendente, che consentivano l'accesso completo a tutti i repository di quell'azienda su GitHub. L'azienda ha eliminato il repository da cui è avvenuta la fuga, ma le chiavi sono ancora disponibili per il recupero tramite richieste basate sull'hash del commit nei repository forkati.
- Il terzo scenario riguarda il modello di sviluppo dei progetti che sviluppano una versione open source di base in un repository pubblico e una versione proprietaria estesa in uno privato. Se una società inizialmente ha sviluppato un progetto in un repository privato e poi, dopo l'apertura del codice del progetto, lo ha trasferito nel rango pubblico, ma ha continuato a sviluppare una versione interna chiusa o estesa in un fork privato, c'è la possibilità di accedere alle modifiche aggiunte nel fork privato tramite gli hash dei commit attraverso il repository pubblico. Tuttavia, l'accesso è possibile solo alle modifiche aggiunte nel fork privato prima della conversione del repository principale in pubblico (i repository privati e pubblici sono separati, ma quando due repository erano privati, i commit sono stati conservati insieme, quindi sono rimasti nel repository dopo la sua conversione 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 è occasionalmente utilizzato per vari scherzi e per ingannare gli sviluppatori (ad esempio, gli scherzatori creano occasionalmente l'illusione di una sostituzione di backdoor nel repository del kernel Linux su GitHub). Come misura per contrastare tali scherzi, GitHub ha aggiunto un avviso che il commit richiesto non appartiene ai rami del repository attuale e potrebbe appartenere a un fork. Tuttavia, la possibilità di accedere ai commit tramite l'hash in qualsiasi fork associato al repository è 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 sulla base dell'algoritmo SHA-1 e comprendente 32 caratteri non è realistico, ma si è rivelato che non è nemmeno necessario. GitHub supporta una forma abbreviata per fare riferimento ai commit, permettendo di indirizzare le modifiche utilizzando solo i primi caratteri dell'hash, a condizione che non ci siano sovrapposizioni con altri commit. Il numero minimo di caratteri per una referenza abbreviata dell'hash è 4, il che corrisponde a circa 65.000 possibili combinazioni (16^4). Tuttavia, la ricerca potrebbe non essere necessaria, poiché l'API di GitHub consente di connettere gestori per catturare eventi, utilizzati da progetti di terze parti che mantengono un archivio con un log completo di tutte le operazioni, in cui le informazioni sugli hash dei commit rimangono anche dopo la cancellazione dei repository.
Fonte: opennet.ru
