Des spywares dans les cartes SIM ?

[Nico37]

Des spywares dans les cartes SIM ?

Une carte SIM qui envoie subrepticement des SMS bourrés d’informations indiscrètes, cela ne pouvait que susciter de sérieuses investigations de notre part ! A supposer qu’elle ne soit là que pour la bonne cause, cette nouvelle fonctionnalité repérée sur les cartes USIM d’Orange mérite d’être surveillée, par crainte de possibles dérives...
Patrick Gueulle

En principe, les cartes USIM sont destinées aux mobiles de 3e génération (UMTS), mais comme elles peuvent fonctionner dans n’importe quel téléphone GSM, on commence même à en trouver dans les kits prépayés d’entrée de gamme. Bien que l’application USIM reste parfaitement « dormante » dans un mobile de première ou seconde génération, il se produit des choses étranges quand on essaie de telles cartes dans différents téléphones compatibles Phase 2+... On peut même s’attendre à ce que le phénomène gagne progressivement des cartes SIM déjà en circulation, à commencer par celles de type Java dans lesquelles des applications supplémentaires peuvent être téléchargées à tout moment, plus ou moins à l’insu de l’utilisateur.
Comment la puce peut-elle nous être mise à l’oreille ? Facile : un « suivi conso » détaillé (horodaté à la minute près...) qui révèle des envois de SMS gratuits vers un numéro bizarre (par exemple le 20782 pour les clients d’Orange), ou encore un mobile bien élevé qui, comme certains modèles de Nokia, demande la permission avant de laisser la carte SIM envoyer un SMS. Dans le cas qui nous intéresse, la chose se produit dès que l’on déplace la carte SIM d’un téléphone à un autre, et peut donc être déclenchée à volonté, ce qui facilite grandement l’expérimentation.
Mais il faut tout de même ruser : les cartes SIM ou USIM récentes supportent généralement la fonction PPS (Protocol Parameters Selection), tout comme la plupart des téléphones actuels. En clair, cela signifie que seule la « réponse au reset » (ATR) de la carte est transmise à 9600 bps, la suite des échanges s’opérant à un rythme de modulation plus rapide, librement négocié entre la carte et le mobile. Pour pouvoir enregistrer la partie intéressante du dialogue au moyen d’un espion raisonnablement simple (voir notre ouvrage Plus loin avec les cartes à puce), il faut donc trouver un téléphone compatible Phase 2+, mais ne supportant pas le PPS. Tel est le cas, par exemple, du M3188 Motorola, un modèle déjà âgé.


Une aiguille dans une botte de foin ?
Le dispositif d’espionnage étant mis en place, transportons sur le M3188 une carte USIM ayant préalablement été utilisée dans un téléphone plus récent. Des milliers d’octets vont s’enregistrer dans un fichier log, du simple fait de l’initialisation du mobile. Patientons au moins quelques minutes, puis arrêtons tout. Il va maintenant s’agir de repérer l’échange spontané de SMS entre la carte SIM et le réseau, en commençant l’analyse du fichier par la fin.
On devrait normalement trouver là un certain nombre de commandes dont les octets CLA et INS sont respectivement A0h et F2h. Il s’agit de commandes Status, que le mobile envoie à intervalles réguliers (de l’ordre de 2 mn) pour s’enquérir de l’état de la carte SIM, et auxquelles celle-ci répond à chaque fois par une bonne vingtaine d’octets. C’est donc un peu en amont qu’il faut chercher les commandes SIM Application Toolkit (voir spécification GSM 11.14) qui contiennent la clef du mystère : commandes en A0 12 (Fetch) lorsque le mobile vient prendre des ordres auprès de la carte, et commandes en A0 14 (Terminal Response) ou en A0 C2 (Envelope) quand le téléphone envoie des données à la SIM.
Dans le cas particulier de la carte USIM d’Orange qui nous a servi de cobaye, c’est une commande A0 12 00 00 88 qui ordonne au mobile d’envoyer un SMS, puisque son bloc de données (longueur 88h soit 136 octets) contient une commande proactive Send short message (code opération 13h). Cela étant, le découpage judicieux de cette suite de valeurs hexadécimales est riche d’enseignements. Dans le champ de données qui suit le libellé de l’instruction (D0 81 85 81 03 01 13 00 82 02 81 83 05 00 06), on isole ainsi successivement :

- L’en-tête du SMS où l’on retrouve, moyennant une classique permutation de quartets, le numéro du SMSC (+33689004000), le numéro du destinataire (20782), et un PID-DCS (00 F6) indiquant que le corps du message est codé en mode 8 bits :

