Examiner les données WiFi sur un vol Southwest sans accès à Internet

 (jamesbvaughan.com)
1 points par GN⁺ 2023-09-29 | 1 commentaires | Partager sur WhatsApp
  • Lors d’un vol direct St. Louis–Oakland au retour de Strange Loop, l’échec du paiement de 8 $ pour Internet a conduit à vérifier quelles données restaient accessibles via le WiFi à bord sans accès Internet
  • Dans les requêtes réseau du portail WiFi de Southwest, un endpoint current.json qui répondait systématiquement avec succès a été repéré, et sa réponse semble fournir les données de base de la page d’état du vol
  • Cet endpoint pouvait être appelé avec curl sans cookie ni en-tête, et renvoyait notamment l’altitude, les coordonnées, l’heure d’arrivée estimée, la vitesse sol, la distance restante, la progression du vol et l’état de la liaison satellite
  • À partir des données collectées, l’altitude, l’ETA et la vitesse sol ont été visualisées ; en dehors de la phase de descente, l’altitude ne variait que d’environ 20 à 30 pieds
  • Ce n’était pas une découverte particulièrement utile, mais le seul JSON d’état du vol exposé par le portail WiFi à bord suffit pour faire de la collecte et de l’analyse de données en vol

Exploration du WiFi à bord après un échec de paiement

  • Lors d’un vol direct St. Louis–Oakland au retour de Strange Loop, l’auteur a tenté d’acheter l’accès Internet à 8 $ via le portail WiFi à bord de Southwest, mais aucun moyen de paiement n’a été accepté
  • La page web n’affichait aucun message d’erreur utile, ce qui a conduit à examiner les requêtes en échec dans les outils de développement réseau du navigateur
  • Les requêtes échouées donnaient peu d’indices, mais une requête current.json qui réussissait de façon répétée a attiré l’attention

Les données d’état de vol renvoyées par current.json

  • La réponse de current.json semble alimenter la page d’état du vol du portail WiFi à bord
  • L’exemple de réponse contient notamment les valeurs suivantes
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: une valeur qui semble représenter la progression du vol
    • altVal: l’altitude actuelle
    • lat, lon: les coordonnées actuelles
    • dtzone: le fuseau horaire de destination
    • within_us: si le vol se situe aux États-Unis
    • etad: l’heure estimée d’arrivée à destination
    • gspdVal: la vitesse sol actuelle
    • ttgc: une valeur qui semble représenter le temps restant
    • dist_remain: la distance restante
    • actime24: l’heure actuelle dans un certain fuseau horaire

Reproduire la requête du navigateur avec curl

  • La fonction “Copy as cURL” du navigateur a permis d’obtenir rapidement la commande d’appel de l’endpoint
  • Cette fonction est présente dans Firefox et dans les navigateurs basés sur Chromium, et elle est utile pour reproduire une requête envoyée par le navigateur avec les mêmes en-têtes
  • L’expérience a montré que les cookies et en-têtes inclus dans la requête n’étaient pas indispensables, et qu’un simple appel curl comme celui-ci suffisait à récupérer les données
curl 'https://getconnected.southwestwifi.com/current.json'
  • Ensuite, une boucle a été lancée pour récupérer les données toutes les 30 secondes et les accumuler dans un fichier de logs
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

Questions restantes sur les champs de réponse

  • La plupart des champs étaient intuitifs, mais certaines valeurs restaient ambiguës
    • la différence entre sat_commlink_portal.status et satcomm_status.commlink
    • si pcent_flt_complete repose sur la distance ou sur le temps estimé
    • dans quelle mesure altVal, etad et gspdVal fluctuent pendant le vol
    • ce que signifie ac dans actime24
  • actime24 semble correspondre à l’heure actuelle à destination plutôt qu’à l’heure actuelle à la position de l’avion, ce qui rend l’interprétation de ac comme “aircraft” peu convaincante

Visualisation des données collectées en vol

  • Les données collectées ont servi à visualiser les variations d’altitude, d’ETA et de vitesse sol

  • Variation de l’altitude

    • L’objectif initial était d’évaluer le niveau de bruit dans les données d’altitude
    • Comme l’échelle globale masquait ce bruit, la phase de descente a été retirée, ce qui a montré des variations d’environ 20 à 30 pieds
    • Cette stabilité était supérieure à ce qui était attendu, sans qu’il soit possible de juger de la plage normale ou de la précision réelle des données

  • Variation de l’ETA

    • L’ETA était supposée rester raisonnablement stable et, après le départ initial, elle est effectivement restée stable pendant un vol sans incident
    • En cas de retard à l’atterrissage dû à la météo, il reste à voir si l’ETA augmenterait progressivement ou grimperait brusquement en fin de trajet

  • Variation de la vitesse sol

    • La vitesse sol s’est elle aussi révélée stable, conformément aux attentes
    • Au départ, l’unité affichée avait été indiquée en MPH, mais des lecteurs de HN ont signalé qu’il s’agissait probablement de nœuds
    • La collecte n’ayant pas commencé dès le début du vol, il n’a pas été possible d’observer la courbe d’approche de la vitesse de croisière

