- Dans le flux d’authentification KCM/CASS de la TSA, si le système côté compagnie aérienne était compromis, il devenait possible d’ajouter des utilisateurs arbitraires comme s’ils avaient passé la vérification de leur statut d’employé, ce qui pouvait mener au contournement du contrôle de sécurité, voire à l’accès au cockpit
- FlyCASS fournissait une interface web CASS pour les petites compagnies aériennes, et une injection SQL sur la page de connexion d’Air Transport International permettait une connexion administrateur
- L’interface d’administration pouvait accorder les autorisations KCM et CASS lors de l’ajout d’un nouvel employé sans vérification supplémentaire, et un utilisateur de test apparaissait ensuite comme approuvé dans les deux systèmes
- Après une divulgation à ARINC, à la FAA et au DHS/CISA fin avril 2024, le DHS a confirmé que FlyCASS avait été dissocié de KCM/CASS, mais n’a pas répondu aux demandes de rectification concernant les explications de la TSA
- La TSA a affirmé qu’un accès au checkpoint était impossible en raison d’un examen effectué avant l’émission d’un code-barres KCM, mais la procédure réelle conservait une voie de saisie manuelle de l’identifiant employé, ce qui élargissait l’impact de la faille
Ce que vérifient KCM et CASS
- Known Crewmember (KCM) est un programme de la TSA qui permet aux pilotes et au personnel navigant de contourner le contrôle de sécurité, y compris lors de déplacements personnels à l’intérieur du pays
- L’employé présente un code-barres KCM dans une file dédiée, ou fournit à un agent de la TSA son numéro d’employé et sa compagnie aérienne
- Le portable de l’agent TSA vérifie le statut d’employé auprès de la compagnie aérienne, et si la vérification réussit, l’employé peut entrer en zone sécurisée sans contrôle supplémentaire
- Cockpit Access Security System (CASS) est un système distinct qui vérifie l’autorisation d’accès au cockpit
- La plupart des avions disposent d’un jumpseat dans le cockpit, derrière les pilotes en fonction
- Lorsqu’un pilote fait la navette ou se déplace et ne peut pas facilement utiliser un siège payant, il peut utiliser ce jumpseat
- Le personnel de porte vérifie via CASS que l’utilisateur du jumpseat est bien un pilote autorisé, puis peut informer l’équipage que l’authentification CASS a été validée
- Le point central des deux procédures est la vérification du statut d’employé actuel auprès d’une compagnie aérienne
- Une personne qui n’est pas employée d’une compagnie aérienne n’est pas considérée comme ayant passé les vérifications d’antécédents, et ne doit donc pas pouvoir contourner le contrôle de sécurité ni accéder au cockpit
- Une photo du membre d’équipage est également renvoyée afin de confirmer qu’il s’agit bien de la personne approuvée
ARINC et les systèmes d’authentification des compagnies aériennes
- ARINC est une filiale de Collins Aerospace et semble être chargée de l’exploitation de KCM pour la TSA
- ARINC exploite des composants centraux comme un site web permettant aux pilotes et au personnel navigant de vérifier leur statut KCM, ainsi qu’une API qui achemine les demandes d’approbation entre compagnies aériennes
- Chaque compagnie aérienne semble exploiter son propre système d’authentification pour participer à KCM et CASS, et ce système interagit avec le hub d’ARINC
- La TSA et les compagnies aériennes peuvent envoyer à ARINC des requêtes comme
CockpitAccessRequestetCrewVerificationRequest - ARINC achemine ensuite la requête vers le système de la compagnie concernée et récupère la réponse
- La TSA et les compagnies aériennes peuvent envoyer à ARINC des requêtes comme
- 77 compagnies aériennes participent actuellement à KCM
- Les grandes compagnies ont peut-être développé leur propre système, mais la question de savoir comment les petites compagnies répondaient aux requêtes KCM ou CASS a fait l’objet de l’enquête
L’injection SQL découverte dans FlyCASS
- En cherchant le fournisseur qui exploitait réellement ces systèmes d’authentification, les chercheurs ont découvert FlyCASS
- FlyCASS fournissait une interface web CASS pour les petites compagnies aériennes
- Chaque compagnie disposait d’une page de connexion distincte, et Air Transport International (8C) était accessible via
/ati
- En saisissant une apostrophe dans le nom d’utilisateur sur la page de connexion, une erreur MySQL était immédiatement renvoyée
- Le nom d’utilisateur semblait être inséré directement dans la requête SQL de connexion
- Le problème d’injection SQL a été confirmé avec sqlmap
- Avec le nom d’utilisateur
' or '1'='1et le mot de passe') OR MD5('1')=MD5('1, il était possible de se connecter au compte administrateur d’Air Transport International
Ajout d’utilisateurs approuvés KCM/CASS avec des droits administrateur
- FlyCASS exploitait à la fois KCM et CASS pour les compagnies aériennes participantes
- Une fois les droits administrateur d’Air Transport International obtenus, il était possible de gérer la liste des pilotes et du personnel navigant rattachés à cette compagnie
- Lors de l’ajout d’un nouvel employé à la compagnie, aucune vérification ni authentification supplémentaire n’était effectuée
- Un administrateur de la compagnie pouvait ajouter n’importe qui comme utilisateur approuvé KCM et CASS
- À des fins de test, un employé nommé
Test TestOnlya été créé avec une photo de test choisie, puis doté des droits d’accès KCM et CASS- Une vérification via la fonction Query a ensuite montré que cet utilisateur de test apparaissait comme approuvé à la fois dans KCM et dans CASS
- Avec de simples connaissances de base en injection SQL, il était donc possible de se connecter au site et d’ajouter des utilisateurs arbitraires à KCM et CASS
- En conséquence, cela aurait pu permettre de contourner le contrôle de sécurité et même d’accéder au cockpit d’un avion de ligne commercial
- La procédure de divulgation a commencé immédiatement après la découverte du premier problème, et plusieurs autres failles graves ont également été identifiées
Divulgation et réaction de la TSA
- Trouver un contact approprié pour la divulgation n’a déjà pas été simple
- Comme FlyCASS semblait être exploité par une seule personne, les chercheurs ne voulaient pas la contacter directement d’emblée et la prendre au dépourvu
- Le problème a été divulgué au Department of Homeland Security le 23 avril 2024, et le DHS a confirmé en avoir pris connaissance et le prendre « très au sérieux »
- Par la suite, FlyCASS a été désactivé de KCM/CASS, et le problème semble avoir ensuite été corrigé
- Après la correction, une tentative de coordination d’une divulgation sûre a eu lieu, mais le DHS a cessé de répondre
- Le service de presse de la TSA a publié une explication niant l’impact de la faille
- La TSA a affirmé qu’il était impossible d’accéder à un checkpoint KCM via cette faille, car une procédure d’examen était lancée avant l’émission d’un nouveau code-barres KCM
- Cependant, le code-barres KCM n’est pas obligatoire pour utiliser un checkpoint KCM, et un TSO peut saisir manuellement l’identifiant employé de la compagnie aérienne
- Après que les chercheurs ont signalé cela à la TSA, celle-ci a supprimé de son site la section mentionnant la saisie manuelle de l’identifiant employé et n’a pas répondu aux demandes de rectification
- Il a été confirmé que l’interface utilisée par les TSO permet toujours la saisie manuelle de l’identifiant employé
Attaques supplémentaires possibles et chronologie de la divulgation
- Comme la faille permettait de modifier des membres KCM existants, il était également possible de changer la photo et le nom d’utilisateurs déjà enregistrés
- Cette méthode aurait pu permettre de contourner une éventuelle procédure d’examen des nouveaux membres
- Si l’on pouvait obtenir un code-barres KCM non enregistré, il était également possible de l’associer directement à un identifiant employé sur le site web KCM
- Chronologie de la divulgation :
- 2024-04-23 : première divulgation à ARINC et à la FAA
- 2024-04-24 : divulgation supplémentaire au DHS via la CISA
- 2024-04-25 : le CISO du DHS confirme qu’un travail de remédiation est en cours
- 2024-05-07 : le CISO du DHS confirme que FlyCASS a été dissocié de KCM/CASS
- 2024-05-17 : relance auprès du CISO du DHS au sujet des explications de la TSA, sans réponse
- 2024-06-04 : nouvelle relance auprès du CISO du DHS au sujet des explications de la TSA, sans réponse
1 commentaires
Avis sur Hacker News
Ici, la réponse de la TSA est puérile et embarrassante, mais ce n’est pas surprenant si l’on considère qu’il s’agit d’une organisation qui ne se soucie pas vraiment de la sécurité réelle
Le DHS semble avoir d’abord traité le signalement de manière rapide et professionnelle, mais il est intéressant de voir qu’il n’a finalement pas réussi à conserver jusqu’au bout l’autorité sur la correction et le processus de divulgation
J’ai vu de gros problèmes comme des clés exposées être traités comme des détails, tandis que des sujets comme une vieille bibliothèque JavaScript ou l’absence de prise en charge d’IPv6 étaient escaladés
Il est clair que la TSA et ses prestataires cherchent à minimiser l’exposition potentielle, mais il est aussi très probable que beaucoup d’administrateurs aient du mal à comprendre la portée de la faille, et que les développeurs minimisent leur propre responsabilité en rejetant la faute sur les autres
En pratique, son objectif semble être surtout de consolider l’appareil de surveillance et de projeter une image de puissance
Ils ne se sont pas contentés de confirmer une injection SQL : ils ont même créé de faux enregistrements d’employés, et il est choquant que le Homeland Security ne soit pas venu arrêter les personnes impliquées
Pour moi, Homeland Security fait partie des organismes les plus susceptibles de prendre une divulgation responsable pour du piratage malveillant et de l’appeler ainsi
C’est presque plus marquant que l’incompétence de la faille elle-même
S’ils s’étaient ajoutés eux-mêmes à Known Crewmember et avaient réellement contourné le contrôle à l’aéroport, là ils auraient fini en prison
À leur place, ce sont les meilleurs talents d’autres pays moins amicaux qui les examineront, et ils auront moins de chances de faire une divulgation responsable
https://bugcrowd.com/engagements/dhs-vdp
Ils travaillent avec eux depuis des années, donc ils devraient être un minimum habitués. La TSA elle-même l’est peut-être moins, mais comme le DHS gère une politique de divulgation des vulnérabilités (VDP) à l’échelle du ministère et conseille aussi d’autres agences via la CISA sur la mise en place de VDP, je doute qu’ils demandent au DOJ d’engager des poursuites
Mais il est possible que je sois trop optimiste
Cela permet de réduire le risque d’être poursuivi pour divulgation responsable
Une méthode encore plus sûre consiste à envoyer le rapport anonymement en fixant une échéance claire pour la publication ou la divulgation complète, même si dans ce cas il devient difficile d’être reconnu comme découvreur
C’est tellement grave qu’au moment où j’écris, personne ne parle même du fait qu’ils stockaient les mots de passe en MD5, tant le problème est relégué au second plan
On découvre aussi qu’ils n’utilisaient même pas de sel, et avec MD5, même un sel ne serait pas suffisant
Mais si une simple requête permet déjà de manipuler la requête SQL elle-même à volonté, la qualité du stockage des mots de passe n’a plus tellement d’importance
La proportion de ceux qui utilisaient un sel et un hash cryptographiquement sûr était probablement inférieure à 20 %, et MD5 revenait vraiment très souvent
Quand on sait qu’il y avait déjà eu un gros tri avant cet entretien, le niveau de base global était probablement encore pire
L’explication selon laquelle ils n’auraient pas contacté FlyCASS d’abord parce que « cela semblait être géré par une seule personne » est difficile à croire
On a plutôt l’impression qu’ils savaient que le développeur du site corrigerait immédiatement le problème, et qu’ils voulaient faire plus de bruit autour de leur découverte
Ce n’est pas quelque chose que le responsable doit corriger discrètement avant de passer à autre chose : il faudrait revérifier toutes les personnes présentes dans la base de données
Si l’unique développeur l’avait corrigé immédiatement, il aurait sans doute été plus difficile de faire remonter le problème plus haut pour obtenir une correction systémique
Je ne sais pas si une refonte complète aura réellement lieu, mais si on ne fait pas remonter l’affaire, les chances qu’elle se produise sont encore plus faibles
Il n’est pas surprenant qu’ils aient nié la gravité du problème, mais il est assez surprenant qu’ils n’aient pas alerté le FBI ni tenté de faire arrêter quelqu’un
C’est peut-être un petit progrès
S’il avait signalé directement à la TSA, cela aurait très bien pu déboucher sur des menaces juridiques et de l’intimidation
Je peux parier 50 dollars qu’Ian sera inculpé
Il est presque étonnant qu’un adolescent de 17 ans qui s’ennuie, avec une fausse carte d’identité, n’ait pas encore posté sur TikTok une vidéo où il monte clandestinement dans un avion
Une injection SQL, quand même
C’est à la fois drôle et pas si surprenant qu’une vieille injection SQL suffise à neutraliser tout un théâtre de la sécurité à plusieurs dizaines de milliards de dollars par an
Il est assez surprenant que des compagnies aériennes achètent un logiciel aussi sensible du point de vue de la sécurité à une entreprise d’une seule personne
Aux États-Unis, dès qu’on atteint un certain stade en essayant de vendre du SaaS à la plupart des entreprises, on vous demande au minimum un rapport d’audit SOC2
Le SOC2 est plutôt facile à obtenir sans remarques majeures si l’on regarde les critères d’audit, mais si l’entreprise est gérée par une seule personne, il y a plusieurs points qui devraient faire apparaître des voyants rouges dans le rapport
Pour un logiciel intégré à un système d’accès de la TSA, j’aurais pensé que les exigences seraient bien plus strictes que le SOC2
Tout, côté backend, tient avec encore plus de ruban adhésif que dans la petite entreprise moyenne
Il suffit d’acheter quelques vieux avions de ligne et de les convertir en cargos pour devenir une « compagnie aérienne »
Est-ce que l’apparition de nouvelles compagnies aériennes est une bonne chose ? Faut-il les forcer à fermer simplement parce qu’elles n’ont pas encore des systèmes qui prennent des années, voire des décennies, à se mettre en place ? Une entreprise qui exploite une seule ligne entre deux lieux perdus avec deux appareils doit-elle payer très cher pour des systèmes sur mesure conçus pour les grands transporteurs de passagers ?
Ici, des exigences et des audits ne sont pas la réponse. Le vrai problème de conception, c’est que la TSA a lié l’assertion « la compagnie aérienne XXX dit que vous êtes un employé » à un pouvoir extrêmement large, « contourner tous les contrôles de sécurité dans n’importe quel aéroport du pays », sans même une vérification élémentaire comme « cette compagnie opère-t-elle dans cet aéroport ? »
J’étais déjà surpris que ce soit aussi facile, mais l’explication de la réponse de la TSA à la fin est vraiment très inquiétante
Les personnes qui ont fait ça vont probablement recevoir la visite du Homeland Security ou du FBI
Je ne vois pas bien ce qu’elles pensaient pouvoir y gagner
Je ne pense pas que le gouvernement se soucie réellement de la sécurité, mais il est vindictif
Si je comprends bien, l’attaque possible consiste à acheter un billet sur une grande compagnie, mettre des objets interdits dans son bagage cabine, puis utiliser une injection SQL dans le système tiers FlyCASS pour s’ajouter à la liste Known Crew Member d’une petite compagnie afin de contourner le contrôle de la TSA
Et ensuite, embarquer sur un vol d’une grande compagnie avec ces objets interdits ?
De nos jours, la plupart des files de contrôle de la TSA ne demandent même plus de carte d’embarquement, donc en théorie on pourrait apporter une bombe et contourner tout ce théâtre sécuritaire