Kompromittierter Microsoft-Schlüssel: Größere Auswirkungen als erwartet

 (wiz.io)
1 Punkte von GN⁺ 2023-07-24 | 1 Kommentare | Auf WhatsApp teilen
  • Der Storm-0558-Vorfall wurde als Kompromittierung von Exchange Online und Outlook.com bekannt, doch Analysen zeigen, dass der kompromittierte MSA-Signaturschlüssel auch zur Fälschung von OpenID-v2.0-Tokens für Azure-AD-Anwendungen missbraucht werden konnte
  • Der potenziell betroffene Bereich reicht von Microsoft-Apps, die die Anmeldung mit persönlichen Microsoft-Konten nutzen, über Kunden-Apps mit „Login with Microsoft“ bis hin zu Multi-Tenant-Apps unter bestimmten Bedingungen
  • Der betreffende öffentliche Schlüssel befand sich mindestens seit 2016 in Microsofts OpenID-Schlüsselliste, wurde zwischen dem 27. Juni und 5. Juli 2023 ausgetauscht, und sein Thumbprint stimmt mit dem von Microsoft veröffentlichten acquired signing key überein
  • Microsoft hat den Schlüssel außer Betrieb genommen und damit neue gefälschte Tokens verhindert; Apps, die vor der Stilllegung des Schlüssels erzeugte Sessions oder alte Caches öffentlicher Schlüssel weiter vertrauen, müssen jedoch gesondert geprüft werden
  • Gefälschte Tokens können offline erstellt werden, sodass im Azure-Portal keine Ausstellungsspuren bleiben; ohne Roh-Tokens oder kid-Logs ist eine Kompromittierung nur sehr schwer zu bestätigen

Auswirkungen über Exchange Online hinaus

  • Microsoft und CISA haben einen Sicherheitsvorfall offengelegt, der mehrere Kunden von Exchange Online und Outlook.com betraf
  • Laut Microsoft erlangte der als China-naher Threat Actor eingestufte Storm-0558 einen privaten kryptografischen Schlüssel, den MSA-Schlüssel, und fälschte damit Access Tokens für Outlook Web Access und Outlook.com
  • Der Threat Actor soll außerdem zwei Sicherheitsprobleme in Microsofts Token-Validierungsprozess ausgenutzt haben
  • Nach Analyse von Wiz Research war der kompromittierte Schlüssel nicht auf Outlook.com und Exchange Online beschränkt, sondern konnte auch zur Fälschung von Access Tokens für mehrere Azure-Active-Directory-Anwendungen verwendet werden
    • Anwendungen, die die Anmeldung mit persönlichen Konten unterstützen
    • Von Microsoft verwaltete Anwendungen wie SharePoint, Teams und OneDrive
    • Kundenanwendungen, die „Login with Microsoft“ unterstützen
    • Multi-Tenant-Anwendungen unter bestimmten Bedingungen

Wie der kompromittierte Schlüssel identifiziert wurde

  • Am 11. Juli 2023 gab Microsoft bekannt, dass ein böswilliger Akteur einen MSA consumer signing key erlangt hatte und damit Access Tokens für Exchange-Online- und Outlook.com-Konten fälschen konnte
  • Wiz untersuchte Microsofts offizielle Dokumentation zur OpenID-Token-Validierung, um Schlüssel zu identifizieren, die OpenID-Tokens für Microsoft-Konten und Azure-Active-Directory-Anwendungen signieren können
  • Zu diesem Zeitpunkt stützten sich Azure-Anwendungen für persönliche Konten mit v2.0 auf 8 öffentliche Schlüssel, während Azure-Multi-Tenant-v2.0-Anwendungen mit aktivierten Microsoft-Konten auf 7 öffentliche Schlüssel angewiesen waren
  • Eine Prüfung mit der Internet Archive Wayback Machine ergab, dass ein seit mindestens 2016 gelisteter öffentlicher Schlüssel zwischen dem 27. Juni und 5. Juli 2023 ausgetauscht wurde
    • Dieser Zeitpunkt entspricht dem von Microsoft im Blog genannten Zeitpunkt für den Austausch des erlangten Schlüssels
    • Das frühere Zertifikat des öffentlichen Schlüssels wurde am 5. April 2016 ausgestellt und lief am 4. April 2021 ab
    • Der Thumbprint entspricht dem Wert, den Microsoft im aktuellen Blog als „Thumbprint of acquired signing key“ veröffentlicht hat
  • Bei dem von Storm-0558 erlangten Schlüssel handelte es sich um Microsofts privaten Schlüssel für den MSA tenant; der Analyse zufolge konnte er jedoch auch OpenID-v2.0-Tokens für mehrere Azure-Active-Directory-Anwendungen signieren

