White Russians, Anyone?

Russian alcohol retailer WineLab closes stores after ransomware attack

Episode Transcript

Speaker 1 (00:00):
So I was reading in the news that a ship
carrying Yo Yo's from China sank six times yesterday.

Speaker 2 (00:10):
But I'm bump, Okay, Carl, Now you gotta tell a Joe.

Speaker 3 (00:14):
Okay, Carl telling joke.

Speaker 1 (00:26):
So we have a special guest for security this week.
By the way, I'm Carl. That's Patrick and Dwayne, and
the other guy that you're gonna hear is Cliff Agis
and Cliff. I don't know if you guys knew him
before the Discord server, but he was definitely oh one
that Cliff. I was.

Speaker 3 (00:44):
I was Cliff. I think it was on maybe X
or one of the other platforms were going back and
forth before the discords were Actually it might have been
Cliff that suggested discords. I can't remember who had said
yesterday discord Okay, yeah, yeah.

Speaker 1 (00:57):
Well I saw Cliff in Sweden and Stockholm earlier this
year at dev some Yeah, and.

Speaker 2 (01:01):
He's avoiding me as well he should.

Speaker 4 (01:06):
You got you can find it.

Speaker 1 (01:08):
So you know, if you're a good developer with security focus,
and you know you answer questions and ask questions on Discord,
you too might be able to Oh I don't know, and.

Speaker 3 (01:17):
We might drag you on he might drag you on
kicking and screaming.

Speaker 1 (01:21):
Yeah right, so Cliff obviously listens to the show, so
you know it's the format. We're going to go through
a few stories here. Let's start with critical wing FTP
server vulnerability actively being exploited in the wild.

Speaker 2 (01:37):
Who's surprised that an FTP server is hackable? I mean
it's it's almost every hack the box scenario is, Oh,
and there's an FTP server.

Speaker 1 (01:44):
By the way, FTP is one of the oldest protocols
on the Internet, and it uses a few ports that
usually aren't open, but you know, people open them if
they need to copy files to a website, for example.
Is the probably the biggest use of them.

Speaker 2 (01:58):
You know, what the giveaway is that FTP is unsecure
is that there's a version called secure FTP.

Speaker 1 (02:03):
Yeah, that's right.

Speaker 4 (02:05):
I was going to say to say.

Speaker 1 (02:10):
Yeah, I actually use it.

Speaker 3 (02:11):
Yeah, I've used it in the past, but every time
I see it on a on a like a box
we're trying to break into, it's like huzza. The only
FTP I've ever seen that we can't break into is
the file Zilla And what really kind of ticks me
off is it's files Zila. Yeah, well there's that, but
it's file Zilla beta. It's beta. It's like they're taunting
you to break into it. It's not even real production

(02:33):
and we can't. Like That's why I prefer Gopher. Come on, yeah,
wais or Archie have you? Okay?

Speaker 2 (02:39):
I have set up a Gopher server in the past
as well as an Archie server.

Speaker 1 (02:43):
So you guys want to hear something. How old I am?
I wrote two books for John Wiley and sons on
Internet programming in the nineties, and they were They went
through the protocols and how to write them in visual
basic using sockets, and Gopher was in there and FTP
is in there, So I know exactly what you're talking about. Patrick.

Speaker 2 (03:02):
Those systems output to stone tablets.

Speaker 3 (03:07):
Wow.

Speaker 1 (03:11):
So I use FTP to get files up to and
from Azure. You know, when I have websites and I
don't want to redeploy the whole damn thing. I just
have a couple of data files that change. They use
FTP and he use file Zilla.

Speaker 3 (03:25):
It's great, file Zilla, that's the key.

Speaker 1 (03:28):
Well, I used the file Zilla client.

Speaker 3 (03:30):
The horse of a color okay.

Speaker 1 (03:32):
Color a different horse.

Speaker 3 (03:33):
It's true.

Speaker 2 (03:34):
Okay, So this is an RC remote code execution. FTP
is almost always on the web, so it's probably a
web a web vulnerability.

Speaker 3 (03:42):
I'd say this is pretty severe.

Speaker 4 (03:43):
Yeah, yep, I agree, it's it's also the fact that
it's a null handling of a null, and you kind
of wonder which is older null or at FTP?

Speaker 3 (03:53):
Right, wow?

Speaker 1 (03:54):
Yeah, So what you're saying is you you add a
null to the end of a string. Yeah, right, yep,
and yeah, now sends it into it.

Speaker 2 (04:04):
Where's LUA come in? I mean, I remember LUA is
what you know, wow add ins and things like that.
I didn't know what was using.

Speaker 3 (04:10):
I was gonna say, the last time I programmed in
Lou I think was when we created aw a Wow mod.

Speaker 2 (04:14):
Yeah, we had Dragon, a dkpiece system we did.

Speaker 1 (04:17):
So.

Speaker 3 (04:17):
LUA is a programming language. You know some's World of Warcraft,
by the way. So what happens in the back end
here is this, This particular FTP server actually processes sessions
with LUA code on the back end, like who's connected,
what are they connected to? All that other good stuff.
So as it's displaying and processing those sessions, if you

(04:38):
send in that null byte character, it breaks out of
the lua's expected terminated stripped and then you can do
whatever you want, right, you can run a spoke and
you can run code and that sort of stuff. Man,
And this this is pretty common. We've seen this type
of null and I love the comic Cliff. You're right,
like Noll breaking into things has been around for a

(04:59):
long time. Yea. We generally see it with like PHP
websites where you know, the the URL bar has you know,
and your user name equals or whatever, or you know,
your first name equals whatever, and if you just put
in there slash zero zero, right, it sends a null
character breaking out of the string. And we've seen that
with issues too, So it's not just Lua that has

(05:21):
these issues, but it still surprises me. It makes it
out of QA.

Speaker 1 (05:24):
You know the phrase input is evil. It always comes
back to that, right, Yes, yeah, input is evil. People
don't know how to sanitize, they don't know how to
trim strings, they don't know how to do that kind
of stuff.

Speaker 2 (05:35):
Okay, so, so is that our advice We've we've gotten religion.
We want to get religion about giving more solid advice,
especially to developers sanitizing your strings.

Speaker 1 (05:44):
Yeah.

Speaker 3 (05:45):
Well that's a great question, and you're in put okay, okay,
Cliff being the developer on the call, one of the
developers on the call.

Speaker 1 (05:51):
Yeah, thank you.

Speaker 3 (05:52):
I play one on TV.

Speaker 2 (05:53):
I pretend to be what you used to be a podcast. Hey,
I got check ehbt, I got cursor.

