Masque Attack aka Enterprise Deployment

Keine drei Tage sind vergangen und schon wieder scheucht eine Sicherheits-Firma, diesmal ist es FireEye, iOS-User mit einer Schreckensmeldung auf, die sich bei näherem Hinsehen als normales Feature herausstellen, das ich selbst schon viele Jahre als iOS-Entwickler benutze: Enterprise Deployment. FireEye nennt es hingegen: Masque Attack: All Your iOS Apps Belong to Us.

Ich erkläre erstmal, worum es hier technisch geht. Und danach dann, worin FireEye das Problem sieht.

iOS Apps normal laufen lassen

iOS läßt nur passend signierte Apps laufen. Ist das Zertifikat nicht ok, geht gar nichts. Entwickler können auf ihren automatisch von Xcode bei Apple registrierten Geräten ihre Apps direkt laufen lassen.

Entwickler können ihre Apps auch Ad-Hoc verteilen an ebenfalls registrierte Test-Geräte, was allerdings auf hundert Geräte pro Jahr beschränkt ist. Die Provisioning Profiles werden von Apple ausgestellt und enthalten die Geräte-Nummern, so daß iOS die App nur ausführt, wenn das Gerät im Provisioning Profile gelistet ist und die App vom selben Entwickler signiert wurde.

Dann gibt es noch den App Store, seit iOS 8 auch mit integriertem internem Alpha-Test und Beta-Test. Apps, die aus dem App Store kommen, tragen Apples Signatur und werden von iOS akzeptiert. Die Entwickler laden die Apps mit ihrem Apple-Zertifikat hoch, um den Ursprung nachzuweisen. Apple prüft die App und gibt ihr die Apple-Signatur.

Enterprise Deployment

Da Firmen gerne eigene iOS-Apps intern erstellen und verteilen möchten, gibt es seit vielen Jahren eine Möglichkeit, firmen-interne App Stores zu betreiben. Ein App Store ist eigentlich nur ein Webserver, der App-Archive zum Download anbietet. Apples Store ist das auch. Für solche Firmen stellt Apple das Enterprise Deployment zur Verfügung mit entsprechenden Zertifikaten, um die Apps damit zu signieren. Aus eigener Erfahrung weiß ich, daß man nicht einfach so in dieses Enterprise Programm aufgenommen wird, denn Apple will einige offizielle Dokumente über die Firma sehen.

Die Zertifikate erlauben es der Firma dann, ihre Apps so zu signieren, daß iOS sie auch installiert und laufen läßt. Die Installation geht über einen Link, den man per Email verschicken kann, oder den man auf einem Webserver als App Store zur Verfügung stellt. Der Link verweist auf eine Property-List, die Informationen über die zu installierende App enthält inklusive einer URL zum App-Archiv.

Ruft der User den Link zu der Property-List auf, dann zeigt iOS ihm die Infos zu der App und fragt ihn, ob er diese App installieren möchte. Bejaht er die Abfrage, werden das Enterprise-Zertifikat und die App auf seinem Gerät installiert.

App Updates

Was für den User wie eine App auf seinem Gerät aussieht, ist ein Verzeichnis, das sowohl die App als auch daneben liegend seine User-Daten enthält. Wird eine App aktualisiert, dann wird die App überschrieben, die User-Daten jedoch behalten. Löscht der User die App, dann wird das ganze Verzeichnis weggeworfen, also die App und die User-Daten.

Eine App wird von iOS als Update für eine bereits installierte App erkannt, wenn ihr Bundle-Identifier übereinstimmt. Für iTunes wäre das zum Beispiel so etwas wie "com.apple.itunes".

Im App Store kontrolliert Apple automatisiert, daß der Entwickler nur Apps hochladen kann, die einen Bundle-Identifier haben, der auf ihn registriert ist. Ich könnte also erst gar keine App mit "com.apple.itunes" registrieren, geschweige denn hochladen, weil der Identifier bereits für jemand anderen vergeben ist.

Firmen mit Enterprise Deployment haben ihrerseits die Hohheit über ihren eigenen App Store und können und müssen die Identifier selbst organisieren. Damit könnten sie Apps anderer Dritthersteller in ihrer Firma überschreiben mit eigenen Updates.

Es ist jedoch strengstens untersagt, Enterprise-Apps außerhalb der eigenen Firma zu verteilen. Verstößt man dagegen, fliegt man aus dem Programm raus und Apple macht die Zertifikate ungültig und damit sämtliche Apps der Firma weltweit unfähig, jemals wieder zu laufen.

Angriffs-Szenario

Der User muß dazu gebracht werden, einen Installieren-Link zu benutzen. Danach muß er im Bestätigungs-Dialog dem Installieren des vom System als nicht vertrauenswürdig vorgestellten (Enterprise-) Entwickler-Zertifikates explizit zustimmen: Nicht vertrauenswürdiger Entwickler! Wollen Sie dem Entwickler XY erlauben, Apps auf ihrem Gerät laufen zu lassen? Es sind also zwei bewußte Aktionen des Benutzers nötig, um Enterprise-Apps zu installieren.

Und so könnte man das für böse Zwecke laut FireEye mißbrauchen: Man bietet eine App an, die ABC heißt, aber tatsächlich einen Identifier einer bekannten anderen App, die der User schon installiert hat, verwendet. Damit würde die vorhandene App BLAH ersetzt (aktualisiert) und ihre Daten und Zugriffsrechte blieben erhalten. Der User würde sich wundern, daß er die App mit dem Namen ABC, die er grad geladen hat, gar nicht auf seinem Gerät findet. Er würde die App BLAH wieder starten, aber das wäre ab dann die App ABC. Und die schickt dann die Daten, die sie von BLAH geerbt hat durch das Update, an den bösen Server. Sollte die neue App jedoch die alte nicht gut genug imitieren, würde das dem User doch auffallen, allerdings zu spät dann, weil die Daten schon rausgegangen sind.

Der User müßte also erstmal sehr aktiv mithelfen und bewußt Apps von jenseits des App Stores her installieren und dabei die iOS-Warnung ignorieren. Außerdem wäre das Zeitfenster für den Angreifer recht klein sein, denn Apple wird mit einem einzigen Schalter sämtliche Apps des Enterprise-Entwicklers aus dem Verkehr ziehen.

Wer jetzt immer noch Grund für eine Panik sieht und das für eine Major iOS insecurity! hält, wie beispielsweise The Safe Mac, den ich ansonsten sehr schätze, der aber kein iOS-Entwickler wie ich ist, der möge sich meinetwegen Sorgen machen. Denn wie man am Beispiel WireLurker / Machook sehen konnte, zieht Apple solche Späßchen recht schnell aus dem Verkehr.

---