Meltdown, Spectre, beA – der nächste Supergau vor der Tür

Was haben die größten IT-Schlagzeilen der letzten Woche gemeinsam? Sie betreffen alle die Sicherheit des Datenaustausches. Doch während beA einfach misslungen ist, stammen Meltdown und Spectre hauptsächlich von der Hardwareseite der bekanntesten Hersteller Intel, AMD und Apple und bedeuten für alle ein sehr großes Datenschutzproblem.

Der letzte Monat des vergangenen Jahres war nur gefüllt von Meldungen um Datenschutzprobleme, von beA über Kernschmelze und Schreckengespenst;nicht nur Fachbeiträge der IT sondern auch die Juristen haben sich dazu gemeldet. Hauptsächlich wurden aber Fachbegriffe genannt und man hat sehr schnell den Überblick über die Geschehnisse verloren. So möchte ich in diesem Beitrag die tatsächlichen technischen Hintergründe kurz zusammenfassend erklären.

off:Sollte etwas am Ende unklar oder unrichtig sein, bitte schreibt mir/uns in den Kommentaren; denn Datenschutz betrifft und alle und somit sollten alle verstehen können, worum es aktuell (u.A. auch) geht.

Meltdown & Spectre- aka die Hardware-Problematik

Trennung von Speicherbereichen=Speicherschutz? – die Grundlagen

Die großen Lücken unter den Namen stammen jeweils aus dem Prozessor (CPU), also das Rechenwerk aller Maschinen, deren Kernaufgabe es ist Befehle der Reihe nach abzuarbeiten und an andere Prozesse abzugeben und somit diese zu steuern. Dabei gelangen die Befehle in den Speicher des Computers. Dabei wird eine sogenannte virtuelle Speicherverwaltung (virtual memory management, VMM) geöffnet, um den technisch und tatsächlich vorhandenen Arbeitsspeicher von einem bestimmten Bereich abzutrennen und einem Prozess zuzuweisen, um die Daten nur dort zur Verfügung zu stellen, wo sie auch gebraucht werden. Der Vorteil dabei ist, dass Programme untereinander getrennt werden und somit nicht auf den Speicher eines anderen Programmes zugreifen können. So stürzt zum Beispiel nicht das gesamte Betriebssystem durch einen Fehler der Browser ab; eventuell virenbehaftete Programme können grundsätzlich die Bankzugangsdaten beim Onlinebanking nicht rauslesen. Würden jedoch Programme vollständig voneinander separiert werden, wäre zum Beispiel Copy & Paste von einem Programm in das Andere gar nicht erst möglich, sodass heute eine kontrollierte Speichertrennung mit kleinen Brücken durchgeführt wird. Diese kleinen Brücken nutzen den sog. Cache

Im Endeffekt ähnelt es der Arbeitsweise eines Partners in einer Großkanzlei. Er hat sein Büro, seine Angestellten, seine Fälle. Bei der Übernahme der Mandate werden die relevanten Informationen dem Mitarbeiter zugewiesen, der sich mit diesem beschäftigen soll. Dieser steht jedoch bei Nachfragen stets in Kontakt mit weiteren Stellen innerhalb der Kanzlei. So wendet er sich bei Fristenfragen auch an den Fristenanwalt, bittet das Sekretariat um einen Anruf des Mandanten bei Nachfragen etc. Doch den Fall bearbeiten wird er im Zweifel alleine.

Cache, der digitale und intelligente Kühlschrank

Der Cache ist wie ein Kühlschrank, indem die darin enthaltenen Sachen systematisch nach Benutzung sortiert werden. So wird bei manchen die Butter ganz vorne stehen, bei einem erfolgreichen Manager der Sekt, etc. Dabei ordnet der Cache diese nicht nur neu bei Änderung der Verwendungskapazität, sondern bewahrt sie auch auf indem er diese zwischenspeichert. Kopiert man zum Beispiel einen Text von einer Webseite, landet dieser im Cache, um im nächsten Schritt dem in der Bearbeitung befindlichen Text hinzugefügt zu werden. So laden innerhalb kürzester Zeit oft besuchte Webseiten schneller, als wenn man sie tagelang nicht mehr besucht; u.a. auch deswegen schneller, weil sie sich noch zum Teil im Cache befinden.

Das eigentliche Problem

“bounds check bypass” (CVE-2017-5753): Spectre

“branch target injection” ( CVE-2017-5715 ): Spectre

