Zum Inhalt springen
BlogLinodeRetrospektive Sicherheitsuntersuchung

Sicherheitsuntersuchung Retrospektive

blog-generic-triangles

Am 5. Januar 2016 haben wir ein Passwort-Reset ausgegeben für alle Linode-Kunden während unserer Untersuchung des unautorisierten Zugriffs auf drei Kundenkonten. Wir haben in dieser Angelegenheit mit Bundesbehörden zusammengearbeitet, deren strafrechtliche Ermittlungen noch andauern. Heute teilen wir unsere Ergebnisse und die der externen Sicherheitsfirma mit, die wir beauftragt haben, uns bei dieser Untersuchung zu unterstützen.

Bevor wir uns näher damit befassen, möchten wir Ihnen versichern, dass Ihre Kontoinformationen sicher sind. Wir haben nur drei Kunden gefunden, die von diesem Vorfall betroffen waren und haben diese Probleme direkt mit ihnen gelöst.

Was geschah

Dies ist ein komplexer Rückblick auf zwei separate Untersuchungen, eine im Juli und eine im Dezember. Obwohl die Fälle Ähnlichkeiten aufweisen, haben wir keine Beweise dafür, dass die beiden Fälle zusammenhängen. Nichtsdestotrotz ist hier eine vollständige Zeitleiste der Ereignisse, so wie wir sie verstanden haben.

Am 9. Juli informierte uns ein Kunde über einen unbefugten Zugriff auf sein Linode-Konto. Der Kunde erfuhr, dass sich ein Eindringling Zugang zu seinem Konto verschafft hatte, nachdem er eine E-Mail-Benachrichtigung erhalten hatte, in der ein Root-Passwort-Reset für eines seiner Linodes bestätigt wurde. Unsere anfängliche Untersuchung ergab, dass der unautorisierte Login beim ersten Versuch erfolgreich war und einer normalen Aktivität ähnelte.

Am 12. Juli, in Erwartung der Einschaltung der Strafverfolgungsbehörden, folgte der Kunde mit einer Anfrage zur Aufbewahrung einer Linode, die einer IP-Adresse entspricht, von der angenommen wird, dass sie an dem unberechtigten Zugriff beteiligt ist. Wir kamen der Anfrage nach und baten den Kunden, uns zusätzliche Beweise (z. B. Logdateien) zur Verfügung zu stellen, die belegen, dass die Linode die Quelle der böswilligen Aktivitäten war. Weder der Kunde noch die Strafverfolgungsbehörden folgten dieser Aufforderung, und da wir Kundendaten nicht ohne begründeten Verdacht untersuchen, haben wir das erhaltene Image nicht analysiert.

Am selben Tag berichtete der Kunde, dass der Benutzer, auf dessen Konto zugegriffen wurde, einige Wochen zuvor ein mobiles Gerät verloren hatte, das die für den Zugriff auf das Konto erforderlichen 2FA-Anmeldeinformationen enthielt, und erklärte, dass der Besitzer einige Zeit später versucht hatte, das Gerät aus der Ferne zu löschen. Außerdem verwendete dieser Benutzer ein schwaches Passwort. In Anbetracht dieser Informationen und ohne Beweise dafür, dass die Zugangsdaten von Linode stammen, haben wir keine weiteren Nachforschungen angestellt.

Am 9. Dezember nahm ein unabhängiger Sicherheitsforscher Kontakt mit uns auf. Der Forscher behauptete, eine Person zu verfolgen, die Anmeldedaten von zahlreichen anderen Dienstanbietern gestohlen hatte. Der Forscher wollte uns darauf aufmerksam machen, dass die Person möglicherweise versucht hat, sich mit diesen gestohlenen Anmeldedaten bei einigen unserer Kundenkonten anzumelden.

Unsere erste Untersuchung ergab, dass die angegebenen IPs tatsächlich dazu verwendet wurden, sich beim ersten Versuch in drei Konten einzuloggen. Mit anderen Worten, der Benutzer kam auf der Linode Manager Login-Seite mit den erforderlichen Anmeldedaten an, so wie es jeder normale Benutzer tun würde. Am selben Tag kontaktierten wir die Kunden und erhielten von jedem die Bestätigung, dass die Aktivitäten verdächtig waren. Wir bestätigten auch, dass bei keinem dieser Konten die Multi-Faktor-Authentifizierung aktiviert war und alle schwache Passwörter verwendet hatten.

