0:00

Hello and welcome to the Wednesday, June

0:02

26th, 2024 edition of the Sands and

0:04

Storms and Stormcast. My

0:08

name is Johannes Ulrich and today

0:10

I'm recording from Stockholm, Germany. I've

0:14

got an interesting paper that I

0:16

saw today from researchers at the

0:18

Graz University of Technology.

0:21

The problem they're trying to

0:24

solve is trying to figure

0:26

out a website that a

0:28

user is visiting without having

0:30

direct access to the network

0:33

path or any of

0:35

the endpoints. So essentially

0:37

they're trying to remotely sniff the

0:39

network traffic. The solution they

0:42

came up with is kind of quite

0:44

ingenious and wonder how well

0:46

it works in real life. But

0:49

what they noticed is that the

0:51

latency of network traffic does

0:54

change as the user visits

0:56

a website and the exact change

0:58

depends on the website that's being

1:01

visited. The simple sort of

1:03

demonstration of the effect of that they're

1:05

showing, which is something that you may

1:07

be able to also sort of repeat

1:10

yourself is if you just

1:12

keep pinging a particular IP

1:14

address, like for example, the famous 8888

1:17

Google DNS server, and then

1:19

you visit google.com and then

1:22

later amazon.com. Well you see

1:24

some characteristic changes in latency

1:27

as expressed in the ping

1:29

roundtrip time. Just before

1:31

recording this I was playing with this myself and I have

1:33

to say that I didn't really

1:36

get very conclusive results here, but I'm

1:38

using a VPN here back from Germany

1:40

back to the US so that

1:43

adds a lot of additional noise, which

1:46

of course is one of the defensive

1:48

techniques. If your net

1:50

connectivity is pretty noisy in the

1:52

first place, meaning there's a lot

1:54

of variation in latency, then

1:57

of course, this becomes more difficult

1:59

to exploit. And

2:01

of course ICMP as ping may

2:03

not be the best way to

2:05

measure latency in this case and

2:08

that's really sort of where the

2:10

paper then dives into. They basically

2:12

assume that the victim has simultaneously

2:14

a TCP connection open

2:16

to the attacker for example downloading

2:18

a web page, a large file

2:21

from the attacker system and then

2:23

TCP can be used to measure

2:26

latency which actually may be more

2:28

accurate and also more continuous than

2:30

what you usually get with sort

2:32

of one ping a second. They

2:35

do derive quite decent capabilities

2:37

here and probabilities to figure

2:39

out what particular website a

2:41

victim is visiting in particular

2:43

if you are limiting the

2:45

number of websites that you

2:47

are considering. Overall I think

2:49

it's an interesting trick. It's

2:51

sort of one of those

2:53

side channel attacks. I don't

2:55

really see it as a

2:57

realistic big threat but certainly

3:00

recommend you take a look at

3:02

a paper because it'll probably teach

3:04

you something about latency buffering and

3:06

TCP some of these issues that

3:08

are often a little bit neglected.

3:11

And Elastic Security Labs has a nice

3:14

write-up with details regarding a

3:16

new technique that they have observed

3:19

being used in the wild. The trick

3:22

here is that the attacker

3:24

is using management safe console

3:26

files or MSC files in

3:28

order to gain full code

3:30

execution. The way this works

3:32

is while these files are

3:34

being executed by the Microsoft

3:37

Management Console and the

3:39

way they get the victim to

3:41

actually execute the files is an

3:43

older cross-site scripting vulnerability. While the

3:46

vulnerability appears to be old it

3:48

was apparently reported in 2018 to Microsoft Adobe.

3:50

It has not been fixed yet and that of

3:52

course makes

3:58

an attractive target for And

4:01

Hymalver so far doesn't detect

4:03

this particular malicious MSC file.

4:07

Certainly one of those extensions that you

4:09

probably should block from entering your network.

4:13

And as part of the plug elastic

4:15

security labs also talks about some detection

4:17

techniques, but they're

4:20

of course more specific to

4:22

their detection products. And

4:25

if you have a new

4:27

security update from Wyse for

4:29

its security cameras, probably not

4:32

that secure. Actually, out of

4:35

the four vulnerabilities being addressed here,

4:37

the one that I consider kind

4:39

of the most severe one is

4:42

the one actually with one of the lower CVS

4:44

scores 7.5. It's

4:47

an cloud infrastructure improper

4:49

authentication vulnerability. And

4:51

essentially here the device's MAC

4:54

address is being used as

4:56

a credential. Of course,

4:58

MAC addresses are somewhat predictable

5:00

in particular if you are

5:03

limited down to a particular

5:05

manufacturer. So that's

5:08

something that I think is certainly exploitable. There's

5:10

also a Wi-Fi SSID OS

5:12

command injection vulnerability. But that

5:14

only happens during the initial

5:16

setup of the device as

5:18

you're reading a QR code.

5:21

So I don't really see

5:23

that that severe, but

5:25

again, someone very typical because

5:28

you probably then pass these parameters

5:30

to some command line

5:32

script in order to set the

5:34

SSID. The most

5:36

severe vulnerability here is a

5:39

Wi-Fi driver heap based buffer

5:41

overflow, and that's in real

5:43

tech Wi-Fi drivers. So that

5:46

particular vulnerability may already be known

5:48

even though the advisory doesn't speak

5:51

to that. Well, that's

5:53

it for today. And then just a

5:55

quick announcement about next week. Next

5:57

week again is a little bit of travel week for myself.