Speaker 3 (06:00):
Yeah you do. Oh my god, he's a live good lord.
H So okay, So how often in development just talking
to other developers and that sort of stuff? I know
you've given lectures on you know, development and that sort
of stuff. Do you see where someone comes up to
you and asks you, like, okay, but what should I
be worried about from a security standpoint? Right? Like for me,
it's they do it all the time because I'm in security, right,

(06:22):
But for like a developer known very well as a
developer in the field, do you get a lot of
developers come up to you and say, Okay, it's cool,
I can add this functionality, but what about you know,
what should I worry about from a from a security
standpoint or now?

Speaker 1 (06:33):
Everything?

Speaker 4 (06:34):
I probably can't on one hand number of times people
have asked me security advice. Yeah, I'm not sure if
they'd look to my code and thought it's not ask Cliff,
because that's really bad. It's it's a case of you know,
developers tend not to stick that way.

Speaker 5 (06:48):
They'll afraid your yourll answer and you'll have the work
to do. But the answer is everything. You should worry
about everything. Everything that comes into your system by way
of a user needs to be the clean, sanitized, trimmed
any not just.

Speaker 4 (07:00):
A user though, I've I've worked on ioch projects that yeah,
you know, the data coming in from the field is
the format, So sanitize everything. Don't trust anything coming in.

Speaker 2 (07:13):
Now, zero trust. There's a reason that that's a framework. Yeah,
I agree, but that's that that's a philosophy. We need
zero trust. But here's the other thing that's interesting about
this article. They say, okay, so all right, so let's
let's all put our developer hats on. How you know, uh,
code is getting processed and that sort of stuff. And
a null comes in and Lewa decides to terminate this
string and maybe you put au you know, luah, you know,

(07:34):
operating system execute piece of code in there, and it
runs something. The next line here says that that particular
this can be used to execute arbitrary system commands. Of course,
because you just do like a you know, an OS
command call in LUA with the privileges of the f
T piece service root or system by default.

Speaker 1 (07:55):
Wow.

Speaker 3 (07:55):
Now, why on in this day and age would you
ever be running piece of software with root? I get
it in like the old Windows works on my PC? Wait?
Is that the classical developer moniker, that's the answer. Yeah,
that's how they got it to work. No, but it's
like I remember in Windows, if you wanted to open

(08:16):
a socket you needed to be an administrator, right, if
you ran a piece of code or whatever. Right, I
get that. But nowadays you can just configure the PC
correctly and then run it as a normal user. Shoot.
So even though this exploit may be bad, you're not
now running a system. Just that's my two cents. From
a developer standpoint, you know, sanitizing code makes sense. But

(08:38):
from a network operation standpoint, whoever installed this should never
be installed as as root or system.

Speaker 4 (08:45):
Here's a question for you, en duaye. Yeah, just put
in my idiot developed cap on. If you install this,
then you're on a shared box and it gives you
root access. That mean you've not got access to all
the other systems on that bar.

Speaker 2 (09:00):
It breaks it breaks the tenant firewall.

Speaker 4 (09:02):
So it's a great way of breaking into things. Isn't
it just a shared box? Yeah, not that it's like,
you know, giving it any advice anyway, But.

Speaker 3 (09:09):
Your neighbors wept handing a career.

Speaker 1 (09:14):
It's criminal.

Speaker 2 (09:16):
How many tenants are run a single server nowadays? I'm
sure it's a huge number.

Speaker 3 (09:20):
There's a there's still a fair bit. You know, they've
been trying to obfuscate it due to side channel attacks.
It used to be you could rent, uh like a
VM in Azure and apply enough stress to that VM
that you could actually read the memory from other vms
running on the same tenant. Wow, And they've now done
away with all of that. It's but yeah, no, I

(09:41):
agree with you.

Speaker 1 (09:42):
So here's just a little side story before we move on.
Richard Cambell and I interviewed Michael Howard, who's on the
Red team at Azure.

Speaker 3 (09:50):
Yep, he wrote secure Code.

Speaker 1 (09:52):
Secure Code, yeah low as many years ago.

Speaker 3 (09:54):
Still probably write secure code.

Speaker 1 (09:56):
I bet the book Secure Code. Yeah.

Speaker 3 (09:58):
Yeah.

Speaker 1 (10:00):
Anyway, so I was telling him about, you know, my
world's colliding here because of the show that we do
and the whole idea of a contagion score. And we'll
get to that in a minute. But one of the
things that came to mind is and he you know,
we're asking him like, what does it take to be
a Red Team hacker? Right, And he's kind of like you, Dwayne,

(10:21):
He's like, just you gotta think evil, you gotta think
from a criminal perspective. And the funny thing is it's
rubbing off on me because the first thing when I
read this story, the first thing that occurred to me is, Wow,
I use Azure FTP to update my Azure thing. So
I wonder if I just like put a null at
the end of my password, if I can get access
to the route. And then I'm thinking, well, Michael Howard

(10:44):
like spends his time trying to hack into all the
systems in Azure and at Microsoft. You gotta think that
they know about this, right, It's.

Speaker 2 (10:54):
A big surface area. They probably do, but it's a
big surface area.

Speaker 3 (10:59):
Yeah. Yeah, that's the biggest problem.

Speaker 2 (11:01):
I don't think they're using the Wing FTP server is
the big thing.

Speaker 3 (11:04):
No, they are not.

Speaker 1 (11:05):
Well, that's probably right. It probably wrote their own.

Speaker 3 (11:07):
But that it brings up a good point because I
talked to a lot of customers where they're like, oh,
I have this one application. Maybe it's a point of
sale system. I have this one application and it's secure,
and people have looked at the code and it's been
pen tested and here's its report and blah blah blah
blah blah, and I'm like, great, that's awesome. So that
means in a lab connected to nothing, configured exactly the
way the vendor wanted it, and used one hundred percent

(11:28):
the way they wanted it, with the same surface of attack,
it's perfect. But when you put it in your environment
and you configured it and you may be using it differently,
and you also have maybe SQL on that box and
I on that box and all sorts of other things
on that same server, you've changed the configuration. Fundamentally it's
unique to you, which means it may now be vulnerable, right,
And Carl and I were talking about this just before

(11:50):
the podcast, where you chain vulnerabilities together. It's rare. You're
taking one vulnerability and just hey, this gives me access
to everything. It's I'm going to exploit this thing in
the access and then prevest to give me access here
in them.

Speaker 2 (12:03):
Laterally, I think AI is going to cause an eventual
explosion in side channel attacks.

Speaker 1 (12:08):
You know, it's funny you should mention AI because there's
something funny about this. My next story, Project zero, which
is the Project zero team at Google, put out a
thing here, a website, blog posts, whatever it is from
nap time to big sleep using large language models to
catch vulnerabilities in real world code.

