Die Cybersicherheit ist ein dynamisches Feld, in dem ständige Wachsamkeit und das Verständnis für neu auftretende Bedrohungen und deren Umgehungsmöglichkeiten unerlässlich sind. In diesem Zusammenhang rückt die Umgehung von Sicherheitsmechanismen wie dem App Control von Microsoft Defender for Cloud Apps (MDA) in den Fokus. Dieser Artikel beleuchtet eine spezifische Methode, die auf dem Einsatz eines modifizierten User-Agent-Strings basiert, insbesondere im Zusammenhang mit der Applikation “Teams 1.4.00.35564”. Wir analysieren, wie diese Technik funktioniert und welche Implikationen sie für die Sicherheit von Cloud-Anwendungen hat.
Microsoft Defender for Cloud Apps, in Verbindung mit Azure AD und dem Conditional Access App Control, bietet eine robuste Plattform zur Erkennung, Abwehr und Eindämmung von Cloud-Risiken und Sicherheitsproblemen. Die Funktionalitäten reichen von der Überwachung von Sitzungen bis hin zur Durchsetzung von Richtlinien. Es ist jedoch wichtig zu verstehen, dass diese Systeme, wie jedes komplexe Sicherheitssystem, potenzielle Schwachstellen aufweisen können, die von Angreifern ausgenutzt werden können.
Die hier beschriebene Umgehungsmethode ist ein Szenario von mehreren, das darauf abzielt, den Session-Proxy zu umgehen. Wir werden uns auf diesen speziellen Fall konzentrieren und die zugrunde liegenden Mechanismen beleuchten. Es ist wichtig zu betonen, dass es fortlaufend Möglichkeiten gibt, Agenten-Imitationen zu beschränken und zu verhindern, und dass die in diesem Beitrag beschriebenen Techniken nicht als Anleitung zur Verletzung von Sicherheitsrichtlinien verstanden werden sollten, sondern vielmehr zur Aufklärung über potenzielle Sicherheitslücken dienen.
Im nächsten Beitrag werden wir uns der Erkennung und Abwehr dieser Umgehungen mit MDA und Microsoft Sentinel widmen und so ein umfassenderes Bild der Sicherheitslandschaft zeichnen.
Der Session-Proxy im Überblick
Die Integration von Microsoft Defender for Cloud Apps (MDA) in Ihre Conditional Access-Richtlinien ermöglicht es, Benutzersitzungen zu Cloud-Anwendungen über MDA umzuleiten. MDA fungiert dabei als Reverse-Proxy und bietet die Möglichkeit, die Sitzung und den gesamten Datenverkehr, der durch diese Sitzung fließt, zu steuern.
Um diese “Cloud Application Reverse Proxy”-Funktionalität durch MDA nutzen zu können, muss die Anwendung über Azure AD zugänglich sein. Sollte eine Cloud-Anwendung auf andere Weise erreichbar sein, beispielsweise durch eine Benutzeranmeldung mit einem Konto und Passwort, das von einem anderen Identitätsanbieter stammt, greift die MDA-Integration nicht in gleicher Weise.
Bei der Integration mit Azure AD Conditional Access können Anwendungen so konfiguriert werden, dass sie mit dem Conditional Access App Control zusammenarbeiten. Dies ermöglicht die schnelle und selektive Durchsetzung von Zugriffs- und Sitzungssteuerungen für die Anwendungen Ihrer Organisation, basierend auf beliebigen Bedingungen im Conditional Access.
Die definierten Bedingungen legen fest, für wen eine Conditional Access-Richtlinie gilt. Nachdem diese Bedingungen festgelegt wurden, können Benutzer an Microsoft Defender for Cloud Apps weitergeleitet werden, wo Daten durch die Anwendung von Zugriffs- und Sitzungssteuerungen geschützt werden können. Das Conditional Access App Control ermöglicht die Überwachung und Steuerung des Benutzerzugriffs auf Anwendungen und deren Sitzungen in Echtzeit, basierend auf definierten Zugriffs- und Sitzungsrichtlinien. Das Portal von Microsoft Defender for Cloud Apps nutzt diese Richtlinien, um Filter weiter zu verfeinern und Aktionen für Benutzer festzulegen.
Schematische Darstellung eines Session-Proxys in der Cloud-Sicherheit
Anwendungsfälle für das Conditional Access App Control
MDA und das App Control können in einer Vielzahl von Szenarien eingesetzt werden, von der reinen Erkennung bis hin zu Data Loss Prevention (DLP)-Szenarien. Microsoft stellt ein Whitepaper zur Verfügung, das 20 Anwendungsfälle für die Nutzung eines Cloud App Security Brokers (CASB) über Microsoft Defender for Cloud Apps detailliert beschreibt.
Zu den in diesem Whitepaper genannten Anwendungsfällen gehören unter anderem:
- Entdeckung aller Cloud-Anwendungen und -Dienste, die in Ihrer Organisation genutzt werden.
- Bewertung des Risikos und der Compliance von Cloud-Anwendungen.
- Verwaltung entdeckter Cloud-Anwendungen und Erkundung unternehmensgerechter Alternativen.
- Durchsetzung von DLP- und Compliance-Richtlinien für sensible Daten, die in Ihren Cloud-Anwendungen gespeichert sind.
- Sicherstellung sicherer Kollaborations- und Datenaustauschpraktiken in der Cloud.
- Durchsetzung adaptiver Sitzungssteuerungen zur Echtzeitverwaltung von Benutzeraktionen.
- Erfassung eines Audit-Protokolls für alle Benutzeraktivitäten in hybriden Umgebungen.
- Erkennung von Bedrohungen durch privilegierte Konten.
- Identifizierung und Widerruf von Zugriffen auf riskante OAuth-Apps.
- Erfassung von Benutzeraktivitäten innerhalb benutzerdefinierter lokaler und Cloud-Anwendungen.
Der Link zum genannten Whitepaper ist in den Referenzen aufgeführt.
Sitzungssteuerung in Aktion
Die Erstellung einer Sitzungsrichtlinie mit dem Conditional Access App Control ermöglicht die Verwaltung von Benutzersitzungen durch Umleitung des Benutzers über einen Reverse-Proxy anstatt direkt zur spezifischen Anwendung. Alle Benutzeranfragen und -antworten durchlaufen Microsoft Defender for Cloud Apps (MDA) und nicht direkt die Anwendung selbst.
Wenn eine Sitzung durch den Proxy geschützt ist, werden alle relevanten URLs und Cookies durch Microsoft Defender for Cloud Apps (MDA) ersetzt. Beispielsweise, wenn eine Anwendung eine Seite mit Links zurückgibt, deren Domains mit myapp.com enden, wird die Domain des Links mit einem Suffix wie *.mcas.ms versehen.
Mögliche Domain-Suffixe, die in Transparenzprotokollen erscheinen können, sind:
*.msmcasproxy.**.-rs-mcas.ms*.rs-mcas.ms*.-rs2-mcas.ms*.rs2-mcas.ms*.admin-mcas.ms*.mcas.ms
Beim Zugriff auf Cloud-Anwendungen wie SharePoint Online, AWS oder andere, werden Sie daher feststellen, dass ihre URLs mit einem der genannten Domains, wie z.B. *.cas.ms, *.mcas.ms etc., versehen sind.
Betrachten wir zum Beispiel SharePoint Online unter Überwachung mit dem Session-Proxy. Wir könnten den gesamten Datenverkehr mit allen Proxy-Domains sehen, sofern sie zur mcas-Domäne oder den Azure Proxy-Domänen gehören. In den Sitzungsdetails könnten die Kopfzeilen eingesehen werden, um zu sehen, welche Domains Teil dieser Sitzungen sind, sowie die Anfragen.
Dies ist ein normales Verhalten, das aus dem Schutz Ihrer Umgebung durch Microsoft Defender for Cloud Apps (MDA) resultiert. Selbst wenn Ihre Organisation MDA nicht nutzt, werden die URLs von Besuchern Ihrer Website oder Ihres Dienstes, die aus einer Umgebung stammen, in der MDA aktiv ist, neu geschrieben, um ihren Zugriff zu schützen.
Beispielhafte Darstellung von Sitzungsdaten in einem Proxy-Log
Die Frage, welche Komponenten den Proxy-Sitzungsdienst bereitstellen, wird durch die folgenden Elemente beantwortet:
Zugriffskontrollen (Access Controls): Viele Organisationen, die Sitzungssteuerungen für Cloud-Anwendungen verwenden, um Aktivitäten innerhalb einer Sitzung zu kontrollieren, wenden auch Zugriffskontrollen an, um native mobile und Desktop-Client-Anwendungen zu blockieren. Dies bietet einen umfassenden Schutz für die Anwendungen. Der Zugriff auf native mobile und Desktop-Client-Anwendungen kann durch Zugriffspolitiken erfolgen, indem der Client-App-Filter auf “Mobil und Desktop” gesetzt wird. Einige native Client-Anwendungen können einzeln erkannt werden, während andere, die Teil einer Suite von Anwendungen sind, nur als oberste Ebene erkannt werden können. Beispielsweise kann die Anwendung SharePoint Online nur durch die Erstellung einer Zugriffspolitik erkannt werden, die auf Office 365-Anwendungen angewendet wird.
Sitzungssteuerungen (Session Controls): Sitzungssteuerungen sind so konzipiert, dass sie mit jedem Browser auf jedem gängigen Betriebssystem funktionieren. Unterstützt werden Microsoft Edge, Google Chrome, Mozilla Firefox und Apple Safari. Der Zugriff auf mobile und Desktop-Anwendungen kann ebenfalls blockiert oder erlaubt werden.
App-Konnektoren (App Connectors): Durch die Nutzung von API-Konnektoren können die von MCAS gesammelten Informationen auf die Anwendungsdienste erweitert werden, die diese Art von API-Verbindungen unterstützen. Die meisten SaaS-basierten Anwendungen von Microsoft werden in diesem Szenario unterstützt. Auf der Website werden folgende Anwendungen mit API-Verbindungen aufgeführt:
- Office 365
- GCP
- ServiceNow
- Salesforce
- AWS
- Workday
- und weitere
Welche Daten entdeckt werden können, hängt von der Funktionalität ab, die vom Hersteller der App bereitgestellt wird.
Nutzung des Conditional Access App Control
Das Conditional Access App Control agiert als Reverse-Proxy, der die Sitzung des Endbenutzers an Microsoft Defender for Cloud Apps (MDA) umleitet, um Aktivitäten in Echtzeit zu überwachen. Dies ermöglicht eine feinere Kontrolle über die Sitzung und die Bedingungen, die in den Zuweisungen der Conditional Access-Richtlinien festgelegt sind.
Für diese Steuerung gibt es drei Optionen, die Signale von MCAS nutzen, um Aktionen durchzuführen:
- Nur überwachen (Monitor Only): Diese Option protokolliert und auditiert Aktivitäten innerhalb der Sitzung, ohne weitere Aktionen gegen die Sitzung durchzuführen. Überwachungsdaten können in MDA für Compliance- oder andere Sicherheitszwecke überprüft und dann in eine entsprechende benutzerdefinierte Sitzungsrichtlinie umgewandelt werden.
- Downloads blockieren (Block downloads): Diese Option kann das Herunterladen, Kopieren und Drucken von Dokumenten verhindern. Sie kann dazu dienen, die Exfiltration von Daten von nicht verwalteten Geräten zu unterbinden.
- Benutzerdefinierte Richtlinie (A custom policy): Hierbei werden innerhalb von MDA erstellte Richtlinien zur Durchsetzung von Aktionen verwendet. Dies kann nahezu jede Zugriffs- oder Sitzungsrichtlinie umfassen, die MDA konfigurieren kann, wie z.B. die Erzwingung der Nutzung von Vertraulichkeitsbezeichnungen, DLP oder die vollständige Sperrung des Zugriffs.
Bekannte Einschränkungen
- Proxy-Umgehung durch eingebettete Sitzungstoken: Es ist möglich, den Proxy zu umgehen, wenn die Anwendung das Token direkt in Links einbettet. Der Endbenutzer kann den Link kopieren und direkt auf die Ressource zugreifen.
- Parameteränderung zur Umgehung des Proxys: Durch die Änderung von Parametern kann die definierte Sitzungsrichtlinie umgangen werden. Beispielsweise ist es möglich, die URL-Parameter zu manipulieren, um den Proxy zu täuschen und den Download einer sensiblen Datei zu ermöglichen.
Verhalten bei Umgehungsversuchen
Wenn ein Benutzer, auf den die CA-Richtlinie anwendbar ist, von einem nicht verwalteten (oder nicht konformen) Gerät auf https://sharepoint.microsoft.com zugreift, wird die Sitzung zu MCAS umgeleitet. Dies ist an der URL ersichtlich, die in diesem Fall lautet: https://domain.access-control.cas.ms/aad_login.
Die erste Seite, die der Benutzer sieht, ist eine benutzerdefinierte Seite mit dem Firmenbranding, die darauf hinweist, dass der Zugriff auf SharePoint Online überwacht wird. Der Benutzer hat die Option, diese Seite für eine Woche zu unterdrücken, wird aber danach erneut daran erinnert.
Die Umgehung: Wie “Teams 1.4.00.35564” ins Spiel kommt
Reverse-Proxys funktionieren, indem sie Interaktionen zwischen Benutzern und den von ihnen aufgerufenen Anwendungen vermitteln. Wenn Benutzer verwaltete Anwendungen öffnen und sich authentifizieren, wird der Reverse-Proxy in den Datenverkehrspfad eingefügt, um Daten während der Übertragung zu überwachen und Schutzmaßnahmen in Echtzeit anzuwenden. Im Wesentlichen ist der Proxy ein Code-Mittelsmann, der sich für die Anwendung als Benutzer ausgibt und die Sitzung für den Benutzer virtualisiert. Im Gegensatz zu MAM bewahrt ein Reverse-Proxy das native Benutzererlebnis der Anwendungen.
Bei verschiedenen Authentifizierungsmethoden kann der Wert des “User-Agent”-Headers in einer Anfrage verwendet werden, um zu bestimmen, ob eine Benutzerauthentifizierung durchgeführt wird. Dies ist nützlich, wenn Sie Benutzer mit einer bekannten Gruppe von Anwendungen, typischerweise Browsern, authentifizieren und andere Anwendungen über einen Reverse-Proxy zulassen möchten.
Wenn eine Webseite angefordert wird, wird eine GET-Anfrage für diese Seite an den Server gesendet. Diese GET-Anfrage enthält verschiedene Parameter wie Host, Cookies, Sicherheitsheader und viele andere. Einer dieser Parameter ist der “User-Agent”, der dem Server mitteilt, von welchem Client-Typ die Seite angefordert wird. Dies kann dem Server ermöglichen, basierend auf dem Wert im “User-Agent” zu entscheiden, was gesendet werden soll.
Generell ermöglicht der Reverse-Proxy, dass Geräte den SAML-Authentifizierungsprozess durchlaufen. Infolgedessen werden autorisierte Anwendungen von allen verwalteten oder nicht verwalteten Geräten zum CASB-Proxy umgeleitet. Wenn Sie jedoch Office 365 verwenden und sich über Azure Active Directory authentifizieren, ist diese Methode nicht erfolgreich, da die Authentifizierung nicht über SAML-Authentifizierung umgeleitet wird.
Wenn das “User-Agent”-Feld verwendet wird, ist das kritische Element der reguläre Ausdruck (Regex), der den Abgleich durchführt.
- Der “^-Operator wird nicht unterstützt.
- Vordefinierte Regexes werden für die gängigsten Browser bereitgestellt.
- Wenn das Feld leer ist, stimmen alle User-Agent-Werte überein.
- Sie können einen benutzerdefinierten Regex erstellen, indem Sie das Feld direkt bearbeiten.
- Mehrere Regexes sind erlaubt.
Der User-Agent-Anfrage-Header ist eine Zeichenkette, die es Servern und Netzwerk-Peers ermöglicht, die Anwendung, das Betriebssystem, den Anbieter und die Version des anfordernden User-Agents zu identifizieren.
Die User-Agent-Zeichenkette eines Browsers (UA) hilft dabei, den verwendeten Browser, seine Version und das Betriebssystem zu identifizieren. Wie alle anderen Browser sendet ein Chrome-basierter Browser diese Informationen bei jeder Anfrage an eine Website oder App im User-Agent-Header. Wenn Feature-Detection-APIs nicht verfügbar sind, wird die UA verwendet, um das Verhalten oder den Inhalt für bestimmte Browserversionen anzupassen.
Ein User Agent ist eine Datenzeichenkette, einschließlich Browsername, Version, Betriebssystem und Gerätetyp, die Ihr Browser an jede Website sendet, mit der Sie sich verbinden, um die Anzeige des Inhalts an Ihr Gerät anzupassen. Da der User-Agent eine Reihe von Informationen über jeden Website-Besucher liefert, nutzen Vermarkter oft die User-Agent-Daten, um ihren Anzeigenverkehr mit ihren Zielkriterien abzugleichen. Sie überprüfen beispielsweise, ob der Gerätetyp mobil ist, um den Traffic als gültig für eine mobile Werbekampagne einzustufen. Der User-Agent kann jedoch durch eine Taktik namens User-Agent-Spoofing manipuliert werden.
Beim User-Agent-Spoofing modifizieren böswillige Akteure Elemente der User-Agent-Zeichenkette, um ihre Verkehrsdetails zu verschleiern. Sie lassen beispielsweise hohe Traffic-Volumina von einem einzigen Gerät wie viele individuelle Werbeinteraktionen von mehreren Geräten aussehen.
Wie die Umgehung mit “Teams 1.4.00.35564” gelingt
Durch das Setzen einer User-Agent-Zeichenkette in Ihrem Browser können Sie die vom Microsoft Defender for Cloud Apps Proxy angebotenen Schutzmaßnahmen umgehen. Die Aktionen, die umgangen werden können, umfassen Kopieren, Einfügen, Herunterladen usw.
Die User-Agent-Zeichenkette kann über ein User-Agent-Switcher-Plugin oder das User-Agent-Switching im Browser verwendet werden. Führen Sie zur Umgehung die folgenden Schritte aus:
Öffnen Sie Ihren Webbrowser und verwenden Sie den Chrome User-Agent Switcher als Teil der Entwicklertools. Öffnen Sie diese, indem Sie auf das Menü-Symbol klicken und dann “Weitere Tools” -> “Entwicklertools” auswählen. Sie können auch die F12-Taste auf Ihrer Tastatur verwenden.
Entwicklertools im Chrome-Browser mit der Option User-Agent Switcher
Anschließend können Sie einen spezifischen User-Agent-Browser und eine Zeichenkette auswählen. Am wichtigsten ist die Zeichenkette. Sie können die bereits für dieses Szenario geprüften Zeichenketten verwenden, die unten aufgeführt sind.
Hinweis: Da diese Einstellung temporär ist, funktioniert sie nur, wenn das Entwicklertools-Panel geöffnet ist und nur für den aktuellen Tab. Der beste Weg ist daher, den User-Agent in der Browserkonfiguration oder einer Flag-Option zu ändern oder einen User-Agent-Switcher zu verwenden.
TIPP: Sie können einen spezifischen User-Agent erstellen oder die Erweiterung ‘User-Agent Switcher for Chrome’ herunterladen und installieren.
Beispiel für die Installation einer User-Agent Switcher-Erweiterung im Chrome Web Store
Hinweise:
- Erstellen Sie eine User-Agent-Zeichenkette unter Verwendung der folgenden User-Agent-Strings.
- Stellen Sie den neuen User-Agent als aktiv innerhalb der Erweiterung ein.
- Navigieren Sie zu einem der durch Microsoft Defender for Cloud Apps geschützten Dienste.
- Beobachten Sie, dass Sie nun auf die reguläre Website zugreifen und nicht mehr über den Microsoft Defender for Cloud Apps Proxy geleitet werden.
User Agent Strings für die Umgehung
Hier sind die spezifischen User-Agent-Strings, die für die Umgehung des Proxys mittels der “Teams 1.4.00.35564”-Applikation von Bedeutung sind:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Powerpoint/1.4.00.35564 Chrome/85.0.4183Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.4.00.35564 Chrome/85.0.4183.121Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.4.00.35564 Chrome/85.0.4183.121 Electron/10.4.7 Safari/537.36Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) MicrosoftTeams-Preview/1.3.00.5153 Chrome/69.0.3497.128 Electron/4.2.12 Safari/537.36Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)Mozilla/5.0 (iPhone; CPU iPhone OS 15_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148
TIPP: Sie können die Anwendung, die der Proxy-Sitzung nicht verwendet, ersetzen, und dann wird die Umgehung stattfinden. Sie können es sogar noch einfacher machen und die Seite eines der vielen Dienste aufrufen, die Ihren User-Agent anzeigen: https://suip.biz/?act=my-user-agent
Darstellung eines umgeleiteten oder manipulierten User-Agents mit einer Warnung
Spoofing des MDA App Proxy mit Burp Suite
Zusätzlich können Sie denselben Test mit Burp Suite durch die folgenden Aktionen durchführen:
- Gehen Sie in Burp Suite zum Tab “Proxy” -> “Options” und suchen Sie den Abschnitt “Match and Replace”. Dort gibt es bereits mehrere Regeln zum Ersetzen des User-Agents, um Anfragen von verschiedenen Geräten zu emulieren.
- Sie können bestehende Regeln einschließen oder eine neue erstellen. Um eine neue zu erstellen, klicken Sie auf die Schaltfläche “Add”.
- Wählen Sie für “Type” die Option “Request header”.
- Geben Sie im Feld “Match”
^User-Agent.*$an. - Geben Sie im Feld “Replace” den Wert ein, der den HTTP-Header des User Agents ersetzen wird – verwenden Sie hierfür dieselben Zeichenketten wie zuvor.
- Geben Sie im Feld “Comment” einen beliebigen Kommentar ein, um sich schnell zu merken, wofür dieser Titel bestimmt ist.
- Aktivieren Sie das Kontrollkästchen “Regex match”.
Referenzen
Für weiterführende Informationen und zur Überprüfung der technischen Details, die in diesem Artikel behandelt wurden, verweisen wir auf die folgenden Quellen:
- https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE3nibJ (Microsoft Whitepaper)
- https://docs.microsoft.com/en-us/defender-cloud-apps/troubleshooting-proxy-url (Microsoft Dokumentation zur Proxy-URL-Behandlung)
- https://docs.microsoft.com/en-us/cloud-app-security/enable-instant-visibility-protection-and-governance-actions-for-your-apps#how-it-works (Microsoft Dokumentation zu Sichtbarkeit und Governance-Aktionen)
- https://user-agents.net/ (Ressource für User-Agent-Strings)
- https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (OWASP Cheat Sheet zur Sitzungsverwaltung)