Mac Security – Ein Satz mit X? Teil 2: Forscherangriffe & Pwn2Own
Kommentare

Mac OS X ist sicher. Behauptet zumindest Apple. So sicher, dass man dort lange Zeit behauptete, Virenscanner seien überflüssig und Viren ein Windows-Problem. Dass das die Hersteller der Virenscanner natürlich ganz anders sehen, ist verständlich. Wer hat Recht? Kann man Mac OS X nicht angreifen, oder wollte es nur keiner angreifen?
In unserer fünfteiligen Serie nehmen wir die Sicherheitsrisiken von Mac OS X genau unter die Lupe.

Im Gegensatz zu iOS mit seinem relativ guten Sicherheitskonzept samt „walled garden“ des App Stores hatte Mac OS X zumindest anfangs kein echtes Sicherheitskonzept – und eigentlich gibt es das heute noch nicht. Man verließ sich auf die Sicherheit, die Unix als Mehrbenutzersystem von Haus aus mitbrachte. Der Administrator verwaltet den Rechner, der normale Benutzer nutzt ihn. Einen Root-Benutzer gibt es gar nicht, zumindest keinen, der sich einloggen könnte.

Da es oft nur einen einzigen Benutzer gibt, ist der dann gleichzeitig der Administrator, und statt zweier getrennter Benutzerkonten wird meist ein einziges mit den Rechten, den Rechner zu verwalten, verwendet. Und schon ist eine der Schutzmaßnahmen hinfällig, da dieser Benutzer Schaden anrichten kann, der ihm meist gar nicht bewusst ist.

Die optionale Verschlüsselung des Dateisystems ist in dieser Konstellation nicht von Bedeutung. Sie schützt höchstens bei einem Diebstahl des Geräts. Falls es Schadsoftware oder allgemein einem Angreifer gelingt, sich auf einem laufenden Rechner einzuschleichen, hat sie oder er zumindest auf die Daten des angegriffenen Benutzers Zugriff.

Lange Zeit riet Apple auch von der Nutzung eines Virenscanners ab – mangels Schadsoftware gab es einfach keinen Bedarf dafür. Erst sehr spät nahm man von dieser Einstellung Abstand, und einige Zeit später implementierte man selbst einen rudimentären Virenscanner.

Inzwischen hat Apple den Mac App Store eingeführt, und für die darin aufgelisteten Programme wird es früher oder später auch die Pflicht zur Nutzung der Sandbox geben. Mit Mac OS X „Mountain Lion“ wurde mit „Gatekeeper“ die Möglichkeit geschaffen, optional die Ausführung von nicht aus dem Mac App Store geladenen Programmen oder von Programmen ohne vertrauenswürdige Signatur zu verbieten. Man versucht also, die Benutzer in einen „walled garden“ zu locken, der eigentlich überhaupt nicht verlockend aussieht. Und was die Sicherheit betrifft, hat der Mac App Store sogar einen großen Nachteil: Apple braucht zu lange, um Updates zu prüfen und zuzulassen. Dadurch werden dringende Sicherheitsupdates verzögert ausgeliefert.

Aber werfen wir mal einen Blick auf die Sicherheit von Mac OS X im Laufe der Zeit. Los geht es mit der Theorie.

Angriffe durch Forscher

Sicherheitsforscher haben sich immer wieder mit der Sicherheit von Mac OS X beschäftigt. Das Folgende ist ein Auszug, der Schwerpunkt liegt auf den „Black Hat“-Konferenzen. Auch auf vielen anderen Sicherheitskonferenzen wurden Vorträge zum Mac gehalten, die Website der „Black Hats“ hat aber das bei Weitem beste Archiv.

Der Januar 2007 wurde von Lance M. Havok und Kevin Finisterre zum „Month of Apple Bugs“ erklärt: Sie veröffentlichten jeden Tag eine neue Schwachstelle in Mac OS X oder Mac-Programmen. Darunter einige, die als kritisch eingestuft wurden und die Ausführung von Code aus der Ferne oder lokale Privilegieneskalation erlaubten.

Im Juni 2007 stellte Charlie Miller, von dem noch öfter die Rede sein wird, auf der „Black Hat USA 2007“ Angriffe auf die damals aktuelle Version „Leopard“ von Mac OS X vor (Präsentation, Whitepaper). Entgegen der Ankündigung beschäftigte sich gut die Hälfte seines Vortrags mit der Sicherheit des iPhones, im Whitepaper geht er aber ausführlicher auf die Mac-Angriffe ein.

Dass es prinzipiell gar nicht schwierig ist, Code in Mac-Programme einzuschleusen, hat Vincenzo Iozzo im Februar 2009 auf der „Black Hat DC 2009“ gezeigt. Er hatte sich mit dem von Mac OS X für ausführbare Dateien verwendeten Mach-O-Dateiformat und Angriffen darauf beschäftigt (Video, Whitepaper & PDF).

[ header = Seite 2 ]

