{"id":25054,"date":"2020-09-07T14:59:38","date_gmt":"2020-09-07T12:59:38","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=25054"},"modified":"2020-09-07T14:59:38","modified_gmt":"2020-09-07T12:59:38","slug":"black-hat-macos-macros-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/black-hat-macos-macros-attack\/25054\/","title":{"rendered":"Wie man b\u00f6sartige Makros unbemerkt auf MacOS startet"},"content":{"rendered":"

Viele Benutzer von MacOS-Computern sind immer noch davon \u00fcberzeugt, dass ihre Rechner keinen Schutz ben\u00f6tigen. Schlimmer noch, viele Systemadministratoren in Unternehmen, in denen Mitarbeiter mit Apple-Rechnern arbeiten, sind oft der gleichen Meinung.<\/p>\n

Auf der Black Hat USA 2020<\/a>-Konferenz versuchte der Forscher Patrick Wardle, die Zuh\u00f6rer von diesem Irrtum zu befreien, indem er seine MacOS-Malwareanalyse vorstellte und eine Exploit-Kette aufbaute, um die Kontrolle \u00fcber einen Apple-Computer zu \u00fcbernehmen.<\/p>\n

Microsoft, Makros und Macs<\/h2>\n

Dokumente mit b\u00f6swilligen Makros (Office-Anwendungen) sind eine der wohl gew\u00f6hnlichsten Angriffsmethoden auf MacOS. Tats\u00e4chlich bevorzugen viele Benutzer trotz der Verf\u00fcgbarkeit von Apples eigenen Produktivit\u00e4tsanwendungen die Verwendung von Microsoft Office. Einige tun dies aus Gewohnheit, andere aus Kompatibilit\u00e4tsgr\u00fcnden.<\/p>\n

Nat\u00fcrlich kennt jeder die potenzielle Bedrohung, die von Dokumenten mit Makros ausgeht. Daher verf\u00fcgen sowohl Microsoft als auch Apple \u00fcber Schutzmechanismen, die den Benutzer besch\u00fctzen sollen.<\/p>\n

Microsoft z.B. warnt Benutzer, wenn ein Dokument ge\u00f6ffnet wird, das ein Makro enth\u00e4lt. Wenn der Benutzer beschlie\u00dft, das Makro trotzdem zu starten, wird der Code in einer Sandbox ausgef\u00fchrt, was den Entwicklern von Microsoft zufolge verhindern soll, dass der Code auf die Dateien des Benutzers zugreift oder dem System anderen Schaden zuf\u00fcgt.<\/p>\n

Was Apple betrifft, so hat das Unternehmen mehrere neue Sicherheitsfunktionen in der neuesten Version seines Betriebssystems, macOS Catalina, eingef\u00fchrt. Dazu geh\u00f6ren insbesondere die Dateiquarant\u00e4ne und die \u201eApple-Beglaubigung\u201c, eine Technologie, die den Start von ausf\u00fchrbaren Dateien aus externen Quellen verhindert.<\/p>\n

Grunds\u00e4tzlich sollten diese Technologien zusammengenommen ausreichen, um jeglichen Schaden durch b\u00f6sartige Makros zu verhindern. Theoretisch scheint alles ziemlich sicher zu sein.<\/p>\n\n

\u00a0<\/p>\n

Eine Exploit-Kette befreit das Makro aus der Sandbox<\/h2>\n

In der Praxis werden jedoch viele Sicherheitsmechanismen eher problematisch umgesetzt. Daher k\u00f6nnen Forscher (oder Angreifer) m\u00f6glicherweise Methoden finden, um sie zu umgehen. Wardle veranschaulichte dies in seinen Vortrag, indem er eine Kette von Exploits aufzeigte.<\/p>\n

1. Umgehung des Makro-deaktivierenden Mechanismus<\/h3>\n

Schauen wir uns folgendes Beispiel an: Das System warnt den Benutzer, wenn es ein Makro in einem Dokument entdeckt. In den meisten F\u00e4llen funktioniert es wie von den Entwicklern beabsichtigt. Gleichzeitig ist es aber auch m\u00f6glich, ein Dokument zu erstellen, in dem das Makro automatisch und ohne Benachrichtigung des Benutzers gestartet wird, selbst wenn die Makros in den Einstellungen deaktiviert wurden.<\/p>\n

Dazu kann das Sylk<\/a> (SLK)-Dateiformat verwendet werden. Das Format, das die XLM-Makrosprache verwendet, wurde in den 1980er Jahren entwickelt und zuletzt 1986 aktualisiert. Microsoft-Anwendungen (z.B. Excel) unterst\u00fctzen Sylk jedoch aus Gr\u00fcnden der Abw\u00e4rtskompatibilit\u00e4t immer noch. Diese Schwachstelle ist nicht neu und wurde 2019 ausf\u00fchrlich beschrieben<\/a>.<\/p>\n

2. Flucht aus der Sandbox<\/h3>\n

Wie wir jetzt festgestellt haben, kann ein Angreifer auf unsichtbare Weise ein Makro ausf\u00fchren. Der Code wird jedoch nach wie vor in der isolierten Sandbox von MS Office ausgef\u00fchrt. Wie kann ein Hacker den Computer \u00fcberhaupt angreifen? Nun, es stellt sich heraus, dass der Ausbruch aus Microsofts Sandbox auf einem Mac nicht gerade schwer ist.<\/p>\n

Es stimmt, dass man gespeicherte Dateien auf dem Rechner von der Sandbox aus nicht ver\u00e4ndern kann. Man kann jedoch Dateien erstellen<\/em>. Diese Schwachstelle wurde bereits fr\u00fcher genutzt, um die Sandbox zu umgehen, und es scheint, dass Microsoft ein Update ver\u00f6ffentlicht hat, um die Schwachstelle zu schlie\u00dfen. Das Problem wurde jedoch nicht wirklich gel\u00f6st, wie eine genauere Untersuchung des Patches gezeigt hat: Der Patch behebt nur die Symptome, indem es die Erstellung von Dateien an Orten blockiert, die von einigen Entwicklern als kritisch und unsicher angesehen wurden. Ein Beispiel w\u00e4re daf\u00fcr der Ordner LaunchAgents, der als Speicherort f\u00fcr Skripte dient, die nach einem Neustart automatisch gestartet werden.<\/p>\n

Aber wer wei\u00df, ob Microsoft bei der Erstellung des Patches alle \u201egef\u00e4hrlichen Ort\u201c abgedeckt hat? Zuf\u00e4lligerweise konnte ein in Python geschriebenes Skript, das von einem Office-Dokument aus gestartet (und daher in einer Sandbox ausgef\u00fchrt wurde) verwendet werden, um ein \u201eAnmeldeobjekt\u201c zu erstellen. Solche Anmeldeobjekte werden automatisch gestartet, wenn sich der Benutzer sich am Rechner anmeldet. Das System startet das Objekt, so dass es au\u00dferhalb<\/em> der Office-Sandbox ausgef\u00fchrt wird und somit die Sicherheitsma\u00dfnahmen von Microsoft umgeht.<\/p>\n

3. Umgehung der Apple-Sicherheitsmechanismen<\/h3>\n

Jetzt wissen wir also, wie man heimlich ein Makro ausf\u00fchrt und ein Anmeldeobjekt erstellt. Nat\u00fcrlich verhindern die Sicherheitsmechanismen im MacOS immer noch diesen Backdoorangriff, der durch einen in verd\u00e4chtigen Prozess in einer Sandbox gestartet wird, oder?<\/p>\n

Einerseits ja, denn Apples Sicherheitsmechanismen blockieren in der Tat die Ausf\u00fchrung eines solchen Codes. Andererseits gibt es einen Workaround: Wenn man ein ZIP-Archiv als Anmeldeobjekt hinzuf\u00fcgt, dann entpackt das System die Datei bei der n\u00e4chsten Anmeldung automatisch.<\/p>\n

Der Angreifer muss nur noch den richtigen Ort f\u00fcr das Entpacken der Datei w\u00e4hlen. Beispielsweise kann das Archiv im gleichen Verzeichnis wie die Benutzerbibliotheken abgelegt werden, also genau dort, wo Objekte vom Typ Launch Agent, die Microsoft korrekterweise als angreifbar einstuft, gespeichert werden sollen. Das Archiv selbst kann ein Verzeichnis namens LaunchAgents enthalten, das das Skript Launch Agent enth\u00e4lt.<\/p>\n

Nach dem Entpacken wird das Skript im Ordner LaunchAgents abgelegt und beim Neustart ausgef\u00fchrt. Da es von einem vertrauensw\u00fcrdigen Programm (dem Archivierungsprogramm) erstellt wurde und keine Quarant\u00e4ne-Attribute besitzt, kann es dazu verwendet werden, etwas Gef\u00e4hrlicheres zu starten. Sicherheitsmechanismen werden den Start dieser Datei nicht einmal verhindern.<\/p>\n

Infolgedessen kann ein Angreifer \u00fcber die Bash-Befehlsshell einen Mechanismus starten, um Fernzugriff auf den Rechner zu erhalten (Reverse Shell). Dieser Bash-Prozess kann zum Herunterladen von Dateien verwendet werden, denen auch das Quarant\u00e4ne-Attribut fehlt, so dass der Angreifer wirklich b\u00f6sartige Codes herunterladen und ohne Einschr\u00e4nkungen ausf\u00fchren kann.<\/p>\n

Eine kurze Zusammenfassung:<\/p>\n