Ad inizio del mese i maggiori fornitori pubblici di repository git hanno scoperto un attacco di tipo ransom su parecchi repository erogati delle loro piattaforme.

Il 2 Maggio diversi account utenti sono stati compromessi, i relativi repository (sia pubblici che privati) sono stati quindi svuotati e rimpiazzati con un singolo file contente il testo:

To recover your lost data and avoid leaking it: Send us 0.1 Bitcoin (BTC) to our Bitcoin address 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA and contact us by Email at admin@gitsbackup.com with your Git login and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your code is downloaded and backed up on our servers. If we dont receive your payment in the next 10 Days, we will make your code public or use them otherwise.

Per ripristinare i tuoi dati persi ed evitare la loro pubblicazione: inviaci 0.1 Bitcoin (BTC) al nostro indirizzo bitcoin 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA e contattaci inviando una email a admin@gitsbackup.com con la tua login Git e la prova del pagamento. Se non sei sicuro che noi abbiamo i tuoi dati, contattaci e ti manderemo una prova. Il tuo codice è stato scaricato e salvato sui nostri server. Se non riceveremo il tuo pagamento nei prossimi 10 giorni, renderemo il tuo codice pubblico o lo useremo in altro modo

Da un’indagine immediata dei team di sicurezza delle tre aziende si è scoperto che gli account sono stati compromessi usando credenziali legittime come password, password delle applicazioni, chiavi per le API e token di accesso personale e, successivamente, sono stati utilizzate delle git push per rimuovere i dati, caricare il file e svuotare lo storico del repository. Gli account sono quindi stati bloccati o disattivati in via preventiva.

Inoltre è stato scoperto, dallo stesso provider da cui ha avuto origine l’attacco, un salvataggio di credenziali di terze parti che interessava circa un terzo degli account violati; anche in questo caso, GitLab, GitHub e Bitbucket hanno provveduto ad invalidare le credenziali.

Infine hanno scoperto (l’ultima evidenza è del 10 Maggio) sui loro sistemi uno scan costante dei file .git/config (ed altri file comuni dei repository git) da parte dello stesso IP, probabilmente alla ricerca di dati sensibili o token erroneamente salvati su questi file.

Insomma, un attacco in piena regola ed, effettivamente, un attacco che per avere origine necessità di avere accesso a file/sistemi che comunemente devono essere accessibili a chiunque (soprattutto se parliamo di repository pubblici).

Le tre società continuano a lavorare all’identificazione degli attacchi, ma alla fine c’è poco che possono fare per prevenirli (a meno di identificare, come in questo caso, un chiaro IP che li sta portando); per questo motivo sono state pubblicate delle linee guida da seguire per evitare di essere vittima di questi tentativi.

Di cosa si tratta? Nulla di diverso da quanto viene normalmente consigliato:

• Abilitare l’autenticazione a più fattori sulla piattaforma scelta (Bitbucket, GitHub o GitLab);
• Utilizzare password complesse ed univoche (davvero, non usate la stessa password ovunque)
• Trattare i token, utilizzati per semplificare il processo di autenticazione su questi sistemi, alla stregua di password e, se proprio dovete inserirli in chiaro nel config per non dover costantemente inserire la password, almeno non caricarli su repository pubblici

E’ stata inoltre pubblicata una guida per rirpristinare il proprio repository nel caso si fosse stati vittima dell’attacco. Trovate tutti i dettagli nel post sul blog di GitHub.

Quello che però si evidenzia in tutto questo discorso è un aspetto positivo ed uno negativo legati al sistema git ed ai suoi “fornitori”; sicuramente l’avere un sistema singolo e ben standardizzato così tanto utilizzato da chiunque rende quel sistema più interessante per eventuali attaccanti: trovi la vulnerabilità una volta ed hai uno spettro di vittime estremamente ampio; comportamenti simili li abbiamo già visti in passato verso i sistemi Windows che, proprio grazie al loro esteso utilizzo, finivano per essere bersagliati molto più spesso di altri OS concorrenti.

La nota positiva, invece, è di come queste aziende pur essendo concorrenti l’una con l’altra, siano disposte a collaborare per risolvere un problema comune. E’ la prova che l’ideologia open source non si applica al solo codice e che, la condivisione di informazioni -di qualunque natura siano- porta a benefici per tutti.

Voi siete stati colpiti? Cosa pensate di come la situazione è stata gestita da questi big?

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.