Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Hey, guys, I read a study that showed people with
high IQs tend to be lazy or something like that.
I don't know. I didn't read the whole thing.
Speaker 2 (00:11):
I found it fascinating.
Speaker 1 (00:15):
Wa Hey, guess what. It's security this week. I'm Carl Franklin.
That's Patrick and Dwayne, and we're here for your horrification
and edutainment. Is that good?
Speaker 3 (00:35):
I think that's accurate.
Speaker 1 (00:38):
Let's start with horrification. New Linux U discs flaw, let's
attackers get root on major Linux distros. Who wants this one?
Speaker 2 (00:50):
Yeah, I'll take this one. This one's interesting that we've
seen these types of applications. So you disc gives you
the ability to see discs on Linux, right, I can
mount different discs that are local there that sort of stuff.
Speaker 3 (01:04):
Yeah, and it's default on pretty much every distro.
Speaker 2 (01:06):
It's been default on every distro. Gosh, I don't know.
If I were to take a guess, maybe since the seventies.
Maybe it's a more recent thing, but it's it's a
long time, call it a long time. Ever since I've
been using Linux, there's there's always been a U disc
in there where you can.
Speaker 1 (01:23):
And these are local privilege escalation vulnerabilities that they just
found and it's been there since the seventies. Come on
Linux people.
Speaker 2 (01:33):
Yeah, that's that's the crazy stuff here, is like we
we keep finding these, uh you know, these exploits in
common applications and tools that are sitting on every Linux distro.
And we saw it with sud to edit, which was
you know, that gives you the ability to edit files,
you know, in a sort of an elevated way, and
(01:54):
there was a way to exploit it where you could
then garner you know, root level privileges to a box
that had sitting around. I think that exploit was actually
twenty years old. So yeah, it's it's amazing that now
digging through some of these, we also see sometimes and
it's not the case with this one, but sometimes we
see that these were found a long time ago and
they come back, right, they get patched, and then in
(02:17):
you know, later distros or forks of the distros and
that sort of stuff they do unpatched. Right, Yeah, exactly.
Speaker 1 (02:23):
Somebody says, hey, this, this would be a good feature.
Why do we get rid of it. Let's put it
back in there.
Speaker 3 (02:27):
Well, because the code's not marked well enough to say
this is this code is here for this reason. We've
actually seen also bugs that are introduced by the compilers.
So a compiler change can introduce a bug.
Speaker 1 (02:39):
So my question is is this just for on prem distros.
Speaker 3 (02:44):
Or you have to be a local user?
Speaker 1 (02:46):
Okay, So if you have something in AWS or as
you're right in the cloud running on Linux, do you
have to be that worried about it?
Speaker 2 (02:55):
Yeah, so you do. Yes, absolutely. I would say anybody
who has a Linux district that's really doing anything, whether
it's in the cloud or whatnot, should absolutely worry about it. And
here's why this coupled with another exploit, right, Like it's
not always when we look at exploits, we don't think
like how damaging is this one single exploit? We think, okay, well,
(03:18):
assuming somebody gets to the box, assuming I'm running a
web server on there, and somebody's going to find an
exploit on it, or assuming I'm running you know, with
the CUPS service, and then there's an exploit on it.
Now what what could they do? Oh? Well, they're running
as a normal user. But then if you have this
particular exploit, now they're not they're running his root. So
that's it's pretty classic. I mean the other thing is
(03:39):
gaining access to systems sometimes isn't so hard. Social engineering, phishing,
that sort of stuff. You might gain access as a
low level user. And with this now at this point
you can you can move yourself up to a root
level user. So yeah, absolutely, I'd say this is this
is something to be worried about. And no matter who
you are or you know what type of.
Speaker 3 (03:56):
There's lots of web things that run under you know,
local accounts. I mean, everything you do has to run
as some account and its local account. So if I
have an application that's exposed to the web, I can
I now have an in as a local user. Maybe
it's an unprivileged user, but this is what privileged escalation
is all about. And when we combine these things, think
(04:18):
think of a house that only has windows on the
second floor and some of them are exploitable. You still
got to get to the second floor.
Speaker 1 (04:25):
Right And in this case, like if you have a
web server that's running in Linux on Azure, that should
be completely locked down except for what FTP maybe for
updating it.
Speaker 2 (04:36):
Ye ssh maybe SSH.
Speaker 3 (04:40):
Port eighty so so not so locked down? Well, okay,
is it running WordPress and does it have a control
put panel, and you know there's all these other convenience
convenience features.
Speaker 1 (04:51):
I hear, I hear you. So there's there's other vulnerabilities
that allow you to get system access. And once you
have that, then these you disk things are no match.
Speaker 2 (05:02):
Yeah, And if you and if you take a look
at sort of how this is broken down, and there
is a POC out there. There's a POC for twenty
twenty five sixty eighteen the PAM miss misconfiguration in how
that works. And then there's also another POC for the
twenty twenty five sixty nineteen which is the U disc
lib block dev root command execution. So the way the
(05:25):
way this works is a two step process. Right on
open seu's Leap fifteen and SEUs Linux Enterprise. The PAM
policy incorrectly assigns allow active permissions to a user who
shouldn't have it right, So that's like a sort of
a default thing. This lets a local So the allow
active is a policy kit action that lets the user
(05:48):
control services if they're considered active. What does active mean?
Active means just logged in locally. So if you're logged
in locally, you get the ability to control services, which
we're already getting into a weird right, So this lets
the user get authorization to call sensitive pole Kit actions
without a password. So okay, so now we're in a
(06:10):
weird place, right. Users by default habit privilege that they
may not necessarily need if they're logged in locally. Now
that coupled with twenty twenty five sixty nineteen the U
disc lib block dev issue. Once the user has allowed
active right, which we've already established in open sous leap
(06:31):
fifteen X, they do they can call the u disc
ctl part of the u disc thirty two to perform
a device level action including formatting and modifying discs. Okay,
that sounds more than terrible. Could be you know, data
wipe and all that other good stuff Behind the scenes,
you dis two calls the lib block dev to execute
commands with root privileges, trusting Polekit to manage who should
(06:54):
have this. And this is the sort of the crux
of the problem. Now you're going down to the dpath
where users have control roll over running this tool that
then runs his root and you can see where that's going.
Speaker 1 (07:04):
So there's a quote here from qualis True Senior manager
Say Dabasi. He said, given the ubiquity of you disks
and the simplicity of the exploit. Organizations must treat this
as and now in all bold critical universal risk a
critical universal risk and deploy patches without delay. So what
(07:27):
are the patches though.
Speaker 3 (07:29):
Yeah, so it's not as bad as this. Well, there
are patches, but there's it's basically every single Unix system
has to have a patch.
Speaker 2 (07:39):
Yeah, you would have to patch to patch PAM, and
you'd have to patch the live block dev u disc
pretty much everywhere.
Speaker 1 (07:46):
So, I mean, I guess the upside of having something
in the cloud is that you know, as long as
it's not on a VM that you have to maintain,
it's going to be patched.
Speaker 2 (07:56):
Right.
Speaker 3 (07:56):
If you're doing platform as a service, yes, But if
you're doing infrastructure as a service, then it's on you.
Speaker 2 (08:00):
Yeah, exactly, yeah, right, and the updates not so hard. Right.
You can update PAM, Dash canfig Comma, you disc to
Comma lib block dev right, and it will update it
on your system and you're good to go. We can
make sure that that makes it into the show notes.
But you know, in short, yeah, go go make sure
(08:21):
you patch this relatively quickly because there's an active, active
poc out there for it.
Speaker 1 (08:26):
Now, what does that mean for all of the smart
TVs running Linux and all of those other things. Are
we less worried about home appliances? Are we just as worried?
Speaker 2 (08:35):
Yeah, that's a good question. I didn't. I didn't see
anything in there that says that those are exploitable. But
I don't know. I actually I wouldn't mind testing it out.
I mean, when you start talking about squash fs, which
is the file system that's on a lot of those devices,
is a little bit different than you know, your straight
up Unix.
Speaker 3 (08:53):
Android doesn't have this. If this isn't an android's.
Speaker 2 (08:56):
Exploit, yeah, but you do still have things like busy box,
which do you have some of the same functions and
utili show. Yeah, I would say no, but checking I'm
saying that with a with it.
Speaker 1 (09:10):
I don't. You're saying I don't know. But if I
had to guess probably not.
Speaker 2 (09:14):
I had to guess probably not.
Speaker 3 (09:15):
You're saying it with with a certain intonation. You're saying
I don't know.
Speaker 1 (09:19):
Yeah, Yeah, that's what Dwayne said. Question.
Speaker 2 (09:24):
And if I do find it, I'll only keep it
to myself for a couple of months and then I'll
let everybody.
Speaker 1 (09:28):
Know, all right, heads up, Well, you note pad plus
plus users, and you know who you are. I love
no pad plus plus.
Speaker 3 (09:36):
It doesn't love you back.
Speaker 1 (09:38):
Vulnerability. Let attacker gain complete system control, no proof of
concept released.
Speaker 2 (09:45):
Yikes, yeah, how this is uh, this is the case
of what's going.
Speaker 1 (09:54):
One job? Your job is to open a file and
let me edit it. Why are you on the internet?
Why are you connecting anyways?
Speaker 3 (10:03):
Because code injection. This is a code injection vulnerability, and
that means the sky's limit.
Speaker 2 (10:08):
So it is funny though, because my team, we've used
no pad plus plus ubiquitously right, and every time you
open no pay for any of you know, pet plus
plus people. Anytime you open it, you'll see, hey, there's
a new module. Do you want to update? And I
swear to god, our team always goes not today Russia
and we clicked no.
Speaker 3 (10:29):
I've heard them say that. I've heard them say that.
Speaker 2 (10:32):
We're like, if somebody were to compromise our team, it's
probably a fake note pad plus plus update.
Speaker 1 (10:38):
What kind of modules does the updating? Does no pad
need come on?
Speaker 3 (10:45):
There's the modules does the module that edits text? And
then there's the module that what are the manuduls?
Speaker 2 (10:50):
What they need? I mean, I know right when the
calls home to Russia. So there are no In all reality,
there are actually some really cool extensions in moduleser than
just yeahs the hacker are they are? They awesome? They
are awesome. So some of them, you know, some of
them will format texts uh in you know, in easier
(11:13):
ways to read, whether it's examlo Jason or whatever. Some
of them will there's a lot of some of them
will convert text. Some of them will convert encoding.
Speaker 1 (11:22):
So it's really a low grade word processor. It's not
a text editor.
Speaker 2 (11:26):
Yeah, there's Now there's a lot behind the scenes that
you can do in NOE plus plus. It has a
rej ex engine in there, so you can do rejects,
so look for certain things. It's actually powerful.
Speaker 3 (11:38):
That seems very convenient.
Speaker 1 (11:41):
All right, let's get let's get to the vulnerability itself. Yeah,
so it allows attackers to gain system level privileges through
a technique known as binary planting, with a proof of
concept demonstration now publicly available. Yes, what is binary planting?
Speaker 2 (11:57):
So binary planting is the ability for you to exploit
the search flaw in applications. What does that mean when
I load up an application, And this is actually one
of the ways that we'll do DLL hijacking if I
load up an application and I watch what that application
is doing when it loads. Right, So if I'm on
(12:18):
you know, Linux, I'm going to watch an application, watches
it loads on Windows, watches it loads, and when it loads,
it makes calls out to different DLLs on the system. Right,
it might be the net thirty two API, right, because
it needs to talk to networking and that sort of stuff.
Speaker 1 (12:34):
Yeah, let me talk to the kids for a minute.
Ds are libraries that exist in Windows system directory. Usually
they can be calm objects, which you don't need to
know about anymore because it's sold technology, or they can
just be straight up binary dlos. But anyway, they are
loaded by executables as libraries that contain code.
Speaker 3 (12:55):
Okay, continue on, Dynamic link library.
Speaker 2 (12:59):
Fun fact, they're all it's also my initials, yeah, dll
is or my initials middle names LEO just for you guys, taken.
Speaker 3 (13:07):
Notes a lab that made him had a sense of humor.
Speaker 2 (13:13):
It's like I was born to be in computers.
Speaker 1 (13:15):
Dynamic link LEO.
Speaker 2 (13:19):
Right, all right, so is there? Uh? Yeah, so go
out you can go out and patch. There are there
are later versions of noepet plus plus that you can
go out eight eight two. That Really the way this
would be exploited is if you were downloading now Pad
plus plus from a sort of a CD location into
your let's see your downloads directory, and and there happened
(13:40):
to be another DLL in there when you went to
install it or run it or whatever. The search order
for every application is always search my local directory first.
For DS, oh it's not here. Let's go take a
look at the operating system path system right, Oh it's
not there. Let's take a look at our install path. Right.
So there's this this order of and they're just manipulating
(14:01):
that and saying, oh, we're going to throw this DLL
it's looking for in the local directory so that when
you launch it that uses that instead of using the
official ones.
Speaker 1 (14:09):
So so, how did you actually find this, Dwayne? How
did you find this this vulnerability? What did you go
What CD site did you go to that made you
discover this?
Speaker 2 (14:21):
As a researcher, you go to all the CD sites.
Uh No, actually, honestly, there's all There are a lot
of really cool tools you can use to watch Windows
applications load and see see what they actually are calling
for and see it get denied. So you can see like, oh,
it tried to reach out to the DLL. Let's call it,
(14:41):
you know, Carl dot dll like wire trace for code
in in my download directory and that and that failed
because I got a file NOTT found And then it
reached out in a c com backslash Windows backslash System
thirty two looking for Carl dll and that failed, right,
and then it so you can actually watch that path
and go okay, as an attacker, I'm going to create
this Carl DLL and I'm going to put it in
(15:03):
System thirty two. I'm going to put it in Carl's
directory where he's running this application, because it'll get called first.
Speaker 1 (15:08):
Ye know, my Carl DLL doesn't fit in my Windows
drive because it's so big. It's basically a copy of
my brain in code form. And I have to have
a special hard drive ten terabyte hard drive.
Speaker 2 (15:22):
Not a floppy, right, yeah.
Speaker 1 (15:24):
Just to hold it all right, I got a puzzle
for you, speaking of terabyte hard drives. I must I'm
a music producer and a musician and stuff, and I
have a client in my studio. We've been working on
an album more like on the last song. Right. All
of his music is on one of those sand disc
four terabyte USB drives, right, And it's a policy of
(15:47):
mind that that goes home with you like you keep
it and because I don't want you to calling me
ten years from now saying hey, do you have that file?
Blah blah blah. All right, So so we're we're together
studio and he says, hey, pull up this particular song.
And it's a song that I recorded for him a
long time ago. I didn't even remember it. And we
(16:09):
looked on the drive and it wasn't there, and I said,
wait a minute, did we do this at the other location.
He says, yeah, we did it the other location. So
that was a different computer, which right now I'm using
as a Dublin webcam. Right. So I go over there
and I dropped to a command prompt and I do
a dr slash ass and sure enough I find it. Oh,
(16:32):
it's right here. So I don't really have shared drives
between these these computers are not connected at all. So
I unplug the sand dis drive, plug it into the
old computer, copy the stuff over. He takes it home
to copy off on his own backup, and he says, hey,
(16:54):
this hard drive is protected with some password or something,
and I'm like, huh, oh, it's not I never protected it, right.
He goes, yeah, something about BitLocker. Oh, and I'm like what.
Speaker 2 (17:06):
That doesn't make any sense.
Speaker 1 (17:07):
So yeah, so he brings it back with his laptop
and sure enough, his laptop says, no, this is protected
by BitLocker. What's the code?
Speaker 3 (17:15):
Those are very long codes.
Speaker 1 (17:16):
Forty eight characters something like that. Oh yeah, So there's
a website I find that you can go to at
Microsoft and find all your BitLocker keys, And sure enough,
there was one there that was set by this secondary computer.
The secondary computer locked that drive with BitLocker encrypted it.
Oh wow, And I even know. I just plugged it
(17:37):
in and copied some files, but it clearly said it
right there. So, now that I know I wasn't getting ransomwared,
I plugged it into my computer and unlocked it. But nice,
How about that?
Speaker 3 (17:50):
Why unintended feature?
Speaker 2 (17:53):
Yeah?
Speaker 1 (17:53):
Thanks Microsoft? Why did you encrypt something that I didn't
ask you.
Speaker 3 (17:57):
To without prompting?
Speaker 1 (17:58):
Yeah? Yeah, without anything.
Speaker 2 (18:00):
Yeah, that's that's interesting. I didn't know you could automatically
have it.
Speaker 1 (18:04):
Yeah.
Speaker 2 (18:05):
So adopt a BitLocker, a drive.
Speaker 3 (18:07):
It's probably a setting, probably a low level setting.
Speaker 1 (18:10):
Yeah, it must be a low level setting or something.
But apparently there's a feature in Windows ten and eleven
and certain versions that will automatically do that.
Speaker 3 (18:18):
What could be is that there was a bug and
it got patched after a short period of time and
you just never did you decommissioned the computer and missed it.
I'm hoping that's what it is.
Speaker 2 (18:28):
Now.
Speaker 1 (18:28):
The computer is, the computer is automatic updates.
Speaker 3 (18:31):
Like oh okay, oh yeah, that may well, yeah, it's
a weird one.
Speaker 1 (18:36):
Weird one. All right, let's move on this next one.
I'm sure you guys.
Speaker 3 (18:40):
Have so I have many opinions.
Speaker 1 (18:43):
Well, let me announce it first, I know, right, first,
damn jump up there, sit down.
Speaker 2 (18:48):
Man oh manish chevit's all.
Speaker 1 (18:50):
Right, bleeping computer. How today's pen test models compare and
why continuous pen testing wins?
Speaker 3 (18:58):
So Patrick, thank you. So I agree in spirit with this,
but it's a gimmick to some extent because the problem is,
and this is self criticism for our industry, but I
think we do a really good job of not doing this.
The way a lot of pen tests are run is
here's a scan. Merry Christmas, give me my money. We've
(19:21):
had customers tell us that We've had customers tell us
they weren't going to work with us for more than
a year, and then five years later they're still working
with us because they've had such bad experience. As they
thought just playing the field and having a different vendor
every year is the only way to protect themselves. If
you get a great pen test and you can do
that all year round, you better have deep pockets. It's
very expensive. You have to have really good resources to
(19:44):
find stuff. If you're just doing scans, then yeah, scan
every day. You can buy the scanning software. But to
do a really good pen testing on a continual basis,
you have to hire really good resources in house and
have them work on it all the time. Hugely expensive,
and we've got customers that do that. Or you have
to be just being willing to pay boltloads of money
(20:06):
to have pen tests done by professionals.
Speaker 1 (20:08):
It's not like a pipeline you can set up and
get hub.
Speaker 3 (20:11):
You know, their hope is the gimmick here is well,
we have this AI software that'll find this stuff. And
Dwayne will tell you all day long there are plenty
of customers that we've gone to that have gotten pen tests,
sometimes within weeks of when we take a look at
the systems and they're companies that you would know the
names of, and then we get in there, we find
all sorts of things they didn't find because they're using
(20:33):
AI tools and they're using scanners and they're using you know,
but we're actually cans on keyboard saying well, I wonder
if this would work. And that's we're still not there
with AI. We're not there with air for a while.
Speaker 1 (20:46):
They don't have data the Android in their crew.
Speaker 3 (20:48):
No, it's it's you know, AI is a AI is
really good at identifying patterns. It's identifying, hey, this person's
logging in outside of business hours and things like that.
But it's also bad at understanding exceptions.
Speaker 1 (21:02):
Yeah, things that hasn't seen before.
Speaker 3 (21:04):
So I that's my take on it. I'm very curious
what Dwain's take on it is.
Speaker 2 (21:09):
So my take on it is a lot of people
that You're absolutely right, a lot of people don't understand
the difference between a pen test and a vulnerability scan, right,
and that that's key. And it's amazing how much confusion
there is in our industry right where they're like, oh,
I had a pen test done. You're like, oh cool,
that's awesome. So we're talking like engineers, hands on keys,
actually poking it this software making sure that whatever static
(21:33):
analysis you had, they're going above and beyond. This is
the dynamic analysis of your code, making sure that everything
is working right and you've configured everything properly. And they're like, no, no, no, no,
it took an hour and they just handed me a
pen test report and it's and that's not a pen test, rights,
it's a NESSA scan. Yeah. Yeah, Hey, anybody's offering you
a scan of your environment. You can go out to
(21:54):
nessis and you can buy a license and you can
go scan your environment externally and come up with a report.
If that's what you're looking to do.
Speaker 1 (22:01):
How do you spell that? Can we add a link
to that? What is that? Nessus?
Speaker 2 (22:04):
Sure?
Speaker 3 (22:04):
Absolutely an eess us. Now, if it's run by somebody
who adds extra value to it, it's can be useful, yes,
but let's do this real quick. A vulnerability scan is
like someone walking around your house looking at windows and
doors and taking notes about what could be done. Potentially
a pen test. They try to actually crawl through the vents,
(22:24):
go get into the bulkhead, pick the locks and try
to get into the house, right, and then they look
around once they're in and they try to find out
whether they can get in the safe and things like that.
Vulnerability assessment is very superficial. You can do internal vulnerabil
assessments which are far more expensive and more invasive, but
it's still just looking at well, these are no I
(22:46):
can tell from the external that these are vulnerabilities, whereas
a PEN test we actually try to see can we
do anything with it? What can where can we chang
these these problems?
Speaker 1 (22:55):
Okay?
Speaker 2 (22:55):
Yeah, and so so now take you're saying you're going
to do an automated AI PEN test continuously as a service,
and there's there's today's day and age. I'm not saying
it can't happen at some point maybe when AGI comes out,
but in today's day and age, there's there are there.
Speaker 3 (23:14):
Are very if it's not too busy killing us.
Speaker 2 (23:16):
Yeah, in today's day and age, there's very few ais.
And I'll throw the AIRR quotes out there. Large language
model statistical analysis engines right that can go through all
of the different types of weird configurations humans may put
on computers and come back and say, yes, it's safe, right.
(23:39):
It generally takes an engineer. Unfortunately, a lot of times
it takes an engineer who has decades of experienced to say, Okay,
I see how this is all stitched together, and I
know how I would break it, and here's how I
would how I would break it. You know, think of
it as I'm trying to guess a sixty four character password. Right.
(23:59):
Computers can't do that right now. But if I knew
that the user liked to use music, and they liked
these certain digits, and here are their birth dates, right,
I is a password cracking engineer of ten years could go, okay,
I can probably guess a sixty four character password where
a computer wouldn't. Right, same type of thing when you're
(24:19):
starting to look at a super complex network, you're looking
at code that's created that has been created over the
last twenty years and is kind of this monstrous application,
and you know, it generally takes a really experienced personal
look through and go, I know how I break this.
So I just don't think you're going to get there.
This is what I'm saying, where you have this AI
continuous pen testing.
Speaker 1 (24:39):
But it's interesting you say you could break a sixty
four character password if you know certain things, would you
sort of still use randomizers but narrow or include the
rules that you know the things that they use.
Speaker 2 (24:52):
Yeah, absolutely, yeah, yep, yeah, and some of it's regional,
you know, if not saying we do, but if we
were cracking password from systems in China, we know there
are certain there.
Speaker 3 (25:04):
Are certain eighty percent of them are all numbers.
Speaker 1 (25:06):
And there's a reason why he's laughing, folks.
Speaker 3 (25:09):
Eighty percent of them are all numbers.
Speaker 1 (25:10):
It is certain because that's complete bs.
Speaker 2 (25:13):
There are certain numbers they like maybe that help, so yeah,
possibly possibly certain magic numbers that they should probably stop using.
That sounds like words.
Speaker 1 (25:27):
We're not going to give them any criminal career advice.
Speaker 2 (25:29):
However, so but yeah, so needless to say, yeah, profiling
can definitely help augment password cracking, and it's and an
AI computer's not going to figure that out right and
say hey, this is how I would approach this.
Speaker 1 (25:43):
Okay, anything else on pen testing you guys want to
talk about, because this is kind of what you do.
Speaker 3 (25:50):
I mean, we see a lot of frustration in our
industry because there's a shortage of people who do what
we do. There's a very large percentage of people who
do what we do that have imposter syndrome, and therefore
they keep secretive about how they do it. And as
far as I know, we're the only company I've ever
seen or heard of that invites the customer to watch right,
(26:14):
and we try to turn into a training exercise.
Speaker 1 (26:16):
Yeah, right, because you ultimately want them to take care
of themselves.
Speaker 3 (26:20):
Oh, absolutely right, and we get I mean, we have
such retention amongst our customers. It's not it's really helpful,
but it's because we want them to survive this cyber
war that we find ourselves in.
Speaker 1 (26:33):
Right, And on that happy note, let's take a quick
break and we'll be right back after these very important messages.
And as a reminder, if you don't want to hear
these messages, just go to Patreon, dots securitydoweek dot com.
Five bucks a month will get you a feed with
no ads. We'll be right back. All right, and we're back.
It's Security this week. I'm Karl, let's Dwayne, that's Patrick,
(26:56):
and we're We've got a few more stories here before
we say goodbye. The first one is hacker news. Citrix
releases emergency patches for actively exploited CV twenty twenty five
six five four three and NetScaler ADC.
Speaker 3 (27:14):
Yeah, this is a quick one.
Speaker 2 (27:16):
That's a lot of acronym super is.
Speaker 3 (27:17):
So there's a patch available. It's it's being exploited in
d doss attacks, which you know is still not no bueno.
But it's better than ransomware and many of the other things.
So I consider this important, but not like crazy crazy
Sky's falling.
Speaker 1 (27:36):
First of all, what does the ADC stand for? And
it's a net Scaler product, I get it, But what
is it?
Speaker 2 (27:41):
Yeah? So net Scaler's ADC is the application delivery controller. So,
for those of you who have known and used Citrics
for a very long time, application delivery controllers. There are
a lot of times you want users to have access
to a particular type of application, but you don't want
to give them a full operating system. You want them
to have it in access to it in a browser,
(28:01):
but it might be a thick client, not necessarily something
that served over the web. So the ADC gives you
the ability to do those types of things.
Speaker 1 (28:09):
Cool, all right, So this vulnerability carries a CVSS score
nine point two, and I wondered, Dwayne, is that accurate
for a contagent score as well? Or do you think
it has a lower contagent score because it's d DOS.
Speaker 3 (28:23):
I don't think it should be ranked as high.
Speaker 2 (28:25):
Yeah, agreed. For the most part, I generally ranked d
DOSS as lower. In general, Yes, it sucks if it
goes offline, but it doesn't compromise much. So if somebody
wants to be malicious, you can find who's doing it
generally and shut them down.
Speaker 3 (28:40):
I mean, if it's nine to one to one emergency
services a different deal, Yeah, yeah, exactly, or if it's
a context specific blood.
Speaker 2 (28:48):
Analysis company, which we'll talk about maybe a little bit later.
But agreed, denial of service can be damaging. I get it,
But from an exploitation sense, like I usually the ease
at which you can exploit these things matters, but also
the damage it can do matters, So yeah, I would
(29:09):
I would absolutely say it not as high on my list.
Speaker 1 (29:12):
Okay, all right, And there is a patch apparently mm hmm.
Speaker 2 (29:16):
Yep, go patch, Go patch, patchy patch patch great patch easy.
Speaker 1 (29:21):
This one is interesting because I have used both of
these things. Hackers abuse Microsoft click once and AWS services
for stealthy attacks. I don't know if you remember click once, Patrick,
but we used to use that in our demos and
we did all those Microsoft Demo roadshows. It's basically a
way that you could all right, So, before there was
(29:44):
browsers that had really good software and all the security
and everything, people wrote Windows applications and the big problem
with Windows applications was how do you distribute them to
You could make an installer, but what about when you
have updates? Right, So they came up with this click
once feature where you literally just installed it with a
single click. It downloaded everything and then it could notify
(30:05):
you of changes and all that stuff. And it's basically
a manifest that has versions and DLLs and folders on
a web directory. And we had multiple problems with this
working in demos and things like that because it requires
a network connection. Even if it's one twenty seven zero
(30:26):
zero one, you had to like install. So I just
remember just pain to demo.
Speaker 3 (30:31):
It was the assumption that we would always be on
and that's just not the case really. I mean we
thought that that would be the case, but there's still
situations where you want to work without that connection.
Speaker 1 (30:42):
Yeah.
Speaker 2 (30:43):
It still amazes me though that it's something that still works. Right,
You would think it was such a defunct technology we
use technologist had it's hard time getting it to work
under real circumstances. Mind kind of attackers getting to use it.
So good for them. Maybe they were just phenomenal network administrators.
(31:03):
Maybe they six captives, they fixed it. What they just
hate their users, right exactly? Probably honestly, yeah, I do,
I do remember, all right.
Speaker 1 (31:13):
So but they also they mentioned AWS services, so those
things are completely different. How do they fall into the
same umbrella.
Speaker 2 (31:22):
So a w S services is Honestly, if you're if
you're looking to hack into a place, a w S
services are awesome, don't it's here's why. So a lot
of times, if you're going to be hacking into an organization, big,
(31:45):
small doesn't matter. There are certain places that most organizations
will not block, and uh AWS and Azure generally be
two of them. So also, let's say you're trying to
hack a cloud property. So let's say I want to
hack something in Azure. The best place to do it
is from AWS. You don't want to do it from
a property in Azure because Microsoft has control over all
(32:07):
of that.
Speaker 1 (32:08):
Yeah, you're right.
Speaker 2 (32:09):
So if you do it from AWS. Well, the thing
with a WS is it's real hard for Microsoft and
Amazon ciye to eye. So it makes it a real
nice place for you to and the seams poke the
bear from me either say.
Speaker 1 (32:19):
They don't share their IP address ranges or anything like that.
They don't like sit around the coffee table in the
morning and say, hey, right, I'm using these.
Speaker 2 (32:27):
Yeah, you're using yeah. And and what's great about hacking
from the cloud is if you do get compromised in
some way, you just shift your IP address, right, it
goes away, So and then you continue your hacking, which
is always fun.
Speaker 1 (32:44):
For you're learning stuff kids?
Speaker 2 (32:46):
Are you learning stuff legally? All right?
Speaker 1 (32:49):
So what what's going on with this with this problem here,
this vulnerability.
Speaker 2 (32:57):
Yeah, so in this, in this particular case, the click once,
which was a deployment Microsoft technology, is the initial vector, right. Okay,
so they combine attacks here where they have that custom
malware baked into a click ones tool that then reaches
out and is using cloud as kind of a C
(33:18):
two command control structure. Okay, Right, so no corporate network
is going to say, oh my gosh, you're reaching out
to Amazon right right, Well, because everybody reaches out to
Amazon for every you know, sort of cloud sass style
service you could possibly imagine, So it doesn't throw any
red flags for corporate firewall to see communications back out
(33:38):
to a WS or Azure. So it makes it a
really good place to control.
Speaker 1 (33:41):
Is this a click once installation on AWS or is
it on Azure or is it in on prem where
is it? Can it be anywhere?
Speaker 2 (33:49):
So it can be anywhere. Honestly, you got to be
careful what you're downloading. Click ones had a great I
mean honestly, I really liked click once because you could
give a n rel to a user and have them
click on it and they were just install an app right.
Speaker 3 (34:02):
Like dehydrated application.
Speaker 2 (34:03):
Yeah, there was a lot of really cool stuff. There
was also, if I remember correctly, there was a way
to deploy the app icon to the user's desktop and
I have it not be installed yet, and when they
double clicked on the icon, going oh I want to
use this app, it installed and then opened immediately. Yeah,
what could go wrong? Really from a from a malware
(34:27):
deployment sense, it's actually a really good way to the
dream come true. Yeah, it's nice. So then once once this, uh,
you know, once they pulled information out of the cloud
and pulled down the you know, the one click installation,
then we start seeing a bunch of backdoors get installed
and some some Go applications get installed that were doing
(34:49):
all sorts of nasty stuff, Cobalt strike beacons getting installed.
So there's a lot of stuff in the back end
I gets thrown in there.
Speaker 1 (34:55):
All right, So is there a way that we can
mitigate this other than don't use click one? That's what
they thank you, thinking, stupid developers, what are you doing?
Speaker 2 (35:04):
Yeah, you know what that's Uh, you can actually restrict
click ones.
Speaker 3 (35:08):
I mean it does start with a phishing email oh okay,
with a link to the fake hardware analysis site. So
it so basically they've got they've got to click at
least once.
Speaker 1 (35:17):
I see. So if huh, all right, So, if you know,
Bob and Software Engineering sends you a URL that's the
click ones deployment for an app that's clearly defined and
blah blah blah, you're going to trust that more than
you get an email from somebody else.
Speaker 3 (35:37):
And the thing about this is if somebody clicks this,
you could actually give them an app that looks like
what you've promised, and they might think not not realized,
they just got owned. Wow. Because the problem is if
somebody clicks on the wrong thing, they might just unplug
the computer, they might sever their network connection, they might
do a whole bunch of things to keep you from
stealing all their data. Whereas with this you might say, oh,
(36:01):
that's an interesting applicat.
Speaker 1 (36:02):
Oh it's not.
Speaker 3 (36:03):
It's not connecting. I'll have to look at that in
a little bit, and they can give you a user
interface that looks like what they promised, and you won't
get you won't get caught on till later.
Speaker 1 (36:12):
All right, So go read the article and make sure
that you don't do any of the things that they did.
How about that?
Speaker 2 (36:20):
How about that? Don't put on don't click on anything.
Speaker 1 (36:22):
Don't click on links. Links are bad.
Speaker 3 (36:24):
I mean, it's not like what we're talking about is
life or death or is it?
Speaker 2 (36:29):
Oh?
Speaker 1 (36:29):
Speaking of death? This one all right, Well, let's just
go ahead and read this. This is from sky News,
that bastion of really high quality, well researched news. Patience
death linked to cyber attack on NHS hospital. Trust says
so the member the the cyber attack last year that
(36:56):
saw eleven hundred cancer treatments, laid two thousand outpatient appointments,
and canceled more than a thousand operations. So yeah, or
postponed a thousand operations. So this is the first death.
Speaker 3 (37:12):
Remember when we thought that this kind of attack would
be caused for war, Yeah, that this was a red line,
that they'd never do this unless we are actually in
a war. It's now become commonplace.
Speaker 2 (37:23):
Yeah, honestly, it's too bad too. I could see, like
I see hackers targeting critical infrastructure when you know there's
a war going on, I am and from critical instructure
infrastructure like power, grids and water and that sort of stuff,
and that sucks, right, But just to have a ransomware
group hit you know, some random medical facility and start
(37:45):
causing it just don't know it's killing people.
Speaker 1 (37:48):
I mean, it's a it's a soft way to cause
death and mayhem. That is completely unnecessary.
Speaker 2 (37:56):
Yeah, I agree, one hundred percent. Yeah. Uh And you
know this, this article actually came from Cliff and Ethan
on our discord, So thank you guys for pointing this out.
Speaker 1 (38:08):
But I told you I met Cliff in Sweden.
Speaker 2 (38:10):
Right, Yeah, that's cool. We're going to drag them on
the show at some point. Yeah, very good to get
is to get his feeling for what, you know, different
different security issues we see. But but yeah, this is
just we wanted to bring this up because it you
know a lot of times we talk about cyber breaches
and ransomware and that's where stuff and it's like, oh,
you know, some you know, whatever school district got ransomware
and the kids got the day off of school.
Speaker 1 (38:32):
Yeah, if it costs people money, we're not so right. Well,
you get what you you know, reap what you sew.
But but when people are dying.
Speaker 2 (38:39):
Yeah, yeah, because the people who in this particular case,
the person who died had no control over whether the
systems that you know, the blood Analysis company were patched,
no control over what their you know, software policies were
and their security policies were. It's just they happened to
be a senseless victim of this. So that, yeah, that sucks.
Speaker 3 (39:01):
I would be willing to pay more taxes to have
someone hunt these people down and kill them.
Speaker 2 (39:05):
Oh wow, because it's fast.
Speaker 3 (39:07):
Well, yeah, that's my role kind of the dark guy.
Speaker 2 (39:12):
We haven't heard bawks in a while.
Speaker 3 (39:14):
Let me get let me get the last words on
this manifesto real quick.
Speaker 1 (39:18):
Patrick has a sign on his yard that says no trespassing.
I ran out of body bags.
Speaker 3 (39:27):
The alligators are full.
Speaker 2 (39:28):
Yeah, yeah, come back to my room.
Speaker 1 (39:31):
All right. Shall we get to our clickbait story? Yes?
I chose this one for the last story because many
people use Gmail and many people are such as me,
are afraid if their Gmail account gets compromised because I
have you know, like everybody, I have so much stuff
in my inbox and I have so much stuff in
(39:53):
drive and all this and you know, go back and
look at the calendar, like you know, a lot of
people just use this for everything. Thing. So the story
is Russian hackers bypass Gmail multi factor authentication using stolen
app passwords. And at first Blush, you might think, oh
my god, change your Gmail password, change your Gmail password
(40:16):
right now, and you know it's not safe, and change
your MFA, get a new phone, like you know, this
is scary stuff. So what is the real story here?
Speaker 2 (40:28):
The real story here is a classic social engineering story.
Speaker 1 (40:33):
It just comes back to don't click on that link.
Speaker 3 (40:36):
It's spearfishing, it's well researched. They're targeting people who are
illuminaries academics and journalists who tark who are critical of Russia,
so I'd probably be on that list. And they're trying
they're convincing them to create what's called an app specific passwords.
So imagine you had a federation with Google with Gmail,
(40:57):
and you had an app that was going to enhance
your Gmail in some way, and so it needs access
to your contacts list or to some aspect of your Gmail.
They're convincing these people to share that with them, and
in that way they're getting around two factor authentication.
Speaker 1 (41:16):
It's a good you know, you use a service, and
simple example is you want to use Gmail to log in,
So you get at sure log in with Gmail, and
then it's Gmail pops up and says, hey, do you
want to allow Bob's discount sharkcages dot com to access
your Gmail account or whatever? Yeah, log you in.
Speaker 3 (41:34):
But they're convincing them that they're being contacted by the
US State Department and then probably saying things like, hey,
we see that you're being targeted, which is true because
they are being targeted, and we want to help you
because we believe they're going to come after your Gmail,
which they are. Again the truth. All the way through.
But we have this app that will help detect you
(41:57):
and protect your Gmail and give you a higher level
of security. So you'd like to do that, sign up
for this and when you sign up, you have to
give it a password and you have to allow it
permissions to your Gmail. And so now they're in. So
it's it's it's under the quantity. So when you deal
with high level security people in the government, they rarely
say call this number. Yeah, they say, go to the
(42:18):
website for my agency, call this office, look up this office,
call that number and ask for agent whatever, and then
they'll verify that I'm who I say I am.
Speaker 1 (42:28):
In general, I never I completely ignore anything government anything,
text email, whatever from the government. Government wants to get
in touch and me, you'll send me a letter because
they try that. Yeah, well they have a van with
guys with masks. They get you anyway. The long and
(42:49):
short of it is, it's social engineering. Do you guys
know the rules about that? Don't click anything suspicious, Never
call a number that somebody texts you. Always never click
a link that somebody texts you. And yeah, be careful
out there, kids.
Speaker 2 (43:06):
Yeah, And I would say there that there's definitely a
call to action too to go through your Google account
and see if there are any applications that are authentic,
that are authenticating or authorized to use your app, and
you know your your account and shut them down right,
It's easy to go to you know, Gmail dot com
(43:27):
and click on your little face up in the upper
or right hand corner, and you know, manage my account
and you'll see it right in the security section which
apps on your phone have access to your account and
as well as which linked accounts you have.
Speaker 3 (43:40):
One more thing about this is this attack was done
with the message comes from a Gmail account, but they
they see see multiple state dot gov accounts that probably
don't exist and bounce and so therefore it's you should
be able to pick that up with. The first thing
we teach people in fishing training is first, have good bait.
(44:04):
Of other side is to have is to check who
it's from and make sure there's no typo, squatting or
anything funny there. If I get something from Gmail, if
I don't know them like personally and know that's their email,
I'm out. And I usually don't click on links from
people even if I know them.
Speaker 1 (44:21):
Yeah, me too. The friends in the band have a
bad habit of just texting.
Speaker 3 (44:26):
Linksy, man, check this out, just links, right, And it's.
Speaker 1 (44:30):
Usually like some musicians, some video or something, but it's
never I never click on them. And they say, hey,
did you see any thing? Of saying said, no, I
don't click on links and texts. I'm sorry. Well, you
don't trust me, not that I don't trust you. I
don't trust everyone around you. I don't trust everyone else.
Speaker 3 (44:46):
And yes, I don't trust you.
Speaker 2 (44:47):
And it's not just you, but nothing personal you too.
Speaker 3 (44:52):
Yeah, it's just that you're not a paragon of cybersecurity.
Speaker 2 (44:57):
Right.
Speaker 1 (44:58):
And then I'll open up the phone and say, is
this the one you're talking about?
Speaker 2 (45:01):
This is good?
Speaker 1 (45:02):
Oh okay, I'll watch it now.
Speaker 3 (45:04):
You're just out of banding it, that's all, yeah, exactly,
And that has two meanings in this case because they're
in a bad right.
Speaker 1 (45:11):
All right, guys, I gotta go. I'm waiting for Jeff
Bezos's wedding.
Speaker 3 (45:16):
Until Venice, I said, Hill.
Speaker 1 (45:20):
We'll see you next week, guys.
Speaker 3 (45:21):
Bye, guys,