Une chercheuse découvre une faille critique CVSS 9.4 dans les logiciels de la NASA

Une chercheuse en cybersécurité a découvert une vulnérabilité critique CVSS 9.4 dans le logiciel de contrôle spatial AIT-GUI de la NASA, causée par quatre failles permettant l'exécution de code à distance.

GeektimeAuteur : כתבת אורחת
Source
Une chercheuse découvre une faille critique CVSS 9.4 dans les logiciels de la NASA
Photo : Geektime / תמונה: NASA

Dans le monde du développement logiciel, omettre la validation des entrées ou les contrôles d'authentification est monnaie courante. Au pire, un pirate informatique défigure une page d'accueil ou divulgue une liste de diffusion. Mais que se passe-t-il lorsque ces lignes de code s'insèrent directement dans l'interface de contrôle de la NASA/JPL, le serveur chargé de surveiller les engins spatiaux, de transmettre des commandes et de synchroniser des équipements à travers la galaxie ?

Dans le cadre d'une recherche récente, nous avons examiné le code de l'AIT-GUI, l'interface utilisateur Web de la boîte à outils AMMOS Instrument Toolkit. Ce système open-source est utilisé par les ingénieurs et opérateurs de la NASA pour communiquer avec le matériel lors de missions spatiales. Nous n'aurions jamais imaginé y découvrir une vulnérabilité critique (GHSA-p9r8-2q67-fp86) affichant un score de gravité CVSS de 9,4.

Comment quatre petites erreurs créent un accès libre à l'exécution de code à distance

Pour comprendre la sensibilité de la situation, imaginez une rangée de portes verrouillées où les développeurs ont simplement oublié d'installer des serrures, laissant un panneau indiquant Ne pas entrer. Aucun mot de passe, nom d'utilisateur ou privilège particulier n'était requis. La combinaison de quatre petites erreurs de développement a forgé une chaîne d'attaque fatale.

Un serveur à l'écoute de tous

Le code contenait une variable hôte lisant localhost à partir des paramètres. Une excellente idée, n'est-ce pas ? Sauf que le développeur initialisant le serveur a simplement oublié de lui passer cette variable.


host = getattr(self, "host", "localhost")

...

gevent.pywsgi.WSGIServer(

 ("0.0.0.0", port),

 App, handler_class=WebSocketHandler,

)

Résultat : le serveur est resté figé sur l'adresse 0.0.0.0. L'opérateur du système est persuadé d'être isolé sur un réseau local, tandis que son serveur est grand ouvert à toute requête provenant de n'importe quelle adresse IP.

Absence totale de mécanismes de défense de base

Le système ne comportait aucun mécanisme de connexion, jeton CSRF ou restriction CORS. Pire encore, les requêtes modifiant l'état étaient envoyées au format application/x-www-form-urlencoded, permettant des requêtes Cross-Origin sans vérification préalable. En clair, il suffit qu'un opérateur navigue sur un site Web d'apparence anodine pour que celui-ci déclenche en arrière-plan une requête silencieuse exécutant des commandes en son nom.

Un canal ouvert pour la transmission de commandes

Le système exposait un point de terminaison permettant d'envoyer des commandes directement aux composants opérationnels. Dépourvue de couche de protection ou de filtres, l'entrée reçue était analysée et acheminée directement vers le bus de commandes du système :


command = bottle.request.forms.get("command").strip()

args = command.split()

name = args[0].upper()

args = [util.toNumber(t, t) for t in args[1:]]

if self.send(name, *args):

Contournement de bac à sable (Path Traversal)

Le point culminant a été découvert dans le composant d'exécution de scripts (POST /seq). Le code concaténait le nom de fichier fourni par l'utilisateur directement au chemin racine sans vérification des limites :


bn_seqfile = bottle.request.forms.get("seqfile")

seqfile = os.path.join(SEQRoot, bn_seqfile)

gevent.subprocess.Popen(["ait-seq-send", seqfile], ...)

Résultat : un attaquant peut injecter des séquences de traversée de répertoire telles que '../../../../' pour s'échapper du dossier désigné et exécuter n'importe quel fichier ou script sur le serveur.

Quand la chercheuse rencontre des agents IA

L'un des aspects les plus fascinants de cette découverte a été l'utilisation d'agents IA autonomes pour l'analyse du code. Alors qu'un œil humain a tendance à omettre une petite variable définie mais non transmise, les agents d'intelligence artificielle ont analysé les flux de données et relié rapidement les entrées corrompues aux actions dramatiques des points de terminaison. La synergie entre l'intuition d'un chercheur en cybersécurité humain et la capacité de l'IA à analyser de vastes volumes de code nous a permis de décoder rapidement toute la chaîne d'attaque.

Conformément aux procédures de divulgation coordonnée, nous avons immédiatement contacté les équipes de développement de la NASA dès la découverte de la faille. La NASA a réagi rapidement, a pris en compte le rapport et a corrigé les composants exposés dans la version mise à jour AIT-GUI 2.5.2.

Impossible de compter sur un environnement fermé

Le monde du Web et celui des technologies opérationnelles (OT) se croisent aujourd'hui plus que jamais. Si une requête POST compromise dans une application classique perturbe tout au plus une base de données, dans les systèmes OT et spatiaux, il s'agit de commandes envoyées à des équipements physiques, modifiant radicalement le rayon d'impact.

Les pare-feu ne constituent plus un plan de sécurité viable. Il est impossible de s'appuyer sur un environnement fermé en supposant que personne n'atteindra le serveur interne. Le code open-source, même destiné à la NASA, doit être conçu dès le départ selon une approche Zero Trust, avec une authentification rigoureuse et une sanitisation approfondie de chaque entrée.

Dans la même rubrique