Une faille découverte dans des applications iOS, Réactions à la publication du 25/08/2014

[Lionel]

Afin d'éviter que des applications ne passent à notre insu des appels vers des numéros surtaxés, Apple a prévu dans iOS une sécurité qui passe par un message de confirmation avant de composer le numéro de téléphone.
Andrei Neculaesei un chercheur en sécurité a découvert que le codage de certains logiciels sous iOS permet de s'affranchir de cette confirmation. Ce ne serait pas forcément grave s'il n'avait démontré qu'il est possible via la simple consultation d'une page web spécialement formatée de passer un appel.
Il n'a pas été vérifier tous les logiciels iOS mais a découvert que ce problème touche les applications Facebook, Google et aussi l'application FaceTime. Un lien malveillant envoyé par un de ces canaux suffit à déclencher l'appel.


On peut présumer qu'Apple va réagir avant que des pirates n'utilisent ces failles pour faire appeler à l'insu des propriétaires des numéros fortement surtaxés.
Lien vers le billet original

[tibounise]

On peut présumer qu'Apple va réagir avant que des pirates n'utilisent ces failles pour faire appeler à l'insu des propriétaires des numéros fortement surtaxés.

Cette "faille" n'en est pas vraiment une.

https://developer.apple.com/library/ios/fea...PhoneLinks.html

Premier paragraphe, on peut lire :

When a user opens a URL with the tel scheme in a native app, iOS does not display an alert and initiates dialing without further prompting the user. However, a native app can be configured to display its own alert.

Je doute donc qu'Apple va réagir, car c'est bien précise dans les docs.

EDIT/ Pour info, les applications touchées sont celles qui font usage de UIWebView sans avoir été configurées pour afficher des alertes quand on clique sur une URI interne. Soit presque toutes les applications faisant usage des UIWebView sur l'App Store.

Ce message a été modifié par tibounise - 25 Aug 2014, 14:13.

[cooltea]

J'avais rencontré un problème similaire avec une application dont l'appui sur un bandeau publicitaire déclenchait un appel vers un numéro surtaxé. L'application a depuis géré le problème (en retirant la publicité incriminée) mais si une sécurité a été mise en place par Apple (iOS 7) je ne l'ai pas vue à l'oeuvre.

Par contre je ne comprends pas comment cette faille peut affecter FaceTime : on peut naviguer depuis cette application ?

Ce message a été modifié par cooltea - 25 Aug 2014, 15:20.

[lolo-69]

Bonjour.


Si le boulot était fait en amont... :

Système de signalement de ces N°, et blocage au niveau des opérateurs téléphoniques, enquêtes pour retrouver et punir les coupables de ces arnaques...

Si l'énergie, le fric dépensés pour défendre les intérêts privés des mafias du multimédia étaient orientés pour défendre le citoyen lambda, on n'en serait peut-être pas là.
Je ne compte pas ce qui est mis dans les moyens qu'ont la NSA et autres agences gouvernementales. (S'il fallait compter sur eux pour nous défendre! )
Dans ce cas, on sait se donner un pouvoir qui passe les frontières pour punir les resquilleurs, donc, ça doit bien être possible pour ces empoisonneurs parasites, non?

Je sais, je rêve, d'autres intérêts masqués, plus rémunérateurs sont en jeu.


Séquence "coup de gueule". Je sais, ça sert à rien, mais ça fait du bien de le dire!

Ce message a été modifié par lolo-69 - 25 Aug 2014, 15:24.

[noop]

Bonjour.


Si le boulot était fait en amont... :

Système de signalement de ces N°, et blocage au niveau des opérateurs téléphoniques, enquêtes pour retrouver et punir les coupables de ces arnaques...

Si l'énergie, le fric dépensés pour défendre les intérêts privés des mafias du multimédia étaient orientés pour défendre le citoyen lambda, on n'en serait peut-être pas là.
Je ne compte pas ce qui est mis dans les moyens qu'ont la NSA et autres agences gouvernementales. (S'il fallait compter sur eux pour nous défendre! )
Dans ce cas, on sait se donner un pouvoir qui passe les frontières pour punir les resquilleurs, donc, ça doit bien être possible pour ces empoisonneurs parasites, non?

