Fehler in populären iOS-Apps ermöglichen Anrufe ohne Nutzereingriff

Aufgrund eines nicht überprüften URI-Schemas können Angreifer mit Gmail, Google+ oder Facebook Messenger die Telefonnummer eines Nutzers herausbekommen. Apples eigener Browser hat das Problem nicht.

In Pocket speichern vorlesen Druckansicht 36 Kommentare lesen
Lesezeit: 2 Min.

Mehrere aktuelle iOS-Apps enthalten ein Problem, das zum unerwünschten Auslösen von Anrufen führen kann, schreibt der Entwickler Andrei Neculaesei in seinem Blog. Grund ist eine nicht vorhandene Nachfrage bei Verwendung des von Apple angebotenen URI-Schemas tel://, das auch in Web-Ansichten (Webviews) bereitsteht. Über Links wie "tel://1234" lassen sich damit Anrufe starten.

Wie Niculaesei in mehreren Drittanbieter-Anwendungen wie Google+, Gmail und Facebook Messenger festgestellt hat, werden darüber empfangene Nachrichten, die in einer Webview-Darstellung angezeigt werden, nicht ausreichend überprüft. So war es dann möglich, mittels eines kleinen JavaScript-Programms, das einen in einer Nachricht enthaltenen Link virtuell anklickte, Telefonate auszulösen.

Mit ein wenig JavaScript klickt sich der Telefonier-Link einfach selbst.

(Bild: Algorithm.dk)

Das ist aus mehreren Gründen ein Problem. So könnte ein Angreifer eine teure Telefonnummer anrufen lassen, deren Anwahl der Nutzer nicht mehr verhindern kann. Zudem lässt sich auf diese Art die Rufnummer eines Nutzers ermitteln: Wenn dieser, wie heute zumeist üblich, die Funktion Caller ID aktiviert hat und dann eine unter der Kontrolle des Angreifers stehende Gegenstelle anruft.

Interessanterweise tritt das Problem in Apples eigenen Programmen nicht auf. So fragt der Browser Safari stets nach, bevor ein Anruf ausgelöst wird. In Apples Beschreibung der tel://-Funktion führt der Hersteller allerdings explizit auf, dass bei der Verwendung von Webviews in nativen Apps keine Nachfrage erfolgt.

Ganz unschuldig ist Apple also nicht: Es ist eine unglückliche Entscheidung des Herstellers, dass es Webview erlaubt ist, die Telefonfunktion ohne Sicherheitsabfrage zu aktivieren. Besser wäre der umgekehrte Weg gewesen – dass die Entwickler die Sicherheitsfrage explizit abschalten müssen, wenn sie diese nicht haben möchten. (bsc)