0:00

This is the Week in Review for the week ending Friday, June

0:02

28, 2024. I'm

0:06

Howard Solomon, contributing reporter

0:08

on Cybersecurity for Tech

0:10

newsday.com. In a

0:13

few minutes, Terry Cutler of Montreal's

0:15

Sciology Labs will be here to

0:17

discuss three of the week's more

0:19

interesting developments. But

0:21

first, a look at other

0:24

headlines from the past seven days. The

0:27

discovery that a domain supporting

0:30

the polyfill.js open source library

0:32

has been injecting malware after

0:34

it was bought by a

0:36

Chinese company started

0:39

a rush by website administrators this

0:41

week to delete the code. Polyfill

0:45

allows websites to support older

0:47

browsers. Quick

0:50

action by cybersecurity companies since

0:52

news of this vulnerability was

0:54

released by researchers at Sansec

0:56

has helped blunt the danger.

0:59

For example, Google began blocking

1:01

Google Ads for e-commerce sites

1:04

that link to CDN.polyfill.io,

1:09

and CloudFlare implemented real-time rewrites

1:12

of that domain to their

1:14

own safe version. In

1:17

addition, an American domain registrar put

1:19

the bad domain on hold. Still,

1:22

web developers and admins

1:24

using this code should

1:27

remove any polyfill.io references

1:29

in their code. Since

1:32

the beginning of the year, Google has disrupted over

1:34

10,000 instances of YouTube video

1:37

and editorials on Blogger that

1:40

come from a China-based group that

1:43

brings the total number of blocked

1:45

instances of ProChina spam to over

1:47

175,000 since last year. The

1:52

campaign, which Google calls Dragon

1:55

Bridge, creates content

1:57

reacting to breaking news, Most

2:00

of the content doesn't have a political

2:02

message, but some portray U.S.

2:04

government, society and democracy in a

2:07

negative light. Google

2:09

takes action against unauthentic activity,

2:12

such as videos pretending to be

2:14

news shows. The

2:17

Attorney General of Arkansas is

2:19

suing the e-commerce website called

2:21

TEMU for allegedly violating the

2:23

state's Deceptive Trades Practices Act

2:26

and its privacy law. The

2:29

suit alleges TEMU is spyware,

2:31

designed to gain unrestricted access

2:33

to shoppers' mobile phones. TEMU,

2:37

the Attorney General alleges, is

2:39

led by a cadre of

2:41

former Chinese Communist Party officials.

2:46

According to The Verge, TEMU's parent

2:48

company was based in China, but

2:50

last year moved headquarters to Ireland.

2:54

And finally, the P2P infect

2:57

malware now has a crypto

2:59

miner, a rootkit and

3:02

ransomware payloads. That's

3:04

according to researchers at Cato Security.

3:07

This worm spreads by exploiting

3:09

the replication features in Redis,

3:12

an in-memory data store that can be

3:14

used either as a database, cache

3:16

or a message broker. Infection

3:19

adds the computer to a

3:21

botnet for distributing the R-SAGIN

3:24

ransomware. Redis administrators

3:26

should make sure Redis servers

3:28

are patched and protected

3:30

from compromise. Joining

3:34

me now is Terry Cutler. Hi

3:36

there. How's it going, Howard? Very

3:38

well, thanks. And with yourself? Any better than I

3:40

couldn't handle it. Okay,

3:44

let's start with how Progress Software

3:46

handled the discovery of a new

3:48

vulnerability in its Move It! file

3:50

transfer software. Listeners may

3:53

recall that last year a

3:55

vulnerability in Move It! was

3:57

exploited mercilessly by the Klopp

3:59

ransomware gang. and others to

4:01

steal data on over 90 million

4:03

people from over 2,700 companies. Data

4:08

thieves have indeed found file

4:10

transfer applications are excellent

4:12

sources of personal data. Their

4:14

servers hold large amounts of

4:16

compressed data for transfer. So

4:19

in the past five years, they've been

4:21

targeted, particularly by CLOP.

4:25

Applications that have been compromised

4:27

include Excellion, SolarWinds

4:29

Serv-U managed file transfer,

4:32

Fortraz, Go Anywhere MFT, Citrix FileShare,

4:37

and IBM FastBacks. Last

4:40

year, as I said, Progress Software

4:42

was badly burned by the

4:44

zero-day hole in Move-It. But

4:48

according to researchers at Watchtower, this

4:51

latest vulnerability was

4:53

found by the company and in response

4:56

it began quietly notifying customers

4:58

so they could patch before

5:00

publicly releasing word of the

5:02

whole. That's good

5:04

news, isn't it Terry? Absolutely, and

5:06

I believe it's really the right approach as well.

5:10

Quietly notifying your customers about vulnerabilities

5:12

before making it public allows your organizations

5:14

to patch their flaws without potentially

5:16

