Black Hat: Demonstration eines EFI-Rootkits für Macs

[Apple User]

Das Unternehmen gab daraufhin das Funktionieren der Attacke zu, ein Fix selbiger erweise sich aber als schwer realisierbar aufgrund der Architektur von Thunderbolt.

Gefällt mir gut ! Das ist mal eine passende Antwort seitens Apple.

[JvW]

Ähm, verstehe ich das jetzt richtig:

Zugang zu dem Apple Rechner erhält das Rootkit über einen manipulierten Thunderbolt-Ethernetadapter, auf dem der Hacker einen Gerätetreiber ablegte.

klingt für mich so, als müsste der "Hacker" so einen Adapter bei mir austauschen - also physikalischen Zugriff haben. Oder mir sonstwie einen manipulierten Adapter unterjubeln (ey, bay).

Oder wie?

[Snoopy181]

So habe ich es auch verstanden.

[tjp]

Ähm, verstehe ich das jetzt richtig:
klingt für mich so, als müsste der "Hacker" so einen Adapter bei mir austauschen - also physikalischen Zugriff haben.

Im Prinzip ist das richtig, aber es ist auch denkbar, daß man remote Zugriff auf ein TB Device bekommt und dort Schadcode erstmal deponiert, damit dieser beim Reboot aktiviert wird.

So wie Apple TB momentan verwendet, hat man im Betrieb über den TB-Port eines Macs direkten Zugriff auf den kompletten Arbeitsspeicher. Das ließe sich mit IOMMU (Intel nennt das VT-d) verhindern, aber dazu müßte es konsequent angewendet werden.

[ProSpeed]

Man zeigt sich enttäuscht über Apples Vortrag und zeigt Einfallstore, die seit über einem Jahr bekannt sind. Das wird ja immer besser.

Ja, man braucht physischen Zugriff. Der Worst-Case: Ein Konferenz-Beamer, der über den Displayport (=Thunderbolt) angeschlossen wird.
Das Problem gab es aber auch so ähnlich schon mit Firewire. Und mit externem PCI wird es ähnlich sein. Das ist der Preis, zu dem man die Vorteile einer direkten PCI Anbindung gegenüber USB z.B. erkauft.
Genauso gut könnte man manipulierte Grafikkarten verkaufen etc.
Bei einem Adapter ist nur die Wahrscheinlichkeit höher, dass den "mal eben" jemand anschließt.

[tjp]

Das Problem gab es aber auch so ähnlich schon mit Firewire. Und mit externem PCI wird es ähnlich sein. Das ist der Preis, zu dem man die Vorteile einer direkten PCI Anbindung gegenüber USB z.B. erkauft.

Das nicht ganz korrekt. Der skizzierte Angriff nutzt vorallem eine Schwäche im EFI aus. Wenn Apple das EFI mit mehr Konfigurationsmöglichkeiten versehen würde, könnte man z.B. unterwegs das Laden von Treiber im EFI über TB komplett deaktivieren.

Den Zugriff verhindern während des laufenden Betriebs kann man mittels IOMMU (VT-d). Dann erhalten die TB Devices nur noch Zugriff auf spezielle vom OS freigegeben Datenbereiche im Speicher. Die IO-Buffer die auch dafür vorgesehen sind. Der Rest des Arbeitsspeicher wäre dann blockiert.

[ProSpeed]

Das nicht ganz korrekt. Der skizzierte Angriff nutzt vorallem eine Schwäche im EFI aus. Wenn Apple das EFI mit mehr Konfigurationsmöglichkeiten versehen würde, könnte man z.B. unterwegs das Laden von Treiber im EFI über TB komplett deaktivieren.

Da hast du selbstverständlich recht, aber das würde dermaßen der Appleschen Philosophie widersprechen, dass ich es hier nicht als realistische Lösung sehe.
Auch bei anderen Geräten, die über eine sonstwie geartete PCI Schnittstelle laufen, wird man dieses Problem fast Zwangsläufig haben. Denn einfach die Treiber zu laden via TB etc. ist an sich super komfortabel.

IOMMU (oder VT-d, je nachdem in welchem Hause man gerade ist ) ist sicherlich ein Ansatz. Ich bin gerade nicht im klaren, wie stark die Performance Einbußen dadurch wären. Ob und mit welchem Aufwand man das System umgehen kann bliebe dann noch zu klären. An der Stelle bin ich dann aber aktuell raus.
Ein großes Problem ist aber das Geld. Und so etwas zu implementieren kostet natürlich Geld. Und da die Firma ihr Geld liebt...
Der Milliardenberg folgt dem Grundsatz, dass Haben von behalten kommt

[Kaizer]

Was ist der Unterschied zwischen Windows und Mac? Bei Windows weiß man wenigstens, dass man angreifbar ist!

