Gehacktes Microsoft-Testkonto hatte Administratorrechte

• Der Vorfall bei Microsoft ist gravierender als eine einfache Kontoübernahme, da ein altes Testkonto ohne MFA zum Zugriff auf E-Mails von Führungskräften sowie der Sicherheits- und Rechtsabteilung führte
• Die mit dem russischen Staat verbundene Gruppe Midnight Blizzard nutzte schwache Zugangsdaten per Password Spraying aus und meldete sich bei einem „legacy non-production test tenant account“ an
• Die Angreifer nutzten in dem kompromittierten Test-Tenant OAuth-App-Berechtigungen, um die Rolle full_access_as_app in Office 365 Exchange Online zu erhalten
• Da für die Zuweisung von full_access_as_app Administratorrechte erforderlich sind, wurde kritisiert, dass das Testkonto aufgrund einer Fehlkonfiguration in der Produktionsumgebung übermäßige Rechte hatte
• Ein Testkonto, das gegen das Prinzip der geringsten Rechte verstößt, sowie Password Spraying über Residential Proxies erschweren die bisherige, auf Kompromittierungsindikatoren basierende Erkennung

---

Vom Testkonto zum E-Mail-Zugriff

• Russische staatliche Hacker nutzten per Password Spraying schwache Zugangsdaten aus und meldeten sich bei einem „legacy non-production test tenant account“ an
• Dieses Testkonto war nicht durch Multi-Faktor-Authentifizierung geschützt
• Danach wurden Berechtigungen erlangt, die den Zugriff auf E-Mail-Konten von Microsoft-Führungskräften sowie Mitarbeitern aus Sicherheits- und Rechtsabteilung ermöglichten
• Die Angreifergruppe Midnight Blizzard missbrauchte das OAuth-Authentifizierungsprotokoll, um dauerhaft auf privilegierte E-Mail-Konten zuzugreifen
  • Im kompromittierten Test-Tenant wurde eine bösartige App erstellt
  • Der App wurden Berechtigungen erteilt, mit denen auf alle E-Mail-Adressen im Microsoft-Office-365-Maildienst zugegriffen werden konnte
  • Über eine bestehende Test-OAuth-Anwendung wurde die Rolle full_access_as_app in Office 365 Exchange Online vergeben

Legacy-Testkonto mit Administratorrechten

• Microsofts Update enthielt die Angabe, dass eine „legacy test OAuth application“ in der Microsoft-Unternehmensumgebung über elevated access verfügte
• Laut Kevin Beaumont muss ein Konto über Administratorrechte verfügen, um einer OAuth-App die Rolle full_access_as_app zuweisen zu können
• Beaumont bewertete diese Konfiguration als „einen ziemlich großen Konfigurationsfehler in der Produktion“
• Es wurde kritisiert, dass es kaum einen plausiblen Grund gebe, einem alten Legacy-Testkonto derart weitreichende Rechte zu geben und diese beizubehalten
• Microsoft lehnte eine Erklärung dazu ab, warum das Testkonto ursprünglich so konfiguriert wurde und warum dies auch nach seinem Legacy-Status beibehalten wurde

Konfiguration entgegen dem Prinzip der geringsten Rechte

• Diese Konfiguration verletzt das Prinzip der geringsten Rechte, nach dem ein Konto nur die minimal nötigen Rechte für seine Aufgaben haben sollte
• Das Kernproblem ist, dass kaum nachvollziehbar ist, warum ein Legacy-Testkonto Administratorrechte haben sollte
• Beaumont verglich dies mit einer Situation, in der in einer Testdomäne ohne Sicherheit, MFA, Firewall und Monitoring ein Domain Admin aus dem Produktionssystem vorhanden ist
  • Ein Domain-Admin-Benutzer hat volle Administratorrechte über mit dem Netzwerk verbundene Geräte, einschließlich Domain Controllern und Active Directory
  • Da es sich um das mächtigste Konto im Netzwerk handelt, sollte es isoliert sein und nur selten in Produktionssystemen vorkommen
  • Wenn ein solches Konto ohne starkes Passwort und ohne Standard-Sicherheitsmaßnahmen bestehen bleibt, ist der potenzielle Schaden groß

Kompromittierungen anderer Organisationen und verdecktes Password Spraying

• Microsoft stellte fest, dass Midnight Blizzard zusätzlich in andere Organisationen eingedrungen war, und informierte die betroffenen Organisationen
• Auch Hewlett-Packard Enterprises erklärte, das eigene Netzwerk sei von Midnight Blizzard gehackt worden
  • Der Vorfall ereignete sich im Mai
  • Entdeckt und gestoppt wurde er erst im Dezember
