ACBM - Le Virus Informatique qui vous défend !Retour à l'accueilLes brèvesLe magasinContacts Ecrire dans le virusListe de diffusionPetites annoncesLes concours



Paru dans Pirates Magazine n°15
2003-07-01 00:00

Des SMS malveillants ?


Longtemps dédaignés par les utilisateurs de téléphones portables, les SMS et autres Textos connaissent maintenant leur heure de gloire. Alors même que l'on commence à se préoccuper du déferlement de messages publicitaires, il est permis de se demander si ce moyen de communication commode et peu coûteux ne risque pas, comme l'e-mail, de véhiculer discrètement des contenus plus ou moins malicieux, voire des virus.

Les SMS (Short Message Service) constituent un service essentiel du système GSM, et sont surtout connus sous la forme de mini-messages d'un maximum de 160 caractères affichables. Il faut cependant savoir que la norme définit de très nombreuses variantes, dont des possibilités de concaténation permettant de mettre plusieurs messages bout à bout pour transporter des volumes de données plus importants. Il existe aussi des catégories de SMS dont la réception peut se faire totalement à l'insu de l'utilisateur, en vue d'opérer des modifications plus ou moins profondes dans les cartes SIM ou les mémoires non volatiles des téléphones. En milieu industriel, enfin, les SMS sont de plus en plus souvent utilisés pour télécommander et télésurveiller toutes sortes d'équipements munis de modems GSM, y compris à bord des trains.

L'OTA ou Over The Air
Les applications Over The Air des SMS sont à cent lieues des « petits mots » que s'échangent si volontiers les jeunes (et parfois les moins jeunes), en mode texte. C'est évidemment par SMS que certains prestataires peuvent télécharger à distance (et, bien entendu, à titre payant) les répertoires de numéros des cartes SIM de leurs clients, des mélodies de sonnerie ou des logos graphiques. C'est aussi par SMS que s'est fait le basculement d'Itinéris à Orange, astucieusement effectué par remplissage à distance du fichier 7F20:6F46 des cartes SIM. Ecrite dans ce fichier Service Provider Name, la chaîne d'octets « 00 4F 72 61 6E 67 65 20 46 FF FF FF FF FF FF FF FF » impose (du moins sur les mobiles compatibles) l'affichage du texte « Orange F » à la place du nom d'origine du réseau sur lequel le mobile est inscrit, sauf à l'étranger où les deux peuvent coexister. Grâce à la technologie ESMS si chère à Gemplus, ce genre de manœuvre fonctionne même avec des cartes SIM relativement anciennes (dites « Phase 2 »). En gros, le SMS contient une suite de commandes (dont peut-être la présentation de codes secrets...), que la carte est priée d'exécuter comme si elle les avait reçues directement du terminal dans lequel elle est insérée. Cela peut aller jusqu'à la création de nouveaux fichiers, grâce à des commandes « administratives » qui diffèrent, hélas, d'un fabricant de cartes à l'autre, freinant la généralisation du système (fin 1999, seulement 20 % des opérateurs en faisaient usage).