07 91 33 86 09 40 00 F0
0B 6F 51 01 05 81 02 87 F2
00 F6 01 64

- Un groupe d’octets dont la signification semble « propriétaire », mais où l’on découvre, en ASCII, le mot « IME » (certainement pas par hasard, comme nous le verrons) :

02 70 00 00 5F 0D 00 00 00 00 49 4D 45 00
00 00 00 01 00

- Huit champs numérotés de 1 à 8, avec indication de longueur (structure TLV ou Tag, Length, Value).

Dans le bloc n°1, long de neuf octets, se trouve l’IMSI de la carte SIM, autrement dit son numéro de compte, réputé confidentiel (ici, xx yy zz masquent sa partie la plus personnelle) :

01 09
08 29 80 10 66 10 xx yy zz

Le bloc n°2 contient, sur dix octets (L = 0Ah) l’ICCID de la carte, autrement dit le numéro de série qui est imprimé dessus (quatre derniers octets masqués par nos soins) :

02 0A
98 33 10 65 64 00 aa bb cc dd

Dans les huit octets du bloc n°3, on lit l’IMEI du téléphone (Motorola) dans lequel se trouve la carte (6 derniers chiffres occultés) :

83 08
4A 84 38 06 a8 cb ed 0f

Le bloc n°4, pour sa part, révèle l’IMEI du précédent téléphone (Nokia) dans lequel la carte a été utilisée !

04 08
4A 39 00 17 a0 cb ed 0f

Le bloc n°5 contient le Terminal Profile du téléphone courant, autrement dit une liste de fonctionnalités qu’il supporte (bits à 1) ou non (bits à 0) :

85 14
0F 07 FF F7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Les deux octets du bloc n°6 s’incrémentant lors de chaque tentative (réussie ou non) d’envoi d’un SMS, il s’agit manifestement d’un compteur, probablement destiné à maintenir la synchronisation entre la carte SIM et la plate-forme OTA avec laquelle elle dialogue :

06 02
00 0E

Les deux derniers champs, pour leur part, hébergent des données dont la signification reste encore à élucider :

07 02
20 01

08 06
01 01 00 01 03 00