Speaker 3 (12:29):
And this works both ways.

Speaker 2 (12:30):
That if good guys can find vulnerabilities to patch them,
hackers can find them to exploit them. Yeah, it's not trivial,
but it's not impossible either.

Speaker 4 (12:39):
Business what gethou has been doing, right, we depend upon
and the likes yeah for years now, yep, absolutely, you
know I get the dependerbot emails it's like your code
is vulnerable here, and go from vixicks ql too.

Speaker 1 (12:53):
I think it's called right kid hub ql.

Speaker 3 (12:55):
Yeah, yeah, and I've definitely seen that from GitHub where
it's kind of bot goes through and it says And
what's interesting about that is that's using static analysis of
the code at rest. And you know, it is interesting
how how many people we talked to you are like, well,
you know I would get these alerts from you know,
whatever it might be snick or dependabo or whatever it is.

(13:16):
And static analysis is super important. It's one of those
things that will catch like SQL injection via string concatenation, right,
that sort of stuff, But it will miss certain things
that only happen when the code is in motion. Right,
And that's why you know, we always recommend things like
dynamic analysis as well. Have somebody slam on it.

Speaker 2 (13:36):
It's like inspecting a car while it's running in the
driveway versus down the highway.

Speaker 3 (13:40):
Exactly the big difference. Yep. So I would I wouldn't
you know, be against doing it right, absolutely uses, you know,
usea to look through the normal code patterns and see
what it finds. But you're still I think, and maybe
it's just me trying to advocate for my own job,
but I think you're I think you're still gonna find
like it makes sense to have a developer slide security

(14:00):
engineer looks.

Speaker 1 (14:01):
Absolutely it's running. Yeah, certainly now and most likely in
the future.

Speaker 2 (14:05):
And while I think the ll ms are going to
be good at finding vulnerabilities that are known, eventually they'll
be able to create some unique novel things. But but
I think it's going to be still people coming up
with the more creative stuff.

Speaker 4 (14:18):
For a while, Dwayne versus ai hip Site otherwise were
not of a joke.

Speaker 2 (14:23):
Yeah, well, well we're all out of a job of it.
You know, given a big enough timescale, four hundred years,
two hundred years, we're all out of a job anyways.
But I wouldn't care then, you know, incarnators are right,
you're will.

Speaker 1 (14:36):
Ray car smile and I plan to live forever. So
I don't know about you guys, but it's impressed.

Speaker 2 (14:41):
That's true. I know I haven't died yet, so you
never know, no precedence for me.

Speaker 1 (14:44):
How do you know you haven't died.

Speaker 2 (14:46):
Yeah, I would have remembered.

Speaker 1 (14:48):
That's all right. This is Remember Philosophy this week. It's
a new show.

Speaker 2 (14:53):
So you know, AI it's an area to watch. You know,
it's not a bad idea to have an AI take
a look at the you know you code to see
if you can find vulnerabilities things like that. But but
I do agree people, it doesn't have to be us.
It just having a person think things through. I think
it's another level. There's static, there's a AI, and then

(15:14):
there's people. Because the other thing about AI is it
only can do things that are synthesized from what it's
already seen, right, which is why I think side channel
attacks are going to be a big thing because side
channel attacks is a hard thing to come up with.
You get to I mean, it's another level of weird thinking, right,
which is why they're so cool. But once you have
that example, I think as would be better at.

Speaker 3 (15:35):
It than the average person.

Speaker 1 (15:36):
M interesting.

Speaker 3 (15:38):
Yeah, I still think it's going to be an augmented tool.
I think a good red teamer will use AI, especially
on analyzing large subsets of code. But you're still going
to need somebody who can think outside the box. It's
like the vibe coding.

Speaker 2 (15:50):
You can do a POC with vibe coding right now,
but you can't really get a production, enterprise, big application.
I don't think just with vibe coding.

Speaker 1 (15:59):
So so here's what the article says. Today, we're excited
to share the first real world vulnerability discovered by the
big sleep agent, an exploitable stack buffer underflow in sequel Light,
a widely used open source database engine. We discovered the
vulnerability and reporter to the developers in early October, who
fixed it on the same day. Fortunately, we found this

(16:21):
issue before it appeared in an official release, so sequl
that users were not impacted. I think that's pretty cool.

Speaker 4 (16:27):
That is pretty well not impacted as long as they.

Speaker 2 (16:29):
Updated before it even shipped. Wasn't it? Was it a
pre release version?

Speaker 4 (16:35):
I don't know, that's what I mean. But if that
existed in a previous version, that's a good point. If
you're using on a version a few years old, then
you've still got you need to patch.

Speaker 3 (16:47):
Yeah, you know, it's rare to see a buffer underflow
overflows buffer underflows a little on.

Speaker 1 (16:54):
So it had negative five characters in it.

Speaker 3 (16:57):
Or maybe it's where you ally kate a buffer of
a certain size and you only use less, so it
assumes the rest of the buffers is free. I don't know. Yeah,
it's interesting.

Speaker 1 (17:06):
I don't know what that is. We're gonna have to
ask you.

Speaker 3 (17:08):
Don't run in a buffer overflows much or underflows.

Speaker 1 (17:11):
It's gonna have to ask chat GPT about that to
get the official answer.

Speaker 3 (17:14):
Oh my god. Check? All right?

Speaker 1 (17:16):
Shall we move on to sonicquall?

Speaker 3 (17:17):
Yes?

Speaker 1 (17:18):
All right? Son SMA device is hacked with overstep rootkit
tied to ransomware. Ransomware I've heard of that, and stay
tuned for more fun after the break. The last story
has to do with ransomware. What happened here, guys?

Speaker 3 (17:36):
This one has all sorts of oddities in it. So
we'll we'll try and break it down. But at this
point most of the security researchers are going, hmmm, like
they got exploited, but we're not entirely sure how they
put a shell on a non shellable system.

Speaker 1 (17:53):
What why?

Speaker 3 (17:54):
How is that even possible? Yeah, and then they're like
they may have used any of these five zero days
or end days or whatever.

Speaker 2 (18:01):
Right, so this is giving Titanic vibes, the unsekable ship.

Speaker 3 (18:06):
That's saying exactly the bit.

Speaker 4 (18:07):
The bit that made me giggle was the fact that
the Sonic will s m A, which stands for mobile access.
So the very name of S in s m A
is already broken.

Speaker 2 (18:17):
It's got to change the U m A they on
the access.