Am 13. Dezember begannen wir mit der notwendigen flottenweiten Xen Security Advisory (XSA)-Wartung, bei der die Server in ihren lokalen Nachtstunden rund um die Uhr neu gestartet wurden. Obwohl dies nichts mit der Untersuchung zu tun hatte, dauerte es bis zum 18. Dezember und stellte eine erhebliche Ressourceneinschränkung dar.

Am 14. Dezember, obwohl wir keine Beweise für ein Eindringen in unsere Infrastruktur gefunden hatten, begannen wir mit der Befragung von externen Sicherheitsfirmen und kontaktierten mehrere Strafverfolgungsbehörden. Wir setzten auch alle verfügbaren internen Ressourcen ein und begannen, unsere Umgebung auf Anzeichen von Missbrauch zu untersuchen.

Am 17. Dezember haben wir aufgrund der Ähnlichkeiten zwischen diesem Fall und dem vom Juli den Fall vom Juli wieder aufgerollt und sind zu dem Schluss gekommen, dass wir nun genügend Grund haben, das von dieser Untersuchung zurückbehaltene Bild zu untersuchen.

Linode verwendet TOTP um eine Zwei-Faktor-Authentifizierung zu ermöglichen. Dies ist ein Algorithmus, der einen geheimen Schlüssel verwendet, der auf unserem Server gespeichert ist und zwischen ihm und der Zwei-Faktor-Authentifizierungs-App des Kunden (wie Google Authenticator) geteilt wird. Der Algorithmus generiert einen zeitkritischen Code, den der Benutzer bei der Anmeldung als zusätzliche Authentifizierungskomponente angibt. Wir verschlüsseln diese geheimen Schlüssel, wenn wir sie in unserer Datenbank speichern.

Nach der Untersuchung des Bildes aus unserer Untersuchung im Juli entdeckten wir Software, die in der Lage ist, TOTP-Codes zu generieren, wenn ein TOTP-Schlüssel bereitgestellt wird. Wir fanden Software, die die Entschlüsselungsmethode implementiert, die wir zur Sicherung von TOTP-Schlüsseln verwenden, zusammen mit dem geheimen Schlüssel, mit dem wir sie verschlüsseln. Wir fanden auch Befehle in der bash -Historie, die erfolgreich einen einmaligen Code generierten. Obwohl die gefundenen Anmeldedaten in keinem Zusammenhang mit den unautorisierten Linode Manager-Anmeldungen im Dezember standen, hat die Entdeckung dieser Informationen die Ernsthaftigkeit unserer Untersuchung erheblich verändert.

Am 21. Dezember schaltete sich unser externer Sicherheitspartner in die Untersuchung ein. Dieses Team fuhr mit einer forensischen Analyse fort, um jegliche unautorisierte Aktivität auf Systemebene zu identifizieren, die es einem Eindringling ermöglicht haben könnte, auf die in unserer Datenbank enthaltenen Kundenanmeldedaten zuzugreifen. Das Team suchte auch nach Beweisen für den Missbrauch von Webanwendungen, die eine seitliche Bewegung von einem Linode Manager-Konto zu einem anderen ermöglicht hätten. Zusätzlich initiierte das Team eine gezielte Schwachstellenanalyse mit dem Ziel, einen möglichen Angriffsvektor zu identifizieren, um Zugriff auf die Linode-Datenbank zu erhalten.

Am 25. Dezember begannen DDoS-Attacken gegen unsere Infrastruktur. Obwohl wir keine Beweise dafür haben, dass diese Angriffe mit den Vorfällen von unautorisiertem Zugriff in Verbindung stehen, mussten aufgrund der Angriffe Ressourcen von unserer Untersuchung abgezogen werden. Dies und die Abwesenheit der Mitarbeiter über die Feiertage stellten unsere Support- und Betriebsteams vor zusätzliche Herausforderungen.

