Anzeige
[English]Works as designed, oder doch etwas größerer GAU? Administratoren sollen Geräte über Microsoft Intune verwalten können. Die Prüfung der Geräte-Compliance in Microsoft 365 lässt sich aber in Intune umgehen. Nachdem sich in den letzten Wochen bereits Angriffe angedeutet haben, sind sie dank frei verfügbarer Werkzeuge nun ein Kinderspiel. Das Tool TokenSmith von JumpsecLabs zur Ausführung der Angriffe ist auf GitHub verfügbar. Angreifer könnten Tokens klauen und für Zugriff auf die Unternehmensressource missbrauchen.
Microsoft Intune Konformitätsrichtlinien
Microsoft Intune ermöglicht Administratoren Konformitätsrichtlinien für verwaltet Geräte zu erstellen. Konformitätsrichtlinien sind Sätze von Regeln und Bedingungen, die zum Auswerten der Konfiguration verwalteter Geräte verwenden. Microsoft meint, diese Richtlinien können helfen, Organisationsdaten und -ressourcen von Geräten zu schützen, die diese Konfigurationsanforderungen nicht erfüllen. Verwaltete Geräte müssen die Bedingungen erfüllen, die Sie in Ihren Richtlinien festlegen, damit sie von Intune als konform eingestuft werden.
Administratoren, die die Konformitätsergebnisse aus Richtlinien in Microsoft Entra für einen bedingten Zugriff integrieren, können von einer zusätzlichen Sicherheitsebene profitieren, wirbt Microsoft. Der bedingte Zugriff kann Microsoft Entra Zugriffssteuerungen erzwingen, die auf aktuellen Status eines Geräts basieren, um sicherzustellen, dass nur kompatible Geräte auf Unternehmensressourcen zugreifen dürfen. So weit die Ausführungen Microsofts, die beispielsweise im Beitrag hier nachlesbar sind.
Microsoft 365 Geräte-Compliance umgehen
Andy Wendel hat mich in einer privaten Nachricht auf einen LinkedIn-Post von Christian Biehler aufmerksam gemacht (danke dafür). Die kurze und knackige Botschaft lautet, dass sich die Prüfung der Geräte-Compliance in Microsoft 365 über Microsofts Intune umgehen lässt.
Anzeige
Biehler schreibt, dass sich in den letzten Wochen bereits Angriffe angedeutet haben. Nun gibt es frei verfügbarer Werkzeuge für dieses Szenario. TokenSmith heißt das Tool von JumpsecLabs und ist auf GitHub verfügbar.
TokenSmith generiert Entra ID-Zugangs- und Aktualisierungs-Tokens für "offensive" Einsätze, in denen Angriffe simuliert werden. Das Tool eignet sich sowohl für verdeckte Angreifersimulationen als auch für Penetrationstests. Die generierten Token funktionieren sofort mit vielen gängigen Azure Post Exploitation Tools, schreibt der Entwickler.
Biehler meint, dass sich mit Hilfe des Tools gängige Conditional Access Regeln zur Gerätecompliance umgehen lassen und ergänzt: "Works as designed". Denn die Umgehung gelingt über die Intune-Portal / Unternehmensportal-App im Tenant, welche zur Registrierung der Geräte benötigt wird.
Das Problem: Ist ein Gerät nicht bekannt, kann es nicht compliant sein. Also muss das Intune-Portal die Compliance-Prüfungen umgehen können. Und genau dies lässt sich für Angriffe missbrauchen. Über die Graph-API lassen sich mit den geklauten Tokens und bekannten Tools wie GraphRunner anschließend alle gängigen Angriffe auf den Tenant durchführen, schreibt Biehler. Es wird lediglich ein gültiger Zugang (per Phishing, PW-Spray etc.) benötigt.
Christian Biehler hat das gesamte Thema samt den damit verbundenen Problemen zum 28. Dezember 2024 im Beitrag Microsoft 365 – Geräte-Compliance-Bypass aufbereitet und zusammen gefasst. Die Abwehr von Angriffen umschreibt er als "schwierig". Vielleicht für den einen oder anderen Intune-Administrator von Interesse.
Anzeige
Zitat: "Das Problem: Ist ein Gerät nicht bekannt, kann es nicht compliant sein.
Also muss das Intune-Portal die Compliance-Prüfungen umgehen können"
Macht ja dann richtig viel Sinn Zeit und Ressourcen in eine solche Konfiguration im Bereich A zu stecken wenn es durch Bereich B ausgehebelt wird. Failed by Design würde ich mal sagen, oder genau so gewollt dank Patriot Act ?!
Der Fail ist nicht, dass man auf Intune zugreifen kann, sondern dass man anschließend einen gültigen Token erhält mit dem der Zugriff auf andere Ressourcen möglich ist.
Das Microsoft eine Hintertür absichtlich wegen dem Patriot Act einbaut ist ziemlich unsinnig.
Dass Microsoft (und Apple, Google usw.) Hintertüren mit voller Absicht einbauen, ist spätestens seit dem Cloud Act sehr klar.
https://de.wikipedia.org/wiki/CLOUD_Act
Dass man den Conditional Access (CA) noch ausgehebelt bekommt, obwohl Intune ein Gerät über die Compliance Policy wegen Nichtkonformität markiert hat, kann ich noch irgendwie nachvollziehen.
Wenn aber tatsächlich Angriffe auf den Tenant gefahren werden, dann glaube ich eher, dass der CA nicht ordentlich konfiguriert (z. B. mit Richtlinien für Benutzer und Gruppen, Beschränkung von IP-Adressen bzw. -Adressbereichen, …) wurde. Oder wie holen sich die Angreifer die erforderlichen Rechte, um sich im Tenant ausbreiten zu können?
Mal davon abgesehen: Wer blickt bei den vielen Admin Centern, Portalen und Diensten von Microsoft noch durch? Microsoft 365 Admin Center, Exchange Admin Center, Microsoft Purview, Microsoft Purview Compliance Portal, Microsoft Priva, Microsoft Viva, Microsoft Intune Admin Center, Microsoft Entra Admin Center, Microsoft Entra ID, Microsoft 365 Defender Portal, Microsoft Defender Security Center, …
Nicht unbedingt ausbreiten, eher mit den Rechten des Nutzers das machen, was er eben können/machen soll nur eben von jedem x-beliebigen Gerät aus.
Wie schon geschrieben wurde sind IP Source Beschränkungen meist in der Form wenig zielführend weil der Standort nicht fix ist. Und ggf. nichtmal eine VPN Verbindung existiert, also die Source IP überhaupt kontrollierbar ist.
Simples Beispiel, du nutzt Exchange Online und willst administrativ erzwingen, dass sich nur Firmengeräte auf die Mailbox verbinden, damit geschäftsrelevante Daten nicht auf bspw. privat PCs abgelegt oder zwischengespeichert werden. Es gibt also eine CA Richtiline mit eben diesen Parametern. Standort variabel, weil der Mitarbeiter ja auch unterwegs sein könnte. User/PW/2FA/Key whatever hat der Nutzer auch.
Im Fall von EXO ist das ggf. noch etwas weiter her geholt, da man wohl weniger die API bemüht, aber in Sachen Administration der Ressourcen oder bei Schnittstellen zwischen Systeme ist das faktisch ein Problem.
Früher ohne Cloud war das weniger wirklich relevant, weil die Ressourcen nicht online waren. Aber in der Cloud ist es halt perse erstmal offen.
Zum besseren Verständnis hilft der im letzten Absatz verlinkte Artikel weiter. Evtl. muss man sich in der Materie auch ein wenig auskennen, um das Ganze zu verstehen:
Damit ein neues Gerät als konform erkannt werden kann, muss es erst mal registriert werden. Damit ein Admin (bei großen Firmen, etc.) das nicht dutzendfach täglich manuell machen muss, gibt es entsprechende APIs im Intune, mit denen sich das (teilweise) automatisieren lässt. Und genau da gibt es jetzt anscheinend eine Lücke, dass man über die API nicht nur neue Geräte registrieren, sondern gleich unter Umgehung der Conditional Access Regeln auf den ganzen Tenant zugreifen kann. Zumindest jedenfalls auf alles, auf das der ursprüngliche Benutzer hinter dem per Phishing oder anderen Methoden abgegriffenen Token von einem konformen Gerät aus zugreifen dürfte.
Danke an euch beide, P.B. und Klaus2.
Wir hatten das Thema Automatisierung bei einer Risikobeurteilung schon in einem anderen Kontext auf den Schirm, und zwar bei Windows Autopilot. Das Szenario: Interner "Lieferkettenangriff", bei dem sich der Angreifer die Ressourcen und etwaige Zugriffsrechte über die Templates (Images) verschafft, die mit Windows Autopilot ausgerollt werden. Ein anders gelagertes Szenario sah den Rollout von kompromittierten Templates vor, da ja mittlerweile viel über die Cloud läuft.
Es bleibt spannend.