Domenica 16 marzo 2025, il mondo della sicurezza informatica ha assistito a una campagna di phishing mirata estremamente sofisticata, che ha avuto come obiettivo migliaia di sviluppatori e manutentori di progetti open source su GitHub.
Questa campagna rappresenta un nuovo capitolo nella lunga storia di minacce ai danni della supply chain del nostro software.
Le piattaforme open source come GitHub sono da sempre obiettivi di alto valore per attori malevoli. Il motivo è semplice: una volta compromesso un account di un maintainer è possibile iniettare codice malevolo in librerie popolari e diffondere rapidamente malware a milioni di utenti e organizzazioni.
Questa volta, l’attacco ha sfruttato tecniche avanzate di phishing e manipolazione delle funzionalità native di GitHub.
Indice degli argomenti
Truffa su GitHub: la campagna di attacco
L’attacco rilevato in questa recente campagna sfrutta un vettore insidioso e altamente convincente: la generazione automatica di notifiche da parte di GitHub per nuove issue aperte nei repository pubblici.
Gli attaccanti, utilizzando account falsi e strategicamente nominati come “GitHub Notification”, hanno aperto delle “issue”, delle segnalazioni o meglio richieste, su migliaia di repository di codice e progetti open source pubblicati tramite la nota piattaforma.
Queste “issue” riportavano titoli altamente allarmistici come “Security Alert: Unusual Access Attempt”, studiati per scatenare un sussulto da parte degli amministratori del progetto.
Quello che rende l’attacco particolarmente efficace è il fatto che all’apertura delle “issue”, GitHub invia in automatico dei messaggi di posta ai proprietari dei progetti. Le notifiche via email ricevute dai manutentori, pertanto, provengono effettivamente dagli indirizzi di posta legittimi di GitHub, senza alcun indizio diretto di spoofing o alterazione.
Inoltre, l’email di notifica inviata all’apertura della “issue” include quasi inalterato il corpo della richiesta aperta dall’attaccante, in questo caso accuratamente realizzato per imitare in maniera indistinguibile una vera notifica di sicurezza del team di GitHub.
Quindi, il contenuto della notifica, che si presenta come una reale “Security Alert”, e che descrive dettagli precisi di un presunto accesso sospetto, includendo informazioni credibili quali IP e località insolite, provenendo dagli indirizzi legittimi della piattaforma, genera panico nella vittima portandola ad interagire con il messaggio per “proteggere” il proprio account.
Esempio di messaggio della campagna di attacco.
La trappola scatta proprio qui: il messaggio richiede di verificare l’attività sospetta autenticando sedicente una “security app” di GitHub.
In realtà, l’app in questione non ha nulla di ufficiale; si tratta di un’applicazione di terze parti fraudolenta denominata in modo ingannevole. Ad esempio, durante la campagna, l’applicazione era nominata “Github Security” ed ospitata su servizi cloud di terze parti, in questo caso Render.com, piattaforma PaaS californiana di nicchia.
E qui il secondo trucco: il link a questa app fraudolenta presente all’interno della mail punta all’indirizzo di GitHub ufficiale. In particolare, alla pagina ufficiale della piattaforma per concedere autorizzazioni ad applicazioni di terze parti.
Quindi, anche in questo caso, le normali cautele anti-phishing rischiano di saltare, perché il dominio di destinazione è effettivamente quello della piattaforma.
Tuttavia, la malaugurata conferma da parte dell’utente a questa applicazione di terze parti (nella campagna, app id: Ov23liQMsIZN6BD8RTZZ), apparentemente innocua e legittima, autorizza in realtà l’attaccante ad avere accesso diretto e completo al suo account GitHub, ottenendo il controllo totale dell’account, dei repository privati e pubblici, e dandogli la possibilità di manipolare i codici sorgenti di progetti open source e librerie utilizzate da innumerevoli organizzazioni nel mondo.
A quale fine? Difficile dirlo in questo momento, tuttavia, la compromissione di repository di codice potrebbe essere utilizzata per infiltrare la supply chain del software, compromettere organizzazioni e prodotti tecnologici, minare criptovalute, ed installare backdoor.
Schermata di autorizzazione dell’app malevola
L’ombra malevola che viene dall’oriente
Questa campagna, nella sola giornata di domenica 16 marzo, ha colpito ben 8 mila progetti open source. La sofisticazione e la scala di questa campagna di attacco suggeriscono il coinvolgimento di attori strutturati. Difficile attribuirne la paternità in questo preciso momento. Tuttavia, ci sono alcuni elementi contestuali per cui considerare una potenziale matrice Nord Coreana.
Di recente, Lazarus, tar i principali APT nordcoreani, noto per le sue operazioni globali, ha orchestrato attacchi all’ecosistema della supply chain del software, ad esempio ai danni del popolare gestore di librerie “npm”, dove ha inoculato librerie infette con nomi simili a quelli di librerie e dipendenze utilizzate da milioni di sviluppatori in tutto il mondo: una digitazione errata da parte di uno di questi, e Lazarus è dentro il prodotto.
Ma non solo, un’altra serie di attività malevole riconducibili alla Corea del Nord è stata registrata sempre di recente, in cui gli attaccanti, fingendosi recruiter nel settore dello sviluppo software, attirano le vittime con false e, successivamente, le inducono a scaricare progetti software che nascondono malware.
Questi esempi evidenziano come gli attori nordcoreani siano in questo particolare periodo estremamente concentrati nell’attaccare la supply chain del software, con l’obiettivo di compromettere infrastrutture critiche e ottenere informazioni sensibili.
Conclusioni
La campagna di phishing contro GitHub di marzo 2025 segna un preoccupante punto di svolta nella sofisticazione degli attacchi informatici contro il mondo open source e sottolinea la necessità di adottare misure efficaci per proteggere la supply chain del software.
Ad esempio, occorre assicurarsi che gli sviluppatori siano consapevoli delle minacce attuali e delle migliori pratiche di sicurezza è fondamentale, come anche implementare politiche che integrino la sicurezza in ogni fase dello sviluppo è essenziale, includendo linee guida per la scrittura di codice sicuro, la gestione delle vulnerabilità e l’adozione di strumenti di analisi della sicurezza del codice.
E, ultimo ma non meno importante, è cruciale monitorare costantemente le dipendenze del software e gli accessi concessi a terze parti.
In ultima analisi, la protezione dell’ecosistema del software richiede una combinazione efficace di vigilanza, educazione e collaborazione proattiva tra piattaforme, comunità e autorità internazionali.
