Verschlüsselte Festplatten
macOS: FileVault 2-Passwort lässt sich über Thunderbolt auslesen
Solltet ihr noch auf der Suche nach guten Gründen für die schnellstmögliche Installation der macOS-Aktualisierung auf Version 10.12.2 sein, dann scheut euch diesen Blogeintrag des schwedischen Security-Experten Ulf Frisk an.
Der Hacker, der bereits zur letzten DefCon-Konferenz einen Vortrag über direkte Arbeitsspeicher-Angriffe gehalten hat, demonstriert jetzt im Video, wie leicht sich die Passwörter der Apple-eigenen Festplattenverschlüsselung FileVault 2 auslesen lassen.
Die einzigen Voraussetzungen: Ein etwa $300 teurer Thunderbolt-Adapter und ein schlafendes bzw. gesperrtes MacBook mit aktiver FileVault-Verschlüsselung. Frisk unterstreicht: So lange der Rechner nicht komplett heruntergefahren wurde, lässt sich nun das aktive Passwort aus dem Geräte-Speicher auslesen, anzeigen und zum Login in den eigentlich geschützten Mac benutzen.
Just stroll up to a locked mac, plug in the Thunderbolt device, force a reboot (ctrl+cmd+power) and wait for the password to be displayed in less than 30 seconds! […] The first issue is that the mac does not protect itself against Direct Memory Access (DMA) attacks before macOS is started. EFI which is running at this early stage enables Thunderbolt allowing malicious devices to read and write memory. At this stage macOS is not yet started. macOS resides on the encrypted disk – which must be unlocked before it can be started. Once macOS is started it will enable DMA protections by default.
Frisk, der seinen Angriff in diesem Youtube-Video demonstriert, hat das Kommandozeilen-Programm PCILeech geschrieben, mit dem sich der Angriff unter Zuhilfenahme des entsprechenden Thunderbolt-Adapters reproduzieren lässt, und bietet den Code hier zum Download an.
Natürlich wurde auch Apple über die Schwachstelle der hauseigenen Festplattenverschlüsselung informiert. Frisk erläutert:
- Ende Juli: Schachstelle gefunden
- 5. August: Präsentation von PCILeech auf der DefCon 24
- 15. August: Apple in Kenntnis gesetzt.
- 16. August: Apple bestätigt das Problem, erbittet zusätzliche Zeit zum Reagieren
- 13. Dezember: Apple veröffentlicht macOS 10.12.2 um die Lücke zu schließen
The solution Apple decided upon and rolled out is a complete one. At least to the extent that I have been able to confirm. It is no longer possible to access memory prior to macOS boot. The mac is now one of the most secure platforms with regards to this specific attack vector.
Doppelt verschlüsselt hält besser ;-)
Übel, aber in der Praxis vermutlich (wie die meisten Sicherheitslücken) für die meisten Anwender eher weniger relevant (ein Dieb oder Finder freut sich über das MacBook und nicht über die Daten…). Natürlich trotzdem wichtig, dass das behoben wurde.
Stünde in der Überschrift aber etwas von Microsoft oder Android, wäre das Ätsch-Geschrei hier vermutlich schon groß :-)
In (Uni)-Bibliotheken ist das Scenario nicht weit her geholt. Auch nicht im Büro oder an öffentlich zugänglichen Orten.
Es ist großartig, dass so zeitnah abgestellt wurde.
Ouch! Weiß jemand ob 10.11.6 auch betroffen ist?
FileVault 2 wurde wohl mit OS X v10.7 eingeführt – heißt aber natürlich nicht zwingend, dass 10.11.6 betroffen ist – wenn man den Blogeintrag so liest, darf man das aber zumindest stark vermuten.
Immer wieder diese vollkommen sinnlose Arroganz! Es gibt Menschen, die liebenden Blick über den Tellerrand, auch wenn das Mac Anwender im Leben nie begreifen können werden. Das macht Apple nämlich genauso, sonst sähen die Produkte sicherlich anders aus. Was mich im übrigen an diesen Kommentaren besonders stört ist, dass genau diese Kommentatoren sich über sinnlose Beiträge ebenso ich chauffieren. Wie mit das? Apple sicherlich nicht. Und die Produkte werden auch nicht besser dadurch.
Erst die Vorstellung auf der DefCon und erst 10 Tage danach Apple informieren? Sorry aber bei erster Gelegenheit bei der ich mir sicher bin eine si gravierende Lücke gefunden zu haben informier ich doch den Hersteller damit der reagieren kann bevor ich es in die Welt hinaus posaune…
Ob die Lücke nun wirklich geschlossen wurde?
Ich frage mich, ob diese (Apple’s) Programmierer so dumm sind, dass sie ein Verschlüsselungs- bzw. System-Passwort nicht im Speicher behalten werden sollte, und wenn, dann eben verschlüsselt. Es gibt heute so viele Beispiele, auf was für Ideen Schlaue kommen – ob aus reiner Neugier oder kriminell/schnüffeln lass ich mal offen – und wie sie vorgehen. Der Code liegt einem ja vor und seriös programmiert sollte er auch auskommentiert sein. Da muss man doch aus reinem Verantwortungsbewusstsein nachschauen, was man programmiert hat. Und auch von oben her sollten entsprechende Direktiven vorherrschen. Gut, ein Essen mit dem zukünftigen Präsidenten lässt das zeitlich halt nicht zu.
Im Ernst: Wir sprechen hier nicht von Kinderspielen oder Hobby-Programmierern, sondern gut bezahlten Mitarbeitern der hochangesehnen Firma Apple, die ein OS an HW gebunden zu Consumer-Höchstpreisen verkaufen, höchste Ansprüche an Qualität stellen und dazu sich als die Besten ausgeben.
Systeme werden nunmal komplexer. Aber diese gleichen Fragen stellen sich auch, warum Microsoft es seit Jahrzehnten nicht hinbekommt, ein halbwegs sicheres OS zu entwickeln und warum Google mit Android die gleichen Programmierfehler macht, wie MS bei Windows. Das macht mir sogar mehr sorgen – gerade bei der Verbreitung beider Systeme – als die Schwachstellen unter Mac OS und iOS.
So einfach wie sich das ein Hoby Informatiker vorstellt ist es leider nicht und die Apple Entwickler sind nicht einfach Dumm. Der Schlüssel muss im Hauptspeicher stehen damit das OS die Daten auf der HD entschlüsseln kann. Wird der Schlüssel verschlüsselt im Hauptspeicher gehalten, muss natürlich auch der 2 Schlüssel im Haupspeicher stehen. Wird dieser Schlüssel verschlüsselt ….
Es darf halt nicht möglich sein via TB oder andere Ports auf den entsprechenden Speicherbereich zuzugreifen. Und das vollständig abzusichern, ist nicht trivial. Hat man sensieble und verschlüsselte Daten auf seinem Computer, ist es sowieso besser die Kiste wenn man sie nicht physisch unter kontrolle hat und nicht Benutzung Einfach herunter zu fahren.
Niemand behauptet hier, dass Apple Programmierer dumm sind. Die arbeiten auch nur die Vorgaben ab, die ihnen von oben diktiert werden. Und wenn ein Betriebssystem pünktlich alle 365 Tage parat zu stehen hat, kann man schon mal das ein oder andere übersehen. Als Nutzer interessiert mich der Fakt, ob etwas trivial oder nicht ist, gar nicht. Im Gegenteil: Ich habe keinerlei Mitleid mit Leuten, die mir Dinge verkaufen, die nicht sicher sind. Und an dieser Stelle ist @mike’s Kritik mehr als gerechtfertigt.
Mal so ganz nebenbei: Es geht mir einfach nicht in die Birne, warum es soviele Apple-Nutzer gibt, die sich fehlerhafte Soft- oder Hardware aus Cupertino schönreden und die Apple-Milliardäre auch noch in Schutz nehmen. Das hat für mich was von Masochismus.
Naja, schönreden. Realistisch sein ist wohl eher richtig. Es gibt keine sicheren Systeme. Apple treibt es mit der Sicherheit schon relativ weit. Trotzdem wird es immer wieder Mittel und Wege geben…
@ Gast 48
Doch, ich stell mir das sogar sehr einfach vor.
Zu Hause habe ich einen Schüssel. Nun gehe ich schlafen, auswärts, …
Lasse ich den Schlüssel offen herumliegen und das Fenster auch nur einen Spalt offen, kann ihn jemand bei Abwesenheit (Schlafendes MB) mit einem Draht herausfischen – oder man bricht ein. Ist der Schlüssel aber in einer verschlossenen Schublade, Box oder Kasten, geht das nicht mehr so leicht oder gar nicht. Bin ich wieder zu Hause, kann ich ihn für jene, die ihn brauchen, wieder auf den Tisch legen.
Zum Mac: Der Schlüssel könnte ja mit dem Benutzerpasswort im Speicher verschlüsselt werden – besonders dann, wenn es in den Schlaf gelegt wird – und ist automatisch wieder entschlüsselbar, aber nur im laufenden Betrieb, nur vom BS und nicht auf Abruf von aussen.