Die Security-Firma Palo Alto Networks hat entdeckt, dass Hunderte Apps aus China mit einer kompromittierten Version der Entwicklungsumgebung Xcode programmiert wurden. Sicherheitsforscher Ryan Olson nennt Details.
Durch die "XcodeGhost"-Affäre hat das Vertrauen der Nutzer in Apples App-Store-Sicherheit einen Knacks bekommen. Malware-Entwicklern in China war es gelungen, Dutzende Entwickler davon zu überzeugen, eine manipulierte Version der Entwicklungsumgebung Xcode zu verwenden, die wiederum Schadcode in fertige Apps integrierte. Apple selbst merkte davon bei seinen Sicherheitsüberprüfungen nichts.
Unter den betroffenen Anwendungen waren populäre Programme wie WeChat oder die chinesische Version von "Angry Birds 2", die Millionen Nutzer haben. Als Entdecker von "XcodeGhost" gilt die US-Sicherheitsfirma Palo Alto Networks. Im Interview mit Mac & i nennt deren Sicherheitsforscher Ryan Olson, der die Malware zusammen mit Claud Xiao untersucht hat, die technischen Details.
Mac & i: Herr Olson, hat Apple selbst die Möglichkeit, "XcodeGhost"-Infektionen zu erkennen?
Ryan Olson: Ja, Apple kann das. Neben der Möglichkeit, das Verhalten von Apps zu beobachten, die einen Command & Control-Server für die Malware besuchen, kann der Konzern auch einfach den Code aller Apps scannen. Letztere Methode ist schneller und genauer.
Technisch gesehen hat XcodeGhost zwar verschiedene Versionen, doch sie haben alle einige gemeinsame Code-Charakteristika. Wir haben Apple alle diese Versionen übermittelt, damit die Firma sie erkennen kann. Wir wissen allerdings nicht, welche Erkennungsmethode Apple benutzt.
Insgesamt ist es also nicht schwer, Apps, die mit XcodeGhost infiziert sind, zu erkennen, denn der Code ist ja jetzt bekannt. Die große Herausforderung liegt darin, ähnliche Angriffe zu erkennen, die mit einer neuen böswilligen Payload kommen.
Mac & i: XcodeGhost nutzt eine besonders gefährliche Methode, indem die komplette Entwicklungsumgebung verwendet wird, um Malware in Apps einzuschleusen. Gibt es eine Möglichkeit für Apple, Integritätschecks durchzuführen, um festzustellen, dass eine Anwendung mit dem echten Xcode erstellt wurde? Hat Apple vergessen, solche Überprüfungen einzubauen?
Olson: Aus der Perspektive des App Store ist es schwierig, herauszufinden, ob eine App mit der offiziellen Version von Xcode entwickelt wurde oder nicht. Unseres Wissens nach gibt es keine naheliegende Methode für Apple, zu überprüfen, mit was eine App erstellt wurde. Die Codesignatur von iOS ist hier irrelevant, denn das Problem tritt ja auf, bevor diese Signatur in Xcode erfolgt – auch böser Code wird so signiert.
Man muss an anderer Stelle ansetzen. Es gibt ja schon jetzt Sicherheitsmechanismen im aktuellen OS X, die verhindern, dass ein modifiziertes Xcode ausgeführt wird – über den GateKeeper-Mechanismus, der die Codesignatur prüft und schaut, woher eine App kommt. In der Praxis schalten viele Entwickler diese standardmäßig aktive Sicherheitsmaßnahme aber ab, weil sie auch einige nützliche Drittanbieter-Werkzeuge blockieren kann und manchmal das Testen behindert.
Mac & i: In ihrer Untersuchung schreiben Sie, dass XcodeGhost-infizierte Apps Phishing-Routinen enthielten und den Inhalt der Zwischenablage klauen konnten. Welche dieser böswilligen Routinen war tatsächlich aktiv?
Olson: Das wissen wir noch nicht, weil diese potenziellen Angriffe vollständig von den Command & Control-Servern gesteuert wurden, die mittlerweile abgeschaltet sind. Unsere Analyse zeigt, dass diese Funktionen implementiert waren und vom Angreifer aus der Ferne aktiviert werden konnten. Datenverkehr vom Command & Control-Server, den wir vor der Abschaltung mitschneiden konnten, war allerdings harmloser: Er besagte nur, dass die Malware inaktiv bleiben sollte.
Mac & i: Apple verwendet in iOS eine Sandbox, die Apps untereinander abschottet. Sorgte die dafür, dass XcodeGhost-Infektionen weniger problematisch sind? Sollte Apple die Sandbox noch stärker schützen?
Olson: Zunächst muss man wissen, dass Apples Sandbox auch unter den Bedingungen von XcodeGhost weiter funktioniert. Sie kann einige sensible Operationen wirksam unterdrücken, die die Malware nutzen könnte. Gäbe es keine Sandbox, wäre XcodeGhost viel, viel gefährlicher in seinem Verhalten.
Allerdings zeigt sich auch, dass die aktuelle Version von XcodeGhost mit ihrem Verhalten die Sandbox nicht verletzt. Alle verwendeten Angriffsformen nutzen ein ganz normales Standardverhalten wie den Aufruf einer URL oder das Aufpoppen eines Dialogs [zwecks Phishing, Anm. d. Red]. Die Sandbox kann so etwas natürlich nicht verhindern, weil so auch völlig legitime Apps gestört würden.
Mac & i: Es ist erstaunlich, dass so viele chinesische Entwickler Apples Originalwebsite nicht verwendet haben, um das kostenlose Xcode herunterzuladen. Selbst Großkonzerne wie Tencent (WeChat) waren dabei. Sind die Download-Geschwindigkeiten in China wirklich so schlecht, dass man auf möglicherweise manipulierte lokale Downloads zugreifen muss?
Olson: Die Geschwindigkeiten sind unterschiedlich. Manchmal geht es mit ein paar Megabytes pro Sekunde, manchmal kriechen die Daten mit 10 Kilobyte pro Sekunde durch die Leitung. Die Geschwindigkeit hängt von vielen Faktoren ab [darunter insbesondere die "Große Firewall" der chinesischen Regierung, Anm. d. Red.].
Bislang wissen wir nicht, wie es sein konnte, dass große Firmen wie Tencent unoffizielle Kopien von Xcode für ihre Produkte verwendet haben. Dort wurde das Problem nur bestätigt, Gründe aber nicht genannt.
Mac & i: Könnten ähnliche Angriffsformen wie XcodeGhost noch in Apps stecken?
Olson: Ja, da gibt es viele Möglichkeiten. Neben Xcode gibt es ja noch diverse andere große Bibliotheken für die App-Entwicklung, die sich durch inoffizielle Kanäle verbreiten.
Das gilt nicht nur für Apple. China hat ja beispielsweise auch Google-Websites blockiert, was dazu führt, dass chinesische Entwickler sich ihr Android-SDK und das Android Studio nicht direkt vom Hersteller herunterladen können. Daneben besteht auch die Möglichkeit, dass selbst nach Installation der offiziellen Xcode-Version eine OS-X-Malware daherkommt und Xcode oder andere Werkzeuge nachträglich manipuliert.