[accueil]
Paru dans Pirates Magazine n°15
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 !
|
|
Patrick Gueulle
Tous les ouvrages de l'auteur
Vous voulez soutenir une information indépendante ? Rejoignez notre Club privé !
[contact & legal & cookies] [since 1997]