0:02

You're listening to the CyberWire Network, powered

0:04

by N2K. Hey

0:09

there! Did you know Kroger always

0:11

gives you savings and rewards on top of

0:14

our lower than low prices? And

0:16

when you download the Kroger app, you'll enjoy

0:18

over $500 in savings every week with digital

0:21

coupons. And don't forget FuelPoints to help you

0:23

save up to $1 per gallon at the

0:25

pump. Want to save even more?

0:27

With a Boost membership, you'll get double FuelPoints

0:29

and free delivery! So shop and save

0:32

big at Kroger today! Kroger, fresh

0:34

for everyone! Savings may vary by

0:36

state. Restrictions apply. Seasight for details.

0:45

Hello everyone and welcome to the

0:48

CyberWire's Research Saturday. I'm Dave Bittner

0:50

and this is our weekly conversation

0:53

with researchers and analysts tracking down

0:55

the threats and vulnerabilities, solving some

0:57

of the hard problems and protecting

1:00

ourselves in a rapidly evolving cyberspace.

1:03

Thanks for joining us. YAML

1:10

files are a communist

1:13

way of doing everything

1:15

from configuring stuff to

1:17

creating pods to everything else. While

1:20

it surpasses some parameters in the

1:22

YAML file, there may be some

1:24

parameters who are unsanitized

1:27

and may lead to command

1:29

injection opportunities and to command

1:31

execution from the

1:33

Kubernetes point of, from the Kubernetes

1:35

service on the node or on

1:37

the pod or on the cluster

1:39

itself. That's

1:49

Tomer Paled, a security and

1:51

vulnerability researcher at Akamai. The

1:54

research we're discussing today is

1:56

titled What a Cluster, Local

1:58

Volumes Vulnerability in Kubernetes. A

2:03

few months ago, we put up a blog

2:05

about another CV, which led

2:07

to a system RC over every

2:09

Windows node on the cluster. On

2:12

the tail end of that research, we found

2:14

out another CMD command execution that could lead

2:16

to a command injection. And

2:19

this research is the culmination of all of

2:21

this research that we've done since

2:25

the last CV. Sorry. Yeah.

2:28

Well, let's dig into it here. Before we do, though,

2:30

can you give us a little bit of the background

2:32

for folks who might not be

2:35

all that familiar with Kubernetes? What

2:37

do they need to know going into

2:39

today's explanation of your research? So

2:42

Kubernetes is a container orchestration

2:45

framework. It's

2:48

being used by a lot of developers. And

2:51

today, we are

2:53

going to talk about command injection

2:55

and its parsing mechanism.

2:59

So yeah, so YAML files are Kubernetes'

3:02

way of doing everything from

3:05

configuring stuff to creating

3:07

pods to everything else. While

3:10

it's parsing some parameters in this YAML

3:12

file, there may be some

3:14

parameters who are unsanitized

3:17

and may lead to command injection

3:19

opportunities and to command

3:21

execution from Kubernetes service

3:23

on the node or on the

3:25

pod or on the cluster. When

3:29

we're talking about sanitization here,

3:31

what exactly do we mean? Sanitization,

3:35

in a broad sense,

3:37

is when our application tries

3:39

to find out if there is anything

3:43

malicious going on while parsing

3:45

a command. In

3:49

Kubernetes, sanitization means that every

3:51

parameter in a YAML file is going

3:54

to be checked to see if anything

3:56

malicious is going into the cluster while

3:58

creating a pod, while creating a configuration

4:01

while creating secrets. So

4:04

every time one of

4:06

these operations is being executed, it needs to be

4:08

sanitized. We found out that it's

4:10

not actually the case, and in some cases

4:12

it will lead to an RC, which

4:15

is a remote code execution over Windows

4:19

nodes on the cluster. Well,

4:22

digging into some of the specifics of the

4:24

research here, you start

4:26

out talking about Kubernetes volumes and point

4:28

out that it's important for people to

4:30

understand what we're talking about there. Can

4:33

you explain that for us? Yeah, sure.

4:35

So Kubernetes volumes are the way that

4:37

Kubernetes facilitates the share of data between

4:40

a pod and

4:42

another computer,

4:44

another node itself, or another

4:47

host, or from the host to the

4:49

pod. So for example,

4:51

you can take a Git repository

4:54

and the pod itself, and

4:56

a Git volume will actually link

4:59

between the repository and the pod.

5:02

Let's dig into the vulnerability itself here.

5:05

What's going on? Okay. So in

5:07

this vulnerability, a parameter inside

5:09

the local volume feature, which

5:11

is one of the volumes that you can

5:14

create, that you can use. Local

5:17

volumes, if we can just talk a little

5:19

bit about what local volumes are, local volumes

5:21

are a way to share a

5:23

drive, not

5:26

a folder, or a Git

5:28

