SiSyPHuS Win10 : Ein Blick auf die Sicherheit von Windows 10

Von Maximilian Winkler, BSI

Mit dem Release von Windows 10 im Herbst 2015 und der damit verbundenen Ankündigung von Microsoft, dass es keine weiteren Hauptversionen von Windows mehr geben werde, wurde eine tiefergehende Befassung mit dieser Version durch das BSI erforderlich. Diese Analyse sollte unabhängig vom Hersteller sein und sich auf die zentralen sicherheitskritischen Funktionen fokussieren. Die mit der Novellierung des BSI-Gesetzes im Jahr 2015 geregelten Befugnisse zur Untersuchung von Produkten (§ 7a) sind ein wichtiger Aspekt, um diesen Ansprüchen zu genügen, da Herstellerinformationen zur internen Funktionsweise der im Projekt untersuchten Funktionen nicht oder nur spärlich öffentlich verfügbar sind. In vielen Fällen können dadurch die benötigten Informationen mittels Reverse-Engineering aus dem vorliegenden Betriebssystem gewonnen werden.

Mit der politisch-strategischen Entscheidung für Windows 10 als Betriebssystem für die Bundesverwaltung besteht die Erwartung an das BSI, verlässliche Aussagen zu den Rahmenbedingungen und Voraussetzungen eines sicheren Einsatzes von Windows 10 zu tätigen. Mit der „Studie zu Systemaufbau, Protokollierung, Härtung und Sicherheitsfunktionen von Windows 10“ (kurz: SiSyPHuS Win10) wird daher eine Grundlage geschaffen, um

• die Gesamtsicherheit und Restrisiken für eine Nutzung von Windows 10 bewerten zu können,
• Rahmenbedingungen für einen sicheren Einsatz des Betriebssystems zu identifizieren sowie
• praktisch nutzbare Empfehlungen für einen sicheren Einsatz von Windows 10 geben zu können.

Untersuchungsgegenstand der Analysen war zunächst Windows 10 Version 1607, 64bit in deutscher Sprache aus dem „Long Term Servicing Branch“ (LTSB 2016). Seit 2019 ist die untersuchte Betriebssystemversion die Version 1809 aus dem „Long Term Servicing Channel“ (LTSC 2019). Die bereits abgeschlossenen Analysen der Version LTSB 2016 werden mit der aktuellen LTSC-Version (2019) abgeglichen und einzelne Komponenten bei Bedarf erneut betrachtet.

Die Entscheidung für die LTSB/LTSC-Version hatte verschiedene Gründe: So war bereits vor Projektbeginn klar, dass aufgrund des Projektumfangs und der damit verbundenen mehrjährigen Projektlaufzeit der Untersuchungsgegenstand möglichst unverändert (Feature-stable) bleiben und die zu erwartenden Projektergebnisse ihre Aussagekraft über einen längeren Zeitraum behalten sollten. Damit waren die beiden weiteren vom Hersteller angebotenen Releasezyklen von Windows 10, der „Current Branch“ (CB) sowie der „Current Branch for Business“ (CBB) bereits aus dieser Sicht keine Option für das Projekt. Zum Anderen war zu diesem Zeitpunkt in der Bundesverwaltung bereits die LTSB-Version als Windows 10 Client vorgesehen. Projektergebnisse lassen sich dadurch leicht auf den Betrieb von Windows 10 in der Bundesverwaltung übertragen.

Die Fokussierung bei der Analyse auf die LTSB/LTSC-Version bedeutet jedoch nicht, dass sich die gewonnenen Erkenntnisse nicht auch auf andere Windows-10-Versionen übertragen lassen. So trägt zum Beispiel die zum Untersuchungsgegenstand äquivalente Semi-Annual-Channel-Version (SAC) die Versionsnummer 1809 – diese ist funktionsgleich hinsichtlich des Betriebssystemkerns und der Komponenten, die in beiden Versionen (LTSC 2019 und SAC 1809) enthalten sind. In der Regel enthalten jedoch die SAC-Versionen mehr Systemkomponenten/Features als die LTSC-Version, welche aber in den Analysen nicht betrachtet werden. Ähnlich verhält es sich bei den häufigeren Versionswechseln im SAC, wodurch sich auch die analysierten Komponenten verändern können.

Das Projekt ist bis 2023 angelegt. Sämtliche im Projekt erarbeiteten Ergebnisse und Erkenntnisse zu den einzelnen Arbeitspaketen werden während der Projektlaufzeit fortlaufend auf der Website des BSI veröffentlicht. Alle erstellten Tools und Skripte sind quelloffen und stehen – soweit möglich – unter der Lizenz GNU GPLv2 zum Download zur Verfügung [1]. Aufbauend auf den vom BSI im Projekt erarbeiteten Grundlagen können damit zum Beispiel Sicherheitsforscher weitere Untersuchungen vornehmen sowie Funktionsweisen und Schnittstellen der jeweiligen Komponenten besser verstehen – aus diesem Grund sind die Ergebnisdokumente in englischer Sprache verfasst. Gleichzeitig erleichtert dies auch die Diskussion
der Analysen mit dem Hersteller Microsoft Corp. Jedes Dokument enthält zudem zusätzlich eine Zusammenfassung der Ergebnisse auf Deutsch.

Ergebnisse

Zu den bereits untersuchten Features und Komponenten gehören unter anderem die TPM-Nutzung, Powershell, DeviceGuard, der „Virtual Secure Mode“, „Universal Windows Apps“ und die Telemetrie. Im Rahmen einer Projekterweiterung 2018 wurden die Windows-Features „Application Compatibility Infrastructure“, „Driver Management“ und „PatchGuard“ in die zu analysierenden Komponenten zusätzlich aufgenommen.

Aus den hier gewonnenen Erkenntnissen sowie bekannten Best Practices wurden Handlungsempfehlungen zur Härtung des Betriebssystems sowie zur Konfiguration der Protokollierung abgeleitet, welche sich mit Windows-Bordmitteln umsetzen lassen. Ein Fokus bei der Erstellung dieser Empfehlungen lag auf der einfachen Umsetzung und praktischen Anwendung. Administratoren sollten möglichst wenig Zeit aufwenden müssen, um die Einstellungen in ihren Systemen umzusetzen.

Die Dokumentenstruktur der Empfehlungen entspricht der Reihenfolge der Einstellungen im Windows Gruppenrichtlinieneditor, sodass sich die Anpassungen sozusagen ohne Hin-und-her-Blättern vornehmen lassen. Als weitere Maßnahme werden die empfohlenen Konfigurationseinstellungen zusätzlich als direkt in Windows importierbare Gruppenrichtlinienobjekte (in Form eines GPO-Backups) bereitgestellt: So kann ein Großteil der empfohlenen Einstellungen mit wenigen Klicks übernommen und auf die jeweilige Einsatzumgebung angepasst werden.

Die angestrebte einfache und praktische Umsetzbarkeit der Empfehlungen setzt konkrete Einstellungen voraus, die sich – als konkrete Konfiguration – auch direkt in das Betriebssystem importieren lassen. Beispielsweise wäre eine Empfehlung im Sinne von „erzwingen Sie die Nutzung eines ausreichend langen Kennworts“ hierfür nicht geeignet und für die Mehrzahl der Anwender ohnehin nicht hilfreich.

Oft hängen jedoch in der Tat Einstellungen von den örtlichen Gegebenheiten, Schutzbedürftigkeiten und anderen operationellen Aspekten der Einsatzumgebung ab und unterscheiden sich damit auch zu Recht von Fall zu Fall. Eine allgemeingültige Empfehlung könnte damit gar nicht konkreter ausfallen, um nicht in die Gefahr zu geraten, bei einem speziellen Einsatzszenario unter Umständen falsch zu sein.

Die Grundprinzipien bei der Erstellung der Empfehlungen waren:

• Verhinderung von bekannten und verbreiteten Angriffsszenarien, die nach aktueller Kenntnislage aktiv ausgenutzt werden beziehungsweise mit hoher Wahrscheinlichkeit ausgenutzt werden können
• Verringerung der Angriffsfläche durch Deaktivierung nicht benötigter (oder veralteter) Funktionen und Komponenten
• Verbesserung des Datenschutzes, indem Funktionen und Komponenten, die auf Cloud-Diensten basieren, deaktiviert werden
• Verbesserung des Datenschutzes, indem soweit wie möglich die Übertragung von – nicht für die Funktionalität benötigten – Informationen an den Hersteller unterbunden wird
• Minimierung der Sicherheits- und Datenschutzabfragen sowie Auswahlmöglichkeiten beim Benutzer
• Erzwingen von sinnvollen Standardeinstellungen, um eine Modifikation durch den Benutzer zu verhindern

Für die Empfehlungen aus dem Projekt ist neben diesen Grundprinzipien ein konkretes Einsatzszenario formuliert worden, zu welchem dann auch konkrete Empfehlungen gegeben werden können. Dieses ist so gewählt worden, dass es einen möglichst großen Anwenderkreis abdeckt: einen „Standard-Büroarbeitsplatzrechner“ in einem Unternehmen oder einer Behörde. Dabei sollen möglichst wenig Funktionseinschränkungen entstehen.