Speaker 3 (18:23):
It's just access for everybody. It's just as exactly not
so much s a lot of a wait anyways. So yeah,
so it's this is in essence, this is like, think
of it like a VPN server, right that can do
thousands of concurrence and sessions and allow remote workers to
come in and connect and do the things they're supposed
to do. But the Google's research team discovered the fact

(18:49):
that this vulnerability was in here and they say this
is an unknown zero day remote code execution vulnerability, so
oddly unknown zero day usually means unknown. Like yeah, it's like, hey,
nobody's ever seen this before, this say, quote unquote unknown.

Speaker 2 (19:06):
They don't understand it is the problem, yes.

Speaker 3 (19:09):
And that was the point is like, not only is
it something that's not patched, but we don't know really
what they did. And if you read through here, what's
really kind of cool and I think is awesome with
overstep is it actually has the ability to selectively remove
itself from logs.

Speaker 1 (19:29):
Wow.

Speaker 3 (19:30):
So it leaves a majority of the logs there, but
anything that would have allowed them to track what it's
doing on the system it cleans up in real time.

Speaker 1 (19:38):
Wow.

Speaker 3 (19:39):
And this is why the security researchers are like, we
don't know what happened. This operating system shouldn't even be shellable.
Nobody should be able to run a command on here.
And sure enough they were be able to shell it.
But if you look through here, they talk about actually
having this be a user mode shell, the kernel mode shell,
not running as a service. So it think like application

(20:00):
running on Linux. Yeah, right, so not as persistent, but
easier to run you don't need elevated privileges necessarily. So
there's a lot going on here that I think they're different,
a new.

Speaker 2 (20:11):
Kind of living off the land perhaps interesting. Wow, all right,
so what's the guidance for this?

Speaker 3 (20:19):
Would you?

Speaker 2 (20:19):
I would say, you're using this just shut it off?

Speaker 3 (20:22):
Throw them awa right? No, yeah, because there's out the door.

Speaker 4 (20:25):
It does say that it's the end of life devices
that have been been targeted, So maybe if it's the
end of line, actually throw them.

Speaker 2 (20:34):
Away called doctor Kovorkian place with something new.

Speaker 3 (20:38):
Yeah, I mean, that's honestly cliffs right, Like, these devices
are targeted specifically, I think because of the fact that
they're not going to go patch them, and actually in
this case, I don't even think they know how they
got on these boxes. The risk here, though, is if
you take a look at sort of halfway through this article,
it says Google's team warns that overstep can steal sensitive

(20:59):
files such like such as the persist dot dB database
and certificate file. So that for those of you who
have been using VPNs right old timey VPNs, you used
to use user names and passwords, those were a little
bit hackable, right just by perforcing et cetera. So you
usually have a certificate. You hand a public certificate or
private certificate key out to a user to put the

(21:20):
public on the server whatever it may be. You exchange keys.
So if I can steal those certificates, not only might
I gain access to this particular VPN, but it is
ben has been known to people reuse those certificates right
paying the butt to create them. So I just hold
onto my own SSH private and public key and I
just seed it all over the place when I want

(21:40):
to log into something.

Speaker 2 (21:41):
Credential reuse at the SSH level. Yeah, yeah, exactly. So
we could see this attack ultimately spreading further where they go. Oh,
by the way, I guess what, remember when we told
you about this persist dB stuff. Yeah, they stole thousand
certificates and they were able to break into other places,
maybe bikes.

Speaker 1 (21:57):
All right, so update your advice or turn it off
at least drill and yeah, put a drill through it
and take it to your local staples because they recycle
stuff like this. All right, let's take a break and
when we come back, we got a few more stories
for you, including that one that I was hinting about
white Russians anyone. Hmm, We'll be right back, and we're back.

(22:23):
It's Security this week. I'm Karl. It's Dwayne and Patrick
and Cliff is with us today. Yeah, and it's We're
glad to have him here. Next story is about EPSS.
I don't know what that stands for, but it's a
pretty cool acronym. I think it's ex Exploit Prediction Scoring System.
I just read it. They stole so so what is this?

(22:46):
Is this like the you know, the the contagent score?
What is this?

Speaker 3 (22:51):
Yeah? Absolutely so we had we here at Security this week.
I have been talking for years about how the CVSS
score on a piece of on an exploit, whether it's
you know, one or ten, isn't really great, right. There
could be a wait, you might be running wing FTP.
We just saw that was a ten. But what if

(23:13):
that wing FTP is sitting behind five firewalls and isn't
accessible from the Internet and only is on a v
land with one computer. Is it still a tent?

Speaker 1 (23:22):
You have to be on the network and have admin
access to it.

Speaker 3 (23:25):
Yeah, exactly, so, I asked the panel of U three,
is that still a tent? Should it be considered a ten?

Speaker 1 (23:30):
No?

Speaker 3 (23:30):
I don't think so right right, because it's it's like,
you know, yeah, it's a big deal, but if somebody
gets this far, we're kind of sol anyways, and we've
already architected around this issue, so that that should change.
Then on top of that, are we seeing it being
exploited in the wild if you haven't, if it's just
some security researcher found some FTP software from forty years

(23:53):
ago that you know, oh, by the way, is exploitable
that a nobody might be running anymore, and b we're
not seeing exploited in the while still again should be
a ten.

Speaker 1 (24:01):
Right, ten is the chicken little score.

Speaker 3 (24:04):
It is the chicken little score, right, So here it's
securedy this week we thought, well, we'll come up with
this contagion score. Every time we see a CVSS, we'll
try and some reality on it. Yeah, exactly should you
worry about it? Shouldn't you? Actually? I almost I think
that was kind of the premise of the podcast, was
for us to say, hey, this is you know, the
sky is falling, but really it's not. What's the problem.

(24:26):
How do I know if it affects me? What do
I do if it affects me? That's that's what people
want to know.

Speaker 1 (24:31):
Right, what can I do to future proof myself from
things like this? Actually, yeah, that's another thing.

Speaker 3 (24:36):
Cliff.

Speaker 2 (24:36):
Cliff has access to our to our our slack right
for this channel out.

Speaker 4 (24:42):
He does not, Well, the discord, it's not the slack.

Speaker 3 (24:46):
Yeah, I can.

Speaker 2 (24:46):
I can add in to that because we because we
have a we have a format we throw around where
we we literally have these exploits and we include stuff
like severity, the CBSS score. The little wing one, for example,
is a ten when it was disclosed, what kind of
type it is, whether it's in the wild, what CV is,
and this The questions we pose on that is how

(25:07):
do you know if you're affected, what to do if
you're affected, and the potential consequences. And we think that's
really the information that people want.