[/gebashe aus]

[kommerzdoedel]

Über Fire-Wire ist es auch möglich, auf den Arbeitsspeicher zuzugreifen und das Passwort auszulesen.

[tjp]

Da hast du selbstverständlich recht, aber das würde dermaßen der Appleschen Philosophie widersprechen, dass ich es hier nicht als realistische Lösung sehe.

Eine schlechtere Alternative ist ein kryptographisches Signatursystem für die Treiber, allerdings wurde solche Systeme immer wieder aufgebrochen, und alle Signaturen tauscht man bei Hardware nicht so schnell aus.

Auch bei anderen Geräten, die über eine sonstwie geartete PCI Schnittstelle laufen, wird man dieses Problem fast Zwangsläufig haben. Denn einfach die Treiber zu laden via TB etc. ist an sich super komfortabel.

Es betrifft nur ExpressCard u.ä. Lösungen, da interne Karte nicht so ohne weiteres eingebaut werden. Wenn man ein solchen physikalischen Zugriff auf das Gerät hat, kann man ohnehin alles machen.

Die Gefahr bei TB und ExpressCard geht von der Einfachheit der Attacke aus. TB Device einstecken, Rechner hochfahren (.d.h nur das EFI muß laufen es muß kein OS gebootet werden), Rootkit installiert sich auf dem System (Flash Speicher der GPU o.ä.), Rechner runterfahren und TB Device abziehen. Danach ist ein Rootkit auf dem System, daß sogar das Flashen des EFI Roms des Mainboards überlebt. Eine Neuinstallation des OS ist natürlich vollkommen sinnfrei, weil das Rootkit sich dadurch nicht entfernen läßt.

Ein großes Problem ist aber das Geld. Und so etwas zu implementieren kostet natürlich Geld. Und da die Firma ihr Geld liebt...
Der Milliardenberg folgt dem Grundsatz, dass Haben von behalten kommt

VT-d kommt erst ins Spiel, wenn das OS bereits gebootet ist. Dadurch lassen sich Angriffe des laufenden System unterbinden. Dazu ist VT-d fähige Hardware notwendig. Die Desktopchipsätze von Intel sind prinzipiell dazu fähig, offiziell unterstützen es nur die Qxx und die C2xx Chipsätze. Beide werden von Apple nicht genutzt. Wobei aber Intel auf Kundenwunsch es auch bei anderen Chipsätzes freischaltet. Ferner wird eine VT-d fähige CPU benötigt, das dürfte auf alle von Apple verbauten CPUs zutreffen. Das Hauptproblem ist die Firmware und das OS, diese müssen natürlich VT-d supporten, sonst wird das nichts.

Bei den Mobile Chipsätzen und CPUs verhält es sich analog zu den Desktop Geräten. Bisher wird VT-d bei Apple nur auf den MacPros (und früher den Xserves) unterstützt.

[ProSpeed]

Die Gefahr bei TB und ExpressCard geht von der Einfachheit der Attacke aus.

Das erwähnte ich ja bereits in meinem ersten Beitrag. Man könnte genauso gut manipulierte Grakas in Umlauf bringen, aber die steckt man nicht mal eben an. Dazu kommt, dass TB auch die Video-Schnittstelle ist, also z.B. an Beamern Verwendung findet. Hier wiederum kommen häufig geschäftlich genutzte Rechner zum Einsatz und da wird die Sache spannend.

VT-d kommt erst ins Spiel, wenn das OS bereits gebootet ist.

Das kommt erschwerend hinzu, aber würde den Einschnitt, dass nicht direkt beim Start Treiber geladen werden ein Stück weit ausbügeln. Die Infrastruktur ist nicht so schwierig umzusetzen. Nachträglich hapert es meist an den Chipsätzen. Wenn Apple wollte, würde Intel kaum sagen: Nö kriegt ihr nicht.

Eine Neuinstallation des OS ist natürlich vollkommen sinnfrei

Das hast du noch sehr nett ausgedrückt. Der Rechner ist wirtschaftlich schrottreif. Denn alle im Rechner verbauten Speicher zurückzusetzen ist relativ viel Arbeitsaufwand und damit ein K.O. Kriterium bei hiesigen Lohnkosten. (Es sei denn, man sieht den Schritt bereits vor, aber ich denke nicht, dass es dafür einen simplen Zugriff aufs System gibt / die Werkseinstellungen im Speicher zur Verfügung stehen)

[iStationär]

Memo an mich selbst: niemals irgendwo anstecken :P

[echo.park]

War ja klar das sowas irgendwann kommt.

[MBSoft]