Warum die Kompromittierung eines OpenID-Signaturschlüssels gefährlich ist

  • Die Azure identity platform veröffentlicht je nach Anwendungstyp unterschiedliche Listen vertrauenswürdiger öffentlicher Schlüssel und verwendet sie zur Integritätsprüfung von Tokens, die Azure Active Directory ausgestellt hat
  • AAD-Anwendungen prüfen die Tokensignatur anhand der richtigen Liste öffentlicher Schlüssel und entscheiden anschließend, ob dem Token vertraut wird
  • Wird ein in der Liste enthaltener Schlüssel kompromittiert, können Anwendungen, die gegen diese Liste validieren, unter bestimmten Bedingungen ein gefälschtes Access Token als gültig akzeptieren
  • Aus Microsofts Blog schließt Wiz, dass Storm-0558 Zugriff auf einen von mehreren Schlüsseln hatte, die zur Signatur und Validierung von AAD Access Tokens verwendet wurden
  • Der kompromittierte Schlüssel wurde für die Signatur von OpenID-v2.0-Access-Tokens für persönliche Konten und mixed audience, also AAD-Anwendungen für Multi-Tenant- oder persönliche Konten, als vertrauenswürdig eingestuft
  • Dadurch konnte Storm-0558 theoretisch Tokens fälschen, die sich in betroffenen Anwendungen, die Microsoft-OpenID-v2.0-mixed-audience- und persönliche-Konten-Zertifikate vertrauen, als beliebige Nutzer authentifizieren
  • Der Signaturschlüssel eines Identity Providers kann als noch mächtigeres Geheimnis gelten als ein TLS-Schlüssel
    • Selbst wenn ein TLS-Schlüssel abfließt, muss der Angreifer zur Ausweitung der Auswirkungen den betreffenden Server imitieren
    • Ein Identity-Provider-Schlüssel kann zur Fälschung von Tokens genutzt werden, die in einem einzigen Schritt Zugriff auf Postfächer, Dateidienste, Cloud-Konten und mehr ermöglichen
    • Dasselbe Risiko gilt nicht nur für Microsoft, sondern auch für den Abfluss von Signaturschlüsseln großer Identity Provider wie Google, Facebook und Okta

