Martedì 5 maggio GoDaddy ha comunicato di essere rimasta vittima di un data breach che ha compromesso le credenziali di accesso degli account di circa 28.000 clienti. La notifica della violazione (Breach Notification) a firma del CISO e VP di GoDaddy Demetrius Comes è stata fatta all’ufficio del Procuratore Generale della California.
La società ha rivelato che l’attività sospetta si è verificata su alcuni dei suoi server il 19 ottobre 2019, ma la scoperta è avvenuta il 23 aprile 2020 quando GoDaddy ha rilevato che un individuo non autorizzato aveva ottenuto l’accesso alle credenziali di accesso (username e password) di circa 28.000 clienti che utilizzano il protocollo crittografico SSH (Secure SHell) per connettersi ai loro account di web hosting.
In una nota ufficiale, GoDaddy ha dichiarato che solo i nomi utente e le password utilizzate per accedere ai server ospitati in remoto sono stati compromessi e che “l’attore della minaccia non aveva accesso ai principali account GoDaddy dei clienti“. Ha aggiunto, inoltre, di avere immediatamente reimpostato i nomi utente e le password e che al momento non c’è alcuna evidenza in merito alla possibilità che l’intruso abbia utilizzato le credenziali dei clienti o che abbia modificato i loro account di hosting.
Inoltre, si è resa disponibile a fornire gratuitamente ai clienti coinvolti un abbonamento annuale al suo servizio di sicurezza del sito web e di rimozione del malware.
Indice degli argomenti
Cosa potrebbe essere accaduto
GoDaddy non ha rivelato l’esatta causa della violazione dei dati, ma è interessante quanto segnalato il 31 marzo scorso dal noto sito KrebsOnSecurity: un rappresentante del servizio clienti di GoDaddy è stato vittima di un attacco di social engineering, realizzato con un’e-mail di spear phishing.
L’azione ha permesso all’attaccante di visualizzare e accedere ai record di alcuni clienti. L’accesso è stato utilizzato per modificare le impostazioni del dominio per una mezza dozzina di clienti GoDaddy, compreso il sito di intermediazione delle transazioni escrow.com. Durante l’incidente, per poche ore, gli hacker hanno modificato (“hijacked”) i record DNS di Escrow.com per reindirizzare gli utenti su un sito web diverso (puntavano a un indirizzo Internet in Malesia: 111.90.149[.]49).
Matt Barrie, CEO di Freelancer.com, l’azienda che controlla escrow.com ha dichiarato che nessun sistema di Escrow.com è stato compromesso e che non sono stati violati i dati dei clienti.
Non è neppure chiaro se l’incidente denunciato da GoDaddy sia stato causato dal riutilizzo di credenziali precedentemente rubate (se ne trovano a miliardi nel Dark Web, venduta a pochi dollari) o da attacchi di tipo brute force (meno probabile).
Anche sulla base della segnalazione di KrebsOnSecurity, si può ritenere che comunque l’attacco sia stato reso possibile – come quasi sempre – da un errore umano, che ha permesso l’intrusione nei server dell’azienda e il furto di dati.
In ogni caso, qualsiasi accesso non autorizzato tramite gli account SSH non sarebbe potuto avvenire se GoDaddy avesse utilizzato l’autenticazione a due fattori (MFA) o la gestione degli accessi privilegiati (PAM) per gli account di accesso remoto.
Per questo – e questa vicenda ce lo insegna per l’ennesima volta – è importante mettere in pratica misure di “hardening” dei sistemi, sia da parte di GoDaddy che dei suoi clienti. Misure che sono, per esempio:
- utilizzare l’autenticazione a due fattori, sia per SSH che per l’accesso al backend dei siti;
- password management: utilizzare password forti ed univoche e gestirle con password manager;
- rafforzare la sicurezza degli account dei domini esistenti con le società di registrazione, attivando sistemi di notifica sicuri quando e se un dominio sta per scadere (questo per evitare attacchi di phishing, molto usati in queste circostanze);
- utilizzare le funzioni di registrazione come Registry (o Registrar) Lock che possono aiutare a proteggere i record dei nomi di dominio dalla modifica (Domain Hijacking). Questa misura può impedire il trasferimento fraudolento di un dominio da un registrar ad un altro, con la perdita del dominio da parte del legittimo proprietario;
- implementare il protocollo DNSSEC (Domain Name System Security Extensions) per evitare gli attacchi di “cache poisoning” che mirano ad alterare il contenuto della cache dei server DNS. Con DNSSEC viene certificato in maniera inoppugnabile che il sito web che si sta visitando è proprio quello che dichiara di essere. Non tutti i TLD (Top Level Domain) supportano DNSSEC, ma – ove disponibile – questa è un’opzione migliore dei soli certificati SSL (quelli che hanno i siti HTTPS) perché non è raro vedere certificati falsi.
Cos’è SSH e a cosa serve
SSH è l’acronimo di Secure SHell (ovvero shell sicura). Si tratta di un protocollo che permette di stabilire una connessione client-server cifrata (quindi sicura) con un host remoto attraverso un canale aperto e insicuro come, per esempio, la rete internet. In pratica la shell, in quanto interprete dei comandi, permette di inviare comandi in remoto da un sistema ad un altro e di operare su più sistemi contemporaneamente da un unico terminale in modo sicuro.
SSH è stato creato da Tatu Ylonen e rilasciato nella versione SSH 1.0 nel 1995. Opera sulla porta standard 22, assegnata allora da IANA (Internet Assigned Numbers Authority), essendo le porte 21 e 23 già dedicate rispettivamente a FTP e telnet.
Oggi SSH è diventato uno standard utilizzato su praticamente tutti i sistemi operativi UNIX, Linux, macOS e Microsoft Windows, soppiantando l’ormai desueto e insicuro “telnet”. E come telnet ha un interfaccia a riga di comando.
Come detto, SSH è cifrato: usa la crittografia asimmetrica con l’algoritmo di scambio delle chiavi Diffie-Hellman che serve per l’autenticazione a chiave pubblica. Una volta eseguito lo scambio delle chiavi, la comunicazione cifrata tra client e server utilizza algoritmi di crittografia simmetrica (computazionalmente meno onerosi di quelli asimmetrici).
Quindi SSH offre un modo sicuro – se configurato correttamente – per lavorare con sistemi remoti e trasferire file in rete.
In una società come GoDaddy, SSH viene utilizzato dai clienti per connettersi ai loro account di hosting per caricare o spostare file ed eseguire comandi.
Con queste premesse, possiamo supporre che l’incidente accaduto a GoDaddy non sia imputabile a vulnerabilità del protocollo SSH.
Quali potrebbero essere i rischi per i clienti GoDaddy
Le credenziali del database compromesse potrebbero essere utilizzate per ottenere il controllo di un sito, se le connessioni remote del database sono abilitate, cosa che GoDaddy permette su molti dei suoi account di hosting. Potrebbe essere accaduto, fino alla scoperta del data breach, ma GoDaddy ha forzato la modifica delle credenziali violate, per cui questo rischio è ora superato.
Non è noto – e probabilmente non lo sarà mai – quali e quanti altri dati sia riuscito ad esfiltrare l’attaccante nel tempo in cui ha avuto accesso agli account violati e se questi dati sono finiti nel mercato nero del Dark Web.
Di una cosa possiamo essere ragionevolmente certi: questo genere di violazioni, ancorché non riescano a causare danni maggiori, possono essere utilizzate per campagne di spear phishing, mirato in questo caso ai clienti di GoDaddy.
Il phishing è un attacco in cui un aggressore crea un’e-mail che sembra provenire da una fonte legittima, ma che ha lo scopo di ottenere informazioni sensibili da un utente ignaro. Anche se solo 28.000 account di hosting sembrano essere stati colpiti, sono milioni (oltre 78 milioni, come dichiarato dall’azienda) i siti ospitati da GoDaddy.
Ciò significa che ci sono milioni di clienti che potrebbero ricevere un’e-mail con una notifica di violazione del loro account di hosting. E questa e-mail potrebbe essere costruita appositamente per risultare inviata da GoDaddy.