Conclusion

  • Les données collectées n’ont rien révélé de particulièrement utile ou surprenant
  • Même sans accès Internet, le JSON d’état du vol exposé par le portail WiFi à bord permet de collecter et d’analyser des données pendant le vol

À lire aussi

1 commentaires

 
GN⁺ 2023-09-29
Avis sur Hacker News

  • Quand mon fils avait environ 9 ou 10 ans, je l’ai vu utiliser Internet sur son téléphone dans l’avion. Comme je n’avais jamais payé l’accès, je lui ai demandé comment il faisait.
    Il m’a dit qu’un camarade de classe lui avait montré qu’il suffisait de modifier les chiffres de l’adresse IP attribuée par DHCP dans les réglages Wi-Fi. À l’époque, American Airlines semblait se contenter d’autoriser les IP des utilisateurs payants ; si quelqu’un devinait une adresse IP dans la plage 192.168 et se faisait passer pour un autre, il pouvait récupérer la connexion sans authentification supplémentaire.
    Je lui ai bien dit de ne pas le faire, mais j’étais quand même un peu fier de son culot à essayer.

    • Je faisais souvent quelque chose de similaire sur les anciens hotspots Wi-Fi payants.
      D’abord, avec nmap -sP, je faisais un ping sweep de tout le sous-réseau pour remplir le cache ARP avec des adresses IP/MAC utilisables, puis je changeais l’adresse IP et l’adresse MAC une par une jusqu’à trouver une combinaison qui passait le pare-feu.
      Le fait d’avoir travaillé comme ingénieur NOC chez Wayport (aujourd’hui AT&T WiFi) m’a aidé à comprendre l’architecture.
    • J’utilisais la même méthode dans les avions et les hôtels, avec un meilleur taux de réussite dans les hôtels.
      Parce qu’il était moins probable que quelqu’un utilise la connexion à ce moment précis, et moins probable aussi qu’elle soit coupée.
      Quand j’étais jeune, je faisais aussi un autre petit hack : à l’époque où les compagnies aériennes vendaient ou louaient des écouteurs spéciaux pour les films à bord, le port était composé de deux trous côte à côte et la fiche de deux tubes.
      Avant l’embarquement, je récupérais quelques pailles dans un fast-food du terminal, si possible des pailles coudées, je les emboîtais pour faire une longue paille, j’en mettais une extrémité dans le port et l’autre à l’oreille, et je pouvais écouter gratuitement l’audio des films.
    • Il y a quelques années, dans un avion Southwest, j’avais oublié de désactiver OpenVPN, et j’ai pu accéder à Internet via le tunnel sans payer.
      À l’époque, il semble qu’ils ne bloquaient que les ports courants (80, 443, 53, etc.) pour les utilisateurs qui n’avaient pas payé ; depuis, cette faille a été corrigée.
    • C’est une anecdote vraiment étonnante.
      L’état de la sécurité des Wi-Fi ouverts est en fait assez regrettable, et je ne vois pas très bien comment les compagnies aériennes pourraient faire beaucoup mieux facilement.
      Si les appareils le prennent en charge, on pourrait utiliser Opportunistic Wireless Encryption [1] et lier l’authentification à une session OWE précise plutôt qu’à une adresse MAC précise, mais je ne sais pas à quel point une session OWE est stable.
      S’il faut se reconnecter à chaque changement de point d’accès, ce serait très pénible.
      C’est dommage que la sécurité du Wi-Fi payant ou gratuit ne soit toujours pas un problème résolu, et qu’il faille encore des solutions temporaires sur mesure comme des portails captifs fragiles qui doivent laisser passer du trafic optionnel, par exemple pour le paiement, 3DS ou les e-mails de réinitialisation de mot de passe.
      Ce serait bien aussi qu’il existe un endpoint standard et une API permettant au client de savoir s’il est actuellement connecté, limité, ou s’il doit payer/s’authentifier, et qu’il puisse recevoir un jeton d’authentification pour se reconnecter naturellement dans la même session.
      Hotspot 2.0 et WPA-EAP (WPA Enterprise) existent bien, mais ils sont plutôt conçus respectivement pour les réseaux de hotspots opérés par les opérateurs télécoms et les environnements d’entreprise, donc ils ne correspondent pas vraiment à l’usage « payer via un portail web ».
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • À une époque, il existait des applis qui scannaient les adresses IP et MAC d’un réseau déjà connecté à Internet.
      Si l’on réglait sa configuration sur l’une de ces adresses MAC, on pouvait utiliser seul cette connexion une fois que l’utilisateur d’origine avait terminé.
      En déplacement professionnel, je refusais de payer le Wi-Fi, et c’était assez utile à l’époque où les aéroports et les cafés facturaient encore l’accès.
      Aujourd’hui, ce n’est presque plus nécessaire, mais cela peut encore aider dans les endroits où l’accès reste payant.

  • « D’après ces données, l’altitude de l’avion ne variait que d’environ 20 à 30 pieds. C’est plus stable que je ne l’aurais cru ! »
    Les pilotes automatiques sont très performants et asservissent les commandes sur la base de l’altitude barométrique.
    Beaucoup d’encodeurs d’altitude barométrique des avions modernes, par exemple ceux qui alimentent l’altitude transmise par le transpondeur au radar SSR ou via ADS-B, ont une résolution d’encodage de 25 pieds.
    Il est très probable que ce que l’on voit ici corresponde aussi à cette résolution de 25 pieds ; il existe aussi des encodeurs à 10 pieds, mais 25 pieds est très courant.

    • Je ne sais pas quelles données de capteurs reçoit l’API mentionnée dans l’article, mais la plupart des avions de ligne diffusent aussi la précision de la position détectée, ainsi que la précision de la position verticale/de l’altitude.
      Sur la carte https://globe.adsbexchange.com/, cliquez sur un avion puis faites défiler la barre latérale de gauche jusqu’en bas pour voir la section « Accuracy ».
      ADS-B Exchange n’affiche pas Rc/v, la précision de position verticale, mais montre les autres valeurs.
      Pour plus de détails, voir https://mode-s.org/decode/content/ads-b/7-uncertainty.html.
    • Sur un petit avion, une variation de 20 à 30 pieds n’a rien d’anormal quand on pilote manuellement avec attention.
      En croisière, un avion de ligne utilise évidemment très probablement le pilote automatique.
      Il y a quelque temps, alors que je bénéficiais d’un suivi de vol, j’ai perdu environ 100 pieds et le contrôleur m’a demandé si tout allait bien ; j’ai été surpris de voir qu’il surveillait d’aussi près.
      J’avais oublié d’enfiler mon gilet de sauvetage avant un passage au-dessus de l’eau et, pendant que je le mettais, j’avais confié les commandes à ma femme, qui n’avait pas encore pris de cours de pilotage.
      Elle a ensuite obtenu sa licence elle aussi, et j’ai trouvé intéressant que le suivi ATC soit assez précis pour intervenir.
    • Cela aurait été sympa d’enregistrer avec un téléphone une trace GPS incluant l’altitude pour comparer.
      La pression barométrique et le GPS sont différents, et je me demande aussi si la différence sauterait aux yeux quand on recale l’altimètre barométrique sur un autre calage AWOS.
      Je ne sais pas comment cela se passe sur les gros porteurs, mais sur les petits avions il faut régler l’altimètre en fonction de la météo locale.
      La station météo mesure la pression à son altitude, annonce par radio une valeur « corrigée au niveau de la mer », et on la saisit dans l’altimètre pour corriger l’indication d’altitude barométrique selon les variations météo locales.
      Même après un vol d’une heure en revenant au même endroit, le calage altimétrique peut avoir changé de quelques millibars.
    • Avec l’introduction du RVSM, cela a probablement gagné en précision.
      La séparation verticale entre avions était de 2000 pieds, puis elle a été réduite à 1000 pieds au début des années 2000.
    • J’ai lu qu’une précision excessive pouvait, dans certains cas, devenir dangereuse.
      Par exemple, si un pilote vise 3000 pieds, il se retrouve exactement à 3000 pieds ; si un autre pilote, sur une trajectoire de collision, veut lui aussi 3000 pieds, la collision peut devenir certaine.
      Avec une altitude moins précise, cela aurait plus de chances de n’être qu’un quasi-accident.
      La solution était probablement d’éviter les chiffres ronds et d’utiliser plutôt 2950 pieds ou 3050 pieds.
      Les détails sont peut-être inexacts, mais je suis assez sûr que ce problème a été étudié sérieusement.

  • J’ai découvert la même chose il y a quelques mois et j’ai créé un traqueur de vols en CLI qui utilise cette API.
    Je l’ai testé avec quelques compagnies aériennes et, comme elles utilisaient toutes le même fournisseur d’Internet à bord, il fonctionnait presque parfaitement.
    [1] : https://github.com/NalinPlad/OuterFlightTracker

    • Génial.
      J’avais envie de faire quelque chose de similaire, mais je n’avais pas assez d’expérience pour créer une TUI sans pouvoir consulter Internet pendant le vol.
      Je suis quand même content que cela existe déjà.

  • Voici comment obtenir les mêmes données sur un vol Delta

    $ curl https://wifi.delta.com/api/flight-data | jq  

    {  
"timestamp": "2023-07-11T14:54:41Z",  
"eta": "17:48",  
"flightDuration": 278,  
"flightNumber": "DAL786",  
"latitude": 39.723472595214844,  
"longitude": -97.1514205932617,  
"noseId": "3879",  
"paState": false,  
"vehicleId": "N879DN",  
"destination": "KPDX",  
"origin": "KATL",  
"flightId": "N879DN_SF_20230711121358",  
"airspeed": null,  
"airTemperature": 24,  
"altitude": 33922,  
"distanceToGo": 179,  
"doorState": "Closed",  
"groundspeed": 442,  
"heading": -73,  
"timeToGo": 174,  
"wheelWeightState": "Off"  
}

    Il y a aussi un petit bout amusant

    $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=";, .latitude, ",", .longitude' | tr -d '\n'; echo  
