35 inserimenti di codice dannoso in GitHub: attacco o sforzo di ricompensa di bug?

Un hacker conosciuto con lo pseudonimo "Pl0xP" ha clonato un gran numero di repository GitHub e ha leggermente modificato i nomi dei repository clonati, in uno sforzo di typosquatting per impersonare progetti legittimi, infettando così potenzialmente qualsiasi software che ha importato il codice, hanno detto oggi gli esperti di software.

La clonazione diffusa ha provocato più di 35,000 inserimenti di URL dannosi in diversi repository di codici, anche se il numero esatto di progetti software interessati è probabilmente molto inferiore, ha dichiarato in un post su Twitter l'ingegnere informatico Stephen Lacy. L'attacco, una variante di confusione di dipendenza, avrebbe potuto causare problemi agli sviluppatori che utilizzavano i falsi repository GitHub senza un'adeguata verifica della fonte del software, ha affermato.

Se importato, il codice dannoso esegue codice sul sistema, secondo Lacy. “Questo attacco invierà l'INTERO ENV dello script, dell'applicazione, del laptop (app elettroniche) al server dell'aggressore! Gli ENV includono: chiavi di sicurezza; Chiavi di accesso AWS; Chiavi crittografiche... molto altro ancora." 

Gli "ENV" sono variabili di ambiente, utilizzate per archiviare informazioni a cui gli sviluppatori desiderano fare riferimento nei loro flussi di lavoro.

L'ingegnere del software ha scoperto la funzionalità dannosa quando ha controllato una libreria software che pensava di incorporare nel suo progetto, ha detto Lacy.

"Ho scoperto l'exploit mentre stavo esaminando un progetto che ho trovato tramite una ricerca su Google," ha twittato. "Ecco perché non installiamo pacchetti casuali da Internet!"

La clonazione, o “forking”, non è una nuova tecnica dannosa, ma è complessa.

"I malintenzionati sono già noti in passato per aver creato repository popolari clonati o biforcati con codice dannoso", afferma Mor Weinberg, ingegnere informatico di Aqua Security. "Questo può diventare piuttosto difficile da individuare, poiché i repository clonati possono conservare commit di codice con nomi utente e indirizzi e-mail degli autori originali, dando l'impressione fuorviante che anche i commit più recenti siano stati effettuati dagli autori del progetto originale. I commit del codice open source firmati con chiavi GPG di autori di progetti autentici sono un modo per verificare l'autenticità del codice.

"Questo... era come se qualcuno creasse un sito web 'falso' o inviasse un'e-mail di phishing", aggiunge Mark Lambert, vicepresidente dei prodotti presso ArmorCode. "Questo attirerà le persone che non prestano attenzione."

Un attacco o una ricerca legittima?

Questo fork di massa in GitHub potrebbe non essere stato un vero attacco. Una persona che affermava di essere a conoscenza della questione ha posizionato il diffuso typosquatting come uno sforzo di ricerca legittimo.

“Questo è un semplice tentativo di ricompensa per gli insetti. nessun danno fatto. Il rapporto verrà pubblicato”, a L'utente di Twitter denominato "pl0x_plox_chiken_p0x" ha twittato il 3 agosto.

Anche se un progetto di ricerca mal concepito potrebbe spiegare l’attacco, creare migliaia di modifiche al codice per la ricerca sembra irrazionalmente rischioso. Inoltre, l'utente di Twitter aveva registrato l'account solo nei tre giorni precedenti: la breve durata degli account è spesso una caratteristica degli utenti online fraudolenti.

L'affermazione secondo cui l'attacco fa parte di un bug bounty "è in attesa di essere provata, poiché l'attività ha le caratteristiche di un'attività con intenti dannosi", dice a Dark Jossef Harush, responsabile dell'ingegneria della sicurezza della catena di fornitura presso la società di sicurezza software Checkmarx. Lettura.

In ogni caso, Michael Skelton, direttore senior delle operazioni di sicurezza presso la piattaforma bug-bounty Bugcrowd, osserva che almeno i repository di codice originali sono rimasti inalterati.

