tabbysable/poc-2020-8558Informationen über Kubernetes CVE-2020-8558, einschließlich Proof-of-Concept-Exploit.
CVE-2020-8558 ist eine Kubernetes-Sicherheitslücke, die veröffentlicht wurde, weil kube-proxy unerwarteterweise lokale, an localhost gebundene Host-Dienste für andere im Netzwerk verfügbar macht. Ich betone „unerwarteterweise", weil diese Schwachstelle auf einem Designfehler (Versehen) beruht, nicht auf einem Implementierungsfehler (Bug). Der Code tut genau das, was er tun soll, aber wir alle haben es versäumt, die Sicherheitsauswirkungen dieser Entscheidung zu erkennen.
Um Host-Prozessen den Zugriff auf NodePort-Dienste über die Adresse 127.0.0.1(localhost) zu ermöglichen, setzt kube-proxy die Sysctl-Einstellung net.ipv4.conf.all.route_localnet=1. Laut Kernel-Dokumentation bewirkt diese Einstellung, dass der Kernel „Loopback-Adressen nicht als Martian betrachtet" – eine Folge davon ist, dass sie von anderen Knoten im Netzwerk erreicht werden können. Das ist eine große Sache, wenn du sensible Dienste ohne Authentifizierung betreibst, deren einziger Schutz die Bindung an localhost ist!
Zum Zeitpunkt dieses Schreibens arbeitet die Kubernetes-Community noch an der besten Lösung für CVE-2020-8558. Die beiden naheliegenden Optionen sind, die Sysctl-Einstellung route_localnet erst gar nicht zu setzen oder unangemessen weitergeleitete Localnet-Pakete mit iptables zu blockieren. Ein Fix, der die letztgenannte Strategie verwendet, wurde bereits in kubelet >= 1.18.4, 1.17.7 oder 1.16.11 veröffentlicht. Du kannst ihn auch selbst anwenden, indem du dich auf das weiter unten verlinkte Kubernetes-Issue für diese CVE beziehst.
Warum verdient das Setzen von net.ipv4.conf.all.route_localnet=1 eine CVE-ID? In erster Linie, weil es unsere Intuition über IP-Netzwerke verletzt.
Seit mindestens RFC 1122 aus dem Jahr 1989 werden Pakete aus dem Localhost-Netzwerk 127.0.0.1/8 besonders behandelt und dürfen nicht „außerhalb eines Hosts" erscheinen. (Bitte kontaktiere mich auf Twitter, wenn du eine frühere Referenz zu den besonderen Eigenschaften von 127/8 kennst.) Jeder RFC-konforme Host hat im Wesentlichen eine implizite, nicht entfernte Firewall-Regel, die den Zugriff von außen auf Dienste blockiert, die an 127.0.0.1 (und andere IPs in diesem Netzwerk – probier mal, 127.127.127.127 anzupingen, falls du das noch nie getan hast!) gebunden sind. Wir haben uns darauf verlassen und dieses Verhalten erwartet. Wir betreiben häufig sensible Dienste ohne Authentifizierung oder Verschlüsselung und binden sie aus Sicherheitsgründen an localhost. Zum Beispiel sind unverschlüsselte HTTP-Backends, der Redis-Key-Value-Store und der überkommene unsichere Kubernetes-API-Server-Port normalerweise auf diese Weise vor Eindringlingen geschützt. Wir sind so an dieses Verhalten gewöhnt, dass es ein fester Bestandteil unserer intuitiven Vorstellung davon ist, was es bedeutet, ein IP-Host zu sein. So betrachtet ist es verständlich, dass zahlreiche Experten diesen Fehler so lange übersehen konnten.
Wie funktioniert das?
Nennen wir jede Entität mit einer IP-Adresse einen „Knoten" (Node). IP-Pakete werden von einem Knoten zu einem anderen gesendet, identifiziert durch die Quell- und Ziel-IP-Adresse im Paketkopf. Jeder IP-Knoten ist entweder ein Router (in RFC 1122 als Gateway bezeichnet) oder ein Host. Der Hauptunterschied besteht darin, dass ein Host Pakete, die für die Adresse eines anderen bestimmt sind, ignoriert. Ein Router konsultiert seine Routing-Tabelle und leitet Pakete weiter, um sie ihrem endgültigen Ziel näher zu bringen. Ein Host kennt einige lokal verbundene Knoten; um andere Knoten zu erreichen, muss er seine Pakete an einen lokal verbundenen Router senden. Diese lokalen Verbindungen können Punkt-zu-Punkt (z. B. eine PPP-Verbindung oder einige virtuelle Netzwerke) oder gemeinsam genutzte Medien (z. B. Ethernet) sein.
Dein Briefkasten kann als Punkt-zu-Punkt-Verbindung zwischen deinem Haus und der örtlichen Poststelle betrachtet werden. Um ein Paket über eine Punkt-zu-Punkt-Verbindung zu leiten, muss der Host nur die korrekte Zieladresse anwenden und das Paket senden. (Dies geschieht auf Schicht 3 des OSI-Modells.) Um ein Paket über ein gemeinsames Medium zu leiten, muss der Host zunächst eine virtuelle Punkt-zu-Punkt-Verbindung über das gemeinsame Medium aufbauen. In Ethernet/IP-Netzwerken geschieht dies per ARP auf Schicht 2 des OSI-Modells. Im Wesentlichen gilt: Wenn du ein ARP-Paket senden kannst, kannst du einem anderen Host sagen: „Hey, ich bin hier drüben", und er wird es dir glauben. (Wenn dies unangemessen geschieht, nennt man es ARP-Cache-Poisoning.) Dann kannst du kommunizieren, indem du die entsprechenden Ethernet-Quell- und -Zieladressen in deine Pakete einfügst.
Ein normaler Knoten wird niemals ein Paket mit der Zieladresse 127.0.0.1 senden, wegen RFC 1122. Wenn ein normaler Knoten ein Paket mit der Zieladresse 127.0.0.1 empfängt, wird er es ignorieren (verwerfen), wiederum wegen RFC 1122. Das Setzen von net.ipv4.conf.all.route_localnet=1 ändert das – es erlaubt das Senden und Empfangen von 127.0.0.1-Paketen, als wären sie nichts Besonderes.
Wenn also ein Angreifer eine lokale Verbindung zu einem Zielknoten mit net.ipv4.conf.all.route_localnet=1 hat, kann er ihm ein Paket mit der Zieladresse 127.0.0.1 senden, und dieser Zielknoten wird entsprechend antworten, als ob 127.0.0.1 eine völlig normale Adresse wäre. Die beiden häufigsten Möglichkeiten, heutzutage eine lokale Verbindung zu einem Zielknoten zu haben, sind, sich im selben Ethernet-Netzwerk (Broadcast-Domäne) wie das Ziel zu befinden oder ein Container zu sein, der auf dem Ziel läuft.
Beachte, dass Linux bei normaler Konfiguration dem Angreiferknoten nicht erlaubt, normale Pakete mit dem Ziel 127.0.0.1 zu senden. Das kann umgangen werden, indem der Linux-Knoten des Angreifers neu konfiguriert wird (falls er Root-Zugriff hat), oder indem Pakete mit einem Raw-Socket gefälscht werden. Raw-Sockets erfordern nur die Linux-Kernel-Fähigkeit CAP_NET_RAW, die standardmäßig an unprivilegierte Container vergeben wird. Das bedeutet, dass ein vom Angreifer kontrollierter unprivilegierter Container in der Lage ist, CVE-2020-8558 auszunutzen.
Kurz gesagt: Wenn du kube-proxy verwendest oder raffinierte Dinge mit net.ipv4.conf.*.route_localnet machst, bist du gefährdet. Du solltest etwas Zeit in die Bedrohungsmodellierung investieren, um zu bestimmen, wie riskant diese Gefährdung für dich ist, und eine geeignete Gegenmaßnahme planen.
Im Grunde ist jeder Linux-Host mit gesetztem net.ipv4.conf.all.route_localnet=1 anfällig. Ob diese Schwachstelle für einen Angreifer interessant ist, hängt von mehreren Faktoren ab:
Um CVE-2020-8558 zu bewerten, musst du dir Angreifer mit verschiedenen Fähigkeiten vorstellen und diese Fragen aus der Sicht dieser Angreifer beantworten. (Adam Shostacks Buch „Threat Modeling: Designing for Security" beschreibt diesen Prozess sehr detailliert.) Zwei relevante Angreifer, die du unbedingt berücksichtigen solltest, sind ein Angreifer mit einem Knoten in deinem Ethernet-Netzwerk und ein Angreifer, der Code in einem unprivilegierten Pod auf deinem Host ausführen kann. Es gibt möglicherweise weitere interessante Angreifer, die du ebenfalls in Betracht ziehen solltest, je nach deiner Umgebung und deinen Anforderungen.
Zur Veranschaulichung hier ein teilweise durchgerechnetes Beispiel:
Der Host ist für beide Angreifer mit Sicherheit erreichbar; das haben wir in beiden Fällen angenommen.
Die Pakete können gefiltert sein oder auch nicht. Das musst du prüfen. In vielen Cloud-Umgebungen und streng verwalteten On-Premises-Netzwerken werden Pakete blockiert, wenn die IP-Zieladresse nicht mit der Ethernet-Zieladresse übereinstimmt, die das Netzwerk erwartet. Das allein könnte für den Angreifer mit einem Knoten das Aus bedeuten. Wenn alle deine Knoten über geeignete lokale Firewall-Regeln verfügen (wie sie von einem aktualisierten kubelet bereitgestellt werden), werden beide Angreifer scheitern.
Es gibt wahrscheinlich mehr interessante Dienste, als du denkst. Offensichtlich ist der unsichere Port des Kubernetes-API-Servers ein äußerst verlockendes Ziel, und du solltest ihn deaktivieren, wenn du kannst. Untersuche alle Prozesse, die an IP-Adressen im 127.0.0.0/8-Netzwerk gebunden sind: Verfügen sie über eine robuste Authentifizierung? Wenn nicht, könnten sie über CVE-2020-8558 gefährdet sein. Selbst wenn alle deine normalen localhost-Dienste sicher sind, können kurzlebige Dienste ebenfalls ein Problem darstellen. Zum Beispiel wird SSH-Portweiterleitung häufig genutzt, um Netzwerkbeschränkungen für zeitlich begrenzte, autorisierte Zwecke zu umgehen. Standardmäßig sind per SSH weitergeleitete Ports an localhost gebunden, sodass der temporäre Zugriff nur autorisierten Benutzern erlaubt ist. Mit CVE-2020-8558 sind diese „sicheren" Portweiterleitungen auch für deine Angreifer verfügbar.
Angenommen, du hast Root-Zugriff auf einem Linux-Rechner in derselben Broadcast-Domäne wie das Ziel, erlauben dir die folgenden Konfigurationseinstellungen, CVE-2020-8558 auszunutzen:
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
Da einige wichtige Dienste (hüstel, hüstel, systemd-resolved) auf einer 127.0.0.0/8-Adresse laufen, fügen wir eine neue hinzu, um den Host nicht zu beschädigen. Dann muss der Host seine Standardadresse 127.0.0.1/8 vergessen. Als Nächstes weisen wir den Kernel an, Verkehr für 127.0.0.1 über das Netzwerk zu deinem Ziel zu leiten, das weiß, wie es auf 127.0.0.1 zugreifen kann. Schließlich setzen wir das berüchtigte Sysctl, das diese Konfiguration sonst daran hindern würde, zu funktionieren.
Einfaches Python-Skript zum Testen auf CVE-2020-8558 durch Senden von Raw-Paketen. Das könnte ein Scapy-Einzeiler sein, aber ich wollte ein wenig mehr Komfort einbauen. Es sendet ein Paket an 127.0.0.1 über dein Ziel und prüft, ob eine Antwort kommt.
Python-Skript zum Ausnutzen von CVE-2020-8558, indem es gewöhnlichen TCP- oder UDP-Client-Anwendungen erlaubt, über gefälschte Pakete mit einer entfernten localhost-IP zu kommunizieren. Führe dieses Skript aus und verbinde dich dann mit einem normalen TCP- oder UDP-Client (z. B. kubectl oder nc) mit deiner fakedestination (standardmäßig 198.51.100.1).
Beachte, dass die fakedestination eine IP-Adresse sein muss, die nie auf Pakete antwortet, und deine Route dorthin über dasselbe Interface führen muss, über das du auf dein Ziel zugreifst. Im Normalfall sind sowohl fakedestination als auch Ziel über dein Standard-Gateway-Interface erreichbar, und das ist keine große Sache.
Da dieses Skript Raw-Sockets zum Senden und Empfangen der „localhost"-Pakete verwendet, funktioniert es problemlos in einem normalen unprivilegierten Container.
Kubernetes-Issue für diese CVE auf GitHub
Dokumentation der Kernel-IP-Sysctl
Adam Shostack: Threat Modeling
Shout-out an Ian Coldwater, Brad Geesaman, Duffie Cooley und Laurent Bernaille. Danke für die Gedanken, Ratschläge und Lacher, ihr alle. Hupt den Planeten an!