Romain Canu

A429Fuzzer

Temps de lecture : 8 min

Présentation et objectifs du projet

Le projet consiste à injecter en entrée d’un système embarqué avionique des trames au format ARINC 429 générées de façon aléatoire (erronées ou correctes) – principe du fuzzing - pour tester la robustesse du driver SPI d'un système embarqué Linux qui gère la réception des données issues du réseau avionique.

Les objectifs du projet sont :

  • De développer un outil de fuzzing ARINC 429 en langage Python,
  • De vérifier que le driver SPI du système embarqué Linux est robuste aux cyberattaques,
  • De commencer à me former aux protocoles de communication avionique

Les étapes

Tout d'abord, j'ai dû définir l'architecture à mettre en place pour les tests de fuzzing : Pour être le plus représentatif possible de la réalité, j'ai dû interconnecter le système embarqué cible contenant le driver SPI attaqué (système embarqué 2 dans le schéma ci-dessous) avec un deuxième système embarqué Linux (système embarqué 1) simulant le calculateur avionique qui produit les données ARINC 429. J'ai également dû relier l'ordinateur qui allait exécuter le Fuzzer aux deux systèmes Linux via Ethernet, de manière à pouvoir émettre d'un côté le message ARINC 429 généré à destination du système 1 qui allait le transmettre vers le système 2, et, de l'autre côté, de réceptionner le message décodé par le système 2 et transmis vers l'ordinateur pour comparer la trame initiale générée avec la trame décodée par le système 2. Tout écart allait identifier un problème dans le driver SPI.

Une fois l'architecture déposée et validée par mon tuteur, il m'a fallu ensuite comprendre en détail le format d’une trame ARINC 429 qui est un bus de données série unidirectionnel standard (simplex) largement utilisé dans les réseaux de communication avionique et qui impose un seul émetteur par bus, et jusqu'à 20 récepteurs.

J'ai dû ensuite analyser les données transportées dans ce format, puis appréhender la manière dont le driver SPI codé en C acquiert les données ARINC 429. J'ai dû pour cela analyser le code à travers des sessions de lecture, que j'ai complétées par une exécution pas à pas pour suivre plus facilement le flot de contrôle du logiciel. Ce logiciel étant de très bas niveau (très proche par nature du hardware), sa compréhension n'était pas facile.

L'étape suivante a consisté à me lancer dans le développement du fuzzer à proprement parler, un programme en Python qui génère des trames aléatoires ARINC 429. J'ai ensuite modifié le code C du driver bidirectionnel ARINC 429 du système embarqué 1 pour permettre de transférer les trames aléatoires générées par le programme Python vers le driver SPI installé sur le système embarqué 2. À noter que j'ai porté une attention toute particulière à bien commenter le code développé et modifié.

Il a ensuite fallu définir une première solution de monitoring pour vérifier que la trame envoyée par le programme Python est bien la même que celle reçue par le driver SPI. Il a ensuite fallu définir une seconde solution de monitoring pour vérifier la bonne santé du driver SPI (le principe consiste à écouter un message envoyé toutes les secondes par le driver). L’objectif de ce monitoring est de détecter les cas où le driver SPI n’est pas robuste à certaines de ses entrées (par exemple, s’il reçoit un trop grand nombre de messages (lag) qu’il n’arriverait pas à traiter ou une trame qui le ferait crasher).

Une fois les différents niveaux d'intégration réalisés, j'ai lancé formellement les tests de fuzzing (voir résultats). Pour finir, j'ai rédigé l'ensemble de la documentation associé au projet: document d'architecture, de conception, guide utilisateur, etc.

Les acteurs

J'ai dû répondre à une problématique donnée par mon tuteur d'alternance pour vérifier la robustesse du driver SPI embarqué dans les futurs avions. Au démarrage du projet, mon tuteur m'a donné beaucoup de pistes pour aborder cette problématique (par exemple utiliser un deuxième système Linux pour simuler un calculateur avionique). Il a ensuite été toujours présent durant toute la durée du projet pour répondre à mes sollicitations et à mes interrogations, même si j'ai dû faire preuve de beaucoup d'autonomie. Je me suis également appuyé sur des collègues qui avaient la connaissance pointue des drivers SPI.

À la fin du projet, j'ai présenté les résultats aux membres de l'équipe cybersécurité de Thales Avionics Toulouse.

Les résultats

J’ai mis environ trois mois pour réaliser le projet A429Fuzzer. Après à peine quelques jours d’exécution, j’ai eu la grande satisfaction d’obtenir des résultats très intéressants dont je ne peux pas parler dans ce portfolio pour des raisons de confidentialité et qui ont permis de renforcer la sécurité du système embarqué Linux cible.

D'un point de vue personnel, ce projet m'a permis de renforcer mes compétences dans la programmation en C et m'a conforté dans le fait que j'avais une bonne maîtrise du Python.

Les lendemains du projet

Au moment où j’écris ce portfolio, je suis en train de développer une extension du Fuzzer pour tester le driver SPI non plus en injectant des trames ARINC 429, mais des trames au format ARINC 717 (format utilisé par les enregistreurs de vol). Ce format s'appuyant sur un certain nombre de bits de synchronisation, cela rend l'adaptation du driver bidirectionnel beaucoup plus compliquée que pour l'ARINC 429.

Enfin, j'ai pu avoir la satisfaction de voir certaines parties de mon code du fuzzer reprises par des membres de mon équipe à destination d'autres projets.

Mon regard critique

Ce projet est très intéressant, car il combine à la fois des protocoles de communication avionique (ARINC 429 / ARINC 417) et des protocoles de réseaux standard (Ethernet). Modifier un driver bidirectionnel s'avère complexe, car le code est volumineux (plusieurs milliers de lignes de code) et de très bas niveaux. J'ai certainement perdu du temps sur cette partie, mais que j'ai compensé avec ma bonne maîtrise du Python.

Pour conclure, je dirais que ce projet m'a fait prendre conscience de l'importance du fuzzing dans l'industrie et de son efficacité pour trouver les failles de codage dans les logiciels qui pourraient être exploités par des personnes malveillantes. C'est une technique que j'essaierai donc tout naturellement de promouvoir dans les futures entreprises que j'intégrerai.