• Das für den Zugriff auf das Testkonto verwendete Password Spraying wurde mit wenigen Versuchen pro Konto gegen eine begrenzte Zahl von Konten durchgeführt
• Die Angreifer machten ihre Aktivitäten mit einer verteilten Residential-Proxy-Infrastruktur weniger auffällig
  • Der Zugriff erfolgte von IP-Adressen mit guter Reputation
  • Es wurden IP-Adressen aus erwartbaren Regionen verwendet
  • Der Verkehr wirkte dadurch stärker wie legitimer Nutzer-Traffic

Grenzen der Erkennung anhand klassischer Kompromittierungsindikatoren

• Der Einsatz von Residential Proxies ist keine neue Technik und wurde bereits beim SolarWinds-Lieferkettenangriff 2020 verwendet
• Auch der SolarWinds-Angriff wird mit Midnight Blizzard in Verbindung gebracht
• Da Residential Proxies Traffic über eine große Zahl legitimer Nutzer-IP-Adressen weiterleiten, ist eine traditionelle indikatorbasierte Erkennung von Kompromittierungen praktisch schwierig
• Midnight Blizzard ist eine Gruppe, von der die US- und britische Regierung sagen, dass sie für den russischen Auslandsnachrichtendienst SVR tätig ist
• Weitere Bezeichnungen für dieselbe Gruppe sind APT29, the Dukes, Cloaked Ursa, UNC2452 und Dark Halo

[GN⁺]

Meinungen auf Hacker News

• Erinnert mich an einen alten Roblox-Hack, von dem ich früher gehört habe. Es gab eine nicht produktive Staging-Site, auf der sich Nutzer registrieren konnten, mit einem Banner: „Alles hier ist nicht dauerhaft“
  In der Produktionsumgebung wurde ein neues Admin-Konto angelegt. Jemand registrierte sich dann auf der Staging-Site mit demselben Nutzernamen und konnte mit dessen Cookies und Tokens das Produktionskonto übernehmen und die Site kompromittieren
  Wenn man kryptografische Tokens auf Basis von Nutzernamen oder Nutzer-IDs erzeugt, ohne für Produktion und Staging unterschiedliche Secrets zu verwenden, oder wenn die Staging-Site mit externen Diensten kommuniziert und sich dabei mit der Autorisierung der Produktion vermischt, scheint so ein Problem gar nicht so selten zu sein

  • Ich habe früher einmal eine Versand-API für E-Commerce implementiert und sie mit Anbietern wie DHL integriert. Wir vergaßen, auf den Produktionsserver umzuschalten, und versendeten monatelang mit Labels, die von der Test-API ausgegeben wurden. Die Waren wurden zugestellt, aber nicht berechnet
    Sobald wir es bemerkten, meldeten wir es offen
  • Deshalb gibt es in Tokens ein Audience-Feld

• In Großunternehmen ist die Grenze zwischen Entwicklung und Produktion viel durchlässiger, als man gerne glauben möchte
  Man stelle sich einen typischen Tag vor: Man meldet sich am PC an, prüft E-Mails und loggt sich dann mit denselben Anmeldedaten im Azure-Portal ein. Am Ende hängt alles am selben Tenant, und das Konto ist auch mit GitHub und Cloud-Konten verknüpft
  Groups und Teams werden überall angelegt, und Dinge, die mit fragwürdigen Berechtigungen entstanden sind, nur um Teams oder OneDrive zu nutzen, bleiben im Unternehmensverzeichnis nahezu ununterscheidbar von Security Groups zurück
  Gelegentlich kommt eine automatische E-Mail mit „Brauchen Sie das noch?“, aber die Nachricht ist undurchsichtig, und in einem sehr großen Unternehmen gibt es auch niemanden, den man sinnvoll fragen könnte. Der Helpdesk antwortet erst zwei Tage später, und man kann ja auch nicht John Savill auf Twitter fragen, also klickt man einfach auf Bestätigen und macht weiter
  Irgendwann beginnt das Gewebe der Organisation zu reißen, und ein Angreifer hat an einer schwachen Stelle Glück, kommt hinein, bewegt sich lateral durch den Tenant und holt sich, was er will
  Wie ein kluger CISO sagte: Hacker brechen nicht ein, sie loggen sich ein

  • Die hier als „typisch“ angenommene Situation ist ziemlich gewagt, was ich interessant finde
    Natürlich benutzt demnach jeder Microsoft Cloud, Skype, Twitter, OneDrive und dergleichen, und zur Glaubwürdigkeit wird sogar noch irgendein Personenname eingestreut