Wie man Schwachstellen in Mac OS X findet und Exploits dafür entwickelt, haben Dino Dai Zovi und Charlie Miller im März 2009 auf der „CanSecWest 2009“ beschrieben. Im April 2009 hielt Charlie Miller dann zusammen mit Vincenzo Iozzo auf der „Black Hat Europe 2009“ einen Vortrag über die Entwicklung von Payloads für Mac OS X (PDF der Präsentation).

Neue, Mach-basierte Rootkits für Mac OS X wurden von Dino Dai Zovi im Juli 2009 auf der „Black Hat USA 2009“ vorgestellt [Paper und Slides]. Der Kernel von Mac OS X ist ein Hybrid aus BSD- und Mach-Kernel. Während Rootkits für FreeBSD seit Langem ausführlich untersucht sind, gibt es deutlich weniger Untersuchungen der Möglichkeiten, die der Mach-Teil des Kernels bietet.

Im Januar 2011 hielten Dino Dai Zovi und Vincenzo Iozzo auf der „Black Hat DC 2011“ einen Workshop zur Exploit-Entwicklung unter Mac OS X. Von der Suche nach Schwachstellen bis zum Schreiben des Exploits wurden alle Schritte vorgeführt. Im März 2011 hielt Vincenzo Iozzo den gleichen Workshop auf der „Black Hat Europe 2011“.

Die Schutzfunktionen der Kernel von Linux, Windows, Mac OS X, FreeBSD, iOS und Android gegen die Ausnutzung von Speicherverletzungen samt möglicher Angriffe darauf wurden im März 2011 auf der „Black Hat Europe 2011“ von Patroklos Argyroudis und Dimitrios Glynos vorgestellt (Whitepaper, Präsentation).

Die Rolle von Mac OS X in Zeiten der Advanced Persistent Threats wurde von Alex Stamos, Aaron Grattafiori, Tom Daniels, Paul Youn und B.J. Orvis im August 2011 auf der „Black Hat USA 2011“ beleuchtet. Als Advanced Persistent Threat (APT) werden die oft von Staaten ausgehenden, mit viel Aufwand durchgeführten gezielten Angriffe auf Unternehmen und Organisationen bezeichnet. Denen hat Mac OS X relativ wenig entgegen zu setzen. Bei Windows sieht es allerdings auch nicht besser aus.

Auf der gleichen Konferenz stellte Charlie Miller seine Untersuchungen der Firmware der Embedded Controller in den Lithium-Ionen- und Lithium-Polymer-Akkus der MacBooks vor. Das ist aber mehr eine Spielerei – sehr wahrscheinlich kann ein Angreifer maximal den Akku unbrauchbar machen.

Im November 2011 veröffentlichte Core Security ein Security Advisory, in dem auf eine Schwachstelle in den von Apple vordefinierten Sandbox-Profilen hingewiesen wird: Einige der Beschränkungen lassen sich über Apple Events umgehen. Apple hat daraufhin eine Anpassung der Dokumentation angekündigt, um klar zu stellen, dass sich die Einschränkungen der vordefinierten Profile nur auf den jeweiligen Prozess beziehen.

Rootkits für die EFI-Firmware der Macs wurden von Loukas K im Juli 2012 auf der „Black Hat USA 2012“ vorgestellt. Im August 2012 wies Jonathan Grynspan auf einen Schwachpunkt in der FileVault-2-Verschlüsselung hin: Erlaubt der Benutzer das Zurücksetzen des Passworts mithilfe der Apple ID, kann jeder, der Apple ID und zugehöriges Passwort kennt, auf die mit FileVault geschützten Daten zugreifen. Ist das ein Problem? Eigentlich nicht, da niemand Apple ID und Passwort des Benutzers kennen sollte. Denn sonst hat der noch ganz andere Probleme. Einer Analyse von Omar Choudary, Felix Gröbert und Joachim Metz zufolge ist FileVault 2 ansonsten sicher. Lediglich die Entropie des Recovery-Passworts könnte verbessert werden, und Teile der Benutzerdaten aus der Systeminstallation bleiben nach der Verschlüsselung unverschlüsselt auf der Platte zurück, bis sie überschrieben werden.

Im November 2012 demonstrierte Bogdan Calin, wie über eine präparierte E-Mail durch einen Cross-Site-Request-Forgery-Angriff die Einstellungen von SOHO-Routern manipuliert werden können. Dabei können zum Beispiel die Einstellungen des Nameservers geändert werden, so dass der Angreifer sein Opfer beispielsweise auf eine Phishing-Seite locken kann. Das funktioniert prinzipiell mit jedem betroffenen Router und jedem E-Mail-Client. Erwähnenswert ist es hier nur, weil Bogdan Calin sich iOS und Mac OS X für seine Demonstrationen ausgesucht hat.

Zwischenfazit 1

Die Sicherheitsforscher haben immer wieder theoretisch und teilweise an Beispielen auch praktisch gezeigt, dass es möglich ist, Schwachstellen in Mac OS X erfolgreich auszunutzen. Wie das in der Praxis aussehen kann, wurde auf den Pwn2Own-Wettbewerben, die seit 2007 auf der Sicherheitskonferenz CanSecWest abgehalten werden, demonstriert. Dort ist Mac OS X mit Ausnahme von 2012 jedes Jahr negativ aufgefallen.

