Viele App-Entwickler für Mac nutzen das Sparkle-Framwork für praktische Auto-Updates - und machen damit zahlreiche Mac-Programme angreifbar. Betroffen sind nicht nur VLC und uTorrent.

Zahlreiche Programme für Mac-Nutzer sind für Man-in-the-Middle-Angriffe verwundbar, wenn diese den Sparkle-Updater verwenden. Das schreibt der Sicherheitsforscher Radek, zu dem leider kein Vorname bekannt ist, in seinem Blog. Betroffen sind zahlreiche Programme, die eine Sparkle-Version vor 1.13.1 verwenden und bei denen die Entwickler keine Kommunikation über HTTPS implementiert haben.

Das Sparkle-Framework kann von Entwicklern genutzt werden, um automatische Update-Routinen in ihre Programme einzubauen. Zahlreiche Programme, die nicht über den Mac-App-Store verfügbar sind, setzen Sparkle ein. Das quelloffene Programm steht unter der MIT-Lizenz.
Im aktuellen Fall sind unter anderem VLC, uTorrent in der Version 1.8.7, Sketch 3.5.1, Camtasia 2, Version 2.10.4 und Duetdisplay 1.5.2.4 betroffen. Die Liste ist nicht abschließend und könnte zahlreiche weitere Programme umfassen. VLC hat mittlerweile ein Update veröffentlicht.

Das Problem tritt auf, wenn Entwickler darauf verzichten, für das Herunterladen der Updates und die Verteilung der Update-Informationen HTTPS zu verwenden - was ohnehin problematisch ist. Ein Angreifer im gleichen Netzwerk wie der verwundbare Rechner kann die Kommunikation zwischen dem Nutzer und dem Appcast-Server abgreifen und manipulieren. Appcast ist ein RSS-Dienst, der Informationen über verfügbare Updates, Versionsnummern und Release Notes an die Nutzer verteilt.

Appcast nutzt XML, um die Informationen an die Nutzer zu schicken. Der übermittelte Code ist reines HTML, das dann im Installer als Webview-Komponente angezeigt wird. Ein Angreifer kann durch das Abfangen der Nachricht also HTML und Javascript-Code in die Webview-Komponente einfügen und auf dem Rechner der Nutzer anzeigen.

Dieser Angriff vermag also zunächst keinen konkreten Schaden anzurichten - doch ein Angreifer könnte das System dazu bringen, den Standardbrowser aufzurufen, um dort gängige Exploit-Kits über manipulierte Webseiten aufzuspielen. Doch nicht immer sind Exploits verfügbar - ein Angriff ist trotzdem möglich.

Angreifer können auch Code ausführen

Dazu werden nach Angaben von Radek folgende Komponenten benötigt: ein eigener FTP-Server, um Schadcode zu hosten, ein HTTP-Server, der als Appcast-Server dient, und umgeleiteter HTTP-Traffic von der eigentlichen Applikation zum eigenen HTTP-Server. Jetzt wird eine Einstellungsdatei des Mac-Terminals mit dem Namen UPGRADE.terminal geladen. In einer solchen Einstellungsdatei können beim Start auszuführende Kommandos voreingestellt werden.

Das aufgerufene Kommando lädt eine externe Ressource vom FTP-Server. Externe Ressourcen werden von OS X automatisch und ohne weitere Nachfrage nach /Volumes/ gemountet. Das gilt nach Angaben von Radek für FTP, SMB und AFP-Ressourcen. Der erzeugte lokale Pfad entspricht dem Namen des eigenen Servers. Die App wird über eine .terminal-Datei geöffnet. Auf diesem Wege findet durch das Betriebssystem keine Prüfung eines Zertifikats und auch keine Signaturprüfung statt. Der Gatekeeper-Sicherheitsmechanismus wird also umgangen.

Es ist nicht notwendig, ein Update zu forcieren, um den Angriff auszuführen. Die Applikationen prüfen in regelmäßigen Abständen selbst, ob Updates verfügbar sind - abwarten reicht also.
In dem Post werden weitere mögliche Angriffe beschrieben. So ist es möglich, durch Manipulation des XML-Contents den Billion-Laughs-Angriff zu starten. Hier wird eine Schwäche für XML External Entitiy Processing (XXE) ausgenutzt. Dabei werden externe URIs durch XML-Parsing in die zurückgegebene XML-Antwort integriert. Im Beispiel zeigt Radek, wie er die Sequel-Applikation dazu bringen kann, mehr als 3 GByte Speicher zu belegen.

Nutzer könnten selbst prüfen, ob verschiedene Programme für die Angriffe anfällig sind und sich schützen. Einerseits kann die Auto-Update-Funktion bei den meisten Programmen deaktiviert werden. Erfahrene Nutzer können außerdem mit Wireshark prüfen, ob bestimmte Programme unverschlüsselt kommunizieren. Entwickler müssten bei der Konfiguration von Sparkle einen HTTPS-Link angeben. Außerdem sollten sie auf die aktuelle Version des Sparkle-Frameworks updaten.