0:01

Stormcast. My name is Johannes

0:03

Ulrich and today I'm recording

0:05

from Stockholm, Germany. We

0:14

got a diary today

0:17

by one of our

0:19

Sands-Edu undergraduate interns, Kelly

0:22

Fiocci-Tapani, did write about

0:24

a honeypot they ran as

0:26

part of the internship and some

0:28

of the attacks they saw. Of

0:30

course, if you run honeypots for

0:33

a while, there is probably not

0:35

a huge surprise here but also

0:37

the speed at which some of

0:39

these highly automated attacks did

0:41

evolve from a simple login

0:44

via a weak username and

0:46

password to essentially a complete

0:49

takeover of the system if

0:51

this would have been a

0:53

real system. Luckily, of course,

0:55

with honeypots, the attacker only

0:57

gets the appearance of being

0:59

successful. Not only did it

1:02

only take 10 seconds

1:04

for this entire attack to

1:06

unfold, there were also several

1:09

hundred attacks a day against

1:11

a simple honeypot running within

1:14

Amazon's cloud in this example.

1:18

And TeamViewer announced that

1:20

they experienced a compromise

1:22

of their internal corporate

1:24

IT environment on

1:27

Wednesday, June 26th. So

1:29

a couple days ago, given

1:31

the widespread use of

1:33

TeamViewer and of course

1:35

the sensitive nature of

1:37

TeamViewer's access to users'

1:39

desktops and systems, does

1:42

make this of course a rather relevant

1:44

event. There is not a lot of

1:46

details known yet from

1:49

TeamViewer. I'll link to their

1:51

statement in the show notes.

1:53

It's very brief. They do

1:55

state that the product environment

1:57

was completely independent of the

1:59

company. compromised corporate

2:01

IT environment but remember

2:03

this just happened and

2:06

there's always a chance that

2:09

more parts of compromise will

2:11

be discovered sooner well later

2:14

in the future. Current recommendation

2:16

is to review your TeamViewer

2:18

logs, make sure that there

2:21

is no unusual activity, try

2:23

to reach out to TeamViewer

2:25

if you do spot any

2:28

unusual activity. At this point,

2:30

I haven't heard from anybody

2:32

who said that they think

2:35

they were or their TeamViewer

2:37

sessions or environment was

2:40

somehow compromised as part of

2:42

this incident. And if you're

2:45

using Fortas File Catalyst workflow

2:47

product, it's urgent that you're

2:50

patching the product. There is

2:52

not only a new SQL

2:55

injection vulnerability but also a

2:57

proof of concept ready to

3:00

go for it thanks to

3:02

Tenable. Forta did

3:04

release a patch earlier this

3:07

week. They also included some

3:09

possible configuration changes you may

3:11

apply that will mitigate the

3:14

vulnerability. However, that involves to

3:16

actually disable some of the

3:18

vulnerable service. Another

3:21

piece of software that needs your

3:23

attention before the weekend is GitLab.

3:25

A GitLab released an

3:27

update fixing a number of

3:29

important vulnerabilities. One of them

3:32

in particular sticks out it does

3:35

allow one user to execute

3:37

the creation pipeline

3:39

as another user. CVS

3:42

value here is 9.6. There is

3:44

not a ton of detail here

3:48

however there is some functionality that

3:51

changed with the update and that

3:53

gives you a hint what may

3:55

be happening here and that's when

3:58

you have a two

4:00

merge requests that are

4:03

being issued simultaneously where you first

4:05

try to merge x into main

4:07

but then you also try to

4:09

merge a different branch y into

4:12

x. So in

4:14

doing so, it's possible that

4:16

whoever is trying to merge

4:18

y into x is able

4:20

to execute a pipeline that

4:22

was sort of triggered by

4:24

the first merge request. So

4:27

in other words, there may be

4:29

enough detail here to allow a

4:32

crafty attacker to come up with

4:34

an exploit rather quickly. There's also

4:36

some changes that were made to

4:39

the authentication via craftql. One

4:43

of the attacks that's often being

4:45

talked about with large language models

4:48

is a prompt injection. What

4:50

a prompt injection really refers

4:53

to is the ability of

4:55

the user to send a

4:57

prompt to the system that

4:59

will override some of the

5:01

built-in security features. JFrog

5:04

published a nice blog post

5:06

about just such a prompt

5:09

injection in vana.ai, which does

5:11

lead to SQL injection. They're

5:13

doing a real good job

5:15

in also taking apart a

5:18

little bit the problem of

5:20

prompt injection. Often, it's

5:22

sort of a little bit more used

5:25

like a prank, for example, where you're

5:27

able to convince a system like chat.

5:29

GPT to tell you how to build

5:32

a Molotov cocktail by basically asking it

5:34

not to tell you how to do it. A

5:37

little bit like how you

5:40

would sort of trick a three-year-old into

5:42

doing something or telling you something they're

5:44

not supposed to tell you. And that's

5:46

about where some of these models are

5:48

at. The tricky part

5:50

here with the SQL injection

5:53

comes to play because vana.ai

5:55

is actually built to create

5:57

SQL queries. This

6:00

of course is always dangerous and

6:02

the trick being played here is

6:04

sort of your classic SQL injection

6:07

trick where you're providing poverty SQL

6:09

statement that will then be inserted

6:11

into the SQL statement just as

6:13

user data. Of course,

6:16

I probably can hear someone cry

6:18

out here talking about prepared

6:20

statements and such. This doesn't

6:22

quite apply here because the

6:25

code is kind of supposed

6:27

to create arbitrary SQL code

6:29

of course within some guardrails.

6:31

The fix here is actually

6:33

not a fix for a

6:35

SQL injection problem but instead

6:37

just limiting permissions in order

6:39

to prevent malicious SQL queries

6:41

from just failing based on

6:44

not having the necessary privileges.

6:47

Well, and this is it

6:49

for today. This is also

6:51

the last podcast until July

6:54

8th. There will be no

6:56

podcast next week due to

6:58

travel, couple of events, 4th

7:01

of July holiday and such. So,

7:03

wouldn't really work out to do

7:05

a podcast next week and that's

7:07

why I'll wait till July 8th

7:10

for the next podcast. Thanks for

7:12

listening. Thanks for liking and commenting

7:15

on the podcast. If you have

7:17

any stories that I missed or

7:19

such, please send me an email

7:21

or comment via the Storm Center's

7:24

comment forum and thanks and talk

7:26

to you again on Monday, July

7:28

8th.