Original-URL des Artikels: https://www.golem.de/news/security-jahresrueckblick-das-jahr-in-dem-die-firmware-brach-1801-131796.html    Veröffentlicht: 10.01.2018 12:03    Kurz-URL: https://glm.io/131796

Security

Das Jahr, in dem die Firmware brach

2017 wurde viel Firmware und andere grundlegende Computertechnik produktiv auseinandergenommen und kaputt gemacht. Gut so, denn die Fundamente moderner Computer sind oft brüchig.

Die Grundlagen moderner Computer sind oft unsicher - und setzen nicht auf bewährte Sicherheitstechnologien. Im Jahr 2017 hat sich gezeigt, dass zahlreiche Komponenten auf niedriger Ebene angreifbar sind und Nutzer gefährden, ohne dass diese das mitbekommen oder viel dagegen unternehmen können. Ob beim Prozessor und Chipsatz selbst, die WLAN-Karte, Bluetooth oder Krypto-Chips von Infineon - überall lagen kritische Fehler, die jahrelang unentdeckt blieben.

Gezeigt hat sich das unter anderem an der Diskussion um die Sicherheit von Broadcom-WLAN-Chips für Smartphones. Googles Project-Zero-Team hat in diesem Jahr gleich mehrere Sicherheitslücken gefunden, die Angreifern in WLAN-Reichweite der Geräte die Möglichkeit geben, diese komplett zu übernehmen und sogar einen Wurm zu entwickeln, der von Smartphone zu Smartphone springt.

Möglich sind solche Angriffe, weil die Chipsätze letztlich selbst Computer sind, mit einem eigenen Betriebssystem - der Firmware. Wenig überraschend ist auch diese für Sicherheitslücken anfällig. Tatsächlich ist die Softwarequalität in solcher Firmware oft sogar überraschend schlecht, eine tiefgehende Überprüfung des Codes findet meist nicht statt.

Firmware wird oft ungeprüft übernommen

Hersteller vernetzter Geräte übernehmen diese Firmware meist von den Chipherstellern, ohne diese im Detail anzupassen oder selber auf Schwachstellen zu überprüfen. So konnte es im Falle der WLAN-Chips passieren, dass damit auch iPhones angegriffen werden konnten, die eine deutlich bessere Sicherheit aufweisen als die Android-Konkurrenz.

Hinzu kommt, dass bei der Entwicklung der Firmware meist keine modernen Programmiersprachen zum Einsatz kommen, die auf die Vermeidung von Speicherfehlern ausgelegt sind, wie etwa Rust. Auch Anti-Exploit-Techniken wie Adress Space Layout Randomization (ASLR) sind meist nicht verbaut. ASLR sorgt dafür, dass von einem Programm kontrollierte Inhalte an einer nicht vorhersagbaren - also zufälligen - Stelle des Arbeitsspeichers abgelegt werden. Selbst wenn ein Programm dann einen Speicherfehler hat, kann dafür meist kein stabiler Exploit entwickelt werden, weil der Angreifer weniger Parameter kontrolliert.

Wie mächtig Firmware sein kann, zeigte sich auch nach der Veröffentlichung der WLAN-Sicherheitslücke Krack, auch wenn die konkrete Gefährdung durch Krack zumindest bislang nicht besonders hoch ist. Denn Intel legte kurz nach Veröffentlichung von Krack einen Patch für die eigene umstrittene Management Engine (Intel ME) vor. In dem Paket ist nämlich neben den Funktionen für die Fernwartung auch ein kompletter Wi-Fi-Stack enthalten, weil AMT auch Funktionen wie Wake-on-LAN und Wake-on-Wi-Fi anbietet. Künftig könnte WPA in Version 3 für Abhilfe sorgen - einen deutlich besseren Schutz bietet allerdings eine durchgängige TLS-Verschlüsselung. Doch Krack war nicht das einzige Problem der Management Engine. Weil Google sich für die eigenen Server nicht unhinterfragt auf Intels Black Box verlassen will, untersuchten Entwickler des Konzerns Intels ME- und AMT-Komponenten - und fanden heraus, dass diese ab Version 6 auf dem Unix-Derivat Minix basieren.

Ein Lehrprojekt wird zur Grundlagentechnik in der IT