Speaker 1 (25:15):
Yeah, well, you know, Cliff doesn't have access to slack,
but just give them a minute. I'll figure it out.

Speaker 3 (25:21):
He's a smart guy. Yes.

Speaker 4 (25:24):
But to add to that as well, Patria, I want
you to come and tell me if your AI that
you know this, I'm using this in my software bill
of materials, and I want you to come and say, well,
here's my software bill of materials. Yeah, these are all
the dependences have in my code and my projects down
to that guy in Nebraska that's got left pad and

(25:45):
then actually tell me that this CVE has been found.
It applies to you, affects this package and to you,
and come and tell me because I'm too busy doing stuff.

Speaker 2 (25:56):
We have a couple of interns coming to join us
from a very good school. I'm told, oh my god
this summer. They're actually showing up Sunday and they're going
to dig into the Miter s bomb framework for us.
Because we've dug in it before. We want to see
where it is. But the problem is, you got to
get the s bomb implemented, and so we need that.
I think we need that to happen in a worse way.
I think that's the next phase we're going to see

(26:18):
in the industry over the next couple of years, is
people implementing.

Speaker 1 (26:21):
So how we really talked about EPSS?

Speaker 3 (26:23):
What not? Yet?

Speaker 2 (26:24):
No?

Speaker 3 (26:24):
Sorry, well, I mean a little bit a kind of
So what is it?

Speaker 4 (26:27):
So?

Speaker 3 (26:28):
EPSS is a way of evaluating and exploit two more dimensions.
So actually does this matter? Has it been exploited? Who
does it affect? So if we take a look at
halfway down they have sort of a model interpretation, yes,
where you can see, like, okay, version one, you start
to see information about vendors, whether you know what was

(26:50):
the vendor. It might be Adobe, and was there a
poc et cetera. And then in version two they dig
in a little bit a little bit more right, you know,
references of it is it remote or not, et cetera.
And then in version three they say, okay, well, is
there is there code executions or not et cetera. So
they go through and start really kind of assessing how

(27:13):
important is this, and if you scroll down a little
bit further, then they go into seeing, okay, well let's
take a look at cve by cd right or CBSS.
So we see CBSS version three and how they assessed
you know, criticality, coverage, efficiency, and.

Speaker 1 (27:29):
Threat whether it was exploited. Yeah.

Speaker 3 (27:31):
Yeah, And you can see these ven diagrams down here
showing that really EPSS version three really does a great
job of targeting, you know, the actual exploited vulnerability and
how risky it is.

Speaker 1 (27:45):
So it looks like they not only add metadata, but
then they do some analysis on that metadata and give
you some well I don't know if if EPSS includes
like the graphs that you're talking about here, But is
it easy to to do those calculations and extra appollate
real world threats from it?

Speaker 3 (28:03):
So I think it is. And if you on the
paragraph below they say, like, listen, if we had a
standard a thousand vulnerabilities come out this month, that's a lot, right,
systems administrators that have to go through and be patching
probably all month to patch every single one of the thousand.
Wouldn't it be great if you knew which ones were
the most important?

Speaker 1 (28:21):
Right?

Speaker 3 (28:21):
You knew which ones were really A being exploited in
the wild, B had POC code that was being used,
and so on and so forth.

Speaker 1 (28:28):
Yeah, and then if you run that against your s bomb,
then you can then it can really tell you, hey,
you got to watch out for this one right here.

Speaker 2 (28:35):
Well, I think that that's the next evolution, Carly is
actually running this against where you've implemented them. So for example,
if I had wing s FTP, but it's only available
behind the VPN, it's mitigated to a large extent, I
still don't want it, but it's low on the priority list.
And so that's the personalization of this, which I think

(28:56):
would be the next level, but we probably won't see
that for a few years.

Speaker 1 (28:59):
That's really cool, Yeah, really cool. All right, So is
is EPs S the end all be all or is
there another any other things that do that kind of analysis.

Speaker 2 (29:11):
Well, whether it's being exploited in the wild.

Speaker 3 (29:13):
Yeah, and that's that's a good, good lead into the
next Thank you. What the story was?

Speaker 1 (29:22):
All right? So this is America's Cyber Defense Agency ses
CISA reducing the significant risk of known exploited vulnerabilities.

Speaker 3 (29:33):
Well that cliffs like, I don't know if I believe
in this.

Speaker 1 (29:35):
That's a good thing, I guess, right, yeah.

Speaker 3 (29:39):
Yeah, absolutely, So this is this is a sort of
a twist on the same sort of style of narrowing
down what's important. Right, So they have the CBSS, they
have the exploit database. You can always look through and
see all these exploits. But some of those exploits might
have been created by researchers, right, Okay, some of those
exploits may be on old software that's that not even

(30:00):
being used by anyone anymore. So we see this all
the time, and sadly I see this with security researchers too.
They'll take a piece of software from like two thousand
and two, find an exploit on it and then submit
you know, a CVE for it, and you're like why
and A. It's because they can now get their name
associated with the CVE, right, and it's kind of like

(30:22):
a badge of honor. I got three hundred CVS my name, right,
I'm a brilliant security researcher. When in reality, you might
be looking at code that's you know, forty years old,
not forty but close to forty.

Speaker 4 (30:33):
But there's lots of companies out there that are still
using that old code though, can be Yeah, that's the
companies you know. If you look at like, you know,
the hack on the NHS in the UK, Yeah, you're
still using like kind of Windows XP machines. It's like,
well there you go, Yeah, be supported, but you're still
being used.

Speaker 3 (30:50):
Well and it's funny you say that. We see it
a lot in healthcare. Yeah, so case in point right,
they may have machines that only are supported does XP
Windows seven, God forbid, Windows Millennium Edition. But whatever, we
see it all.

Speaker 1 (31:07):
I was trying to forget that one.

Speaker 3 (31:08):
With STUF I like to call it. So we see it,
we see it all the time. Where it's really where
we're like, Okay, what you really need to do is
go behind the computer and see the network cable and
just cut it and then it's sure, it's fine, just
leave it alone, like nobody can get to it. Yeah,
shut off the screen. You just pull the keyboard out too,
that would be that would be ideal. But Cliff, you're

(31:29):
absolutely right, like we do. We do run into that.
I like to say, like every nobody's using IAS classic
anymore or ASP classic anymore? Right, who uses ASP Classical?
Like ASP dot that's been out since nineteen ninety nine,
late ninety nine, we were reading through the frame.

Speaker 2 (31:46):
Yeah, there are voters in multiple elections who were born
after it was.

