Experimental Validation and Mitigation of RRC Storm Attacks in 5G Cellular Networks

Chaque fois qu'un téléphone mobile se connecte à un réseau 5G, il doit d'abord franchir une brève porte déverrouillée. Avant que le réseau ne puisse vérifier l'identité de l'utilisateur ou contrôler son mot de passe, le téléphone doit demander la permission de parler. Cette poignée de main initiale est essentielle au fonctionnement du système, mais elle constitue également une vulnérabilité. Parce que le réseau doit allouer des ressources pour gérer la requête avant de savoir si la demande est légitime, un acteur malveillant peut exploiter cette faille. En envoyant un déluge de fausses requêtes qui ressemblent à de réelles tentatives de connexion mais qui ne se terminent jamais, un attaquant peut encombrer le système. Cela crée un embouteillage où la puissance de traitement du réseau est consommée par des tâches incomplètes, ne laissant plus de place aux personnes réelles pour passer des appels ou envoyer des messages. Ce type spécifique de perturbation, connu sous le nom de tempête de signalisation (signaling storm), est un साथ de menace théorique dans le monde de la sécurité sans fil depuis longtemps, mais prouver qu'il fonctionne dans le monde réel et trouver un moyen de l'arrêter est resté un défi.

Une équipe de chercheurs de l'Université des sciences et technologies King Abdullah a maintenant fait passer ce problème du domaine des simulations informatiques au monde physique. Ils ont construit un véritable réseau 5G en utilisant des radios logicielles et des téléphones mobiles commerciaux pour démontrer exactement comment un attaquant pourrait submerger une antenne-relais. Plus important encore, ils ont conçu et testé une défense légère qui s'exécute directement sur la tour elle-même. Leur travail montre que, bien qu'un attaquant puisse effectivement couper une cellule en inondant celle-ci de requêtes de connexion inachevées, un système de surveillance intelligent peut détecter le schéma de cet abus et le bloquer sans arrêter les utilisateurs légitimes. Les chercheurs ont publié tout leur code en open source, permettant à d'autres de vérifier leurs conclusions et de construire de meilleures défenses.

Pour comprendre l'attaque, il faut d'abord regarder comment un téléphone rejoint un réseau 5G. Lorsqu'un appareil s'allume, il envoie un signal à la tour la plus proche, appelée station de base, pour demander la connexion. La tour répond avec un identifiant temporaire et une autorisation d'envoyer plus de données. Le téléphone envoie ensuite une requête formelle pour établir une connexion. À ce stade, la tour a créé un petit espace mémoire, ou contexte, pour suivre ce téléphone spécifique. Ce n'est qu'après cet échange que le réseau commence le processus d'authentification de l'utilisateur. Dans un scénario normal, le téléphone termine la poignée de main et la connexion devient active. Cependant, un attaquant peut exploiter le fait que la tour crée cet espace mémoire avant de savoir si l'utilisateur est réel. Un dispositif malveillant peut répéter ce processus, en envoyant la requête initiale et le message de suivi, mais en s'arrêtant délibérément avant l'étape finale. La tour se retrouve alors à détenir un espace mémoire pour un téléphone qui n'arrive jamais, un état que les chercheurs appellent une connexion « à moitié ouverte » (half-open).

Les chercheurs ont mis en place un environnement de test pour voir à quelle vitesse cela pouvait mal tourner. Ils ont utilisé un ordinateur de bureau exécutant un logiciel spécialisé pour agir comme la station de base, connecté à deux dispositifs radio qui transmettaient des signaux par les ondes. Une radio agissait comme l'attaquant, tandis qu'un téléphone commercial standard servait de victime. Lorsque l'attaquant a commencé à envoyer ces requêtes incomplètes, les résultats ont été immédiats. La mémoire de la station de base s'est remplie de ces connexions fantômes. Lors de leur premier test, le système a atteint sa limite de seize utilisateurs en moins d'une seconde. Lorsqu'ils ont augmenté la capacité à quatre-vingt-dix utilisateurs, le système s'est quand même effondré en moins de quatre secondes. Une fois la mémoire pleine, la tour ne pouvait plus accepter de nouvelles requêtes. Lorsque les chercheurs ont tenté de connecter le téléphone commercial, celui-ci a échoué à plusieurs reprises, incapable d'obtenir un signal. L'attaque avait réussi à créer un déni de service, bloquant les utilisateurs réels du réseau.

