heise Security

iOS 6 stopft Konfigurationsloch

Ronald Eikenberg

Das jüngste iOS-Update stopft eine seit Jahren bekannte Schwachstelle, die es in sich hat.


Das iPhone-Konfigurationprogramm ist ein mächtiges Werkzeug, das in den falschen Händen auch zur Waffe werden kann.
Kaum etwas deutet auf der Apple-Webseite auf die Existenz des sogenannten iPhone-Konfigurationsprogramms [1] hin. Man findet es nur über den Support-Bereich für Firmenkunden. Es erlaubt das Verteilen definierter Systemeinstellungen an viele iOS-Geräte. So kann etwa ein Unternehmen nach der Anschaffung neuer Diensthandys alle Geräte zeitsparend mit den WLAN-Einstellungen fürs Firmennetz versorgen oder aber auch bestimmte Sicherheitsrichtlinien, wie eine Mindestlänge das Passcodes, durchsetzen.

Freilich lässt sich mit einem solchen Profil auch viel Schindluder treiben. iOS prüft daher, ob die exportierten Konfigrationsdateien (.mobileconfig) mit dem Zertifikat eines vertrauenswürdigen Herausgebers signiert wurde. In Firmenumgebungen können Mitarbeiter so sicherstellen, dass die bevorstehenden Eingriffe ins System tatsächlich von der IT-Abteilung abgesegnet wurden. War die Zertifikatsprüfung erfolgreich, signalisiert iOS dies mit einem Häkchen und dem Schriftzug "Überprüft" in dicken, grünen Lettern.

Die vertrauenswürdige Optik täuscht jedoch: Wie heise Security bei den Recherchen zu der c't-Artikelstrecke Die Hotspot-Falle [2] herausfand, lassen sich die Konfigurationsprofile im Namen jeder beliebigen Person oder Firma signieren – sogar Apple. Und das wirkt sich auch auf die Sicherheit von Privatnutzern aus, die zumeist gar nicht von der Existenz der Konfigurationsprofile wissen. Da die angezeigten Texte weitgehend frei änderbar sind, sind der Phantasie eines Angreifers kaum Grenzen gesetzt.

Das Profil kann etwa wie ein vom Netzbetreiber angeordnetes Update der Systemeinstellungen aussehen:


Würden Sie bei dieser Abfrage skeptisch werden?

Ein solches Konfigurationsprofil kann überall lauern: Ein Angreifer könnte es etwa an eine E-Mail anhängen, die vermeintlich von der Telekom-Kundenbetreuung stammt. Aber auch beim Surfen kann sich ein solcher Dialog ohne das Zutun des Nutzers öffnen – die aufgerufene Webseite muss lediglich auf die online gehostete Konfigurationsdatei umleiten.

Unser Profil stammt anscheinend von der Telekom Deutschland GmbH und wurde "Überprüft". Signiert wurde es von Apple. Eigentlich besteht kein Anlass, dahinter einen Schwindel zu vermuten. Tatsächlich sind jedoch sämtliche Angaben gefälscht. Wer diesen Dialog abnickt, fügt seinen Netzwerkeinstellungen ungewollt einen Proxy hinzu, durch den künftig der gesamte Datenverkehr geschleust wird. Wer auch immer diesen Proxy betreibt, kann fortan alles mitlesen.



Unser Konfigurationsprofil installiert das Wurzelzertifikat "PortSwigger CA" des Webanalyse-Proxies Burp. Damit kann man auch SSL-verschlüsselte Verbindungen aufbrechen, um etwa das iTunes-Passwort zu stehlen.
Übrigens betrifft das auch verschlüsselte Verbindungen: Das Profil fügt dem Zertifikatsspeicher ein CA-Zertifikat hinzu, welches das Gerät künftig als vertrauenswürdig einstuft. Dadurch kann sich ein Angreifer als Man-in-the-Middle in SSL-Verbindungen einklinken, die Datenpakete auf dem Übertragungsweg entschlüsseln und schließlich wieder neu verschlüsseln. Da iOS der CA des Angreifers bedingungslos vertraut, akzeptiert es die neu verschlüsselten Pakete klaglos. Normalerweise würde das zu einer Fehlermeldung führen. Der Angreifer kann die verschlüsselten Daten nicht nur im Klartext sehen, sondern auch beliebig manipulieren.

Kauft der Nutzer nach der Profilinstallation etwa im App Store ein, kann der unsichtbare Lauscher auch das iTunes-Passwort im Klartext sehen. Damit hält er den Schlüssel zur gesamten digitalen Identität in den Händen. Damit kann er nicht nur die Rechnung des Apple-Kunden in die Höhe treiben, er kann prinzipiell auch auf die iCloud-Backups zugreifen und auf ein anderen Gerät einspielen. Damit hat er das iOS-Gerät quasi dupliziert – mit allen darauf enthaltenen Daten.

Die Ursache des Problems liegt in der Überprüfung der Signatur: Unser vermeintliches Telekom-Profil haben wir zwar mit einem tatsächlich gültigen Zertifikat signiert – allerdings mit einem Zertifikat, das eigentlich nur zum Signieren (und Verschlüsseln) von Mails geeignet ist. Das Zertifikat haben wir uns kostenlos von der Symantec-Tochter TC TrustCenter [3] bekommen, deren CA-Zertifikat iOS von Haus aus vertraut.

Warum das Konfigurationsprofil angeblich von Apple signiert wurde, hat einen einfachen Grund: Wir haben uns das E-Mail-Zertifikat bei TrustCenter für Herrn Apple Computer ausstellen lassen. Diese Angaben werden beim Ausstellen von Mail-Zertifikaten nicht überprüft. Es ist also grob fahrlässig von iOS, diesen Signaturen beim Überprüfen von Konfigurationsdateien zu vertrauen. Um die .mobileconfig-Datei mit dem TrustCenter-Zertifikat zu signieren, haben wir ein unsigniertes Konfigurationsprofil mit dem Apple-Tool exportiert und das Signieren anschließend von Hand mit dem Kommandozeilentool OpenSSL [4] durchgeführt.


Nach dem Update auf iOS 6 ist unser Konfigurationsprofil "nicht überprüft".
Wir haben Apple bereits im November 2011 über das Problem informiert. Der Blogger Cryptopath hat das Problem sogar bereits im Januar 2010 öffentlich dokumentiert [5]. Die Lücke klafft demnach bereits seit mehreren Generationen in iOS und Apple hast fast drei Jahre benötigt, um sie zu schließen.

Abschalten lässt sich die Unterstützung des MobileConfig-Formats nicht. Wer kann, sollte daher schon aus Sicherheitsgründen auf iOS 6 umsteigen. Bietet Apple für das genutzte Gerät kein Update mehr an, bleibt einem nichts anderes übrig, als stets mit wachem Blick zu surfen und Hinweisdialoge skeptisch zu inspizieren.


URL dieses Artikels:
https://www.heise.de/security/artikel/iOS-6-stopft-Konfigurationsloch-1705096.html

Links in diesem Artikel:
  [1] http://support.apple.com/kb/DL852?viewlocale=de_DE
  [2] http://www.heise.de/ct/artikel/Die-Hotspot-Falle-1394646.html
  [3] http://www.trustcenter.de/products/tc_internet_id.htm
  [4] http://www.openssl.org/
  [5] http://cryptopath.wordpress.com/2010/01/