Le 5 janvier 2016, nous avons publié une réinitialisation de mot de passe pour tous les clients Linode dans le cadre de notre enquête sur l'accès non autorisé à trois comptes clients. Nous avons travaillé avec les autorités fédérales sur ces questions et leurs enquêtes criminelles sont en cours. Aujourd'hui, nous partageons nos conclusions et celles de la société de sécurité tierce que nous avons engagée pour nous aider dans cette enquête.
Avant d'entrer dans le vif du sujet, nous tenons à vous assurer que les informations relatives à votre compte sont en sécurité. Nous n'avons trouvé que trois clients affectés par cet incident et nous avons résolu ces problèmes avec eux directement.
Ce qui s'est passé
Il s'agit d'une rétrospective complexe de deux enquêtes distinctes, l'une menée en juillet et l'autre en décembre. Bien que les deux affaires présentent des similitudes, nous ne disposons d'aucune preuve permettant d'affirmer qu'elles sont liées. Néanmoins, voici une chronologie complète des événements tels que nous les comprenons.
Le 9 juillet, un client nous a informés d'un accès non autorisé à son compte Linode. Le client a appris qu'un intrus avait obtenu l'accès à son compte après avoir reçu une notification par courriel confirmant la réinitialisation du mot de passe racine pour l'un de ses Linodes. Notre enquête initiale a montré que la connexion non autorisée avait été réussie dès la première tentative et qu'elle ressemblait à une activité normale.
Le 12 juillet, en prévision de l'intervention des forces de l'ordre, le client a fait une demande de conservation d'un Linode correspondant à une adresse IP soupçonnée d'être impliquée dans l'accès non autorisé. Nous avons honoré la demande et demandé au client de nous fournir toute preuve supplémentaire (par exemple, des fichiers journaux) qui confirmerait que le Linode est la source de l'activité malveillante. Ni le client ni les forces de l'ordre n'ont donné suite et, comme nous n'examinons pas les données des clients sans motif valable, nous n'avons pas analysé l'image conservée.
Le même jour, le client a signalé que l'utilisateur dont le compte a été consulté avait perdu, plusieurs semaines auparavant, un appareil mobile contenant les informations d'identification 2FA nécessaires pour accéder au compte, et a expliqué que le propriétaire avait tenté d'effacer l'appareil à distance quelque temps plus tard. En outre, cet utilisateur utilisait un mot de passe faible. À la lumière de ces informations, et en l'absence de preuve que les identifiants ont été obtenus auprès de Linode, nous n'avons pas mené d'enquête plus approfondie.
Le 9 décembre, un chercheur en sécurité indépendant nous a contactés. Il affirmait suivre un individu qui avait volé des informations d'identification à de nombreux autres fournisseurs de services. Il souhaitait nous informer que l'individu avait peut-être tenté d'utiliser ces informations d'identification volées pour se connecter aux comptes de certains de nos clients.
Notre enquête initiale a conclu que les adresses IP fournies avaient en fait été utilisées pour se connecter à trois comptes lors de la première tentative. En d'autres termes, l'utilisateur est arrivé sur la page de connexion de Linode Manager avec les informations d'identification nécessaires pour se connecter, comme le ferait n'importe quel utilisateur normal. Le même jour, nous avons contacté les clients et avons reçu la confirmation de chacun d'entre eux que ces activités étaient suspectes. Nous avons également confirmé qu'aucun de ces comptes n'avait activé l'authentification multifactorielle et que tous avaient utilisé des mots de passe faibles.
Le 13 décembre, nous avons entamé la maintenance nécessaire de l'ensemble de la flotte Xen Security Advisory (XSA), en redémarrant les serveurs pendant les heures nocturnes locales, 24 heures sur 24. Bien que sans rapport avec l'enquête, cette opération s'est poursuivie jusqu'au 18 décembre et a constitué une contrainte importante en termes de ressources.
Le 14 décembre, bien que nous n'ayons découvert aucune preuve d'une intrusion dans notre infrastructure, nous avons commencé à interroger des sociétés de sécurité tierces et à contacter plusieurs organismes chargés de l'application de la loi. Nous avons également consacré toutes les ressources internes disponibles à cet effort et commencé à examiner minutieusement notre environnement afin d'identifier toute preuve d'abus ou de mauvaise utilisation.
Le 17 décembre, en raison des similitudes entre cette affaire et celle de juillet, nous avons rouvert le dossier de juillet et conclu que nous avions désormais suffisamment de raisons d'examiner l'image conservée lors de cette enquête.
Linode utilise TOTP pour fournir une authentification à deux facteurs. Il s'agit d'un algorithme qui utilise une clé secrète stockée sur notre serveur et partagée entre celui-ci et l'application d'authentification à deux facteurs du client (telle que Google Authenticator). L'algorithme génère un code sensible au temps que l'utilisateur fournit lors de la connexion en tant que composant d'authentification supplémentaire. Nous chiffrons ces clés secrètes lorsque nous les stockons dans notre base de données.
Après avoir examiné l'image de notre enquête de juillet, nous avons découvert un logiciel capable de générer des codes TOTP si on lui fournit une clé TOTP. Nous avons trouvé un logiciel mettant en œuvre la méthode de décryptage que nous utilisons pour sécuriser les clés TOTP, ainsi que la clé secrète que nous utilisons pour les crypter. Nous avons également trouvé des commandes dans l'historique de bash qui ont généré avec succès un code à usage unique. Bien que les informations d'identification trouvées n'aient aucun rapport avec les connexions non autorisées au Linode Manager effectuées en décembre, la découverte de ces informations a considérablement changé la gravité de notre enquête.
Le 21 décembre, notre partenaire de sécurité tiers s'est joint à l'enquête. Cette équipe a procédé à une analyse forensique afin d'identifier toute activité non autorisée au niveau du système qui aurait pu permettre à un intrus d'accéder aux informations d'identification des clients contenues dans notre base de données. L'équipe a également recherché des preuves d'utilisation abusive d'applications web qui auraient permis un déplacement latéral d'un compte Linode Manager à un autre. En outre, l'équipe a lancé une évaluation ciblée des vulnérabilités dans le but d'identifier un vecteur d'attaque possible pour obtenir l'accès à la base de données Linode.
Le 25 décembre les attaques DDoS contre notre infrastructure ont commencé. Bien que nous n'ayons aucune preuve que ces attaques soient liées aux incidents d'accès non autorisé, elles ont nécessité que des ressources soient retirées de notre enquête. Cette situation, combinée à l'absence des employés pour les fêtes, a créé des difficultés supplémentaires pour nos équipes de soutien et d'exploitation.
Le 5 janvier, notre partenaire en sécurité a conclu son enquête et nous avons procédé à la réinitialisation du mot de passe. Notre équipe de sécurité interne a continué à examiner notre infrastructure au cours des semaines suivantes et a élaboré un plan détaillé pour améliorer notre sécurité globale.
Résultats
Les résultats de l'enquête de notre partenaire en sécurité ont conclu qu'il n'y avait aucune preuve d'abus ou de mauvaise utilisation de l'infrastructure de Linode qui aurait pu entraîner la divulgation des informations d'identification des clients. En outre, l'évaluation de notre infrastructure et de nos applications par le partenaire en sécurité n'a pas révélé de vecteur qui aurait permis ce niveau d'accès.
L'équipe de sécurité de Linode a découvert une vulnérabilité dans la passerelle SSH de Lish qui aurait pu être utilisée pour obtenir des informations découvertes le 17 décembre, bien que nous n'ayons aucune preuve pour étayer cette supposition. Nous avons immédiatement corrigé cette vulnérabilité.
Les autres théories envisagées pour expliquer l'accès non autorisé comprennent une compromission externe, comme l'utilisation des mots de passe faibles mentionnés précédemment avec d'autres services en ligne, ou des attaques par hameçonnage contre ces utilisateurs.
Ce que nous faisons
Nous utilisons ce que nous avons appris pour apporter des améliorations globales à notre infrastructure, y compris dans des domaines qui ne sont pas liés à l'incident. Voici quelques-unes des mesures que nous avons prises :
Microservice d'authentification : Plusieurs de nos applications (telles que Linode Manager et Lish) effectuent l'authentification des utilisateurs. Auparavant, ces applications remplissaient cette fonction en ayant accès aux informations d'identification directement dans notre base de données, puis en effectuant elles-mêmes les comparaisons. Nous avons développé une nouvelle approche qui implique un microservice soigneusement sécurisé et surveillé qui conserve la propriété de toutes les informations d'identification des clients. Selon cette méthode, lorsqu'une application requiert l'authentification d'un utilisateur, le microservice est en mesure de valider les informations d'identification en renvoyant un simple "oui" ou "non". Les applications n'auront pas accès aux informations d'identification. En fait, les bases de données qui alimentent notre infrastructure ne contiendront plus du tout d'informations d'identification lorsque le déploiement de ce microservice sera terminé. De même, les mots de passe des clients, précédemment stockés sous forme de hachages SHA-256 salés avec des milliers de tours, seront stockés à l'aide de bcrypt et seront mis à niveau de manière transparente lors d'une connexion ultérieure.
Notifications du Linode Manager : Nous nous efforcerons d'améliorer les notifications que nos clients reçoivent sur l'activité de leurs comptes respectifs, y compris les alertes sur les tentatives de connexion à partir de nouvelles adresses IP et les échecs de connexion.
Tokenisation de la carte de crédit : Bien que notre enquête n'ait révélé aucune preuve d'accès aux informations relatives aux cartes de crédit, nous tirons parti de la fonction de symbolisation de notre processeur de paiement pour éliminer le risque associé au stockage des informations relatives aux cartes de crédit.
Politique : Nous avons développé de nombreuses politiques dérivées du cadre NIST sur des sujets allant du bureau propre aux normes de mot de passe. Une nouvelle politique importante est la création de "zones de sécurité" pour les éléments sensibles de l'infrastructure, comme notre base de données et nos serveurs d'authentification. Ces efforts ont permis de réduire considérablement le nombre d'employés ayant accès à des systèmes et à des données sensibles.
Embauche : En plus des changements décrits ci-dessus, nous allons recrutons un expert en sécurité de haut niveau pour rejoindre notre société et diriger une équipe plus importante d'ingénieurs qui se consacrent à plein temps à la sécurité. Cette équipe veillera non seulement à ce que nous suivions les meilleures pratiques actuelles, mais aussi à développer nos politiques écrites, à formaliser nos procédures d'approvisionnement et à garantir fondamentalement que nos politiques sont soutenues par des processus et des responsabilités.
Un nouveau Linode API: Notre stratégie à long terme la plus importante est la réécriture de notre base de code ColdFusion, qui nous permet de prendre un nouveau départ et d'appliquer les leçons que nous avons apprises au cours des 13 dernières années. Pour ce faire, nous avons construit un nouveau Linode API qui est sans état, RESTful, et implémenté dans Python. Nous avons travaillé sur ce projet au cours des derniers mois et nous annoncerons une version alpha publique du nouveau Linode dans les prochaines semaines. API dans les prochaines semaines.
Linode Manager open-source : Ce nouveau API sera la base de toutes les choses à venir, y compris un Linode Manager open-source qui remplacera le manager actuel.
Perspectives d'avenir
Nous reconnaissons que nous pouvons encore nous améliorer en matière de communication et de transparence. Malgré les XSA et les attaques DDoS persistantes tout au long du mois de décembre, nous aurions dû communiquer plus tôt à nos clients la nature et l'ampleur des attaques DDoS et de cet incident de sécurité. Il serait juste de dire que nous étions limités en ressources à ce moment-là. Néanmoins, nous aurions pu faire mieux et nous avons depuis modifié nos procédures pour nous assurer qu'un membre de l'équipe soit désigné à l'avenir pour des événements importants comme celui-ci, afin de faciliter une communication fréquente et transparente avec nos clients.
Nous sommes incroyablement reconnaissants aux clients qui nous ont soutenus tout au long de ces événements. Nous avons entendu vos recommandations et ressenti le soutien que vous nous avez apporté au cours des derniers mois. Sachez que nous restons à l'écoute et que nous tenons compte de vos commentaires.
Nous conclurons en vous disant que nous sommes désolés de vous avoir déçu. Nous apprécions la confiance que vous nous avez accordée en tant que fournisseur d'hébergement et nous nous engageons à la mériter chaque jour. Nous espérons que les détails fournis ici clarifient certaines informations erronées et démontrent notre volonté d'aborder les opportunités d'amélioration, de faire ce qu'il faut et d'améliorer la communication et la transparence avec vous, nos clients.
Commentaires (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.