Grundsätzlich läuft jeder Rechenprozess entlang der Maschinenbefehle im Programm (sog. In-order execution), so auch Studierende der Juristerei, wenn sie sich an den Gutachtenstil halten: Obersatz, Definition, Subsumtion und Ergebnis. Während aber ein Student im Gutachtenstil niemals ein Ergebnis vorwegnehmen sollte oder gar die Reihenfolge durcheinander bringen, besteht bei der Ausführung von Maschinenbefehlen die Möglichkeit die Befehle in einer anderen Reihenfolge auszuführen, als im Programmcode vorgesehen (out-of-order execution). Man muss es sich so vorstellen:

Studentin S guckt sich einen Sachverhalt an und überlegt sich erstmal alle in Betracht kommenden Tatbestände, die im Folgenden zu prüfen sind. Sodann überlegt sich S wo die Probleme liegen und löst diese schon vorab und formuliert die, die am schnellsten erledigt werden auch aus. Außerdem schreibt S zu den einzelnen Tatbeständen auch schon mal die einschlägigen Definitionen hin, um sich Zeit für die eigentliche Arbeit zu sparen. Würde man diese Klausur digital schreiben, müsste man nur noch den übrigen Text, z.B.: Obersatz und Subsumtion einfügen, während man in der handschriftlichen Klausur erst alles komplett nochmal neu abschreiben müsste. Es macht bei einer schriftlichen Arbeit daher auch wenig Sinn alles vorab auszuformulieren; man hat ohnehin nicht mehr Zeit als eine Gliederung Stichpunktartig aufzuschreiben um dann mit dem Gutachten zu beginnen. Ein Prozessor kann aber unterschiedliche Teile der Aufgabe vorab bereits lösen, bevor die Ergebnisse gebraucht werden und so wesentlich effektiver arbeiten. Diese Ergebnisse landen im Cach bis sie gebraucht werden.

“rogue data cache load“ (CVE-2017-5754): Meltdown

Das Meltdown (Kernschmelze) Problem der (hauptsächlich) Intel Prozessoren stammt aus der Arbeitsweise der sog. speculativ Execution (spekulative Ausführung). So überlegen sich Vorhersagefunktionen, welche Befehle und Daten als Nächstes ausgeführt werden bzw. benötigt werden könnten und führen diese, sofern sie als am wahrscheinlichsten erscheinen, mit Hilfe von untätigen Ressourcen nebenbei aus, um lange Wartezeiten zu vermeiden. Im Grunde genommen sind sie ein KI. So können diese Daten dann verwendet werden, wenn das Programm an die Stelle gelangt. In etwa so, als würde ein Anwalt bei Klagedrohung bereits seine Klagerwiderung vorbereiten, obwohl der Sachverhalt sich vielleicht vor Klageerhebung doch noch erledigt oder als würde ein Richter bereits die Haftanordnung eines im Verdacht stehenden Wiederholungstäters im Vertrauen darauf vorbereiten, dass er zum Termin nicht erscheinen wird, dieser jedoch überraschend tatsächlich erscheint. Der Unterschied ist nur, dass ein Richter oder Anwalt selten untätige Ressourcen haben wird, um diese einzusetzen. Diese vorbereiteten Daten landen vorerst im Cache, wo sie dann entnommen werden, wenn sie gebraucht werden.

Ein Angriff könnte dann zum Beispiel über eine Schadsoftware, welche gleichzeitig laufen soll, erfolgen; indem Prozesse soweit provoziert werden, dass genau die Daten, Passwörter etc. in den Cache gelangen, die man haben möchte. So in etwa als würde man einem Richter so lange erzählen, dass der Verdächtige mit Sicherheit nicht kommen wird, bis dieser schon mal vorab den Haftbefehl vorbereitet um diese sodann vom Schreibtisch zu entwenden.

Die gesamte Problematik ist jedoch sehr kompliziert. Ein potenzieller Hacker müsste für einen Eingriff genau wissen, welche Angriffstechniken verwendet werden sollen, abhängig von dem eingebauten Prozessor(Modell, Jahrgang etc.) Außerdem müsste er das Schadsoftware speziell für jeden Prozessor einzeln anfertigen. Denn die Bauweise der Prozessoren wurden über die Jahre Modell für Modell geändert, sodass man davon ausgeht, dass keine Universalschadensoftware für alle Prozessoren wirksam eingesetzt werden kann. Da die Probleme aus der Hardware stammen, wird es entsprechend schwieriger diese zu lösen, sodass erstmal die Softwarehersteller gefragt sind eine vorübergehende Lösung zur Verfügung zu stellen; diese führen allerdings derzeit zu kleineren und größeren Leistungseinbußen. Ob die Hersteller der Prozessoren in irgendeiner Weise die Lücken stopfen können, wird man zukünftig sehen. Ich wage es zu bezweifeln dass eine in Aussicht gestellte Firmwarelösung durch Intel über das Problem hinweghelfen wird, zumal die bereits ausgelieferten Patches Fehler enthielten (s.hier)

