Pentesting Kubernetes Services
Kubernetes utilise plusieurs services réseau spécifiques que vous pourriez trouver exposés sur Internet ou dans un réseau interne une fois que vous avez compromis un pod.
Recherche de pods exposés avec OSINT
Une méthode pourrait consister à rechercher Identity LIKE "k8s.%.com"
dans crt.sh pour trouver des sous-domaines liés à Kubernetes. Une autre méthode pourrait consister à rechercher "k8s.%.com"
sur GitHub et à rechercher des fichiers YAML contenant la chaîne.
Comment Kubernetes expose les services
Il pourrait être utile pour vous de comprendre comment Kubernetes peut exposer des services publiquement afin de les trouver :
Exposing Services in KubernetesRecherche de pods exposés via un balayage de ports
Les ports suivants pourraient être ouverts dans un cluster Kubernetes :
Port | Processus | Description |
---|---|---|
443/TCP | kube-apiserver | Port de l'API Kubernetes |
2379/TCP | etcd | |
6666/TCP | etcd | etcd |
4194/TCP | cAdvisor | Métriques des conteneurs |
6443/TCP | kube-apiserver | Port de l'API Kubernetes |
8443/TCP | kube-apiserver | Port de l'API Minikube |
8080/TCP | kube-apiserver | Port d'API non sécurisé |
10250/TCP | kubelet | API HTTPS permettant un accès complet en mode |
10255/TCP | kubelet | Port HTTP en lecture seule non authentifié : pods, pods en cours d'exécution et état du nœud |
10256/TCP | kube-proxy | Serveur de vérification de l'état de santé de Kube Proxy |
9099/TCP | calico-felix | Serveur de vérification de l'état de santé pour Calico |
6782-4/TCP | weave | Métriques et points de terminaison |
30000-32767/TCP | NodePort | Proxy vers les services |
44134/TCP | Tiller | Service Helm en écoute |
Nmap
Kube-apiserver
C'est le service API Kubernetes avec lequel les administrateurs communiquent généralement en utilisant l'outil kubectl
.
Ports courants : 6443 et 443, mais aussi 8443 dans minikube et 8080 en mode non sécurisé.
Consultez la page suivante pour apprendre comment obtenir des données sensibles et effectuer des actions sensibles en parlant à ce service :
Kubernetes EnumerationAPI Kubelet
Ce service s'exécute sur chaque nœud du cluster. C'est le service qui contrôlera les pods à l'intérieur du nœud. Il communique avec le kube-apiserver.
Si vous trouvez ce service exposé, vous pourriez avoir découvert une RCE non authentifiée.
API Kubelet
Si la réponse est Unauthorized
, alors une authentification est nécessaire.
Si vous pouvez répertorier les nœuds, vous pouvez obtenir une liste des points de terminaison des kubelets avec :
kubelet (Lecture seule)
API etcd
Tiller
Vous pourriez abuser de ce service pour escalader les privilèges à l'intérieur de Kubernetes :
cAdvisor
Service utile pour collecter des métriques.
NodePort
Lorsqu'un port est exposé dans tous les nœuds via un NodePort, le même port est ouvert dans tous les nœuds pour acheminer le trafic vers le Service déclaré. Par défaut, ce port sera dans la plage 30000-32767. Ainsi, de nouveaux services non vérifiés pourraient être accessibles via ces ports.
Vulnérabilités de configuration incorrecte
Accès anonyme à Kube-apiserver
L'accès anonyme aux points d'API de kube-apiserver n'est pas autorisé. Cependant, vous pouvez vérifier certains points d'accès :
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fwww.cyberark.com%2Fwp-content%2Fuploads%2F2019%2F09%2FKube-Pen-2-fig-5.png&width=768&dpr=4&quality=100&sign=ff25c70&sv=1)
Vérification de l'accès anonyme à ETCD
ETCD stocke les secrets du cluster, les fichiers de configuration et d'autres données sensibles. Par défaut, l'ETCD ne peut pas être accédé de manière anonyme, mais il est toujours bon de vérifier.
Si l'ETCD peut être accédé de manière anonyme, vous devrez peut-être utiliser l' outil etcdctl. La commande suivante récupérera toutes les clés stockées :
Kubelet RCE
La documentation de Kubelet explique que par défaut l'accès anonyme au service est autorisé :
Autorise les requêtes anonymes au serveur Kubelet. Les requêtes qui ne sont pas rejetées par un autre méthode d'authentification sont traitées comme des requêtes anonymes. Les requêtes anonymes ont un nom d'utilisateur
system:anonymous
et un nom de groupesystem:unauthenticated
.
Pour mieux comprendre comment l'authentification et l'autorisation de l'API Kubelet fonctionnent, consultez cette page :
Kubelet Authentication & AuthorizationLe service Kubelet API n'est pas documenté, mais le code source peut être trouvé ici et trouver les points de terminaison exposés est aussi simple que d'exécuter :
Vous pouvez utiliser l'outil Kubeletctl pour interagir avec les Kubelets et leurs points de terminaison.
/pods
Cet endpoint répertorie les pods et leurs conteneurs :
/exec
Cet endpoint permet d'exécuter du code à l'intérieur de n'importe quel conteneur très facilement :
Pour éviter cette attaque, le service kubelet doit être exécuté avec --anonymous-auth false
et le service doit être séparé au niveau du réseau.
Vérification de l'exposition des informations du port en lecture seule de Kubelet
Lorsqu'un port en lecture seule de kubelet est exposé, il devient possible de récupérer des informations de l'API par des parties non autorisées. L'exposition de ce port peut entraîner la divulgation de divers éléments de configuration de cluster. Bien que les informations, y compris les noms des pods, les emplacements des fichiers internes et autres configurations, ne soient pas critiques, leur exposition représente tout de même un risque pour la sécurité et doit être évitée.
Un exemple de l'exploitation de cette vulnérabilité implique un attaquant distant accédant à une URL spécifique. En naviguant vers http://<external-IP>:10255/pods
, l'attaquant peut potentiellement récupérer des informations sensibles du kubelet :
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fwww.cyberark.com%2Fwp-content%2Fuploads%2F2019%2F09%2FKUbe-Pen-2-fig-6.png&width=768&dpr=4&quality=100&sign=66aa23e7&sv=1)
Références
Last updated