Minix wurde ursprünglich als Betriebssystem zu Lehrzwecken entwickelt, Linus Torvalds nutzte es später als Entwicklungsumgebung, um den ersten Linux-Kernel zu programmieren. Ein professioneller Einsatz von Minix war von seinem Entwickler Andrew S. Tanenbaum eigentlich nicht vorgesehen. Doch Intel nutzte das C++-basierte System trotzdem als Grundlage der modernen Management Engine.

Untersuchungen aus dem Jahr 2017 zeigen nun, dass Intels Minix-Adaption zahlreiche für C-Projekte typische Fehler in der Speicherverwaltung aufweist, die zudem recht stabil ausgenutzt werden können. Auf der Black Hat Europe präsentierten die Hacker Mark Ermolov und Maxim Goryachy einen solchen Buffer Overflow, mit dem sie ein System von Virenscannern und anderer Sicherheitssoftware unbemerkt übernehmen können.

Das ist nach Angaben der beiden auch möglich, wenn die Intel ME eigentlich durch ein Kill-Bit außer Betrieb gesetzt wurde. Angreifer mit Zugang zu einem Rechner seien außerdem immer in der Lage, auf einem Rechner eine veraltete und damit unsichere Version von Intel ME aufzuspielen, um Angriffe durchführen zu können.

Intel selbst hatte nach den Hinweisen von Ermolov und Goryachy selbst eine Sicherheitsüberprüfung der Management Engine und der AMT-Komponenten durchgeführt und dabei weitere Sicherheitsprobleme entdeckt und gepatcht. Unklar ist nur, warum das Unternehmen diese Analyse nicht bereits vor Jahren durchgeführt hat - bevor die Firmware auf Millionen Chips eingesetzt wurde.

Doch mit den schlechten Nachrichten ist es für Intel im Jahr 2018 nicht vorbei: Bereits im vergangenen Jahr entdeckt, veröffentlichten Wissenschaftler Anfang 2018 Details über brisante Sicherheitslücken mit den Namen Meltdown und Spectre in fast allen Prozessoren. Die Art und Weise, wie diese Informationen sowohl aus dem Kernel als auch aus dem Userspace verwalten, macht sie für Angriffe anfällig - die dann genutzt werden können, um eigentlich vertrauliche Inhalte aus dem Kernelspeicher auszulesen. Die Patches gegen Meltdown und Spectre stellen die IT-Industrie außerdem vor neue Herausforderungen: Wie patcht man einen Fehler in Hardware? Intel will 90 Prozent der betroffenen Prozessoren mit Mikrocode-Updates ausstatten - doch diese Updates werden für andere Sicherheitsforscher kaum nachvollziehbar sein.

Andere Hersteller passen ihr Betriebssystem und den Browser an, um Angriffe möglichst zu erschweren. Intel reagiert außerdem, indem die eigene Entwicklungsabteilung um ein neues Sicherheitsteam erweitert wird - damit ähnliche Fehler in Zukunft unterbleiben.

Der besonders betroffene Prozessorhersteller Intel versuchte zunächst, die Auswirkungen der Entdeckung herunterzuspielen, nannte Berichte über die Sicherheitslücke und Auswirkungen der Patches auf die Systemleistung zunächst "wildly inacurate". Dabei gibt es bereits erste Veröffentlichungen über die angreifbare "spekulative Ausführung" bestimmter Inhalte aus den 90er Jahren und Vorträge über Risiken in KASLR aus dem Jahr 2016. Die Probleme waren also grundsätzlich bekannt, wurden aber offenbar ignoriert.

Bluetooth ist kaputt gewesen

Ebenfalls für Aufregung sorgten zahlreiche Lücken in den Bluetooth-Stacks verschiedener Geräteklassen - also Android-Smartphones, die Windows-Implementierung oder auch die Verwendung von Bluetooth unter MacOS und iOS. Und auch in diesem Fall fällt auf: Viele der Fehler in den bis zu fünf Milliarden Geräten basierten auf unsicheren Programmiersprachen. Besonders in Linux-Umgebungen konnten Angreifer eine ganze Reihe von Speicherfehlern ausnutzen. Schuld war ein Speicherüberlauf in der Anwendung L2CAP - dem Logical Link Control and Adaption Protocol. Anders als bei den Sicherheitslücken in WLAN-Chips wäre es hier nicht notwendig, den Zwischenschritt über den WLAN-Controller zu gehen. Ein Pairing ist für den Angriff nicht notwendig.