Quelles conclusions tirer de cette analyse ? Tout d’abord que le SMS véhicule des données (ICCID, IMSI) que l’opérateur connaît déjà, par définition. Peut-être pour vérifier simplement leur cohérence, mais dans quel but ? Ou alors, le SMS serait-il destiné à un prestataire tiers, qui ne les connaît pas, et à qui on les divulgue malgré leur caractère confidentiel ? De même, l’opérateur dispose d’autres moyens pour aller lire l’IMEI du téléphone, duquel il peut normalement déduire le Terminal Profile pour peu qu’il dispose d’une base de données constructeurs à jour. Clairement, ces informations peuvent lui être utiles pour optimiser, avec un temps de réaction minimum, certains services étroitement liés aux caractéristiques techniques du mobile (par exemple le #123#, qui doit être adapté au « niveau USSD » du téléphone utilisé).
Cependant, à quoi bon mémoriser dans la SIM, puis retransmettre, l’IMEI du précédent téléphone utilisé ? Il pouvait très bien s’agir d’un appareil emprunté, brièvement essayé avant de décider de l’acheter ou non, et pas nécessairement volé ! A l’évidence, cette information est fort indiscrète, et ne présente pas d’utilité technique flagrante. Il est curieux de remarquer que c’est à peu près au moment où les autorités policières et judiciaires améliorent leurs moyens d’interception de SMS, que l’on loge dans de tels messages des données largement redondantes pour leur destinataire supposé. Curieuse coïncidence...

Remontons encore un peu dans notre fichier log, et nous découvrirons des commandes de la forme A0 14 00 00 LEN, par lesquelles le mobile fournit à la carte certaines des données qu’elle va incorporer dans le SMS :

A0 14 00 00 16 14
81 03 01 26 01 82 02 82 81 83 01 00 94 08 4A 84 38 06 a8 cb ed 0f

retourne l’IMEI du téléphone, en réponse à une commande Provide local information (code opératoire 26h), émise par la carte SIM avec un « qualifier » égal à 01h (IMEI) :

A0 12 00 00 0B 12
D0 09 81 03 01 26 01 82 02 81 82

Auparavant, une autre commande réclamait, du fait de son qualifier 00h (LOCI), des informations sur la localisation du mobile :

A0 12 00 00 0B 12
D0 09 81 03 01 26 00 82 02 81 82

Dans la réponse du téléphone, on voit ainsi le code MCC-MNC du réseau sur lequel est inscrit le mobile (ici 208-01 pour Orange France), la zone locale dans laquelle il se trouve (la la), et même l’identifiant de la cellule qui le dessert (ci ci) : de quoi le localiser à quelques kilomètres près !

A0 14 00 00 15 14
81 03 01 26 00 82 02 82 81 83 01 00 93 07 02 F8 10 la la ci ci

On ne trouve pourtant aucune trace évidente de ces informations, bien indiscrètes et déjà connues de l’opérateur, dans le SMS envoyé par la SIM. Elles servent donc vraisemblablement à celle-ci (ou plutôt à l’application qu’elle exécute en tâche de fond) pour décider si elle doit ou non envoyer un SMS. Elle pourra ainsi s’assurer que le mobile est convenablement inscrit sur un réseau (faute de quoi l’envoi échouerait), voire même réagir différemment si le mobile est en roaming à l’étranger.


Et le réseau répond !
Pour peu que l’on n’interrompe pas prématurément l’enregistrement du dialogue entre la carte et le mobile, on verra que le réseau répond au SMS qui lui est envoyé. C’est une commande « Envelope » (CLA-INS = A0 C2) qui sert à rapatrier le SMS reçu vers la SIM, sans enregistrement dans le dossier des messages reçus puisque PID-DCS (7F F6) indique qu’il doit être interprété au vol :

A0 C2 00 00 39 C2
D1 37 82 02 83 81 86
07 91 33 86 09 40 00 F0 8B 28 44 05 85 02 87 F2
7F F6 60 01 32 80 13 91 80 18 02 70 00 00 13 0D
00 00 00 00 49 4D 45 00 00 00 00 00 00 09 06 02
00 0E

Bien plus court, ce message qui fait penser à un accusé de réception reprend le bloc de données contenant le texte « IME », et surtout la valeur du compteur de tentatives d’envoi de SMS, assurant ainsi le maintien d’une certaine forme de synchronisation. Autant dire qu’il faudra prendre des précautions si l’on souhaite composer soi-même, avec des données librement choisies, un SMS que l’on voudrait essayer de soumettre au réseau, « juste pour voir »...

Manipuler hors ligne
Au lieu de s’introduire ainsi malicieusement dans le système, il est possible d’expérimenter sans être inscrit sur aucun réseau, et même sans insérer la carte dans un téléphone ! Un simple lecteur PC/SC suffit, en effet, pour soumettre des commandes à la SIM et pour examiner ce qu’elle répond. Cela pourrait se faire, selon une habitude bien établie, en écrivant un programme ZCBasic implémentant les commandes voulues, mais il est ici plus approprié de se servir d’un outil travaillant en langage script. Faute d’avoir accès au remarquable logiciel Smart Access qu’Atmel fournit à ses clients professionnels, le Script Commander qu’ACS livre avec le SDK de son lecteur ACR38 peut suffire.
Le texte de ce programme, très concis, n’est rien d’autre qu’une suite de commandes que l’on pourrait tout aussi bien enchaîner manuellement, respectant par-là même les temps d’attente prévus ici sous la forme de commandes A0 F2 ou Pause.

Reader 1
power_on
A0 10 00 00 04 7F FF FF FF
A0 12 00 00 67
A0 14 00 00 0C 81 03 01 25 00 82 02 82 81 83 01 00
A0 12 00 00 0F
A0 F2 00 00 1A
A0 14 00 00 10 81 03 01 03 00 82 02 82 81 83 01 00 84 02 01 78
A0 F2 00 00 1A
A0 F2 00 00 1A
A0 F2 00 00 1A
A0 F2 00 00 1A
A0 F2 00 00 1A
A0 12 00 00 0B
A0 14 00 00 15 81 03 01 26 00 82 02 82 81 83 01 00 93 07 02 F8 10 la la ci ci
A0 12 00 00 0B
A0 14 00 00 16 81 03 01 26 01 82 02 82 81 83 01 00 94 08 4A 84 38 06 a8 cb ed 0f
Pause
Pause
A0 12 00 00 88
power_off

Il ne restera plus qu’à étudier les réactions de la carte à des variantes de tel ou tel champ de données, et à simuler éventuellement la réception du SMS retourné par le réseau. Cela, de préférence, sur une carte périmée, afin de ne pas prendre le risque de l’invalider par un trop grand nombre de manœuvres hasardeuses !