0:00

Hello Welcome to the Tuesday May

0:02

Seventh. Two Thousand Twenty Four edition

0:04

of this sides of it stands

0:07

on Ice Storm Cast My name

0:09

is your Highness Henri and Ram

0:11

Recording from San Francisco, California. Today

0:14

me got a two different

0:17

Vpn a related A Wall

0:19

abilities. The first one effects

0:21

multiple Vpn implementations and relies

0:23

on the Hcp options to

0:25

configure a rowdy devote. My

0:28

Billie was documented by researchers

0:30

from Levithan Security Group. For

0:32

example, as I record this

0:34

podcast, I'm connected to a

0:37

hotel borrowers network. To connect

0:39

to the network I need

0:41

to accept at Yale C

0:43

P Lease. This lease

0:46

typically includes at least a

0:48

default gateway in Ip address

0:50

and possibly Dns servers. The

0:52

Vpn is only labeled after

0:54

the laptop is connected to

0:56

the local network. After all,

0:59

it has to reach the

1:01

Vpn server. A decent Vpn

1:03

will usually overwrite the Dns

1:05

servers provided by the Hcp.

1:07

So that's not the problem here, and

1:10

then add a new router bill, send

1:12

all traffic. That's not local

1:14

to the Vpn interface,

1:16

However, in D C

1:18

P. Has an option to

1:20

configure. Specific or routes This

1:23

option option number One hundred

1:25

Twenty One is implemented on

1:27

many current operating systems, I

1:29

believe. Android was an exception

1:32

and has been around. For about

1:34

twenty years, Linux has a

1:36

feature called network name spaces

1:38

that can be used to

1:40

overwrite. These are routing rules,

1:43

so Olympics can be configured

1:45

to actually prevent some of

1:47

the issues. But please, what's

1:49

happening is that the Dlc

1:51

P Server will advertise a

1:53

more specific route using option

1:56

Hundred and Twenty One. Typically

1:58

if there are conflicting. routes

2:00

to a particular destination, the

2:02

more specific one is being

2:04

used. And that's how an

2:06

attacker who has control over

2:08

the local DHCP server could

2:10

trick you to leak some

2:12

traffic outside of the VPN.

2:16

Windows, Mac OS, the

2:19

workarounds are less straightforward here. You

2:22

may be able to ignore option 121 and

2:25

that's probably the easiest fix in

2:27

particular for something like a public

2:29

wifi and such. I don't think

2:31

any of them relies on this

2:33

option to actually make

2:35

the network work. Another

2:38

option is to isolate your system

2:40

from the untrusted network. So for

2:42

example, you're using some wireless access

2:45

point or maybe you're running your

2:47

actual system that's connecting to the

2:49

VPN in a virtual machine. That

2:52

way the system that is actually

2:55

the VPN endpoint will

2:58

not be connected directly to the

3:00

untrusted network but there will be

3:02

this buffer. Your DHCP list is

3:04

coming from your own DHCP

3:06

server, from your own access

3:08

point. The disadvantage of

3:10

this option of course, is that

3:12

it does add yet another layer

3:14

of NAT typically and such so

3:17

that may have some performance

3:19

impact. FireGuard, openVPN,

3:22

doesn't really matter what

3:25

exact VPN you're using as

3:27

long as routing rules are being

3:29

used to direct traffic through the

3:31

VPN, you may be

3:34

vulnerable. The

3:36

next VPN issue is

3:38

less severe. It's a

3:40

specific implementation here, the

3:43

MalvatVPN service. There's also a

3:45

somewhat common issue with

3:48

VPN services. If you

3:50

are switching from one server to

3:52

another, maybe for performance

3:54

reasons or such, there

3:56

is this little gap where the

3:58

VPN is not established. and

4:00

it's tricky not to leak

4:02

any data during that time.

4:06

Now, Mulvat has a specific feature

4:08

that they call a kill switch.

4:10

So the idea of that feature

4:12

is that no traffic will be

4:14

sent if you're not connected to

4:17

the VPN. Many other

4:19

implementations sort of have similar

4:21

features, but it's notoriously tricky

4:23

to implement this. This

4:26

issue particular shows up on

4:28

Android. If you're not

4:31

using the Android DNS

4:33

APIs, and yes,

4:35

many browsers, and that's of course,

4:38

what most people are caring about,

4:40

are using the standard socket implementation,

4:42

the get adder info API. And

4:45

if you're using that get adder info

4:48

API, then your DNS

4:50

queries may be leaked during

4:52

that transition period. And

4:55

the Cisco TALUS research team

4:58

has made public details about

5:00

a vulnerability in TinyProxy. TinyProxy

5:02

is an HTTP and HPS

5:04

proxy, and well, as the

5:06

name implies, it distinguish

5:09

itself with its small footprint.

5:11

The vulnerability is a use

5:13

after free vulnerability in the

5:16

connection header. Exploitation of

5:18

the vulnerability will lead to

5:20

arbitrary code execution. Sadly, there

5:23

is no patch available. Cisco

5:26

has notified the TinyProxy

5:28

team in December, just

5:32

before the holidays, but still they gave

5:34

them until now to actually fix this.

5:37

And well, a fix has not

5:39

yet been released. The

5:41

blog post by Cisco does

5:43

also include a proof of

5:45

concept exploit. And

5:48

if you happen to be at our day this week, see

5:51

Jason and me at our learning

5:53

lab today on Tuesday at 1

5:55

p.m. This

5:58

hands-on lab will focus on

6:00

API security. It's two hours

6:02

where we sort of go

6:04

through various exercises and of

6:06

course tomorrow on Wednesday afternoon

6:08

I'll again be part of

6:10

the SANS most dangerous threat

6:12

panel. So I hope to

6:15

see you if you want any stickers.

6:17

I usually carry them with me and

6:20

that's it for today. Talk

6:22

to you again tomorrow. Bye.