https://maps.google.com/?q=40.5615234375,-101.2824478149414
    • Avec l’interpolation de chaînes de jq, on peut faire plus simple 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • J’ai essayé d’ouvrir cette URL dans l’avion à l’instant, et ça fonctionne vraiment
      Ce sont des informations visibles aussi dans l’interface du portail Wi-Fi, mais sous forme de bloc JSON, ça donne une impression différente 
      {"timestamp":"2023-09-28T21:57:39Z","eta":"23:45","flightDuration":164,"flightNumber":"DAL992","latitude":47.4557876586914,"longitude":-111.73490905761719,"noseId":"3883","paState":false,"vehicleId":"N883DN","destination":"KMSP","origin":"KSEA","flightId":"N883DN_SF_20230928195737","airspeed":null,"airTemperature":null,"altitude":35273,"distanceToGo":13,"doorState":"Closed","groundspeed":499,"heading":95,"timeToGo":107,"wheelWeightState":"Off"}
      Désolé pour le formatage JSON, je suis sur mobile
    • Si on veut prendre l’air, ce serait bien de pouvoir ouvrir la porte avec une requête POST
    • Le choix d’utiliser un vehicleId plus générique au lieu de planeId ou tailNumber est intéressant
      Je me demande s’il existe d’autres types d’équipements exploités par Delta avec une API correspondante
      Je me demande aussi dans quelle mesure quelqu’un qui connaît d’autres systèmes internes pourrait déduire l’architecture du système à partir de flightId
      À première vue, ça ne semble pas être plus qu’une clé composite construite à partir de données visibles, mais c’est quand même intéressant
    • "airspeed": null
      Ça donne envie de regarder dehors d’un air inquiet

  • J’aimerais voir quelqu’un créer un proxy qui utilise les connexions autorisant gratuitement iMessage ou WhatsApp pour envoyer des données arbitraires
    En gros, on installerait un relais WhatsApp chez soi et on échangerait des messages depuis l’avion
    Dans sa forme la plus basique, on pourrait sans doute envoyer une URL au WhatsApp de la maison, qui chargerait la page web puis renverrait le HTML en réponse WhatsApp pour l’afficher
    Je me demande jusqu’où on pourrait faire fonctionner ça
    Apparemment quelqu’un a déjà fait un relais TCP via WhatsApp, c’est assez cool

    • https://github.com/aleixrodriala/wa-tunnel
    • Je n’ai pas lu les conditions d’utilisation, mais je me dis qu’on pourrait tout simplement mettre en place un véritable routeur IP
      On paie l’abonnement et on diffuse aussi un réseau Wi-Fi
      Si le SSID de l’avion est « Foo », on l’appelle « Foo discounted », et dans le portail captif on propose plusieurs « réductions » au choix, pour les anciens combattants, les seniors, les enfants, etc.
      Quelle que soit l’option choisie, on facture 2 dollars sur la page de paiement
      Une fois le coût du service amorti, on affiche aux visiteurs suivants « toutes les réductions ont été utilisées, veuillez utiliser Foo »
      Comme ça, moi j’ai Internet gratuitement, et les utilisateurs du routeur/portail ont Internet pour 2 dollars
      La bande passante montante serait sûrement médiocre, donc il serait probablement facile de multiplexer toutes les données sur ma seule connexion
      Il faudrait mettre ça dans un appareil type RPi, mais pour passer les contrôles de sécurité, il devrait ressembler à un produit fini, comme un lecteur audio, et pouvoir continuer à fonctionner même quand il faut relever la tablette ou aller aux toilettes
      Il me semble très peu probable qu’un avion dispose d’un WIPS ou d’un WIDS pour couper les connexions Wi-Fi malveillantes
      Et puis, les LAN parties ne sont pas interdites à bord, si ?
    • Il y a un an ou deux, j’ai pris l’avion un ou deux jours après la sortie de la première bêta d’Apple Private Relay, et j’ai pu utiliser le Wi-Fi gratuitement pendant tout le vol
      C’était probablement parce que les destinations mises sur liste blanche pour iMessage ou les notifications push l’incluaient aussi
      Quelques jours plus tard, avant le vol retour, c’était déjà bloqué
    • Ma première réaction n’est plus « waouh, trop cool », mais plutôt « la messagerie gratuite est un bon avantage, mais s’il y a des abus, ils vont la couper »
      On dirait que mes années de hacker sont passées
    • J’ai déjà vu des Wi-Fi de compagnies aériennes qui ne bloquaient pas le trafic DNS
      Il y a de fortes chances qu’on puisse faire quelque chose de similaire avec un tunnel DNS comme Iodine(https://github.com/yarrick/iodine)

  • Southwest présente les mêmes données dans une interface plus jolie
    Même sans payer le Wi-Fi, on peut voir beaucoup d’informations comme le suivi du vol, l’altitude actuelle, l’heure d’arrivée prévue, la position sur la carte, etc.
    Il semble probablement utiliser les mêmes données que celles pour lesquelles l’auteur a créé un programme de traitement ; en gros, il y a un site qu’on peut consulter gratuitement

    • Exact, c’est exactement ça
      On peut voir gratuitement une belle page d’état qui visualise ces données
      Mais il y avait quand même deux raisons de les scraper
      D’abord, la page d’état ne montre que les valeurs actuelles, et je voulais voir les données de tout le vol
      Ensuite, c’était amusant
    • Sur un vol intérieur récent aux États-Unis, je crois que c’était Alaska Airlines, il y avait une boîte LAN locale permettant de regarder des films et des séries en Wi-Fi même sans accès Internet
    • Cela répond à la question : « Pourquoi est-ce que je récupère plein de données de l’avion quand j’essaie d’ouvrir la page du portail ? »

  • J’aime l’esprit de cet article
    L’auteur aurait aussi sans doute pu scraper avec Git ces informations
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • J’ai pensé qu’on pourrait prendre des photos par le hublot et associer à l’image les coordonnées GPS de cette sortie JSON
    Ça semble assez utile

    • Si l’autorisation de localisation est activée dans l’application appareil photo, les coordonnées sont ajoutées aux données EXIF de l’image
      Aux États-Unis, les appareils GPS civils ne sont pas autorisés à fonctionner au-dessus de 60 000 pieds d’altitude et au-delà de 1 000 nœuds, en raison des restrictions ITAR sur l’exportation de matériel militaire

  • Si vous voulez comparer les données de l’appareil avec les données ADS-B, il semble que voici le vol de l’auteur de l’article original
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • Il est possible que les sources des données ADS-B et de cette API aient au moins été calculées à partir des mêmes instruments et systèmes de vol
    • C’est bien le bon vol
      C’est une bonne idée, dommage que je n’y aie pas pensé

  • Histoire intéressante
    Mais est-ce que je suis le seul que ce format de time dérange ?
    Ça me paraît être un choix bizarre, je m’attendais à quelque chose de plus standard comme de l’ISO 8601 avec un décalage de fuseau horaire
    "time": "Sun Sep 24 22:02:19 2023"

    • J’ai eu la même impression
      On dirait que la personne qui a conçu ce système a converti l’heure côté serveur en une représentation localisée basée sur la position du vol, afin de l’insérer directement dans l’interface Web sans logique côté client
    • Ça ressemble au format par défaut utilisé par ctime
      C’est peut-être un indice sur le backend sous-jacent
      https://cplusplus.com/reference/ctime/ctime/