{"id":118226,"date":"2024-07-25T15:43:00","date_gmt":"2024-07-25T13:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki"},"modified":"2024-07-25T15:43:00","modified_gmt":"2024-07-25T13:43:02","slug":"dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","title":{"rendered":"Accesso ai dati da repository remoti e privati su GitHub, che hanno fork","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
La possibilit\u00e0 di accedere ai commit tramite hash in tutti i fork collegati di un repository \u00e8 dovuta al fatto che GitHub, per ottimizzare e prevenire duplicati, memorizza tutti gli oggetti del repository principale e dei fork insieme, separando solo logicamente la pertinenza dei commit. Questo tipo di archiviazione consente di visualizzare nel repository principale qualsiasi commit da qualsiasi fork, specificando chiaramente il suo hash nell'URL. Ad esempio, un utente pu\u00f2 creare un fork del repository '\/torvalds\/linux' e aggiungere qualsiasi codice, dopo di che questo codice sar\u00e0 accessibile tramite un collegamento diretto all'hash nel repository '\/torvalds\/linux'. In caso di eliminazione del repository, se esiste almeno un fork pubblico, i dati del repository eliminato rimangono accessibili tramite l'hash del commit. <\/p>\n
Sono proposti tre scenari che rappresentano una minaccia alla sicurezza: <\/p>\n
\n
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 \u00e8 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.\n
Il secondo scenario riguarda la possibilit\u00e0 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 \u00e8 avvenuta la fuga, ma le chiavi sono ancora disponibili per il recupero tramite richieste basate sull'hash del commit nei repository forkati.
<\/center>\n
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\u00e0 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'\u00e8 la possibilit\u00e0 di accedere alle modifiche aggiunte nel fork privato tramite gli hash dei commit attraverso il repository pubblico. Tuttavia, l'accesso \u00e8 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).
<\/center> <\/ul>\n
Il trucco che consente di accedere ai commit nei fork di un repository tramite il link al repository principale \u00e8 conosciuto da molti anni ed \u00e8 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\u00e0 di accedere ai commit tramite l'hash in qualsiasi fork associato al repository \u00e8 stata considerata innocua, poich\u00e9 per accedere ai dati nei fork remoti e privati \u00e8 necessario conoscere l'hash del commit. <\/p>\n
Trovare l'hash di un commit, generato sulla base dell'algoritmo SHA-1 e composto da 32 caratteri, \u00e8 praticamente impossibile, ma si \u00e8 scoperto che non \u00e8 necessario. GitHub supporta una forma abbreviata per riferirsi ai commit, che consente di indirizzare le modifiche utilizzando i primi caratteri dell'hash, se non ci sono sovrapposizioni con altri commit. Il numero minimo di caratteri per l'abbreviazione dell'hash \u00e8 4, il che corrisponde a un massimo di 65.000 combinazioni (16^4). Inoltre, potrebbe non essere necessario fare la ricerca, poich\u00e9 l'API di GitHub consente di collegare gestori per intercettare eventi, utilizzati da progetti di terze parti che mantengono un archivio completo di tutte le operazioni, in cui le informazioni sugli hash dei commit rimangono anche dopo l'eliminazione dei repository. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Accesso](\"\/wp-content\/uploads\/2024\/07\/45381deb03eaa5be40baf8b4dbf7b481.png\")
<\/center>\n![\"Accesso](\"\/wp-content\/uploads\/2024\/07\/23342cf907bd300699e913297d29b310.png\")
<\/center> <\/ul>\n