Speaker 3 (31:51):
It was absolutely after ASP went out, and we still
see it today where I'm like, like, it's funny because
when I'm on like talking to my t EM, I'll
be like, it's almost like I'm the docent of a
of a museum and I'm like, well, kids, let me
tell you how sessions worked back in the nineteen hundreds,
back in the before time exactly. Look at this. This

(32:15):
is a great example of managing sessions through VB script
And they're like, oh.

Speaker 4 (32:21):
Yeah, okay, but A lot of it comes back to like,
certainly in the medical industry, that's where it costs so
much to get something like approved and signed off. Or
it's a big, big company and there's so many like
you know, globally stations plugged in to update all of them,
to go to a new version of software is an
absolute nightmare.

Speaker 3 (32:42):
Yeah, and who wants to do it right? Because for them,
they're like, it works, right, So if it works, and
why are we ripping it out? And it's and it's
for the and it's the world. We could be exploited right.

Speaker 2 (32:51):
Or or we're scheduled to be next Thursday.

Speaker 4 (32:54):
But it's also when you go when you go to
the you know, the management of the finance people and
you speak to and so we want to spend X
millions over here because like we're not upgrade it. It's
like what do we get for that? It will just
carry on working.

Speaker 3 (33:05):
Yeah, exactly right, you get what you get to it.

Speaker 4 (33:08):
We need to do that.

Speaker 3 (33:08):
It's working now.

Speaker 1 (33:10):
So sis's answer is a known exploited vulnerability catalog.

Speaker 3 (33:15):
For a while, this has actually you can subscribe. I
subscribe to this this feed. It's so I get riveting. No,
it is a riveting feed woo. But if some see
something in the wild, so that the criteria for this
is a an exploit has to have an assigned cve
I D, right, So there has to be a discovered
exploit that they have some details on. It can't just

(33:37):
be like, oh, I understanding this weird thing in the
wild like the Fordinet. Oh my god, we don't know
what it is, but yeah, it's a thing like sonic wall. Yeah,
I'm alluding to our nextor so it has to have
an assigned cve I D. That's number one. Number two
it has to be actively exploited in the wild today, right,
So it's not like some researcher somewhere in his basement

(33:57):
decided to find this and I was found in That's important,
don't get me wrong. But if it's not actively exploited,
then really the risk is lower. But number three is
an interesting one, and I don't know if I agree
with it or not, so I wanted to talk to
you three about it. It has to have clear remediation guidance.

Speaker 1 (34:17):
In other words, for.

Speaker 3 (34:18):
It to get into the k EV.

Speaker 2 (34:20):
Yeah, that sounds a little bit artificial.

Speaker 1 (34:22):
Patch or take it offline or whatever.

Speaker 2 (34:26):
Otherwise, Well, otherwise, what are they're afraid? They're just going
to spread panic? Remember it's a government agency, it's run
by a government agency.

Speaker 3 (34:32):
I don't know. I mean, what if it but but
here's the here's the deal. What if it doesn't have
clear remediation guidance? Does that mean nobody gets to know
about this?

Speaker 4 (34:41):
Exactly?

Speaker 3 (34:43):
Yeah, right, exactly right? What is clear? Like, uh, don't
let people touch the server? Is that clear?

Speaker 1 (34:47):
Well? You know what that is? Remediation Unplugging it and
removing it sometimes is necessary because there's no patch.

Speaker 3 (34:54):
But that's always available. You're absolutely right, Patrick, but it's
always available. So when do you stop? So why do you, like,
do you wait for a patch so there's a clear
I'm with doing, I'm with I agree with that quibble.
I don't know. It seems weird to me.

Speaker 1 (35:09):
I'd put it in there anyway. And if the only
remediation is to turn it off or not use it
until a patch comes out, then Sylvie.

Speaker 4 (35:15):
It to me, it reads like the whole idea or
premise of the databases to say, these are known vulnerabilities,
So if we know about it, share the fact that
it's actually being experted. So people then go and unplugged
the network cave on, say, until there's a patch, and
we're going to lead this unplugged and we'll come back
and plug it in later or put some other kind
of guard around it.

Speaker 3 (35:34):
Right exactly.

Speaker 2 (35:35):
There are two criteria seem to be pretty like everything
is either patchable or you should remove it from the
network because it can't be it's end of life or
cannot be otherwise updated. So I don't know what fits
into that category.

Speaker 1 (35:51):
So something that is in the cave ve is it
wouldn't would it if there was no remediation? Could you
still find it in ep s S.

Speaker 6 (36:00):
You'd be able to find it out. It's still be
a it's still be a CVE. You'd see, you'd find
it as CVE, but you wouldn't know how important it is.
There's thousands and thousands and thousands of them. You would
find it in the in the EPSS, but it would
be hard to differentiate between it and one that actually
has a recommend it. So it's almost like there's a
piece in between needed like, hey, we're seeing this, we
know it's real. Hey we're seeing it in the wild,

(36:23):
and here's a here's an X here's a patch or
a way of mitigating, and it's it's that in between
I worry about. If you wait for the patch, then
you're exploitable until it happens.

Speaker 2 (36:34):
They should have a status, they should have a new
status for it, like it's on the KVE provisionally or
it's on the k EV yeah, pending final instructions or
something like that, final criteria.

Speaker 3 (36:45):
Yeah.

Speaker 1 (36:46):
Or why wouldn't you just use EPSS? Does EPSS have
any thing in it?

Speaker 2 (36:50):
Because then you're saying a system is going to cook
to another system and they're separate, they're separate implementations.

Speaker 1 (36:56):
Oh no, I'm saying, why wouldn't you just look at
the instead of.

Speaker 3 (37:01):
Well you should, yeah. I think there's maybe two reasons
for that. One, defining a standard for all of this
is hard, yeah, right, so everybody doesn't want to follow
the same standard. Never mind just in the United States, right, Worldwide,
following one standard is almost impossible. I'm surprised we have
a you know, we have the ability to pass along

(37:24):
information about exploits. And number two, the EPSS, if I
remember correctly, was designed by sec Secop Solutions. There you go,
sec Op Solutions, Secop Solutions actually sells a patchet management software,
so it's entirely and they were like, we're the first
ones to use this. Well yeah, okay, but yeah, so

(37:46):
they might be trying to push this as a standard.

Speaker 1 (37:48):
I see.

Speaker 3 (37:49):
I haven't dug into it too too much because it's,
like I said, it doesn't also meet that remediation need
that I saw.

Speaker 2 (37:55):
And I think it's stupid to say, well, you should
go over here. They should just add a provisional status
to k EV to say which you're waiting for more information.
I don't think it should be a criteria.

Speaker 4 (38:05):
Yep, okay, or setps. We're just listening to secuity this
week and find a problem. Your your score was a
good idea and they've monetized it the punch.

