„You can’t trust code that you did not totally create yourself.”

Wie verwundbar und anfällig sind Sie?

(Kommentar von Adrian Janotta)

Ein Backdoor ermöglicht den unerwünschten Zugriff auf Software (Betriebssystem, Anwendung, BIOS, Firmware, Verschlüsselungsalgorithmus). Das Ziel ist stets Spionage auszuüben. Ist ein Backdoor bereits in der Firmware der IT, ist es oft schon zu spät. Backdoors in Software sind heute im Jahr 2017 leider Alltag. Ken Thompson („Vater“ des Betriebssystems UNIX und der Programmierprache C) wies in seiner Turing Award-Dankesrede „Reflections on Trusting Trust“ (1984) daraufhin hin, dass nur Software vertrauenswürdig sein könne, welche man vollständig selbst erzeugt habe:

„You can’t trust code that you did not totally create yourself.”

und das KEINE Analyse des Source Codes, sei diese auch noch so gründlich, jemanden davor bewahrt, nicht vertrauenswürdigen Code (Malware, Backdoors, Rootkits usw.) zu benutzen:

“No amount of source-level verification or scrutiny will protect you from using untrusted code”

Ken Thompson belegt seine Schlussfolgerung mit dem Beispiel einer Backdoor, welche einem unveränderten Source Code per Kompilierung durch einen kompromittierten Compiler „eingeplanzt“ wird. Die Schlussfolgerungen von Ken Thompson sind in ihren Auswirkungen sehr weitreichend und schränken die Möglichkeiten stark ein, sich vor unerwünschter Software durch alleinigen Zugriff auf den Source Code zu schützen, da jegliche benutzte Software einschließlich der benutzen Compiler im Quellcode vorliegen muss.

Da dies auch für die Software zur Steuerung der benutzten Hardware (BIOS, Firmware, Prozessor-Microcode usw.) gilt, ist dies für den Durchschnittsnutzer praktisch nicht umsetzbar. Der alleinige Zugriff auf den Source Code, mehr gefühlte Sicherheit als wirklichen Schutz vor Backdoors bietet. Denn in der gelebten IT-Praxis wird sehr oft einfach der Binärcode von vertrauenswürdigen Anbietern eingesetzt, ohne den vorliegenden Source Code zu analysieren und anschließend zu übersetzen, und wenn die Quellen übersetzt werden, dann oft ohne Source Code-Analyse und in den wenigsten Fällen mit selbstgebauten Compilern und mit einer ganz gerringen Wahrscheinlichkeit auf Hardware die selbst gebaut wurde. CPU, Arbeitsspeicher, das Mainboard, alles müssten wir, wenn wir Cybersicherheit richtig Leben wollen, selbst herstellen.

„You can’t trust code that you did not totally create yourself.”

Hardware kann von Hackerangriffen betroffen sein, es ist jedoch nicht die Hardware selbst, sondern die Maschinenbefehle der Prozessoren. Diese müssen geschützt werden. Prozessoren, wie sie in Computern stecken, haben einen Satz an Maschinenbefehlen. „Das ist in Silizium gegossenes Betriebssystem für den Prozessor, also Software“. Solche Zugriffe der CPU können manipuliert werden und angegriffen werden. Das ganze nennt sich Embedded Security. Die rasante Miniaturisierung erlaubt die Fertigung von immer leistungsfähigeren, energiesparenden und kostengünstigeren Mikroprozessoren. In immer mehr Gegenständen unseres Alltags wie Autos oder Mobiltelefonen haben kleine Mikrocontroller Einzug gehalten. Solche eingebettete Systeme übernehmen vielfältige, anspruchsvolle und teilweise sicherheitskritische Aufgaben. Fehler in diesen Systemen können unmittelbare Auswirkung auf unser reales Leben haben.

Seit Jahren wissen wir, das dass für die Herstellung eines Prozessors verantworliche Verfahren, theoretisch Änderungen und Angriffe auf die Architektur ermöglicht. Das ganze CPU Design kann so kompromittiert werden. Sichere Methoden wären an dieser Stelle äußerst schwierig zu integrieren, ohne die Datenausgabe der Leistung selbst, Leistungsmerkmale der CPU oder die Stabilität zu ändern. Es gibt eine narrensichere Methode um die CPU selbst zu überprüfen um sicherzustellen, dass Sie richtig gebaut wurde. Das ganze geht nur mit einer visuellen Inspektion. Ingenieure müssen visuell die gesamte Oberfläche eines Kerns überprüfen, um sicherzustellen, das dass CPU Design mit dem ursprünglichen Design übereinstimmt. Jedoch reicht das nicht aus. Sogar Intels Hardware-Zufallsgenerator kann kompromittiert werden, dieser ist jedoch weder visuell detektierbar noch sichtbar, wenn der Chip beim Start getestet wird.

Ebenfalls ist es ein Problem, das die „Dotierung“ des Transistors sich auf die Einführung spezifischer Verunreinigungen in der kristalline Struktur befindet. Dieser Vorgang ist für die Halbleiterfertigung unerlässlich. Transistoren mit besonderen Eigenschaften können so erzeugt werden. Durch die Veränderung des Dopings von sehr spezifischen Regionen können die Angreifer das Verhalten des Initialen Zufallszahlengenerators (RNG) ändern. Speziell kann eines der Elemente, die verwendet werden, um zufällige Zahlen zu erzeugen, die variabel sein sollen, stattdessen als Konstante gesetzt werden. Aber es kommt noch viel Schlimmer: Die Technik dazu wird längst genutzt: Seit 1994 lässt sich Intel einen Zugang zu seinen Chips offen, um auf einfache Art und Weise Patches bei Bugs einspielen zu können. Seit 2000 soll Intel auf diesem Weg über 100 solcher Veränderungen am Microcode von Prozessoren vorgenommen haben. Andere Hersteller wie AMD haben diesen Ansatz übernommen. Es ist alles gefährdet, von der Firewall auf der eine Intel oder AMD CPU arbeitet bis hin zum Server. Ich sehe allerdings noch einen anderen Weg, über den Zugriff auf die Hardware von Rechnern erhalten kann: Getarnt als Windows-Sicherheits-Update.

Die Frage: Wie verwundbar sind Sie, ist daher ernst gemeint:

– Hintertüren und Backdoors ein Problem?
– Ist Hardware Spionage ein Thema?
– Ist Firmware Spionage ein Thema?
– Nutzen Sie angreifbare Software?
– Schadsoftware bzw. Malware, Trojaner, Würmer bereits im Netzwerk?
– Von Social Engineering betroffen oder ein Thema?
– Advanced Persistent Threats (APT),
–  ( Spam, Schadprogramm-Spam und Phishing)
– Botnetze, sind Ihre Server an einem Botnetz angeschlossen?
– Distributed Denial of Service (DDoS)-Angriffe,
– Drive-by-Exploits und Exploit-Kits ein Problem?
– Identitätsdiebstahl, Spoofing, Phishing, Pharming oder Vishing?
– Seitenkanalangriffe – bedacht?

Kommentar verfassen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.