Conditional Access ist eine der leistungsstärksten Sicherheitsfunktionen von Microsoft und der zentrale Motor ihrer Zero-Trust-Architektur. Unserer Meinung nach sollte dies die Grundlage jeder Zero-Trust-Strategie von Organisationen sein, die auf cloud basieren. Wenn Sie jedoch nicht verstehen, wie die Zugangskontrolle funktioniert, könnte sie Ihnen ein falsches Gefühl der Sicherheit vermitteln. In diesem Blogartikel zeigen wir Ihnen, warum es wichtig ist, den Prozess der Bewertung einer Conditional Access Policy zu verstehen und wie Sie Schwachstellen in der Konzeption einer Strategie finden und ausnutzen können.
Über die Zugangskontrolle
Conditional Access ist eine Funktion von Azure AD Premium und ist standardmäßig deaktiviert. Es gibt eine Funktion namens Sicherheitsstandardwerte, die zum Tragen kommt, wenn keine Richtlinien eingerichtet sind, die aber nicht in den Geltungsbereich dieses Artikels fallen. Auch die Sicherheitsstandardwerte sind immer deaktiviert, wenn Sie eine oder mehrere Richtlinien für die Zugangskontrolle eingerichtet haben.
Bei der Zugangskontrolle ist standardmäßig alles erlaubt. Und selbst wenn Sie eine, zwei oder drei Richtlinien erstellen, ist alles erlaubt, was Sie nicht explizit blockieren.
In fast allen Tenants, die wir sehen, gibt es Löcher in der Konzeption der Zugangskontrolle, weil sich die Administratoren zu sehr darauf konzentrieren, welche Anwendungsfälle sie zulassen wollen, und nicht darauf, was gesperrt werden sollte. Conditional Access-Strategien werden oft verkehrt herum entworfen, was den Tenant anfällig für Angriffe macht.
Passwörter und Zugangskontrolle
Es ist wichtig zu verstehen, dass die Conditional Access Policies in Azure AD nach der Genehmigung des ersten Faktors, nämlich des Benutzerpassworts, ausgewertet werden. Ich werde in diesem Artikel nicht auf die Techniken des Passwortdiebstahls eingehen, und alles, was ich hier erkläre, geschieht, nachdem das Passwort erfolgreich von Azure AD (oderAD vor Ort mit PTA oder ADFS) überprüft wurde. Erst nach dem ersten Faktor werden die Richtlinien für die Zugangskontrolle ausgewertet, und dem Benutzer wird je nach den Anforderungen der Zielrichtlinien der Zugang gewährt oder verweigert.
Funktionsweise verschiedener Conditional Access Strategien
Beim bedingten Zugriff werden alle Richtlinien bei jeder Verbindung ausgewertet. Dies gilt auch, wenn die Anforderungen jeder Richtlinie erfüllt sind. Die Summe aller Anforderungen aller übereinstimmenden Richtlinien entspricht dem, was der Benutzer und das Gerät erfüllen müssen, um Zugriff zu erhalten. Beispielsweise kann eine Übereinstimmungsrichtlinie die Multifaktor-Authentifizierung erfordern und eine andere kann verlangen, dass das Gerät Folgendes erfüllt Intune. Da die beiden Richtlinien übereinstimmen, müssen beide Anforderungen erfüllt werden.
Die einzige Priorität unter den Strategien ist, dass die Blockierungsstrategien immer gewinnen. Das heißt, wenn eine oder mehrere Blockierrichtlinien bei einer Anmeldung übereinstimmen, wird der Authentifizierungsversuch blockiert, auch wenn andere Richtlinien gleichzeitig Zugriff gewähren.
Einige häufige Schwachstellen
Natürlich ist der beste Weg, eine Zugangskontrolle anzugreifen, sie überhaupt nicht auszulösen, sondern sie zu vermeiden. Es gibt in fast allen Organisationen gemeinsame Schwachstellen, die missbraucht werden können.
Missbrauch einer ausgrenzenden Gruppe
Es wird empfohlen, immer eine Sicherheitsgruppe von allen CA-Richtlinien auszuschließen. Diese Gruppe sollte zwei "Break Glass Accounts" enthalten, die Sie im Notfall verwenden können. Diese Gruppe sollte keine anderen Konten enthalten, aber in der Realität ist dies fast immer der Fall. Administratoren werden schlampig und fügen sich selbst, Dienstkonten oder beschwerdeführende Benutzer zu dieser Gruppe hinzu. Indem wir das Passwort von einem dieser Konten stehlen, können wir die Zugangskontrolle ignorieren.
Fehlende Blockstrategien
Administratoren neigen dazu, Richtlinien zu erstellen, um die Multifaktor-Authentifizierung für einige oder alle Anwendungen eines Kunden durchzusetzen. Aber sie schließen oft Bedingungen in diese Richtlinien ein, wie z. B. erlaubte Plattformen oder erlaubte Standorte. Was sie nicht verstehen, ist, dass ein Angreifer, wenn wir unerwünschte Szenarien nicht mit einer entsprechenden Blockierungsrichtlinie blockieren, einfach den Standort oder die Plattform missbrauchen kann, um die Richtlinie zu umgehen und sich direkt anzumelden. Dies ist größtenteils das, was der Rest dieses Leitfadens darstellen wird.
Dies ist die allgemeine Fehlermeldung, die ein Benutzer erhält, wenn ein Zugriff durch eine Sperrstrategie verweigert wird. Beachten Sie, dass die Blockierfehlermeldung je nach den Bedingungen der Blockierstrategie unterschiedlich ausfallen kann. Sie soll dem Benutzer helfen, zu verstehen, was falsch gelaufen ist (siehe jede Bedingung weiter unten).
Verwenden Sie den Abschnitt Weitere Informationen, um zu sehen, ob es Hinweise auf die Bedingung gibt, die die Blockierung ausgelöst hat, z. B. den Standort der IP-Adresse, den Verwaltungsstatus des Geräts oder die Zielanwendung.
Missbrauch von Bedingungen
Bedingungen werden verwendet, um zu bestimmen, ob eine Richtlinie angewendet werden soll oder nicht. Wenn bei der Anmeldung alle Bedingungen erfüllt sind, werden die Zugriffskontrollen dieser Richtlinie angewendet, z. B. Multi-Faktor-Authentifizierung verlangen oder ein konformes Gerät verlangen. Im Folgenden werden einige Beispiele dafür gegeben, wie jede Art von Bedingung getäuscht werden kann.
Benutzerrisiko / Verbindungsrisiko
Das Benutzer- und das Anmelderisiko sind Teil vonAzure AD Identity Protection (Azure AD Premium P2). Das bedeutet, dass die meisten Microsoft 365 Kunden sie nicht aktiviert haben und dass dies für einen Angreifer kein Problem darstellen wird. Wenn er jedoch aktiviert ist, muss der Angreifer versuchen, sich wie der Benutzer zu verhalten, der Besitzer des gestohlenen Kontos ist, das im Angriff verwendet wurde. Azure AD Identity Protection erkennt Verbindungen aus neuen Ländern, anonyme IP-Adressen, schwarz markierte, offengelegte Anmeldeinformationen usw. Ein Angreifer sollte den Benutzer recherchieren und dann VPNs und andere Techniken verwenden, um die Verbindung so legitim wie möglich erscheinen zu lassen.
Hier sehen Sie, was Sie sehen, wenn eine Sperrstrategie durch diese Bedingung ausgelöst wird:
Geräteplattformen
Die Plattform des Geräts ist leicht zu usurpieren. Sie basiert auf der Benutzeragentenkette der Client-Anwendungen . Wenn eine Richtlinie die Plattformbedingung enthält, die Windows, iOS oder Android erfordert, können Sie Ihre Benutzeragentenkette einfach durch etwas anderes ersetzen, z. B. durch ein Mac-Gerät, ein Linux-Gerät oder eine Raumstation. Es handelt sich einfach um eine Textzeichenfolge und die Zugangskontrolle interpretiert sie, um nach dem Betriebssystem zu suchen. Es wird empfohlen, eine Blockierrichtlinie zu haben, die alle unerwünschten Plattformen blockiert.
So können Sie Ihren User-Agent-String mit den Entwicklertools in Microsoft Edge bearbeiten :
Hier sehen Sie, was Sie sehen, wenn eine Sperrstrategie durch diese Bedingung ausgelöst wird:
Orte
Die Standortbedingung basiert auf der IP-Adresse. Das sind die sogenannten benannten Standorte in Azure AD und können auf bestimmte IP-Adressbereiche oder Länder festgelegt werden. Wenn es eine Richtlinie gibt, die bestimmte Länder blockiert, kann ein Angreifer dies leicht mit einem VPN-Dienst umgehen, der in demselben Land endet wie die Organisation. Wenn es eine Richtlinie gibt, die nur bestimmte IP-Adressen wie die öffentliche IP-Adresse des Unternehmens zulässt, wird es etwas kniffliger. Wenn der Angreifer bereits einen Fuß in das interne Netzwerk gesetzt hat, könnte er dies umgehen. Da die meisten Angriffe heutzutage aus dem On-Premise-Bereich kommen, ist dies sehr wahrscheinlich.
Hier sehen Sie, was Sie sehen, wenn eine Sperrstrategie durch diese Bedingung ausgelöst wird:
Client-Anwendungen
Client-Anwendungen bedeuten Protokolle. Welches Protokoll verwendet der Client bei der Authentifizierung beiAzure AD . Viele Organisationen beginnen, alte Protokolle wie POP3, IMAPund SMTP zu blockieren, indem sie Other und ActiveSync mit Conditional Access blockieren. Aber es gibt fast immer Schwachstellen wie ausgeschlossene Konten, "Break Glass Account", ausgeschlossene Administratorrollen etc. Testen Sie verschiedene Protokolle, um zu sehen, ob der Versuch blockiert wird. Dies kann Ihnen helfen zu verstehen, was beim Entwurf der Richtlinie erlaubt ist.
Die moderne Authentifizierung kann von nicht verwalteten Geräten aus blockiert werden, und in diesem Fall können Sie versuchen, auf ein Firmengerät zuzugreifen (falls die Website kompromittiert wurde), oder Sie können ein Tool wie AAD Internals ausprobieren, das die Möglichkeit beinhaltet, ein gefälschtes, kompatibles Gerät Azure AD hinzuzufügen und gegebenenfalls dem Zielkunden zu gewähren. Sie könnten Glück haben, einen solchen Angriff von zu ziehen.
Der Zugriff auf den Browser wird fast nie von irgendjemandem blockiert, so dass die Browserportale wahrscheinlich Ihr Weg sein würden.
Hier sehen Sie, was Sie sehen, wenn eine Sperrstrategie durch diese Bedingung ausgelöst wird:
Status des Geräts
Die Bedingung für den Gerätestatus ist nicht anwendbar, da sie nur Geräte ausschließt und immer einschließt.
Missbrauch von Zugangskontrollen
Wenn Sie Glück haben, konnten Sie alle oben implementierten Bedingungen umgehen. In diesem Fall sind Sie bereits angemeldet und müssen nicht weiterlesen. Wenn aber hartnäckige Richtlinien im Weg sind, wäre Ihr nächster Schritt, die Zugriffskontrollen zu missbrauchen. Das ist schwieriger und erfordert etwas mehr Arbeit.
Wenn alle Bedingungen in einer Richtlinie übereinstimmen, müssen die Anforderungen unter Zugriffskontrollen in dieser Richtlinie erfüllt sein, andernfalls wird der Authentifizierungsversuch blockiert. Eine Richtlinie kann eine oder mehrere Anforderungen haben, und die Richtlinie kann so eingestellt werden, dass eine oder alle Anforderungen erfüllt werden müssen. Wie bereits erwähnt, können auch mehrere Richtlinien gleichzeitig übereinstimmen und unterschiedliche Prüfungen erfordern. In diesem Fall müssen alle unterschiedlichen Anforderungen der Strategien erfüllt werden.
Multifaktor-Authentifizierung verlangen
Dies ist die bei weitem am häufigsten verwendete Zugriffskontrolle. Sie erfordert, dass der Benutzer seine Identität bei der Multifaktor-Authentifizierung überprüft. Es gibt viele bekannte MFA Angriffe, wie z. B. den Diebstahl von Token MFA, Telekommunikationsmissbrauch (SMS-OTP-Übertragung) und verschiedene Phishing-Techniken, um den Benutzer zur Genehmigung zu verleiten. MFA. Ein Angreifer müsste bei einer dieser Angriffstechniken erfolgreich sein, um Zugriff zu erhalten. Beachten Sie, dass die Zugriffskontrolle MFA immer ausgelöst wird, wenn sie aktiviert ist, auch wenn eine der anderen Zugriffskontrollen ebenfalls zutrifft, aber fehlschlägt. Diese Fehlermeldungen werden nach der Überprüfung MFA angezeigt. Dadurch soll der Tenant vor Fuzzing-Angriffen mit bedingtem Zugriff geschützt werden.
Sie wissen, dass Sie von dieser Zugriffskontrolle angesprochen werden, wenn Sie Folgendes sehen:
Fordern Sie ein Hybridgerät, das an Azure AD
Diese Bedingung erfordert einen Hybrid-Tenant mit synked-Geräten vor Ort. Wenn Sie diese Meldung sehen, wissen Sie, dass der Client ein Hybrid ist. Um diese Anforderung zu umgehen, können Sie den Angriff vor Ort starten. Ein Gerät am Standort ist wahrscheinlich bereits an Azure AD hybrid angehängt. Beachten Sie, dass diese Fehlermeldung zur Zugriffskontrolle immer vor der Fehlermeldung zur Einhaltung von Intune angezeigt wird, wenn beide aktiviert sind.
Sie wissen, dass Sie von dieser Zugriffskontrolle angesprochen werden, wenn Sie Folgendes sehen:
Verlangen, dass das Gerät als konform gekennzeichnet wird
Wenn es zwingend erforderlich ist, dass das Gerät den Richtlinien entspricht Intune, gibt es zwei Möglichkeiten, wie Sie vorgehen können. Sie können ein kompromittiertes Unternehmensgerät verwenden, das beiIntune registriert ist, und den Angriff von dort aus ausführen, oder Sie können versuchen, ein gefälschtes Gerät mit einem Tool wie AAD Internals zu registrieren, um darauf zuzugreifen. Beachten Sie, dass, wenn diese Fehlermeldung angezeigt wird, wenn Sie versuchen, sich von einem nicht verwalteten Gerät aus anzumelden, keine Richtlinie den Azure AD Hybrid-Join erfordert.
Sie wissen, dass Sie von dieser Zugriffskontrolle angesprochen werden, wenn Sie Folgendes sehen:
Eine genehmigte Clientanwendung verlangen
Diese Zugangskontrolle ist nur für iOS und Android und wird nicht mit anderen Plattformen funktionieren. Sie stellt sicher, dass sich der Benutzer mit einer zugelassenen Microsoft-Anwendung aus dem App Store anmeldet. Umgehen Sie dies, indem Sie Windows oder Linux verwenden.
Eine Strategie zum Schutz von Anwendungen verlangen
Dies erfordert den Schutz von Anwendungen Intune. Dies kann nur auf Android und iOS angewendet werden, damit ein Angreifer stattdessen einfach Windows oder Linux verwenden kann.