repository, just a drive between

5:31

the host and the pod itself. So if

5:33

you want to share your D drive or

5:36

Z drive or any other

5:38

drive, you would use local volumes. So

5:41

this vulnerability occurs

5:44

when the Kubernetes service on a Windows

5:46

node tries to see

5:48

link between the drive

5:50

and the pod. It will

5:52

actually try to execute a command

5:54

and we can as an

5:57

attacker use it to inject. instead

6:00

of a drive letter, we

6:02

can inject anything we want and it

6:04

will be executed on the pod or

6:06

on the node. Oh,

6:09

wow. That's interesting. So

6:13

what's going on in your

6:15

estimation that leads to this

6:17

functionality? I mean, is

6:19

this purely an error that it shouldn't

6:21

be looking at this as code? Oh,

6:25

sure. So Kubernetes itself actually

6:28

has the problem in it, not Windows. It

6:31

will try to run a cmd

6:33

command. The cmd command

6:35

will try to see a link between a drive

6:37

and a pod location. The

6:39

pod location it will take from itself

6:42

in the creation process and the drive

6:45

letter is something that you can customize as a

6:47

user. So actually, it

6:50

will happen from, as an attacker, we

6:53

will be able to do it from a

6:55

parameter standpoint. And what happens is

6:57

that Kubernetes will not check

7:00

for anything while creating this

7:02

volume. So

7:04

you can enter anything you want in the

7:07

drive letter or in the

7:09

path parameter and it will

7:11

just take it into the cmd. And

7:15

what you can do with that is

7:17

that while the cmd is running, it

7:19

can concatenate between

7:21

several commands. When

7:23

you do an end-to-end command, it will

7:25

actually try to run this

7:27

command before trying to

7:30

do the actual command itself, the

7:32

actual streaming. So

7:43

what is to be done here? How can

7:45

folks protect themselves against this? Okay,

7:48

so there are a few ways

7:50

to mitigate this vulnerability. One

7:52

of them is to, of

7:55

course, the main one is to patch

7:57

your cluster to a version higher than...

8:02

1.28.4. Another way to do this, to

8:04

try and mitigate or block this kind of

8:07

vulnerability, is by using

8:09

an OPA rule, which OPA

8:11

is Open Policy Agents. And

8:14

another way is to

8:17

use RBAC, or RBAC,

8:19

World-Based Access Control. And

8:23

with RBAC, you will be able

8:25

to determine which user can do

8:27

which actions, and you will be

8:29

able to more

8:32

granularly control

8:35

what you will be able to do and what you can

8:37

see. So you want to be

8:39

able to do a local volume attachment

8:41

or SimLink. On

8:44

the OPA side, you will be able to

8:46

see what's going on, what's going inside the

8:48

cluster and what's being created. So we'll

8:50

be able to block it from that end. But

8:52

majorly, patching to a

8:55

higher version is going to be your main

8:57

course of action. One

8:59

of the things you point out in

9:01

the conclusion in your research here is,

9:03

you say this is a great example

9:05

of why the shared responsibility model is

9:08

crucial in security. Can you explain that

9:10

for us? Sure.

9:12

So security administrator

9:14

needs to be alert

9:17

for everything that's going on

9:20

in the cluster or in Kubernetes itself. And

9:23

they can take outside precautions

9:25

to help avoid serious security

9:28

impact on their organizations. Our

9:41

thanks to Tomer Paled from Akamai

9:44

for joining us. The research is

9:46

titled, What a Cluster, Local Volumes

9:48

Vulnerability in Kubernetes. We'll have a

9:50

link in the show notes. Thank

9:58

you. Hey

10:01

everybody, I want to take a few minutes here

10:03

and talk about our sponsor, Splunk. You

10:06

know, you need to keep operations

10:08

humming around the clock, but potential

10:10

disruptions are everywhere. Splunk

10:12

helps you predict problems and find

10:14

and fix issues fast, so you

10:16

can reduce risk and ditch downtime.

10:19

The world's largest enterprises rely

10:21

on Splunk's unified security and

10:23

observability platform to become more

10:25

efficient, resilient, and innovative. With

10:28

Splunk, you can react quickly, evolve

10:30

faster, and be ready for anything.

10:33

Stay ahead of disruptions. Learn

10:35

more at splunk.com/resilience.

10:50

The Cyberwire Research Saturday podcast is

10:52

a production of N2K Networks, proudly

10:54

produced in Maryland out of the

10:56

startup studios of Data Tribe, where

10:59

they're co-building the next generation of

11:01

cybersecurity teams and technologies. This

11:03

episode was produced by Liz Ervin

11:06

and senior producer Jennifer Iben. Our

11:08

mixer is Elliot Peltzman, our executive editor

11:10

is Peter Kilpey, and I'm Dave Bittner.

11:13

Thanks for listening.