Az - Device Registration
Grundinformationen
Wenn ein Gerät AzureAD beitritt, wird ein neues Objekt in AzureAD erstellt.
Bei der Registrierung eines Geräts wird der Benutzer aufgefordert, sich mit seinem Konto anzumelden (bei Bedarf wird nach MFA gefragt), dann werden Token für den Geräte-Registrierungsdienst angefordert und schließlich wird eine letzte Bestätigungsaufforderung angezeigt.
Dann werden zwei RSA-Schlüsselpaar in dem Gerät generiert: Der Geräteschlüssel (öffentlicher Schlüssel), der an AzureAD gesendet wird, und der Transport-Schlüssel (privater Schlüssel), der, wenn möglich, im TPM gespeichert wird.
Anschließend wird das Objekt in AzureAD (nicht in Intune) generiert und AzureAD gibt dem Gerät ein Zertifikat zurück, das von ihm signiert ist. Du kannst überprüfen, ob das Gerät AzureAD beigetreten ist und Informationen über das Zertifikat (wie ob es durch TPM geschützt ist).
Nach der Geräteregistrierung wird ein Primary Refresh Token vom LSASS CloudAP-Modul angefordert und dem Gerät übergeben. Mit dem PRT wird auch der Sitzungsschlüssel geliefert, der so verschlüsselt ist, dass nur das Gerät ihn entschlüsseln kann (unter Verwendung des öffentlichen Schlüssels des Transport-Schlüssels) und er ist notwendig, um das PRT zu verwenden.
Für weitere Informationen darüber, was ein PRT ist, siehe:
TPM - Trusted Platform Module
Das TPM schützt vor der Schlüssel-Extraktion von einem heruntergefahrenen Gerät (wenn es durch eine PIN geschützt ist) und vor der Extraktion des privaten Materials aus der OS-Schicht. Aber es schützt nicht vor dem Sniffing der physischen Verbindung zwischen dem TPM und der CPU oder dem Verwenden des kryptografischen Materials im TPM, während das System von einem Prozess mit SYSTEM-Rechten läuft.
Wenn Sie die folgende Seite überprüfen, werden Sie sehen, dass das Stehlen des PRT verwendet werden kann, um wie der Benutzer zuzugreifen, was großartig ist, da das PRT sich auf Geräten befindet, sodass es von ihnen gestohlen werden kann (oder, wenn es nicht gestohlen wird, missbraucht werden kann, um neue Signaturschlüssel zu generieren):
Registrierung eines Geräts mit SSO-Token
Es wäre möglich für einen Angreifer, ein Token für den Microsoft-Geräteregistrierungsdienst vom kompromittierten Gerät anzufordern und es zu registrieren:
Welche Ihnen ein Zertifikat gibt, das Sie in Zukunft verwenden können, um PRTs anzufordern. Dadurch wird die Persistenz aufrechterhalten und MFA umgangen, da das ursprüngliche PRT-Token, das zur Registrierung des neuen Geräts verwendet wurde, bereits MFA-Berechtigungen gewährt hatte.
Beachten Sie, dass Sie für diesen Angriff Berechtigungen zur Registrierung neuer Geräte benötigen. Außerdem bedeutet die Registrierung eines Geräts nicht, dass das Gerät in Intune eingeschrieben werden darf.
Dieser Angriff wurde im September 2021 behoben, da Sie keine neuen Geräte mehr mit SSO-Token registrieren können. Es ist jedoch weiterhin möglich, Geräte auf legitime Weise zu registrieren (mit Benutzername, Passwort und MFA, falls erforderlich). Überprüfen Sie: roadtx.
Überschreiben eines Gerätescheins
Es war möglich, einen Geräteschein anzufordern, den aktuellen des Geräts zu überschreiben und während des Ablaufs das PRT zu stehlen (es ist also nicht notwendig, es vom TPM zu stehlen. Für weitere Informationen sehen Sie sich diesen Vortrag an.
Dies wurde jedoch behoben.
WHFB-Schlüssel überschreiben
Überprüfen Sie die ursprünglichen Folien hier
Angriffsübersicht:
Es ist möglich, den registrierten WHFB-Schlüssel von einem Gerät über SSO zu überschreiben.
Es umgeht den TPM-Schutz, da der Schlüssel während der Generierung des neuen Schlüssels abgefangen wird.
Dies bietet auch Persistenz.
Benutzer können ihr eigenes searchableDeviceKey-Attribut über das Azure AD Graph ändern, jedoch muss der Angreifer ein Gerät im Mandanten haben (entweder spontan registriert oder ein gestohlenes Zertifikat + Schlüssel von einem legitimen Gerät) und ein gültiges Zugriffstoken für das AAD Graph.
Dann ist es möglich, einen neuen Schlüssel zu generieren mit:
und dann PATCH die Informationen des searchableDeviceKey:
Es ist möglich, ein Zugriffstoken von einem Benutzer über device code phishing zu erhalten und die vorherigen Schritte zu missbrauchen, um seinen Zugriff zu stehlen. Für weitere Informationen siehe:
Referenzen
Last updated