• Zu Kevin Beaumonts Aussage: „Nur ein Konto mit Administratorrechten kann einer OAuth-App die nahezu allmächtige Rolle full_access_as_app zuweisen. Jemand hat in der Produktionsumgebung eine ziemlich große Fehlkonfiguration vorgenommen“ — ohne die Systemdetails zu kennen, wirkt das für mich nicht wie das Kernproblem
  Es sollte überhaupt keinen Weg geben, so einen Fehler zu machen. Die Menschen, die das entworfen und betrieben haben, hätten es unmöglich machen müssen, und dort liegt auch die Verantwortung
  Wenn man eine Fabrik baut und betreibt, in der es einen Knopf gibt, der alle Mitarbeiter im Inneren unter Strom setzt, und jemand drückt diesen Knopf versehentlich, ist klar, wo das Problem liegt

  • Das ist höchstwahrscheinlich kein technisches Problem. Es mag etwa 20 Best Practices und Sicherheitsvorkehrungen gegeben haben, um es technisch zu verhindern, aber solche Guardrails haben nur dann Bedeutung, wenn Organisation, Führung und Bürokratie sich dafür interessieren
    Über Jahre hinweg wurde ich mehrfach aufgefordert, sämtliche Policies, Verfahren, Vorschriften und Gesetze zu ignorieren und VIPs, die solche Rechte überhaupt nicht brauchten, Superadmin-/root-Rechte zu geben
    Heute ist es noch schlimmer, weil alles wie Matrixorganisation, Teilzeit, Doppelrollen und Dreifachrollen funktioniert
    Ich habe auch rollenbasierte Zugriffskontrolle gesehen, bei der es mehr Rollen gab als tatsächlich vergebbare Berechtigungen. Dann untergräbt RBAC seinen eigenen Zweck. Berechtigungen einzeln zu vergeben wäre schneller gewesen, wurde aber nicht erlaubt, weil dann im Bericht keine Rollen auftauchten
    So etwas kommt nicht von den Technikern, sondern von schlechter Führung
    Früher habe ich einmal eine Erweiterung entworfen, um dieses Problem im RBAC-Berechtigungssystem eines internen ERP abzumildern. Es gab einen Typ „Berechtigungsausnahme“: Wer Rechte außerhalb seiner Rolle brauchte, wurde auf diese Weise zugewiesen, sodass ein Bericht mit allen Personen erstellt werden konnte, die Aufgaben außerhalb ihrer Stellenrolle ausführen konnten
    Letztlich war es nur ein zusätzliches Flag an der Berechtigung, aber es funktionierte gut. HR prüfte quartalsweise die Berechtigungsausnahmen und erwog deren Entfernung, und statt dass ein Teilzeit-Helpdesk per Trial and Error Berechtigungen aufriss, konnten tatsächlich sachkundige Berechtigte die Kontrolle behalten
  • Ich frage mich, wie man Fehlkonfigurationen unmöglich machen will

• Es ist schon lustig: Es gibt jede Menge schicke Security-Zertifizierungen, die angeblich Unternehmen und Branchen mit quantifizierbarem Risiko schützen, aber rationale, durchdachte Best Practices aus einem 36-Dollar-Buch bei Amazon werden völlig ignoriert
  Sicherheit wirkt fast wie eine Art Schleifen-Kampagne

  • Sicherheit ist ein Prozess, kein Produkt
    Wer Sicherheit wie ein Produkt verkauft, betreibt Betrug
  • Selbst wenn ich ein Security-Zertifikat habe, haben es 1.000 andere Mitarbeiter vielleicht nicht
    Normale Mitarbeiter interessieren sich kaum für Sicherheit an sich, sie machen einfach ihre Arbeit
    Es gibt so viele Server, Anwendungen und Konfigurationen, dass sicherheitsbewusste Mitarbeiter nicht ausreichen, um alles zu prüfen
    Wenn man lange genug hinsieht, wird in jedem Unternehmen irgendwann etwas offen sein, das nicht offen sein sollte. Genau das tun Hackergruppen: ständig nach Lücken suchen
    Ein Unternehmen muss im laufenden Betrieb ständig neue Server und neue Konfigurationen erstellen; es ist also kein Problem, das man einmal einstellt und dann abhakt
  • Ich frage mich, welches Buch gemeint ist