Je sais, je rêve, d'autres intérêts masqués, plus rémunérateurs sont en jeu.


Séquence "coup de gueule". Je sais, ça sert à rien, mais ça fait du bien de le dire!

+1

[Groumf29]

Je m'étais fait avoir durant une exposition, qui indiquait le nom de l'application Bookbeo. C'était pour avoir du contenu additionnel.

J'ai cherché Bookbeo sur l'App Store, et je m'en suis servi 3 fois. Soit 3 appels surfacturés, via des vieux numéros d'une vieille techno, qui marche encore chez Orange.

[renards]

en parlant de facetime si ce n'est pas activé sur le iphone, il essaiera de passer un appel malgré tout?

[Twisell]

On peut présumer qu'Apple va réagir avant que des pirates n'utilisent ces failles pour faire appeler à l'insu des propriétaires des numéros fortement surtaxés.

Cette "faille" n'en est pas vraiment une.

https://developer.apple.com/library/ios/fea...PhoneLinks.html

Premier paragraphe, on peut lire :

When a user opens a URL with the tel scheme in a native app, iOS does not display an alert and initiates dialing without further prompting the user. However, a native app can be configured to display its own alert.

Je doute donc qu'Apple va réagir, car c'est bien précise dans les docs.

EDIT/ Pour info, les applications touchées sont celles qui font usage de UIWebView sans avoir été configurées pour afficher des alertes quand on clique sur une URI interne. Soit presque toutes les applications faisant usage des UIWebView sur l'App Store.

Pour le coup Lionel doit on en vouloir à Apple d'avoir laisser autant de liberté aux dévellopeurs?
Si ce que tibounise dit est vrai, que préconise tu? De verrouiller un peu plus le système? ça ne te ressemble pas...

Je trouve ça assez ironique que tu te trouves malgres toi en train de défendre la thèse strictement opposée à la tienne d'habitude

[macik]

pas de problème avec Free, j'ai interdit l'usage de num surtaxé

[Suricate15]

Bonjour.


Si le boulot était fait en amont... :

Système de signalement de ces N°, et blocage au niveau des opérateurs téléphoniques, enquêtes pour retrouver et punir les coupables de ces arnaques...

Si l'énergie, le fric dépensés pour défendre les intérêts privés des mafias du multimédia étaient orientés pour défendre le citoyen lambda, on n'en serait peut-être pas là.
Je ne compte pas ce qui est mis dans les moyens qu'ont la NSA et autres agences gouvernementales. (S'il fallait compter sur eux pour nous défendre! )
Dans ce cas, on sait se donner un pouvoir qui passe les frontières pour punir les resquilleurs, donc, ça doit bien être possible pour ces empoisonneurs parasites, non?

Je sais, je rêve, d'autres intérêts masqués, plus rémunérateurs sont en jeu.


Séquence "coup de gueule". Je sais, ça sert à rien, mais ça fait du bien de le dire!

Tant que ces intrusions et leurs conséquences néfastes ne procurent pas une perte importante de pognon pour la communauté (organismes en tous genres) mais uniquement pour le citoyen lambda, il ne se passera rien, rien du tout. Il faudrait qu'il y ait des effets "extrêmes" donc vraiment très graves pour que quelque chose bouge.

Les uns et les autres (nous) ne vivent pas dans le même monde, mais dans des mondes paralèlles qui ne vont pas forcément se croiser..

[marc_os]

On peut présumer qu'Apple va réagir avant que des pirates n'utilisent ces failles pour faire appeler à l'insu des propriétaires des numéros fortement surtaxés.

Cette "faille" n'en est pas vraiment une.

https://developer.apple.com/library/ios/fea...PhoneLinks.html

Premier paragraphe, on peut lire :

When a user opens a URL with the tel scheme in a native app, iOS does not display an alert and initiates dialing without further prompting the user. However, a native app can be configured to display its own alert.

Je doute donc qu'Apple va réagir, car c'est bien précise dans les docs.

EDIT/ Pour info, les applications touchées sont celles qui font usage de UIWebView sans avoir été configurées pour afficher des alertes quand on clique sur une URI interne. Soit presque toutes les applications faisant usage des UIWebView sur l'App Store.