Le STK ou SIM application toolkit
Les choses peuvent aller infiniment plus loin avec la nouvelle génération de cartes SIM, dites « Phase 2+ », « SIM Toolkit » ou « Proactive SIM », qui adhèrent cette fois à une normalisation très précise (GSM 11.14). Non contentes de pouvoir envoyer spontanément des SMS (sans forcément en avertir l'utilisateur, qui va pourtant payer la note...), elles peuvent aussi en recevoir très discrètement. Cela aussi bien pour les besoins d'une application résidant déjà dans la carte (paiement électronique, par exemple), que pour la mise en place de telle ou telle fonctionnalité nouvelle. Dans un contexte multi-applications, la responsabilité de la manœuvre incombe à l'opérateur ayant émis la carte, même s'il l'effectue pour le compte d'un tiers (par exemple, une banque). La plupart du temps, elle se traduit par l'apparition de nouvelles options dans le système de menus du téléphone, mais une application peut aussi rester parfaitement cachée, voire « dormante ». Bien évidemment, de telles possibilités de téléchargement de code exécutable (souvent des applets Java) peuvent faire craindre l'introduction de virus, éventuellement susceptibles de se propager (toujours par SMS) aux numéros enregistrés dans le répertoire de la carte SIM.

Pour se fixer les idées...
Sans les spécifications GSM 02.48 et 03.48 et les mesures de sécurité (parfaitement facultatives !) qu'elles préconisent, on pourrait craindre que n'importe qui puisse, par exemple, inscrire des numéros (surtaxés ?) dans les annuaires des cartes SIM, ou expédier de fausses factures vers des mobiles équipés de fonctions de paiement. Cela nécessiterait tout de même un peu d'astuce, car un téléphone portable normalement constitué ne permet pas de composer autre chose que des SMS très ordinaires. Qu'à cela ne tienne ! Le programme que voici prouve amplement que quelques lignes de Basic suffisent pour développer un outil capable de construire de toutes pièces, dans une carte SIM valide, un SMS prêt à être expédié :

#Include CARDUTIL.DEF
#Include COMMERR.DEF
ComPort=101
Declare Command &HA0 &HA4 SL(S$,Disable Le)
Declare Command &HA0 &HDC UREC(S$,Disable Le)
Public L As Single
ST$=Chr$(&H07)
SC$="33689004000"
SR$=Chr$(&H11)
REF$=Chr$(&HFF)
To$="3368312345"
PID$=Chr$(&H5F)
DCS$=Chr$(&HF0)
VAL$=Chr$(&H17)
LTX$=Chr$(&H09)
TXT$=Chr$(&HC2)+Chr$(&HB7)+Chr$(&H5B)+Chr$(&HFD) _
+Chr$(&HAE)+Chr$(&HCB)+Chr$(&H41)+Chr$(&H21)+Chr$(&HFF)
U$=Chr$(&H91)
L=Len(SC$):L=L/2
IF L <> Len(SC$)/2 Then SC$=SC$+"F"
For F=1 To Len(SC$) Step 2
K$=Mid$(SC$,F,2)
U$=U$+Chr$(ValH(Right$(K$,1)+Left$(K$,1)))
Next F
SC$=Chr$(Len(U$))+U$
U$=Chr$(&H91)
L=Len(To$):LTO=L:L=L/2
IF L <> Len(To$)/2 Then To$=To$+"F"
For F=1 To Len(To$) Step 2
K$=Mid$(To$,F,2)
U$=U$+Chr$(ValH(Right$(K$,1)+Left$(K$,1)))
Next F
TO$=Chr$(LTO)+U$
SMS$=ST$+SC$+SR$+REF$+TO$+PID$+DCS$+VAL$+LTX$+TXT$
B=176-Len(SMS$)
SMS$=SMS$+String$(B,&HFF)
Call WaitForCard
ResetCard:Call CheckSW1SW2:PRINT
S$=Chr$(&H7F)+CHR$(&H10):Call SL(S$)
S$=Chr$(&H6F)+Chr$(&H3C):Call SL(S$)
Call UREC(P1P2=&H0104,SMS$):Call CheckSW1SW2


Ecrit en ZCBasic (le Basic des fameuses BasicCard), il pourra être personnalisé selon les besoins de chacun, puis compilé à l'aide du kit logiciel (version 4.32 ou supérieure) téléchargeable gratuitement sur www.basiccard.com. Pourvu que le PC soit équipé d'un lecteur de cartes à puce PC/SC (ou CyberMouse, à condition de modifier la valeur ComPort en conséquence), il enregistrera un SMS sur mesures en première position dans la carte SIM que l'on voudra bien y insérer. Auparavant, on aura désactivé le code PIN de la carte (cela se fait à partir du menu du téléphone), et vérifié que l'actuel SMS n° 1 peut être écrasé sans regret (les SMS de rang supérieur ne seront aucunement affectés).
Chaque champ potentiellement intéressant à bricoler se présente sous la forme d'une chaîne séparée :
- SC$ contient, en format téléphonique international, le numéro du SMSC (centre de messagerie) que l'on veut charger d'acheminer le SMS. En règle générale, ce sera celui de l'opérateur ayant émis la carte SIM (par exemple 33689004000 pour Orange, 33609001390 pour SFR, 33660003000 pour Bouygues). Si la formule souscrite autorise l'accès à des SMSC étrangers, alors il n'y a plus de limites : on pourra aussi bien choisir de transiter par la Suisse (41794999000), l'Afrique du Sud (27830000410), Singapour (6596500005), etc. On trouve sur Internet des listes entières de SMSC, dont certains sont aussi accessibles par modem ! Le principal intérêt de la chose est que tous les SMSC n'appliquent pas nécessairement les mêmes règles de rejet des SMS non-conformistes. Mais attention ! Certains opérateurs (et notamment les trois français) refusent les SMS provenant des SMSC de certains pays. Ceci explique peut-être cela...
- To$ contient, toujours en format international (sans le signe +), le numéro du destinataire du SMS (en général le numéro d'un mobile dont on est le légitime propriétaire, ou avec lequel on est dûment autorisé à procéder à de tels essais).
- SR$ aura la valeur 11h si l'on ne réclame pas d'accusé de réception, ou 31h dans le cas contraire. Il s'agit d'un SMS spécial, que certains téléphones affichent sous une forme pas toujours facile à interpréter.
- PID$ définit le protocole que l'on souhaite employer, la valeur par défaut qu'utilisent les téléphones portables étant 00h. La valeur 5Fh suggère ici au mobile d'offrir une possibilité de rappel immédiat du numéro de l'expéditeur : une formule normalement destinée aux opérateurs (pour avertir de l'arrivée d'un message dans le répondeur), mais que l'on peut très facilement s'approprier ! Les valeurs 7Fh, 7Dh, et 7Eh identifient des SMS à destination, respectivement, du système d'exploitation de la carte SIM ou du téléphone, ou destinés à déverrouiller le mobile à distance. Il est intéressant d'observer dans quelle mesure les réseaux et/ou les SMSC refusent l'acheminement des SMS de cet acabit, potentiellement suspects lorsqu'ils émanent d'un particulier et non d'un opérateur.
La valeur 3F, enfin, indique au SMSC qu'on lui demande de se charger d'une conversion de format, par exemple de 8 bits vers 7 bits. Les résultats parfois aléatoires que l'on obtient d'une fois sur l'autre sont assez réjouissants à étudier...
- DCS$ décrit le type de codage utilisé, la valeur par défaut étant, là encore, 00h. Dans ce mode texte, on utilise un codage affreusement compliqué, servant juste à emballer 160 caractères à 7 bits dans 140 octets (ce qui n'est pourtant pas un exploit !). La valeur F0h correspond ainsi au codage sur 7 bits d'un SMS de « classe 0 », ne devant pas être enregistré dans la carte SIM lors de sa réception, mais seulement affiché (Message Flash). 04h indiquerait, par contre, que le message, codé sur 8 bits, n'appartient à aucune classe particulière et doit donc être automatiquement sauvegardé.
C'est là que l'on butera sur une caractéristique de certains téléphones récents, qui refusent de transmettre (et/ou d'afficher) les SMS appliquant ce codage utilisateur à 8 bits. Les mobiles les plus anciens ne souffrent généralement pas de cette limitation, et s'achètent d'occasion pour une bouchée de pain. Un modèle convenant particulièrement bien aux expériences qui nous intéressent est le Philips Fizz (information « libre de toute publicité » !).
- VAL$ précise la durée de validité du message, c'est-à-dire le temps pendant lequel le SMSC est prié de tenter d'acheminer le message si le mobile destinataire est indisponible (par exemple, arrêté). Cette valeur obéit à un codage complexe, mais voici quelques exemples amplement suffisants : 05h (30 minutes), 0Bh (1 heure), 17h (2 heures), A7h (24 heures), ABh (5 jours), FCh (60 semaines !).
- TXT$ représente le contenu utile du message, dont LTX$ indique la longueur en caractères. En codage 8 bits, ce sera tout simplement le nombre d'octets, mais en codage 7 bits, ce sera le nombre de septets, supérieur ou égal, donc, à la longueur de TXT$. Dans notre exemple, TXT$ contient le texte « Bonjour ! » codé sur 7 bits, mais voici une variante permettant d'opérer en clair sur 8 bits, à charge pour le SMSC d'opérer (si tel est son bon plaisir) la conversion en 7 bits :

PID$=Chr$(&H3F)
DCS$=Chr$(&H04)
TXT$="Bien le bonjour !"
LTX$=Chr$(Len(TXT$))

Des fortunes diverses...
Il est intéressant d'observer ce que devient un même message, selon qu'on le transmet avec tel ou tel modèle de téléphone, ou par l'entremise de tel ou tel opérateur français ou étranger. Voilà ainsi ce que donne notre exemple, confié à un Philips Fizz équipé d'une carte SIM émise par Orange avec le numéro +33 6 8a bc de fg (SMSC +33 6 89 00 40 00) : voir dump 1.

Dump 1 :
07 07 91 33 86 09 40 00 F0 11 FF 0B 91 14 97 ih
kj ml Fn 3F 04 17 11 42 69 65 6E 20 6C 65 20 62
6F 6E 6A 6F 75 72 20 21 FF ................. FF

La transmission a été effectuée (le 22/11/02 à 17h 30min 54s) vers un Motorola M3188, inscrit sur le réseau Bouygues, mais équipé d'une carte SIM suisse (numéro de la forme +41 79 hi jk lmn), dans laquelle il a été retrouvé ceci : voir dump 2.

Dump 2 :
01 07 91 33 86 09 40 00 F0 04 0B 91 33 86 ba dc
fe Fg 3F 00 20 11 22 71 03 45 00 11 C2 74 D9 0D
62 97 41 E2 B7 5B FD AE CB 41 21 FF ........ FF

On constate que la conversion de 8 bits en 7 bits a bien été effectuée, mais que l'indicateur de protocole est resté à 3Fh (il aurait tout aussi bien pu être remis à 00h par le SMSC). Mais certains téléphones se permettent de rafraîchir le message dans la carte SIM avant de l'envoyer, redemandant même parfois à cette occasion un numéro de destinataire pourtant déjà présent. Il n'est alors pas rare que PID$ et DCS$ soient rétablis tous deux à leur valeur par défaut de 00h.
En pareil cas, le SMSC n'effectue évidemment pas de conversion, d'où un affichage inintelligible, ou un avertissement du genre « Format de message incompatible » ou « données 8 bits ». Là encore, ce sont les modèles récents qui paraissent les plus enclins à ce genre de censure, et ce n'est peut-être pas par hasard...

Des essais gratuits !
Il est facile de procéder à des essais « à blanc », sans transmission effective (et donc gratuitement), en utilisant une carte SIM « de développement » basée sur une BasicCard 4 ou 5.
Donnant accès à toutes les fonctions du téléphone dans lequel on l'insère, mais ne s'inscrivant sur aucun réseau, une telle carte permet de simuler la transmission d'un SMS, puis de relire celui-ci à l'aide de tout bon éditeur de carte SIM. C'est à ce moment que l'on se rendra compte de ce que le téléphone s'est permis ou non de modifier subrepticement. Pour aller (beaucoup) plus loin dans cette passionnante exploration, on ne saurait trop conseiller la lecture attentive des spécifications GSM 03.40 et GSM 03.38. Rappelons qu'elles sont de nature publique, et téléchargeables gratuitement sur www.etsi.org !

Un exemple vécu !

Parmi les SMS non sollicités que l'on reçoit de plus en plus fréquemment, il arrive de trouver ce genre de « script », en provenance d'un numéro parfaitement inconnu :
//SCKE2 BEGIN:VCARD
N:Adeline
TEL:0610xxyyzz
END:VCARD

Le plus curieux est qu'en l'occurrence, l'utilisateur du mobile dont est censé émaner ce message ne voit pas mieux que le destinataire de quoi il peut bien s'agir : eh oui, il est techniquement possible de se faire passer pour quelqu'un d'autre ! En fait, nous sommes en présence d'une « carte de visite virtuelle » au format vCard, comme on en utilise couramment dans les e-mails. Selon la spécification Smart messaging de Nokia, l'en-tête //SCKE2 indique à tout téléphone compatible qu'il doit détourner ce SMS vers son port n° E2h, justement baptisé « Business card exchange ». De quoi se retrouver (sait-on jamais ?) avec une entrée indésirable (surtaxée ?) dans son annuaire personnel... Seulement, le numéro de téléphone 06 10 xx yy zz était ici... celui auquel le SMS est parvenu ! Fausse manœuvre involontaire, ou acte de malveillance ? Toujours est-il que, reçu fort à propos par un téléphone non compatible, ce message s'est trouvé enregistré dans la carte SIM comme un SMS ordinaire, prêt à subir une analyse approfondie...

Intercepter un paiement électronique !

Le paiement par téléphone portable bi-fente, équipé d'un lecteur de carte bancaire, est basé sur une carte SIM « phase 2+ », hébergeant une application SIM Toolkit spécialisée. Ce véritable logiciel embarqué communique, d'une part, avec l'utilisateur par l'afficheur et le clavier, et d'autre part, avec le serveur monétique par échange de SMS... pas forcément cryptés. Normalement émis et reçus sans que l'utilisateur ne s'en rende compte, ceux-ci peuvent être détournés de leur itinéraire normal, moyennant un peu d'astuce. L'exemple suivant est une facturette reçue par un mobile en réponse à une demande de rechargement de sa formule prépayée. À ce stade, il ne s'agit que d'une opération « pro-forma », que l'on peut valider (en l'authentifiant avec une carte bancaire) ou abandonner. Le mobile ayant initié la procédure de rechargement a été arrêté juste après la sélection du montant de la recharge, puis sa carte SIM a été retirée. Insérée immédiatement dans un autre téléphone, suffisamment vieux pour ne pas supporter le SIM Toolkit, celle-ci a accueilli la facturette comme un SMS ordinaire, on ne peut plus facile à examiner avec des outils courants : voir dump 3.

Dump 3 :
03 07 91 33 86 09 40 00 F0 04 05 83 12 00 F0 7F
··æ3å·@····â····
F6 20 11 71 71 81 31 00 8C 01 35 14 00 35 20 00
· ·qqü1·î·5··5 ·
00 25 00 09 78 17 18 11 11 17 02 68 52 10 30 36
·%··x······hR·06
38 33 3x 3x 3x 3x 3x 3x 30 34 00 00 00 01 82 06
83xxxxxx04····é·
2A 34 32 38 37 30 36 3x 3x 3x 30 30 30 37 31 08
*428706xxx00071·
18 44 66 6C 61 20 6D 6F 62 69 63 61 72 74 65 05
·Dfla mobicarte·
81 12 00 F0 FF FF FF FF FF FF FF 45 55 52 27 31
ü··········EUR'1
72 65 63 68 2E 32 35 1B 65 0A 2B 35 1B 65 20 6F
rech.25·e·+5·e o
66 66 65 72 74 73 0A 76 61 6C 69 64 69 74 05 3A
fferts·validité:
33 20 6D 6F 69 73 20 20 20 20 20 20 20 20 20 20
3 mois
20 20 20 20 FF FF FF FF FF FF FF FF FF FF FF FF
············

Le premier des 176 octets qu'occupe le SMS dans le fichier 7F10:6F3C de la carte SIM indique que nous sommes en présence d'un message reçu, non lu (il serait à 01h si on avait pris la peine de le faire défiler entièrement sur l'afficheur du mobile). Suit le numéro du SMSC (centre de messagerie) ayant acheminé le SMS, l'octet de type (91h) indiquant qu'il est présenté en format téléphonique international (+33 6 89 00 40 00). Le numéro de l'expéditeur du message (21000) est spécifique à l'opérateur (type 83h), et d'ailleurs accessible gratuitement, même en cas de crédit épuisé (sinon, on ne pourrait pas recharger !). Les octets 7F et F6 précisent que le SMS était destiné à la carte SIM, et qu'il est codé en format 8 bits. C'est ce qui explique que les textes que la carte SIM fera s'afficher sur l'écran apparaissent en clair dans notre bon vieil éditeur hexadécimal. Les sept octets qui suivent indiquent la date (17/11/02) et l'heure (17h 18min 13s) d'envoi du SMS, ainsi que le fuseau horaire local (ici 00h). L'octet 8Ch, enfin, correspond à la longueur (140 octets) du contenu utile du message, qui le suit d'ailleurs immédiatement. Il comprend (toujours en clair !), le montant à payer (25 euros), la date et l'heure d'établissement de la facturette, le numéro du téléphone à recharger, et ce qui ressemble fort à une référence de compte à créditer. Pour des raisons évidentes, quelques chiffres y ont donc été masqués... On peut légitimement se demander ce qui se passerait si l'on se risquait à modifier ces champs avant de réacheminer le SMS vers tel ou tel destinataire (mais il y a forcément des protections, hein ?).

Patrick Gueulle

Tous les ouvrages de l'auteur





Vous aimez cette page ? Partagez-en le lien sur les réseaux sociaux !

Facebook
Twitter
Google+
LinkedIn


Retour aux archives
Retour à l'accueil
[RSS]
Legal & cookies