Les TPM sont des composants stockant des clés, des "mesures" (hachés) et réalisant des opérations cryptographiques (chiffrement, signature, génération d'aléa ou de clés). L'espace de stockage est minimal : on y stocke des clés "maître" qui (dé)chiffrent d'autres clés, stockées sur le disque dur ou ailleurs. Les TPM peuvent prendre la forme de puces matérielles dédiées (HSM simples), d'un firmware intégré à la carte mère (Trustes Execution Environment) ou d'implémentations logicielles.

On peut s'en servir pour enregistrer une séquence de démarrage, où chaque composant de la chaîne, du bios à l'OS, mesure le suivant avant de lui passer la main. On peut ensuite témoigner de la séquence auprès d'un tiers (comparaison avec des valeurs de références), utiliser ces valeurs de référence pour autoriser ou bloquer le démarrage (authenticated boot) ou conditionner l'usage d'une clé à ces valeurs, typiquement pour déchiffrer un disque dur.

Le niveau de sécurité que ça permet d'atteindre est intéressant, mais :

• la complexité de mise en place semble assez grande (au moins sur Linux)
• ça apporte une sécurité contre un attaquant qui aurait accès au matériel mais en attaquant uniquement le logiciel (bios, bootloader, OS...). Un attaquant sophistiqué saura ajouter une puce matérielle et contourner ces protections. Le scénario d'attaque auquel ces mesures répondent est donc assez improbable.

Résultat : les cas d'usage me semblent limités pour le moment.

La machinerie k8s répartit des pods (groupe de conteneurs) sur des machines formant un cluster de façon à garantir la haute disponibilité. Les pods se composent en services pour mettre en œuvre une application complète. Tous ces objets et leurs droits d'accès sont gérés par k8s. Les failles peuvent permettre à un conteneur compromis de prendre le contrôle d'un pod, d'un node (machine physique ou virtuelle qui héberge les pods) ou d'objets k8s, voire du cluster complet). Xavier Mehrenberger présente tout ça puis 2 vecteurs d'attaque : helm (gestionnaire de paquets pour k8s), dans sa version 2, avait les droits d'administration du cluster mais n'effectuait par défaut aucune authentification, et la compromission d'images docker via le respository (parfois accessible en écriture) ou la liaison entre k8s et le repository (non chiffrée par défaut !)

Le filtrage du réseau entre les conteneurs doit être pris en charge par un network plugin (il en existe plusieurs, avec des fonctionnalités différentes). Guillaume Fournier examine la possibilité d'affiner les règles en contrôlant les processus de départ et/ou d'arrivée, et pas seulement les conteneurs, comme on le ferait à l'échelle d'un système avec un pare-feu classique.

Frédéric Raynal et Damien Aumaitre remarquent que kubernetes fonctionne comme un système d'exploitation, dont les processus seraient les pods (les threads les conteneurs), où le noyai est en charge de la bonne exécution de chacun et d'une juste répartition des ressources. Les modalités d'attaque classiques (compromission de processus, élévation de privilèges...) sont tout à fait transposable à cet environnement.

Les auteurs ont aussi donné une interview à nolimitsecu fin mars.

Par défaut docker n'écoute pas sur le réseau. Mais quand l'API réseau est activée (par exemple pour un orchestrateur), par défaut il n'y pas d'authentification et les communications se font en clair (port 2375).

Si on est root dans un conteneur et que celui-ci a les capacités DAC_OVERRIDE (présente par défaut) et CAP_READ_SEARCH (absente par défaut), on peut modifier des fichiers arbitraires sur l'hôte, donc en prendre le contrôle (shocker).