CICD-SEC-7 : configuration système non sécurisée

Septième entrée du Top 10 OWASP CI/CD. Libellé officiel : Insecure System Configuration. L’entrée la moins spectaculaire du référentiel, et celle qui produit les incidents les plus bêtes : elle porte sur les réglages et le durcissement des systèmes de la chaîne, gestionnaire de code source, outil d’intégration, dépôt d’artefacts. Le document la présente sans détour comme le fruit mûr de l’environnement.

→ Lire l’explication complète de la marmotte

Le mécanisme : cinq défauts de réglage

Les environnements de livraison sont faits de plusieurs systèmes, venus de plusieurs fournisseurs, avec des réglages à trois niveaux : applicatif, réseau, infrastructure. Le référentiel insiste sur un équilibre que les équipes manquent souvent : travailler à la fois sur le code et les artefacts qui circulent, et sur la posture de chaque système qui compose la chaîne. Cinq défauts.

Un système ou un composant auto-hébergé dans une version obsolète, ou privé de correctifs importants. Le cas le plus banal et le plus documenté : le serveur de construction de Webmin, non corrigé, a été compromis, et une porte dérobée ajoutée à la copie locale du code après sa récupération depuis le dépôt ; les utilisateurs y ont été exposés plus d’un an.

Des contrôles d’accès réseau trop permissifs. Le serveur TeamCity de Stack Overflow était joignable depuis Internet : non la cause de la compromission, mais sa condition. Un outil d’intégration continue n’a presque jamais de raison d’être exposé au public, et c’est pourtant fréquent, parce que cela facilite les webhooks et le travail à distance.

Un système auto-hébergé ayant des droits d’administration sur le système d’exploitation sous-jacent, ce qui transforme une faille applicative en prise de contrôle de machine : l’élévation de privilèges au sens d’ATT&CK.

Des configurations non sûres. Les réglages déterminent l’autorisation, les contrôles d’accès et la journalisation, et le référentiel énonce la phrase qui vaut pour tout le métier : le jeu de configurations par défaut n’est pas sûr dans de nombreux cas. La version la plus coûteuse de ce défaut est une journalisation laissée désactivée, ce qui renvoie à CICD-SEC-10.

Une hygiène d’identifiants inadéquate au niveau du système : identifiants par défaut non désactivés, jetons programmatiques trop permissifs. Le code source de Nissan a fuité d’une instance Bitbucket auto-gérée, joignable depuis Internet, avec des identifiants par défaut. Au sens du catalogue CWE, la variante la plus pure est l’authentification manquante sur une fonction critique ; le reste relève de CICD-SEC-6.

Le document ajoute une nuance utile. Choisir une solution d’intégration en mode service plutôt qu’auto-hébergée supprime une partie des risques liés au durcissement et au mouvement latéral, mais chaque solution a son jeu de réglages dont la configuration reste à la charge de l’organisation. C’est le sujet de la frontière floue de la responsabilité partagée : le fournisseur a repris le durcissement de l’hôte, pas les décisions d’autorisation.

Ce que l’attaquant obtient

Une faille de configuration dans l’un des systèmes de la chaîne donne un accès non autorisé à ce système, ou pire sa compromission et l’accès au système d’exploitation sous-jacent. De là, trois usages : manipuler les flux légitimes de la chaîne, obtenir des jetons sensibles, atteindre la production. Dans certains cas, ces défauts permettent de se déplacer au-delà du contexte de la chaîne, c’est-à-dire d’employer l’outil de construction comme point d’entrée dans le reste du réseau.

L’incident de référence est SolarWinds, où le système de construction compromis a servi à diffuser un code malveillant jusqu’à dix-huit mille clients. Le référentiel le cite au titre de cette entrée et non d’une autre, ce qui mérite d’être relevé : l’événement fondateur de la sécurité de la chaîne de livraison est rangé sous « configuration système », pas sous une attaque sophistiquée. La porte dérobée du dépôt Git de PHP est ici pour la même raison, l’attaque ayant vraisemblablement commencé par la compromission du serveur Git auto-maintenu du projet.

Ce qu’on peut détecter, et par quoi

L’inventaire comparé aux versions supportées. Non pas une détection, mais la mesure qui décide de tout : la liste des systèmes de la chaîne, leurs versions, leur propriétaire. La nomenclature logicielle donne la méthode pour les composants ; pour les systèmes, c’est un inventaire d’exploitation, et il manque plus souvent qu’on ne l’avoue.

L’exposition réseau réelle, pas celle du schéma. Un balayage depuis l’extérieur répond en quelques minutes à « qu’est-ce qui est joignable », et diffère régulièrement de la documentation ; le même écart côté configurations est le sujet de l’inventaire réel contre la dérive. De même, les identifiants par défaut encore actifs se testent vite, leur liste étant publique pour chaque produit.

Les écarts de configuration par rapport à une référence, par une revue périodique de chaque réglage qui pèse sur la posture ; pour un cluster, l’audit de durcissement Kubernetes. Et les accès en mode de mise au point sur les nœuds d’exécution, qui méritent une alerte nominative pour la raison exposée plus bas.

Ce que le défenseur fait

