WireLurker, Machook, die N00bs und ich
Was mußten wir in diesen Tagen nicht alles lesen und ertragen. Die News, die waren voll mit Müll, ich wünschte mir, sie wären still. Doch mußten sie viel Werbung machen und ließen es so richtig krachen. Die Fakten falsch, der Zeilen viele, es war nichts dabei, was mir gefiele. Drum dacht' ich mir: Das kann nicht sein, da bringen wir mal Ordnung rein.
Informations-Quellen
Wenn man über diesen Schädling schreiben möchte, sollte man nicht vom Gemüselaster runtergefallen und direkt auf einem Redaktions-Stuhl gelandet sein. Vielmehr sollte folgendes beachtet werden:
- Viel wäre schon gewonnen gewesen, wenn die News-Leute den vollständigen Bericht gelesen hätten anstelle der kurzen Presse-Mitteilung.
- Wenn man eine Kooperation mit virustotal hat, kann man in der Regel den Schädling auch selbst untersuchen.
- Weiter ist es von Vorteil, wenn man OS X- und iOS-Entwickler ist, sich mit den Sicherheits-Funktionen der Systeme auskennt, versteht, was Jailbreaks anrichten, und Apples Enterprise Deployment für iOS schon jahrelang beruflich eingesetzt hat.
Das ist natürlich alles ein bißchen viel verlangt und darum sind so gut wie alle Nachrichten über diesen Schädling voreilig, Hören-Sagen und ohne ausreichende Recherche und nötiges Fachwissen entstanden. Qualifizierte Leute hingegen sind davon genervt.
Infektions-Start am Mac
Das ultimative Ziel dieser Malware ist anscheinend, Geräte-Infos und User-Daten zum Server rauszuschicken, sowohl von Macs als auch von iOS-Geräten, und Manipulation von Webseiten in iOS-Apps, möglicherweise um an gefälschter Werbung Geld zu verdienen.
Wichtig hierbei ist, daß iOS-Geräte mit Jailbreak von der Malware anders behandelt werden, weil ein Jailbreak alle Sicherheits-Features von iOS beseitigt und der Schädling damit wesentlich mehr anrichten kann.
Die initiale Infektion findet durch den Mac-User selbst statt, indem er eine beliebige mit Malware-Funktionen erweiterte bekannte Mac-App runterlädt und startet. Diese Trojanischen Pferde werden jedoch seit dem 6. November 2014 am Starten gehindert, weil Apple die XProtect-Liste in OS X bereits aktualisiert hat. Ich habe das spontan mit meiner WallsOfTroy.app gesehen.
Laut dieser Untersuchung erbittet die Trojaner-App nach ihrem Start System-Rechte vom User (Requests system administrator privileges), um den Rechner weiter infizieren zu können.
An den mir dank virustotal vorliegenden Malware-Samples kann ich sehen, daß sie unter anderem in die Verzeichnisse /usr/bin/ und /usr/local/ schreiben möchte, die beide Roote-Rechte benötigen. Da die Malware diese Root-Rechte erfragt, kann ich ausschließen, daß den Malware-Autoren der aktuelle RootPipe-Bug bekannt ist, der eine Eskalation aus der Admin-Gruppe hoch zu Root ermöglichen soll. Spekulationen mancher News-Seite, RootPipe würde hier eine Rolle spielen, können wir also als Humbug abtun.
Nachladen
Vorausgesetzt man hat dem Trojanischen Pferd Root-Rechte eingeräumt, wird einmal pro Stunde versucht, die Malware zu aktualisieren. Das Binary, was für das Update zuständig ist, verwendet http://www.comeinbaby.com/mac/getversion.php?sn=%@ als Adresse, wobei als Parameter am Ende die Serien-Nummer des Macs eingetragen wird.
Interessanterweise ist diese Adresse jedoch nicht erreichbar. Laut Doku der Analyse von Palo Alto Networks hat sie jedoch einmal funktioniert.
Das Nachladen umfaßt laut Palo Alto Networks nicht nur Software für den Brückenkopf, die Mac-Malware, sondern auch Apps für iOS.
Infektion von iOS
Die Brückenkopf-Software auf OS X verwendet libimobiledevice, eine Cross-Plattform-Bibliothek, um Daten und Apps auf iOS-Geräten zu verwalten so wie man es sonst mit iTunes macht.
Die Infektion funktioniert über USB, weil dieser spezielle Mac, mit dem iOS immer synchronisiert wird, am iOS-Gerät als vertrauenswürdig gespeichert ist. Ein iOS-Gerät fragt den User, ob es einem jeweils unbekannten Gerät am USB vertrauen soll. Die Malware nutzt den Umstand, daß dem infizierten Mac bereits vertraut wird.
Standard iOS
Die einzige Chance, eigenen Code auf einem iOS-Gerät ohne Jailbreak zum Laufen zu bringen, besteht für die Malware darin, Apps mit einem gültigen Enterprise Deployment Zertifkat zu installieren. Apple hat jedoch die verwendeten Enterprise Deployment Zertifikate ungültig gemacht, so daß jede App, die davon abhängig ist, nicht mehr auf iOS gestartet wird. Damit sind normale iOS-Geräte wieder in Sicherheit.
In den News waren die Redakteure sowohl davon überrascht, daß es über ein Enterprise Deployment Zertifkat läuft, als auch davon, daß der User beim ersten Aufruf einer solchen Enterprise-App explizit um seine Erlaubnis gebeten wird inklusive Hinweis auf den Ersteller der Enterprise-App. Wenn man selbst jahrelang solche Apps in seinem Job erstellt und verteilt hat, dann wundert einen das allerdings nicht. Es ist eher logisch und normal.
iOS führt nur passend und gültig signierten Code aus. Sonst nichts. Alle Apps im Store tragen Apples Signatur. Firmen dürfen intern Apps beliebig verteilen mit Hilfe von Enterprise Deployment Zertifikaten, die Apple ihnen gibt. Wird das Zertifikat ungültig gemacht oder läuft ab, dann sind alle Apps, die damit signiert wurden nicht mehr ausführbar.
Entwickler haben noch andere Möglichkeiten, Apps auf iOS-Geräte zu bringen, aber die sind nicht allgemein auf beliebige Geräte anwendbar, weil die Geräte explizit in dem verwendeten Provisioning Profile einzeln gelistet werden. Das Provisioning Profile wird von Apple signiert und kann vom Entwickler über Xcode oder manuell über die Dev-Webseite bezogen werden. Eine Manipulation würde das Provisioning Profile ungültig machen. Dieses Provisioning Profile paßt ausschließlich zu Apps, die von demselben Entwickler signiert werden. Damit ist so eine Methode für Malware nicht nützlich, zumal die mögliche Gesamtanzahl der Geräte-Ids auch noch stark limitiert ist, auf hundert verschiedene pro Jahr. Malware will ja allgemein und automatisch infizieren. Physikalischer Zugriff mit händischer individueller Installation auf einem eigenen bei Apple registriertem Entwickler-Gerät ist in der Regel keine Option.
Beim Versuch der News, Enterprise Provisioning Profiles nachträglich zu erklären, fiel mir dann auf, daß die News auf Provisioning Profile für Remote Notifications am Mac verlinken. Das ist dann doch etwas anderes, aber so etwas fällt dem Laien halt nicht auf. Es gibt Provisioning Profile für sehr viele unterschiedliche Dinge in der Apple-Programmierung.
In einer News heißt es sogar:
… ein Angreifer könne also die Signatur aus der App löschen, diese manipulieren und anschließend einfach mit einem eigenen Zertifikat wieder signieren. Eine derartige Änderung bleibe vom Nutzer unbemerkt: Die manipulierte App laufe genauso wie die Original-Software.
Das ist nicht ganz richtig und zeigt wieder das mangelhafte Verständnis: iOS führt auf beliebigen Geräten nur Code aus, der entweder von Apple signiert ist, oder ein gültiges Enterprise Zertifikat trägt. Alle Apps aus dem Store werden von Apple signiert. Was hier gemeint ist, dürfte korrekt heißen: Wenn eine App manipuliert wird und man dabei die Signatur beseitigt und sie dann mit einem gültigen Enterprise-Zertifikat versieht, dann läuft sie wieder. Aber: Der User bekommt den Hinweis beim nächsten App-Aufruf, ob er diese App überhaupt noch starten will, weil sie von XY kommt. Und das fällt dem User auf, denn solche Meldungen gab es bei der jeweiligen App im Originalzustand ja vorher nie. Eine Einzel-Installation als Entwickler-Gerät kommt für Malware wie die hier diskutierte technisch nicht in Frage.
Widerrechtlich benutzte Enterprise-Zertifikate und damit signierte Apps haben keine Chance, lange zu überleben, weil Apple sie jederzeit zentral deaktivieren kann.
Eine Manipulation der App erfordert zudem erstmal ihre Entschlüsselung. Da sie nur zur Laufzeit im Hauptspeicher entschlüsselt vorliegt, muß man sie dort in diesem Zustand kopieren, was nur auf einem Jailbreak-Gerät möglich ist, beispielsweise mit Clutch.
Jailbreaked iOS
Schlimmer sieht es bei Geräten aus, die einem Jailbreak unterzogen wurden, wovon ich immer abrate, da damit wichtige Sicherheitsfunktionen ausgeschaltet und Malware unnötig Freiraum eröffnet wird. In dem Fall kopiert die Malware installierte iOS-Apps erstmal auf den Mac, infiziert sie dort und kopiert sie dann wieder zurück auf iOS. Das funktioniert nur mit Jailbreak, denn der Code trägt keine gültige Apple-Signatur und wäre ohne Jailbreak nicht ausführbar. Durch den Jailbreak sind dem System jedoch Zertifikate, gültig oder ungültig oder gar nicht vorhanden, völlig egal. Außerdem installiert die Malware auf solchen Jailbreak-Geräten noch eine Version der sfbase.dylib, die mit MobileSubstrate, einem Jailbreak-Framework, zusammenarbeitet, um iOS-Systemfunktionen und Apps zur Laufzeit im Speicher zu verändern.
Wenn ich mir die sfbase.dylib anschaue, finde ich darin unter anderem dies:
data 0x23d40 (struct class_ro_t *) flags 0x10 instanceStart 4 instanceSize 4 ivarLayout 0x0 name 0x200a5 mydUIWebViewHook baseMethods 0x23d20 (struct method_list_t *) entsize 12 count 2 name 0x1f223 webView:didFinishLoadForFrame: types 0x20164 v16@0:4@8@12 imp 0x11ca5 name 0x1f242 hook_webView:didFinishLoadForFrame: types 0x20164 v16@0:4@8@12 imp 0x11ca9 baseProtocols 0x0 ivars 0x0 weakIvarLayout 0x0 baseProperties 0x0
Offenbar werden geladene Webseiten manipuliert, indem die passenden Funktionen abgefangen werden. Daher und aufgrund der Verwendung des advertisingIdentifier und des AdSupport.framework rührt meine Vermutung, daß es um irgendwelche Web-Werbung und Einnahmen daraus gehen könnte.
Weitere interessante Stellen, die zeigen, was die Malware-Lib so treibt, sind:
MobilePhone MobileSMS MobileSafari MobileStorageMounter /Library/MobileSubstrate/DynamicLibraries/sfbase.dylib yyyy-MM-dd /tmp/uupdate mv -f %@ %@ rm -rf %@ http://www.comeinbaby.com/app/getversion.php?v=%@&adid=%@ result version www.comeinbaby.com /tmp/ulogs /tmp/%@_%@.txt /tmp/sms.db /tmp/AddressBook.sqlitedb upload error %@ /User/Library/SMS/sms.db select distinct chat_identifier from chat where service_name='iMessage' /User/Library/AddressBook/AddressBook.sqlitedb select m.value sphone,p.first , p.last from ABMultiValue m ,ABPerson p where m.record_id=p.rowId advertisingIdentifier UUIDString getSMSUser getPhoneUser
Sie fummelt also anscheinend an der Telephone-Funktion herum, an SMS, an Safari, an den Datenbanken für das Adreßbuch und den SMS sowie den iMessages. Außerdem finden sich Hinweise auf Update-Funktion und das Hochladen der gefundenen Daten.
Software-Qualität
Die Mac-Software verwendet libcrypto, eine schon seit Jahren auf OS X durch bessere Lösungen abgelöste Library. Außerdem wird DES-Verschlüsselung verwendet, die schwach und veraltet ist.
Das globalupdate Mac-Binary verwendet MKNetworkKit, das für OS X noch nicht voll getestet ist. Dieses Framework ist für Anfänger, die Probleme damit haben, selbst eine Queue-basierte Netzwerk-Kommunikation zu programmieren. Dabei ist das gar nicht so schwierig. Auch die Verwendung von NSURLConnection finde ich lahm, sollte man doch NSURLSession verwenden.
Mit Liebe erstellte Software sieht für mich anders aus. Die hier sieht mir doch eher nach quick-and-dirty aus.
Fazit
Diese Malware fängt man sich nicht ein, sondern die holt man sich, indem man illegale Kopien von Mac-Apps installiert. Das muß nicht zwangsläufig auf fernöstliche Quellen beschränkt sein. Die dann mögliche Folge-Infektion von iOS erfolgt anschließend über USB, weil das iOS-Gerät dem Mac schon vorher vertraute. Auf Jailbreak-Geräten fällt die Infektion nicht so schnell auf, bei normalem iOS wird man ausdrücklich auf die außergewöhnliche Software hingewiesen.
Apple hat sowohl die infizierte Mac-Software per XProtect-Update deaktiviert als auch betroffene iOS-Apps durch Invalidierung der verwendeten Provisioning Profile aus dem Verkehr gezogen.
Nicht helfen kann man Jailbreak-Usern, da deren Geräte anders und vor allem tiefer infiziert werden und Code-Signierung und Zertifikate durch den Jailbreak keine Wirkung mehr haben. Hier kann man nur zur sauberen Neu-Installation von iOS raten. Ohne Jailbreak.
In Summe kann man sehen, daß Apples Schutzmaßnahmen ausreichend, schnell und wirkungsvoll waren, um vorhandene Infektionen und zukünftige Installations-Versuche dieser Trojanischen Pferde zu behandeln. Hält man sich von illegalen Kopien fern, ist man sogar völlig sicher vor dieser Schädlings-Sorte. Aus irgendeinem Grund ist der Command-And-Control-Server dieser Malware auch nicht mehr so richtig verfügbar.
Nur mal zum Vergleich: 2013 steckte in 7000 geknackten Android Apps der Android.Troj.mdk Trojaner. 1 Million Geräte waren Teil des damit erstellten Botnetzes. Betroffen war auch hier hauptsächlich Fernost.
Aber die News-Seiten hatten ihren Spaß, das ist das Wichtigste. Und ich habe mir einen Tag lang Malware angeschaut, was gibt es schöneres?
Link: osx.macmark.de/blog/osx_blog_2014-11-a.php