Multi-Faktor-Authentifizierung in einem Fortune-500-Unternehmen umgehen

Wir als ethische Hacker*Innen kennen das: Uns werden Zugangsdaten für mehrere Konten zur Verfügung gestellt, mit komplexen Passwörtern und Multi-Faktor-Authentifizierung (MFA), um die Umgebungen unserer Kunden zu testen. Das ist zwar ein gutes Zeichen für eine optimale Authentifizierungssicherheit, schafft aber Mehraufwand für Penetrationstester*Innen. Es gibt verschiedene Möglichkeiten, die Abhilfe leisten, wie zum Beispiel die vorübergehende Nutzung eines Passwortmanagers im Testbrowser, der MFA unterstützt. Aber was, wenn man keinen Browser für Tests verwendet? 

Ich arbeitete kürzlich an einem Projekt, das die Sicherheitsanalyse einiger Azure-Abonnements umfasste. Die Analyse erforderte die Nutzung von zwei unterschiedlich privilegierten Konten, die ein Kollege und ich teilen mussten. Die Richtlinien für bedingten Zugriff des Kunden erforderten, dass wir unsere Geräte über das Unternehmensportal von Microsoft registrieren. Sobald dies erledigt war, konnten wir das Windows-SSO unseres Geräts einrichten, um auf Unternehmensressourcen wie das Azure-Portal und die Azure-CLI zuzugreifen. Dies war notwendig, um die Konfigurationen der Abonnements zu überprüfen und unsere Prüfung durchzuführen. Windows-SSO bietet den Vorteil, dass wir Anwendungen wie Teams und Outlook ohne ständige MFA nutzen können, es sei denn, wir versuchen, unser Microsoft-Konto zu bearbeiten. Bei diesem Kunden lässt es sich bequemer mit den Desktop-Anwendungen arbeiten, da die Browsersitzungen ständig invalidiert werden und bei jedem erneuten LogIn eine MFA erzwingt. Jetzt war der einzige Schritt, der MFA für uns erforderte, die Registrierung unseres Geräts. Der Windows-SSO-Token kümmert sich um den Rest. 

Wie man die Multi-Faktor-Authentifizierung umgeht

Hier wird es interessant: Mein Kollege und ich mussten die Azure-Umgebung mit den uns zugewiesenen Kundenkonten des jeweils anderen analysieren. Um Zeit zu sparen, wollten wir sie so verwenden, dass wir nicht ständig MFA benötigen. Hier stellte ich fest, dass es uns unsere Windows-SSO-Token nicht nur erlauben, MFA zu umgehen, wenn wir Anwendungen wie Teams oder Outlook verwenden, sondern auch beim Interagieren mit der Azure-CLI. Dies umfasst Intune-Funktionalitäten wie das Hinzufügen eines fremden Kontos zu meinem eigenen registrierten Gerät. Indem ich dies tat, konnte ich mein Kundenkonto verwenden, um mein Gerät zu registrieren und dann mein Gerät nutzen, um es dem Kundenkonto meines Kollegen zuzuweisen. Mit nur dem Benutzernamen und dem Passwort konnte ich meine Windows-SSO-MFA-Richtlinien nutzen, um die MFA einfach mit dem „az login“-Befehl der Azure-CLI zu umgehen. 

Abbildung 1: HLD des Angriffs 

Nachdem ich festgestellt habe, dass auf diese Weise vertrauenswürdigen Geräte missbraucht werden können, um die MFA fremder Benutzer zu umgehen, bleibt eine Frage: Wie groß ist die Auswirkung und das Risiko, wenn immer noch die Anmeldeinformationen des Benutzers benötigt werden? 

Sicherheitsauswirkungen der Umgehung von Multi-Faktor-Authentifizierung verstehen 

Die Auswirkungen sind immer an Bedingungen geknüpft. Ohne interne Bedrohungsakteur*Innen zu sein, können wir nichts unternehmen. Ohne die Anmeldeinformationen eines fremden Benutzers können wir dessen Konto nicht nutzen. Ohne ein Konto eines fremden Benutzers, das Zugang zu sensiblen Informationen hat oder persönliche Beziehungen, die wir für Phishing-Angriffe nutzen können, können wir das kompromittierte Konto nicht einmal ausnutzen. Was können wir also tun? 

Da ich in einer privilegierten Position bin, in der ich Anwendungen teste, bevor sie live gehen, kann ich manchmal Anmeldeinformationen durch Brute-Force-Angriffe ermitteln oder schlechte Protokollierungspraktiken ausnutzen, die Anmeldeinformationen im Klartext speichern. Als Außenstehender ist das viel schwieriger, aber es gibt immer noch viele kompromittierte Datenbanken, die Anmeldeinformationen von Benutzer*Innen enthalten, die ihre Arbeits-E-Mail-Adresse für private Zwecke verwendet haben. Abgesehen davon sind gezielte Angriffe wie Man-in-the-Middle-Angriffe und Phishing-Angriffe immer noch anwendbar. 

