No BadBIOS - Retro Hack
Eine Absicherung gegen BIOS/UEFI-Ransomware, Staatstrojaner und BIOS/UEFI-Rootkits
1.1 Ergänzung des Write-Protect Jumpers am UEFI/BIOS FLASH
Die BIOS/UEFI Firmware wird oft in FLASH-Bausteinen mit den Bauformen TSOP, BGA, PLCC oder auch in seriellen EEPROMs als SOIC8 oder PDIP8 Ausführung gespeichert. Viele dieser FLASH-Bausteine besitzen einen Write-Protection Anschluss. Das Funktionsprinzip dieses Eingangs besteht darin, dass bei Anliegen eines Steuersignals (in der Regel LOW-Pegel oder GND) alle Befehle zur Umprogrammierung des Bausteins nicht mehr angenommen werden. Diese Funktionalität ist in den Bausteinen fest verdrahtet (Hard-Wired). Ältere Mainboards waren sehr oft mit einem sogenannten Jumper (Kurzschlussbrücke) ausgestattet. Je nach Layout des Mainboards musste dieser Jumper gesetzt oder gezogen werden, um am /WP-Pin permanent ein LOW zu erzwingen. Natürlich war auch die Unterbrechung der Programmierspannung bei noch älteren FLASH-Speichern ebenfalls eine sichere Variante, um ein Umprogrammieren zu verhindern.
Ein unbeabsichtigtes oder unbemerktes Umprogrammieren des BIOS-Speicherinhalts konnte mit dieser Technik sehr einfach verhindert werden. (Der Schreibschutz-Jumper ist nicht zu verwechseln mit dem BIOS-Reset Jumper, der eine eingestellte BIOS-Konfiguration in einem flüchtigen CMOS (BIOS)RAM auf einen Standardzustand zurücksetzt.)
Weder Softwarecommandos noch fehlerhafte Steuerbausteine (s. u.) konnten diesen Hardwareschreibschutz aufheben. Nur noch zum Zeitpunkt eines erforderlichen BIOS-Updates, also mit physischen Zugang von einem Sachkundigen, konnte das BIOS dann noch verändert, also der Schreibschutz aufgehoben werden. Die ohnehin sehr seltenen BIOS-Updates wurden dann meist von Spezialisten durchgeführt, die auch in der Lage waren, ein PC-Gehäuse zu öffnen und den Hardwareschreibschutz manuell aufzuheben.
Ein Schreibschutz-Jumper ist leider nur noch sehr selten auf aktuellen Mainboards zu finden. Anscheinend vertraut man mehr auf Softwaremechanismen, wie bspw. signierte Firmwareupdates und die korrekte Funktion der Steuerbausteine, die ein BIOS/UEFI gegen ungewollte Manipulation absichern sollen. Gegen direkte Sabotage, wie ich sie im gleichnamigen Link beschreibe, sind sie völlig nutzlos, und auch die anderen SW-basierten Mechanismen erweisen sich als unwirksam. (s. US-Cert warnt vor weiteren UEFI-BIOS-Lücken o. a. "race condition exists in Intel chipsets that rely solely on the BIOS_CNTL.BIOSWE and BIOS_CNTL.BLE" ) Diese speziell Angriffsmethode über BIOS WE-Bits betrifft die Bausteine, die das BIOS-FLASH ansteuern und nicht den BIOS-FLASH und seine HW-Write Protection selbst. Lojax nutzt diese "Race-Condition" ebenfalls aus (s. ESET Abb. 2).
1.2 No BadBIOS in 15 Minuten für 10 Cent
Ausgehend von den Erfahrungen mit dem USB-Stick-Hack, war es für mich naheliegend, den Umbau auch mit den BIOS-FLASH-Speichern auf einem Mainboard auszuprobieren.
Oft muss die Funktionalität des /WP-Pins der FLASH-Bausteine noch über ein internes programmierbares Register im selbst freigegeben werden. Sind die entsprechenden Blockprotection- und Enable-WP-Bits in den Registern gesetzt, können sie bei aktivem /WP-Pin auch nicht mehr umprogrammiert/zurückgesetzt werden. (Eine Hardware-Protection würde sonst keinen Sinn ergeben, wenn doch wieder alles über Software veränderbar wäre.) Mir ist kein Mechanismus bekannt, mit dem der Schreibschutz bei aktiviertem WP-Pin und programmierten Statusregistern umgangen werden kann. Hersteller weisen ebenfalls darauf hin: Bsp. Maconix MX25L4005 s. S.18 ..„ it is impossible to write the Status Register ..“.
Als Vorbereitung muss der Bausteintyp und die Position vom BIOS-FLASH auf dem Mainboard ermittelt werden. Auch ein TSOP-FLASH-Baustein kann noch mit einer Write-Protection ergänzt werden (s. Umbau der USB-Sticks). Ist es ein BGA-Gehäuse oder gelötetes PLCC-Gehäuse würde ich von einem Umbau abraten. Insbesondere bei einem BGA-Gehäuse ist es eine Herausforderung, die /WP-Leitung zum Bauteil (falls vorhanden) zu finden und zu unterbrechen.
Programmierwerkzeuge wie FLASHROM oder ein BIOS-Programmierservice können weitere Hinweise auf den Bausteintyp geben.
Danach sollte auf jeden Fall das Datenblatt des FLASH-Bausteins studiert werden. Gibt es überhaupt einen /WP-Pin? Teilt der /WP-Pin seine Funktion mit einer Datenleitung? - Dann wird ein Umbau vermutlich das Mainboard zum Brick machen. Müssen Statusregister programmiert werden, um den /WP-Pin zu aktivieren? Gibt es eine Programmiersoftware und ein Programmer mit Programmierclip mit denen diese Statusbits gesetzt werden können?
Als Übung und zum Testen meiner Idee verwendete ich einen älteren PC. Mein bestes Mainboard wollte ich noch nicht dem Risiko aussetzen, in den ewigen Jagdgründen zu landen. Der Umbau wurde an einem EEPROM-Baustein eines ASUS M2V-MX Mainboards vorgenommen. Der BIOS-Baustein ist ein MX25L4005M von Macronix im PDIP8 Gehäuse. Er ist sogar gesockelt, also ein Heimspiel für Bastler.
Abb. 1: DIL Adapter mit WP-Jumper und Pulldown
Mit einem selbst gelöteten Zwischenadapter (s. Abb. 1) erfolgte der Umbau analog zu dem vom USB-Stick. Die Leitung zum /WP-Pin wurde unterbrochen und der /WP-Pin am Speicherchip wurde mit einem 10K Widerstand gegen GND angeschlossen.
Sehr oft liegen /WP-Pin und GND-Pin nebeneinander. SMD-Widerstände in den Bauformen 0603 oder 0805 sind daher besonders gut geeignet, um als Pull-Down Widerstand diese beiden Kontakte miteinander zu verbinden [s. u. Abb. 6].
Ein gesetzter Jumper stellt entweder die Verbindung zum Kontroller auf der Hauptplatine wieder her oder eine permanente Verbindung zu einem HIGH-Pegel/Vcc. Erst dann ist eine Umprogrammierung des Speicherbausteins möglich. Ohne Jumper wird der /WP-Pin permanent gegen GND über den Pulldown-Widerstand gezogen und aktiviert so die Schreibschutzfunktion für Speicher und vorhandene Statusregister.
Abb. 2: BIOS-FLASH mit Adapter auf dem Mainboard
Abb. 3: Bei SOIC-Gehäusen muss der /WP-Pin vorsichtig angehoben werden
Abb. 4: SIOC8 mit SMD-Widerstand am angehobenen /WP-Pin
An einem SOIC-Gehäuse muss der /WP-Pin vorsichtig mit einem SMD-Lötkolben etwas angehoben werden. Nicht zu viel biegen oder zu lange erwärmen, sonst bricht der Pin am Baustein ab. Ein Pulldown-Widerstand wird zwischen dem angehobenen /WP-Pin und gegen GND gelötet. Dünne Kupferlackdrähte verbinden dann den Jumper mit dem angehobenen /WP-Pin und dem Lötpad unterhalb vom /WP-Pin. Es empfiehlt sich, alle Arbeiten mit einer Lupe auszuführen und zu kontrollieren.
Für Bausteine im SO8/SOIC8 Gehäuse können auch Sockel wie der SOK-SPI-8W nachträglich eingebaut werden. Das Nachrüsten mit Jumper und SMD-Widerstand erfordert viel Geschick, Löterfahrung und passendes Werkzeug.
Die freie Software FLASHROM bietet die Möglichkeit, dass FLASH-Bausteine auf der Platine programmiert werden können. Es ist allerdings nicht sichergestellt, ob die Programmierung der Statusregister-Bits für den erforderlichen Baustein auch von FLASHROM unterstützt wird.
Steht keine Programmiersoftware zur Verfügung, welche die Statusregister vom FLASH-Speicher im eingebauten Zustand programmieren kann, dann hilft nur die Programmierung über einen externen Programmer. Ist allerdings die Programmierung mit Programmierclip nicht möglich (BGA u. TSOP) oder ist der Baustein nicht gesockelt, dann muss der Baustein sogar ganz ausgebaut werden.
Einen Umbau von Mainboards mit einem BIOS-FLASH im BGA- Gehäuse empfehle ich nicht. Besser ist es dann ein Mainboard mit BIOS im SIOC8 oder sogar im DIP-Gehäuse zu kaufen.
Hinweise:
Bei eingebauten Baustein und aktiven Mainboard könnte ein Auslesen des Images oder sogar das Programmieren mit Hilfe eines aufgesetzten Programmierclips zu Pegelkonflikten an den Verbindungsleitungen zwischen Programmiergerät und Mainboard führen. Ein defektes Mainboard oder Programmiergerät könnten die Folge sein. Die Firmware vom BIOS ist also immer mit inaktiven Mainboard zu programmieren, wenn ein Programmier- bzw. Test-Clip verwendet wird.
Demovideo: Firmware mit Testclip programmieren
Auch bei abgeschalteten Mainboard können die I/O-Schutzdioden (Pegelbegrenzung) des FLASH-Steuerbausteins eine erfolgreiche Programmierung verhindern. Das BIOS-FLASH muss dann ebenfalls ausgebaut werden.
Sicherheitshinweise:
Netzstecker ziehen und Power-ON drücken, um das Netzteil zu entladen (Warten bis alle LED's erloschen sind. - Das ist ein guter Hinweis auf eine vollständige Entladung des Mainboards). Ein ausgebautes Mainboard erleichtert erheblich die Nachrüstung des Hardwareschreibschutzes. Ein schlechter ESD-Schutz und mangelhafte Löterfahrung führen schnell zu einer zerstörten Hauptplatine und einem defekten BIOS-Speicher.
Und ganz wichtig: Wer seine Elektronik schrottet, der ist selber daran schuld.
1.3 No BadBIOS - TEST
Mit gezogenem Jumper wurde der /WP-Anschluss logisch-0 aktiv. Allerdings konnte ich immer noch ein BIOS programmieren. Im BIOS-Chip musste daher noch das Statusregister programmiert werden. Alle Bits für den Block-Protect- und das Enable-Bit für den /WP-Pin waren laut Datenblatt noch zu setzen. Mit einem Programmiergerät (z. B. Galep5 der Fa. Conitec Datensysteme GmbH) wurde die erforderliche Registerkonfiguration im ausgebauten Baustein eingestellt. Die Webseiten von FLASHROM bieten auch eine Übersicht von USB-Programmern, die ein BIOS beschreiben können.
Der Baustein wurde wieder im Adapter auf die Hauptplatine gesteckt. Das Mainboard und Betriebssystem startete mit gezogenen Jumper (/WP ist LOW ->Schreibschutz ist aktiv). Daraufhin habe ich versucht, ein BIOS einzuspielen. Ohne Erfolg. Die Programmiersoftware meldete einen Löschfehler.
So soll es sein.
Abb. 5: Diese Meldung sieht man nun gerne.
Erst mit gestecktem Jumper war das BIOS wieder programmierbar. Allerdings löschte die Updatesoftware des Herstellers mit ihrer Neuprogrammierung auch die Statusbits für die Aktivierung des /WP-Pins bzw. die Block-Protection Bits.
Das Statusregister vom BIOS-Speicher muss mit dieser Software immer neu programmiert werden.
→Baustein wieder ausbauen …
(Randbemerkung: Das BIOS-Update (512 KByte) hatte nur ca. 15 Sekunden benötigt. Eine Passwort- oder PIN-Abfrage wurde von der Updatesoftware nicht angefordert.
→Ein im Hintergrund gestartetes BIOS-Update und erst recht kleinere Patches, können unbemerkt ausgeführt werden!)
1.4 BIOS-Hardwareschreibschutz – Quo Vadis?
Eine eindeutige Ursache für das Verschwinden der Schreibschutz-Jumper am BIOS-FLASH konnte ich bisher nicht finden.
Natürlich ist es sehr bequem, ein BIOS-Update mal schnell nur mit Software auszuführen. Ein PC-Gehäuse muss nicht geöffnet werden und es ist auch nicht der entsprechende Jumper auf dem Mainboard zu suchen. Es gäbe allerdings genug technische Möglichkeiten (Bspw. Schalter in der Rückblende oder Stiftkontakt um Gehäuse) diese umständliche Prozedur zu vereinfachen.
Ist es der übliche Trend zu Bananen-Produkt, also „Reift beim Kunden“ und muss deshalb permanent eine Möglichkeit für ein Update vorhanden sein? Hat sich UEFI hier möglicherweise einen Bärendienst geleistet? Denn eine Erhöhung der Komplexität macht ein Produkt nicht zuverlässiger/sicherer und erfordert mehr Updates und Korrekturen.
Eine technische Überforderung der fähigen Anwender sehe ich nicht, denn es gibt in den PC-Märkten viele Hardwarekomponenten zum Einbau in einen PC zu kaufen. Diese Komponenten würden aus den Märkten aufgrund von Beratungsbedarf, Rückläufe, Gewährleistung etc. verschwinden, wenn das die Anwender nicht leisten könnten. Es zeigt eher, dass technisch viel mehr von den Anwendern gefordert werden kann, als nur einen Jumper umzusetzen.
Ich sehe auch kein Kostenargument, denn ein notwendiger Widerstand und Jumper kosten nur wenige Cents. Es gibt viele Komponenten eines Computers, die wesentlich kostenintensiver und überflüssig sind. (Bspw. Beipack eines Kaltgerätekabel ca. 3.-€, Urheberrechtsabgabe je PC ca. 13.-€,...)
Warum wurde dann nicht auch der Jumper für das BIOS-Reset ebenfalls mit eingespart? Der Parameter-Reset vom CMOS-RAM muss noch seltener als ein BIOS-Update ausgeführt werden. Ein Sicherheitsmechanismus über Software- und Hardwarebits der Steuerbausteine, wie er für den /WP-Pin des FLASH-Bausteins vorgesehen wurde, das wäre doch auch möglich?
Ein Jumper kann ja offen bleiben, wenn kontinuierliche Updates erforderlich oder eine Administration in der Anwendung dieser Technik überfordert ist. Eine Option für bessere Sicherheit, ist noch lange kein Zwang diese zu nutzen.
Ein fehlender Jumper kann schlicht und einfach nur Unüberlegtheit oder eine Wissenslücke sein. Die Entwickler von Mainboards sind sich dieses Sicherheitspotentials vielleicht einfach nicht bewusst. Brauchen wir einen Jumper wirklich? Wir haben doch andere Mechanismen (UEFI, Secure-Boot, TPM). Die sollten doch auch ausreichen. Also kann der Jumper entfallen. Es ist ja ohnehin praktischer immer ein Update machen zu können (oberflächlich gesehen) und variable Konfigurationsdaten (Zertifikatsspeicher) können dann dort auch abgelegt werden.
Ein Hardware-Designer kennt sich nicht unbedingt in der (nicht) Zuverlässigkeit von Zertifizierungen etc. aus. Und für einen SW-Entwickler ist detailliertes Wissen über Hardware oft ein notwendiges Übel. Es treffen sich unterschiedliche Design-Erfahrungen. Und solange keine Vorgaben gemacht werden, wird schlicht und einfach nach dem eigenen Erfahrungshorizont und Wissen entschieden.
Sind den Kunden die Vorteile eines Hardwareschreibschutzes möglicherweise nicht bekannt? Gerade mit dem Blick auf Lojax, der bestimmt nicht das erste und letzte BIOS-Rootkit sein wird, sollten sie dieses Feature wieder einfordern.
1.5 Aktueller Zustand
Die Software- und Hardware-Hersteller setzen auf eine Blockade (Signatur) in der Ausführung eines manipulierten BIOS/UEFI-Inhalts, bzw. über Signaturmechanismen darf der Speicherinhalt im FLASH nur noch von vertrauenswürdigen Quellen verändert werden (Geheimdienste?).
Wie wird ein manipuliertes BIOS erkannt? Virenscanner haben, wie in „BIOS-Trojaner aufzuspüren, ist fast aussichtslos“ erklärt wurde, keine Möglichkeit eine Manipulation effektiv zu erkennen. Gerade weil die Software im BIOS/UEFI-FLASH zuerst gestartet wird und daher höchste Systemrechte hat, bieten sich hier Tarnmechanismen (Umleitung auf den korrekten Code beim Lesen) wie bei den Bootsektorviren an, wenn vom Betriebssystem aus auf die Speicherbereiche des Trojaners zugegriffen wird. Es bleibt streng genommen nur das Auslesen über einen Programmierclip (evtl. JTAG) direkt am Speicherbaustein übrig oder der Baustein muss ganz ausgebaut werden, um ihn dann mit einem Programmiergerät auszulesen. Ein Vergleich mit einem zuvor gesicherten und als sicher angenommen Inhalt könnte auf Manipulation hinweisen. Aber Achtung, bei einigen BIOS/UEFI-FLASH werden Teile vom Speicherbaustein zu jedem Neustart umprogrammiert bzw. sie werden als variable Speicher für Betriebssystemparameter oder als Zertifikatsspeicher verwendet.
Liegt der Speicherinhalt vom FLASH-Baustein als Datei gesichert vor, dann bietet sich ein Upload nach VirusTotal für eine genauere Analyse an, wobei auch hier wieder das Ergebnis als nicht Zuverlässig betrachtet werden muss.
Das neue Mini-Betriebssystem im UEFI-FLASH ist auch für Ransomware geeignet, denn UEFI-Secure-Boot verhindert nicht die Installation von Malware im BIOS-FLASH oder die Modifikation des Bootloaders, sondern stellt dessen Vertrauenswürdigkeit von Software erst später während des Bootvorgangs sicher.
Aufgrund der Standardisierung sind einheitlich definierte Softwareschnittstellen/Treiber u. a. zur Kontrolle von Bildschirmausgabe, Netzwerkhardware und Datenträger im UEFI implementiert. Der Entwicklungs-aufwand von Trojanern im BIOS/UEFI-FLASH wird dank UEFI stark reduziert. Das eine BIOS/UEFI-Ransomware möglich ist, wurde in einem Proof-of-Concept bereits gezeigt. Ein mögliches Worst-Case-Scenario für BIOS/UEFI-Ransomware habe ich in meinem Blog vom 21. Februar 2017 beschrieben (s. a. Bärendienst).
Weiterhin bietet sich ein BIOS-FLASH für Angriffe an, die eine wirksame Sabotage am Computer zum Ziel haben. Wurde ein BIOS-FLASH gelöscht oder mit fehlerhafter Software beschrieben, dann wird ein Mainboard zum „Brick“. Der Computer kann nicht mehr starten. Selbst Live-Systeme helfen dann nicht mehr, da weder Auswahl noch Ausführung eines Bootmediums ermöglicht werden. Zur Reparatur muss der FLASH-Speicher dann entweder ausgebaut oder an einen Programmierclip angeschlossen werden, um ihn neu zu programmieren. Ein vergleichbarer Angriff wird bei „Brickerbot: Hacker zerstören das Internet of Insecure Things“ ausgeführt. Dort wird der Programmspeicherbereich von aus dem Internet erreichbaren IoT-Geräten mit Zufallsdaten überschrieben, um sie außer Betrieb zu setzen. Eine signierte Software ist in diesem Fall erst gar nicht notwendig und Secure-Boot ist wirkungslos.
Signaturmechanismen beruhen auf Software und sind daher nie zu 100% Fehlerfrei implementiert. (s. 'Hintertür' in Secure Boot: Wichtigster Windows-Schutz ausgehebelt). Außerdem wer garantiert, dass Signaturschlüssel nicht verloren gehen oder sogar an staatliche Stellen weitergegeben werden (müssen).
Folgende Konstruktion, die Staatstrojaner im UEFI-FLASH für mich plausibel macht, sieht folgendermaßen aus:
Ich hatte mich immer gefragt, warum Vertreter des Staates oder des US-Militärs sich so sicher sind, dass sie jeden Computer übernehmen und sogar unbrauchbar machen können. Ein Staatstrojaner für UEFI/BIOS bringt dieses Potential mit. Eine zusätzliche Hilfe werden hier wohl bekannte (abgerungene) Zertifikasschlüssel der Hersteller sein und die UEFI-Standardisierung hält den Entwicklungsaufwand in Grenzen. Mit dem passenden Signaturschlüssel kann ein Trojaner ohne Probleme in ein UEFI-FLASH programmiert und dann sogar mit Secure-Boot ausgeführt werden. Dank richtiger Signatur wird die Software auch vom Updateprogramm im Betriebssystem und vermutlich auch von Virenscannern akzeptiert.
Das mini UEFI-Betriebssystem bringt alle Funktionen mit, um im Hintergrund und unbemerkt vom Betriebssystem, mit dem Internet kommunizieren zu können (dito altes BIOS mit PXE ..). Falls erforderlich, können noch notwendige Module heimlich nachladen werden (Prozessüberwachung, Bildschirm- und Keylogger ...).
Eine UEFI-Firmware hat die höchsten Rechte und arbeitet unter jedem Betriebssystem. Eine Schadsoftware, die im UEFI-FLASH implementiert werden konnte, kann mit jedem Betriebssystem zurechtkommen. Mit Linux wäre... funktioniert diese daher auch.
Um Spuren zu verwischen, könnte ein BIOS-Rootkit sich selbst durch erneute Überprogrammierung mit der Originalsoftware wieder aus dem FLASH entfernen. Es wäre nur schwer aufzuspüren (s. o. Auslesen über Programmierclip oder Ausbau des FLASH-Speichers).
1.6 Lojax Gegenmaßnahmen - Was hilft?
Die Empfehlung, dass nur Secure-Boot gegen Lojax hilft, ist für mich Augenwischerei. Secure-Boot hilft hier sozusagen nur passiv aber aktiv gesehen viel zu spät. Die eigentliche Infektion mit dem Rootkit wird nicht verhindert, selbst wenn Secure-Boot eingeschaltet wäre. Secure-Boot blockiert dann nur die weitere Ausführung von unsignierter Schadsoftware/unsignierten Bootloader die Lojax bzw. irgendein Rootkit dann noch ausführen möchte. Signierte Schadsoftware wird natürlich immer ausgeführt (s. o. "Window-Schutz ausgehebelt"). Im schlimmsten Fall testet ein BIOS-Rootkit nicht auf Secure-Boot (BIOS-Ransomware?) oder Lojax macht einen Fehler. Das Mainboard kann so zum Brick werden, da alle weiteren Bootprozesse mit Secure-Boot blockiert werden. Wird Secure-Boot nachträglich aktiviert, geht vermutlich auch nichts mehr.
Es wird sogar empfohlen das Mainboard/PC zu entsorgen, falls ein Angriff erfolgreich war oder auf neue Mainboards mit fehlerfreien Chipsatz (s. o. "Race-Condition" der BIOS_CNTL.BIOSWE and BIOS_CNTL.BLE) umzurüsten. Nur mal so rein rhetorisch gefragt: Was kostet nochmal so ein WP-Jumper?
Mit nur einem Schreibschutz-Jumper am BIOS/UEFI-FLASH als Vorsorge, braucht es weder ein aktiviertes Secure-Boot, noch ein Erkennen von Lojax oder eine Schutzsoftware und erst recht kein Beheben. Dieser Hinweis wird in vielen Berichten zu Lojax und im besonderen im ESET-Whitepaper (s. Kap 6 Vorbeugung und Gegenmaßnahmen) ganz vergessen.
1.7 Immer beschreibbares FLASH?
Ich ertappe mich bei meinen Überlegungen immer wieder, Hardware als unveränderlich hinzunehmen. Mit diesem WP-Umbau am BIOS möchte ich zeigen, dass sogar bei bereits bestehenden Systemen eine HW-Anpassung möglich ist. Beispielsweise, sollte der aktuelle BIOS-Speicherbaustein kein WP-Pin bereitstellen, wäre es sogar denkbar einen anderen Baustein mit der gewünschten Hardware-WP nachzurüsten.
FLASH-Bausteine wie bspw. der NV25M01 (s. S. 5) können so konfiguriert werden, dass bei aktiven WP-Pin bestimmte Bereiche immer noch beschreibbar bleiben. Die Speicherblöcke mit dem BIOS/UEFI können als HW-write protected eingestellt werden.
Eine HW-Write-Protection am UEFI-FLASH ist daher auch mit Windows und mit nur einem FLASH-Baustein möglich. Die Notwendigkeit eines generell beschreibbaren FLASH-Bausteins ist so gesehen nur ein Scheinargument, um den Jumper wegzudiskutieren. Es muss für das Hardwaredesign also nur der passende Speicherbaustein ausgewählt werden. Ein 2. FLASH, das immer beschreibbar und nur als Speicher für variablen Daten verwendet wird, halte ich für die technisch sauberste Lösung. (Bei Mainboards mit Dual-BIOS ist der Kostennachteil des 2. Bausteins anscheinend ebenfalls nicht so ausschlaggebend, ansonsten würde auf diesen weiteren Baustein bzw. auf das Konzept eines Dual-BIOS ganz verzichtet werden.)
1.8 Hardwareschreibschutz – Eine effiziente Ergänzung
Der wesentliche Vorteil eines über Hardware schreibgeschützten Speichers liegt in der Unabhängigkeit vom Betriebssystem und dessen Sicherheitssoftware. Dieser Schreibschutz wirkt direkt an der Hardware eines Computersystems (KISS-Prinzip) und ich kann ihn unkompliziert kontrollieren (Position Jumper/Schalter). Selbst mit schlechten Administrator-Passwörtern und fehlerhafter Sicherheitssoftware sind heimliche Manipulationen aus der Ferne am BIOS-FLASH nicht mehr möglich.
Es ist ein großer Sicherheitsgewinn, wenn Angreifer erst persönlich an der Hardware aktiv werden müssen oder erst Überredungskünste anwenden müssen, so dass der Anwender selbst den Schreibschutz wieder aufhebt.
Spätestens ab diesem Punkt helfen Firewall und Virenscanner natürlich auch nicht mehr. Ein massentaugliches und einfach mal so Fernsteuern von Computern wird aber mit HW-Schreibschutz verhindert.
Bedauerlicherweise wird der Hinweis, dass falls ein Angriff mit HW-Schreibschutz verhindert werden kann, in den Medien viel zu selten gegeben.
Berichte wie „HackingTeam Uses UEFI BIOS Rootkit“ über Schadsoftware erwähnen erfreulicherweise, dass mit BIOS-HW-Schreibschutz diese Angriffe nicht durchführbar sind (Zitat:„.. Admins managing servers can also opt to buy a server with physical BIOS write-protection ...“). Ein Gegenbeispiel ist c't Heise auch mit „HackingTeam verwendet UEFI-Rootkit“ Zitat: „Der beste Schutz gegen derartige Manipulationen ist die Aktivierung von UEFI Secure Boot und dem Passwort-Schutz fürs BIOS.“… ) - Das war's dazu. Der Leser soll anscheinend nicht mit weiteren Möglichkeiten zur Absicherung überfordert werden und nur „UEFI-Secure-Boot“, also reine SW-Lösungen als Option sehen, die sich allerdings immer wieder als nicht wirkungsvoll erweisen.
Was kann ein versierter Anwender bei einem Zero-Day Exploit noch tun, wenn kein Hardwareschreibschutz möglich ist und der Sicherheits-Patch auf sich warten lässt? Beispielsweise „Lenovo warnt vor ungepatchter BIOS-Lücke“. Denn ohne Hardwareschreibschutz verliert ein Anwender immer das Hase-Igel rennen.
Eine Sicherheitssoftware kann immer nur die bekannten Lücken und Angriffsmöglichkeiten berücksichtigen. Sie erfordert Sachwissen und Wartungsaufwand, wie beispielsweise die Konfiguration einer Firewall, ausführen von Updates oder die Bewertung von Virusmeldungen (false-positive?).
Ein BIOS-FLASH ist mit einem Hardware-Schreibschutz nun als ROM zu betrachten und zur Laufzeit nicht mehr manipulierbar. Wartungsaufwand und Sachwissen für die Anwendung eines Hardware-Schreibschutzes (ein Schalter oder Stiftkontakt am Gehäuse) sind hier nur minimal zusätzlich erforderlich. Je nach technischen Verständnis und Bereitschaft sind viele Varianten möglich, einen Hardwareschreibschutz zu implementieren und zu bedienen. Die Anwender bekommen eine weitere Möglichkeit ihre Systemsicherheit je nach Anforderung und Wissensstand zu verbessern. Für Tante Erna ist es möglicherweise besser, keinen einfach zu bedienenden Schalter am Gehäuse vorzufinden. Ein Jumper auf dem Mainboard würde in diesem Fall erhebliche Überredungskünste erfordern, ein PC-Gehäuse zu öffnen etc.
Darauf aufbauend kann und muss immer noch die notwendige Sicherheitssoftware und Konfiguration (Firewall, Userrechte etc.) eingesetzt werden.Vertrauenswürdige Quellen und Lieferketten (Signatur- und Zertifizierungsmechanismen) von Software (nun incl. Kontrollerfirmware und BIOS-SW) bleiben wie bisher (m. a.) relevant. Besonders die Kombination aus HW- und SW-Mechanismen sehe ich als sehr effizient an. Gerade weil Signaturen missbraucht werden könnten, sollte das Auto-Update für die seltenen BIOS/UEFI-Patches immer deaktiviert sein. Hier muss sich ein Anwender leider tatsächlich über Herstellerhinweise und über ein erforderliches Update informiert halten. Eine Kontrolle der Checksumme/Hashwert mit eingeschlossen. Dieser Aufwand ist allerdings nur selten erforderlich.
Mit einem zusätzlichen HW-Schreibschutz an Systemsoftware, BIOS-FLASH und Kontrollerfirmware können Angriffe nur noch temporär, bis zum Abschalten des Computers im System-RAM aktiv bleiben und dem Anwender schaden.
Zu BIOS-Jumper wird auch vom BSI (Bundesamt für Sicherheit in der Informationstechnik), wie auch vom NIST (National Institute of Standards and Technology ) geraten. Jeweils in „M4.84 Nutzung der BIOS-Sicherheitsmechanismen“ unter IT-Grundschutz und den „BIOS Protection Guidelines“ (s. Kap. 3.1.2, S. 3-2 ). Mit diesen offiziellen Empfehlungen sollte für Großabnehmer von Hauptplatinen und besonders von öffentlichen Einrichtungen, diese zusätzliche Anforderung an Hardware einfach zu stellen sein.
Hardwareschreibschutz gehört für mich zur IT-Basissicherheit und daher sollten die Hersteller der Hardware in die Pflicht genommen werden eine HW-Write-Protection immer als Option vorzusehen. Sie wäre ein gutes Verkaufsargument und sollte auch in die Bewertung zur Systemsicherheit und in Testberichten über Mainboards aufgenommen werden. Besonders Großabnehmer hätten es leicht, dieses Feature wieder einzufordern.
Ohne Jumper haben BIOS-Ransomware, PC-Sabotage (Brick) etc. mit jeder Internetverbindung die Möglichkeit, dem Anwender zu schaden. Das sehe ich als sehr starkes Argument für einen Hardwareschreibschutz und er sollte daher immer so weit vorhanden angewendet und eingefordert werden.
Wer seinen Rechner noch etwas besser gegen physische Eingriffe absichern möchte, der findet hier eine Diskussion. (Ein Einbetonieren des Computers, um auch Evil-Maid Angriffe zu erschweren, macht natürlich nur mit aktiven BIOS-Schreibschutz einen Sinn ;-)
Zusammenfassung:
- Das System ist geschützt vor einer BIOS-Ransomware (Ransomware liegt im BIOS), die sonst die alle erreichbaren Datenträger (auch Netzlaufwerke) immer verschlüsseln würde.
- Ein Bundes- Staatstrojaner /Rootkit kann dort nicht etabliert werden. Das BIOS-FLASH sehe ich hier als zentralen Angriffspunkt, da es für Virenscanner (Schlangenöl) ein blinder Fleck ist.
- Ein mutwilliges Bricken (s. a. IoT Angriff), Sabotage / ein (fehlgeleiteter) Computerangriff ist an dieser Stelle im Computer nun nicht mehr möglich.
- Es ist die Erste-Hilfe-Maßnahme gegen manipulative 0Day-Exploits am BIOS, bis ein SW-Update die erkannte Lücke schließen kann (wenn es das überhaupt gibt).
- Das System ist auch gegen (offiziell) noch unbekannte Fern-Angriffe auf das BIOS-FLASH wirkungsvoll abgesichert (Das leistet keine Software).
- Ein schreibgeschütztes BIOS-FLASH erhöht den Aufwand für einen Angreifer beträchtlich. Denn es wird eine physische Präsenz am Computer erforderlich.
Eine sehr ausführliche Argumentation ist unter Pro-Hardwareschreibschutz zu finden.
1.8 Ausblick/Kommentar
Neben dem Thema BadUSB sehe ich besonders BadBIOS (BIOS/UEFI mit Trojaner, BIOS-Rootkits), als Folge vernachlässigter Sicherheitsmechanismen (WP-Jumper), auf viele Anwender zukommen. Wenn über Staatstrojaner/Bundestrojaner berichtet wird und diese als hochspezialisierte Software bezeichnet werden, dann entspricht dies sehr gut der Beschreibung eines BIOS-Rootkits. Gerade Geheimnisträger und allzu kritischen Journalisten sollten sich gegen diese Angriffe schützen.
Das Thema Ransomware wurde mit einem Proof-of-Concept auf BIOS-Ransomware erweitert. Wie sind Krankenhäuser und andere wichtigen IT-Infrastrukturen auf diese Angriffe vorbereitet? Ein gutes Backup-System hilft dann auch nicht mehr weiter.
Mich würde interessieren, wie Sysadmins jetzt mit diesem Problem umgehen? BIOS-Ransomware im Krankenhaus oder 1000 Bricks einer Serverfarm erfordern dann sogar Lötkenntnisse und gute Argumente gegenüber der Geschäftsleitung, warum bisher kein Hardwareschreibschutz eingesetzt wurde.
Quellen:
- Bios-Trojaner aufzuspüren, ist "fast aussichtslos"
- Virustotal analysiert (UEFI-)BIOS-Code
BIOS Programmier-Software:
- FLASHROM - http://www.flashrom.org/Flashrom - Programmiertool für viele BIOS-Speicherbausteine
Kann auch zum Auslesen vom BIOS-FLASH verwendet werden.
- Firmware mit Testclip programmieren
Fehler in den BIOS- Steuerbausteinen:
- US-Cert warnt vor weiteren UEFI-BIOS-Lücken o. a. "race condition exists in Intel chipsets that rely solely on the BIOS_CNTL.BIOSWE and BIOS_CNTL.BLE
Freie BIOS Entwicklungen:
- Coreboot - http://www.coreboot.org/Welcome_to_coreboot - freies BIOS
- LibreBoot - https://libreboot.org/
BIOS/UEFI - Hacks / Ransomware:
- Programmier-Tipps für die BIOS-Backdoor
- BIOS/UEFI mit Ransomware infiziert
- Lojax "Lojax: Der Spion, der aus dem BIOS kam"
Bauteile:
EEPROM –Macronix.- http://www.macronix.com/CachePages/en-us-default.aspx
X25L4005M Pinbbelegung S. 5 und WP-Registersatz S. 8 : http://www.macronix.com/Lists/Datasheet/Attachments/1530/MX25L4005A,%203V,%204Mb,%20v2.2.pdf
NV25M01 - Baustein mit partiellem Hardwareschreibschutz
Sonst:
Spiegel.de Hardware-Hacker: Laptop zerlegt, Angriff abgewehrt (Mein Kommentar dazu: Stimmt, ein zerstörtes Mainboard bietet weder Angriffsmöglichkeiten noch Anreize.)
Abb. 6: SMD-Widerstand zwischen /WP-Pin und GND