iPhone Backdoor oder Push Service?

1. netstat dein Freund und HelferiPhone Backdoor

Zugegebenermaßen ist die Überschrift etwas reißerisch. Das ist in diesem Fall auch so gewollt. Am Wochenende habe ich mit netstat auf meinem gejailbreakten iPhone 4 mit iOS 5.1.1 Netwerkverbindungen analysiert. Netstat ist ein kleines Tool aus der Linux Welt, welches geöffnete Ports und Verbindungen zu entfernten Rechnern darstellt. Meine Aufmerksamkeit richtete sich schnell auf eine Verbindung, die ich nicht eindeutig zuordnen konnte.

courier.push.apple.com - Port 5223
bzw.
17.172.232.211 - Port 5223

Es handelt sich hierbei um eine ausgehende Datenverbindung zu Apple. In Firewall iP war die Verbindung definitiv nicht explizit erlaubt. Also begab ich mich auf die Suche, um meine Neugierde zu stillen:

  • Welches Programm / Dienst initiiert die Verbindung?
  • Welche Daten werden über diese Verbindung ausgetauscht?
  • Und warum bekommt Firewall iP nichts davon mit?

2. Port 5223 – Was ist deine Funktion?

Zunächst versuchte ich mit netstat an weitere Informationen zu gelangen. Leider ist der Darwin Kernel von iOS dermaßen »beschnitten«, dass ein erweiterter Befehlsaufruf von nestat mit der »-p« Option nicht funktioniert. Daraufhin führte ich einen Neustart des iPhones durch und wollte den Boot-Vorgang bzw. den Start der Netzwerk-Interfaces beobachten. Unmittelbar nachdem das WLAN-Interface am System angemeldet ist wird die Verbindung zum Netzbereich 17.0.0.0/8 auf Port 5223 initiiert. Um herauszufinden welche Informationen über diesen Port mit der Gengestelle ausgetauscht werden, startete ich einen Verbindungsmitschnitt mit mimproxy.

Leider kann mitmproxy lediglich auf Port 80 bzw. 443 ausgehende Datenverbindungen »abfangen« und darstellen. Anderen Ports werden nicht unterstützt. Des Weiteren ist davon auszugehen, dass die verdächtige Verbindung zu *.push.apple.com nicht über den vorkonfigurierten iPhone Proxy aufgebaut wird. Ein Mitschnitt mit mitmproxy führte letztlich nicht zum Erfolg.

3. Fritzbox Mitschnitt

