2276711

CPU-Sicherheitsrisiko Management Engine von Intel: Wie können sich Nutzer schützen?

30.05.2017 | 16:00 Uhr |

Die Management Engine von Intel ist ein Sicherheitsrisiko und muss daher von Anwendern abschaltbar sein.

CPUs von Intel haben ein weiteres 'Intel Inside'

Seit 2008 enthalten die meisten Chipsets von Intel einen winzigen Homunkulus-Computer, genannt Management Engine (ME). Die ME ist ein weitgehend undokumentierter Master-Controller für Ihre CPU; er arbeitet mit der System-Firmware während des Bootvorgangs und hat direkten Zugriff auf den Systemspeicher, den Bildschirm, die Tastatureingaben und das Netz.

Der gesamte Code in der ME ist geheim, signiert und wird von Intel streng überwacht.

Vor kurzem verursachten Schwachstellen im Active-Management-Modul (AMT) einiger Management Engines in Computern mit Intel-CPUs eine katastrophale Schutzlosigkeit gegenüber entfernten und lokalen Attacken. Das AMT lässt sich zwar deaktivieren, aber es gibt derzeit keinen Weg, die Management Engine generell abzuschalten oder ihre Zugriffsrechte einzuschränken.
Intel muss da umgehend Abhilfe schaffen.

Dieser Beitrag beschreibt die Eigenschaften dieser Schwachstellen (Dank an Matthew Garrett für die gute Dokumentation ) und das Potenzial für ähnliche zukünftige Bugs. Die Electronic Frontier Foundation ( EFF ) glaubt, dass Intel ein Mindestmaß an Transparenz und Anwenderkontrolle über die Management Engines in unseren Computern bieten sollte, um eine Wiederholung dieses Cybersecurity-Disasters zu verhindern. Bis das geschieht, ist es wohl nicht empfehlenswert, Intel-CPUs in kritischen Infrastruktursystemen zu verwenden.

Was ist AMT? Wie ist es angreifbar?

Auf vielen Chips von Intel wird die Management Engine mit dem installierten AMT-Modul geliefert. Dadurch können Systemadministratoren die Computer von Organisationen und deren Beschäftigten fernbedienen und -warten.

Eine am 1. Mai 2017 bekannt gewordene Schwachstelle erlaubt es jedoch einem Angreifer, die Passwort-Authentifizierung für dieses Remote-Management-Modul zu umgehen. Das bedeutet, dass entfernte Angreifer in vielen Situationen die gleichen Fähigkeiten wie das IT-Team einer Organisation erwerben können, sofern das AMT aktiviert und verfügbar ist. [1]

Sobald die Angreifer Zugriff auf das AMT haben, können sie mit dem Bildschirm oder der Konsole interagieren als ob es der Anwender selber tun würde. Angreifer können auch beliebig Betriebssysteme starten oder neue installieren - und mit etwas Aufwand auch Passwörter für die Festplattenverschlüsselung stehlen. [2]

Nicht jeder Computer ist für diese Attacken anfällig. Damit eine Attacke glückt, muss das AMT sowohl aktiviert als auch verfügbar sein (normalerweise ist das AMT aktiviert, aber nicht verfügbar). Sobald das AMT bereitgestellt ist, hat es ein Passwortset, sucht dann nach Netzwerkpaketen und wird mit den entsprechenden Reaktionen das System steuern. [3]

Das AMT kann per Grundeinstellung durch den Hersteller eines Rechners bereitgestellt werden, sofern mit dem OEM-Setup eine Eigenschaft, genannt Remote Configuration, verwendet wird. Es lässt sich aber auch durch einen Anwender mit Administrator-Rechten oder interaktiv oder mit einem USB-Stick während des System-Boot-ups oder (per LMS-Anfälligkeit) durch nicht privilegierte Anwender auf Windows-Systemen mit dem LMS (Local Manageability Service) implementieren.

