tabbysable/poc-2020-8558Informations sur Kubernetes CVE-2020-8558, y compris un exploit de preuve de concept.
La CVE-2020-8558 est une vulnérabilité de Kubernetes publiée parce que kube-proxy rend de manière inattendue les services liés à l'hôte local (localhost) accessibles aux autres machines du réseau. Je mets l'accent sur « de manière inattendue » parce que cette vulnérabilité provient d'un défaut de conception (un oubli), et non d'un défaut d'implémentation (un bug). Le code fait exactement ce qu'il prétend faire, mais nous avons tous échoué à reconnaître les implications de sécurité de cette décision.
Afin de permettre aux processus hôtes d'accéder aux services NodePort via l'adresse 127.0.0.1(localhost), kube-proxy définit le paramètre sysctl net.ipv4.conf.all.route_localnet=1. Selon la documentation du noyau, ce paramètre fait que le noyau « ne considère pas les adresses de bouclage comme martiennes » -- une conséquence étant qu'elles peuvent être accessibles par d'autres nœuds du réseau. C'est un vrai problème si vous avez des services sensibles non authentifiés dont la seule protection est d'être liés à localhost !
À l'heure où j'écris ces lignes, la communauté Kubernetes cherche encore la meilleure façon de traiter la CVE-2020-8558. Les deux choix évidents sont de cesser de définir le sysctl route_localnet en premier lieu, ou de bloquer les paquets localnet routés de manière inappropriée à l'aide d'iptables. Un correctif utilisant cette dernière stratégie a déjà été publié dans kubelet >= 1.18.4, 1.17.7, ou 1.16.11. Vous pouvez également l'appliquer vous-même en vous référant au problème Kubernetes pour cette CVE, lié ci-dessous.
Pourquoi la définition de net.ipv4.conf.all.route_localnet=1 mérite-t-elle un identifiant CVE ? Principalement parce qu'elle viole notre intuition concernant les réseaux IP.
Depuis au moins la RFC 1122 de 1989, les paquets provenant du réseau de bouclage 127.0.0.1/8 sont traités de manière spéciale, interdits d'apparaître « en dehors d'un hôte ». (Veuillez me contacter sur Twitter si vous connaissez une référence plus ancienne aux propriétés spéciales de 127/8.) Tout hôte conforme à la RFC possède essentiellement une règle de pare-feu implicite et non amovible qui bloque l'accès extérieur aux services liés à 127.0.0.1 (et aux autres adresses IP de ce réseau -- essayez de pinguer 127.127.127.127 si vous ne l'avez jamais fait !). Nous en sommes venus à dépendre de ce comportement et à l'attendre. Nous exécutons fréquemment des services sensibles sans authentification ni chiffrement, et nous les lions à localhost pour des raisons de sécurité. Par exemple, les backends HTTP en clair, le magasin de clés-valeurs redis et le port non sécurisé résiduel du serveur d'API Kubernetes sont généralement protégés de cette manière contre les intrusions. Nous sommes tellement habitués à ce comportement qu'il fait partie intégrante de notre compréhension intuitive de ce que signifie être un hôte IP. Vu sous cet angle, il est compréhensible que de nombreux experts aient pu négliger cette faille pendant si longtemps.
Comment ça marche ?
Appelons « nœud » toute entité possédant une adresse IP. Les paquets IP sont envoyés d'un nœud à un autre, identifiés par les adresses IP source et destination dans l'en-tête du paquet. Chaque nœud IP est soit un routeur (appelé passerelle dans la RFC1122), soit un hôte. La principale différence est que lorsqu'un hôte reçoit des paquets destinés à l'adresse de quelqu'un d'autre, il les ignore. Un routeur consulte sa table de routage et retransmet (achemine) les paquets afin de les rapprocher de leur destination finale. Un hôte connaît certains nœuds connectés localement ; pour accéder à d'autres nœuds, il doit envoyer ses paquets à un routeur connecté localement. Ces connexions locales peuvent être de type point à point (comme une liaison PPP ou certains réseaux virtuels) ou à support partagé (comme Ethernet).
Votre boîte aux lettres peut être conceptualisée comme une liaison point à point entre votre maison et le bureau de poste local. Pour acheminer un paquet sur une liaison point à point, l'hôte n'a qu'à appliquer l'adresse de destination correcte et transmettre le paquet. (Cela se produit au niveau de la couche 3 du modèle OSI.) Pour acheminer un paquet sur une liaison à support partagé, l'hôte doit d'abord construire un circuit virtuel point à point à travers le support partagé. Dans les réseaux Ethernet/IP, cela se fait par ARP, au niveau de la couche 2 du modèle OSI. Essentiellement, si vous pouvez transmettre un paquet ARP, vous pouvez dire à un autre hôte « Hé, je suis ici » et il vous croira. (Lorsque cela est fait de manière inappropriée, on parle d'empoisonnement du cache ARP.) Ensuite, vous pouvez communiquer en plaçant les adresses Ethernet source et destination appropriées sur vos paquets.
Un nœud normal ne transmettra jamais un paquet avec une adresse de destination de 127.0.0.1, à cause de la RFC 1122. Si un nœud normal reçoit un paquet avec une adresse de destination de 127.0.0.1, il l'ignorera (le rejettera), encore une fois à cause de la RFC 1122. Définir net.ipv4.conf.all.route_localnet=1 change cela -- cela permet aux paquets 127.0.0.1 d'être envoyés et reçus comme s'ils n'étaient pas spéciaux.
Donc, si un attaquant dispose d'une connexion locale vers un nœud cible avec net.ipv4.conf.all.route_localnet=1, il peut lui envoyer un paquet avec 127.0.0.1 comme adresse de destination, et ce nœud cible répondra de manière appropriée comme si 127.0.0.1 était une adresse tout à fait normale. Les deux façons les plus courantes aujourd'hui d'avoir une connexion locale vers un nœud cible sont d'être sur le même réseau Ethernet (domaine de diffusion) que la cible, ou d'être un conteneur exécuté sur la cible.
Notez que, lorsqu'il est configuré normalement, Linux ne permettra pas au nœud attaquant de transmettre des paquets normaux destinés à 127.0.0.1. On peut contourner cela en reconfigurant le nœud Linux de l'attaquant (s'il dispose d'un accès root), ou en forgeant des paquets à l'aide d'une socket brute. Les sockets brutes ne nécessitent que la capacité du noyau Linux CAP_NET_RAW, qui est donnée par défaut aux conteneurs non privilégiés. Cela signifie qu'un conteneur non privilégié contrôlé par un attaquant est capable d'exploiter la CVE-2020-8558.
En bref, si vous utilisez kube-proxy ou faites des choses astucieuses avec net.ipv4.conf.*.route_localnet, vous êtes exposé. Vous devriez passer du temps à modéliser les menaces pour déterminer à quel point cette exposition est risquée pour vous et planifier une stratégie d'atténuation appropriée.
Fondamentalement, tout hôte Linux avec net.ipv4.conf.all.route_localnet=1 défini est vulnérable. Que cette vulnérabilité soit intéressante pour un attaquant dépend de plusieurs facteurs :
Pour évaluer la CVE-2020-8558, vous devez imaginer des attaquants ayant diverses capacités et répondre à ces questions du point de vue de ces attaquants. (Le livre d'Adam Shostack « Threat Modeling: Designing for Security » décrit ce processus en grand détail.) Deux attaquants pertinents que vous devriez certainement considérer sont un attaquant disposant d'un nœud sur votre réseau Ethernet et un attaquant capable d'exécuter du code dans un pod non privilégié sur votre hôte. Il peut y avoir d'autres attaquants intéressants que vous devriez également considérer, selon votre environnement et vos besoins.
Pour illustrer, voici un exemple partiellement travaillé :
L'hôte est certainement accessible aux deux attaquants ; nous l'avons supposé dans chaque cas.
Les paquets peuvent être filtrés ou non. Vous devrez vérifier. Dans de nombreux environnements cloud et réseaux sur site strictement gérés, les paquets sont bloqués si l'adresse IP de destination ne correspond pas à l'adresse Ethernet de destination attendue par le réseau. Cela pourrait à lui seul signer la fin de partie pour l'attaquant-avec-un-nœud. Si tous vos nœuds disposent de règles de pare-feu locales appropriées (comme celles fournies par un kubelet à jour), cela fera échouer les deux attaquants.
Il y a probablement plus de services intéressants que vous ne le pensez. Évidemment, le port non sécurisé du serveur d'API Kubernetes est une cible très attrayante, et vous devriez le désactiver si vous le pouvez. Examinez tous les processus liés à des adresses IP du réseau 127.0.0.0/8 : disposent-ils d'une authentification robuste ? Sinon, ils pourraient être exposés via la CVE-2020-8558. Même si tous vos services localhost normaux sont sûrs, les services éphémères peuvent également être préoccupants. Par exemple, la redirection de port SSH est souvent utilisée pour contourner les restrictions réseau à des fins temporaires et autorisées. Par défaut, les ports redirigés par SSH sont liés à localhost afin que l'accès temporaire ne soit autorisé qu'aux utilisateurs autorisés. Avec la CVE-2020-8558, ces redirections de port « sûres » sont également disponibles pour vos attaquants.
En supposant que vous ayez un accès root sur une machine Linux située dans le même domaine de diffusion que la cible, les paramètres de configuration suivants vous permettront d'exploiter la CVE-2020-8558 :
ip addr add 127.0.0.2/8 dev lo
ip addr del 127.0.0.1/8 dev lo
ip route add 127.0.0.1/32 via YOUR-TARGET-HERE
sysctl net.ipv4.conf.all.route_localnet=1
Parce que certains services importants (toux, toux, systemd-resolved) s'exécutent sur une adresse 127.0.0.0/8, nous en ajoutons une nouvelle pour éviter de casser l'hôte. Ensuite, l'hôte doit oublier son adresse 127.0.0.1/8 par défaut. Ensuite, nous demandons au noyau d'acheminer le trafic destiné à 127.0.0.1 sur le fil vers votre cible, qui sait comment accéder à 127.0.0.1. Enfin, nous définissons le fameux sysctl qui, autrement, empêcherait cette configuration de fonctionner.
Script Python simple pour tester la CVE-2020-8558 en envoyant des paquets bruts. Cela pourrait être un one-liner scapy, mais je voulais ajouter un peu plus de confort de la maison. Il envoie un paquet à 127.0.0.1 via votre cible et cherche à voir s'il y a une réponse.
Script Python pour exploiter la CVE-2020-8558 en permettant à des applications clientes TCP ou UDP ordinaires de communiquer avec une adresse IP localhost distante via des paquets forgés. Exécutez ce script, puis utilisez n'importe quel client TCP ou UDP normal (par exemple kubectl ou nc) pour vous connecter à votre fakedestination (198.51.100.1 par défaut).
Notez que la fakedestination doit être une adresse IP qui ne répond jamais aux paquets et que votre route vers elle doit passer par la même interface que celle que vous utilisez pour accéder à votre cible. Dans le cas habituel, la fakedestination et la cible seront toutes deux accessibles via votre interface de passerelle par défaut, et cela ne posera pas de problème.
Comme ce script utilise des sockets brutes pour envoyer et recevoir les paquets « localhost », il fonctionne correctement dans un conteneur non privilégié normal.
Problème Kubernetes pour cette CVE sur GitHub
Documentation des sysctl IP du noyau
Adam Shostack : Threat Modeling
Un grand merci à Ian Coldwater, Brad Geesaman, Duffie Cooley et Laurent Bernaille. Merci pour les réflexions, les conseils et les éclats de rire, à tous. Klaxonnez la planète !