Hacking MFA & Privilege Escalation: Help-Desk-Agent zu Domain Administrator in 3 Minuten

MFA Basics

MFA (Multi-Factor-Authentication) erfordert bei der Authentifizierung eines Benutzers nicht nur einen Faktor (zum Beispiel ein Passwort) sondern einen zweiten oder sogar mehrere Faktoren. Gängige Beispiele sind OTP (One Time Passwords) die von einem Token generiert werden, oder Smart Cards. Man spricht hierbei von mehreren Faktoren in folgender Form:

  • Passwort: Etwas, das ich weiß
  • Smart Card / Token: Etwas, das ich besitze

Das macht die Authentifizierungsprozess an sich sicherer, weil es weniger wahrscheinlich ist, dass jemand sich sowohl ein Passwort verschaffen kann, als auch einen (physischen) Hardware-Token in seinen Besitz bringen kann.
Randnotiz: Warum MFA aber die „Anmeldung“ an sich (insbesondere in Form der resultierenden Session) zahlreichen Attacken überlässt, beschreibt dieser Artikel von Roger Grimes sehr gut: 11 ways to hack 2FA

Der Angriff

Grundlage für unseren Angriff ist folgende IT-Landschaft:

  • Es gibt einen Helpdesk-Agent (DOMAIN\agent-helpdesk mit UPN agent-helpdesk@domain.com). Der Helpdesk-Agent pflegt die Benutzerobjekte im Active Directory. Dazu hat er entsprechende Berechtigungen. Seine Rechte sind aber auf die entsprechenden OUs begrenzt. Er ist jedoch nicht Domain Admin.
  • Darüber hinaus gibt es den Administrator (DOMAIN\adm-domain mit UPN adm-domain@domain.com). Der Administrator verwaltet alle globalen Aspekte des Active Directory und ist deshalb Domain Admin.

Um die Sicherheit zu erhöhen, wurde 2FA implementiert. Es befindet sich eine Smart Card Lösung im Einsatz. Die Zuordnung der Smart Card (und Keys) erfolgt dabei über den UPN des Benutzers. Der Helpdesk-Agent geht nunmehr folgendermaßen vor:

  • Er ändert kurzfristig seinen eigenen UPN auf agent-helpdesk2@domain.com. Das darf er, da er die Benutzerobjekte im Active Directory pflegen darf und eine Anpassung des UPN für einen Benutzer bei Heirat oder Scheidung fast immer auftritt. Es handelt sich also um eine Routinetätigkeit.
  • Danach ändert er den UPN des Administrators auf agent-helpdesk@domain.com.
  • Anschließend startet er seine Workstation neu. Dann meldet er sich mit seinem Benutzer und seinem Passwort an. Er steckt seine eigene Smart Card, die jedoch aufgrund des UPN dem Administrator-Konto zugeordnet wurde. Die Anmeldung erfolgt nunmehr mit dem Administratorkonto und der Benutzer hat Rechte als Domain Admin.
  • Er kann nun bösartige Operationen als Domain Admin ausführen und anschließend die beiden UPN wieder zurückändern.

Diese Art von Angriff bleibt oft unbemerkt:

  • Alle bösartigen Operationen werden unter dem Benutzernamen „adm-domain“ ausgeführt. Die Spur führt nicht zum Angreifer.
  • Die Änderung des UPN ist eine Routinetätigkeit und wird in den Logs nicht auffallen.
  • Es müssen keine Passwörter geändert oder Gruppenmitgliedschaften hinzugefügt werden. Diese würden in den Logs entsprechend auffallen und einen Alert generieren.

Erleben Sie tenfold LIVE

Melden Sie sich zu unserem kostenlosen und unverbindlichen Webinar an!

Zur Anmeldung

Verbesserungsvorschläge

Was kann man also tun, um solche Probleme zu vermeiden? Folgende Maßnahmen führen in diesem konkreten Angriffsmuster sofort zu Verbesserungen:

  • Logging von wichtigen Attributen wie UPN bei allen administrativen Konten beachten.
  • Administrative Konten in OUs speichern, in denen der Helpdesk keine Änderungsrechte hat.

Einschränkung auf indirekte Administration

Um jedoch nicht nur diesen Fall, sondern gleich eine Reihe von möglichen Angriffsmustern zur Erhöhung der administrativen Privilegien zu verhindern, ist es ratsam, die direkte Administration von AD-Objekten nur einem sehr eingeschränkten Personen-Kreis (wie Power-Admins) zu ermöglichen.
Helpdesk, User Service und vergleichbare Teams sollten lediglich über indirekte und eingeschränkte Methoden die Möglichkeiten haben, Benutzer, Gruppen und Computerkonten im Active Directory zu verändern.

Mit tenfold können die Berechtigungen zur Administration wesentlich granularer als direkt in Active Directory eingestellt werden. Viele Einstellungen können außerdem die Best Practices des Unternehmens darstellen. Diese werden von tenfold automatisch forciert– der Helpdesk hat damit keinen individuellen Gestaltungsraum mehr, was die Sicherheit weiter erhöht.

By |2019-03-19T09:58:24+00:0011 / 03 / 2019|BLOG|

About the Author:

Helmut Semmelmayer
Helmut Semmelmayer ist seit 2012 als Senior Manager Channel Sales beim Software-Hersteller tenfold tätig. Er ist damit für den Partnervertrieb und das Produktmarketing verantwortlich und schreibt in diesem Blog regelmäßig themenbezogene Beiträge aus dem Bereich Identity & Access Management.