Kommen speziellere Anforderungen wie zum Beispiel erhöhter Schutzbedarf der Daten oder administrative Tätigkeiten hinzu, können die Empfehlungen zwar als Grundlage dienen, müssen aber entsprechend angepasst werden. Von den bereits abgeschlossenen Analysen hat insbesondere die Analyse des zentralen Telemetriedienstes Aufmerksamkeit erhalten.

Telemetrie

Die Telemetrie in Windows 10 basiert auf einer Infrastruktur im Betriebssystem, die sich „Event Tracing for Windows“ (ETW) nennt. ETW kennt drei Rollen: Provider (liefert Daten), Consumer (empfängt Daten) und Controller – Letzterer kann sogenannte „ETW Sessions“ erzeugen und sorgt damit für eine Verbindung von Providern zu Consumern.

Bei ETW entscheidet der Entwickler einer Komponente (z. B. einer Betriebssystembibliothek), an welchen Stellen er ein „Ereignis“ erzeugt und dem ETW-Framework diese Information zur Verfügung stellt – das kann beispielsweise der Aufbau einer Netzwerkverbindung sein oder ein Tastendruck der Tastatur. Diese Komponente wird damit zum ETW-Provider; Programme, die diese Ereignisse erhalten und verarbeiten (z. B. Anzeigen in einer Liste) werden ETW-Consumer genannt.

Ein Beispiel zur Verdeutlichung: Das WindowsEventlog ist Controller und Consumer, da hierdurch sowohl Ereignisse von verschiedenen Lieferanten „abonniert“ werden können und diese dann gleichzeitig auch verarbeitet (als Liste angezeigt) werden. Windows 10 ist umfassend mit solchen Messpunkten versehen. Dadurch ist es möglich, das Verhalten des Betriebssystems und der installierten Anwendungen sowie das Nutzerverhalten sehr detailliert zu verfolgen.

Die Aufgabe des Telemetriedienstes in Windows 10 ist es, die vom Telemetrie-Backend gewünschten Informationen zu beschaffen (Abonnieren der Ereignisse) und an die Backend-Server zu übertragen. Die Konfiguration ist dabei dynamisch und wird vom Backend beim Hersteller gesteuert. Während der Analysen wurde circa alle 15 bis 20 Minuten eine solche Konfigurationsdatei übertragen.

Zur Unterbindung von Telemetrieverbindungen wurden im Projekt verschiedene Ansätze untersucht: Diese reichen von der wenig wirksamen Reduktion durch Auswählen eines niedrigen Telemetrie-Levels in der Windows-10-Konfigurationsoberfläche bis hin zur vollständigen Isolation des Clients vom Internet. Die Wirksamkeit wurde über einen Zeitraum von 48 Stunden beobachtet, wobei nahezu alle Maßnahmen die Übertragung von Telemetriedaten verhinderten.

Es zeigten sich jedoch deutliche operationelle Vor- und Nachteile der verschiedenen Maßnahmen. Als Kernaspekt bei der Erarbeitung der Empfehlung stellte sich im weiteren Verlauf der Analysen die Nachhaltigkeit heraus, also die Einschätzung, ob eine bestimmte Konfiguration auch dauerhaft bestehen bleibt (beispielsweise über ein Betriebssystemupdate hinweg). Hierbei schnitten – wenig überraschend – die lokalen Maßnahmen schlechter ab als diejenigen Maßnahmen, welche außerhalb des Systems im Netzwerk umgesetzt werden.

Die Empfehlung des BSI ist es daher, auf lokaler Ebene den Telemetriedienst zu deaktivieren und als zusätzliche netzwerkbasierte Maßnahme ein Proxy zu verwenden, welches Verbindungen zu den bekannten Endpunkten unterbindet.

System Activity Monitor

Für weiter gehende Analysen zur Telemetrie in Windows 10 befindet sich im Projekt derzeit ein Analyse-Framework in der Entwicklung – Arbeitsname: „System Activity Monitor“ (SAM). Mit diesem können beliebige ETW-Ereignisse auf dem analysierten System aufgezeichnet, gefiltert und zur weiteren Aufbereitung an ein externes Auswertesystem übertragen werden. Als praktisches Beispiel wird in der Dokumentation die Analyse der Telemetrieaktivität sowie die Anbindung an einen ELK-Stack beschrieben (Elasticsearch, Logstash und Kibana – zusammen ermöglichen diese drei Open-Source-Tools die Visualisierung und Auswertung von Daten). Die aufzuzeichnenden Ereignisse sind jedoch beliebig konfigurierbar und somit nicht auf die Beobachtung der Telemetrie beschränkt.

Literatur

[1] BSI, SiSyPHuS Win10: Studie zu Systemaufbau, Protokollierung, Härtung und Sicherheitsfunktionen in Windows 10, www.bsi.bund.de/DE/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/SiSyPHuS_node.html