Mehr Grundlagenforschung im Bereich IT-Sicherheit

Zu den notorisch von Sicherheitslücken betroffenen Geräten gehört auch die Firmware von Routern, Modems, Firewalls und einfachen IoT-Geräten. Nicht alle Hersteller dieser Geräte sind traditionell auch Softwareentwickler und verfügen somit nicht unbedingt über die Kompetenz, sichere Software zu entwickeln. Auch hier gibt es zudem oft das Problem ungeprüfter Lieferketten und die blinde Übernahme von Code, ohne dass die Grundlagen der eingesetzten Software von den Herstellern überprüft werden.

Angesichts zahlreicher Sicherheitslücken und der immer größeren wirtschaftlichen Bedeutung funktionierender IT-Systeme wird gerade aus der Politik immer wieder eine Haftung für Sicherheitslücken durch die Hersteller gefordert. Die SPD und die CSU hatten entsprechende Forderungen sogar in ihren Wahlprogrammen. Unklar bleibt dabei nur, wie genau eine solche Haftung sinnvoll umgesetzt werden könnte. Wären Hersteller dann zum Beispiel für Lücken in Bibliotheken und Open-Source-Komponenten verantwortlich und müssten haften?

Und was ist mit zu Anschauungszwecken entwickelter Software wie Minix - die sich dann auf einmal in einem kommerziellen Produkt wiederfindet? Geht die Haftung dann auf den Hersteller der kommerziellen Produkte über oder verbleibt diese beim eigentlichen Entwickler?

Staatliche Zertifizierungen sind zudem keine Garantie für eine sichere IT. Das zeigte sich in diesem Jahr gleich mehrfach im Falle von staatlich zertifizierten Krypto-Verfahren angesichts des Duhk-Angriffs und einer Schwachstelle in Infineon-Chips, die Yubikeys genauso betrifft wie die estnischen Personalausweise mit eID-Funktionen. Warum sollte ein staatliches Siegel für Software dann ausgerechnet Sicherheit garantieren, wenn schon Datenschutzbehörden kaum mit der Aufsicht von Unternehmen hinterherkommen?

Kaputte Technik lässt sich oft nur schwer ersetzen

Am aktuellen Beispiel der stockenden Einführung der neuen TLS-Version 1.3 zeigt sich außerdem, wie umständlich es ist, neue Technologien flächendeckend zu verbreiten - selbst wenn alte Standards schon lange als unsicher gelten. Schon fehlerhafte Geräte weniger Hersteller können für die Dienstebetreiber wie Cloudflare inakzeptable hohe Fehlerraten verursachen. Wer also die IT-Sicherheit in wichtigen Systemen verbessern will, muss oft Jahre vor praktisch möglichen Angriffen damit beginnen, die Basis dafür zu schaffen.

Der beste Weg zu sichereren Grundlagen in der IT scheint daher zu sein, häufig genutzte Basiskompontenten künftig gründlicher auf Schwachstellen zu untersuchen - eine neue Grundlagenforschung im Bereich IT-Security. Bereits beim 33C3 hatte der Hacker Karsten Nohl nach einer Analyse der Sicherheit von Passenger Name Records im Flugverkehr dazu aufgerufen, "mehr Legacy-Systeme anzugreifen".  (hg)


Verwandte Artikel:
Fluggastdaten: Regierung dementiert Hackerangriff auf deutsches PNR-System   
(10.03.2018, https://glm.io/133261 )
Playstation: Firmware-Update bringt Supersampling und Elternkontrolle   
(08.03.2018, https://glm.io/133232 )
Microsoft: KI-Framework kommt auf Windows-10-Endgeräte   
(08.03.2018, https://glm.io/133217 )
Qualcomm-Übernahme: Intel könnte versuchen, Broadcom zu kaufen   
(12.03.2018, https://glm.io/133276 )
Librem 5: Purism-Smartphone bekommt Smartcard für Verschlüsselung   
(09.03.2018, https://glm.io/133248 )

© 1997–2018 Golem.de, https://www.golem.de/