GitHub, GitLab e Bitbucket sotto attacco, ora sensibilizzano sulle password

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?

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.

6 risposte a “GitHub, GitLab e Bitbucket sotto attacco, ora sensibilizzano sulle password”

  1. Avatar Guglielmo Cancelli
    Guglielmo Cancelli

    Io nel mio piccolo sono passato da dropbox a mega.nz, lentissimo come la morte quando accedi dal browser, ma (in teoria) completamente criptato.

  2. Avatar Guglielmo Cancelli
    Guglielmo Cancelli

    Per questo ho scritto “nel mio piccolo”.
    Dropbox e mega li uso per condividere il codice delle mie applicazioni tra vari pc. Se avessi un team piu grande avrei usato git, che ha anche molte funzioni specifiche per gli sviluppatori.
    Sono tutti servizi che servono per tenere i tuoi dati in cloud. Cambiano solo le funzionalità aggiuntive che ci girano intorno.

  3. Avatar Guglielmo Cancelli
    Guglielmo Cancelli

    Infatti. Il rovescio della medaglia è che (almeno nel mio caso) quando inizi ad avere parecchi file, aprire l’interfaccia web diventa un incubo. 4GB di memoria utilizzati e cpu al 100% per svariate decine di minuti. Poi, se intanto il browser non ha mandato in timeout la pagina, puoi utilizzarno normalmente. Perde molto tempo nella fase di decriptazione dei dati del profilo.
    Comunque io ho un vecchio account con 50GB gratuiti, uso prevalentemente il client desktop, per cui non mi lamento più di tanto.

  4. Avatar JustATiredMan
    JustATiredMan

    Dal punto di cifratura, meglio Mega.
    La chiave è gestita a livello client (non a livello di comunicazione) e quindi sui loro server i dati sono salvati già cifrati e illegibili pure da loro.
    E’ questa la ragione per cui se su Mega perdi la password son cavoli e i dati non sono recuperabili.

  5. Avatar JustATiredMan
    JustATiredMan

    Mi pare che da poco ci sia anche un client desktop… hai provato a vedere se va meglio con quello ?
    mega .nz/sync

  6. Avatar Guglielmo Cancelli
    Guglielmo Cancelli

    E’ l’ultima frase della mia precedente risposta: “Comunque io ho un vecchio account con 50GB gratuiti, uso prevalentemente il client desktop, per cui non mi lamento più di tanto.”

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *