Alert!

Kubernetes-Entwickler warnen vor internen Man-in-the-Middle-Angriffen

Das Kubernetes-Security-Team warnt vor einem Sicherheitsproblem, das noch nicht per Patch gelöst werden kann. Die Angreifer müssen aber Nutzer im Cluster sein.

In Pocket speichern vorlesen Druckansicht 3 Kommentare lesen
Lesezeit: 2 Min.
Von
  • Jan Mahn

Bereits im Frühjahr 2020 wurden die für Security zuständigen Kubernetes-Maintainer auf ein Problem aufmerksam gemacht, das sich nicht mit einem einfachen Patch beheben lässt. Nutzer, die mit entsprechenden Rechten im Cluster ausgestattet sind, können einen Container im Cluster starten und auf diesen Verkehr umleiten, der für externe Adressen bestimmt ist.

Das Problem tritt nur in Umgebungen auf, die sich mehrere Teams teilen – und sich gegenseitig nicht trauen. Jeder Nutzer des Clusters, der die Berechtigung hat, einen Service mit dem Attribut spec.externalIPs anzulegen, oder das Attribut status.loadBalancer.ingress.ip eines LoadBalancers zu ändern, kann diesen Angriff umsetzen. Er startet beispielsweise einen Container, den den gesamten Verkehr mitschneidet und protokolliert und legt einen sogenannten ClusterIP-Service (eine Port-Weiterleitung im Kubernetes-Netzwerk) an. Richtet er für diesen Service eine externalIP ein, zum Beispiel auf die IP von heise.de, kommt sämtlicher Verkehr, den andere Container an diese IP richten, auf dem Container des Angreifers an. Spätestens, wenn der Verkehr per TLS gesichert ist und der anfragenden Container gewissenhaft die Zertifikate prüft, fällt die Attacke auf.

Im YAML-Format für Kubectl sieht ein solcher Angriff zum Beispiel so aus:

apiVersion: v1 
kind: Service
metadata:
    name: evil-mitm-service
spec:
    selector:
      app: evil-mitm-app
    type: ClusterIP
    ports:
      - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    externalIPs:
      - 193.99.144.80 #heise.de

Einen schnellen Fix für das Problem gibt es nicht, weil das Verhalten durchaus erwünscht sein kann. Es einfach abzudrehen, würde laufende Umgebungen lahmlegen und wäre ein Breaking Change. Das Security-Team hat sich dazu entschieden, vorsorglich eine CVE-Nummer (CVE-2020-8554) zu beantragen und in der Newsgruppe und in einer Issue bei GitHub zu einer Diskussion über mögliche langfristige Lösungen anzuregen.

Betreibern von großen Umgebungen, in denen nicht jeder dem anderen vertrauen kann, wird geraten, möglichst wenigen Administratoren die Berechtigung zuzuweisen, ClusterIP-Services und LoadBalancer anzulegen und alle entsprechenden Änderungen an solchen zu monitoren. Mit dem Einsatz von Open Policy Agent (OPA) und dem OPA-Gatekeeper kann man noch genauer steuern, wer Umleitungen für externe IP-Adressen setzen darf und so möglicherweise unberechtigt Verkehr mitschneiden kann.

(jam)