Macs haben MEs, werden aber ohne das AMT geliefert. Die Passwort-Sicherung ist für Computer mit bereitgestellter AMT sehr wichtig, aber durch die jetzige Anfälligkeit lässt sie sich umgehen.

[1] Eine zweite Auswirkung dieser Schwachstelle erlaubte lokal, Windows-Anwendern ohne Admin-Rechte das AMT bereitzustellen, sofern die Windows-Komponente Local Manageability Service (LMS) installiert ist. (Ob LMS installiert ist, ist typischerweise vom Hardwarehersteller abhängig. Beispiel: Lenovo könnte entscheiden, ob der LMS in einem Thinkpad automatisch installiert wird oder nicht.) Diese zweite Auswirkung erlaubt es Anwendern ohne Admin-Rechte oder aber kompromittierten Konten, die komplette Steuerung jener Computer zu übernehmen, indem das AMT mit von ihnen ausgewählten Einstellungen bereitgestellt wird.

[2] Ein AMT-Zugriff ist nicht mit dem Ablauf eines beliebigen ME-Codes vergleichbar. Daher können Angreifer nicht direkt auf den Systemspeicher zugreifen; sie müssen die Konsole oder VNC benutzen oder aber ein Betriebssystem-Abbild booten, um ihre Ziele zu erreichen.

[3] Sofern bereitgestellt, 'horcht' das AMT an den Ports 16992 und 16993. Oft ist das nur bei einer physikalischen Ethernet-Verbindung so, aber eine Bereitstellung kann auch AMT über WiFi freigeben (sobald das Betriebssystem läuft, erfordert AMT über WiFi die Unterstützung des Betriebssystems).

Wie können Anwender sich selber schützen?

Viele Organisationen müssen für ihren Schutz etwas unternehmen. Sie müssen sicherstellen, dass das AMT in ihrem Bios  deaktiviert und LMS nicht installiert ist - oder aber die Intel-Firmware aktualisieren.

Selbst wenn das AMT deaktiviert ist, bedeutet das nicht, dass ein Angriff nie möglich ist, denn ein Angreifer könnte das AMT nach einer Attacke auf seinem Weg aus dem System bereits abgeschaltet haben.

Es ist beunruhigend, dass das AMT nur eines der vielen Services/Module ist, die vorinstalliert mit den Management Engines geliefert werden. Unsere derzeit beste Empfehlung für das Beheben dieser Schwäche ist die Abschaltung des spezifischen AMT-Moduls, denn Intel bietet derzeit keine Möglichkeit, um generell die Funktionsleistung der ME zu mindern.

Aber auch Schwachstellen in jedem der anderen Module können für die Sicherheit genauso schlecht oder noch gravierender sein. Einige der anderen Module verfügen über einen hardware-basierenden Authentifizierungscode sowie aus Gründen der Diebstahlssicherung ein System für die Standortverfolgung und entferntes Löschen von Laptops.

Das mag für einige von uns hilfreich sein, aber es sollten die Besitzer der Hardware entscheiden, ob dieser Code auf ihren Computern installiert wird oder nicht. Aber wirklich beängstigend ist, dass es - wie berichtet - ein DRM-Modul gibt, das aktiv gegen die Interessen der Anwender arbeitet. Dieses Modul sollte grundsätzlich nie in der ME installiert werden.

Für Experten mit Computern ohne Verified Boot gibt es ein Github-Projekt, genannt ME Cleaner , mit dem man eine Management Engine stilllegen kann. Aber Vorsicht: Die Anwendung dieses Tools kann potenziell die Hardware unbrauchbar machen. Anwender  sollten vorsichtig sein, bevor sie versuchen, ihr System derart zu schützen. Eine reale Lösung bedarf auf jeden Fall der Unterstützung von Intel.

Was Intel braucht, um das Problem zu lösen