Betroffene Anwendungstypen

  • Betroffen sind ausschließlich Azure-Active-Directory-Anwendungen, die Microsofts OpenID v2.0 verwenden
  • v1.0-Anwendungen sind nicht betroffen, da sie den kompromittierten Schlüssel nicht zur Token-Validierung nutzen

  • Anwendungen, die nur persönliche Microsoft-Konten unterstützen

    • Azure-Active-Directory-Anwendungen, die das Microsoft-v2.0-Protokoll verwenden und „Personal Microsoft accounts only“ unterstützen, sind betroffen
    • Dazu gehören von Microsoft verwaltete Anwendungen wie Outlook, SharePoint, OneDrive und Teams sowie Kundenanwendungen, die Microsoft-Account-Authentifizierung unterstützen

  • Anwendungen, die sowohl Multi-Tenant als auch persönliche Microsoft-Konten unterstützen

    • Azure-Active-Directory-Anwendungen, die „mixed audience“ unterstützen und das Microsoft-v2.0-Protokoll verwenden, sind ebenfalls betroffen
    • Der Threat Actor konnte gültige Access Tokens fälschen, die einen Anwendungsnutzer imitieren, der mit einem persönlichen Microsoft-Konto angemeldet war
    • Microsoft führte eine OpenID-Protokollerweiterung ein, um die Fähigkeit eines MSA-Schlüssels einzuschränken, Organisationskonten zu imitieren
    • Entwickler müssen den issuer claim gegen das issuer-Feld in der OpenID-Liste öffentlicher Schlüssel validieren
    • Diese Validierung soll verhindern, dass ein MSA-Schlüssel Access Tokens signiert, deren issuer nicht der MSA tenant ist
    • Die Erweiterung ist Microsoft-spezifisch, und die Verantwortung für die Implementierung liegt beim Anwendungseigentümer
    • Wiz geht davon aus, dass diese Validierung in vielen Anwendungen fehlen könnte und dadurch die Möglichkeit bestehen bleibt, Organisationskonten zu imitieren
    • Laut Microsofts Blog war auch OWA von einem ähnlichen Problem betroffen
    • Microsoft fügte diese Validierungsfunktion am 12. Juli dem offiziellen Azure SDK hinzu

  • Anwendungen, die nur Multi-Tenant unterstützen

    • Wenn eine Multi-Tenant-Anwendung so konfiguriert war, dass sie statt „Organizations“ auf den common-v2.0-Schlüsselendpunkt vertraut, ist sie betroffen
    • Eine solche Konfiguration sollte als Fehlkonfiguration gelten
    • Microsofts offizielle Dokumentation ist nicht eindeutig dazu, wann der „common“-Endpunkt zu verwenden ist, sodass auch einige Multi-Tenant-Anwendungen betroffen sein können

  • Single-Tenant-Anwendungen

    • Single-Tenant-Anwendungen, die nur „Konten in diesem Organisationsverzeichnis“ unterstützen, sind nicht betroffen

Bedingungen, unter denen Token-Fälschung funktioniert

  • Bei der OpenID-Token-Validierung müssen Anwendungsentwickler prüfen, ob ein Token mit einem für den beabsichtigten Bereich autorisierten privaten Schlüssel signiert wurde und ob das Feld aud zum Scope der Zielanwendung passt
  • Anwendungen validieren Tokens, indem sie die für die Signaturprüfung zulässigen Zertifikate von einem Metadaten-Endpunkt namens jwks_uri abrufen
  • Der Threat Actor kann ein JWT-Token erstellen, Daten wie die E-Mail-Adresse des Opfers eintragen und es dann mit dem kompromittierten Schlüssel signieren, der am öffentlichen Zertifikatsendpunkt von Azure Active Directory registriert ist, um ein gültiges Access Token zu fälschen
  • Das kid des beispielhaft genannten kompromittierten Schlüssels lautet 1LTMzakihiRla_8z2BEJVXeWMqo
  • Nach Microsofts Vorgaben muss der iss claim, damit ein Token gültig ist, der im issuer-Feld des jwks_uri-Endpunkts angegebene MSA-tenant-issuer sein; auch der tid claim muss der MSA-tenant-ID 9188040d-6c67-4c5b-b112-36a304b66dad entsprechen
  • In AAD-mixed-audience-Anwendungen kann ein vom MSA tenant für ein Azure-AD-Konto signiertes Token als gültig gelten, solange es ein persönliches Konto imitiert
  • Details zur ID-Token-Validierung finden sich in Microsofts offizieller Anleitung