Pour le coup Lionel doit on en vouloir à Apple d'avoir laisser autant de liberté aux dévellopeurs?
Si ce que tibounise dit est vrai, que préconise tu? De verrouiller un peu plus le système? ça ne te ressemble pas...

Je trouve ça assez ironique que tu te trouves malgres toi en train de défendre la thèse strictement opposée à la tienne d'habitude

Oui, ce que dit tibounise est vrai : Tu peux le vérifier par toi même grâce au lien vers la documentation d'Apple qu'il a donné !
Alors pourquoi mettre son affirmation en doute ?

Par contre, pour une page web affichée via un navigateur, le système demande confirmation :

When a user taps a telephone link in a webpage, iOS displays an alert asking if the user really wants to dial the phone number and initiates dialing if the user accepts.

Enfin, contrairement à ce que pense tibounise, ce n'est pas parce que c'est précisé dans la documentation que "ça ne va pas changer" si la demande est suffisamment forte - ou si des gens portent plainte.

[Twisell]

Heu je m'adressais, a Lionel...
Je ne remets nullement en doute ce qu'à dit tibounise , simplement comme je n'ai pas eu le temps de lire l'article hier soir j'ai préféré utiliser le conditionnel.

[tibounise]

Enfin, contrairement à ce que pense tibounise, ce n'est pas parce que c'est précisé dans la documentation que "ça ne va pas changer" si la demande est suffisamment forte - ou si des gens portent plainte.

Je répète qu'il ne s'agit que d'un doute de ma part, et non une vérité absolue.
Mais bon, changer une API c'est un peu délicat.

[zero]

Pour le coup Lionel doit on en vouloir à Apple d'avoir laisser autant de liberté aux dévellopeurs?
Si ce que tibounise dit est vrai, que préconise tu? De verrouiller un peu plus le système? ça ne te ressemble pas...

Je trouve ça assez ironique que tu te trouves malgres toi en train de défendre la thèse strictement opposée à la tienne d'habitude

Ah bon, faire en sorte que le système nous demande confirmation avant d'appeler un numéro (qui peut être surtaxé), tu appelles ça verrouiller le système?

Ce message a été modifié par zero - 27 Aug 2014, 10:13.

[Twisell]

Pour le coup Lionel doit on en vouloir à Apple d'avoir laisser autant de liberté aux dévellopeurs?
Si ce que tibounise dit est vrai, que préconise tu? De verrouiller un peu plus le système? ça ne te ressemble pas...

Je trouve ça assez ironique que tu te trouves malgres toi en train de défendre la thèse strictement opposée à la tienne d'habitude

Ah bon, faire en sorte que le système nous demande confirmation avant d'appeler un numéro (qui peut être surtaxé), tu appelles ça verrouiller le système?

Ben oui c'est en tout cas ce qui apparait quand on lit la doc. C'est au développeur de l'application de choisir s'il veut afficher une confirmation ou pas, Apple laisse le choix.

Par exemple si je développe une application qui permet de trouver des numéro de téléphones et présente le résultat dans une vue HTML, je n’ai pas forcément envie que mon utilisateur ais besoin de confirmer à chaque fois.
Si au contraire mon appli permet de visualiser de contenus web très variés et que je ne maitrise pas, j'aurais plutôt intérêt à mettre en place une confirmation (ex: facebook).

Donc oui ce serait un "verrouillage" d'Apple (d'habitude combattu par Lionel) que d'imposer à tout les développeurs la seconde option pour des raisons de sécurité.

Ce qui m’énerve le plus en fait c'est le titre racoleur, ce problème n'est en aucun cas une faille, c'est au pire une mauvais choix d'interface.
Car même s'il n'y a pas de confirmation l'utilisateur à pleinement conscience de passer un coup de fil puisque l'appli téléphone passe en premier plan. Il peut même l'annuler à temps s'il est suffisamment prompt.
Et s'il se fais avoir une fois, il sera naturellement plus méfiant à l'avenir car il à conscience de ce qui se passe. Parler de faille me semble exagéré.

Sous Android il y a déjà eu des failles ou le téléphone passait des appels silencieux ou envoyait des sms sans aucun indice à l'écran.
Et rien que ce dernier mois pour Android entre FakeID et la démonstration de phishing en temps réel d'une autre application... là oui on peut parler de faille.