"Anche se non è chiaro quale sarebbe la natura della scoperta del bug-bounty di Pl0xP (poiché l'ingegneria sociale non rientra nell'ambito di quasi tutti i programmi di bug-bounty), sembra che abbiano clonato un certo numero di repository e apportato le modifiche in quei cloni solo che in nessun caso questo cambiamento è riuscito a raggiungere i repository originali che erano stati clonati", afferma. "La clonazione di un repository è un'azione standard che non influisce sul repository originale a meno che il proprietario non unisca nuovamente una modifica (richiesta tramite una richiesta pull), cosa che non è stata fatta qui."

Le dipendenze da software dannoso abbondano

GitHub apparentemente ha ripulito i commit del codice dannoso e, a partire dal pomeriggio del 3 agosto, una ricerca per l'URL errato incorporato non ha prodotto risultati. Eppure l’attacco non è certo la prima volta che progetti open source hanno a che fare con aggressori. Il numero di attacchi contro la catena di fornitura del software è balzato del 650% nel 2021, guidato principalmente da attacchi di confusione delle dipendenze, in cui l'aggressore utilizza una versione con un nome quasi identico di un blocco di codice open source nella speranza che gli sviluppatori sbaglino a digitare il nome di una libreria o componente desiderato o non notino la leggera differenza nella nomenclatura. 

Il seeding dei repository con progetti dannosi e dai nomi errati richiede che l'aggressore esegua alcune ricerche preliminari. A luglio, la società di sicurezza software Checkmarx ha rivelato un modo per creare account sviluppatore falsi su GitHub, completo di una cronologia attiva dei commit del codice per aumentare la propria credibilità. La tecnica, insieme all'ultimo attacco, sottolinea che i manutentori devono adottare misure per accettare solo commit di codice firmato, afferma Harush. Gli sviluppatori devono "fare attenzione alle richieste pull e ai contributi che presentano commit sospetti non verificati, [e devono] rivedere... il contenuto dei contributi rispetto alla dichiarazione di non responsabilità nel messaggio di commit e ai contributi che aggiungono o modificano le dipendenze esistenti a dipendenze con nomi simili come parte del contributo”, aggiunge.

Non fidarti, verifica

Per evitare che i loro progetti vengano avvelenati, i manutentori e gli sviluppatori dovrebbero fidarsi solo di quei contributori che conoscono e che hanno una cronologia di commit estesa e verificabile. Dovrebbero anche utilizzare gli strumenti disponibili, come le firme digitali e l’autenticazione a più fattori, per proteggere i propri account, afferma Harush.

"Come non dovresti fidarti delle caramelle degli sconosciuti, non fidarti del codice degli sconosciuti", dice. "Gli utenti possono essere ingannati quando valutano il progetto candidato e pensare che sia legittimo, [quindi] lo usano nei loro computer di sviluppo locali, creano ambienti, ambienti di produzione e persino creano software, [fino all'esecuzione di qualcosa di dannoso] sui clienti [ sistemi].”

Nell'avviso di luglio di Checkmarx sullo spoofing delle informazioni sull'identità e sul commit delle informazioni nel file git utilità della riga di comando, l'azienda ha sottolineato i rischi per i progetti software quando i committenti dannosi si travestono da contributori noti. Questo “fa sembrare il progetto affidabile”, ha dichiarato l'azienda. "Ciò che rende questo spoofing ancora più allarmante è il fatto che l'utente oggetto dello spoofing non viene informato e non saprà che il suo nome viene utilizzato."

GitHub ha già aggiunto firme digitali per i commit del codice per verificare l'identità del contributore, ma i manutentori del progetto dovrebbero abilitare la "modalità vigilante", una funzionalità di GitHub che mostra i dettagli dello stato di verifica di ogni commit e del relativo contributore, ha affermato Checkmarx.

Come minimo, gli sviluppatori e i manutentori del progetto dovrebbero occasionalmente rivedere il loro registro dei commit e chiedere agli altri manutentori di abilitare i commit firmati GPG, dice Harush. "Abituarsi ad avere un registro dei commit firmato ti aiuterà a prestare attenzione ai contributi non verificati."

Non è stato possibile raggiungere immediatamente GitHub per un commento.