Speaker 2 (38:17):
Yeah we can buy a candy bar once a mindsetters.

Speaker 1 (38:22):
Now you're thinking like Dwyane. All right, all right, Fortinet,
our old friend Fortinet, as we have said before, used
to just do one thing right. They used to just
have firewalls, and they got into all these other YEA
products and.

Speaker 2 (38:39):
They're doing such a bang up job on all the
other stuff.

Speaker 1 (38:43):
Yeah, bang up, indeed, bang up like an old car. Yeah,
new Fortinet forty web hacks likely linked to public RCEE exploits.
Our friend Bill Tullis wrote.

Speaker 3 (38:55):
This E is part of the name.

Speaker 2 (38:57):
It's not a serious product, and it's a public r
C exploit.

Speaker 3 (39:05):
Okay, so okay, So here's what I want to say
about this. If we read through, I used to like Fordinet.
We used we used to get firewalls Forternet. Firewalls were great,
lockdown ports, they were okay at reporting. They weren't fantastic.
We've we've moved on since.

Speaker 2 (39:21):
But well, and they had that purple thing you could take.

Speaker 3 (39:25):
No, that's firewall. Oh yeah, true, Yeah, no, they don't
mind that wall.

Speaker 2 (39:30):
We're already two firewalls beyond that. We changed firewalls like
other people change underwear.

Speaker 3 (39:37):
Once twice a week.

Speaker 2 (39:39):
Yeah no, at least at least once a year.

Speaker 3 (39:46):
So what's interesting about this is this is their FORIDA
web instances. And if we scroll down in here, it's
CV twenty five twenty five seven, which is a preauthenticated
remote code execution via sequel injection.

Speaker 1 (40:04):
VIAS sequel injection.

Speaker 3 (40:06):
Our old friend, that's a new thing I've never heard of.
Between two to explain this injection.

Speaker 1 (40:15):
To me in the two thousand and two or whatever
it was.

Speaker 3 (40:17):
Oh my god, does it have to do with COVID?
It does? It does? Uh yeah, so an improper neutralization.
I love how they call it that. Not a sanitization
of special elements used in SEQL commands makes it vulnerable.
In the forty web may allow unauthenticated attackers to execute

(40:38):
unauthorized SEQL code or commands via the crafted HTP and
HDV requests. If I remember correctly, Oh yeah, here you go.
The exploit involved performing SQL injection via crafted authorization headers
in the request sent to API fabric device status. So

(41:00):
this is an interesting point. I love the fact that
developers sometimes they get really kind of fixated on the
data that a user can type in a field, right, Like, oh,
usernan password on a field. The only thing obviously the
people can type in is the username and the password. Right.
But all of us on the call here, developers, we
know that's not the only data that goes back to

(41:21):
the server. That's right, Right, there's authorization headers, there's potentially
cookie information, there's potentially.

Speaker 1 (41:28):
Hidden fields, hidden fields.

Speaker 3 (41:30):
Of data that gets sent. Right, There's tons of data
that get sent to what language are they viewing the page?
In there's tons of data they get sent back to
the server. What kind of browser are you using? Exactly? Well, yeah,
browser agents. There used to be an injection in browser agents.
There was a SQL server database that would keep track
of all of the different agents. So we could go
back and say, how many people are using IE? Should

(41:51):
we code our websites for IE? And you would just
put injections in the agent field and gain access to
the back end database.

Speaker 2 (41:58):
I remember that.

Speaker 3 (41:59):
Yeah, so you know, I always wonder, and I throw
this here again out to the developer panel. Here, how
often do you think during QA or during testing of applications.
Let's assume all applications get QAD are they testing other fields?
Testing application? Testing content type?

Speaker 2 (42:20):
No?

Speaker 1 (42:20):
I think we consider that plumbing code. Yeah, really that
we shouldn't have to do. It's only going to get
found it.

Speaker 4 (42:26):
Works on my machine, ship it.

Speaker 2 (42:27):
Yeah, it's probably not even going to get found in
a static analysis. It's going to get found from a
red team engagement from a pentent. Yeah, that's the only
way you're going to find that. Or you train your
developers to think about it. Can you I think you can,
It's just difficult. Well, I always wonder how paralyzing it
must be to be me. No, I mean to like

(42:48):
to develop an application where your sole goal is features
at a timeline dictated by a customer or your boss,
and security is not one of them. Right, So then
you think there's off, Well, this could be exploited. Let
me fix that. This could be exploited. Let me fix that, right.

Speaker 3 (43:03):
And you get to this point where you're like, at
the end of the month, I got one solid feature out.
Your boss is like, that's fantastic, Like chat GPT did
twenty more through out right. I don't know, I don't know.

Speaker 4 (43:13):
Yeah, it's a true, true argument. I mean I worked
with Clout recently and they wanted to have a load
of data sent to the clouds, and it's like it's
just not worth it for what they needed the data,
for what they wanted to date for it just wasn't
worth it. I was like, you're just you know, open
up Pandora's box and it's going to cost you a
fortune because of all the security you need to put

(43:33):
around it. So we eventually got to the point where
we won't connect it to the cloud. So you just
don't connect to winning.

Speaker 3 (43:41):
You haven't got that problem, right, the right thing to
do is not do the thing. Yeah. Yeah, and they.

Speaker 4 (43:47):
Lost a little bit of data which would have been
great for them to have, but it's a it wasn't
a neat to have, it was a nice to have.

Speaker 1 (43:55):
Yeah.

Speaker 4 (43:55):
I started because I listened to this podcast. I've started
thinking that way do we really.

Speaker 3 (43:59):
Need I'm sorry, yeah, broken, but it's.

Speaker 4 (44:04):
Like, do you really need that data? You know, use
the name of passwords, and then you ask ten other things.
It's like do I really need to know like you
know where you live or you know mother's made a
name and stuff like that. You know, I don't need
that anymore.

Speaker 2 (44:16):
Well, and you you are responsible for deleting it if
somebody requests it and it becomes a liability.

Speaker 3 (44:22):
Yeah, yeah, GDPR and ye all that.

Speaker 2 (44:24):
Yeah, it's a tax. Security is a tax that executives
do not want to pay and developers don't have time
to pay. But if you don't pay taxes, you get screwed.
And if you don't do security, you're going to get
screwed too.

Speaker 1 (44:38):
Well, the good news is on this one a patch
is available. Yes, so patch was patch issued July eighth.

Speaker 2 (44:45):
Well, and what was the cost of what was the
cost of doing it wrong the first time and then
having to patch, yeah, versus just doing it right the
first time.

Speaker 3 (44:53):
Yeah. I find a lot of companies hide behind the
no software is secure, Oh, we'll patch it. It's like, okay, well,
if you're taking the time upfront to actually design it
in a secure way, we might not run into these issues.

Speaker 4 (45:05):
But that's just me injection, I mean.

Speaker 3 (45:09):
Yeah, right, it's only been around for like since sequel existed,
since sibase existed.

Speaker 4 (45:14):
Maybe that's we turned off sequel.

Speaker 3 (45:16):
That's it, But I like it. We're shutting off databases
in the defense.

Speaker 2 (45:19):
We never heard about sequel injection till about nineteen ninety nine,
that is, it's true. So they've only had twenty six
years to get ready for this.

Speaker 3 (45:28):
Yeah. I think it was announced by Rainforest Puppy in
like nineteen eighty something. Yeah. Whatever, It's been around a
long time, all right.

Speaker 1 (45:36):
So who wants a white Russian.

Speaker 2 (45:39):
Apparently not this hacking group.

Speaker 4 (45:40):
I'm a work in the morning, so not me.

Speaker 1 (45:43):
Yea, not you, hey man, I got a beverage here,
So this is in bleeping computer. Russian alcohol retailer wine
Lab closes stores after ransomware attack. I don't know how
to feel about that. I mean, I don't want anybody
to have a ransomware attack, but there's been so many

(46:03):
coming out of Russia lately that it kind of feels like.

Speaker 4 (46:06):
Ye, did you say, I'm surprised they're selling wine in Russia?

Speaker 3 (46:12):
Though, right?

Speaker 4 (46:13):
I mean, he buys you.

Speaker 3 (46:14):
It's just a well and yeah, I'm betting. Let's see
they have blah blah blah blah.

Speaker 1 (46:21):
The largest alcohol company in Russia.

Speaker 3 (46:23):
Brandy's, RUMs Bitters, gin, tequila, vermouth wine, and vodka. But
vodka Russia's largest liquor store.

Speaker 1 (46:33):
Yeah, Russia's largest retail So.

Speaker 3 (46:37):
Here's where I don't know A lot of there are
we can all agree, and this is an international panel. Now,
of the four of us, we can all agree Russia
is probably the biggest ransomware purveyor, you know, in.

Speaker 1 (46:54):
So maybe they were thirsty, you know, maybe they just
were like, hey, ransomware this liquor store. We can not
only be paid off in money, but they'll give us
their inventory and we'll just be stoned forever. Yeah.

Speaker 3 (47:09):
Maybe maybe I don't know, but my understanding has always
been and maybe it's wrong that ransomware groups operating within
the Russian borders are free to do so as long
as they don't attack Russian companies.

Speaker 2 (47:23):
Right, that's my understanding as well.

Speaker 3 (47:26):
Yeah, and if they do, then they get a visit
from the BRAVA.

Speaker 2 (47:29):
I wonder if this is a sign that the wheels
are coming off?

Speaker 1 (47:32):
What do you mean?

Speaker 3 (47:32):
Well, that's a good question coming.

Speaker 4 (47:33):
Off it says. It does say further down that most
ransomware groups resonated from Russia a told not to target
within Russia and the ES region wherever. They're starting to
ignore that and target low level, right.

Speaker 2 (47:49):
Which means that maybe the state's authority is starting to
erode maybe, and it's easy to get to the I mean,
if you think about it, these Russian companies have been
artificially protected, they might not be as ready for ransom
and they might be easier targets.

Speaker 1 (48:02):
Yeah.

Speaker 2 (48:03):
I mean, I'm not ruling out the Ukrainians either, But.

Speaker 3 (48:07):
That's a weird hit though. If you're a Ukrainian you're like, haha,
no more alcohol.

Speaker 2 (48:11):
Like Actually, if you look further down, it says that
Ukrainian activists attacked a key alcohol distribution system in Russia
back in twenty twenty two.

Speaker 3 (48:20):
No, I know, but I'm just saying, like if you
were Ukraine and you're like you're Zelenski and you got
like the board out and you're moving the little guys
on the board, and you're like okay, and this guy
right here with a little keyboard, he's gonna go. He's
gonna go right on top of this liquor store in Russia.

Speaker 2 (48:35):
If you're an alcoholic activist, if you're an alcoholic hacker,
that might be exactly what you think is the most
important thing to take down to che right, fair enough,
fair enough, But.

Speaker 4 (48:46):
They take out pizza and coke. That's sort of developers upset,
isn't it.

Speaker 3 (48:50):
I mean, code would stock. I don't think you can
write code without pizza and coke?

Speaker 4 (48:54):
I mean what the security people you know.

Speaker 2 (48:57):
And we're not we're not defining which coke you mean,
just gonna let.

Speaker 3 (49:00):
That sit there?

Speaker 4 (49:01):
Could be the other one get be good.

Speaker 3 (49:03):
Yeah, it doesn't matter.

Speaker 1 (49:05):
So the stores have been closed since July fourteenth. But
does it say that they're down for the counter. Did
they catch the brand somewhere people? What happened after it?

Speaker 3 (49:15):
No?

Speaker 2 (49:16):
No?

Speaker 3 (49:16):
My guess is it sounds like it was pretty pervasive
throughout all of their different locations, so it's going to
take them a while to unravel this and bring it
back online. And like Patrick had said, if they've been
artificially protected, if they've had if they've had mob protection
for a while, right, and nobody will attack you. We're good,
you're at you're a Russian company. And then they unfortunately
probably haven't been patched and haven't been looking at you know,

(49:39):
backing things up and putting them off site and making
sure they can't be encrypted, so they maybe actually be
in more trouble than you'd think.

Speaker 2 (49:46):
So yeah, it's it's it's tough to think of it
this way, and I don't condone it, but the tax
from Russia and from these hacking groups against the West
have hardened the West. We're actually you know, there's not
much low hanging food. This sales some out there, and
I'm still worried about a lot of companies, but there's
a lot of companies that are really rock solid. We
have customers who we do pent tests for them a

(50:08):
year after year, and they follow our advice and they
get stronger and harder and harder. Yeah, and it's going
to take a nation state, you know, with some really
serious firepower to get to these some of these customers,
and that's what we want.

Speaker 1 (50:18):
Yeah, well that sounds like the end of our show today.
So we want to thank Cliff Agis for hanging out
with us today.

Speaker 4 (50:25):
Cliff, thank you, thank you, thanks for having me along.
It's been good fun. Yeah, it will come together.

Speaker 1 (50:30):
I'm sure. Well yeah, and we'll see out on Discord
and we'll talk to you next time on Security this week.

Speaker 2 (50:35):
Bye bye bye