Ce message a été modifié par Twisell - 27 Aug 2014, 13:33.

[zero]

Par exemple si je développe une application qui permet de trouver des numéro de téléphones et présente le résultat dans une vue HTML, je n’ai pas forcément envie que mon utilisateur ais besoin de confirmer à chaque fois.

Je ne vois pas le rapport entre "trouver des numéros de téléphone" et "appeler un numéro de téléphone".

De toute façon, ce que le développeur veut, on s'en fou. C'est à nous, les utilisateurs, de décider dans ce cas. Cet avertisssement est nécessaire, du moins par défaut, après on peut laisser le choix de bloquer l'avertisssement à l'utilisateur.

Ce message a été modifié par zero - 27 Aug 2014, 13:43.

[Twisell]

Par exemple si je développe une application qui permet de trouver des numéro de téléphones et présente le résultat dans une vue HTML, je n’ai pas forcément envie que mon utilisateur ais besoin de confirmer à chaque fois.

Je ne vois pas le rapport entre "trouver des numéros de téléphone" et "appeler un numéro de téléphone".

Pour des raisons d'interopérabilité certains développeurs développent des applications constituées principalement d'une vue HTML (ce qui permet de réutiliser le template sous iOS/ANdroid/WindowsPhone/BB).
C'est un choix discutable mais c'est un choix utilisable.

Si maintenant le but de cette application est d’accéder rapidement à des numéros de téléphones pour pouvoir les appeler (par exemple un annuaire d'entreprise) devoir confirmer à chaque fois via un message d'alerte aura un seul effet : Faire chier l'utilisateur!

Et pour un développeur : utilisateurs pas contents => client pas content => mauvaise réputation

De toute façon, ce que le développeur veut, on s'en fou. C'est à nous, les utilisateurs, de décider dans ce cas. Cet avertisssement est nécessaire, du moins par défaut, après on peut laisser le choix de bloquer l'avertisssement à l'utilisateur.

Une des plus grosse difficulté quand tu publie du software c'est justement de trouver le bon équilibre entre les choix que tu laisse à l'utilisateur et les choix que tu fais à sa place.
Steve Jobs était connu pour pousser le curseur pas mal du coté "choisir à leur place".

Ce message a été modifié par Twisell - 27 Aug 2014, 14:20.

[marc_os]

Heu je m'adressais, a Lionel...
Je ne remets nullement en doute ce qu'à dit tibounise , simplement comme je n'ai pas eu le temps de lire l'article hier soir j'ai préféré utiliser le conditionnel.

J'avais vu, mais pas vraiment saisi le fond de ta remarque...

Par exemple si je développe une application qui permet de trouver des numéro de téléphones et présente le résultat dans une vue HTML, je n’ai pas forcément envie que mon utilisateur ais besoin de confirmer à chaque fois.

Je ne vois pas le rapport entre "trouver des numéros de téléphone" et "appeler un numéro de téléphone".

Pour des raisons d'interopérabilité certains développeurs développent des applications constituées principalement d'une vue HTML (ce qui permet de réutiliser le template sous iOS/ANdroid/WindowsPhone/BB).
C'est un choix discutable mais c'est un choix utilisable.

Si maintenant le but de cette application est d’accéder rapidement à des numéros de téléphones pour pouvoir les appeler (par exemple un annuaire d'entreprise) devoir confirmer à chaque fois via un message d'alerte aura un seul effet : Faire chier l'utilisateur!

Et pour un développeur : utilisateurs pas contents => client pas content => mauvaise réputation

[...]

Une alternative entre le tout ou rien, serait qu'Apple mette en place un réglage (de plus), où l'utilisateur autoriserait (ou pas) telle ou telle application à lancer des appels sans demander de confirmation, comme par exemple pour la géo-localisation.

Ce message a été modifié par marc_os - 28 Aug 2014, 10:33.

[zero]

Une alternative entre le tout ou rien, serait qu'Apple mette en place un réglage (de plus), où l'utilisateur autoriserait (ou pas) telle ou telle application à lancer des appels sans demander de confirmation, comme par exemple pour la géo-localisation.

Un système comme Little Snitch est plus simple et pas gênant. Je suis sûr qu'on peut faire mieux en plus.