[ header = Seite 3 ]

Pwn2Own

Die Regeln der Pwn2Own-Wettbewerbe waren bis 2012 recht einfach: Die Veranstalter stellten einige Notebooks und später auch Smartphones bereit. Wer ein Gerät als erster erfolgreich kompromittierte, durfte es behalten und bekam teilweise noch einen Geldpreis dazu. 2012 wurden die Regeln verschärft, was viele potentielle Teilnehmer abschreckte.

Beim ersten Wettbewerb 2007 standen je ein 15″- und ein 17″- MacBook als Angriffsziel bereit; damals lief der Wettbewerb unter dem Titel „Hack a Mac“. Dadurch sollte die Unsicherheit von Mac OS X demonstriert werden. Um das MacBook zu gewinnen, musste der Angreifer beim 15″-Gerät Code einschleusen und mit normalen Benutzerrechten ausführen, beim 17″-Gerät wurde die Codeausführung mit Root-Rechten verlangt. Dino Dai Zovi konnte durch eine Drive-by-Infektion auf dem 15″-MacBook-Code ausführen, wodurch er den Wettbewerb gewann (Interview mit Dino Dai Zovi auf ZDNet).

2008 wurde der Wettbewerb um weitere Geräte erweitert: Außer einem MacBook Air mit Mac OS X standen je ein Notebook mit Windows Vista und Ubuntu Linux als Angriffsziele bereit. Am zweiten Tag des Wettbewerbs konnten Charlie Miller, Jake Honoroff und Mark Daniel das MacBook über eine Schwachstelle in Safari kompromittieren und gewannen damit das Gerät und 10.000 US-Dollar.

Noch mehr Geräte als Angriffsziele standen 2009 bereit. Da sich mehrere Teilnehmer angemeldet hatten, jedes Gerät aber nur einmal gewonnen werden konnte, wurde die Startreihenfolge ausgelost. Charlie Miller hatte Glück und wurde für den ersten Versuch ausgelost. Er konnte das bereit gestellte MacBook Air innerhalb von zwei Minuten erfolgreich kompromittieren. Die ausgenutzte Schwachstelle kannte er schon seit einem Jahr, er hatte sie extra für den Wettbewerb zurückgehalten. Sein Preis: Das MacBook Air und 5.000 US-Dollar. Nach ihm gelang das gleiche noch Nils, der dafür ebenfalls 5.000 US-Dollar bekam.

2010 galten mehr oder weniger die gleichen Bedingungen wie 2009. Wieder gewann Charlie Miller das MacBook plus 10.000 US-Dollar, wieder mithilfe einer Drive-by-Infektion. Auch Nils konnte erneut das MacBook erfolgreich angreifen, das Gerät hatte aber wie im Vorjahr Charlie Miller bereits gewonnen.

Auch 2011 galten ungefähr die gleichen Regeln wie in den Vorjahren. Das MacBook wurde diesmal vom Team des französischen Sicherheitsunternehmens VUPEN gewonnen, das vor Charlie Miller ausgelost worden war und das Gerät erfolgreich kompromittieren konnte – übrigens auch mit einer Drive-by-Infektion. Charlie Miller ging aber auch 2011 nicht leer aus, er kompromittierte gemeinsam mit Dion Blazakis erfolgreich ein iPhone.

Wie schon erwähnt, wurden die Regeln 2012 gründlich geändert. Daraufhin nahmen mehrere Forscher, unter ihnen Charlie Miller, nicht mehr am Wettbewerb teil (Bericht bei ZDNet). Und erstmals wurde das MacBook mit Safari nicht über eine bisher unbekannte Schwachstelle kompromittiert. Was aber nicht an dessen Sicherheit lag: Es hat einfach niemand versucht. In einem zweiten Wettbewerbsteil mussten Exploits für bereits gepatchte Schwachstellen entwickelt werden, dabei wurde Safari unter Mac OS X zwei Mal Opfer eines erfolgreichen Angriffs.

Zwischenfazit 2

Theoretisch sind Angriffe möglich, Praktisch sind Angriffe möglich – das klingt doch ganz so, als müsste es massenhaft Angriffe auf Mac OS X geben, oder? Wie sieht es also damit aus? Gibt es Schadsoftware für den Mac?

Im zweiten Teil des Artikels geht es morgen unter anderem weiter mit einem Überblick über Schadsoftware und alles rund um Apples erstem Virenscanner.

Teil 1 der Mac Security Week: Timeline der Mac OS X Angriffe

Entwickler Magazin

Entwickler Magazin 2.2013Der Artikel „Mac Security – Ein Satz mit X?“ von Carsten Eilers erscheint im Entwickler-Magazin 2.2013. Mehr Infos zum Heft findet Ihr auf der Homepage des Entwickler Magazins.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -