Microsoft 365 – Angriffsvektor Apps

Die Cloud-Dienste von Microsoft sind mittlerweile in vielen Unternehmen angekommen. Deren Absicherung erfolgt nicht immer mit der notwendigen Professionalität. In unserem Beitrag „Microsoft 365 – Angriffsvektor Apps“ gehen wir auf die aktuelle Entwicklung der Bedrohungslage ein, jenseits von Basishärtung und MFA.

Hacking Microsoft 365

In den letzten Jahren haben immer wieder Angriffe gegen Benutzerkonten in der Cloud die Runde gemacht. Fehlende Mehrfaktorauthentifizierung (MFA) war hier meistens ein Schlüsselfaktor für erfolgreiche Angriffe. Seit einigen Monaten hat Microsoft zwangsweise die meisten (menschlichen) Accounts mit MFA ausgestattet, um zumindest den einfachen Angriffen gegen Benutzername und Passwort einen Riegel vorzuschieben. Die Angreifer haben deshalb natürlich nicht frustriert aufgegeben und sich einen anderen Job gesucht, sondern die Angriffstechniken und Vorgehensweise angepasst. So zeigt der MFA-Zwang von Microsoft zwar eine solide Wirksamkeit gegen Brute-Force-, Passwort-Spray- und Credential-Stuffing-Angriffe, da jedoch kein Phishing-resistentes MFA erzwungen wird, bleibt Social Engineering in Form von Phishing-Angriffen weiterhin ein attraktiver und funktionierender Angriffsvektor. Insbesondere im Unternehmensumfeld wird auch dieser Angriffsweg durch FIDO2-Keys zur Authentifizierung immer weiter erschwert. Wer seine M365-Umgebung im Griff hat, der pflegt ohnehin ein wirksames Conditional Access-Regelwerk und sammelt, verarbeitet und bearbeitet Log-Meldungen und Alarme zu Sign-In-Versuchen der Benutzerkonten.  

Wenn Benutzerkonten ein immer schwierigeres Angriffsziel werden, ist es Zeit für die nächste Evolutionsstufe. Und hier kommt das Konstrukt rund um die „Apps“ im Microsoft 365 Tenant zum Zuge.

Enterprise Applications und App Registrations

Wer einen Microsoft 365-Tenant hat, der hat dort auch Apps. Auf jeden Fall hat er Enterprise Applications, also Anwendungen, die von Benutzern verwendet werden können, um mit bestimmten Tools, z. B. der Graph CLI oder Microsoft Photos auf den Tenant zuzugreifen und dort im Rahmen der vorhandenen Berechtigungen Daten auszulesen oder zu verändern. 

Microsoft 365 unterscheidet zwei Arten von Dingen, die „App“ bzw. „Application“ heißen: 

  • Enterprise Applications: Global Built-in Apps, die Benutzern Zugriff auf den Tenant ermöglichen 
  • App Registrations: Custom Apps, die Benutzern oder der App selbst Zugriff auf den Tenant ermöglichen 

Beide haben ihren Charm aus Sicht eines Angreifers – weniger mit Blick auf „Illicit Consent Grant“ und co., dafür mehr mit Blick auf unerwünschten Zugriff auf die Daten im Tenant. 

Aber der Reihe nach. Wenn wir auf Microsoft 365 – Angriffsvektor Apps schauen, dann gibt es ein paar sicherheitsrelevante Themen zu beachten.

Berechtigungen & Directory Rollen

Über Apps können Benutzer und Angreifer auf die Graph API zugreifen. Hierbei gibt es mit Blick auf die möglichen Berechtigungen zwei wichtige Unterscheidungen:

  • Application-Berechtigungen:
    • Erlauben den Zugriff auf die, über die spezifizierte API nutzbaren Daten, aller Benutzer
  • Delegation-Berechtigungen:
    • Erlauben den Zugriff auf die, über die spezifizierte API nutzbaren Daten, des angemeldeten Benutzers

Einfaches Beispiel: Apps von Backup-Software verfügen typischerweise über Application-Berechtigungen, da der Dienst ja die Daten aller Nutzer sichern möchte. Anwendungen, die SSO über Azure verwenden möchten, haben typischerweise Delegation-Berechtigungen, weil sie nur dann zum Tragen kommt, wenn der Benutzer sich anmeldet.

Die Berechtigungen sind vielfältig und ermöglichen u.a. das Lesen/Schreiben/Senden von E-Mails, Auslesen/Ändern von OneDrive-Daten, Anlegen/Ändern/Löschen von Gruppen und Gruppenzuordnungen, Auslesen von Logs, … also so weitestgehend alles, was man als Angreifer benötigt. 

 

Zuweisung der Global Administrator Rolle für Apps

Es ist auch möglich, dass Apps Entra-Rollen zugewiesen werden. Also beispielsweise kann unsere App die Rollen – und auch die Berechtigungen – des Global Administrators zugewiesen bekommen. Verrückt? Ja, schon …

Anmeldung als …

Apps sind im Sinne von Conditional Access „Cloud Apps“ und tauchen dort für die Konfiguration auf. 

Unsere Custom App Registration taucht als Auswahl im Conditional Access-Regelwerk auf und kann hier konfiguriert werden. 

Conditional Access - Apps

Die Anmeldung an einer App im Microsoft-Tenant erfolgt entweder: 

  • Mit dem regulären Benutzerkonto und dessen Authentifizierung
    •  Geloggt entweder unter „User sign-ins (interactive)“ oder „User sign-ins (non-interactive)“
  • Dem Service Principal per Client Secret oder Certificate
    • Geloggt unter „Service principal sign-ins“

Ein „Service Principal“ ist ein technisches Dienstkonto. Dieses wird im Hintergrund – z. B. Nachts von der Backup-Software – für die Anmeldung und die folgenden Aktivitäten im Tenant verwendet. Naheliegenderweise kann ein „Service Principal“ keine Multifaktorauthentifizierung per App oder Yubikey durchführen. Ein Service Principal ist auch kein Benutzerkonto, was in Conditional Access direkt ausgewählt werden kann. Microsoft hat natürlich eine Lösung dafür – Lizenz vorausgesetzt.

Der Service Principal – Angriff!

Benutzerkonten sind per MFA abgesichert. Und Service Principals? 

Microsoft erlaubt zwei Arten von Authentifizierungen für Service Principals:

  • Client Secrets (=“Benutzername“ und „Passwort“)
    • Die Erstellung erfolgt in Entra 
    • Das symmetrische Passwort / Secret muss anschließend zur App übertragen werden  
  • Zertifikate (= asymmetrische Kryptographie)
    • Die Erstellung des Keys kann auf dem System erfolgen, was später die Zugriffe benötigt
    • Der asymmetrische Public-Key-Part kann Richtung Entra übertragen werden
    • Der private Key verlässt nie das System und ist auch dem Entra Admin nicht bekannt

Was bei TLS und SSH längst Standard ist (Public-Key-Kryptographie), ist bei Microsoft in der Cloud noch nicht so weit verbreitet. Der Unterschied wird schnell deutlich:

App-Zugriffe per Client-Secret
App-Zugriffe per Zertifikat
Client Secrets: Symmetrische Schlüssel erzeugt in Entra

Mit diesem Client Secret ist anschließend der Zugriff auf den Tenant im Namen der Application möglich. Einer legt es an, einer bekommt es zur Verwendung im Script oder in einer Anwendung. Somit kennen das Secret mindestens zwei Personen und eine Hand voll Systeme und Zwischenablagen – kein guter Start für eine sichere Beziehung. 

App-Zugriff per Client Secret

Der Zugriff per Client Secret lässt sich mit wenigen Zeilen PowerShell realisieren.

Übrigens: Ein neues Client Secret lässt sich nicht nur mit der Rolle „Global Administrator“ zufügen, sondern auch mit dem Cloud Application Administrator und vielen weiteren. Client Secrets gelten immer für die App mit all ihren Berechtigungen. Eine App hat immer Zugriff auf den gesamten Tenant (im Rahmen der gewährten Berechtigungen): Dev-CAT/Stage-Prod gehören damit nicht in allen Fällen in den gleichen Tenant!

M365 Apps absichern

Während sich Verteidiger auf die Absicherung von Benutzerkonten konzentrieren und endlich jedem Anwender MFA beibringen, sind die Angreifer schon einen Schritt weiter. Zwar sehen wir immer wieder Tenants, in denen der Break-Glass-Administrator noch ohne MFA und ohne jedes CA-Regelwerk unterwegs ist, aber auch dies wird nach den angepassten Empfehlungen von Microsoft so langsam weniger. 

Enterprise Apps und App Registrations? Tja … 

Achtung: Wildwuchs

Enterprise Apps können umfangreiche Berechtigungen im Tenant haben – oder gleich mit Rollen wie „Global Administrator“ arbeiten. Übrigens haben wir vor wenigen Wochen im Rahmen eines Audits genau das erlebt — von einem großen Anbieter für Security-Appliances im Rahmen einer PoC-Installation. Hier war die App direkt als Global Administrator unterwegs, damit auch alles bei der Installation funktioniert. Und täglich grüßt das Murmeltier in der IT.

Es gibt kaum ein Audit, in dem nicht irgendwelche verwaisten Apps rumliegen, Zertifikate und Client Secrets ausgelaufen sind und schlecht gesicherte Apps mit hohen Berechtigungen vorhanden sind. 

Schritt für Schritt ein bisschen sicherer

Apps im Tenant werden Ziel für Angriffe und zur Schaffung von Persistenz im Tenant bleiben. Solange deren Pflege so aussieht wie heute, wird dieser Angriffsvektor wohl eher stärker bespielt werden in nächster Zeit.

Aus Security-Sicht sind M365-Apps sind wie Software … oder wie Fernzugriffe … oder eine Kombination aus allem. Entsprechend sollten hier auch die grundlegenden Themen gelten, die im Rahmen eines Freigabeprozesses für Software und Fernzugänge vorzusehen sind. Also prozessual insbesondere:

  • Definition eines App-Freigabeprozesses mit App Owner / Manager
  • Definition von Mindestanforderungen an die App-Freigabe
    • Nutzung von Zertifikaten zur Authentifizierung
    • Minimale Berechtigungen
    • Deprovisionierungsprozess beschrieben 
  • Definition eines App-Lifecycle-Prozesses

Mit Blick auf die Apps ganz konkret sollten ein paar Dinge beachtet und geprüft werden:

  • Keine PoC-Installation im produktiven Tenant mit hohen Berechtigungen 
  • Prüfung der Berechtigungen (Permissions & Entra Rollen) 
  • Überwachung von Veränderungen an den Zugangsdaten von Apps (Update application – Certificates and secrets management)
  • Überwachung der Service Principal Sign-Ins
  • Überwachung von Veränderungen an den Permissions der Apps 
  • Steuerung und Überwachung von App Consents
  • Steuerung und Überwachung von App Registrations
  • Steuerung der „Enabled for users to sign-in“-Konfiguration der Enterprise Apps
  • Steuerung der „Assignment required“-Konfiguration der Enterprise Apps
  • Steuerung der „Visible to users“-Konfiguration der Enterprise Apps   

Das sind eine Menge Aufgaben, die im Rahmen eines kontinuierlichen Monitorings der Microsoft 365-Umgebung aber mit dazu gehören und die Basishärtung des Tenants ergänzen. Auch zum Thema Logging haben wir bereits einen Beitrag verfasst, der in diesem Bereich eine Starthilfe bietet. 

Nach oben scrollen