Angriffspunkt Windows Autopilot
Windows Autopilot bietet einen komfortablen Weg, um neue Endgeräte mit geringem IT-Aufwand zu deployen. Microsoft beschreibt das Thema auf einer Learn-Webseite und immer mehr Kunden springen auf den Zug auf. "Zero-Touch"-Deployment und andere coole Buzzwords zieren die Einführung von Autopilot. Mit Windows Autopilot wird das bisherige Deployment abgelöst. Damit einher geht der Angriffspunkt Windows Autopilot, der simpel, logisch, aber nicht unbedingt in jedem Threat-Modelling berücksichtigt wird. Wir zeigen, welcher technische Knackpunkt es einem Angreifer mit physischem Zugriff auf das Gerät erlaubt, dieses zu manipulieren und eine Backdoor einzufügen, ehe das Self-Deployment des eigentlichen Besitzers abgeschlossen wird.
Das Deployment von neuen Clients kann aufwändig sein. In der klassischen IT hieß das oft:
- Gerät bestellen, auspacken, in die Deployment-Umgebung hängen
- Vorinstalliertes Windows platt machen
- Eigenes Windows-Image deployen
- Custom-Config per GPO / Intune Profile / Pipeline / ... aufspielen
- Gerät fertig konfiguriert dem Nutzer übergeben
- BitLocker-PIN einrichten lassen
... fertig.
Klar, dass die Idee von Autopilot hier gut ankommt. Keine Pflege eines eigenen Images mehr. Kein Gerät muss durch die Hände der eigenen IT gehen. Neue Mitarbeiter bekommen das Gerät und von Zauberhand wird bei Eingabe des Benutzerkontos das Setup nach Kundenwunsch fertiggestellt.
Windows Autopilot
Der neue Deployment-Prozess
Der neue, super einfache Deployment-Prozess ist simpel:
- Bereitstellung des Gerätes vom OEM / Hersteller / IT
- Versand des Gerätes mit Windows 11 Basis-OS an den Nutzer
- Start des Setups durch den Nutzer
- Herstellung der Internetverbindung des Geräts
- Anmeldung am Gerät mit dem Unternehmenskonto
- Gerät fragt die vorzunehmende Konfiguration ab und stellt die Installation fertig
Ein Szenario, was insbesondere im Microsoft-365-Umfeld gut funktioniert. Die Konfiguration kommt über Intune, der Nutzeraccount ist ein Microsoft-365-Konto, was über das Internet angemeldet werden kann.
Was nur könnte schief gehen? ...
Der Angriffsvektor im Prozess
Wenn wir den Prozess mal näher betrachten, gibt es eine wesentliche Auffälligkeit. Über diese sind wir aus zwei Blickwinkeln gestolpert.
Aus Richtung ISMS gibt es oft die Vorgabe: Geräte dürfen das Unternehmensgelände nur verschlüsselt verlassen (oder ähnlich).
Aus Angreifersicht im Penetrationstest / *-Teaming ist die Frage, wo im Prozess komme ich an ein unverschlüsseltes Gerät, was ich so manipulieren kann, dass ich ein administratives Konto, eine Backdoor und einen CnC-Channel einrichten kann, bevor alle Sicherheitssysteme laufen?
Die Antwort in beiden Fällen: Wir haben ein Problem mit Autopilot.
Im Autopilot-Szenario werden in der Regel unverschlüsselte Notebooks verschickt, auf denen aber das Windows 11 schon vollständig installiert ist. Es wird lediglich die Konfiguration angepasst, Dienste deinstalliert und installiert. Große Teile des Betriebssystems aber bleiben unberührt.
Im Rahmen unserer Schulungen versuchen wir auf die Problematik hinzuweisen. Ob der Komfort am Ende über das Restrisiko siegt, das bleibt dem jeweiligen Risikoappetit überlassen. Für den Angreifer ist das mögliche Szenario schnell identifiziert:
Als Angreifer können wir die unverschlüsselte Festplatte ausbauen, beliebige Änderungen an Windows vornehmen, die Festplatte wieder einsetzen und das Notebook zum fertigen Deployment weiterleiten.
Klar - die Manipulation von Hardware, die Implementierung von Chips und ähnliche Angriffe gibt es in der Lieferkette schon länger. Diese setzen in der Regel größere Ressourcen und enormes Know-How voraus. Hier handelt es sich um einen Angriff auf ein "plain" Windows, wo jedem Angreifer diverse Möglichkeiten einfallen, sich im System einzunisten.
Das Katz-Maus-Spiel des Setups
Große Teile des Betriebssystems sind schon vorhanden, wenn die Geräte ausgeliefert werden. Klar kann es sein, dass gewisse Manipulationen im Rahmen des Setup-Prozesses wieder überschrieben werden. Aus der Praxis mal ein paar Ideen, was Angreifer so tun können.
- Installation zusätzlicher Dienste
- Veränderung der SDDL / ausführbaren Datei / ... von typischerweise vorhandenen Diensten
- Manipulation der Registry (Image File Execution Options, ...)
- Manipulation der installierten Software
- Manipulation der lokalen Benutzerkonten / Gruppen
- Einrichtung von Scheduled Tasks als System
- ... {you name it}
Welcher Weg bleibt, hängt stark vom Deployment ab. Wird der Microsoft Defender verwendet, so lässt er sich an dieser Stelle schon wunderbar dauerhaft deaktivieren - oder so .... anpassen ... dass er nicht mehr in der Lage ist, wirksam zu funktionieren. Beim klassischen Deployment waren derartige Manipulationen auf dem Weg vom Hersteller zur IT relativ egal - das OS wurde eh komplett gewhiped und mit dem "sauberen" Basis-Image neu aufgespielt.
Letzte Worte
Ist ein Innentäter ein reales Bedrohungsszenario? Werden wirklich Endgeräte in der Lieferkette abgefangen?
Die individuelle Bedrohungsanalyse kann ergeben, dass alles kein Problem ist - und das wäre nicht schlimm. Je nach Größer oder Branche.
Der Angriff ist an einige Bedingungen geknüpft. Ein Angreifer muss physisch Zugriff auf das Gerät haben. Im richtigen Zeitpunkt. Das reduziert die Eintrittswahrscheinlichkeit für Gelegenheitsangreifer.
In einem Penetrationstest, in dem das Szenario erlaubt ist, ist der Drops aber schnell gelutscht. Mit lokalen Administratorrechten kann der Angreifer auf dem System schalten und walten wie er will - Umgehen / Deaktivieren von Sicherheitslösungen aller Art inklusive, insbesondere mit physischem Zugriff auf das Gerät.
Nicht immer gehen Komfort und Sicherheit Hand-in-Hand - eigentlich selten. Oder nie. Die Auslieferung im verschlüsselten Zustand wäre eine Option. Aber wohin mit dem Recovery-Key vor dem Join in den Tenant? Auch schwierig.
Am Ende bleibt es vielleicht ein schönes Szenario für das Risikomanagement.
Bei Fragen unterstützen wir Sie gerne im Rahmen unserer Dienstleistungen!