Am 5. Januar schloss unser Sicherheitspartner seine Untersuchung ab und wir setzten das Passwort zurück. Unser internes Sicherheitsteam setzte die Überprüfung unserer Infrastruktur in den nächsten Wochen fort und entwickelte einen detaillierten Plan zur Verbesserung unserer Gesamtsicherheit.

Befunde

Die Ergebnisse der Untersuchung unseres Sicherheitspartners ergaben, dass es keine Beweise für einen Missbrauch oder eine missbräuchliche Nutzung der Linode-Infrastruktur gab, die zur Offenlegung von Kundenanmeldedaten geführt hätten. Darüber hinaus ergab die Bewertung unserer Infrastruktur und Anwendungen durch den Sicherheitspartner keinen Vektor, der ein solches Maß an Zugriff ermöglicht hätte.

Das Sicherheitsteam von Linode hat eine Schwachstelle im SSH-Gateway von Lish entdeckt, die möglicherweise genutzt werden könnte, um die am 17. Dezember entdeckten Informationen zu erhalten, obwohl wir keine Beweise für diese Vermutung haben. Wir haben die Sicherheitslücke sofort behoben.

Andere in Betracht gezogene Theorien, die den unbefugten Zugriff erklären könnten, beinhalten eine externe Kompromittierung, wie z. B. die bereits erwähnten schwachen Passwörter, die bei anderen Online-Diensten verwendet wurden, oder Phishing-Angriffe gegen diese Benutzer.

Was wir dagegen tun

Wir nutzen die gewonnenen Erkenntnisse, um unsere Infrastruktur umfassend zu verbessern, auch in Bereichen, die nichts mit dem Vorfall zu tun haben. Hier sind einige der Dinge, auf die wir hingearbeitet haben:

Microservice zur Authentifizierung: Mehrere unserer Anwendungen (z. B. der Linode Manager und Lish) führen eine Benutzerauthentifizierung durch. Bisher haben diese Anwendungen diese Funktion ausgeführt, indem sie Zugriff auf die Anmeldeinformationen direkt in unserer Datenbank hatten und dann selbst Vergleiche durchführten. Wir haben einen neuen Ansatz entwickelt, der einen sorgfältig gesicherten und überwachten Microservice beinhaltet, der den Besitz aller Kundenanmeldeinformationen verwaltet. Wenn eine Anwendung eine Benutzerauthentifizierung erfordert, kann der Microservice bei dieser Methode die Anmeldedaten validieren, indem er ein einfaches "Ja" oder "Nein" zurückgibt. Die Anwendungen haben keinen Zugriff auf die Anmeldeinformationen. Tatsächlich werden die Datenbanken, die unsere Infrastruktur versorgen, überhaupt keine Anmeldeinformationen enthalten, wenn der Rollout dieses Microservices abgeschlossen ist. Auch die Kundenpasswörter, die bisher als gesalzene SHA-256-Hashes mit Tausenden von Runden gespeichert wurden, werden mit bcrypt gespeichert und bei einem späteren Login nahtlos aktualisiert.

Linode Manager-Benachrichtigungen: Wir werden daran arbeiten, die Benachrichtigungen zu verbessern, die unsere Kunden über ihre jeweiligen Kontoaktivitäten erhalten, einschließlich Warnungen zu Anmeldeversuchen von neuen IP-Adressen und fehlgeschlagenen Anmeldungen.

CC-Tokenisierung: Obwohl unsere Untersuchung keine Beweise für einen Zugriff auf Kreditkarteninformationen ergeben hat, nutzen wir die Tokenisierungsfunktion unseres Zahlungsabwicklers, um das mit der Speicherung von Kreditkarteninformationen verbundene Risiko zu beseitigen.

Richtlinien: Wir haben mehrere Richtlinien entwickelt, die aus dem NIST-Framework abgeleitet sind, und zwar zu Themen, die von Clean-Desk bis zu Passwortstandards reichen. Eine wichtige neue Richtlinie ist die Einrichtung von "Sicherheitszonen" für sensible Infrastrukturelemente, wie unsere Datenbank- und Authentifizierungsserver. Die Ergebnisse dieser Bemühungen haben die Anzahl der Mitarbeiter, die Zugang zu sensiblen Systemen und Daten haben, stark reduziert.