Der beste Fall ist bereits abgedeckt, in dem der gezielte Benutzer nicht für weitere Ausbeutung verwendet werden kann. Im schlimmsten Fall, wenn man die Anmeldeinformationen eines hochwertigen Kontos erhält, hat man nicht nur Zugang zu deren vollständiger Microsoft 365 Suite (Teams, Outlook, SharePoint usw.), sondern auch Zugang zu allen Mandanten, zu denen das Konto Zugang hat. Für diesen Kunden gehörten dazu angeblich Konten mit administrativen Privilegien innerhalb der Mandanten anderer Unternehmen. Wenn Angreifer*Innen ein solches Konto kompromittieren, könnten sie dies nutzen, um Zugang zu Drittanbieter-Mandanten zu erhalten, was zu Datenschutzverletzungen und Compliance-Verstößen führen könnte. Rechtliche Konsequenzen könnten Geldstrafen nach Schutzvorschriften sowie potenzielle Klagen von betroffenen Unternehmen und Reputationsschäden umfassen.   

Best Practices zur Reduzierung von Schwachstellen der Multi-Faktor-Authentifizierung

Ein Blick auf die Maßnahmen, die wir ergriffen haben, könnte glauben lassen, die Azure CLI an der Umgehung von MFA zu hindern sei simpel. Allerdings offenbaren sich umso mehr Probleme, je intensiver man sich mit den Sicherheitsverbesserungen beschäftigt. Daraufhin haben wir verschiedene Lösungsansätze erarbeitet: 

• Blacklists für Aktionen, die fremde Konten involvieren  
• Whitelists für die erlaubten Anwendungen und Aktionen, die mit Windows-SSO verwendet werden können  
• Blockieren, dass ein Gerät mit mehr als einem Konto verbunden wird  
• Ebenso blockieren, dass ein Konto mit mehr als einem Gerät verbunden wird 

Alles sind funktionierende Lösungen, die ihre Vor- und Nachteile haben. Es ist dennoch sehr empfehlenswert, eine Whitelist für alle Aktionen zu implementieren, die ein Benutzer durchführen darf. Dadurch erhält man die vollständige Kontrolle über jede Aktion, im Gegensatz zur Blacklist, bei der Updates erneut Umgehungen ermöglichen können. Eine Firma muss jedoch immer Sicherheit und Benutzerfreundlichkeit abwägen, weil Benutzer*Innen manuelle Sicherheitspraktiken nach Möglichkeit meiden, wie wir in diesem Artikel deutlich gemacht haben. 

Glücklicherweise gab es Änderungen an den Richtlinien für bedingten Zugriff von Microsoft, die eine feinere Kontrolle über viel mehr Aktionen ermöglichen. Dazu gehört die Benutzeraktion „Geräte registrieren oder verknüpfen“. Ich empfehle, Ihre Richtlinien zu überprüfen und selbst zu sehen, ob Sie diesen Sonderfall erkennen. Denken Sie daran, dass die Nutzung der Benutzeraktion erfordert, dass Sie die MFA-Anforderung in den Einstellungen der Geräteidentität ausschalten, wie in der Warnung von Microsoft hier angegeben.

Lücken in der MFA-Sicherheit von Microsoft schließen 

In diesem Artikel haben wir untersucht, wie die Multi-Faktor-Authentifizierung (MFA) in einer scheinbar sicheren Umgebung ausgenutzt werden kann. Durch die Registrierung eines Geräts und die Verwendung einfacher Azure-CLI-Befehle war es möglich, die MFA ohne das ausdrückliche Einverständnis oder Wissen des fremden Benutzers zu umgehen. Die Folgen umfassen mögliche Datenverletzungen, Angriffe auf die Integrität und Verfügbarkeit der Umgebung sowie mehrere Verstöße gegen Compliance-Richtlinien. Der Schlüssel zu einem sichereren Umgang mit MFA liegt darin, Ihre Richtlinien kontinuierlich zu verfeinern und Rückmeldungen Ihrer Benutzer*Innen einzuholen, um Systeme zu schaffen, die sowohl sicher als auch benutzerfreundlich sind. Ein ideales Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit ermöglicht es Ihnen, die sensiblen Informationen Ihrer Organisation effektiv zu schützen und gleichzeitig die Produktivität Ihrer Benutzer*Innen zu erhalten.