[English]Sicherheitsexperten und der US-Senators Ron Wyden erheben schwere Vorwürfe und werfen Branchen-Platzhirsch Microsoft Versäumnisse vor. Microsoft habe es versäumt, bekannte Probleme mit seiner Cloud-Software zu beheben und Anwender zu warnen. Das habe erst den massiven SolarWinds-Hack ermöglicht, der mindestens neun Bundesbehörden kompromittiert hat. Dabei spielt ein als "golden SAML" bezeichneter Angriffsvektor eine Rolle. Zeit, das Ganze mal etwas zu beleuchten.
Anzeige
Seit Monaten sind zahlreiche US-Behörden und Ministerien sowie Firmen weltweit durch eine Hintertür gehackt und Angreifern ist es gelungen, zahlreiche Dokumente abzuziehen. In den Beiträgen US-Finanzministerium und weitere US-Behörde gehackt und FireEye: Wenn Hacker eine Sicherheitsfirma plündern hatte ich erstmals über diese Hacks des US-Sicherheitsunternehmens FireEye sowie des US-Finanzministeriums und weiterer US-Behörden berichtet. Hacker konnten sich seit Monaten in deren IT-Systemen umsehen, Mails mitlesen und Dokumente abziehen. Weitere Artikel finden sich am Ende des Beitrags verlinkt.
In den Berichten von Firmen und Behörden, die gehackt wurden, wird der Hack als ausgeklügelte Operation einer staatsnahmen Gruppe mit um die Tausend Entwickler dargestellt (siehe auch Microsoft-Untersuchung zu Solarigate: 1.000 Cyber-Krieger und Zugriff auf Quellcode von Azure, Exchange, Intune). Das ist nicht ganz von der Hand zu weisen, wenn man die Größe der Operation anschaut. Und die Vorgehensweise der Angreifer war auch ganz clever, wobei aber die Frage zu stellen ist: Waren sich die Protagonisten unter den Opfern zu sicher? Ich hatte mal im Blog-Beitrag Schlamperei bei SolarWinds für kompromittierte Software verantwortlich? einen Aspekt herausgegriffen, wie Sicherheit beim Entwickler der kompromittierten Orion-Software, der Firma SolarWinds, gelebt wurde.
Es wurde auch mal thematisiert, dass die Vergabe der Entwicklung an ausgelagerte Entwickler für den Lieferkettenangriff verantwortlich sein könnte (siehe SolarWinds-Hack: Motive der Angreifer; Outsourcing als Schwachstelle?). Aber auch Microsoft gerät jetzt unter Druck bzw. eigentlich stellen sich Beobachter die Frage: Tut Redmond genügend für die Sicherheit der Microsoft-Systeme. Einmal wurde Microsoft selbst Opfer des Hacks (siehe SolarWinds-Hacker hatten Zugriff auf Microsoft-Quellcode). Zudem kenne ich es, dass gemeldete Schwachstellen relativiert und monatelang nicht behoben werden ("Uns sind keine Fälle einer Ausnutzung bekannt", "Die Ausnutzung ist unwahrscheinlich").
(Quelle: Pexels Markus Spiske CC0 Lizenz)
Microsoft und der golden SAML-Angriffsvektor
Jetzt greift US-Senator Ron Wyden Microsoft an, denn deren Nachlässigkeit bei der Beseitigung von bekannten Schwachstellen habe erst zum Erfolg der Hacking-Kampagne beigetragen. Reuters berichtete vor wenigen Stunden im Beitrag Microsoft failed to shore up defenses that could have limited SolarWinds hack: U.S. senator über den Sachverhalt. Von Sicherheitsforschern wurde 2017 erstmals öffentlich eine als "golden SAML" bezeichnete Schwachstelle aufgedeckt.
Kurzer Hintergrund zu SAML
SAML steht für Security Assertion Markup Language, ein XML-Framework zum Austausch von Authentifizierungs- und Autorisierungsinformationen. Sie stellt Funktionen bereit, um sicherheitsbezogene Informationen zu beschreiben und zu übertragen. SAML wurde ab 2001 von dem OASIS-Konsortium entwickelt. Zu diesem Konsortium gehören Unternehmen wie Sun Microsystems (übernommen von Oracle), IBM, Nokia und SAP. Bei der Entwicklung hatte man die folgenden Anwendungsfälle im Blick:
- Single Sign-on: Ein Benutzer ist nach der Anmeldung an einer Webanwendung automatisch auch zur Benutzung weiterer Anwendungen authentifiziert.
- Verteilte Transaktionen: Mehrere Benutzer arbeiten gemeinsam an einer Transaktion und teilen sich die Sicherheitsinformationen.
- Autorisierungsdienste: Die Kommunikation mit einem Dienst läuft über eine Zwischenstation, die die Berechtigung überprüft.
Diese Dienste sollen vor allem für Webservices angeboten werden. SAML besteht aus SAML-Assertions, aus dem SAML-Protokoll, aus SAML-Bindings und Profilen.
Der golden SAML-Angriffsvektor
Bei golden SAML handelt es sich um einen Angriffsvektor, den Sicherheitsforscher von CyberArk Labs entdeckten. Die CyberArk Labs-Leute haben kürzlich ein Webinar drüber veranstaltet. Dort wurde ein neues Tool shimit demonstriert, das ein goldenes SAML implementiert. Damit ist es möglich, ein AWS-Konto aus einer Microsoft-Domäne heraus zu kompromittieren.
In kurz: Der golden SAML-Angriffsvektor ermöglicht es einem Angreifer, ein SAML zu erstellen, das im Grunde ein gefälschtes SAML-"Authentifizierungsobjekt" ist. Dieses SAML ermöglicht einem Angreifer sich über jeden Dienst zu authentifizieren, der das SAML 2.0-Protokoll als SSO-Mechanismus verwendet. Es ist quasi so etwas wie ein Generalschlüssel mit Zugang zu allem.
Anzeige
Microsofts Rolle in der Angelegenheit
Microsoft ist ja mit seinen Cloud-Diensten in vielen Behörden und Firmen breit aufgestellt. Dort wird auch SAML zur Authentifizierung verwendet. Die golden SAML-Schwachstelle ermöglicht es Hackern, die Identität autorisierter Mitarbeiter vorzutäuschen, um Zugriff auf die Cloud-Dienste von Kunden zu erhalten. Diese Technik war eine von vielen, die bei dem SolarWinds-Hack verwendet wurden.
US-Senator Wyden, der als Mitglied des Geheimdienstausschusses des Senats Tech-Unternehmen in Fragen der Sicherheit und des Datenschutzes kritisiert hat, wirft Microsoft vor, nicht mehr zu tun, um gefälschte Identitäten zu verhindern oder Kunden davor zu warnen. "Die Bundesregierung gibt Milliarden für Microsoft-Software aus", sagte Wyden gegenüber Reuters vor einer SolarWinds-Anhörung am Freitag im Repräsentantenhaus. Und dann schob Wyden nach: "Sie [die Bundesregierung] sollte vorsichtig sein, noch mehr auszugeben, bevor wir herausfinden, warum das Unternehmen die Regierung nicht vor der Hacking-Technik gewarnt hat, die die Russen verwendet haben, von der Microsoft seit mindestens 2017 wusste".
Das ist natürlich ein heftiger Schuss vor den Bug, speziell da Microsoft unter anderem einen riesigen Auftrag für Cloud-Dienste beim US-Verteidigungsministerium an Land gezogen hatte (siehe z.B. Pentagon-Untersuchung: Microsofts JEDI-Contract war sauber). Microsoft-Präsident Brad Smith soll heute Freitag vor dem Untersuchungsausschuss des Repräsentantenhauses zu den SolarWinds-Hacks aussagen und dürfte sich einige Fragen anhören müssen.
Rolle von golden SAML unklar
Der Fairness halber sollte man auch anmerken, dass das Thema "golden SAML" momentan alles andere als klar ist. Microsoft bestritt Wydens Schlussfolgerungen und erklärte gegenüber Reuters, dass das Design seiner Identitätsdienste nicht fehlerhaft war. Reuters zitiert die Antwort eines Microsoft-Lobbyisten auf schriftliche Fragen von US-Senator Wyden von Anfang Februar 2021, dass der als golden SAML bekannte Angriffsvektor, "nie in einem tatsächlichen Angriff verwendet wurde" und "weder von den Geheimdiensten als Risiko eingestuft wurde, noch von zivilen Agenturen als solches erkannt wurde". Mit anderen Worten "Funktioniert wie implementiert" (worked as designed).
Allerdings gab es nach dem SolarWinds-Hack bereits am 17. Dezember 2020 eine öffentlichen Beratung. Dort forderte die National Security Agency (NSA) eine genauere Überwachung von Identitätsdiensten und stellte fest: "Diese SAML-Angriffsmethode ist seit mindestens 2017 bekannt und wird von Cyber-Akteuren verwendet."
Und in einer Aussage vor dem Kongress am Dienstag sagte Microsoft-Präsident Brad Smith, dass nur etwa 15% der Opfer der Solar Winds-Kampagne über Golden SAML geschädigt wurden. Selbst in diesen Fällen mussten sich die Hacker bereits Zugang zu Systemen verschafft haben, bevor sie die Methode einsetzten. Mitarbeiter von US-Senator Wyden haben Reuters durchgestochen, dass eines dieser Opfer das US-Finanzministerium gewesen sei. Dort wurden die E-Mail-Konten von Dutzenden von Finanzbeamten durch die Hacker wohl über Monate ausgespäht.
Das Risiko der Cloud
Und dann wird es irgendwie doch noch richtig spannend. Wenn unsereins als "kleines Licht" echauffiert, dass der Zug der Lemminge in die Cloud nicht immer gesund sein kann, wird das ja gerne als old school abgetan. In einer Antwort auf weitere Fragen von US-Senator Wyden musste Microsoft in dieser Woche einräumen, "dass seine Programme nicht darauf ausgelegt seien, den Diebstahl von Identitätswerkzeugen für die Gewährung von Cloud-Zugang zu erkennen". Wenn ein Angreifer also ein SAML fälschen kann, stehen ihm über die Cloud alle Türen offen – das ganze hoch gelobte Sicherheitszeugs ist schlicht blind dafür.
Trey Herr, Direktor der Cyber Statecraft Initiative beim Atlantic Council, wird von Reuters so zitiert, dass der Fehler zeige, dass Cloud-Sicherheitsrisiken eine höhere Priorität haben sollten. Seine Aussage: Der ausgeklügelte Missbrauch von Identitäten durch die Hacker offenbare eine besorgniserregende Schwäche in der Art und Weise, wie Cloud-Computing-Giganten in die Sicherheit investieren, indem sie vielleicht das Risiko von Ausfällen mit hoher Auswirkung und geringer Wahrscheinlichkeit in den Systemen, die die Grundlage ihres Sicherheitsmodells bilden, nicht ausreichend mindern. Ist zwar geschwurbelt, lässt sich aber auf den kurzen Nenner "Cloud ist so, wie das aktuell gehandhabt wird, einfach Mist, wir sitzen auf einem Schlitten, der bergab fährt und niemand weiß, wie diese Fahrt endet" bringen. Danke an Gero für den Hinweis – wenn ich auch andere Quellen herangezogen habe.
Ähnliche Artikel:
FireEye: Wenn Hacker eine Sicherheitsfirma plündern
US-Finanzministerium und weitere US-Behörde gehackt
SolarWinds SUNBURST-Schwachstelle: Die Folgen und Schutzmaßnahmen
SolarWinds-Produkte mit SunBurst-Backdoor, Ursache für FireEye- und US-Behörden-Hacks
SUNBURST-Malware: Analyse-Tool SolarFlare, ein ‚Kill-Switch' und der Einstein-Überwachungsflopp
Schlamperei bei SolarWinds für kompromittierte Software verantwortlich?
Neues im Kampf gegen die SUNBURST-Infektion, Domain beschlagnahmt
SUNBURST-Malware wurde in SolarWinds Quellcode-Basis eingeschleust
SUNBURST: Auch US-Atomwaffenbehörde gehackt, neue Erkenntnisse
SolarWinds-Hack: Auch Microsoft & Co. betroffen?
SUNBURST-Hack: Microsofts Analysen und Neues
SolarWinds-Systeme mit 2. Backdoor gefunden
SolarWinds-Hacker hatten Zugriff auf Microsoft-Quellcode
SolarWinds-Hack: Motive der Angreifer; Outsourcing als Schwachstelle?
Gibt es deutsche Opfer des SolarWinds-Hacks?
Neues vom SolarWinds-Hack; JetBrains-Software als Einfallstor?
Kaspersky: SolarWinds Sunburst-Backdoor gleicht russischer ATP-Malware
SolarLeaks bietet angeblich Sourcecode von Cisco, Microsoft und SolarWinds an
Auch Malwarebytes von den SolarWinds-Angreifern erfolgreich gehackt
Vier Sicherheitsanbieter bestätigen SolarWinds-Vorfälle
Neues vom SolarWinds-Hack: 3 neue Bugs, alte Bugs durch chinesische Hacker missbraucht
Microsoft-Untersuchung zu Solarigate: 1.000 Cyber-Krieger und Zugriff auf Quellcode von Azure, Exchange, Intune
2015
Um eine golden SAML attach durchzuführen ist bereist der Zugriff auf den private Key des IDP (z.B. ADFS) notwendig. Vom Prinzip her geht das aber auch bei anderen Authenfizierungsverfahren wie OAuth – letztlich kann ich alles unterschreiben, sobald ich mit dem secret (private Key) die Identität des Servers annehmen kann.
Der Cloud-Provider selbst kann dabei nichts prüfen, da die Authentifizierung explizit ja delegiert / redirected wurde, um den Provider dabei nicht zu involvieren. Verliere ich als Betreiber eines IDP nun das Medium, mit welchem ich die Responses signiere ist das letztlich ja vergleichbar mit einer CA, welche den private Key verliert – dann kann auch jeder blind Zertifikate nach eigenem Gusto ausstellen.
In der Hinsicht ist ein kompromittierter ADFS Server (was zum Erlangen des private Key notwendig ist [ausser der Key liegt irgendwo anders rum]) analog einem kompromittierten DC – nur dass dem Gewinner nicht nur Zugriff auf interne, sondern auch externe Ressourcen gewährt wird :-)
Damit sind wir wieder beim "work as designed" – wenn ich einen Schlüssel verliere, der genau auf ein Schloss passt, ist das doof. Passt der auf 1.000 Schlösser, wächst sich das Problem aus.
Absolut.
Ironischerweise verlieren die meisten den Schlüssel im eigens verwalteten Zugriffsbereich.
Liegt der zweite Faktor nicht im eigenen ADFS sondern beim Cloud-Provider umgehe ich das Problem zu einem gewissen Teil. So sind letztlich zwei Authentifizierungsprovider (auf getrennten Infrastrukturen/Tiers) im Einsatz.
Ich habe über dieses Thema schon einiges gelesen, aber nirgends Hinweise gefunden, wie da der ADFS kompromittiert wurde, und was man tun muss, um den zu härten. normalerweise sind diese Dinger doch nur und ausschließlich über https/443 erreichbar. Wie erfolgt da der Angriff? Wie sichert man das ab?
"das ganze hoch gelobte Sicherheitszeugs ist schlicht blind dafür" – Das macht mir da gerade richtig Sorgen…
Man bedenke, momentan empfiehlt Microsoft, statt einer ESAE-Domäne zur Absicherung der Admins im Tiering-Modell auf eine Azure-Domäne zu wechselen, das heißt, man braucht da einen ADFS-Trust, und dann rennt man genau in das Problem, wenn ich das jetzt richtig miteinander in Zusammenhang bringe. Allerdings empfiehlt MS hierfür eine Zwei-Faktor-Absicherung, z.B. mit der MS-Authenticator-App. Wäre das dann sicher vor solchen Angriffen, müsste letztlich jeder Mitarbeiter für seinen MS-365 (Teams, Office, Outlook, …) genauso abgesichert werden, bekommt dann jeder automatisch ein Smartphone, oder lässt man das auf dem Privathandy zu?
golden SAML ist kein Angriff, welcher auf eine Lücke in einem Produkt basiert – es ist ein logisches Problem. In einem SAML Szenario basiert die Authentifizierung darauf, dass ein Dienst einem IDP vertraut.
Kann jemand den IDP imitieren, merkt das der IDP selbst ueberhaupt nicht – letztlich waere fuer die Erkennung von Abweichungen wiederum jeder SP (service) selbst zustaendig. Sinnvolle Verfahren waeren hier wiederum die Erkennung von Unregelmaessigkeiten mittels ML.
Authentifiziert man Benutzerkonten via OnPrem mit ADFS und nutzt den zweiten Faktor bei MS (z.B. Authenticator App), kann der ADFS kompromittiert werden und es ist immer noch der zweite Faktor erforderlich. Das setzt wiederum voraus, dass MS den zweiten Faktor an jeder Stelle konsequent abfraegt.
In einem solchen Szenario gibt's also fuer jeden Service wiederum einen separaten zweiten Faktor – nimmt den meisten Benutzern den Spass, da uebergreifendes SSO damit nicht mehr geht.
Kannst du zu dem Thema weitere Literatur empfehlen? Weblinks? Das alles liest sich bisher nicht gerade ermutigend.
Ich geh jetzt mal davon aus, dass IDP "Identity Provider" meint, aber "ML" kann ich gerade nicht übersetzen. Für mich stellt sich damit natürlich auch die Frage, wie ich gegenüber der Azure-Cloud den ADFS "imitiere", da müsste man ja wohl öffentliche DNS-Einträge manipulieren, oder wie? Nur wenn ich das weis, weiß ich auch, wie ich sowas verhindern kann, oder?
Literatur habe ich dazu leider nicht viel. Hatte in den letzten Monaten einfach selbst etwas mit den Themen SAML bzw. allgemein IDP zu tun. Da kam das eine zum anderen.
Der Authentication Flow ist bei SAML/OAuth/etc. vom Prinzip her meist recht aehnlich – ergo sind auch die Schwaechen bzw. Risikofaktoren in etwa gleich.
Das musst du nicht gegenueber der Cloud imitieren.
Der Service leitet den Client auf den anderen Dienst um. Habe ich also einen Fake IDP, manipuliere ich einfach einen lokalen DNS (oder die hosts-File), dann routet der Browser den Request schon auf ein lokales Ziel. Der Fake IDP bescheinigt die Identitaet, die du hijacken moechtest und unterschreibt die Response mit dem vorab geklauten private Key. Dann einmal redirect zurueck zum SP und das wars.
In der Umsetzung dauert das natuerlich schon ein bisschen laenger als es sich liest – je nach Groesse des Hauptgewinns aber vernachlaessigbar.
Zu: aber „ML" kann ich gerade nicht übersetzen -> Machine Learning – also KI.
Also wenn ich das jetzt richtig verstehe, ist das Thema Azure-Anbindung per ADFS kaputt by design…? Das liest sich nämlich so, ich will mich mit einem AD-Account bei Azure anmelden, und so kenne ich das auch, dass ich bei der Anmeldung (sowieso@firmenname.de) "zur Unternehmensseite", also zum ADFS umgeleitet werde, und mich dort anmelde. Der ADFS sagt mir dann, alles gut und mein PC meldet dieses Ergebnis an Azure weiter? Wenn das so ist, dann ist das nämlich wirklich sehr dumm. Ich hoffe, ich missverstehe das nicht. Denn besser wäre ja dann wohl, wenn ich mich an Azure anmelden will, dass dann Azure den ADFS meiner Firma kontaktiert, und meine Anmeldeinformationen dort selbst prüft. So macht es ja z.B. RSA mit dem Tokens und der dazugehörigen SecurID Appliance. Wenn das so ist, wie ich das momentan verstehe, dann hat MS da einen riesen Bockmist zusammengeschraubt… O-;
Der Ablauf ist hier grundsätzlich anders – das Problem ist nicht konzeptionell bei MS defekt. Es ist einfach so, dass man bei SAML einem IDP vertraut – und wenn jemand diesen imitieren kann, kann derjenige eben auch alles authentifizieren (oder so tun als ob).
Das Risiko ist aehnlich wie eine (interne) CA / PKI zu betreuen. Verliert man den Hauptschluessel, kann jemand viel Unfug damit treiben :-)
Wer nach nun einem Vierteljahrhundert offenkundiger (oder: absichtlicher??) Schlamperei in Seattle immer noch eine tragende Verbindung von Microsoft zum Thema Sicherheit (aller Art) zieht – ist dann auch selber (mit) Schuld (Win NT war eine (die!) Ausnahme: das war HR aus der Konkursmasse von DEC).
Es gibt andere Betriebssysteme, andere Cloud-Anbieter, andere Protokolle.