Einstellen: Zusätzlich zu den oben beschriebenen Änderungen werden wir einen Senior-Level-Sicherheitsexperten ein der in unser Unternehmen eintritt und ein größeres Team von Ingenieuren leitet, das sich ganz auf die Sicherheit konzentriert. Dieses Team wird nicht nur sicherstellen, dass wir die aktuellen Best Practices befolgen, sondern auch unsere schriftlichen Richtlinien erweitern, unsere Bereitstellungsverfahren formalisieren und grundsätzlich sicherstellen, dass unsere Richtlinien durch Prozesse und Verantwortlichkeit unterstützt werden.

Ein neues Linode-API: Unsere wichtigste langfristige Strategie ist eine Neuschreibung unserer alten ColdFusion-Codebasis, die uns die Möglichkeit für einen Neuanfang und die Anwendung der Lektionen gibt, die wir in den letzten 13 Jahren gelernt haben. Um dies zu tun, haben wir ein neues Linode-API gebaut, das zustandslos, RESTful und in Python implementiert ist. Wir haben in den letzten Monaten daran gearbeitet und werden in den nächsten Wochen eine öffentliche Alpha-Version des neuen API ankündigen.

Open-Source Linode Manager: Diese neue API wird die Grundlage für alles sein, was in Zukunft kommt, einschließlich eines Open-Source-Linode-Managers, der den aktuellen Manager ersetzen wird.

Blick in die Zukunft

Wir erkennen an, dass wir in Sachen Kommunikation und Transparenz noch Verbesserungspotenzial haben. Ungeachtet der XSAs und der anhaltenden DDoS-Angriffe im Dezember hätten wir Art und Umfang der DDoS-Angriffe und dieses Sicherheitsvorfalls früher an unsere Kunden kommunizieren müssen. Zu sagen, dass wir zu diesem Zeitpunkt an Ressourcenmangel litten, wäre eine faire Einschätzung. Dennoch hätten wir es besser machen können und haben seitdem Verfahrensänderungen vorgenommen, um sicherzustellen, dass bei wichtigen Ereignissen wie diesen in Zukunft ein Teammitglied benannt wird, um eine häufige und transparente Kommunikation mit unseren Kunden zu ermöglichen.

Wir sind unglaublich dankbar für die Kunden, die uns während dieser Ereignisse unterstützt haben. Wir haben Ihre Empfehlungen gehört und die Unterstützung gespürt, die Sie in den letzten Monaten geleistet haben. Sie können sicher sein, dass wir weiterhin zuhören und auf Ihr Feedback reagieren.

Abschließend möchten wir uns bei Ihnen entschuldigen, wenn wir Sie enttäuscht haben. Wir wissen das Vertrauen zu schätzen, das Sie in uns als Ihren Hosting-Provider gesetzt haben, und sind bestrebt, dieses Vertrauen jeden Tag aufs Neue zu verdienen. Wir hoffen, dass die hier aufgeführten Details einige Fehlinformationen aufklären und unsere Bereitschaft zeigen, Verbesserungsmöglichkeiten anzusprechen, das Richtige zu tun und die Kommunikation und Transparenz mit Ihnen, unseren Kunden, zu erhöhen.


Kommentare (17)

  1. Author Photo

    *”…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

  2. Author Photo

    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.

  3. Author Photo

    “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?

  4. Author Photo

    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 🙂

  5. Author Photo

    The most significant take away for me is that Linode is becoming more transparent. Please continue down this path.

  6. Author Photo

    Good news for the new Linode manager, is there any ETA?

  7. Author Photo

    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.

  8. Author Photo

    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.

  9. Author Photo

    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)

  10. Author Photo

    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.

  11. Author Photo

    “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

  12. Author Photo

    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.

  13. Author Photo

    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.

  14. Author Photo

    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.

  15. Author Photo

    Well done, Linode!

  16. Author Photo

    If you are going to update the Linode Manager API, *please, please, please* give us the ability to do programmatic snapshots.

    Thank you.

  17. Author Photo

    I greatly appreciate the explanation and transparency. So very different than other companies. This is the kind of thing that creates customer loyalty.

Kommentar abgeben

Ihre E-Mail Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit *gekennzeichnet