Ayant prouvé que l'attaque fonctionne, l'équipe s'est tournée vers la solution. Ils avaient besoin d'un moyen de distinguer un réseau chargé avec beaucoup d'utilisateurs réels d'un réseau sous attaque. Dans une situation normale de haute charge, la plupart des téléphones qui commencent le processus de connexion le terminent. Lors d'une attaque, le ratio des connexions terminées par rapport aux connexions commencées chute brutalement car l'attaquant ne termine jamais la poignée de main. Les chercheurs ont programmé la station de base pour surveiller ce ratio. Si le nombre de connexions terminées tombe en dessous d'un certain niveau par rapport au nombre de connexions commencées, le système sait qu'une attaque est en cours.

Une fois l'attaque détectée, le système devait agir sans couper toute la cellule. Les chercheurs ont développé une méthode qui regroupe les requêtes suspectes en fonction de leur provenance. Ils ont utilisé une valeur appelée « avance de temps » (timing advance), que la tour calcule pour déterminer la distance d'un téléphone. Bien que cette valeur ne soit pas assez précise pour identifier un appareil spécifique, elle est assez précise pour regrouper les appareils situés à une distance similaire. Le système compte le nombre de connexions à moitié ouvertes provenant de chaque groupe de distance. Si un groupe présente un pic soudain de connexions incomplètes, le système marque ce groupe comme suspect.

Lorsqu'un groupe est signalé, la station de base modifie son comportement pour toute nouvelle requête provenant de cette distance spécifique. Au lieu de donner à ces nouvelles requêtes tout le temps nécessaire pour se terminer, le système leur accorde une fenêtre très courte pour achever la poignée de main. Pour un utilisateur légitime, cette fenêtre est amplement suffisante pour se connecter. Pour l'attaquant, qui essaie d'enchaîner des milliers de fausses requêtes le plus rapidement possible, la fenêtre est trop courte pour accumuler le nombre nécessaire de connexions à moitié ouvertes. Les requêtes de l'attaquant expirent et sont effacées, libérant ainsi les ressources.

Les chercheurs ont testé cette défense dans le même montage en conditions réelles. Lorsque l'attaque a commencé, le système a détecté la chute des connexions terminées et a activé la défense. L'attaquant a été immédiatement empêché de remplir la mémoire. Crucialement, le téléphone commercial a également pu se connecter, bien qu'il ait dû essayer plusieurs fois car il se trouvait dans le même groupe de distance que l'attaquant. Le téléphone s'est finalement connecté et a atteint la pleine vitesse. Ce résultat a mis en évidence le compromis de la défense : les utilisateurs légitimes dans la même zone que l'attaquant peuvent subir un léger retard ou devoir réessayer, mais le réseau dans son ensemble reste ouvert. Sans la défense, l'ensemble du réseau aurait été coupé.

L'étude conclut que, bien que la tempête de signalisation RRC soit une menace réelle et dangereuse, elle n'est pas inarrêtable. En surveillant le flux de requêtes de connexion et en appliant un filtre simple et ciblé basé sur la distance, un réseau peut se protéger contre le risque d'être submergé. Les chercheurs ont souligné que leur défense est légère et s'exécute directement sur l'équipement réseau, ce qui la rend pratique pour un déploiement réel. Ils ont également noté que si un attaquant se déplace ou utilise plusieurs appareils dans différents lieux, la méthode actuelle pourrait être moins efficace, suggérant que les défenses futures pourraient combiner la distance avec d'autres caractéristiques pour attraper des attaques plus complexes. En publiant leur travail en open source, l'équipe a fourni à la communauté un modèle fonctionnel pour tester, améliorer et adapter, transformant une vulnérabilité théorique en un problème résolu doté d'une défense pratique.