8 hours 39 minutes
hello and welcome to another application of the minor attack framework discussion today. It we're looking at component firmware. So with that, let's go ahead and jump into our objectives. So today's objectives are as follows. We're going to describe component from where and what that is within minor.
We're going to describe how has component from where been used. What are some ways that this attack
methodology has been utilized for persistence? 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, so malicious device from where it 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 ah system, and even potentially, if the system was wiped and 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 low jacks and hacking team you e F I root kit. So these air types of you e F i root kits, they're dangerous in that again, they have the capability to survive measures such as operating system re installations and hard disc replacement. So is that not a scary?
I thought some of our
most aggressive malware that we've dealt with before typically does not survive a reload oven 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 brain new hard disk in that, that would not make a difference here.
Physical tampering. So there is some generic proof of concept backdoor from where modules on the accessibility of tools has made it possible to in star from where root kits in as little as four minutes of physical access to a system, so
that brings up A. 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 thesis Tums, 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 a ness corded
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 than 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 chip sets to pre installed applications. Now,
in this case, though,
we're not talking about chip sets or pre installed applications were 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.
let's talk about mitigation techniques, right? Cause this is this is tricky.
So per miner Okay, As 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.
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 ah, 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, uh, that arm or detection oriented, which we'll talk about here in a moment. But offhand, you may be able to have systems in place that check
the known good variance of firmware
and maybe do some some checks. There may be right out the gate
I PS systems intrusion prevention systems block
no malicious connections that may be 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 aren't targeted.
So let's talk about detection methodology here, and even the detection methodology again is pretty cumbersome. So forensic utilities may be capable of finding things such a strings, 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 $10,000 but there are also a lot of tools out there that you can use for free in things like the Cali Lennox distribution. But
you may still need ah, certain adapters or tools to even investigate these components and look through him. 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 dealing with super secret sauce information,
you probably have trusted providers, and you probably do evaluate equipment in this manner. But if your florist
you know, you may not have the capability to do these types of detection techniques
ah, comparison of the component hashes to known, Goodwin's may provide some insight to a 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
been great. But again, that is, maybe, you know, 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 from where is easily detectable and can be reverted. 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 firm where is not easily detectable,
um, and may not be easily reverted. Or it may take flashing
and things that nature that would have to be done that could potentially brick devices or render them useless so it could be risque 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 is being a persistence mechanism in which the firmware of a
peripheral device or devices, not system related is changed. We reviewed how component from where 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 known 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.