alerting the attackers. So software

5:19

reduces the risk of exploitation and strengthens

5:21

the security of the systems that are

5:23

involved in this patch. And

5:25

I think by addressing these issues promptly, companies

5:28

can prevent these breaches and protect

5:30

themselves and especially their sensitive data,

5:32

which is critical to maintaining the trust with customers

5:35

and especially the stakeholders. So I think this

5:37

proactive stance is essential in today's Cyber Street

5:39

landscape. The

5:41

only thing is this wasn't a zero-day

5:44

that the crooks found first, so

5:46

it seems that progress software had

5:48

the luxury of alerting

5:50

customers. And I think

5:53

this is really fantastic news because it means

5:55

that the developers probably received proper cybersecurity training

5:57

in order to test these flaws before releasing

5:59

the updates. Especially

12:00

when we go and coach developers on how to

12:02

code with security in mind, all these practices get

12:04

put into place. So it's very important that the

12:06

developers get trained to look out for these types

12:08

of flaws. So

12:11

why aren't API errors caught before

12:13

the code goes into production? Well,

12:16

I think there's a couple of things

12:18

here. Obviously the sheer complexity of all

12:21

these things, right? These APIs are usually

12:23

involved in multiple interactions and dependencies. So

12:25

it makes thorough testing really challenging. And

12:27

of course, the developers are under constant

12:30

stress to deploy these softwares as quickly as

12:32

possible. So there's a lot of time

12:34

constraints or limited resources. And

12:37

sometimes there's a comprehensive gap to

12:39

how security testing has to be conducted. So

12:42

that's why the training of

12:44

software developers are so key here. Because

12:47

these guys are forced to really

12:49

ship out product as quickly as possible because they want to

12:51

be first to market. And it doesn't

12:53

give them enough time to do a thorough testing. And of

12:55

course, there's going to be mistakes that are good overlooked. And

12:59

there's maybe inadequate security practices

13:01

because not all teams prioritize

13:03

these risks at the same

13:05

level. So it's very important

13:07

that they have the proper vulnerability management testing in

13:09

place. Is

13:12

there a difference between API coding

13:14

errors and other application coding errors?

13:18

There's a bit of a difference. So I mean,

13:20

APIs are often publicly accessible, making them the prime

13:22

target for attackers. Whereas the internal

13:24

application errors might not be as easily

13:26

exploitable. So when you look

13:28

at the integration with APIs, these

13:30

things interact with various external systems

13:33

and services, leading to more complex

13:35

and potentially vulnerable interactions compared to

13:37

internal application logic. So

13:40

these APIs often handle sensitive data

13:42

exchanges. So errors can lead to

13:44

significant data breaches like we're seeing right now. And

13:48

there's also another challenge where you

13:50

have authentication and authorization capabilities, which

13:53

are often involved in critical issues. So here's an

13:55

example. I had an issue where my website

13:57

a couple of years ago. ago

14:00

was breached, the terrykalor.com

14:02

site. And basically

14:05

what happened here was I had some

14:07

inactive plugins that had API capability enabled,

14:10

but they were never in use, but they

14:12

were still active in the backend. And

14:15

making a long story short, attackers

14:17

were able to breach the site and

14:20

I guess they affected the

14:22

core modules, which started delivering

14:24

malicious code to any visitor that was coming.

14:26

So then every visitor would receive a pop-up

14:28

saying, hey, this site is malicious. Google

14:31

has flagged it as malicious and wants to,

14:33

you need to go away or select,

14:35

I agree anyway to bypass it. So

14:39

it can happen to anybody in these old APIs. We

14:41

need to ensure that everything is secure. One

14:47

problem is allegedly the code

14:49

was fixed on one access

14:51

control, but not another. We don't

14:54

know if the IT team at

14:56

Optus didn't see the

14:58

target domain or just assumed it

15:00

wasn't a problem because it wasn't

15:02

supposed to be active. Yeah.

15:05

And I think the bottom line is

15:07

it's essential to understand your attack surfaces

15:09

and identify what's vulnerable. So when you

15:12

have a comprehensive protection in place against

15:14

vulnerabilities, this allows you to have that

15:16

proactive approach, especially with patch management and

15:19

continuous monitoring that'll be across all

15:21

of your systems. So you need to really understand what's

15:23

out there. And

15:25

the other problem is that there

15:28

were two domains, two entry

15:30

points, like one on each

15:32

domain. Was this necessary?

15:36

We don't know how their systems are configured, but a

15:38

lot of times these redundancies get

15:40

added, but it adds also

15:42

an unnecessary complexity, which obviously increases the risk

15:44

of oversight like we're seeing right now. And

15:47

maybe each domain required separate management and

15:50

security checks and a lapse

15:52

could lead to that vulnerability. So

15:54

simplifying the architecture will obviously reduce

15:57

the unnecessary entry point. But