#FactAero :
Comment (et pourquoi) j'ai trompé Flightradar24 ?!
Aujourd’hui, Mathieu revient sur l’action qu’il a menée vendredi dernier : la simulation sur Flightradar24 d’un vol au-dessus de Kiev de l’A225 détruit et au callsign évocateur. Il nous livre son récit au travers d’un #FactAero.
Le vendredi 11 mars 2022 en début de matinée, vous avez peut-être pu apercevoir sur le site Flightradar24 une piste présentée comme étant celle du fameux Antonov 225 « Мрія », affublée du callsign FCKPUTIN.
Cet appareil mythique dont il n’existait qu’un exemplaire entièrement terminé et en état de vol a pourtant été détruit par un bombardement dans les tous premiers jours de la guerre menée par la Russie contre l’Ukraine.
Capture d’écran – Pervi Kanal
Toutefois, son fantôme a pu tourner virtuellement autour de la capitale ukrainienne pendant 40 minutes environ avant que la supercherie soit détectée et interrompue par les administrateurs de Flightradar24.
Entre temps, beaucoup de spotters virtuels avaient reçu une alerte et repéré cette danse au milieu du désert que constitue le ciel Ukrainien en ce moment. Désert qui n’a d’ailleurs pas de réalité au-delà des écrans, comme les images quotidiennes des bombardements nous le rappellent cruellement.
Certains analystes OSINT qui utilisent ces outils pour surveiller l’activité des aéronefs circulant aux frontières de la zone ont également repéré ce dernier tour de piste.
Ce chant du cygne de Мрія était pendant quelques minutes la trajectoire la plus suivie du site avec plus de 58000 personnes l’ayant affichée simultanément.
Au-delà du « message de protestation » et de l’hommage à l’appareil et au personnel d’Antonov, un de mes buts principaux était évidemment de démontrer que ces sites peuvent facilement être trompés et qu’il faut donc être vigilant sur l’interprétation des informations qu’on peut y voir.
C’était d’ailleurs bien affiché dans mon tweet de « revendication » consultable à ce lien.
Les réactions que j’ai pu apercevoir (principalement sur Twitter) étaient plutôt positives et amusées.
Certains ont imaginé que le transpondeur de Mriya avait été récupéré et accroché sur un drone ou emporté en vol par le fantôme de Київ*. D’autres, que c’était directement une initiative de Flightradar24.
Quelques-uns enfin ont trouvé cela stupide, puéril ou dangereux. 🤷🏼
En fait, il s’agissait d’un « spoof » (littéralement parodie), c’est-à-dire la production et l’envoi à Flightradar24 de données à peu près vraisemblables qui ont donné l’illusion de la présence de l’avion.
Flightradar24 n’avait pas été préalablement informé et leurs conditions d’utilisation proscrivent d’ailleurs explicitement ce que j’ai fait.
L’extrait des CGU de Flightradar24 prohibant l’envoi de données fabriquées de toutes pièces.
Si l’on oublie les possibilités d’emport du transpondeur de l’AN-225 dans un autre aéronef, la reprogrammation d’un transpondeur neuf avec le même code hexadécimal et les solutions de cet acabit, deux autres voies étaient possibles.
- La première, celle de forger directement des messages numériques, c’est-à-dire des suites d’octets contenant la position, la vitesse, le callsign etc. similaires à ceux produits par le logiciel usuel « dump1090 » qui est couplé aux récepteurs radios utilisés par les amateurs (qui constituent une grande partie du réseau de surveillance de Flightradar24) puis d’envoyer ces messages vers leur serveur.
En somme de créer une version modifiée de dump1090 qui aurait produit de la donnée crédible sans avoir du tout besoin d’un récepteur radio. - Une seconde méthode possible – celle finalement utilisée – était d’utiliser une chaîne Flightradar24 tout à fait normale, c’est-à-dire un récepteur radio standard et les logiciels habituels sans aucune modification mais d’utiliser un second appareil pour émettre directement des messages radio imitant une partie de ceux d’un véritable transpondeur.
La méthode retenue augmente un peu la portée de la démonstration car moyennant une radiodiffusion effective des signaux (OTA : over the air), elle permet par exemple d’utiliser un récepteur Flightradar24 de manière « non coopérative », c’est à dire à l’insu de son propriétaire et de son éventuel bon vouloir.
Au-delà et puisque c’est le nom de la technologie sous-jacente, elle met en évidence de façon « pratique » certaines faiblesses de la norme ADS-B qui ont déjà été soulignées dans des papiers de recherche, notamment celui écrit par Andrei Costin et Aurélien Francillon et consultable ici ou encore par un spécialiste en sécurité informatique lors d’une conférence DEFCON en 2012.
Dans le jargon cybersécurité, il existe un acronyme et même un blog « PoC||GTFO » (Proof of Concept or Get The Fuck Out) et c’est aussi dans cette tradition que s’inscrit le test grandeur nature effectué.
Je ne suis absolument pas spécialiste du contrôle aérien ni de l’ADS-B et donc je me garderai bien de conclure sur l’impact potentiel sur l’infrastructure aérienne réelle.
Les radars primaires et secondaires qui maillent le territoire n’y seraient pas sensibles car ils ont (me semble-t-il) besoin d’un écho (plot) réel correspondant à la présence d’un objet physique dans le faisceau au moment de l’illumination. Il y a peut-être toutefois des cas où les technologies de fusion des pistes pourraient être trompées et un plot réellement présenté à des contrôleurs ? Je serais curieux d’avoir l’avis de spécialistes.
Naïvement, j’ai tendance à croire qu’en revanche, les TCAS (dispositifs anticollision embarqués) basés eux aussi sur l’ADS-B pourraient y être plus sensibles et, en présence de traces simulées, émettre en cabine des alertes perturbant l’équipage de conduite. Le fait est que l’ADS-B n’offre aucune étape d’authentification (comme il en existe par exemple dans les communications réseau via par exemple le chiffrement par clé privée et le déchiffrement par clé publique) et que l’existence depuis quelques années d’émetteurs SDR peu coûteux permettant de mettre en œuvre des spoofing comme celui employé invite à repenser aux limites de cette technologie et en tout cas à mieux les connaître.
Cette remarque est également valable pour des technologies alternatives similaires comme les FLARM, les systèmes de « Remote ID » pour drones etc…
Sans mécanisme d’authentification, tous ces signaux sont falsifiables et ont été ou seront falsifiés un jour pour des usages malicieux.
Pour revenir plus spécifiquement à ma manipulation « Мрія » sur Flightradar24, j’ai utilisé un dispositif SDR HackRF qui coûte environ 300€ (à droite sur la photo ci-dessous du montage de test) et qui, comme son nom l’indique permet via son logiciel de moduler et émettre des signaux radio (dans une gamme de fréquence importante, permettant l’exploration et l’expérimentation vraiment intéressante autour des signaux radio).
J’aurais aimé disposer de tels outils quand j’étais étudiant !
De manière à rester totalement dans les règles, aucune radiodiffusion n’a jamais eu lieu. Émettre « over the air » aurait été à la fois illégal et dangereux !
Plutôt que d’équiper l’émetteur et le récepteur d’antennes adaptées à la fréquence de l’ADS-B (1090 MHz), les signaux produits ont été directement acheminés du HackRF vers le récepteur FlightAware Pro Stick Plus via un câble coaxial. Même en réglant la puissance d’émission au minimum, il y avait un risque de dégrader le récepteur, ou de saturer les niveaux de réception et c’est la raison pour laquelle des dispositifs atténuateurs sont visibles sur l’image.
J’ai ensuite récupéré sur GitHub quelques projets « adsb-out » déjà existants. La plupart de ces derniers permettent la création « hors ligne » d’un fichier de signaux (on parle d’échantillons) puis sa diffusion via un petit logiciel associé au HackRF appelé « hackrf_transfer ».
Ces solutions présentent toutes un certain nombre de limitations. Les fichiers d’échantillons générés sont rapidement très volumineux et limitent donc la durée du spoof ; le signal généré est « statique », c’est-à-dire qu’il simule toujours les mêmes coordonnées géographiques, ne permettant que de faire afficher sur une carte un objet immobile.
Décidé à améliorer ces aspects, j’ai utilisé comme base ces projets récupérés puis ai consulté la documentation officielle accessible plus ou moins librement (certains documents de normes sont d’accès payant) et ensuite réimplémenté une version améliorée qui permet la création et la diffusion des signaux simulés en temps réel, avec des trajectoires simples dont le but n’est que de produire une trace mobile sur la carte lors des tests.
J’avais déjà commencé ce projet personnel il y a 2 ou 3 ans mais motivé par la situation, j’ai terminé la « mise au propre » récemment. Le développement doit représenter au total une grosse dizaine de soirées (et les mauvaises nuits où l’on pense à la résolution des bugs qui vont avec…).
La dernière version permet même de simuler plusieurs aéronefs en même temps.
Elle est disponible sur ce repository.
Pour la diffusion vers Flightradar24, lors de la configuration du point de « feed », je lui ai attribué des coordonnées géographiques fictives correspondant à un emplacement près de Kiev, le but étant principalement d’éviter un filtrage lié à une distance calculée trop grande entre la station réceptrice et l’objet capté. Il aurait en effet été peu crédible qu’une station située en France capte un aéronef émettant au-dessus de l’Ukraine.
C’est d’ailleurs un des éléments de configuration des logiciels de ce genre qui placent un seuil de distance au-delà duquel les détections ne sont pas considérées (car elles sont souvent trop intermittentes).
Cela montre que Flightradar24 n’utilise pas de mécanisme de filtrage GeoIP pour corréler la position de la station indiquée par l’utilisateur avec celle de l’origine de l’adresse IP qui transmet les données.
C’est un des doutes qui subsistait avant l’opération, les seules répétitions ayant eu lieu sur une version « locale » très simplifiée.
J’ai également désactivé la possibilité offerte par Flightradar24 d’utiliser le récepteur pour faire du positionnement par multilatération (MLAT pour les connaisseurs). Ici aussi, le but était d’éviter une éventuelle détection de données incohérentes et de toute façon, un seul récepteur allait « capter » l’aéronef simulé.
Le seul échange que j’ai eu avec Flightradar24 suite à cette expérimentation a été pour leur demander s’il était possible de réactiver mon compte (en étant honnête et en affichant ne pas pouvoir promettre de ne pas recommencer…).
La réactivation a été refusée, ce qui est bien entendu leur droit (mais si vous avez de bonnes connaissances, vous pouvez quand même leur relayer à nouveau ma demande voire négocier une autorisation) !
Extrait de la communication par mail avec le support Flightradar24
Pour aller un peu plus loin, en plus des réflexions sur l’ADS-B et l’authentification des signaux radio, il y a certainement des mécanismes/algorithmes intéressants à développer pour identifier/détecter/filtrer automatiquement ce genre de spoof sur les sites grand public.
Manifestement, aucune mesure de ce genre n’est actuellement implémentée sur le site Flightradar24.
J’espère en tout cas que l’hypothétique apparition d’une trace virtuelle de B-52 en direction de Moscou ne viendra jamais alimenter de discours de propagande étatique pour justifier une éventuelle escalade.
Pourtant, la mauvaise foi éhontée des déclarations officielles Russes peut amener à douter de ce qui est aujourd’hui une hypothèse à exclure totalement ou pas, alors qu’hier n’importe quel individu rationnel aurait jugé celle-ci absolument farfelue.
Mathieu Peyréga
@MathieuPeyrega
* : Le fantôme de Київ (Kiev) est un pilote de chasse Ukrainien, réel ou fantasmé, qui aurait abattu un nombre important d’aéronefs russes le premier jour du combat – 24 février 2022 – donnant naissance à cette légende.
Valentin | @VaIentinn
BONUS : Ils en ont parlé
Les médias
Les réseaux sociaux
Plus de 200k interactions et 16 millions de personnes atteintes.