Neuere Modelle der FRITZ!Box ermöglichen einen Paketmitschnitt der verbauten Netzwerk-Interfaces. So lässt sich über das Webinterface (http://fritz.box/html/capture.html) eine entsprechende Funktion aufrufen, die auch Paketmitschnitte vom WLAN-Interface anfertigen kann. Über eine Export-Funktion lassen sich die gesammelten Verbindungsdaten anschließend in Wireshark importieren und in Ruhe analysieren.Paketmitschnitt

Noch während des Boot-Vorgangs initiiert das iPhone eine Verbindung zu *.push.apple.com auf Port 5223 auf. Nach der Verbindungsaushandlung wird im Klartext eine Art Device-Kennzeichnung übertragen. Danach werden noch einige Daten übertragen, die allerdings verschlüsselt gesendet werden. In unregelmäßigen Abständen schickt das iPhone weiterhin Daten über den Informationskanal.

Backdoor

Leider war meine Neugier damit noch nicht annähernd befriedigt. Ich wusste noch immer nicht zu welchem Zweck die Verbindung aufgebaut wird, welche Daten außer einer Device Kennzeichnung noch übertragen werden und warum sich über Firewall iP kein Einfluss auf diese Datenverbindung nehmen lässt. Nur eines war bis dahin klar: Die Verbindung wird durch einen Launch Daemon direkt im Boot-Vorgang initiiert.

4. Sherlock Homes übernehmen Sie!

In einem Apple Support Dokument fand ich zunächst eine Liste mit »Well known TCP and UDP ports used by Apple software products«. Unter Port 5223 ist die Bezeichnung »Apple Push Notification Service« aufgeführt. In einem weiteren Dokument fand ich dann endlich ein paar Antworten. Port 5223 dient dem Empfang von Push Notifications innerhalb eines WLAN’s, wenn kein Telefonsignal zur Verfügung steht. Steht ein Signal bzw. die mobilen Daten zur Verfügung geschieht der Austausch über die Ports 2195 und 2196.

Die Verbindung zu *.push.apple.com über Port 5223 bzw. 2195/2196 dient also dem APNS (Apple Push Notification Service). iOS Geräte bauen demnach eine dauerhafte Verbindung zu dem Service auf, um Notifications bzw. Benachrichtigungen von Anwendungen zu erhalten. Selbst wenn eine App nicht aktiv läuft, erhält das Gerät über diesen Kanal eine Meldung, dass für eine bestimmte Anwendung neue Daten bzw. Informationen vorliegen.

Letztlich dient diese dauerhafte Verbindung also dem Empfang von Push-Notifications/Benachrichtigungen. Nach meinem Verständnis ist dies allerdings kein Push-Dienst, da eine dauerhafte Datenverbindung initiiert wird. Es stellt sich unweigerlich die Frage, ob sich die APNS-Funktion auf dem iPhone deaktivieren lässt bzw. ob dies überhaupt von Apple vorgesehen ist.

5. Push Service deaktivieren

Nachdem ich mich durch alle Einstellungen »gewühlt« hatte war klar, dass sich die APNS-Funktionalität nicht abschalten lässt. Bei jedem Neustart und nach einer definierten Zeit X baut das iPhone eine Verbindung zu 17.0.0.0/8:5223 im WLAN auf. Der komplette Adressbereich 17.0.0.0 – 17.255.255.255 ist übrigens auf Apple registriert.

Im Hintergrund werden also nach wie vor weiterhin Daten ausgetauscht. Aufgrund der Verschlüsselung ist allerdings nicht nachvollziehbar, um welche Daten bzw. Information es sich hierbei handelt. Im Prinzip wäre Apple über diese Datenkanal in der Lage jegliche Informationen von einem iPhone unbemerkt auszulesen.

6. Verbindung kappen – APNS deaktivieren

Es ist tatsächlich möglich die dauerhafte Verbindung zu Apple zu kappen. Allerdings ist der Eingriff mit Bedacht vorzunehmen und ebenfalls mit einem gravierenden Nachteil verbunden: Nach dem Eingriff erhält das iPhone keine Push Notifications mehr, was wiederum bedeutet, dass jegliche Statusupdates von Apps nicht mehr zugestellt werden. Folglich erhaltet ihr keine Benachrichtigung mehr, wenn beispielsweise eine neue Messenger-Nachricht für euch bereitsteht. Wer die »Wanze« dennoch entfernen möchte, kann dieser Beschreibung (auf eigene Gefahr!) folgen. Ein Jailbreak wird voraussgesetzt:

  • Zunächst erfolgt der Zugriff auf das iPhone Dateisystem, beispielsweise über das SSH-Protokoll.
  • Anschließend navigiert ihr zu folgendem Ordner: /System/Library/LaunchDaemons 
  • Den LaunchDeamon »com.apple.apsd.plist« kopiert ihr als Backup auf eure Festplatte. Damit lässt sich der »Eingriff« wieder umkehren.
  • Danach wird die Datei vom iPhone gelöscht, da der Befehl »launchctl unload /System/Library/LaunchDaemons/com.apple.apsd.plist« zu keinem Erfolg führte.
  • Neustart – Und tatsächlich: Es wird keine Verbindung mehr initiiert! Mittels netstat könnt ihr dies überprüfen. Zur Sicherheit habe ich noch eine ganze Weile den Verkehr am WLAN-Interface mitgeschnitten.

Hinweis

Der Eingriff ist nicht ungefährlich. Legt euch zumindest eine Sicherheitskopie des »Launch Daemons« an. Push Notifications könnt ab sofort keine mehr empfangen.

Alle Apps die Push Notifications unterstützen melden sich beim Start ab sofort mit folgender Meldung:

APN deaktiviert

Du kannst den Blog aktiv unterstützen!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

7. Fazit

Zunächst möchte ich auf meine zu Beginn formulierten Fragen eingehen:

  • Welches Programm / Dienst initiiert die Verbindung?
    Die Verbindung wird durch APNS (Apple Push Notification Service) direkt vom iPhone über einen Launch Daemon initiiert.
  • Welche Daten werden über diese Verbindung ausgetauscht?
    Unklar. In jedem Fall Push Notifications. Nach Entfernung des Daemons ist der Empfang solcher nicht mehr möglich.
  • Und warum bekommt Firewall iP nichts davon mit?
    Es handelt sich hierbei um ein »Feature« von iOS. Ich gehe davon aus, dass der Entwickler von Firewall iP den kompletten Adressraum 17.0.0.0/8 als unkritisch eingestuft hat.

Für die dauerhafte Datenverbindung ist folglich also der APNS (Apple Push Notification Service) verantwortlich. Generell eine clevere Lösung, um Push Notifications über einen Kanal zu empfangen. Über das System selbst lässt sich der Dienst allerdings nicht deaktiveren, selbst dann nicht, wenn im Grunde genommen keine Anwendung für den Push Empfang konfiguriert wurde. Erst der Eingriff auf Systemebene entbindet APNS von seinen Aufgaben.

Ob es sich beim APNS letztlich um eine iPhone Backdoor handelt, oder darüber lediglich Push Notifications bereitgestellt werden kann uns nur Apple mit Sicherheit beantworten. Fakt ist: Über diesen Datenkanal lassen sich nicht nur Push Notifications empfangen, sondern auch Daten vom iPhone übermitteln.

Bildquellen:

Warnung: Nemo, Creative Commons CC0

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

2 Ergänzungen zu “iPhone Backdoor oder Push Service?”

  1. Comment Avatar Sabine sagt:

    Guten Tage, Herr Kuketz,

    wie läuft das bei iOS 8.3? Ich hab dort die „com.apple.apsd.plist“ nicht gefunden. Oder hat das etwas mit der iOS-Version zu tun?

    Mit freundlichen Grüßen

    • Comment Avatar Mike Kuketz sagt:

      Kann ich leider nichts zu sagen. Ich weiss nicht wie Apple das unter iOS 8.3 konzipiert hat. Der Blog-Eintrag ist schon etwas älter und daher leider auch nicht mehr aktuell – gilt entsprechend nur für iOS 5.x.

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.