La ricognizione è la prima fase di qualsiasi attacco mirato. Quando i team infrastrutturali pensano alla mappatura delle minacce, l'attenzione si concentra spesso sulla scansione della rete e sull'enumerazione delle porte. Ma esiste una superficie di attacco meno ovvia ma ben visibile: l'API di GitHub. Una recente analisi di Datadog Security Labs documenta campagne coordinate che enumerano sistematicamente organizzazioni, repository e account di sviluppatori aziendali su GitHub tramite strumenti automatizzati che evitano deliberatamente di attivare i limiti di frequenza o di essere rilevati.
Come gli account fantasma consentono la ricognizione silenziosa
Il funzionamento di queste campagne rivela un approccio operativo sottile ma deliberato. Gli aggressori non utilizzano account GitHub appena creati, poiché questi sarebbero privi di storia e reputazione. Al contrario, acquisiscono o riattivano account inattivi, a volte risalenti a anni prima, che presentano grafici di attività e cronologie di commit dall'aspetto legittimo. Questi account fantasma si integrano perfettamente nell'ecosistema di GitHub. Se abbinati ad user agent personalizzati o dall'aspetto legittimo, le richieste API provenienti da tali account non vengono immediatamente rilevate come sospette.
Un vettore alternativo prevede l'utilizzo di token OAuth compromessi, ottenuti tramite precedenti violazioni di dati, campagne di phishing o tecniche di ingegneria sociale. Un token associato a un account sviluppatore reale implica una fiducia implicita e può eludere molte delle euristiche di rilevamento che le organizzazioni applicano ai modelli di utilizzo delle proprie API.
Una volta in possesso di queste identità di copertura, gli aggressori eseguono strumenti di scraping automatizzati che interrogano l'API di GitHub per ottenere informazioni sulla struttura organizzativa, l'appartenenza ai team, i nomi dei repository, la cronologia dei commit e le impostazioni di visibilità. L'obiettivo non è lo sfruttamento immediato, bensì una mappatura dettagliata della postura di sviluppo software di un obiettivo: identificare quali repository sono pubblici, quali privati, quali pratiche di sviluppo sono visibili e quali account dispongono di privilegi elevati.
Perché le organizzazioni non colgono questi segnali
La fase di ricognizione può protrarsi per settimane senza attivare gli avvisi convenzionali. Le organizzazioni GitHub spesso consentono volumi di chiamate API relativamente elevati, soprattutto per le organizzazioni con molti sviluppatori. Un account inattivo che effettua query sistematiche sui metadati pubblici potrebbe non superare i limiti di frequenza. Inoltre, le organizzazioni spesso non dispongono di una visibilità centralizzata su chi interroga le loro API e da dove, soprattutto se non hanno configurato la registrazione degli eventi di controllo a livello di organizzazione.
La fase di ricognizione in sé non è distruttiva: non viene modificato alcun codice, non si ottiene alcun accesso e non si verifica alcuna esfiltrazione di dati in uscita. Gli strumenti SIEM standard configurati per gli indicatori di violazione non segnaleranno l'enumerazione sistematica delle API come anomala, soprattutto se le richieste provengono da account GitHub consolidati con una cronologia pregressa.
Rafforzare la sicurezza di GitHub come infrastruttura critica.
Per i team addetti all'infrastruttura e alla sicurezza, l'accesso a GitHub dovrebbe essere considerato un punto di controllo sensibile, non un servizio pubblico. Diverse misure pratiche riducono la superficie di ricognizione:
- Conservazione e revisione dei registri di controllo: Abilita la registrazione degli eventi di controllo a livello di organizzazione su GitHub e importa i log in un SIEM. Cerca modelli API insoliti, come l'enumerazione rapida dei repository, l'interrogazione sistematica dei membri del team o le richieste provenienti da origini geografiche inaspettate.
- Rotazione del token di accesso personale: È fondamentale garantire la rotazione regolare dei token di accesso personali e delle applicazioni OAuth. I token compromessi, con il passare del tempo, hanno maggiori probabilità di rimanere inattivi nelle mani di malintenzionati.
- Monitoraggio del limite di frequenza delle API: Configura avvisi personalizzati se l'utilizzo delle API da qualsiasi account o applicazione si avvicina ai limiti di frequenza della tua organizzazione, anche se i limiti non vengono effettivamente superati.
- Controlli di visibilità del repository: Riduci la superficie dei metadati esposta agli utenti anonimi o con privilegi limitati che chiamano le API. Valuta la possibilità di limitare l'accesso agli elenchi pubblici dei repository, se il tuo modello di minaccia lo giustifica.
- Politiche di protezione delle filiali e di revisione del codice: Anche un accesso riuscito al repository risulta meno utile se le modifiche al codice richiedono revisione e approvazione. Non si tratta di difesa a scopo di ricognizione, bensì di resilienza post-violazione.
Il quadro generale: la ricognizione come minaccia persistente
Le campagne di ricognizione come quelle documentate da Datadog vengono spesso condotte mesi prima di qualsiasi tentativo di sfruttamento. Rappresentano un metodo a basso rischio per gli avversari per identificare obiettivi di alto valore e comprenderne i flussi di lavoro di sviluppo. Per le organizzazioni che ospitano codice sensibile, sia in ambienti cloud privati, repository gestiti o infrastrutture offshore, è fondamentale considerare GitHub come un potenziale punto di osservazione.
L'utilizzo di account fantasma e token compromessi non è una pratica esclusiva di GitHub. Lo stesso schema si riscontra nelle attività di ricognizione contro piattaforme cloud, servizi DNS e altre API esposte dalle organizzazioni. La lezione da imparare è che qualsiasi API esposta per un utilizzo legittimo da parte degli sviluppatori espone anche informazioni a potenziali hacker. La difesa non consiste nel bloccare completamente l'accesso, ma nel monitorare la visibilità, stabilire parametri di riferimento per il comportamento normale e reagire quando tali parametri cambiano.
Analisi di Datadog Serve a ricordare che la sicurezza delle infrastrutture si estende oltre i firewall e la segmentazione di rete, coinvolgendo gli strumenti e i flussi di lavoro su cui gli sviluppatori fanno affidamento quotidianamente. Proteggere la catena di fornitura significa proteggere l'infrastruttura su cui il codice viene creato, revisionato e rilasciato.
