CyberArk Discloses Kubernetes Security Issues
CyberArk, a provider of privileged access management tools, published a report today detailing how weaknesses in the Container Network Interface (CNI) employed to connect Kubernetes Pods can be exploited by cybercriminals.
Nir Chako, security research team leader for CyberArk, says as Kubernetes clusters become more widely deployed, cybercriminals are employing some tried and true techniques to compromise CNI security.
Specifically, attack techniques such as Address Resolution Protocol (ARP) poisoning and DNS spoofing are being aimed at CNI plug-ins. The attacks show it’s possible to bypass different Kubernetes cluster security controls such as iptables rules used to set up a Linux firewall utility and hardening of the node operating system via subtle manipulation of networking features in Kubernetes environments.
Using these techniques, Chako says it’s possible to launch a DNS spoofing attack from a pod on a Kubernetes worker node. This attack vector impersonates the DNS server and returns false answers to DNS queries sent from a pod on the same worker node. Cybercriminals can direct the pod’s communications with the desired domain to an IP address of their choice, he says.
This attack vector is specific to Layer 2 network plugins, which means all the pods that are on a node are on the same subnet and are not segmented by a device that blocks Ethernet broadcasts. Launching these attacks require attackers to achieve a man-in-the-middle position by employing an ARP spoofing attack against the cni0 bridge device and on the targeted pod.
This attack vector requires the attacker to manipulate packets. It’s possible to drop the NET_RAW capability from an application, which will prevent the attacker from using raw sockets. Another option is to set up a firewall configuration using iptables that doesn’t allow the transfer of DNS responses from a pod that is not a DNS server to another pod.
The second class of attack aimed at CNI plug-ins employs network overlays such as VXLAN to bypass security policies by dropping the NET_RAW capability from the pod, adding a reverse path filtering on the pod’s device and circumventing a network firewall policy. This approach exploits a weakness stemming from the ability to access a UDP port 8472 on the server from a pod. An iptable rule that blocks a pod from sending any packet destined to a cluster eliminates this risk. IT teams should pay close attention to the “list nodes” privileges they have on their cluster. It would be much more difficult for an attacker to send these kinds of packets without knowing the MAC address of the relevant virtual tunnel endpoint (VTEP).
Chako says these attacks can be difficult to detect because the packets moving across these networks typically are encrypted.
Given the relative immaturity of Kubernetes networking, Chako says IT teams should expect to see other exploits involving Kubernetes networking to emerge in the months ahead. Those issues may not slow down Kubernetes adoption but they surely will present IT security teams with new challenges on a platform many of them are just starting to get to know.
