A08:2021 – Manque d'intégrité des données et du logiciel

Facteurs

CWEs associées	Taux d'incidence max	Taux d'incidence moyen	Exploitation pondérée moyenne	Impact pondéré moyen	Couverture max	Couverture moyenne	Nombre total d'occurrences	Nombre total de CVEs
10	16,67 %	2,05 %	6,94	7,94	75,04 %	45,35 %	47 972	1 152

Aperçu

Une nouvelle catégorie pour 2021 qui se concentre sur la formulation d'hypothèses relatives aux mises à jour logicielles, aux données critiques et aux pipelines CI/CD sans vérification de l'intégrité. Il s'agit de l'un des impacts pondérés les plus élevés des données CVE/CVSS (Common Vulnerability and Exposures/Common Vulnerability Scoring System). Les Common Weakness Enumerations (CWE) notables comprennent CWE-829 : Inclusion of Functionality from Untrusted Control Sphere, CWE-494 : Download of Code Without Integrity Check, et CWE-502 : Deserialization of Untrusted Data.

Description

Les défaillances de l'intégrité des logiciels et des données sont liées au code et à l'infrastructure qui ne sont pas protégés contre les violations de l'intégrité. C'est le cas, par exemple, lorsqu'une application s'appuie sur des plugins, des bibliothèques ou des modules provenant de sources, de dépôts et de réseaux de diffusion de contenu (CDN) non fiables. Un pipeline CI/CD non sécurisé peut introduire un risque d'accès non autorisé, de code malveillant ou de compromission du système. Enfin, de nombreuses applications intègrent désormais une fonctionnalité de mise à jour automatique, où les mises à jour sont téléchargées sans vérification d'intégrité suffisante et appliquées à l'application précédemment fiable. Les attaquants pourraient potentiellement télécharger leurs propres mises à jour pour les distribuer et les exécuter sur toutes les installations. Un autre exemple est celui des objets ou des données qui sont codés ou sérialisés dans une structure qu'un attaquant peut voir et modifier et qui sont vulnérables à une désérialisation non sécurisée.

Comment s'en prémunir

utilisez des signatures numériques ou des mécanismes similaires pour vérifier que le logiciel ou les données proviennent de la source prévue et n'ont pas été modifiés ;
assurez-vous que les bibliothèques et les dépendances, telles que npm ou Maven, consomment des dépôts de confiance. Si vous avez un profil de risque plus élevé, envisagez d'héberger un dépôt interne connu et approuvé ;
assurez-vous qu'un outil de sécurité de la chaîne logistique logicielle, tel que OWASP Dependency Check ou OWASP CycloneDX, est utilisé pour vérifier que les composants ne contiennent pas de vulnérabilités connues ;
veillez à ce qu'il existe un processus de révision des changements de code et de configuration afin de minimiser les risques d'introduction de code ou de configuration malveillants dans votre pipeline logiciel ;
assurez-vous que votre pipeline CI/CD dispose d'une ségrégation, d'une configuration et d'un contrôle d'accès appropriés pour garantir l'intégrité du code passant par les processus de construction et de déploiement ;
veillez à ce que les données sérialisées non signées ou non chiffrées ne soient pas envoyées à des clients non fiables sans une forme de contrôle d'intégrité ou de signature numérique permettant de détecter la falsification ou le rejeu des données sérialisées.

Exemple de scénarios d'attaque

Scénario n°1 mise à jour sans signature : de nombreux routeurs domestiques, décodeurs, firmwares de périphériques et autres ne vérifient pas les mises à jour via un firmware signé. Les microprogrammes non signés constituent une cible de plus en plus importante pour les attaquants et leur nombre ne devrait cesser d'augmenter. Il s'agit d'une préoccupation majeure car, bien souvent, il n'y a pas de mécanisme pour y remédier, si ce n'est de corriger dans une version future et d'attendre que les versions précédentes soient périmées.

Scénario n°2 mise à jour malveillante de SolarWinds : les États-nations sont connus pour attaquer les mécanismes de mise à jour, avec une attaque récente notable, l'attaque SolarWinds Orion. La société qui développe le logiciel a mis en place des processus sécurisés de construction et d'intégrité des mises à jour. Néanmoins, ces processus ont pu être contournés et, pendant plusieurs mois, la société a distribué une mise à jour malveillante très ciblée à plus de 18 000 organisations, dont une centaine ont été touchées. Il s'agit de l'une des violations de cette nature les plus étendues et les plus importantes de l'histoire.

Scénario n°3 désérialisation non sécurisée : une application React appelle un ensemble de microservices Spring Boot. Étant des programmeurs fonctionnels, ils ont essayé de s'assurer que leur code est immuable. La solution qu'ils ont trouvée consiste à sérialiser l'état de l'utilisateur et à le transmettre dans les deux sens à chaque requête. Un attaquant remarque la signature d'objet Java "rO0" (en base64) et utilise l'outil Java Serial Killer pour obtenir l'exécution de code à distance sur le serveur d'application.