Verbleibende Risiken nach der Stilllegung des Schlüssels

  • Da Microsoft den kompromittierten Schlüssel außer Betrieb genommen hat, akzeptieren Azure-Active-Directory-Anwendungen mit diesem Schlüssel gefälschte Tokens nicht mehr als gültige Tokens
  • Auch Tokens mit langer Ablaufzeit werden von Anwendungen abgelehnt
  • Wurde jedoch bereits vor der Stilllegung des Schlüssels eine Session in einer Kundenanwendung erstellt, könnte der Threat Actor über die Anwendungsberechtigungen Persistenz erlangt haben
    • Ausstellung anwendungsspezifischer Access Keys
    • Einrichtung anwendungsspezifischer Backdoors
    • Fälle, in denen Storm-0558 vor Microsofts Maßnahmen Access Tokens für OWA fälschte und damit gültige Exchange-Online-Access-Tokens ausstellte
  • Auch Anwendungen, die Kopien der AAD-öffentlichen Schlüssel von vor der Stilllegung des Microsoft-Zertifikats vorhalten, können gefährdet sein
    • Wenn sie einen lokalen Zertifikatsspeicher oder gecachte Schlüssel verwenden und dem kompromittierten Schlüssel weiter vertrauen, sind sie anfällig für Token-Fälschung
    • Microsoft empfiehlt, lokale Speicher und Zertifikats-Caches mindestens einmal täglich zu aktualisieren

Was Azure-Nutzer prüfen sollten

  • Um zu prüfen, ob der kompromittierte Schlüssel in der eigenen Umgebung verwendet wurde, sollten potenziell betroffene Anwendungen identifiziert, Spuren gefälschter Tokens gesucht und mit den von Microsoft veröffentlichten Indicators of Compromise relevante IP-Aktivitäten überprüft werden
  • Wenn Anwendungen öffentliche OpenID-Zertifikate von Microsoft gecacht haben, sollte der Cache aktualisiert werden
  • Microsoft hat zusätzliche Validierungen in das offizielle Azure SDK integriert, um Authentifizierung von Organisationskonten mit einem MSA-Schlüssel zu verhindern; Nutzer dieses Pakets sollten auf die neueste Version aktualisieren

Warum die Erkennung schwierig ist

  • Da der Threat Actor Access Tokens offline fälschen kann, bleiben im Azure-Portal keine Spuren der Token-Ausstellung zurück
  • Um festzustellen, ob der Schlüssel verwendet wurde, müssen Cloud-Kunden die anwendungsspezifischen Logs potenziell betroffener AAD-Anwendungen prüfen
  • Die von Wiz identifizierten betroffenen Anwendungen sind solche, die für die Validierung von Microsoft-v2.0-Access-Tokens die folgenden Endpunkte verwendet haben
  • Potenziell betroffene AAD-Anwendungen lassen sich per Azure CLI identifizieren, indem Apps abgefragt werden, deren signinaudience AzureADMultipleOrgs, AzureADandPersonalMicrosoftAccount oder PersonalMicrosoftAccount ist
  • AAD-Apps, die auf Azure WebApps weiterleiten, lassen sich ebenfalls mit einer separaten CLI-Abfrage finden
  • Durch Dekodieren der von der Anwendung verwendeten Access Tokens und Prüfen, ob das Feld kid im JOSE Header die Zeichenfolge 1LTMzakihiRla_8z2BEJVXeWMqo enthält, lassen sich Tokens finden, die mit dem kompromittierten Schlüssel signiert wurden
  • Laut Microsoft war der kompromittierte Schlüssel inaktiv; daher sollten alle mit diesem Schlüssel signierten Access Tokens als verdächtig gelten
  • Für anwendungsspezifisches Logging fehlt es an standardisierten Praktiken
    • Viele Anwendungseigentümer verfügen nicht über detaillierte Logs mit Roh-Access-Tokens oder Signaturschlüsseln
    • Dadurch können Identifikation und Untersuchung von Ereignissen sehr schwierig sein
  • In reinen Multi-Tenant-AAD-Anwendungen, die keine persönlichen Microsoft-Konten unterstützen, lassen sich gefälschte Tokens anhand der Claims iss und tid erkennen
    • Verbindungsversuche mit Access Tokens, die mit der MSA-tenant-ID 9188040d-6c67-4c5b-b112-36a304b66dad signiert wurden, können auf die Verwendung des kompromittierten Schlüssels hindeuten
  • Wenn für eine WebApp HTTP Logs aktiviert wurden, kann mit Log Analytics geprüft werden, ob die im Microsoft-Blog genannten IP-Adressen des Threat Actors auf die Anwendung zugegriffen haben

