Plusieurs vulnérabilités ont été découvertes lors de l'analyse des conteneurs Docker

docker piraté

Récemment devenu connu par un article de blog, les résultats des outils de test pour identifier les vulnérabilités pas de correctif et identifier les problèmes de sécurité dans des images de conteneur Docker isolées.

Le test a montré que 4 des 6 scanners images Docker connues avait des vulnérabilités critiques cela permettait d'attaquer le scanner lui-même et d'exécuter son code sur le système, dans certains cas (en utilisant Snyk par exemple) avec les privilèges root.

Pour une attaque, un attaquant a juste besoin de commencer à vérifier son Dockerfile ou manifest.json, qui comprend des métadonnées spécialement formatées, ou placez les fichiers podfile et gradlew dans l'image.

Nous parvenons à préparer des prototypes d'exploit pour WhiteSource, Snyk, Fossa et les systèmes d'ancrage.

El Paquete Claire, écrit à l'origine avec la sécurité à l'esprit, a montré la meilleure sécurité.

Aucun problème identifié dans le package Trivy et en conséquence, il a été conclu que les scanners de conteneurs Docker devraient être exécutés dans des environnements isolés ou utilisés uniquement pour vérifier leurs propres images, et également être prudent lors de la connexion de ces outils à des systèmes d'intégration continue automatisés.

Ces scanners font des choses compliquées et sujettes aux erreurs. Ils s'occupent du docker, d'extraire des couches / fichiers, d'interagir avec les gestionnaires de packages ou d'analyser différents formats. Les défendre, tout en essayant de s'adapter à tous les cas d'utilisation pour les développeurs, est très difficile. Voyons comment les différents outils essaient et parviennent à le faire:

Le score de divulgation responsable reflète mon opinion personnelle: je pense qu'il est important pour les éditeurs de logiciels d'être réceptifs aux problèmes de sécurité qui leur sont signalés, d'être honnêtes et transparents sur les vulnérabilités, de s'assurer que les personnes qui utilisent leurs produits sont dûment informés pour prendre des décisions concernant la mise à jour. Cela inclut les informations les plus importantes selon lesquelles une mise à jour comporte des modifications liées à la sécurité, l'ouverture d'un CVE pour suivre et communiquer sur le problème, et potentiellement informer vos clients. Je pense que cela est particulièrement raisonnable à supposer si le produit concerne CVE, fournissant des informations sur les vulnérabilités du logiciel. De plus, je suis rassuré par la rapidité de la réponse, les délais de correction raisonnables et la communication ouverte avec la personne qui signale l'attaque.

Chez FOSSA, Snyk et WhiteSource, la vulnérabilité était liée avec appel à un gestionnaire de packages externe pour déterminer les dépendances et vous permettre d'organiser l'exécution de votre code en spécifiant les commandes touch et système dans les fichiers gradlew et Podfile.

En Snyk et WhiteSource ont également trouvé une vulnérabilité, associée aux commandes du système de lancement organisation qui a analysé Dockerfile (par exemple, dans Snyk via Dockefile, vous pouvez remplacer l'utilitaire ls (/ bin / ls), provoqué par le scanner et dans WhiteSurce, vous pouvez remplacer le code par les arguments sous la forme "echo"; appuyez sur / tmp / hacked_whitesource_pip; = 1.0 '«).

Dans Anchore, la vulnérabilité a été causée par l'utilisation de l'utilitaire skopeo pour travailler avec des images de docker. L'opération a été réduite à l'ajout de paramètres de la forme '»os»: «$ (touch hacked_anchore)»' au fichier manifest.json, qui sont remplacés lors de l'appel de skopeo sans échappement approprié (seuls les caractères «; & <ont été supprimés > ", Mais la construction" $ () ").

Le même auteur a mené une étude sur l'efficacité de la détection des vulnérabilités pas patché via des scanners de sécurité des conteneurs docker et le niveau de faux positifs.

Outre l'auteur fait valoir que plusieurs de ces outils utiliser directement les gestionnaires de packages pour résoudre les dépendances. Cela les rend particulièrement difficiles à défendre. Certains gestionnaires de dépendances ont des fichiers de configuration qui permettent l'inclusion de code shell. 

Même si ces moyens simples sont gérés d'une manière ou d'une autre, appeler ces gestionnaires de paquets signifiera inévitablement dépenser de l'argent. Ceci, pour le moins dire, ne facilite pas la défense de la demande.

Résultats des tests de 73 images contenant des vulnérabilités connu, ainsi qu'une évaluation de l'efficacité pour déterminer la présence d'applications typiques dans les images (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), peut être consulté dans la publication faite dans le lien suivant.


Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.