Breaking down a high-severity vulnerability in Kubernetes.

Dave Bittner: Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner. And this is our weekly conversation with researchers and analysts, tracking down to threats and vulnerabilities, solving some of the hard problems, and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

Tomer Peled: YAML files are Kubernetes way of doing everything from configuring staff to creating pods to everything else. While it's parses some parameters in the SAML file, there may -- there may be some parameters who are unsanitized and may lead to command injection opportunities and to command execution from the Kubernetes point of -- both from the Kubernetes service on the node or on the pod or on the cluster itself.

Dave Bittner: That's Tomer Peled, a Security & Vulnerability Researcher at Akamai. The research we're discussing today is titled, What a Cluster, Local Volumes Vulnerability in Kubernetes.

Tomer Peled: A few months back, we put up a blog about another CV, which led to a system RC over every Windows node on the cluster. On the tail end of that research, we found out another CMD command execution that could lead to an command injection. And this research is the culmination of all of this research that we've done since the last TV. Sorry.

Dave Bittner: Yeah. Well, let's dig into it here. But before we do, though, can you give us a little bit of the background. For folks who might not be all that familiar with Kubernetes, what do they need to know going into today's explanation of your research?

Tomer Peled: So Kubernetes is a container orchestration framework. It's being used by a lot of developers. And today we are going to talk about command injection in its parsing mechanism. So, yeah. So YAML files are Kubernetes way of doing everything from configuring staff to creating pods to everything else. While it's parses some parameters in the SAML file, there may -- there may be some parameters who are unsanitized and may lead to command injection opportunities and to command execution from Kubernetes service on the node or on the pod or on the cluster itself.

Dave Bittner: When we're talking about sanitization here, what exactly do we mean?

Tomer Peled: Sanitization in a broad -- in a broad sense is when an application tries to find out if there is anything malicious going on while parsing a command. In this sense, the same in Kubernetes sanitation means that every parameter in a YAML file is going to be checked to see if anything malicious is going into the cluster, while creating a pod, while creating the configuration, while creating the secret. So every time some -- one of these operations is being executed, it needs to be sanitized. We found out that it's not actually the case. And, in some cases, it will lead to an RC, which is a remote code execution over windows and nodes on the cluster.

Dave Bittner: Hmm. Well, digging into some of the specifics of the research here, you start out talking about Kubernetes volumes and point out that it's important for people to understand what we're talking about there. Can you explain that for us.

Tomer Peled: Yeah. Sure. So Kubernetes volumes are the way that Kubernetes facilitates the sharing of data between a pod and another computer, another node itself, another host, or from the host to the pod. So, for example, you can take a git repository and the pod itself. And the one -- a git volume will actually link between the repository and the pod.

Dave Bittner: Let's dig into the vulnerability itself here. What's -- what's going on?

Tomer Peled: Okay. So, in this vulnerability, a parameter inside the local volume feature, which is one of the volumes that you can create, that you can use, local volumes, if we can just talk a little bit about what local volumes are, local volumes are a way to share a drive, not folder or git repository, just a drive between the host and the pod itself. So if you want to share your D drive or Z drive or any other drive, you would use local volumes. So this vulnerability occurs when the Kubelet service on a Windows node tries to symlink between -- between the drive and the pod. It will actually try to execute a command. And we can, as an attacker, use it to inject -- instead of a drive letter, we can inject anything we want. And it will be executed on the -- on the pod or on the node.

Dave Bittner: Oh, wow. That's interesting. So, what's going on in your estimation that leads to this functionality? I mean, is this -- is this purely an error, that it shouldn't be looking at this as code?

Tomer Peled: Oh, sure. So Kubernetes itself actually is -- has the problem. It's not Windows. It will try to run a CMD command. The CMD command will try to symlink between a drive and a pod location, the pod location, it will take from itself in the curation process. And the drive letter is something that you can customize as a user. So, actually, it will happen from -- as an attacker, we will be able to do it from a parameter standpoint. And what happens is that Kubernetes will not check for anything while creating this -- this volume. So you can enter anything you want in the drive letter or in the -- or in the path parameter. And it will just take it into the CMD. And what you can do with that is that, while CMD is running, it can concatenate between -- between several commands. When you do an end end command, it will actually try to run this command before trying to do the actual command itself, the actual seeming.

Dave Bittner: So what is to be done here? How can folks protect themselves against this?

Tomer Peled: Okay. So there are a few ways to mitigate this vulnerability. One of them is to -- of course, the main one is to patch your cluster to a version higher than 1. 28 1.4. Another way to do it is to do this -- to try and mitigate or block this kind of vulnerability is by using an OPA role, which OPA is an open policy agent. And another way is to basically use RBAC or R-B-A-C, role-based access control. And, with RBAC, you will be able to determine which user can do which actions and will be able to more granularly -- granularly control what it -- what it will be able to do and what you can see. So you want to be able to do a locker volume attachment or symlink. On the OPA side, you'll be will be able to see what's going on, what's going on inside the classroom, what's been created. So we'll be able to block it from that end. But majorly patching to a higher version is going to be your main course of action.

Dave Bittner: One of the things you point out in the conclusion in your research here is you say this is a great example of why the shared responsibility model is crucial in security. Can you explain that for us.

Tomer Peled: Sure. So security screening administrator need to be -- needs to be alert for everything that's going on in the cluster or in Kubernetes itself, and they can take outside precautions to help avoid a serious security impact on their organizations.

Dave Bittner: Our thanks to Tomer Peled from Akamai for joining us. The research is titled, What a Cluster, Local Volumes Vulnerability in Kubernetes. We'll have a link in the show notes. The CyberWire research Saturday Podcast is a production of N2K Networks, proudly produced in Maryland out of the startup studios of DataTribe where they're co-building the next generation of cybersecurity teams and technologies. This episode was produced by Liz Irvin and senior producer Jennifer Eiben. Our mixer is Eliot Peltzman. Our executive editor is Peter Kilpe, and I'm Dave Bittner. Thanks for listening.