Des malwares qui font tomber les avions...

C

omme souvent quand on mélange aviation et sécurité informatique, le buzz ne brille pas par son exactitude. Ainsi, il n'a pas fallu beaucoup attendre pour qu'on rebondisse sur les affirmations du journal espagnol El País et qu'un virus informatique devienne responsable du crash du vol Spainar 5022. Contrairement à d'autres avis probablement plus éclairés, mais moins sensationnels...

Évidemment, l'hypothèse de la compromission d'un ordinateur de bord, l'empêchant d'alerter l'équipage et tuant par son silence 154 des 172 personnes présentes à bord du MD82, a de quoi séduire l'amateur de scoops croustillants. Et de générer son lot de commentaires plus ou moins inspirés chez certains professionnels. Il ne manque plus que la clé USB infectée pour parfaire le scénario du Confiker-like meurtrier...

Il y a quand même quelques personnes qui se posent des questions ou font un peu de follow-up sur leurs billets. C'est rassurant, mais bon, ce n'est pas ça qui va empêcher les esprits les plus fertiles de tourner à fond les ballons... Surtout pour en faire le premier incident du genre...

Évidemment, pour remettre un peu les pieds sur Terre, il faut revenir à la source, à savoir le rapport préliminaire d'incident publié par le CIAIAC^[1]. Et ça tombe bien, parce qu'il est public.

La cause technique de l'accident est un décollage sans volets, configuration impropre sur ce type d'appareil. Les évènements qui ont mené à cette configuration sont multiples, mais semblent résulter principalement d'une revue trop rapide des checklists de décollage par un équipage stressé et ensuite du non fonctionnement du TOWS^[2], équipement de bord censé émettre une alerte vocale pour prévenir l'équipage du problème de volets.

Pas mal d'articles parus sur le sujet spéculent sur une infection du TOWS par un malware. Infection qui expliquerait son absence de réaction. Sauf que comme d'habitude, les choses sont un peu plus compliquées qu'une explication à l'emporte-pièce et la vérité est ailleurs. L'équipage était stressé par un retard imputable à une défaillance matérielle. Alors qu'il se dirigeait vers la piste de décollage, une mesure anormale retournée par une sonde de température^[3] avait conduit à son retour en porte. Or, la sonde en question n'est activée qu'en vol mais il semble qu'elle fonctionnait alors que l'avion était encore au sol.

Le fait que l'avion soit ou non au sol est détecté par des interrupteurs logés dans le train avant. Ils contrôlent des relais qui permettent d'activer ou de couper certains équipements. Parmi ces derniers figurent le RAT, mais aussi le TOWS qui n'est actif qu'au sol. Or ces deux systèmes dépendent du même relais, dont une défaillance est avancée comme hypothèse probable de la coupure du TOWS. Car si le relais en question indiquait que l'avion était en vol au RAT, il fournissait la même information au TOWS, lequel se trouvait donc désactivé. Pas de malware dans le TOWS, difficile d'en loger un dans un relais. Poursuivons...

D'après le rapport, c'était le sixième incident du genre enregistré par le DFDR^[4] de l'appareil. Trois d'entre eux se trouvent consignés dans l'ATLB^[5] de l'appareil. Il s'agit d'un journal technique, opéré par l'airline sur un système informatique externe à l'avion, dans lequel on répertorie, entre autres, les opérations de maintenance consécutives à des incidents. L'analyse de ce journal permet de remonter des alertes en cas d'occurence d'un même incident. Avec comme conséquence possible de clouer l'appareil au sol pour inspection. Or, aucune alerte n'a été remontée à l'équipe de maintenance ce jour là.

Comment expliquer ce silence ? Le malware, forcément ! C'est donc là que l'hypothèse du système compromis entre en scène. Un système vérolé n'aurait pas averti les équipes de maintenance de la répétition d'un problème de RAT dans l'ATLB, conduisant à une autorisation de décollage qui n'aurait pas due être donnée. CQFD...

Maintenant, je vais me garder de spéculer plus avant sur les causes du silence du système gérant l'ATLB. À ceux qui voudraient le faire, je recommanderai toutefois de considérer les points suivants.

D'abord, le rapport préliminaire ne fait pas mention^[6] de l'absence d'une alerte quant au contenu de l'ATLB. On peut donc s'interroger sur l'importance supposée d'un tel incident, pour autant que ça en soit un. Ensuite, dans un précédent article, El País mentionnait que Spanair se donnait un délai de 24h pour réconcilier les rapports que remontent les équipes de maintenance au sein de l'ATLB. Ce qui amène à se demander si les informations dont disposaient l'équipe de maintenance étaient à jour, et donc susceptibles de les alerter.

Ceci m'inspire que l'hypothèse du malware n'est pas la seule permettant d'expliquer cette absence d'alerte. Et quand bien même ce serait le cas, pourrait-on pour autant parler de malware tueur ? Je vous laisse juger par vous-même...

Notes

[1] Comisión de Investigación de Accidentes e Incidentes de Aviación Civil, l'équivalent espagnol du BEA français ou du NTSB américain.

[2] Take-Off Warning System.

[3] La RAT, pour Ram Air Temperature.

[4] Digital Flight Data Recorder.

[5] Aircraft Technical Log Book.

[6] Ou je ne l'ai pas vu.