Anwender sollten frei entscheiden können, was auf ihrem System ablaufen soll und auch die Möglichkeit haben, Code zu entfernen, der Schwächen aufweisen könnte. Da die Management Engine nur Code-Module abarbeitet, die von Intel signiert sind, muss man eine Möglichkeit haben, die ME abzuschalten oder sie mit minimaler, prüffähiger Firmware zu aktualisieren (Reflash).

Obwohl Intel viel in die Jagd nach Sicherheitsbugs investiert, wird es unweigerlich Schwachstellen geben, die in einer besonderen Low-level-Komponente lauern - ohne Wahrnehmung durch das Betriebssystem oder durch eine zuverlässige Protokollierung, ein Albtraum für die Cybersicherheit.

Die Entscheidung, einen geheimen, nicht modifizierbaren Managementchip in jeden Computer zu setzen, war furchtbar. Und den Anwender diesen Risiken ohne Ausstiegsrecht auszusetzen, ist ein Akt extremer Verantwortungslosigkeit.

Für die sichere Anwendung von Computern durch die Nutzer wäre es von Vorteil, wenn Intel eine offizielle Unterstützung zur Eingrenzung der Angriffsmöglichkeiten bieten würde, damit die potenzielle Gefahr der ME limitiert wird.

Wir fordern hiermit Intel auf:

* Eindeutige Dokumentationen für die Softwaremodule zu liefern, die auf verschiedenen Management Engines vorinstalliert sind. Welche HECI-Befehle liefern eine komplette Liste von den installierten Modulen/Services? Welches sind die Interfaces zu diesen Services?

* Ein Verfahren für ihre Kunden zu liefern, mit dem ME-Code auf Schwachstellen überprüft werden kann. Das ist derzeit nicht möglich, weil der Code geheimgehalten wird.

* Ein Verfahren zu unterstützen, mit dem die ME abgeschaltet werden kann. Wenn das wirklich nicht möglich ist, sollten Anwender in der Lage sein, ein absolut minimales und allgemein überprüfbares ME-Firmware-Abbild zu laden (Flashing).

* Auf Systemen, wo die ME aus anderen Sicherheitsgründen für einige Anwender (wie Boot Guard) unverzichtbar ist, sollte eine zusätzliche Option in Form eines nahezu minimalen, allgemein überprüfbaren ME-Firmware-Abbilds angeboten werden, das nur diese Sicherheitsfunktionen ausführt.

Oder es sollte alternativ einen unterstützten Weg geben, Firmware-Abbilder zu erstellen und zu flashen, wobei der Anwender prüfen und bestimmen kann, welche Services/Module vorhanden sind, um die Sicherheitsrisiken durch diese Module zu managen.

So lange Intel diese Schritte nicht unternimmt, befürchten wir, dass die nicht dokumentierten Master Controller in den Intel-Chips auch weiterhin eine Quelle gravierender Schwachstellen in Computern, Servern sowie kritischen physikalischen Infrastrukturen der Cybersicherheit sind.

Intel sollte schnell handeln, um der Allgemeinheit eine überprüfbare Lösung für diese Gefahren zu liefern.

 

Korrektur vom 12. Mai 2017:

Intel kontaktierte uns mit zwei Korrekturen zu den Details dieses Berichtes.

(1) Management Engines sind physikalisch nicht auf der CPU- Die selber platziert, sondern sie befinden sich in anderen Bereichen der Intel-Chipsets

(2) Die LMS-basierende lokale Privileg-Eskalation war eine zweite Folge der ersten Code-Schwäche und eben nicht eine zweite Schwäche oder ein eigener Bug.

Wir haben unseren Bericht an einigen Stellen entsprechend geändert, aber wir glauben nicht, dass diese Verbesserungen unsere Schlüsse beeinflussen.

Dieser Beitrag wurde am 8. Mai 2017 auf https://www.eff.org veröffentlicht.

Übersetzt und bearbeitet von Henning Wriedt

0 Kommentare zu diesem Artikel
2276711