Tenir l’inventaire, et nommer un propriétaire par système. Le référentiel lie les deux, et c’est le bon ordre : un composant sans propriétaire n’est pas corrigé. Puis vérifier en continu ses vulnérabilités connues et appliquer les correctifs : la gestion des vulnérabilités, les correctifs sur un parc hétérogène, et pour l’ordre de passage prioriser avec CVSS, EPSS et KEV.

Quand il n’y a pas de correctif, retirer le composant, ou réduire l’impact en restreignant l’accès au système ou sa capacité à conduire des opérations sensibles. Recommandation rare, et qui mérite d’être notée : le référentiel envisage explicitement de se passer du composant.

Aligner l’accès réseau sur le moindre accès. Formule du document, plus restrictive que le moindre privilège : non pas limiter ce qu’on peut faire, mais qui peut joindre quoi. Le durcissement de l’hôte est décrit dans durcir un serveur Linux de production, et il faut y ajouter une revue périodique des configurations, en partant du principe que les valeurs par défaut ne sont pas les bonnes.

Et surtout, traiter le mode de mise au point comme un privilège. C’est le point le plus original de l’entrée : accorder aux ingénieurs des droits de mise au point sur les nœuds d’exécution est courant, mais tout utilisateur qui accède à un nœud dans ce mode peut exposer l’ensemble des secrets au moment où ils sont chargés en mémoire, et employer l’identité du nœud. Ce droit confère donc des permissions élevées à chacun de ses détenteurs, quel que soit le soin apporté au cadrage des secrets décrit par CICD-SEC-5. La réponse n’est pas de l’interdire, impraticable, mais de le traiter comme un accès à privilèges, nominatif, limité dans le temps et enregistré, selon la logique de l’accès juste à temps.

Sources

CICD-SEC-7: Insecure System Configuration, OWASP Top 10 CI/CD Security Risks, 2022 : définition, cinq défauts de durcissement, nuance sur le service hébergé, recommandations, et les sept incidents cités plus haut, de SolarWinds aux fuites de code source par identifiants par défaut.

🐝 Ce qui arrive si on s’en passe

Le premier coût est de n’avoir aucune idée de sa surface. Sans inventaire des systèmes et de leurs versions, « cette version est-elle chez nous » reste sans réponse le jour d’une alerte publique, et faute de propriétaire désigné, il n’y a personne à qui la poser. Le second coût est l’étendue de la compromission : un outil de construction ayant les droits d’administration sur son hôte transforme n’importe quelle faille applicative en prise de contrôle de la machine qui détient les secrets de déploiement. L’attaquant n’a pas besoin d’empoisonner un pipeline, il modifie le code après sa récupération, comme chez Webmin, ce qui ne laisse aucune trace dans le dépôt et survit à la mise hors service du serveur si la restauration se fait depuis une sauvegarde locale. Enfin, le mode de mise au point ouvert à toute l’équipe rend caduc le cloisonnement des secrets : chaque ingénieur dispose, sans le savoir, d’un accès équivalent à celui du pipeline le plus privilégié.

🦫 Explication de la marmotte 🍫

Une chaîne de fabrication logicielle est faite de logiciels distincts, achetés ou installés à des moments différents : celui qui garde le code, celui qui assemble, celui qui stocke les paquets. Chacun a des centaines de réglages, et la plupart des organisations les ont laissés tels qu’ils sont arrivés.

Le défaut décrit ici est l’ensemble de ces négligences d’installation. Un logiciel non mis à jour depuis des années parce qu’il fonctionnait. Un outil accessible depuis Internet alors que trois personnes l’utilisent. Un mot de passe par défaut jamais changé, ce qui a suffi à faire fuiter le code source d’un constructeur automobile. Et le plus structurel : les réglages livrés par défaut, qui ne sont presque jamais les bons, le fournisseur préférant que son produit fonctionne tout de suite plutôt qu’il soit sûr tout de suite.

Deux remarques valent d’être retenues. La première est que le plus grand incident connu de ce domaine, la compromission d’un éditeur de logiciels d’administration réseau qui a diffusé un programme piégé à dix-huit mille clients, est rangé par les auteurs dans cette catégorie et non dans une attaque savante : c’est une machine d’assemblage mal tenue.

La seconde concerne un privilège dont presque personne ne mesure la portée. Pour comprendre pourquoi une fabrication a échoué, un développeur demande souvent l’accès à la machine en mode de diagnostic, ce qui paraît anodin. Or ce mode permet de voir les mots de passe au moment où la machine les charge, et d’agir sous son identité : accorder ce confort à toute une équipe revient à donner à chacun les clés du déploiement. Il faut le traiter comme ce qu’il est, un accès privilégié, nominatif, temporaire et enregistré.

Pages voisines

CICD-SEC-7 : configuration système non sécurisée

Elle cite

: les deux pages se citent l’une l’autre.

CICD-SEC-7 : configuration système non sécurisée

CICD-SEC-7 : configuration système non sécurisée

Le mécanisme : cinq défauts de réglage

Ce que l’attaquant obtient

Ce qu’on peut détecter, et par quoi

Ce que le défenseur fait

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines