iOS/OS X: XcodeGhost fischt iCloud-Logins ab?

Eine trojanisierte Xcode-Version in China produziert infizierte (iOS)-Apps, die dann ihrerseits versuchen, auf dem User-Gerät iCloud-Logins abzufischen. Wir haben als iOS-User der betroffenen Apps auf jeden Fall ein Problem. Und Ihr kennt mich. Ich mache keine Witze bei dem Thema.

Zusammenfassung

Xcode ist die Entwicklungsumgebung, mit der Programmierer Apps für Apples Geräte herstellen. XcodeGhost ist ein kompromittiertes Xcode-Installations Disk Image, das für mindestens die Versionen 6.1 bis 6.4 entdeckt wurde. Es wurde über den File Sharing Dienst Baidu verteilt, der gerne von chinesischen Entwicklern benutzt wird, um schnellere Downloads zu haben. Baidu hat die Malware inzwischen von seinen Servern gelöscht. Und Apple hat begonnen, damit erstellte Apps aus dem Store zu entfernen und die Entwickler zu benachrichtigen, mit einer sauberen originalen Xcode-Version ein Update zu erstellen. Es sind mindestens 39 Apps betroffen. Die chinesische Sicherheitsfirma Qihoo360 sagt sogar, sie habe 344 kompromittierte Apps entdeckt.

Apple hat nun eine offizielle Liste betroffener Apps.

Inzwischen, nach Sichtung des mutmaßlichen Client-Quellcodes der Malware und dem Testen der XcodeGhost Version 6.4, bestand wohl keine konkrete Gefahr, daß Accounts abgefischt wurden. Details weiter unten …

Verbreitungs-Methode beim Entwickler

Chinesische Entwickler haben manchmal langsames Internet und versuchen ihre Downloads schneller zu bekommen, indem sie einmal heruntergeladene Dateien auf den File-Sharing-Dienst Baidu für andere Entwickler hochladen. Cracker haben eine manipulierte Version des Xcode-Installers erstellt und dort verteilt. Sie verteilten die Links in diversen Entwickler-Foren. Das XcodeGhost genannte manipulierte Disk-Image wurde bereits vor sechs Monaten dort hochgeladen.

Der manipulierte Installer enthält einige zusätzliche Dateien, die man aufgelistet bekommt, wenn man per Shell die Signaturprüfung durchführt. Dort bekommt man eine klare Warnung, daß eine versiegelte Ressource fehlt oder ungültig ist. Die wesentliche Datei ist ein kompromittiertes CoreServices Framework.

Wenn der Entwickler diese manipulierte Version benutzt, wird in jede damit gebaute App das gefälschte CoreServices Framework eingebunden. Diese Version enthält Extra-Code für die UIWindow- und die UIDevice-Klasse. Jede iOS App hat ein UIWindow: Ihr eines und einziges (meistens Vollbild-) Fenster. Mac-Apps können mehrere Fenster haben.

Xcode Check

Ich habe mir die manipulierte Xcode-Version 6.4 besorgt und auf meinem Test-System mit Yosemite angesehen und mit dem originalen Xcode 6.4 verglichen.

Xcode 6.4 ist 5.850.060.112 bytes groß, XcodeGhost 5.850.917.234 bytes.

Eine Überprüfung mittels codesign -vvv ergibt beim Original: "valid on disk" und "satisfies its Designated Requirement". Beim Ghost kommt heraus: "a sealed resource is missing or invalid". Außerdem wird ausgegeben, daß diverse Dateien hinzugefügt wurden. Es stand jeweils "file added: /Volumes/Xcode 1/Xcode.app/Contents/Developer/Platforms" davor:

In "iPhoneOS.platform/Developer/SDKs/Librarys/" jeweils:
Frameworks/CoreServices.framework/CoreServices
PrivateFrameworks/IDEBundleInjection.framework/_CodeSignature/CodeResources
PrivateFrameworks/IDEBundleInjection.framework/IDEBundleInjection
PrivateFrameworks/IDEBundleInjection.framework/Info.plist
PrivateFrameworks/IDEBundleInjection.framework/version.plist

In "iPhoneSimulator.platform/Developer/SDKs/Library/" jeweils:
iPhoneSimulator.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreServices
iPhoneSimulator.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework/_CodeSignature/CodeResources
iPhoneSimulator.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework/IDEBundleInjection
iPhoneSimulator.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework/Info.plist
iPhoneSimulator.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework/version.plist

In "MacOSX.platform/Developer/SDKs/Library/Frameworks":
CoreServices.framework/CoreServices

Und in "MacOSX.platform/Developer/SDKs/Library/PrivateFrameworks/" jeweils:
IDEBundleInjection.framework/IDEBundleInjection
IDEBundleInjection.framework/Resources
IDEBundleInjection.framework/Versions/A/_CodeSignature/CodeResources
IDEBundleInjection.framework/Versions/A/IDEBundleInjection
IDEBundleInjection.framework/Versions/A/Resources/Info.plist
IDEBundleInjection.framework/Versions/A/Resources/version.plist
IDEBundleInjection.framework/Versions/Current

Hätte man also ganz einfach prüfen und die Manipulation bemerken können als Entwickler, der sich aus Drittquelle den Xcode zieht. Hätte, hätte, Fahrradkette. Hat aber wohl keiner.

Watte, watte! Datt kommt noch viel geiler: Manuelle Prüfung war wohl zuviel. Was ist denn, wenn ich es einfach normal starte? Ich ziehe den kompromittierten Xcode brav in /Applications und doppelklicke ihn. Dann kommt das übliche "Xcode wird überprüft …"

Und dann wird Xcode nicht gestartet, sondern – Achtung jetzt kommt's, wahre Geschichte – es kommt ein Warnhinweis: "Xcode.app ist beschädigt und kann nicht geöffnet werden. Du solltest es in den Papierkorb werfen." Hammer, ne? Alles super bei Apple. Aber diese Volldeppen haben wohl auf "Cancel" gedrückt und Xcode doch geöffnet.

Ganz ehrlich: Wie blöd muß man sein? Wieviele Warnblinkanlagen sollen denn noch angehen? Ich bekam diese Version erst nicht zum Laufen. Nachdem ich dann in den Sicherheitseinstellungen von OS X auf "App Installation erlauben für Apps aus Download von überall" umgestellt hatte, ging es. Aber auch dann erst nach einer weiteren Warnung, daß dies eine App wäre, die von da und dort käme und ob ich die wirklich öffnen will.

So Kinder, bitte. Noch eine Warnung von OS X. Und nun erst konnte ich den bösen XcodeGhost öffnen. Ich habe keinerlei Verständnis für Leute, die auch nach der zweiten Warnung nichts läuten hören. Echt nicht.

Apple beschreibt jetzt auch noch mal explizit, wie man Xcode überprüfen kann. Außerdem führt Apple aus, daß Xcode signiert ist und standardmäßig automatisch auf Integrität überprüft wird vom System, es sei denn, man lädt es von irgendwo und hat Gatekeeper ausgeschaltet. Das deckt sich mit meinem Test oben.

Als nächstes schaue ich mir die Serverkommunikation einer damit erstellten App an.

Ich habe auf einem Testgerät XcodeGhost verwendet und eine Test-App damit erstellt. Ich habe sie dann ohne Debugging laufen lassen und die Kommunikation mit dem CharlesProxy überwacht. Ich konnte bislang keine Requests feststellen. Eigentlich müßte da etwas zu sehen sein. Momentan kann ich mir noch nicht erklären, warum keine Serveranfragen auftauchen.

Schadfunktion beim Benutzer

Läuft nun eine der infizierten Apps auf dem Apple-Gerät, dann werden einige Daten an einen Kommando-Server geschickt: Aktuelle Zeit, App-Name, Bundle-Id, Geräte-Name und -Typ, System-Sprache und -Land, Geräte-ID und Netzwerktyp. Geschickt werden die Infos zum Beispiel an http://init.crash-analytics[.]com oder http://init.icloud-diagnostics[.]com oder an http://init.icloud-analysis[.]com.

Die Kommandoserver der Angreifer empfangen diese Daten als Input und geben dem Malware-Code in den Apps abhängig davon als Antwort individuelle Kommandos, was die App tun soll:

• Einen Fake-Dialog anzeigen: Dabei werden diese Textfelder vom Server vorgebeben (modern per JSON): Titel, Haupttext, AppID, Abbrechen-Button-Text, OK-Button-Text. Der User sieht einen neuen Dialog in der ihm vertrauten App und wird eventuell nach Login und Paßwort für iCloud oder sein Online-Banking oder ähnlichem gefragt, je nachdem, was für eine App das gerade ist.
• Eine URL öffnen: Dabei kann es sich um eine externe URL handeln oder um eine bekannte lokale URL, die eine andere App als URL-Schema für App-zu-App-Kommunikation verwendet. Damit können sie probieren, von nicht-infizierten anderen Apps weitere Daten zu bekommen.
• Die Zwischenablage benutzen: In der Zwischenablage (Kopieren und Einfügen) befinden sich manchmal sensible Daten wie Paßworte.

Da XcodeGhost weiß, in welcher App er sich grad befindet, kann er die jeweils am besten geeignete Aktion auswählen, um nützliche Daten abzugreifen.

Aufgefallen ist diese Netzwerk-Kommunikation unter anderem einigen Entwicklern, weil ihre App, die gar kein Netzwerk benutzen sollte, plötzlich Dialoge für ein iCloud-Login anzeigte. Offenbar ist das primäre Ziel, Login-Daten für iCloud abzugreifen. Das geht nicht nur über die gefälschten Dialogboxen, sondern wird von den infizierten Apps auch durch Zugriff auf die Zwischenablage probiert, in der Hoffnung, daß der User einen Paßwort-Manager mit Kopieren und Einfügen benutzt, zum Beispiel 1Password. Und als dritte Methode klingt sich der Schadcode in der jeweiligen App auch in ihre etwaige Kommunikation über URL-Schema ein.

Client Source Code

Auf GitHub hat am 18.9.2015 augenscheinlich der Autor von XcodeGhost den Quellcode gepostet, der in die Apps eingeschleust wird. In der Beschreibung entschuldigt er sich mehr oder weniger auf Chinesisch und sagt es wäre ein privates Experiment gewesen ohne schädliches Verhalten. Er bestätigt, welche Daten gelesen würden. Ferner sei die Werbefunktion von Beginn bis zum Runterfahren des Servers nicht benutzt worden. Er habe die Sachen vom Server genommen und alle Daten gelöscht und es würde niemand beeinträchtigt worden sein. Der XcodeGhost wäre ein schlechtes Experminent gewesen, aber nun nur noch komplett toter Code. Private Daten wären nie erhoben worden, App-Nutzung wäre auch nicht beeinflußt worden, der Code wäre jetzt tot. Dann kommt noch eine Entschuldigung und er wünscht uns ein schönes Wochenende.

Da hat wohl jemand kalte Füße bekommen und stellt es als Dummen-Jungen-Streich dar. Mich stört an der Darstellung, daß er nach Erfahrung betroffener Entwickler sehr wohl die Dialog-Anzeige-Funktion benutzt hat. Die Frage ist, wieviel man dem Text glauben kann, der dort als ReadMe steht.

Eine Klasse sammelt tatsächlich die allgemeinen Daten ein vom Gerät wie oben erwähnt. Das sind keine wirklich privaten Daten, sondern Sachen, die jede andere App auch verwendet.

Die zweite Klasse sendet diese Daten periodisch und abhängig vom App-Lebenszyklus an http://init.icloud-analysis.com. Die empfangenen und gesendeten Daten sind mit DES verschlüsseltes JSON mit einer Schlüssellänge von 256. iOS-Systeme unter 6.0 werden ignoriert. Wenn ein Debugger läuft, wird ebenfalls nichts gesendet.

Der Server kann anweisen, daß ein SKStoreProductViewController angezeigt wird, den es erst seit iOS 6 gibt. Das erklärt die Abfrage weiter oben. Offenbar möchte er also für andere Apps in den Apps werben, da eine AppID übergeben wird als iTunesItemIdentifier. Ein normaler Mechanismus.