Wer sich fragt, ob sein Rechner betroffen ist: mit dem Schnelltest-Tool „Spectre Meltdown CPU Checker“ von Ashampoo und vom SpecuCheck von Alex Ionescu kann der eigene Rechner auf das Vorhandensein der Schwachstelle überprüft werden.

Kurze Zusammenfassung und Überleitung

Auch wenn das besondere elektronische Anwaltspostfach perfekt funktionieren würde, würde man ohne Sicherheitspatches und Firmwareupdates Informationen aus dem sicheren Kommunikationskanal abgreifen können, auch wenn dies in der Praxis nicht so einfach sein dürfte und u.a. Intel davon ausgeht, dass die Lücken bisher nicht ausgenutzt wurden. (https://www.focus.de/digital/computer/chip-schwachstellen-intel-chef-geht-wegen-sicherheitsluecke-in-die-offensive_id_8272953.html) Wichtig ist daher, die eigenen Systeme stets aktuell zu halten.

Zum Glück braucht sich Atos & BRAK derzeit keine Gedanken um einen Sicherheitspatch für beA zu machen, denn das Postfach funktioniert nicht. Es funktioniert sogar so sehr nicht, dass es mittlerweile komplett abgeschaltet wurde, ganz zum Ärgernis derjenigen, die bereits auf den Kanal gebaut haben. Warum aber eigentlich?

beA- Die Zertifikat-Problematik

Quelle: bea.brak.de

„Um die derzeitigen Zertifikate-Probleme zu begreifen, muss man zunächst etwas über die Funktionsweise der beA-Software wissen.“ So stellte Constantin v. L. In seinem Beitrag in der F.A.Z- Einspruch Ausgabe die hauptsächlichen Probleme sehr anschaulich dar. So wird es „von der Software auf jedem Anwaltsrechner ein eigener kleiner beA-Webserver eingerichtet. Wer auf sein Postfach zugreift, stellt also zunächst eine Verbindung von seinem Browser zu dieser lokal installierten Software her.

Die Verbindung zu dem lokalen beA-Webserver wird zudem über ein Zertifikat gesichert. Solche Zertifikate sind im Internet inzwischen weit verbreitet und kommen vor allem auf Seiten zum Einsatz, an die sensible Daten übermittelt werden, also zum Beispiel beim Onlinebanking, auf Händlerseiten oder bei sozialen Netzwerken. Die Zertifikate verbürgen, dass es sich bei der besuchten Seite tatsächlich um die handelt, für die sie sich ausgibt. „Was genau heißt es?“
Während die online Kommunikation in ihren Anfangsjahren quasi ohne jeglicher Art von Datenschutz verlief, erfolgt der Datenaustausch heute verschlüsselt, um einen Zugriff und ein Ausspähen der Daten zu vermeiden. So verschicken wir heute keine digitalen Postkarten ohne Briefumschläge mehr. So sieht es auch die Rechtslage vor, vlg. § 13 (4) Nr. 3., (7) TMG. Doch wie genau funktioniert das?

Eine durch TLS (Transport Layer Security Standard), im Alltag unter der veralteten Ursprungsversion SSL (Secure Socket Layer) bekannt,verschlüsselte Webseite lässt sich daran erkennen, dass die Domain der Webseite anstatt mit http:// mit httpS:// beginnt und ein kleines Schlosssymbol erscheint.

Die Funktionsweise ist im Grunde recht einfach: gibt man eine Adresse in den Browser ein, so versendet der zur Webseite zugehörige Server sein SSL/TLS-Zertifikat. Diese wird dann vom Browser bei der ausstellende Zertifizierungsstelle überprüft. Ist das Zertifikat gültig, entsteht eine gesicherte Verbindung zwischen Server und Browser, in der alle übertragenen Daten verschlüsselt werden. Gleichzeitig wird so sichergestellt, dass der Inhaber der Webseite derselbe ist wie der Inhaber des Zertifikats. So kann man sicher gehen, dass man nicht von Hackern umgeleitet wurde.

Sicherheitszertifikat

Damit die sichere Kommunikation funktionieren kann, müssen sich die Teilnehmer zunächst einmal autorisieren, um dem Browser zu zeigen, dass u.a. der aufzurufende Server auch zu der Domain gehört, für die er sich ausgibt. Während des Verifizierungsverfahrens der verschiedenen Zertifizierungsstellen werden neben unterschiedlichen Informationen auch ein sog. Öffentlicher Schlüssel (public key) hinterlegt, mittels dieser die Nachrichten verschlüsselt werden aber nicht entschlüsselt werden können. In etwa so, als würden sie ihr eigenes Alphabet bei der Zertifizierungsstelle hinterlegen; es funktioniert allerdings nur in eine Richtung. Um die Nachrichten wieder zu entschlüsseln wird ein weiterer, privater Schlüssel (private key) benötigt, welcher auf dem verifizierten Server installiert und ausschließlich diesem bekannt wird. Somit wird jedem die Möglichkeit geboten seine Nachrichten verschlüsselt an den Server zu schicken, jedoch kann nur der Server die Daten auslesen.

Was jedoch bei beA im Dezember (u.a.) passiert ist, ist dass der private Schlüssel im Zuge der Anpassung durch Atos öffentlich gestellt wurde, sodass der eigentliche Sinn und Zweck der SSL-Verschlüsselung aufgehoben und überflüssig gemacht wurde.

Ergänzung am 16.01.18: Genau genommen und detailliert betrachtet stimmt der letzte Satz nicht ganz, vielmehr erscheint dieser nach einem Austausch mit Herrn Jörn Erbguth “etwas missverständlich”. Denn “[m]an könnte ihn so lesen, dass ATOS unnötigerweise einen privaten Schlüssel für die Kommunikation zwischen Anwalt und BRAK veröffentlicht hätte. Das war aber so nicht der Fall. Der problematische private Schlüssel war von Anfang an in jeder Version des Clients enthalten, da er dazu diente, die Kommunikation zwischen dem Web-Browser und der “Client-Security” als https zu gestalten. Die Client-Security braucht diesen privaten Schlüssel, um selbst als https-Server zu fungieren. Markus Drenger hat diesen privaten Schlüssel aus der Software herausgeholt und ihn an Telesec gemeldet. Die Telesec hat daher das entsprechende Zertifikat gesperrt. Das große Problem entstand dann mit der Anleitung von ATOS, die dazu gedacht war, dieses Problem zu “lösen”. Dazu sollte statt einem von einer Zertifizierungsstelle signiertes Zertifikat ein Root-Zertifikat installiert werden. Dieses war dazu noch so konfiguriert, dass es ermächtigt war, weitere Zertifikate auszustellen. Dieses Root-Zertifikat sicherte zunächst einmal nur wieder die lokale Kommunikation zwischen Client-Security und Browser. Weil es aber weitere Zertifikate ausstellen konnte und natürlich der private Schlüssel in der Software enthalten war, konnte man damit den Anwälten beliebige falsche https-Verbindungen vortäuschen. Beim beA gibt es mindestens vier verschiedene Arten von „privaten Schlüsseln“. Das kann in der Kommunikation zu Missverständnissen führen. ”

An der Stelle vielen Dank für den Hinweis und die detaillierten Ausführungen und Richtigstellung an Herrn Erbguth.

Doch leider war das Zertifikat nicht das einzige Problem. Den entsprechenden Vortrag von Markus Drenger vom CCC Darmstadt könnt ihr euch hier dazu anschauen:

Video: Talk von Markus Drenger auf dem 34C3 zum BeA (45:16)

Eine wichtige Frage stellt sich am Ende noch: Wie konnte es sein, dass Meltdown & Spectre über Jahre und Jahrzehnte unentdeckt blieben? Wie konnte es sein, dass das Sicherheitsaudit des beA durch die Sicherheitsfirma SEC Conult die gravierenden Probleme (angeblich) nicht entdeckte?

Wenn wir für Datenschutz plädieren und persönliche Informationen über alles schützen wollen, um u.a. auch dem Anwaltsgeheimnis gerecht zu werden, müssen wir uns selbst zwingen diese Themen zu verstehen und kritisch zu hinterfragen. In der Zukunft wird ein zunehmendes Bewusstsein aller Parteien nötig sein. Insbesondere dürfen wir uns nicht für dumm verkaufen lassen.

An der Stelle vielen Dank an Anders Fogh von G DATA Advanced Analytics, der in Zusammenarbeit mit der TU Graz die Grundlagen für die Entdeckung der Sicherheitslücken Meltdown und Spectre lieferte, sowie Markus Drenger für die Überprüfung des beAs.