• Ich hasse es, wenn ich in einem neuen Job anfange und mir jemand massenhaft Berechtigungen gibt, weil „das einfacher ist“. Das sollte man nicht tun
  Es setzt nicht nur das Unternehmen einem Angriff aus, sondern schiebt mir auch unerwünschte Verantwortung zu. Ich könnte versehentlich etwas Wichtiges kaputtmachen, und wenn irgendetwas gehackt wird, könnten Leute mich verdächtigen, nur weil ich diese Rechte hatte

  • Wenn man bedenkt, wie viele Konten und Berechtigungen über mehrere Dienste hinweg pro Mitarbeiter verwaltet werden müssen, wirkt diese Entwicklung fast wie eine natürliche Evolution
    Im Grunde erleben wir auf Service-Ebene so etwas wie die Sicherheitspopups von Windows XP. Bei jedem Arbeitsschritt wird man aufgefordert, sich gegenüber irgendetwas anderem zu authentifizieren, und es kann Tage dauern, bis man die richtigen Anmeldedaten mit den passenden Rechten bekommt
    Menschlich kann ich verstehen, dass Supportteams aufgeben und neuen Mitarbeitern Konten und Berechtigungen einfach im Paket hinwerfen

• Was in diesem Beitrag fehlt, ist die Frage, wie die Autoren „Produktion“ definieren, wenn ein Nicht-Produktionskonto Administratorrechte für die Produktionsdomäne hat

  • Das ist aus meiner Sicht der Kern. Der Beitrag und die Zitate nennen das einen „Fehler“, aber in einer großen und komplexen Organisation wie Microsoft halte ich falsch zugewiesene Berechtigungen für unvermeidlich
    Deshalb ist es wenig hilfreich, sich auf den Blickwinkel „in einem Unternehmen mit 220.000 Leuten hat irgendwann jemand einen Fehler gemacht“ zu konzentrieren
    In den meisten Unternehmen gibt es jedoch normalerweise eine feste, dicke Trennlinie zwischen Produktionssystemen und Testsystemen. Einem Testkonto Produktionszugriff zu geben, sollte praktisch unmöglich sein; daher sollte der Fokus der Untersuchung darauf liegen, wie so etwas passieren konnte

• Ich habe noch Schlimmeres gesehen. Ich habe in einer Anwaltskanzlei gearbeitet, wo Administratoren und Partnern Administratorzugriff auf alles gegeben wurde
  Nach einem Passwort-Reset war das Standardpasswort „passme“, weil das ursprüngliche Passwort zu lang und schwer zu merken gewesen sei. Nach dem Einloggen auf dem Server sollte man das Passwort ändern
  Hacker übernahmen einige dieser Konten, fummelten an diversen Dingen herum und stahlen Daten. Auch einige Testkonten hatten Administratorrechte
  Zum Glück arbeite ich dort nicht mehr. Ich war Programmer Analyst und hatte nur Administratorrechte auf meinem PC, damit Visual BASIC 6.0 lief

• Dieses Muster ist im gesamten Microsoft-Ökosystem eher die Regel als die Ausnahme, aber dass Microsoft selbst so gehandelt hat, ist besonders peinlich
  Das Microsoft-Sicherheitsteam hat viel Aufwand in Tools und Best-Practice-Dokumentation gesteckt, um solche großen Vorfälle zu verhindern

  • Ich frage mich, wie das ursprüngliche Testkonto kompromittiert wurde. Vermutlich gab es keine Multi-Faktor-Authentifizierung, und nach Password Spraying über den OAuth-ROPC-Flow erfolgte eine laterale Bewegung
    M365 ist ziemlich schlecht darin, Multi-Faktor-Authentifizierung durchzusetzen. Es ist so aufgebaut, dass man dafür zahlen muss
  • So etwas passiert überall. Die Testmethoden vieler Leute, mit denen ich gearbeitet habe, bestanden fast immer darin, maximale Rechte zu vergeben. Keine Ahnung, es fühlt sich an wie Shotgun-Debugging
    Das größere Problem ist, dass die Leute es vergessen. Man erstellt fünf Testkonten mit Administratorrechten, und bis jemand ein unternehmensweites Audit der Benutzerrechte durchführt, fällt es nicht auf

• Eine Firma, bei der ich früher gearbeitet habe, hatte alle Passwörter für Produktionsserver und Datenbanken in Textdateien im Code-Repository abgelegt. Der Grund war, dass der leitende Architekt sich keine Passwörter merken wollte
  Als ich dem CTO sagte, wie dumm das sei, bekam ich als Antwort: „Wir vertrauen unseren Mitarbeitern“ und „Wir haben das Sicherheitsaudit bestanden“
  Ich spüre immer noch die Nachwirkungen des Facepalms

  • Ich hasse Datenbankpasswörter auch. Sie werden viel zu schnell geknackt
    Sie sind nur ein Ärgernis, keine Sicherheitsfunktion. Ich verwende keine Passwörter wie „c00lz500“, sondern eher so etwas wie eine leere Zeichenkette
    Stattdessen nutze ich Firewalls und interne Netzwerke