Détournement de session et arnaque au faux code : le canal USSD comme surface d’attaque

Par J. Ramses DAGBAN

                 Cyber Security Analyst

L’USSD est le canal principal du Mobile Money: il fonctionne sur tous les téléphones, sans connexion ni application. Mais ce fonctionnement (sessions courtes, échanges en clair et commandes textuelles) en fait une cible privilégiée, avec des risques bien distincts du SIM Swap.

On distingue deux grands types d’attaques sur l’USSD :

• Techniques: l’exploitation du cycle de vie de la session (sessions abandonnées, absence de délai d’expiration, force brute sur le PIN).
• Humaines: la manipulation de l’utilisateur, à qui l’on dicte une syntaxe malveillante pour lui faire valider un transfert à son insu (l’arnaque au faux code de confirmation).

Voici un décryptage de ces méthodes, suivi des mesures concrètes pour sécuriser la passerelle USSD (USSDGW) et le Core Mobile Money.

1. Le cycle de vie d’une session USSD

Une session USSD est temporaire et conserve un état actif. Dès l’ouverture (par exemple *145#), le système attribue un Session ID qui stocke le contexte (menu en cours, compte, montant saisi) jusqu’à la fermeture.

Le point critique: toute donnée conservée dans ce contexte (un compte ciblé ou un montant non validé) reste exploitable si la session ne se ferme pas proprement.

2. Technique : attaques sur la session et le PIN

·       Réutilisation de session abandonnée (stale session)

Si un utilisateur quitte un menu financier sans le terminer et que la passerelle ne détruit pas immédiatement le Session ID, un contexte partiellement authentifié peut subsister. Sur des implémentations faibles, une requête ultérieure peut reprendre ce contexte, court-circuitant une étape de vérification.

Solution : détruire immédiatement le Session ID dès la fin de l’opération, l’abandon par l’utilisateur ou l’expiration du temps imparti.

• Absence de délai d’expiration strict (timeout)

Une session qui reste ouverte trop longtemps élargit la fenêtre d’interception et de reprise de contexte.

Solution : imposer une fermeture automatique après 30 à 60 secondes d’inactivité maximum, sans possibilité de contournement applicatif.

• Attaque par force brute sur le code PIN

Un PIN Mobile Money court est trivialement énumérable si aucun verrouillage n’existe. Un attaquant disposant du canal (post SIM Swap, ou terminal volé) peut tenter les combinaisons.

Solution : bloquer automatiquement le compte après 3 échecs consécutifs, ajouter un délai d’attente progressif et envoyer une alerte.

• Filtrage des données saisies (input sanitization)

Les caractères spéciaux saisis dans les menus (*, #, ;, guillemets) doivent être filtrés par le backend avant tout traitement pour prévenir les injections dans la base de données, les logs ou les commandes.

3. Humaine : l’arnaque au « faux code de confirmation »

C’est la méthode la plus redoutable : elle contourne la sécurité sans aucune faille technique. La victime effectue le virement elle-même, persuadée d’annuler une erreur ou d’accepter un remboursement.

Le mode opératoire : l’escroc appelle sa cible (souvent juste après lui avoir envoyé un faux SMS de dépôt) en se faisant passer pour le service client de l’opérateur ou de la banque. Il lui dicte ensuite une commande USSD complète : « Pour annuler l’erreur, tapez exactement : *145*2*1*<numéro>*<montant>*<PIN># »

En réalité, cette séquence n’annule rien : elle compose un transfert sortant du compte de la victime vers celui de l’escroc, PIN compris. La victime, en tapant elle-même le code, franchit toutes les vérifications légitimes.

Pourquoi les contrôles classiques échouent

• La session est authentique (bon MSISDN, bon PIN).
• Le montant et le bénéficiaire sont saisis par la victime.
• Aucune anomalie technique n’est détectable au niveau protocole.

Seuls des contrôles comportementaux et la sensibilisation peuvent l’endiguer.

4. Contrôles applicatifs différenciants

• Écran de confirmation explicite et non ambigu : avant tout débit, afficher un récapitulatif clair (Transfert de 50 000 XOF vers 90XXXXXX : Confirmer ?) plutôt qu’une validation implicite par PIN.
• Délai / friction sur les transferts atypiques : temporisation ou double confirmation pour un premier transfert vers un bénéficiaire jamais utilisé.
• Plafonds glissants limitant l’impact d’une session frauduleuse unique.
• Détection de corrélation appel entrant ↔ transaction lorsque la donnée est disponible.

5. Conduite à tenir et sensibilisation

Le message opérationnel à diffuser en continu tient en une phrase : aucun code USSD légitime ne vous est jamais dicté par téléphone pour « annuler » ou « rembourser ». Toute demande de ce type est une tentative de fraude.

En cas d’incident confirmé : geler le bénéficiaire, remonter le graphe transactionnel vers d’éventuels comptes mules, notifier le MFIN-CERT.