iStegSiri : une attaque des dispositifs iOS pour voler des informations privées
En se basant sur l'assistant vocal Siri
Le 2015-01-20 18:09:20, par Amine Horseman, Expert éminent sénior
Deux chercheurs en sécurité informatique ont réussi à voler des informations privées des appareils iOS en utilisant l'assistant vocal Siri.
Siri est une application publiée en 2010 par Apple, puis intégrée en natif dans les appareils iOS à partir de 2011. Son but est de convertir les commandes vocales de l'utilisateur en commandes que la machine pourrait comprendre (effectuer un appel, envoyer un message, écrire du texte, etc.). Mais en réalité ces commandes vocales ne sont pas traitées dans l'appareil mobile, mais plutôt envoyées au serveur d’Apple, qui les convertit en texte puis renvoie la réponse.
L'attaque iStegSiri décrite par les deux chercheurs se base sur la dissimulation de données durant la phase d'envoi. En effet, une personne malveillante pourrait utiliser ce flux comme canal de transfert afin de voler des informations sensibles sans être repéré en transformant la forme du trafic généré par l'application Siri. En guise d'exemple, les deux chercheurs ont réussi à exfiltrer des données à un taux de 0,5 octet/sec, sans nécessiter l'installation de composants logiciels supplémentaires, ni modification de l'appareil. Ils ont d'abord transformé le message secret en séquence audio, cette séquence est ensuite envoyée par le microphone interne à Siri, qui l'envoi à son tour au serveur d'Apple. C'est durant ce transfert que le hacker devra intercepter le message et décoder les informations cachées. À noter qu'avec cette vitesse (0,5 octet/sec), il faudra environ 2 minutes pour envoyer un numéro de carte de paiement à 16 chiffres.
Figure : fonctionnement de l'attaque iStegSiri
« Avec iStegSiri, la contre-mesure idéale agit sur le côté serveur », écrivent les chercheurs dans leur rapport, « Apple devrait analyser les tendances dans le texte reconnu pour déterminer si la séquence de mots s'écarte sensiblement des comportements typiques de la langue utilisée. Par conséquent, la connexion pourrait être interrompue de sorte à limiter le taux de données secrètes transférées ».
Ce type d'attaques n'est pas nouveau. Une technique similaire avait été utilisée par le passé pour cacher des informations en utilisant des applications populaires comme Skype afin de tromper les analyseurs de flux et les antivirus.
Source : Rapport publié par les chercheurs
Et vous ?
Siri est une application publiée en 2010 par Apple, puis intégrée en natif dans les appareils iOS à partir de 2011. Son but est de convertir les commandes vocales de l'utilisateur en commandes que la machine pourrait comprendre (effectuer un appel, envoyer un message, écrire du texte, etc.). Mais en réalité ces commandes vocales ne sont pas traitées dans l'appareil mobile, mais plutôt envoyées au serveur d’Apple, qui les convertit en texte puis renvoie la réponse.
L'attaque iStegSiri décrite par les deux chercheurs se base sur la dissimulation de données durant la phase d'envoi. En effet, une personne malveillante pourrait utiliser ce flux comme canal de transfert afin de voler des informations sensibles sans être repéré en transformant la forme du trafic généré par l'application Siri. En guise d'exemple, les deux chercheurs ont réussi à exfiltrer des données à un taux de 0,5 octet/sec, sans nécessiter l'installation de composants logiciels supplémentaires, ni modification de l'appareil. Ils ont d'abord transformé le message secret en séquence audio, cette séquence est ensuite envoyée par le microphone interne à Siri, qui l'envoi à son tour au serveur d'Apple. C'est durant ce transfert que le hacker devra intercepter le message et décoder les informations cachées. À noter qu'avec cette vitesse (0,5 octet/sec), il faudra environ 2 minutes pour envoyer un numéro de carte de paiement à 16 chiffres.
Figure : fonctionnement de l'attaque iStegSiri
« Avec iStegSiri, la contre-mesure idéale agit sur le côté serveur », écrivent les chercheurs dans leur rapport, « Apple devrait analyser les tendances dans le texte reconnu pour déterminer si la séquence de mots s'écarte sensiblement des comportements typiques de la langue utilisée. Par conséquent, la connexion pourrait être interrompue de sorte à limiter le taux de données secrètes transférées ».
Ce type d'attaques n'est pas nouveau. Une technique similaire avait été utilisée par le passé pour cacher des informations en utilisant des applications populaires comme Skype afin de tromper les analyseurs de flux et les antivirus.
Source : Rapport publié par les chercheurs
Et vous ?
-
tiamat59Membre habitué?? confusion pourquoi byte en anglais c'est octet c'est tout.
il y a confusion sur les termes, l'article original parle de byte/sec (et pas d'octet/sec),
bah ça c'est bit (en anglais et en français).
de plus le "byte" est ici utilisé dans son sens le plus large : "la plus petite unité de donnée" (soit 0 ou 1)
le 22/01/2015 à 8:56 -
mrqs2crbsMembre avertisalut DelphiManiac,
il y a confusion sur les termes, l'article original parle de byte/sec (et pas d'octet/sec),
de plus le "byte" est ici utilisé dans son sens le plus large : "la plus petite unité de donnée" (soit 0 ou 1)
pour décrire un nombre à 16 chiffres, il faudra donc 64 "bytes"
au rythme de 0.5 byte/sec, on arrive bien à 128 sec.le 21/01/2015 à 23:14 -
mrqs2crbsMembre avertipas forcément:
1 octet c'est toujours 8 bits,
1 byte c'est 1 unité de mémoire (souvent 8 bits, mais pas toujours, ici c'est plutôt 1 bit)le 22/01/2015 à 9:55 -
Le Vendangeur MasquéNouveau Candidat au ClubQue comme toute faille c'est corrigeable, et qu'on fait là dessus beaucoup de bruit pour rien, puisque l'attaque nécessite d'être faite sur un appareil préalablement jailbreaké, donc déjà transformé en passoire.
On passera aussi sur le côté sensationnaliste du rapport de ces chercheurs, qui nous sortent en préambule l'habituelle poncif "oui mais comme Apple a du succès les créateurs de malwares se sont jetés dessus"… en avouant quand-même une ligne plus tard que c'était là encore sur des appareils jailbreakés.
Mais ce que est dommage c'est que l'article oublie justement de préciser que le jailbreak est nécessaire et c'est pourtant important.le 22/01/2015 à 10:17 -
DelphiManiacMembre émériteHonnêtement, ma réponse étais plus un "joke" qu'autre chose, mais là tu commence à m'expliquer qu'il est évident que le document initial utilise Byte pour désigner bit, alors que ce n'est là que ton interprétation, autant utilisé bit quand c'est un bit. Demain, on inventeras les bytes de 0.5 bit et l'étape suivante sont les bytes de tailles aléatoires :/ comme ça il sera facile de communiquer.le 22/01/2015 à 14:30
-
DelphiManiacMembre émériteJe ne sais pas comment ont calculer ces "chercheurs", mais 0.5 octet par sec, ça fait un octet toutes les 2 secondes, donc 32 secondes pour 16 octets ^^ (pas 2 minutes). Ça rassure sur la capacité des chercheurs à chercher :pÀ noter qu'avec cette vitesse (0,5 octet/sec), il faudra environ 2 minutes pour envoyer un numéro de carte de paiement à 16 chiffres.le 21/01/2015 à 20:35
-
SaverokExpert éminentCa, c'est le cas idéal.
Il faut également tenir compte qu'il s'agit du débit de la connexion, pas celle du transfert de données car il peut y avoir des pertes de paquets, des de contrôles de flux, etc. (cf TCP)
Autrement dit, 128s, c'est le temps minimalle 22/01/2015 à 10:43 -
JayGrMembre actifle 26/01/2015 à 9:42