Leute, jede von außen bestehende Möglichkeit, etwas "vernünftiges" mit einem Rechner anzustellen beinhaltet immer auch die (wenigstens theoretische) Möglichkeit, das Gegenteil zu tun.
Mich ärgert etwas ganz anderes: Als PC-Nutzer der ersten Stunde erinnere ich mich noch sehr gut, was auf den 4Mhz-Systemen der Anfangszeit durch smarte Programmierung alles möglich war. Ich will da gar nicht erst auf die Hardwareaustattung der Apollo-Raketen abzielen....
Heute beschäftigen die Firmen eine Unzahl Mitarbeiter, um superschnelle Geräte noch ein klein wenig schneller zu machen. Das ist prima, leider kümmert man sich in erheblich geringerem Umfang um die Sicherheit. Eine geschickte Kombination aus Hard- und Software könnte und müßte in Zeiten der Quasi-Vernetzung fast aller Rechner über das WWW endlich konsequent angegangen werden. Die ständigen Erfolge beim Auffinden von Sicherheitsproblemen sollten doch wohl bei den PC-Herstellern selbst statt finden und dann auch gleich in Angriff genommen werden. Für die Masse völlig irrelevante Gefahren -wie die hier beschriebene- sind oft zwar reine Theoriepanik, aber ein monatelang verschlepptes Update einer als unsicher erkannten Betriebssystemfunktion etc. darf nicht sein. Vielleicht wachen die Hersteller aber auch hier wieder erst dann auf, wenn der Gesetzgeber erstmals irgendwo eine drakonische Strafe verhängt, wenn er nachweisen kann, dass nicht angemessen reagiert wurde. DAS wäre mal ein sinnvoller Einsatz der Ressource "Justiz" im Zusammenhang mit elektronischen Geräten....nicht die Entscheidungsfindung, wer die cooleren Tablets baut

[iStationär]

Wenn wir jetzt schon auf unsere Politik hoffen müssen ist aber Holland in Not :P

[SilentCry]

Gelöscht - ich muss das nochmal lesen.

[SilentCry]

Über Fire-Wire ist es auch möglich, auf den Arbeitsspeicher zuzugreifen und das Passwort auszulesen.

Nicht wenn man das EFI-Passwort gesetzt hat. Schreibt auch der Hacker:
(http://ho.ax/De_Mysteriis_Dom_Jobsiv..._Hat_Paper.pdf)

Apple has implemented password-protection on the BDS (Boot Device Selection) phase of the EFI firmware in order to prevent "evil maid" attacks where an attacker has gained physical access to a system and can interfere with the boot process. This mechanism prevents attackers from executing malicious EFI drivers and applications from devices connected to the USB, FireWire and network interfaces ...

Nur gegen diese EFI-Katastrophe hilft das nichts.

[Warp-x]

Zum Glück habe ich noch einen alten Mac - ohne TB

[SilentCry]

Ja. Ich auch. Noch. Und das wird dank dieser Meldung auch so bleiben.
Irgendwann jedoch wird das MBP zu alt sein - was dann? Wird Apple bis dahin das EFI-PWD so verwenden, dass es dagegen schützt?

Wenn Apple sich da genau so verhält wie MS bei der Firewire-Lücke:

Microsoft sieht im Firewire-DMA kein Sicherheitsproblem, da es Teil der IEEE-1394-Spezifikation ist. Laut Boileau denke man deshalb in Redmond auch nicht darüber nach, dies zu verhindern.

Dann ist der Ofen aus. Thunderbolt kann man nicht deaktivieren. Und selbst wenn man das könnte, es ist die elementare Schnittstelle auf dem Gerät, ohne TB kein Docking mit dem Display, kein Ethernet...

[ProUser]

Ja, man braucht physischen Zugriff. Der Worst-Case: Ein Konferenz-Beamer, der über den Displayport (=Thunderbolt) angeschlossen wird.
Das Problem gab es aber auch so ähnlich schon mit Firewire. Und mit externem PCI wird es ähnlich sein. Das ist der Preis, zu dem man die Vorteile einer direkten PCI Anbindung gegenüber USB z.B. erkauft.

Den Beamer an der Thunderbolt-Buchse des Macs einfach über ein gewöhnliches Displayport-Kabel anschließen - ein Displayport-Kabel leitet nur GraKa-Signale (Bild- u. Tonsignale) und nicht PCIe..

PS: Ist ein Konferenz-Beamer an der Decke befestigt, macht ein Displayport-Kabel sowieso mehr Sinn, da dieser anders als (derzeit) ein Thunderbolt-Kabel nicht auf 3 m Länge beschränkt ist, sondern bis zu einer Länge von 15 m eingesetzt werden kann - bei VGA, DVI und HDMI dagegen ist die nutzbare Auflösung immer von der Kabellänge anhängig..

Siehe dazu: http://www.elektronik-kompendium.de/...om/1205051.htm