Offene Fragen und praktische Schlussfolgerungen

  • Die Gesamtauswirkungen sind deutlich größer als zunächst bekannt und könnten langfristige Folgen für Cloud-Vertrauen und insbesondere für die identity layer als grundlegende Komponente der Cloud haben
  • Potenziell verwundbar waren Millionen von Anwendungen, einschließlich Microsoft-Apps und Kunden-Apps, und viele verfügen nicht über ausreichende Logs, um eine Kompromittierung zu beurteilen
  • Anwendungseigentümer sollten vorrangig das Azure SDK auf die neueste Version aktualisieren und prüfen, ob die Anwendungscaches erneuert wurden
  • Anwendungen, deren Cache nicht aktualisiert wurde, können weiterhin für Threat Actors anfällig sein, die den kompromittierten Schlüssel verwenden
  • Die Angelegenheit wird noch untersucht; wie der Threat Actor den Schlüssel erlangte, wann genau dies geschah und ob weitere Schlüssel kompromittiert wurden, lässt sich anhand der veröffentlichten Informationen nur schwer beantworten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-24
Hacker-News-Kommentare

  • Signaturschlüssel von Identitätsanbietern kommen den mächtigsten Geheimnissen der heutigen Zeit sehr nahe. Zum Beispiel sind sie deutlich mächtiger als TLS-Schlüssel
    In vielerlei Hinsicht sind sie Schlüsseln von Zertifizierungsstellen (CAs) ebenbürtig, und Organisationen, die Microsoft- und Azure-Dienste nutzen, sollten die potenziellen Auswirkungen bewerten
    Es scheint, als hätten die Leute das alte Sprichwort „Lege nicht alle Eier in einen Korb“ vergessen

    • Wenn diese Schlüssel so wichtig sind, verstehe ich nicht, warum sie nicht mit Sicherheitsmaßnahmen auf CA-Schlüssel-Niveau behandelt werden
      Warum teilen sich Dutzende, Hunderte oder vielleicht Tausende Server eine kleine Zahl von Schlüsseln?
      Wo sind HSM-basierte Root-Schlüssel, standortbezogene Zwischen-Schlüssel, temporäre Signaturschlüssel pro Server und Zertifikatsperrlisten?
      Ich frage mich, ob es überhaupt möglich ist, Bearer Tokens bei solchen Angriffen zuverlässig zu schützen, oder ob man wieder dazu übergehen muss, dem Ursprungsdienst einen Nonce vorzulegen, um die Payload sicher abzurufen
    • Vermutlich deshalb, weil Hühner damals nicht mit Nachdruck dafür geworben haben, möglichst viele Funktionen zu integrieren und die Lebensqualität zu erhöhen
      Es sind eben Funktionen entstanden, die nur nutzbar sind, wenn man die Eier an einem Ort bündelt
    • Unsere Firma ist auch bei allem auf Office 365, Teams usw. eingestiegen
      Ich habe schon Popcorn vorbereitet für den Fall, dass alles zusammenbricht, und sicher ist nur, dass die Firma sich selbst nicht die Schuld geben wird
    • Ich frage mich, wie man die Eier überhaupt aufteilen soll
      Ist damit einfach gemeint, einen anderen Anbieter zu nutzen, der seine Schlüssel nicht verloren hat?
    • Ich sehe nicht, wie man das realistisch vermeiden kann
      Inzwischen gibt es praktisch nur noch vier Tech-Giganten

  • Man kam zu dem Schluss, dass „Angreifer mit dem kompromittierten MSA-Schlüssel möglicherweise Zugriffstokens für mehrere Arten von Azure Active Directory-Anwendungen hätten fälschen können“
    Dazu zählen SharePoint, Teams, OneDrive, Kundenanwendungen mit Unterstützung für „Mit Microsoft anmelden“ sowie alle Anwendungen, die die Authentifizierung mit persönlichen Konten unterstützen, etwa mandantenfähige Anwendungen unter bestimmten Bedingungen
    Hoffentlich ist es nur ein Zufall, dass Microsoft Azure AD kürzlich in Entra ID umbenannt hat: https://devblogs.microsoft.com/identity/aad-rebrand/

    • Davon höre ich zum ersten Mal, aber Microsofts katastrophales Naming ist endlose Unterhaltung
      Wenn ich an ein Sicherheitsprodukt denke, möchte ich nicht an einen Anbieter denken, der Menschen „hereinlässt“, statt böswillige Akteure draußen zu halten. Entra kommt von entrar, also hineingehen/hereinkommen, /s
      Im Spanischen wirkt es sogar wie der Imperativ, also als würde man jemandem befehlen: „Komm rein!“

  • „Das Zertifikat des zuvor veröffentlichten öffentlichen Schlüssels wurde am 5. April 2016 ausgestellt, lief am 4. April 2021 ab, und der Fingerabdruck stimmte mit dem Fingerabdruck des Schlüssels überein, den Microsoft im neuesten Blogbeitrag als den ‚Fingerabdruck des erlangten Signaturschlüssels‘ veröffentlicht hat“
    Wenn ich das richtig lese, bedeutet das dann, dass der Schlüssel trotz Ablaufs weiterverwendet wurde?

    • Ich weiß nicht, wie die Gültigkeitsprüfung in den Systemen funktioniert, in denen diese Schlüssel verwendet wurden, aber im Allgemeinen gibt es bei schlüssel- oder zertifikatsbasierter Validierung zwei Arten, mit abgelaufenen Schlüsseln/Zertifikaten umzugehen.
      Ich frage mich, ob jemand weiß, welches Verfahren Microsoft hier eingesetzt hat, wofür auch immer diese Schlüssel verwendet wurden.
      Die eine Variante ist die TLS-Validierung, bei der Cn von Cn-1 signiert wird und dann beim Prüfen der Zertifikatskette bis C0 ungefähr so vorgegangen wird:
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 return NOT_EXPIRED
      Dabei wird das Ablaufdatum jedes Zertifikats anhand der aktuellen Zeit geprüft.
      Die andere Variante wird bei der Code-Signierung verwendet und funktioniert ungefähr so:
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 time_check = cert.issue_time
      6 return NOT_EXPIRED
      Cn wird anhand der aktuellen Zeit geprüft, die übrigen anhand des Zeitpunkts, zu dem das jeweils darunterliegende Zertifikat signiert wurde.
      Warum Code-Signierung so funktioniert, ist nachvollziehbar. Im Kern ist sie eine digitale Beglaubigung; nur weil der Notar später seine Qualifikation verliert und seine Zulassung abläuft, sollte ein bereits beglaubigtes Dokument nicht plötzlich als unbeglaubigt gelten.
    • Als Microsoft den Kunden erklärte: „Storm-0558 hat einen inaktiven MSA-Consumer-Signaturschlüssel erlangt“, hätte es eigentlich heißen müssen: „Storm-0558 hat einen abgelaufenen MSA-Consumer-Signaturschlüssel erlangt.“
      Und statt „Aufgrund eines Validierungsproblems konnte diesem Schlüssel für die Signatur von Azure-AD-Token vertraut werden“ hätte es heißen müssen: „Aufgrund von mehreren Validierungsproblemen konnte diesem Schlüssel für die Signatur von Azure-AD-Token vertraut werden.“
      Und statt „Die Akteure kannten die Zielumgebung, Logging-Richtlinien, Authentifizierungsanforderungen, Richtlinien und Verfahren gut“ hätte man eher sagen sollen:
      „Die Akteure wollten vielleicht einfach einen dreisten Hit-and-Run-Angriff durchziehen und sich keine Sekunde um Nebensächlichkeiten wie Richtlinien scheren. Oder die Akteure waren möglicherweise unerfahren und wussten nicht einmal, dass das US-Außenministerium uns deutlich mehr Geld für die Berechtigung zahlt, Ereignisse zum Mailbox-Zugriff ausführlich zu protokollieren. Boeing hat mit MCAS gewissermaßen schon einen Hinweis gegeben. Außerdem haben die Akteure offenbar übersehen, dass Chrome 92 zuletzt 2021 aktualisiert wurde und als User-Agent für einen Angriff auf die ICT-Systeme eines US-Ministeriums, das aktuelle Browser verwenden sollte, eine ziemlich schlechte Wahl ist. Ebenso wussten sie offenbar kaum, wie auf Mailboxen des US-Außenministeriums zugegriffen wird, und scheinen mit zufälligen öffentlichen Rechenzentren in ganz Europa schlechte Vermutungen angestellt zu haben.“
      [1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
      [2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...
      [3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...

  • Dass sich dieser Schlüssel in einem HSM befand, erscheint sehr unwahrscheinlich.
    Jedes Mal, wenn ich Nachrichten darüber sehe, dass Schlüssel gestohlen wurden, die eigentlich in einem HSM liegen sollten, bin ich erneut überrascht.

    • Schlüssel in einem HSM sind für Teams schwer zu nutzen, und es gibt zwar netzwerkgebundene HSMs, aber deren Integration in Toolchains, die Entwickler häufig verwenden, ist nicht besonders gut.
      Ich konnte kürzlich selbst ein ideales Tool bauen, um die Lücke zwischen modernen Toolchains und Hardware-Sicherheitsenklaven zu schließen: https://keymux.com
    • Eines der populären HSMs, das Thales Luna Network HSM, kann 20.000 ECC-Operationen pro Sekunde durchführen [1].
      Selbst in der Größenordnung von Azure AD bräuchte Microsoft für Signaturen womöglich nicht besonders viele HSMs.
      HSMs sind allerdings nicht sonderlich einfach zu verwalten, was ein Grund dafür sein könnte, dass sie nicht so breit eingesetzt werden, wie nötig wäre.
      [1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
    • Es gibt zwei Szenarien.
      Erstens könnte Microsoft JWT-Signaturschlüssel im Speicher gehalten und genutzt haben, und ein Angreifer könnte den Schlüssel durch Code-Injektion oder Zugriff auf das Speicherabbild dieses Prozesses erlangt haben.
      Zweitens könnte Microsoft tatsächlich HSMs verwendet haben, die Schlüssel aber geografisch verteilen mussten, und der Angreifer könnte dabei Zugriff auf die Schlüssel erhalten haben.
      Das erste erscheint wahrscheinlicher, aber das zweite lässt sich nicht ausschließen.
    • Was ist ein HSM?

  • Sollte man es FAANGs nicht legal erlauben, gegeneinander Cyberkrieg/Spionageaktivitäten zu betreiben?
    Dann müssten sie wohl wenigstens ein Mindestmaß an bewährten Sicherheitspraktiken erreichen, statt sich auf Mehrdeutigkeit zu verlassen.

    • Alle betreiben Bug-Bounty-Programme.
      Solange man keinen echten Schaden verursacht oder keine echten Kundendaten herunterlädt und seine Erkenntnisse offenlegt, ist es ohnehin schon legal.

  • Satya wird im nächsten Earnings Call wohl AI sehr viel häufiger sagen müssen, um dieses Chaos zu überdecken.

  • Es ist schwer, sich einen schlimmeren Vorfall vorzustellen, als dass eine ausländische Macht in die E-Mail-Konten unserer Vertreter eingedrungen ist, die genau dieser Macht gegenüberstehen.
    Ich hoffe, dass die US-Regierung ihre Politik, Computing zu den großen Cloud-Anbietern zu verlagern, ernsthaft überdenkt.

  • „Abschließend danken wir dem Microsoft-Team dafür, dass es bei diesem Artikel eng mit uns zusammengearbeitet und geholfen hat sicherzustellen, dass er technisch korrekt ist.“
    Wie kam wohl die Entscheidung zustande, diese Nachricht an einem Freitag zu veröffentlichen?

    • Wenn man sich anschaut, was nach dem sommerlichen Friday News Dump passiert ist, bleibt es selbst bis Montagabend ruhig.
      Ich habe bei Google News nach „microsoft“ gesucht, die ersten fünf Seiten durchgesehen und dann aufgegeben; insgesamt gab es nur zwei Erwähnungen dazu.
      Der Großteil waren „Nachrichten“ wie PR-Artikel, Produktwerbung oder lärmende Meldungen zum Aktienkurs.

  • „Die Gesamtauswirkungen dieses Vorfalls sind weitaus größer, als wir ursprünglich verstanden hatten. Dieser Vorfall wird langfristige Auswirkungen auf das Vertrauen in die Cloud und die zentralen Komponenten haben, die sie tragen, insbesondere auf die Identitätsschicht, das grundlegende Gewebe von allem, was wir in der Cloud tun. Wir müssen daraus lernen und uns verbessern.“
    Vielleicht sollte man erst einmal damit anfangen, nicht alles in die Cloud zu packen.
    Das Problem ist weniger die Cloud selbst als vielmehr eine kaputte kapitalistische Wirtschaft, die am Ende Monopole oder Kartelle aus einigen wenigen Großkonzernen hervorbringt.
    Für kleine Unternehmen im Long Tail ist es eigentlich nicht sinnvoll, Produkte und Services großer Konzerne zu nutzen, doch wenn man den Marktsiegern immer mehr Macht gibt, entstehen am Ende Unternehmen, die too big to fail sind.
    Bei solchen Großkonzernen wird die Angriffsfläche schon durch einen einzigen Fehler, einen einzigen Ausrutscher, enorm groß. Bei solchen Vorfällen ist nicht die Frage, ob sie passieren, sondern wann.
    Wenn die Gesellschaft langfristig überleben will, dann sind föderierte Dienste die Antwort, selbst wenn man dafür einen Teil der Bequemlichkeit opfern muss.

    • Im Computerbereich liegt die Ursache meist eher in der menschlichen Natur nach dem Motto: „Nobody ever got fired for buying IBM.“
      Business-Leader sind keine Technik-Nerds, die von größeren und besseren föderierten Diensten träumen.
      IT ist meist ein großer Kostenfaktor, sowohl in der Gewinn-und-Verlust-Rechnung als auch in der Zeit und dem Leid, die dafür draufgehen, Computerprobleme zu verstehen, Entscheidungen zu treffen und darum zu kämpfen.
      Als Vergleich: Wenn man sich trotz unsicherer Wetterlage für Microsoft Airlines entscheidet, dann gibt es selbst bei Flugausfall und Verspätung viele Leidensgenossen und viel Mitgefühl.
      Wenn man dagegen seinen eigenen Weg geht und den Zug nimmt, bleibt die ganze Last, Fahrplan, Bahnhöfe und alles andere zu verstehen, an einem selbst hängen. Denn das Flugzeug ist die Art, „die alle kennen“.
      Und wenn Microsoft Air sicher ankommt, aber es beim Zug Probleme gibt, steht man am Ende allein da wie ein dampfender Haufen auf dem Küchenboden.

  • Eine großartige Zusammenfassung, und beängstigend dazu.
    Obwohl das Thema komplex ist, wurde es leicht verdaulich erklärt.