Die Alerts, die angezeigt werden, haben nur die Standard-Buttons und keine Eingabefelder. Die in manchen Berichten auftauchenden iCloud-Logins müßten demnach eine andere Ursache haben.

Die empfangenen Daten können optional das Zeitinterval für die nächste Kommunikation verlängern.

Ist eine AppID enthalten, dann wird die Store-Promotion-Funktion aufgerufen damit.

Ist eine configURL enthalten, dann wird die übergebene URL geöffnet und damit eine andere App angesprochen, falls es eine auf dem Gerät gibt, die sich für das ebenfalls angegebene Schema registriert hat.

Wenn das der echte Client-Source-Code ist, dann sehe ich dort keine Möglichkeit, Login-Daten abzugreifen damit, denn im Code werden für den Dialog nur Titel, Text, Cancel- und Ok-Button verwendet, aber keine Eingabefelder. Es werden auch keine Eingabefelder manuell hinzugefügt. Es werden auch keine Eingabefelder über UIAlertViewStyle hinzugefügt. Insbesondere wird im Code kein UIAlertViewStyleSecureTextInput, kein UIAlertViewStylePlainTextInput und kein UIAlertViewStyleLoginAndPasswordInput verwendet.

Apple sagt dazu: We’re not aware of personally identifiable customer data being impacted and the code also did not have the ability to request customer credentials to gain iCloud and other service passwords." Apple sieht also auch keinen Hinweis darauf, daß private Kundendaten betroffen sind. Außerdem sieht Apple im Code auch keine Möglichkeit, vom Benutzer Login-Daten abzufragen.

Betroffene Apps

Fox-IT, eine niederländische Sicherheitsfirma, hat den Netzwerkverkehr zu den Kontrollservern untersucht, und festgestellt, daß folgenden Apps betroffen sind: Mercury, WinZip, Musical.ly, PDFReader, guaji_gangtai en, Perfect365, 网易云音乐, PDFReader Free, WhiteTile, IHexin, WinZip Standard, MoreLikers2, CamScanner Lite, MobileTicket, iVMS-4500, OPlayer Lite, QYER, golfsense, 同花顺, ting, installer, 下厨房, golfsensehd, Wallpapers10000, CSMBP-AppStore, 礼包助手, MSL108, ChinaUnicom3.x, TinyDeal.com, snapgrab copy, iOBD2, PocketScanner, CuteCUT, AmHexinForPad, SuperJewelsQuest2, air2, InstaFollower, CamScanner Pro, baba, WeLoop, DataMonitor, 爱推, MSL070, nice dev, immtdchs, OPlayer, FlappyCircle, 高德地图, BiaoQingBao, SaveSnap, WeChat, Guitar Master, jin, WinZip Sector, Quick Save, CamCard. Außerdem Didi Chuxing, Railway 12306, China Unicom Mobile Office, Tonghuashun.

Dann sollen auch noch diese infiziert sein laut Palo Alto Networks: 网易云音乐 2.8.3, 微信 6.2.5, 讯飞输入法 5.1.1463, 滴滴出行 4.0.0.6-4.0.0.0, 滴滴打车 3.9.7.1 – 3.9.7, 铁路12306 4.5, 下厨房 4.3.2, 51卡保险箱 5.0.1, 中信银行动卡空间 3.3.12, 中国联通手机营业厅 3.2, 高德地图 7.3.8, 简书 2.9.1, 开眼 1.8.0, Lifesmart 1.0.44, 网易公开课 4.2.8, 马拉马拉 1.1.0, 药给力 1.12.1, 喜马拉雅 4.3.8, 口袋记账 1.6.0, 同花顺 9.60.01, 快速问医生 7.73, 懒人周末, 微博相机, 豆瓣阅读, CamScanner, CamCard, SegmentFault 2.8, 炒股公开课, 股市热点, 新三板, 滴滴司机, OPlayer 2.1.05, 电话归属地助手 3.6.5, 愤怒的小鸟2 2.1.1, 夫妻床头话 1.2, 穷游 6.6.6, 我叫MT 5.0.1, 我叫MT 2 1.10.5, 自由之战 1.1.0, NetEase Cloud Music App,

