Die aktuellste Version des Dokuments ist unter tu-ilmenau.de erhältlich. Außerdem ist eine englische Version verfügbar.
Der Ecos Secure Boot Stick soll auch aus unsicheren Umgebungen heraus einen sicheren Zugriff auf Terminalserver und Webservices bieten. Dazu wird in einem herkömmlichen PC, über den keine speziellen Annahmen getroffen werden, vom USB-Stick ein Betriebssystem gebootet. Der Hersteller schreibt: "Der ECOS SECURE BOOT STICK ermöglicht einen hochsicheren Zugang zu einer Terminalserver- oder Virtual-Desktop-Infrastruktur und Webanwendungen aus einer gesicherten Umgebung heraus."
Referenzkunden sind deutsche Behörden, Banken, Versicherungen und Krankenhäuser. Die Zahlen auf der Webseite lassen darauf schließen, dass einige Tausend SBS im Umlauf sind. Dieses Dokument beschreibt eine Reihe von Schwachstellen, die bei einer Sicherheitsuntersuchung des Boot Sticks und der dazugehörigen Management Appliance entdeckt wurden. Alle gefundenen Schwachstellen führen zu einem Versagen von herstellerseitigen Sicherheitsaussagen oder allgemein akzeptierten Sicherheitszielen. Typischerweise bedeutet dies den unautorisierten Zugriff eines kompromittierten Hosts oder einer dritten Partei auf private Daten oder kryptographisches Schlüsselmaterial.
Hinweis: Es werden keine Aussagen zur Vollständigkeit der Analyse gegeben. Insbesondere können möglicherweise andere Schwachstellen existieren, die ein höheres Risiko darstellen. Es wurde unsererseits weder eine systematische Bedrohungsanalyse durchgeführt, noch wurden Sicherheitsanforderungen abgeleitet. Stattdessen wird über die vom Hersteller formulierten Sicherheitsaussagen und -maßnahmen sowie allgemein anerkannte Prinzipien (beispielsweise sollten private Schlüssel nicht auslesbar sein) argumentiert.
In der Zwischenzeit wurden neue [SE]- und [SX]-Versionen des Produktes auf den Markt gebracht und durch das Bundesamt für Sicherheit in der Informationstechnik zum Schutz von VS-NfD-Daten zugelassen. Diese beiden Versionen standen uns für Tests nicht zur Verfügung. Aus diesem Grund können wir keine Aussage darüber treffen, ob die in diesem Dokument beschriebenen Schwachstellen auch bei den beiden zugelassenen Produktvarianten zutreffen -- es kann aber auf Basis unseres Erkenntnisstandes auch nicht ausgeschlossen werden. Das BSI kann eine Zulassung auch an (in der Regel nicht-öffentliche) Bedingungen knüpfen, die Risiken mitigieren.
Die System Management Appliance enthält einen aktivierten root-Nutzer, dem SSH-Zugang erlaubt wird. Die Passwortdatei /etc/shadow zeigt außerdem, dass ein Passwort für den Nutzer gesetzt ist. Die Datei selbst wird während der Installation der Appliance von einem Ecos-Server heruntergeladen. Somit kontrolliert Ecos das Passwort für den administrativen Zugang. Möglicherweise werden hierbei von Ecos für unterschiedliche Kunden verschiedene Passwörter gesetzt, da in die Download-Anfrage der Lizenzschlüssel eingeht. Die in unserem Setup installierte shadow-Datei hat den folgenden Inhalt (die letzte Zeile ist eine base64-kodierte Signatur von Ecos):
root:$6$ys8MpGD8fzOj1CMa$8S5YZ2UasC5IVMOoshDevPYeGEfxe/t.WUYL1nOHzR6g38VQmUO6t5vLsNQvk1thPJhTygDsvUyd9tfbJz5ib.:10091:0:99999:7:::
setup:*:12101:0:99999:7:::
remotesetup:*:12101:0:99999:7:::
RUNPUyBUZWNobm9sb2d5IEdtYkg6IGNvbmYtc2lnbtlpePrdaFQhGVMzvKCum1Se8f8kAQBUo7BcQAy9GeRSx2+cRPHJPzSg792pvZ4Ib5RYVbb6GOJdO92mrdFN4JwQhcb5unnmJLa9GX3XpBC2Ujh8AmZsBW2Q06h0ka0qfxJMkcmRDZ3LxOU/GjG/vGnyiymlk1g8iUdYf6u7NNZ0HVoz1HC8dQdZgcH1J5cHnOFGgVl4oak207tnUpgziAwSkALddZHR0jJ7sNiNlboIMToqPmM2lxYJulRCzWcplFoiHkvhEZos0m1TI9NnEA+nlp38cSWBf5lOytN10eeVnaov+uGAp2Xl22avmZmOz6c0K4TttTKGdi1+i2/Tzgs3Jhwegn3b4fNrvp5iB8/umBsYR3i2AQYBHxQAAAAAAAECfk1vZHVsZSBzaWduYXR1cmUgYXBwZW5kZWR+Cg==Schritte zur Rekapitulation:
/usr/msrc/certs/shadow.new existiert und einen Hash für das Passwort des root-Nutzer enthält/etc/shadow auf einen selbstbestimmten WertPotentielle Implikationen:
Mögliche Gegenmaßnahmen:
Ein Angriff kann durch einen der folgenden Schritte verhindert werden:
sshd_config deaktiviert werden.Zugewiesene CVE-Nummer: CVE-2018-12338
Das Ecos-Management bietet einen dokumentierten Fernwartungszugang remotesetup mit stark eingeschränkten Rechten (siehe beispielsweise ECOS SMA V5 Admin-Handbuch, Abschnitt 3.4.5 Wartung). Dieser sollte nicht mit dem hier beschriebenen 'root'-Zugang verwechselt werden, welcher nicht deaktiviert werden kann. Das Admin-Handbuch (Revision 0111, Dezember 2017) schließt einen solchen Zugang sogar explizit aus:
In jedem Fall ist über die Konsole kein Shell- oder Root-Zugang möglich, sondern nur zu einem Menü, das grundlegende Wartungsaufgaben, wie z. B. Setzen der IP-Adresse oder Senden eines ping etc., erlaubt.In allen Tests zur Untersuchung der Schwachstelle war der dokumentierte Fernwartungszugang deaktiviert. Über den root-Zugang konnte dennoch per SSH zugegriffen und eine entsprechende Shell geöffnet werden.
Das Easy Enrollment erlaubt es Nutzern ihren SBS (im Auslieferungszustand) über das Internet mit dem Management zu koppeln und zu initialisieren. Die Authentisierung erfolgt mithilfe eines "Activation Code" und einer "Passphrase", die aus sechs Ziffern besteht. Diese initiale Inbetriebnahme erfolgt technisch durch das Kopieren der Konfigurationsparameter von der zentralen Management Appliance, deren IP-Adresse in den Activation Code kodiert ist. Um sich gegenüber dem Management zu authentisieren, baut der SBS eine SSH-Verbindung auf Port 909 auf. Hierzu wird das SSH-Password-Authentisierungschema benutzt, wobei der Nutzername und das Passwort sich direkt aus Activation Code und Passphrase ergeben. Da der kryptographische Fingerprint des SSH Servers nicht überprüft wird, können Activation Code und Passphrase durch einen einfachen Man-in-the-Middle-Angriff abgefangen werden.
Video: enrollmentMITM.mp4
Potentielle Implikationen:
Mögliche Gegenmaßnahmen: Easy Enrollment darf nur innerhalb von vertrauenswürdigen Netzen durchgeführt werden. Beim Einsatz von Smartcards könnte das Easy Enrollment von diesem Angriff nicht betroffen sein, da die Smartcard-Initialisierung in einem separaten Offline-Schritt erfolgt. Wir haben dies jedoch nicht verifiziert.
Zugewiesene CVE-Nummer: CVE-2018-12331
Laut Hersteller ist das Problem in SBS-Version 5.4.43 und 5.6.11 in Kombination mit Management 5.2.70 und 5.3.40 adressiert worden.
Nach dem der Easy-Enrollment-Prozess einen SSH-Tunnel aufgebaut hat, sendet der SBS darüber eine Reihe von HTTP-Anfragen an den Server. Die Antworten enthalten alle Dateien, die für ein initiales Bootstrapping erforderlich sind, beispielsweise private und öffentliche SSH-Schlüssel des SBS. Diese werden für spätere SSH-Verbindungen verwendet. Nach Abschluss des initialen Downloads wird der Activation Code aus der Datenbank gelöscht.
Ein Angreifer kann einen Activation Code jedoch auch für beliebige SSH-Port-Weiterleitungen auf dem Management benutzen. Dadurch ist es ihm möglich sich auf Ports zu verbinden, die durch Binden an 127.0.0.1 ausschließlich innerhalb des Managements zur Verfügung stehen sollten. Die zentrale CouchDB des Managements akzeptiert Anfragen auf Port 5984 und kann dazu gebracht werden die Nutzerkonfigurationen beliebiger Sticks und Nutzer auszugeben. Zusätzlich muss der Angreifer den Activation Code nicht löschen, sodass der Angriff unbemerkt geschehen kann.
Video: enrollmentKeyExtraction.mp4
Potentielle Implikationen:
Mögliche Gegenmaßnahmen: Easy Enrollment darf nur innerhalb von vertrauenswürdigen Netzen durchgeführt werden (insbesondere nicht über das Internet), beispielsweise durch Blockieren von Port 909 (mit Seiteneffekten, da auch andere Management-Komponenten erreichbar sind).
Zugewiesene CVE-Nummer: CVE-2018-12335
Laut Hersteller ist das Problem in Management-Version 5.2.70 und 5.3.40 adressiert worden.
Ecos erklärt: "Die Nutzung des Sticks hinterlässt keinerlei Spuren, womit es ausgeschlossen ist Rückschlüsse auf Verbindungsdaten oder Arbeitsdaten zu nehmen."
Trotz dieser Aussage verbleibt nach einem harten Neustart des PCs (z.B. durch Betätigen des Reset-Knopfs) während der Ausführung des SBS vertrauliches Schlüsselmaterial im Speicher zurück. Ein kompromittiertes Betriebssystem auf dem Hostrechner kann anschließend dieses Schlüsselmaterial aus dem "uninitialisierten" Hauptspeicher lesen. Dies kann beispielsweise auch bei folgendem Arbeitsablauf passieren: Ein Nutzer resettet das OS eines Ecos SBS versehentlich, arbeitet weiter, fährt seine Ecos-SBS-Sitzung sauber herunter und bootet in ein kompromittiertes OS. Der Speicher der ersten (abgebrochenen) Ecos-Sitzung wird dabei nicht notwendigerweise vollständig von der zweiten überschrieben.
Schritte zur Rekapitualtion:
Video: coldBoot.mp4
Potentielle Implikationen:
Mögliche Gegenmaßnahmen: Nach einem Neustart müssen Nutzer den PC vollständig und für mehrere Sekunden vom Strom trennen, um sicherzustellen, dass der Speicher seinen Zustand verloren hat. Bei Nutzung von älteren RAM-Typen muss der PC unter Umständen eine längere Zeit vom Strom getrennt werden. Geräte, die nicht sicher ausgeschaltet werden können, etwa weil die Akkus nicht zu entfernen sind, sollten nicht verwendet werden. Langzeitgeheimnisse können möglicherweise durch den Einsatz einer externen Smartcard besser geschützt werden, wir haben diese Option jedoch nicht untersucht.
Zugewiesene CVE-Nummer: CVE-2018-12332
Der Hersteller bewirbt den Stick zur Nutzung als zweiten Authentisierungsfaktor, bei dem das Zertifikat an die Hardware-ID des Sticks gekoppelt wird (wörtlich "Zertifikat, gekoppelt an die Hardware-ID des Sticks"). Dies suggeriert, dass der Stick nicht durch einen Angreifer beziehungsweise kompromittierte Software geklont werden kann.
Der SBS ist nicht ausreichend gegen ein Klonen geschützt, da aktuelle Generationen von USB-Speicher-Sticks schlicht über keine feste "Hardware-ID" verfügen. Ein Angreifer kann Parameter wie die Vendor- und Product-ID sowie die Seriennummern auf allgemein verfügbaren Speicher-Sticks frei ändern [3]. Ein Angreifer beziehungsweise eine bösartige Software muss anschließend nur eine 1:1-Kopie des Sticks erstellen (zum Beispiel durch Nutzung von dd auf einem Unix-System). Anzumerken ist, dass hierzu kein physischer Zugang erforderlich ist. Alle erforderlichen Inhalte des Sticks könnte über das Internet übertragen werden, sobald der Stick in einen PC gesteckt wird auf dem eine kompromittierte Software aktiv ist.
Video: stickClone.mp4
Potentielle Implikationen:
Mögliche Gegenmaßnahmen: Nutzer sollten den SBS nicht in Geräten verwenden, deren Hard- und Software nicht in vollen Umfang vertraut werden kann. Dies schließt möglicherweise kompromittiertes USB-Equipment, wie Hubs, mit ein. Die Nutzung eines anderen zweiten Faktors, wie einer Smartcard sollte das Problem beheben, dies wurde im Rahmen der Analyse jedoch nicht näher untersucht. Starke Bootpasswörter können den "ersten Faktor" stärken, sodass der physische Besitz des Sticks weniger relevant für das Erreichen des angestrebten Sicherheitsniveaus ist. Das Sperren von Nutzerzertifikaten an zentralen Punkten (VPN-Konzentratoren, Terminal-Server oder internen Webseiten) ist einem Einziehen des SBS als Sicherheitsmaßnahme vorzuziehen.
Zugewiesene CVE-Nummer: CVE-2018-12329
Erklärung des Herstellers: "Vor Ausführung der Firmware erfolgt eine Prüfung, ob der Stick in einer virtuellen Maschine gebootet wurde. Dies verhindert, dass die Schutzmaßnahmen des Sticks unterlaufen werden und beispielsweise ein Keylogger oder Trojaner auf dem Hostsystem Bildschirminhalte oder Tastaturanschläge protokolliert."
Die Entwicklung guter Erkennungsstrategien einerseits und die Verbesserung von VMs zur Vermeidung einer solchen Erkennung andererseits ist ein fortwährender Wettlauf -- unter anderem zwischen Virenautoren und Antivirusherstellen. Aus theoretischer Sicht ist eine Erkennung einer virtualisierten Umgebung nicht unter allen Umständen zu garantieren. Allerdings kann es aus praktischer Sicht vergleichsweise schwierig sein eine solche Virtualisierungsumgebung zu implementieren (siehe z.B. [4]).
Dies führt zur Frage wie sich die Schutzmaßnahmen des SBS in diesem Spannungsfeld einordnen. Fehlermeldungen während des Bootvorgangs deuten darauf hin, dass die Erkennung ein Teil der kryptographischen Schutzmechanismen ist. Zeichenketten in der verantwortlichen Executable zeigen verblüffende Ähnlichkeiten zur Virtualisierungserkennung von systemd (der GPL-Code kann im Github Repository eingesehen werden). Allerdings wurde die Erkennung von systemd nie entwickelt, um gegen bösartige Angriffe zu bestehen, so dass es nicht überrascht, dass ein unmodifiziertes KVM einfach instruiert werden kann einen SBS in einer VM zu booten. Es genügt folgendes Kommando:
kvm -m 2048 \
-cpu host,kvm=off,-hypervisor \
-usb -device usb-ehci,id=ehci \
-device usb-host,bus=ehci.0,vendorid=0x8564,productid=0x1000 \
-smbios 'type=0,vendor=' -smbios 'type=1,manufacturer=,product=' \
-vga cirrusFalls ein Angreifer keinen physischen Zugang zu einem Stick haben sollte, sondern nur ein Image (beispielsweise von einem kompromittierten Rechner), kann er durch einen simplen Patch von QEMU den gleichen Ansatz verwenden. Blaupausen sind im Internet verfügbar.
Video: virtualization.mp4
Potentielle Implikationen:
Es existieren zwei Szenarien in denen die Schwachstelle zu einem erfolgreichen Angriff führen kann:
Der Nutzer weiß nicht, dass sein System virtualisiert betrieben wird. Wie bereits vor mehr als 10 Jahren demonstriert wurde, ist es bösartiger Software möglich, dass eigentliche Betriebssystem in einer VM auszuführen, um die eigene Anwesenheit zu verbergen [5]. Auch für einen dediziert gebooteten SBS sind verschiedene nutzertransparente Virtualisierungsangriffe denkbar. Beispiele sind:
Ein virtualisiertes Ecos-SBS-System kann jederzeit vollständig überwacht und modifiziert werden. Das bedeutet ein Angreifer ist in der Lage:
Zusammenfassend können keinerlei Sicherheitsziele garantiert werden, falls Virtualisierungsangriffe nicht effektiv verhindert werden können.
Mögliche Gegenmaßnahmen: Nutzer dürfen den SBS nicht in Geräte einstecken, die unvertrauenswürdige Hard- oder Software enthalten könnten. Administratoren müssen sich bewusst sein, dass Nutzer Virtualisierung verwenden, um ihre Sticks zu betreiben. Falls den Nutzern nicht vollständig vertraut werden kann, kann der SBS nicht sicher eingesetzt werden.
Zugewiesene CVE-Nummer: CVE-2018-12334
Der Hersteller erklärt: "Zusätzlich übernimmt das ECOS SECURE LINUX die Hoheit über die angeschlossene Peripherie, so dass selbst eine Schadsoftware im BIOS oder im UEFI keine Bedrohung darstellt."
Diese Aussage ist recht überraschend, denn sie widerspricht:
Um die Herstelleraussage zu validieren, wurde eine freiverfügbare UEFI-Hintertür von Github leicht modifiziert. So wurde beispielsweise eine einfache Speicherersetzungsstrategie implementiert, die es erlaubt IPsec-Sitzungsschlüssel auf portable Art und Weise zu extrahieren und über das Internet zu versenden. Das Resultat ist ein circa 600 Zeilen C-Code umfassendes EFI-Modul, welchen in einem MSI Z170A GAMING M7 Motherboard installiert wurde. Dazu genügt das Ausführen einer Datei mit einem Administrator-Account in einer unmodifizierten Windows-Installation. Dafür wurde ein aktuelles UEFI von der offiziellen MSI-Webseite bezogen, mittels eines UEFI Tools modifiziert und anschließend mit dem offiziellen MSI BIOS Upgrade Tool aufgespielt. Der Ansatz ist hochgradig flexibel, da das veränderte UEFI beispielsweise über gezielte Mails oder einen Rubber Ducky (siehe Video) injiziert werden kann.
Wie zu erwarten, kann der Ecos SBS die Extraktion des Schlüsselmaterials nicht verhindern. Ein Angreifer ist in der Lage, IPsec-Schlüssel auszuleiten und eine gekapselte RDP-Session in Echtzeit abzuhören.
Video: smmBackdoor.mp4
Durch Speichermanipulationen ist es ebenfalls möglich, Programmcode im SBS zur Laufzeit zu verändern. Zur Demonstration wurde der login-Prozess verändert, sodass er eine Root-Shell öffnet. Andere Veränderungen sind selbstverständlich ebenfalls möglich.
Video: loginPatch.mp4
Potentielle Implikationen:
Zusammenfassend können keinerlei Sicherheitsziele garantiert werden, falls die Firmware einer Hardware kompromittiert wurde auf der ein SBS ausgeführt wird.
Mögliche Gegenmaßnahmen: Nutzer dürfen den SBS nicht in Geräte einstecken, die unvertrauenswürdige Hard- oder Software enthalten könnten.
Zugewiesene CVE-Nummer: CVE-2018-12330
Ecos bewirbt die UEFI-Secure-Boot-Unterstützung als ein Sicherheitsmerkmal. Weiterhin geben sie an: "In einer »Chain-of Trust« überprüfen sich Bootloader, Kernel und Applikationen gegenseitig durch einen sich permanent wiederholenden Prozess."
Bereits die vorhergehenden zwei Schwachstellen unterstreichen, dass nicht die BIOS/UEFI-Komponente die Integrität und Authentizität des gestarteten Betriebssystems verifizieren muss, sondern dass das Betriebssystem in der Lage sein müsste zu verifizieren, dass es in einer authentischen Umgebung gestartet wurde. Dieses Sicherheitsmerkmal wird durch UEFI-Secure-Boot schlicht nicht realisiert. Ecos hat signifikanten Aufwand betrieben, um eine vom UEFI ausgehende eine "Top-Down"-Verifikation zu realisieren, allerdings kann ein Angreifer die Überprüfungen einfach entfernen oder die Komponenten ersetzen, zum Beispiel einen Vanilla-Kernel oder einen eigenen Bootloader. UEFI-Secure-Boot kann den Start eines so modifizierten Sticks nur unter folgenden Umständen garantiert verhindern:
Die letzte Bedingung impliziert, dass der Stick auf eine geeignete Art seine Umgebung verifizieren muss. Der Stick verifiziert allerdings aktuell nur den gestarteten Kernel (weder das BIOS/UEFI noch den tatsächlich aktiven Bootloader). Auch diese Authentisierung geschieht nur an zwei Stellen; wir werden uns im Folgenden auf die ausgeklügeltere konzentrieren. Hierbei geht der gestartete Kernel in den Prozess zur Entschlüsselung des SBS-Dateisystems mit ein. Ein tatsächliches Ausnutzen der ungenügenden vom UEFI-ausgehenden Vertrauenskette wird im Rahmen von Schwachstelle 10 vorgestellt.
Um Schlüsselmaterial abzuleiten, mit dem auf die verschlüsselten Teile des SBS zugegriffen werden kann, misst der initiale Userland-Prozess (das ìnit-Programm aus dem initrd-Image auf Partition 4) den Kernel, den Stick selbst und die aktiven Userland-Prozesse. Der Bootprozess beendet sich mit einem "Entschlüsselungsfehler", wenn Änderungen detektiert werden. Das heißt Modifikationen an der Bootkette, z.B. durch vorheriges Starten eines Programms, ändern die Messung und Modifikationen an später aktivierten Komponenten scheitern, da diese Teile verschlüsselt und authentisiert sind. Ein Angreifer könnte den Maschinencode der involvierten Executables analysieren, aber es existiert ein weit bequemerer und flexiblerer Weg: Fortschritte bei der Entwicklung von Sandboxing-Umgebungen können genutzt werden, den Prozess der Schlüsselgenerierung kontrolliert auszuführen. Beispielsweise kann usercorn verwendet werden, um alle Syscalls abzufangen, gegebenenfalls zu modifizieren oder zu unterdrücken. Unter Nutzung dieser Technik kann exakt kontrolliert werden, welche Informationen der Prozess erhält und welche verborgen bleiben sollen. Zum Beispiel kann der Signaturprüfung einfach ein anderes Image gegeben werden, als das welches später eingebunden wird. Falls der Nutzer kein Bootpasswort gesetzt hat, können auf diese Weise direkt alle Geheimnisse, die im SBS gespeichert sind, extrahiert werden.
Um ein vorzeitiges Abbrechen der Emulation zu verhindern, müssen weitere Syscalls in usercorn abgefangen werden. Dabei ist es jedoch hinreichend dem aufrufenden Prozess eine erfolgreiche Ausführung durch einen geeigneten Rückgabewert zu signalisieren. Eine eigentliche Implementation der Syscalls ist nicht erforderlich.
Die Verwendung von usercorn ist allerdings nicht die einzige Möglichkeit den Kontrollfluss bei der Schlüsselgenerierung zu steuern. Zumindest die folgenden fünf Ansätze sind denkbar:
init-Prozess dem Linux-Kernel übergibt, könnten in einem modifzierten Linux-Kernel vor der Ausführung geändert werden. Beispielsweise könnte der gestartete Prozess geeignet markiert werden, und beim Lesen von Dateien wie /proc/keys einfach den Inhalt einer anderen Datei erhalten.ptrace und seccomp verändert werden (Beispiel).init-Datei kann in einem Debugger gestartet und Breakpoints bei jeder int 80h-Instruktion (Syscall) gesetzt werden. Beim Anspringen der Breakpoints können anschließend die Argumente der Syscalls vor jeder Ausführung verändert werden.init-Programms legt die starke Vermutung nahe, dass es GPL-lizensierten Programm-Code enthält, wodurch das komplette Programm dieser Lizenz unterliegen würde. Der Hersteller wäre in diesem Fall verpflichtet, jedem Nutzer den vollständigen Programm-Code zugänglich zu machen, den dieser modifizieren und weitergeben könnte. Ein Angreifer könnte mittels des auf diese Weise beschafften Codes ein eigenes, beliebig modifiziertes init-Programm erzeugen.init-Binary durch Analyse und Veränderung des Maschinencodes in ihrem Verhalten zu modifizieren. Beispielsweise können Signaturprüfungen übersprungen oder Dateizugriffe umgeleitet werden.Video: offlineKeyExtraction.mp4
Potentielle Implikationen:
Mögliche Gegenmaßnahmen:
Die Folgenden drei Maßnahmen wirken nur in Kombination:
Zugewiesene CVE-Nummer: CVE-2018-12337
Unter Nutzung der Entschlüsselungsmethode ist es nicht nur möglich, das sogenannte "Firmware"-Image und die nutzerspezifische Konfiguration zu extrahieren, sondern es findet sich auch eine weitere Konfiguration im Verzeichnis basedata/certs der vierten Partition, die für alle unterschiedlichen Bootmethoden gleich ist. Diese Konfiguration ist nicht durch das Bootpasswort geschützt und kann daher in jedem Fall extrahiert werden. Das Verzeichnis enthält unter anderem eine verschlüsselte und signierte shadow Datei. Im untersuchten Stick hatte sie den folgenden Inhalt:
root:$6$kD.Sv/YPnhZqNwXw$xHvghwrKESSS4inwjPRFt5UNgsLXRuuCtUUIP1.W7qK08NkBF.n/vT7iRpSH4hLB2aZ8iPtuNQ20mlVoEaNgk1:10091:0:99999:7:::
setup:*:12101:0:99999:7:::
remotesetup:*:12101:0:99999:7:::
RUNPUyBUZWNobm9sb2d5IEdtYkg6IGNvbmYtc2lnbtlpePrdaFQhGVMzvKCum1Se8f8kAQAytCKRbYYaeiWywek18P0AAJ43Yhy/VUvpMUBdRom8Wd/WISBXe23ZqumopgwNDglYvcSm28AK+tufQxcX8P4MspVLuI07CH9CGLmPqgzffP0gqpPFbSsEGtBiCX/9h5epu7ARnGfKst/2uWLLSvXidcKqht2A6f38QxNO7MGxrKZ5wDOkqTnJx3nxjKFfN5Rpmlyz7gLo8s+VscAPqf6if8QzH6rksRHRAKFzPGcCtVKExNA5dxURNFGU10NUtuZUE5ZbawLSfhbxNenLBf3bAMLdKNxIPVZsJhPUEvHJntyK73Dype5o3JXiLmiPo/GSXmp31NCl50cAyvNFyIYpAQYBHxQAAAAAAAECfk1vZHVsZSBzaWduYXR1cmUgYXBwZW5kZWR+Cg==Die base64-kodierte Signatur verweist auf Ecos, wurde also nicht durch die Management Appliance generiert. Weiterhin ist die shadow-Datei bereits werksseitig auf Sticks vorhanden, die noch nicht initialisiert wurden, also auch noch keinen Kontakt zum Management des Kunden hatten. Dies weist auf einen weiteren undokumentierten root-Zugang hin. Im Unterschied zu Schwachstelle 1 allerdings nicht in der Management Appliance, sondern direkt auf den Sticks selbst. Dass es sich tatsächlich um einen Zugang handelt, der vom Hersteller auch über SSH genutzt werden könnte, wird im Zuge der nächsten Schwachstelle demonstriert.
Video: sbsRootAccess.mp4
Potentielle Implikationen:
Mögliche Gegenmaßnahmen: Der SBS darf nicht in Szenarien eingesetzt werden in denen ein Zugriff auf den SSH-Dienst möglich ist.
Zugewiesene CVE-Nummer: CVE-2018-12336
Bitte beachten Sie den Hinweis bezüglich des dokumentierten Fernwartungszugangs am Ende von Abschnitt 2.1. Dieser trifft auch auf den SBS zu.
Herstelleraussage: "Schreibgeschützte Partition für Firmware und Applikationen"
Technisch sauberer ist die Aussage, dass unautorisierte Modifikationen am Stick -- etwa durch Signaturüberprüfungen -- erkannt werden. Allerdings ist auch diese relaxierte Aussage nicht in jedem Fall aufrecht zu erhalten, wie anhand der folgenden drei Szenarien diskutiert wird.
Der SBS ist hardware-seitig ein völlig gewöhnliches USB-Speichermedium. Ein kompromittiertes Betriebssystem könnte den Inhalt des gesamten Stick also vollständig überschreiben, wenn der Nutzer den Stick einsteckt während das OS noch aktiv ist. Beispielsweise könnte es ein minimales OS auf dem Stick platzieren, welches nach dem Booten sofort alle Massenspeicher absucht und darauf vorhandene Betriebssysteme infiziert. Danach könnte es ein Ecos Logo mit der Fehlermeldung "Ihr PC wird nicht unterstützt, bitte verwenden Sie den SBS in einem anderen PC" zeigen.
Dieser Ansatz könnte es einem Angreifer erlauben, Malware von einem Heimarbeitsplatz auf einen PC innerhalb eines Firmennetzes zu verbreiten.
Wie bereits erwähnt ist zwar die sogenannte "Firmware", also die eigentliche Arbeitsumgebung des SBS, durch eine Signatur geschützt, die Stick-Konfiguration jedoch nur über einen von außen zu berechnenden symmetrischen Authentisierungswert. Das bedeutet, dass das Schlüsselmaterial welches zur Entschlüsselung verwendet wurde (siehe Punkt 8) auch dazu verwendet werden kann die Konfiguration zu verändern; möglicherweise ohne dass diese Modifikation erkannt wird. Die Stick-Konfiguration kann dabei selbst dann verändert werden, wenn das Bootpasswort nicht bekannt ist. Das bedeutet, die im Rahmen der letzten Schwachstelle beschriebene shadow-Datei kann verändert und so ein eigenes root-Passwort gesetzt werden. Eine Hürde ist noch zu nehmen: Der Angreifer muss die historische crypt-Methode benutzen, um den Hash des root-Passworts zu generieren und sicherstellen, dass eine update.conf-Datei im gleichen Verzeichnis existiert. Diese scheint nur auf manchen Sticks präsent zu sein und enthält die folgenden Daten:
reltype=V5.6.5
bbtype=mthc
fn1=ca.crt
fn2=base.pem
fn3=runtime.pem
fn4=shadow
fn5=my.pem
force-reltype=1Nach dieser Modifikation kann ein Angreifer über SSH auf den SBS zugreifen, unabhängig davon auf welchem Computer dieser gebootet wurde (sofern SSH-Netzwerkzugriff gegeben ist). Über die SSH-Sitzung können Langzeitgeheimnisse, Sitzungsschlüssel und Daten von der privaten Festplatte des Nutzers abgegriffen werden (der SBS enthält hierzu bereits einen NTFS-Dateisystem-Treiber). Zum Teil können diese auch modifiziert werden. Außerdem enthält das "gehärtete" Betriebssystem auch ein Werkzeug um Screenshots von der aktiven Nutzersitzung zu machen (/bin/xwd) und einen funktionsfähigen VNC-Server, sodass es möglich ist den Nutzer live zu beobachten oder sogar mit der Sitzung zu interagieren. Passives Beobachten wird dem SBS-Nutzer gegenüber nicht angezeigt (falls der Angreifer dies nicht explizit möchte).
Video: stickMod1.mp4
Auch ohne Ausnutzen des schwach geschützten Teils der Konfiguration ist es möglich den Stick auf geschickte Art zu modifizieren. So ist es möglich Signaturüberprüfungen vollständig zu entfernen und den Stick mit einer Hintertür zu versehen, die beispielsweise andere Betriebssysteme infiziert und den SBS als Wirt benutzt. Dazu können die initialen Signaturüberprüfungen durch einen eigenen Bootloader (mit Ecos-Theme) und Kernel ausgehebelt werden. Durch einen modifizierten Kontrollfluss während des init-Prozesses, fällt dies, ebenso wie eine Veränderung des squashfs-Dateisystems, nicht auf. Im Rahmen von Schwachstelle 8 wurden verschiedene Wege beschrieben mit denen eine solche Veränderung des Kontrollflusses erreicht werden kann.
Es verbleiben die Überprüfungen der geladenen Betriebssystemumgebung. Ecos beschreibt: "Wird eine Manipulation erkannt, schaltet sich der Stick sofort ab. Eine Manipulation des Sticks, egal ob im laufenden Betrieb oder im ausgeschalteten Zustand, wird so wirkungsvoll verhindert." Allerdings ist es relativ schwierig diese Sicherheitsüberprüfung überhaupt auszulösen, da sie auf einer (sehr kleinen) Whitelist zu basieren scheint. Von den 663 Dateien im /bin-Verzeichnis des "gehärteten" Betriebssystems scheint dies nur auf eine Handvoll zuzutreffen. Es ist daher sehr einfach diesen Schutzmechanismus zu umgehen. Für Demonstrationszwecke wurde das Werkzeug /bin/insmod im Ecos-OS ausgetauscht, um eine Windows-Installation zu infizieren. Die Datei wird regelmäßig ausgeführt und ist nicht durch die Whitelist geschützt.
Video: stickMod2.mp4
Potentielle Implikationen: Die Auswirkungen dieser Schwachstelle hängen stark vom Angriffsszenario und den Ressourcen des Angreifers ab. Hauptbedrohungen sind:
init-Prozess verändern, sodass das Bootpasswort oder die Smartcard PIN aufgezeichnet werden (falls er diese an anderer Stelle benötigt).Mögliche Gegenmaßnahmen:
Nutzer dürfen den SBS nicht in Geräte einstecken, die unvertrauenswürdige Hard- oder Software enthalten könnten. SBS sollten nicht an unterschiedlichen PCs verwendet werden, um ein etwaiges Verbreiten von Malware zu unterbinden.
Zugewiesene CVE-Nummer: CVE-2018-12333
In diesem Dokument wurden verschiedene Schwachstellen des Ecos SBS und seiner Management Plattform diskutiert. Die Sicherheitsanalyse hat sich dabei auf den Bootprozess und das Easy Enrollment fokussiert. Nichtsdestoweniger zeigen die Resultate, dass eine Reihe von Sicherheitsaussagen der Herstellerwebseite und Broschüren zumindest aktuell nicht zu halten sind. Dies umfasst:
Außerdem, wurden mögliche Herstellerhintertüren, eine Schwachstelle gegen Man-in-the-Middle-Angriffe und die Möglichkeit aufgedeckt, die interne Management-Datenbank auszulesen, inklusive aller privaten Schlüssel assoziierter SBS.
Einige dieser Schwachstellen mögen auf einfache Nachlässigkeiten zurückzuführen sein, etwa die aktivierten root-Nutzer oder die Möglichkeit die Datenbank zu spiegeln. Ein großer Anteil basiert jedoch auf konzeptionellen Fehlern. Von diesen könnten Schwachstelle 5 durch die korrekte Nutzung mit einer Smartcard abgewendet werden. Die Kernprobleme von Schwachstellen 4, 6, 7 & 8 liegen jedoch in Limitierungen der aktuellen x86-Plattform. Sie können nach Meinung der Autoren nicht ohne zusätzliche hardware-seitige Fähigkeiten oder die ausschließliche und exklusive Nutzung vertrauenswürdiger Hardware behoben werden.
Aus makroskopischer Sicht sind die beschriebenen Schwachstellen ebenfalls interessant, da sie zeigen wie wenig verlässlich punktuelle IT-Sicherheitstest bei Einführung eines Produktes sind. Die meisten Referenzkunden, die von Ecos angeführt werden, gaben an, dass sie interne oder externe Sicherheitstests durchgeführt haben. Die Empfehlungen implizieren, dass dabei keinerlei schwerwiegende Fragen bezüglich der Sicherheit aufgekommen sind.
Die Analyse unsererseits erstreckte sich über einen Zeitraum von ungefähr einem Monat und wurde neben unseren eigentlichen Forschungsprojekten durchgeführt. Professionelle Pentester werden vermutlich weniger Zeitressourcen haben, sodass sie die verschiedenen kryptographischen Verschleierungsschichten nicht durchdringen können. Selbst unser weniger beschränkter Zeitplan erlaubte keine vollständige Überprüfung aller Angriffsvektoren, die der SBS durch seinen Ansatz bietet. Dennoch ist es alarmierend, dass einige Herstelleraussage direkt der verbreiteten Meinung von Sicherheitsexperten widersprechen -- offensichtlich ohne signifikante Zweifel zu wecken. Am markantesten sind die folgenden Punkte:
Selbst der einfache BSI IT-Grundschutz enthält in Abschnitt M 4.63 die Anforderung "Der Telearbeitsrechner sollte über einen Boot-Schutz verfügen, um zu verhindern, dass unbefugt von auswechselbaren Datenträgern, z.B. von DVD oder USB-Stick, gebootet werden kann." Es existieren jedoch keine Hardware-Mechanismen, die zusichern könnten, dass nur authentische Sticks gebootet werden können. Dennoch behauptet Ecos zu M4.63 konform zu sein.
Die Schwachstellen wurden von Robert Lasch, Franz Girlich und Michael Rossberg (ohne bestimmte Reihenfolge) gefunden und mit Demonstrationen unterlegt. Wissenschaftliche Aufsicht führte Guenter Schaefer1.
Fragen und Anmerkungen können an Michael Rossberg via michael [dot] rossberg [at] tu [dash] ilmenau [dot] de gerichtet werden. Der korrespondierende GPG-Fingerprint lautet: FD9B 425C 8DE5 69D6 77ED 52C2 CC00 C314 0337 76C9
[1] J. Bauer, M. Gruhn, und F. C. Freiling, „Lest we forget: Cold-boot attacks on scrambled DDR3 memory“, Digital Investigation, Bd. 16, S. S65–S74, 2016.
[2] S. F. Yitbarek, M. T. Aga, R. Das, und T. Austin, „Cold boot attacks are still hot: Security analysis of memory scramblers in modern processors“, in High performance computer architecture (HPCA), 2017 IEEE international symposium on, 2017, S. 313–324.
[3] G. Ravago, „Reverse engineering a USB flash drive“. 2015.
[4] A. Sergeev, V. Minchenkov, und V. Bashun, „Malicious hypervisor and hidden virtualization of operation systems“, in Application of information and communication technologies (AICT), 2015 9th international conference on, 2015, S. 178–182.
[5] J. Rutkowska, „Introducing blue pill“, The official blog of the invisiblethings.org, Bd. 22, S. 23, 2006.
[6] S. Embleton und S. Sparks, „SMM rootkits“, in Proceedings of the 4th International Conference on Security and Privacy in Communication Networks, Securecomm, 2008, Bd. 8.
[7] J. Rutkowska, „Intel x86 considered harmful“, the Invisible Things Lab, 2015.
[8] K. Nohl und J. Lell, „BadUSB – on accessories that turn evil“, Black Hat USA, 2014.
Transparenzerklärung: Guenter Schaefer arbeitet Vollzeit als Professor an der Technischen Universität Ilmenau. Weiterhin ist er nebenberuflich ein Mitglied des Aufsichtsrats der secunet Security Networks AG.↩