iStegSiri : une attaque des dispositifs iOS pour voler des informations privées

**Amine Horseman** · 20/01/2015, 18h09

iStegSiri : une attaque des dispositifs iOS pour voler des informations privées
En se basant sur l'assistant vocal Siri

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 ?

Que pensez-vous de ce type d'attaque et des solutions potentielles ?

**DelphiManiac** · 21/01/2015, 20h35

À 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.

Je 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

**mrqs2crbs** · 21/01/2015, 23h14

Envoyé par DelphiManiac

0.5 octet par sec, ça fait un octet toutes les 2 secondes, donc 32 secondes pour 16 octets ^^ (pas 2 minutes)

salut 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.

**tiamat59** · 22/01/2015, 08h56

il y a confusion sur les termes, l'article original parle de byte/sec (et pas d'octet/sec),

?? confusion pourquoi byte en anglais c'est octet c'est tout.

de plus le "byte" est ici utilisé dans son sens le plus large : "la plus petite unité de donnée" (soit 0 ou 1)

bah ça c'est bit (en anglais et en français).

**mrqs2crbs** · 22/01/2015, 09h55

Envoyé par tiamat59

?? confusion pourquoi byte en anglais c'est octet c'est tout.

pas 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 Vendangeur Masqué** · 22/01/2015, 10h17

Envoyé par Amine Horseman

Que pensez-vous de ce type d'attaque et des solutions potentielles ?

Que 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.

**Saverok** · 22/01/2015, 10h43

Envoyé par mrqs2crbs

pour décrire un nombre à 16 chiffres, il faudra donc 64 "bytes"
au rythme de 0.5 byte/sec, on arrive bien à 128 sec.

Ca, 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 minimal

**DelphiManiac** · 22/01/2015, 14h30

Envoyé par mrqs2crbs

pas 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)

Honnê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.