Il 5 gennaio 2016 abbiamo ha emesso una reimpostazione della password per tutti i clienti Linode durante la nostra indagine sull'accesso non autorizzato a tre account di clienti. Abbiamo collaborato con le autorità federali su queste questioni e le loro indagini penali sono in corso. Oggi condividiamo i nostri risultati e quelli della società di sicurezza di terze parti a cui ci siamo rivolti per assisterci in questa indagine.
Prima di entrare nel merito, vorremmo rassicurarvi che i dati del vostro conto sono al sicuro. Abbiamo trovato solo tre clienti interessati da questo incidente e abbiamo risolto i problemi direttamente con loro.
Cosa è successo
Si tratta di una complessa retrospettiva di due indagini distinte, una svolta a luglio e l'altra a dicembre. Sebbene i casi presentino delle analogie, non abbiamo prove che dimostrino che i due casi siano collegati. Tuttavia, ecco una cronologia completa degli eventi, così come li abbiamo compresi.
Il 9 luglio un cliente ci ha notificato un accesso non autorizzato al suo account Linode. Il cliente ha scoperto che un intruso aveva ottenuto l'accesso al suo account dopo aver ricevuto una notifica via e-mail che confermava la reimpostazione della password di root per uno dei suoi Linode. Le nostre indagini iniziali hanno mostrato che l'accesso non autorizzato è riuscito al primo tentativo e che assomigliava a un'attività normale.
Il 12 luglio, in previsione del coinvolgimento delle forze dell'ordine, il cliente ha presentato una richiesta di conservazione di un Linode corrispondente a un indirizzo IP ritenuto coinvolto nell'accesso non autorizzato. Abbiamo accolto la richiesta e abbiamo chiesto al cliente di fornirci qualsiasi prova aggiuntiva (ad esempio, file di registro) che confermasse che il Linode era la fonte dell'attività dannosa. Né il cliente né le forze dell'ordine hanno dato seguito alla richiesta e, poiché non esaminiamo i dati dei clienti senza una causa probabile, non abbiamo analizzato l'immagine conservata.
Lo stesso giorno, il cliente ha riferito che l'utente il cui account era stato violato aveva smarrito diverse settimane prima un dispositivo mobile contenente le credenziali 2FA necessarie per accedere all'account e ha spiegato che il proprietario aveva tentato di cancellare il dispositivo da remoto qualche tempo dopo. Inoltre, questo utente utilizzava una password debole. Alla luce di queste informazioni e in assenza di prove a sostegno del fatto che le credenziali fossero state ottenute da Linode, non abbiamo indagato ulteriormente.
Il 9 dicembre ci ha contattato un ricercatore di sicurezza indipendente. Il ricercatore affermava di essere sulle tracce di un individuo che aveva rubato credenziali da numerosi altri fornitori di servizi. Il ricercatore voleva informarci che l'individuo avrebbe potuto tentare di utilizzare queste credenziali rubate per accedere agli account di alcuni dei nostri clienti.
La nostra indagine iniziale ha concluso che gli IP forniti erano stati utilizzati per accedere a tre account al primo tentativo. In altre parole, l'utente è arrivato alla pagina di login di Linode Manager con le credenziali necessarie per accedere, come farebbe qualsiasi altro utente normale. Lo stesso giorno abbiamo contattato i clienti e abbiamo ricevuto da ciascuno la conferma che le attività erano sospette. Abbiamo anche confermato che nessuno di questi account aveva attivato l'autenticazione a più fattori e tutti avevano utilizzato password deboli.
Il 13 dicembre abbiamo iniziato la necessaria manutenzione di Xen Security Advisory (XSA) a livello di flotta, riavviando i server nelle ore notturne locali. Sebbene non sia correlata all'indagine, questa operazione è proseguita fino al 18 dicembre e ha rappresentato una significativa limitazione delle risorse.
Il 14 dicembre, nonostante non avessimo trovato alcuna prova di un'intrusione nella nostra infrastruttura, abbiamo iniziato a intervistare società di sicurezza terze e a contattare diverse forze dell'ordine. Abbiamo anche dedicato tutte le risorse interne disponibili a questo sforzo e abbiamo iniziato a esaminare il nostro ambiente per identificare qualsiasi prova di abuso o uso improprio.
Il 17 dicembre, a causa delle somiglianze tra questo caso e quello di luglio, abbiamo riaperto il caso di luglio e abbiamo concluso di avere motivi sufficienti per esaminare l'immagine conservata da quell'indagine.
Linode utilizza TOTP per fornire l'autenticazione a due fattori. Si tratta di un algoritmo che utilizza una chiave segreta memorizzata e condivisa tra il nostro server e l'applicazione di autenticazione a due fattori del cliente (come Google Authenticator). L'algoritmo genera un codice sensibile al tempo che l'utente fornisce durante il login come componente aggiuntivo di autenticazione. Le chiavi segrete vengono crittografate quando vengono memorizzate nel nostro database.
Dopo aver esaminato l'immagine della nostra indagine di luglio, abbiamo scoperto un software in grado di generare codici TOTP se viene fornita una chiave TOTP. Abbiamo trovato un software che implementa il metodo di decodifica che utilizziamo per proteggere le chiavi TOTP, insieme alla chiave segreta che utilizziamo per crittografarle. Abbiamo anche trovato comandi nella cronologia di bash che hanno generato con successo un codice una tantum. Sebbene le credenziali trovate non fossero correlate agli accessi non autorizzati a Linode Manager effettuati a dicembre, la scoperta di queste informazioni ha cambiato significativamente la gravità della nostra indagine.
Il 21 dicembre il nostro partner di sicurezza terzo si è unito all'indagine. Il team ha proceduto a un'analisi forense per identificare qualsiasi attività non autorizzata a livello di sistema che potesse consentire a un intruso di accedere alle credenziali dei clienti contenute nel nostro database. Il team ha anche cercato prove di un uso improprio dell'applicazione web che avrebbe potuto consentire un movimento laterale da un account Linode Manager a un altro. Inoltre, il team ha avviato una valutazione mirata delle vulnerabilità con l'obiettivo di identificare un possibile vettore di attacco per ottenere l'accesso al database Linode.
Il 25 dicembre sono iniziati gli attacchi DDoS contro la nostra infrastruttura. Sebbene non abbiamo alcuna prova che questi attacchi siano collegati agli incidenti di accesso non autorizzato, gli attacchi hanno reso necessario sottrarre risorse alle nostre indagini. Questo, unito all'assenza dei dipendenti per le vacanze, ha creato ulteriori problemi per i nostri team di supporto e operativi.
Il 5 gennaio il nostro partner per la sicurezza ha concluso l'indagine e abbiamo rilasciato il reset della password. Il nostro team di sicurezza interno ha continuato a esaminare la nostra infrastruttura nelle settimane successive e ha sviluppato un piano dettagliato per migliorare la nostra sicurezza generale.
Risultati
I risultati dell'indagine del nostro partner per la sicurezza hanno concluso che non c'erano prove di abuso o uso improprio dell'infrastruttura di Linode che avrebbero portato alla divulgazione delle credenziali dei clienti. Inoltre, la valutazione del partner di sicurezza della nostra infrastruttura e delle nostre applicazioni non ha prodotto un vettore che avrebbe fornito questo livello di accesso.
Il team di sicurezza di Linode ha scoperto una vulnerabilità nel gateway SSH di Lish che potrebbe essere stata utilizzata per ottenere le informazioni scoperte il 17 dicembre, anche se non abbiamo prove a sostegno di questa ipotesi. Abbiamo immediatamente risolto la vulnerabilità.
Altre teorie prese in considerazione per spiegare l'accesso non autorizzato includono una compromissione esterna, come l'utilizzo delle password deboli precedentemente menzionate con altri servizi online, o attacchi di phishing contro questi utenti.
Cosa stiamo facendo al riguardo
Stiamo utilizzando quanto appreso per apportare miglioramenti completi alla nostra infrastruttura, anche in aree non correlate all'incidente. Ecco alcuni degli obiettivi che abbiamo raggiunto:
Microservizio di autenticazione: Molte delle nostre applicazioni (come Linode Manager e Lish) eseguono l'autenticazione degli utenti. In precedenza, queste applicazioni svolgevano questa funzione accedendo alle informazioni sulle credenziali direttamente all'interno del nostro database ed eseguendo poi autonomamente i confronti. Abbiamo sviluppato un nuovo approccio che prevede un microservizio attentamente protetto e monitorato che mantiene la proprietà di tutte le credenziali dei clienti. Con questo metodo, quando un'applicazione richiede l'autenticazione dell'utente, il microservizio è in grado di convalidare le credenziali restituendo un semplice "sì" o "no". Le applicazioni non avranno accesso alle informazioni sulle credenziali. Infatti, i database che alimentano la nostra infrastruttura non conterranno affatto informazioni sulle credenziali quando il rollout di questo microservizio sarà completato. Inoltre, le password dei clienti, precedentemente memorizzate come hash SHA-256 salato con migliaia di cicli, saranno memorizzate utilizzando bcrypt e saranno aggiornate senza problemi a un successivo accesso.
Notifiche di Linode Manager: Lavoreremo per migliorare le notifiche che i nostri clienti ricevono sull'attività dei rispettivi account, compresi gli avvisi sui tentativi di accesso da nuovi indirizzi IP e sui login falliti.
Tokenizzazione CC: Sebbene la nostra indagine non abbia fornito alcuna prova di accesso ai dati della carta di credito, stiamo sfruttando la funzione di tokenizzazione del nostro processore di pagamento per eliminare il rischio associato alla memorizzazione dei dati della carta di credito.
Politiche: Abbiamo sviluppato diverse politiche derivate dal framework NIST su argomenti che vanno dal clean-desk agli standard per le password. Una nuova politica significativa è la creazione di "zone di sicurezza" per gli elementi sensibili dell'infrastruttura, come i nostri database e i server di autenticazione. I risultati di questi sforzi hanno ridotto notevolmente il numero di dipendenti che hanno accesso a sistemi e dati sensibili.
Assunzione: Oltre alle modifiche descritte in precedenza, stiamo assumendo un esperto di sicurezza di livello senior che si unirà alla nostra azienda e guiderà un team più ampio di ingegneri che si occuperanno a tempo pieno di sicurezza. Questo team non solo garantirà che stiamo seguendo le best practice attuali, ma amplierà anche le nostre politiche scritte, formalizzerà le nostre procedure di provisioning e garantirà fondamentalmente che le nostre politiche siano supportate da processi e responsabilità.
Un nuovo Linode API: La nostra più importante strategia a lungo termine è la riscrittura della nostra base di codice ColdFusion, che ci dà l'opportunità di ricominciare da capo e di applicare le lezioni apprese negli ultimi 13 anni. Per fare questo, abbiamo costruito un nuovo Linode API che è stateless, RESTful e implementato in Python. Ci abbiamo lavorato negli ultimi mesi e annunceremo un'alpha pubblica del nuovo Linode API nelle prossime settimane.
Linode Manager open-source: Questo nuovo API sarà la base per tutto ciò che verrà in futuro, compreso un Linode Manager open-source che sostituirà il manager attuale.
Guardare avanti
Riconosciamo di avere margini di miglioramento per quanto riguarda la comunicazione e la trasparenza. Nonostante gli XSA e gli attacchi DDoS persistenti per tutto il mese di dicembre, avremmo dovuto comunicare prima ai nostri clienti la natura e la portata degli attacchi DDoS e di questo incidente di sicurezza. Dire che all'epoca eravamo a corto di risorse è una valutazione corretta. Tuttavia, avremmo potuto fare di meglio e da allora abbiamo apportato modifiche procedurali per garantire che in futuro un membro del team venga nominato per eventi importanti come questi, per facilitare una comunicazione frequente e trasparente con i nostri clienti.
Siamo incredibilmente grati ai clienti che ci hanno sostenuto durante questi eventi. Abbiamo ascoltato i vostri consigli e sentito il sostegno che ci avete fornito negli ultimi mesi. Sappiate che continuiamo ad ascoltare e ad agire in base al vostro feedback.
Concludiamo dicendo che ci dispiace se vi abbiamo deluso. Apprezziamo la fiducia che ci avete accordato come fornitore di hosting e ci impegniamo a guadagnarcela ogni giorno. Ci auguriamo che i dettagli qui forniti chiariscano alcune informazioni errate e dimostrino la nostra volontà di affrontare le opportunità di miglioramento, di fare la cosa giusta e di aumentare la comunicazione e la trasparenza con voi, i nostri clienti.
Commenti (17)
*”…we are incredibly grateful for the customers who have supported us throughout these events… [we] felt the support you’ve provided over the past few months… We value the trust you’ve placed in us…”*
Nice sentiments, but words are cheap. You could have shown your appreciation by giving people some money off their bill for the period in question
If there is to be a new Linode Manager, please please PLEASE do not try and “modernize” or “streamline” the interface like Namecheap did. I like my utilitarian and functional Manager.
“We found software implementing the decryption method we use to secure TOTP keys, along with the secret key we use to encrypt them. We also found commands in the bash history that successfully generated a one-time code.”
How do you explain the presence of software using the decryption method you use to secure TOTP keys, along with the secret key you use to encrypt them?
There are always some bumps on the road, sometimes these are big and hard to pass thru, but I think that you’re on the right track.
Keep up the good work 🙂
The most significant take away for me is that Linode is becoming more transparent. Please continue down this path.
Good news for the new Linode manager, is there any ETA?
Long-term customer here. I appreciate all the effort made during the difficult time over the holidays. However, I have asked for 2FA by SMS rather than google authenticator (or in addition to), and was told it will not be happening. It seems that this breach could have been avoided at least in part if 2FA by SMS had been used. The user who lost his phone would have moved his phone number to his new phone as soon as it was replaced. The entire compromise of the TOTP algorithm would not have been possible. So my request, and recommendation still stands; give us 2FA by SMS if we want it.
I know how difficult these situations can be and wish you all the best in your continued growth and improvements. Unfortunately, I’ll be switching to another provider after reading this. I stuck around waiting for an explanation that I hoped would satisfy my concerns and this certainly doesn’t do that… There is reasonable evidence that your story regarding the cell phone is incorrect. In my opinion you should have had a senior security director years ago. Given the nature of the July incident, that image going unexamined is mind boggling and no explanation is given about how the 2FA crypto keys could have ended up on that system. It sounds entirely plausible your infrastructure got breached in July or earlier by a skilled attacker and the evidence is simply not there months later.
It sounds like you’re moving in the right direction, but those are some seriously poor decisions by those in charge and I’ve lost confidence that further mistakes won’t be made.
I like the current Linode manager. It’s simple and fast and clean. Please don’t change it too much. (Don’t go all Namecheap on us)
I’m a longtime Linode customer as well. After reading up on this latest incident I am seriously considering moving my infrastructure to another provider. I’ve been through a number of these cases with Linode and so far have been unaffected and given them the benefit of the doubt. I completely understand that threats are uncovered and exploited and that’s a risk you take with any provider. This isn’t about me taking a knee jerk reaction. I’m fully aware that other providers have been exploited as well but Linode have had multiple exploits and that is reason for concern.
In this post you state that you found software on a client’s VPS generating login credentials using a very private piece of your data and a piece of data that can be used to decrypt other customers data and you have no idea how it arrived on a clients machine and you don’t really seem bothered by that or at the very least you gloss over it. Have you audited every other instance to ensure they’re not also capable of generating keys/decrypting data? From my knowledge of this, the client in question was PagerDuty who alerted you after their own intrusion detection system picked up on the login. By your own account the initial illegal access looked like a legitimate login to your systems and didn’t raise any alarms. You also state that you don’t inspect customers instances without probable cause. So we have to assume that there might be other malicious software running in your infrastructure that you are not aware of and it’s allowing access that isn’t raising alerts.
You say that only three customers were accessed under suspicious circumstances. On that face of it that looks like a small number, considering you have a large client base. However, from what I can gather these were large and notable customers PagerDuty and WPEngine, I believe. That, to me sounds less like a percentage risk and more like plucking high value targets. I’m only a small customer so it’s probably more out of luck that I haven’t been affected rather than my details not actually being available.
Linode has offered a product that’s very valuable to me and my business. It’s provided reliable hosting and features. I chose them because I felt they would be able to support any application that I need to grow without the fuss of moving providers. I no longer have that confidence. The previous attack against Linode resulted in credit card loss and it’s only now that you are looking at tokenizing credit cards and moving to bcrypt for hashing?
I do appreciate that resources get stretched and trying to pick out relevant data and act on it is really difficult in a growing business. But the lack of security awareness at Linode has got to a point not where I feel I can’t trust it with my business which is sad because my experience with them has been positive, well if you put aside data breaches, credit card loss and their private keys ending up on clients’ VPSs and inability to communicate.
“We also found commands in the bash history that successfully generated a one-time code”
I don’t get how you saw this and the investigation concluded that “the security partner’s assessment of our infrastructure and applications did not yield a vector that would have provided this level of access.”
I mean, I don’t understand why someone have a bash on your systems, how he achieved that and what changed so he can’t do it in the future
Just FYI, I’ve been forced to spend considerable ongoing time and money investigating other services and finally choosing a viable non-Linode. This is money that could have been spent on better things, even if it had just been more Linode servers. Outside 3-4 work weeks redirected, my computing budget doubled even after whittling down my 4 Linodes to two.
You might consider joining forces with a cooperative and reputable industry counterpart in an effort to provide more viable business recovery scenarios for your mutual customers. In my case, now I have both a dedicated server vendor and Linode, a solution that is not neither pleasant nor economical. Each has complementary benefits.
I hope that your security efforts prove successful and I concur with the comments that should you change the inside workings of the Linode manager, it should remain simple and shun any feature that is only cosmetic.
I agree with the poster above that Linode appears to be going down a path of greater transparency. I’m extremely happy to see this.
I also believe that full disclosure and admitting fault where necessary is a very honorable thing, and you are to be commended for what you’ve said here.
Odd, all this transparency is making some people think there is a lack of security knowledge at Linode. Guys, you’d have this or worse at practically any other company.
Sounds like almost this entire thing boiled down to a few customers who have no clue about security to begin with. Weak passwords and a mobile device that doesn’t have a screen code to lock the phone. Sigh, sorry Linode had to go through all of that because of a few lazy people, but it does look like they’ve learned a lot and are improving and moving forward.
Kneejerk reacting will only put you with someone else, that probably isn’t doing the same thing as Linode.
Keep up the great works guys and I’m glad to see the improvements.
Well done, Linode!
If you are going to update the Linode Manager API, *please, please, please* give us the ability to do programmatic snapshots.
Thank you.
I greatly appreciate the explanation and transparency. So very different than other companies. This is the kind of thing that creates customer loyalty.