Apple hat nun eine offizielle Liste betroffener Apps.

Palo Alto Networks arbeitet bezüglich dieser infizierten Apps mit Apple zusammen.

Alle diese Apps werden offenbar von Leuten gebaut, die es nicht für nötig halten, sich Xcode bei Apple direkt herunterzuladen. Wenn Du eine dieser Apps verwendest, dann hoffe ich, daß Du ihr nicht Deine iCloud-Daten gegeben hast. In dem Fall ist dringend geraten, die iCloud-Zugangsdaten zu ändern. Ansonsten landen Deine Photos und alles andere aus der iCloud wie bei TheFappening möglicherweise bei interessierten unbefugten Leuten. Ich würde mein iCloud-Paßwort auf jeden Fall ändern, wenn ich eine dieser Apps benutze. Außerdem die App erstmal löschen und ein Update abwarten dafür.

Es sind noch weitere Apps betroffen, die ich namentlich nicht kenne. Potentiell kann es jede App sein, die von chinesischen Entwicklern stammt.

Apple hat am Sonntag, 20.09.2015, gegenüber Reuters bestätigt, daß sie dabei sind, die betroffenen Apps im Store zu beseitigen, und bei den Entwicklern dafür zu sorgen, daß sie die Apps mit dem korrekten Xcode neu bauen.

Schlußgedanken

Wenn man betrachtet, daß WeChat hunderte Millionen User haben soll, dann ist das eine Katastrophe. Der Kontrollserver kann jeder App-Installation gesagt haben, sie solle einen konfigurierbaren Fake-Dialog zeigen, zum Beispiel für iCloud, oder die Zwischenablage auslesen / ändern oder in die URL-Schema-Kommunikation der App eingreifen, mit der Apps sich untereinander Nachrichten schicken können. Diese Funktionen sind nachgewiesenermaßen in allen betroffenen Apps möglich.

Es kann also millionenfach versucht worden sein, Login-Daten abzugreifen. Die betroffenen Apps sind Banking-Apps, Apps für Instant-Messenger, Mobile Carrier Apps, Aktien-Handel-Apps, SMS-Apps und Spiele. Apps, denen die User möglicherweise schon seit vielen Versionen vertrauen.

Sollte der Zugriff auf ein iCloud-Konto doch irgendwie in falsche Hände gelangt sein, dann merkt man das spätetens am Inhalt der Emails mit "Ihre Apple-ID wurde verwendet, um …". Je nachdem, ob das ein eigenes Gerät war oder nicht, kann man sich dann Sorgen machen ;-) Außerdem kann man idealerweise die zweistufige Bestätigung aktiviern. Die verhindert Account-Zugriff auch dann, wenn der Angreifer das Paßwort kennt.

Laut Apple: Es hat sich herausgestellt, daß zwar diverse Apps betroffen waren, aber möglicherweise doch keine schädlichen Aktionen stattgefunden haben auf den User-Geräten. Apple hat die Apps entfernt und blockiert das Hochladen damit infizierter Apps. Für China-Entwickler will Apple die Downloads von Xcode verbessern, so daß sie nicht auf andere Quellen ausweichen.

Apple könnte dafür sorgen, daß bei jedem Start von Xcode die Signatur auf Gültigkeit geprüft wird und Xcode nicht gestartet werden kann, wenn es durch die Prüfung fällt. Damit könnte ein weiterer solcher Fall verhindert werden. Bei iOS werden ja auch nur Apps mit gültiger passender Signatur gestartet. Es ginge also. Korrektur: Nach meinem Test oben mit einem Sample der XcodeGhost-Version zeigte sich, daß die Prüfung stattfindet und den Start des bösen Xcode verhindert, bis man das System umkonfiguriert.

Steve Jobs hatte damals bestätigt, daß in iOS eine Funktion enthalten ist, die es Apple erlaubt, Programme zu löschen, falls eines, das beispielsweise User-Daten stiehlt, versehentlich in den App Store kommen sollte. Jetzt wäre ein guter Zeitpunkt, diesen "Kill-Switch" einzusetzen. Na, dann los:

---