Où sont toutes les violations de conteneurs ?

Comment les pirates attaqueront-ils et utiliseront-ils les conteneurs ? C'est une question à laquelle je pense constamment. Je travaille dans ce domaine depuis plus de deux décennies maintenant, et j'ai l'impression que je devrais avoir une réponse. Mais je ne le fais pas.

Au lieu de cela, j'ai beaucoup d'idées différentes, dont aucune ne peut vraiment être identifiée comme correcte. Une partie de cette indécision est due à tout le temps que j'ai passé à apprendre la sécurité dans le monde « hérité ». Les conteneurs n'ont pas vraiment d'analogue. Bien sûr, les machines virtuelles (VM) sont souvent confondues avec des conteneurs, mais elles n'ont jamais pu évoluer comme des conteneurs. Ils sont également utilisés à des fins complètement différentes de celles des conteneurs. Il m'a fallu un certain temps pour ajuster ma réflexion et comprendre où les conteneurs s'intègrent réellement dans la surface d'attaque.

Les exemples publics d'attaques contre des environnements conteneurisés sont très limités. Les brèches sont presque toujours liées au minage de cryptomonnaies, qui sont des attaques sérieuses, mais la personne qui répond aux incidents en moi les trouve décevantes. Un autre point commun est qu'ils sont principalement le résultat d'une mauvaise configuration, que ce soit dans Kubernetes ou un compte cloud. La combinaison des motifs et des tactiques n'a pas été très inspirante jusqu'à présent.

L'ancienne manière

Les vulnérabilités d'exécution de code à distance (RCE) sont depuis longtemps la principale préoccupation en matière de sécurité informatique. Ils le sont toujours, mais comment cette façon de penser s'applique-t-elle aux conteneurs ? Il est facile de passer immédiatement au RCE en tant que menace principale, mais cela ne semble pas être la bonne façon d'aborder les conteneurs. D'une part, les conteneurs ont souvent une durée de vie très courte - 44% des conteneurs vivent moins de cinq minutes – donc un intrus devrait être rapide.

Cette approche suppose également que le conteneur est exposé à Internet. Certes, certains conteneurs sont configurés de cette manière, mais ils sont souvent très simples et utilisent des technologies éprouvées, comme NGINX. Il peut y avoir des jours zéro pour ces applications, mais elles seraient extrêmement précieuses et difficiles à trouver. Mon expérience m'a montré que beaucoup de conteneurs sont utilisés en interne et ne se connectent pas directement à Internet. Le scénario RCE devient beaucoup plus difficile dans ce cas. je devrais mentionner log4j, bien que ces types de vulnérabilités puissent être exploitées à distance même si le système vulnérable n'est pas en périphérie.

La nouvelle façon

Si le RCE n'est pas la plus grande menace pour les conteneurs, alors qu'est-ce que c'est ? Les conteneurs sont-ils même sur le radar des acteurs de la menace ? Oui, les conteneurs et leur infrastructure de support sont trop importants pour être ignorés. Le logiciel d'orchestration de conteneurs a permis d'adapter les charges de travail conteneurisées à des nombres inimaginables. La tendance d'utilisation est également à la hausse, vous pouvez donc être sûr qu'ils seront une cible. Ils ne peuvent tout simplement pas être considérés comme des serveurs auxquels vous accédez via des vulnérabilités RCE.

Au lieu de cela, l'inverse est en fait vrai. Au lieu d'attaquer les conteneurs de l'extérieur vers l'intérieur, ils doivent être attaqués de l'intérieur vers l'extérieur. C'est essentiellement ce que font les attaques de la chaîne d'approvisionnement. La supply chain est un vecteur d'attaque extrêmement efficace contre les conteneurs quand on commence à comprendre comment ils sont construits. Un conteneur commence par un fichier de définition, tel que Dockerfile, qui définit tout ce qui se trouvera dans le conteneur lors de son exécution. Elle est transformée en une image une fois construite, et cette image est ce qui peut être transformé en charge de travail un nombre incalculable de fois. Si quelque chose dans ce fichier de définition est compromis, alors chaque charge de travail qui s'exécute est compromise.

Les conteneurs sont souvent, mais pas toujours, spécialement conçus avec une application qui fait quelque chose et se ferme. Ces applications peuvent être presque n'importe quoi - la chose importante à comprendre est de savoir combien est construit à l'aide de bibliothèques, qu'elles soient fermées ou open source, écrites par d'autres personnes. GitHub a des millions de projets, et ce n'est pas le seul référentiel de code disponible. Comme nous l'avons vu avec SolarWinds, la source fermée est également vulnérable aux attaques de la chaîne d'approvisionnement.

Une attaque de la chaîne d'approvisionnement est un excellent moyen pour les acteurs de la menace d'entrer dans l'environnement de conteneurs d'une cible. Ils peuvent même laisser l'infrastructure du client dimensionner leur attaque pour eux si le compromis passe inaperçu. Ce type de scénario est déjà en train de se jouer, comme on l'a vu avec le Violation de Codecov. Mais c'est difficile à détecter en raison de la nouveauté de tout cela et de la façon dont notre pensée est encore enracinée dans les problèmes du passé.

Une voie à suivre

Comme pour la résolution de la plupart des problèmes, la visibilité est généralement un excellent point de départ. Il est difficile de réparer ce que vous ne pouvez pas voir. Pour sécuriser vos conteneurs, vous devez avoir une visibilité sur les conteneurs eux-mêmes, ainsi que sur l'ensemble du pipeline qui les construit. La gestion des vulnérabilités est un type de visibilité qui doit être intégré dans le pipeline de build. J'inclurais également d'autres outils d'analyse statique, tels que ceux qui recherchent également des secrets divulgués. Étant donné qu'il est impossible de prévoir à quoi ressemble une attaque de la chaîne d'approvisionnement, la surveillance de l'exécution devient essentielle pour que vous sachiez exactement ce que font vos conteneurs.