Hello and welcome to another
application of the minor attack
framework discussion today
we're looking at component firmware.
So with that, let's go ahead and
jump in to our objectives.
So today's objectives are
as follows.
We are going to describe component
firmware and what that is within
Meitner.
We're going to describe how
has component firmware been used?
What are some ways that this attack
methodology has been utilized for
persistance?
What are some mitigation techniques
and what are some detection
techniques as well?
So with that, let's go ahead and
jump right in.
So component
firmware is considered a
sophisticated means
to compromise a computer component.
The technique is like system
firmware, but it takes
advantage of system components that
may not have the same capability
as a malicious device.
Firmware can provide a persistent
level of access and
so not much to go on there.
But essentially what's happening
here is that other components
outside of the system can be taken
advantage of, their firmware
compromised, and then those devices
used to stay in the
system. And even potentially
if the system was wiped, reloaded
because it's firmware on the
component, that component could stay
intact as far as a mechanism for the
threat actor.
And so some of the areas
in which this has been used,
first off, Logic's
and hacking team UTF
rootkit. So these are types of
UTF I root kits.
They are dangerous in that, again,
they have the capability to survive
measures such as operating system
RE installations and hard disk
replacement.
So is that not a scary
thought? Some of our
most aggressive malware
that we've dealt with before
typically does not survive a reload
of an operating system or the
complete wipe and putting it back
to the golden image, whatever the
case may be.
So it's scary to think
that we're dealing with malware
of a nature that even if
we were to completely remove the
hard disk and put a brand new
hard disk in that, that would not
make a difference here, physical
tampering. So there is some generic
proof of concept back door from
where modules and the accessibility
of tools has made it possible to
install firmware kids
in as little as four minutes
of physical access to a
system.
So that brings up
an interesting point
in that this may be,
in this particular case,
either insider threat.
Right. Or
some type of maybe supply chain
compromise that has to happen
with the systems because.
Four minutes in the grand scheme
of things, especially if you're in a
high pace or productive environment,
can be quite a bit of
time. And so how
does one go about getting
unescorted access
to or the capability to be
in front of a system for
the amount of time, in this case, as
little as four minutes to be
able to tamper
with the system.
And again, though, this is a proof
of concept here, but I'm
sure that if someone has thought it,
then someone has likely done it.
Supply chain attacks.
So when a threat actor again
compromises hardware from where
before it ever reaches the customer
environment.
This has been seen with everything
from chipsets to preinstalled
applications.
Now, in this case,
though, we're not talking about
chipsets or preinstalled
applications.
We're just indicating here that a
supply chain attack, much like
in those two areas, could
also be taken advantage of
with respect to the
component firmware piece
that we're talking about.
So let's talk
about mitigation techniques.
Right, because this is this is
tricky.
So Perminder
is listed on Minor.
This type of attack technique cannot
be easily mitigated with
preventative control since it's
based on the abuse of system
features.
Now, we could argue
that with things like physical
tampering, when it's within
our premise, we might
have some compensating controls and
things of that nature.
But before the hardware
or component ever gets
to us
as a provider
or a business, whatever
the case may be, how
are we?
Able to even know if
such components were tampered
with and the answer is, is that we
may not always have that
capability, maybe
we start to think about things like
that or more detection oriented,
which we'll talk about here in a
moment.
But often you may be
able to have systems in place that
check the known
good variants of
firmware and maybe
do some some checks.
There may be right out the gate.
Systems Intrusion Prevention Systems
block.
No malicious connections that made
me come off of those devices,
so there might be some things to say
there, but in a nutshell,
it would be very difficult to
potentially prevent this
type of attack if you are targeted.
So let's talk about the detection
methodology here.
And even the detection methodology,
again, is pretty
cumbersome. So forensic utilities
may be capable of finding things
such as string's unexpected
disk, partition, entry tables or
table entries, blocks of
unusual memory.
But again, this is coming back
to capability
internally. I mean, I've seen
forensic devices that cost
upwards of ten thousand dollars,
but there are also a lot of tools
out there that you can use for free
and things like the
Kelly Linux distribution.
But you may still
need certain adapters
or tools to even
investigate these
components and look through them.
So, again, there's got to be some
training there. There's some initial
investment.
Is the juice worth the squeeze
with respect to risk reduction?
And again, it just all depends
on what type of organization you are
and what your day to day tasks
are. I mean, if you're a national
security agency, if you're dealing
with super secret source
information, you
probably have trusted
providers and you probably do
evaluate equipment in this manner.
But if you're a florist.
You know, you may not have the
capability to do these types of
detection techniques.
A comparison of the component hashas
to known Goodwins may provide some
insight to potential system
tampering as well.
And so, again, if we've got a
capability to take a file
that is a known good file and
generate a hash against the one
that we are provided with.
As far as on the component,
then great.
But again, that is
may be feasible for
some folks. It may not be feasible
for others as well.
So this is, again, a pretty
difficult type
of persistence mechanism
to combat.
So let's do a quick check on
learning.
Tampering with component firmware is
easily detectable and can be
reworded.
So I don't think you have to think
about this one. I am pretty sure we
know right out the gate that this is
false. So tampering with component
firmware is not easily detectable
and may not be easily reverted,
or it may take flashin and
things of that nature that would
have to be done, that could
potentially break devices or render
them useless.
So it could be risky
either way with respect to these
areas. And so let's go ahead and
talk about our summary.
So in summary, we described
component firmware as being a
persistent mechanism in which
the firmware of a
peripheral device or device, it is
not system related
is changed.
We reviewed how component firmware
has been used.
We looked at some mitigation
techniques that were very slim
and then we reviewed some potential
detection techniques.
Again, that in themselves could be
somewhat cumbersome, like forensic
utilities and things like that, a
comparison of hash values with
no good component information.
So with that in mind, I
want to thank you for your time
today, and I look forward to seeing
you again soon.