35C3 preroll music
Herald angel: OK so our next talk is given
by Frederic Vachon, so please give him a
warm round of applause.
Applause
Vachon: Okay so hello everyone. Thank you
for having me today. I'm really happy to
be to be here. So today I'm going to talk
about a research that a colleague of mine,
Jean-Ian Boutin and I did earlier this
year and which led us to the discovery of
a UEFI rootkit. So very quickly. My name
is Frederic Vachon, I'm a malware
researcher at ESET and I've been working
there for the last two years and for the
last year or so I've been really focusing
on boot level threats and UEFI firmware
reverse engineering. So let's look at the
agenda for this talk. So the first thing I
want to talk about is what is Sednit very
quickly. Then I'll talk about LoJack,
which is an anti-theft software and past
research related to this software and the
reason for that is that the UEFI rootkit
that I'll talk about really mimics the
architecture of this legitimate software.
Then we'll move on and I'll talk a little
bit about compromised LoJack agents that
were found in the wild, and finally I'll
jump into the UEFI rootkit, well, where
I'll talk about the tools around the
rootkit and the UEFI rootkit itself. So,
Sednit. Sednit is an espionage group
active since the early 2000s and it is
also known as Fancy Bear, APT28 and
STRONTIUM, so maybe you know this group by
one of these alternative names. And Sednit
is the name basically that we use at ESET.
So this group was very visible in the past
few years as being allegedly behind some
pretty mysterious hacks like the hack
against the Democratic National Committee,
the DNC, where some emails were leaked
online. The hack against the World Anti-
Doping Agency as well as the hack against
the French broadcasting network TV5 Monde.
But at ESET when we're talking about
Sednit, we're really talking about the
tools and the different campaigns that
were led using these tools, and we're not
talking about the people who are operating
this malware because we don't have the
information necessary to draw such
conclusions. However, in July 2018 the
U.S. Department of Justice named the group
as being responsible for the Democratic
National Committee hack in this specific
indictment. And what's interesting is that
the tools that we analyzed were... are
named in this specific indictment and they
also mention who's the authors of these
malware. And also early, not earlier, but
closer from from now, in October 2018, the
Department of Justice issued another
indictment naming pretty much the same
people are related to the World Anti-
Doping Agency hack. And the way that
Sednit will usually infect their targets
is by sending phishing emails, so
sometimes they will contain malicious
links and some of the time malicious
attachments. OK. So now let's talk a
little bit about LoJack. So Lojack is an
anti-theft software as I mentioned, and it
was previously known as Computrace. So
maybe you know the solution by this name
instead. And it is made by Absolute
Software. So, yeah, and this solution is
built in many laptops. But an anti-theft
software needs to be as persistent as
possible if you want it to be reliable. It
needs to be... to survive an operating
system re-install or a hard disk
replacement. So to achieve this what
Absolute Software did is that they added a
module in the UEFI BIOS itself. Yeah and
the solution needs to be activated in the
BIOS setup. So with a persistence
mechanism like that coming from the
firmware, it's really attracted the
attention of security researchers, who
looked into this to find vulnerabilities
basically. And at BlackHat in 2009 there
was a talk there where the architecture of
the solution was described and several
design vulnerabilities in the agent were
also described there. So let's look at the
architecture of LoJack back then. So the
first thing that we have here is a module
in the UEFI BIOS, and this module will
write a file to the Windows partition. So
this file is called autochk.exe, which
replaces the legitimate autochk.exe, whose
job is to perform filesystem integrity
check during early Windows boot. So by
replacing this agent during early Windows
boot it will be executed. And from there
it will drop rpcnetp.exe, which is the
small agent, and will install a service
and when Windows will run it will run this
service, and rpcnetp will be launched at
this point. And it will inject itself into
svchost , and then from there it will
inject itself into Internet Explorer which
is pretty interesting because it's very
shady and that's something that we see
pretty much all the time in malware but
not often in legitimate software. And from
Internet Explorer it will then communicate
with the command and control server and it
will download the full recovery agent. So
now let's look at some of the issues that
the researchers found with this... in this
solution. So one of the vulnerabilities
they found is very interesting for us and
in fact that's really the only one that
matters for this talk. And this is a
configuration file vulnerability. So the
configuration is embedded into rpcnetp.exe
and it is encrypted but it is encrypted
with a very weak algorithm. So it is in
single byte XOR key, and it is not
authenticated whatsoever. And what's in
this configuration file? Well, that's
where you can find the server, the command
and control server. So an attacker can
just change this configuration to point to
its own attacker-controlled server. So we
knew that this vulnerability existed for a
while, it was back in 2009, but we had no
evidence of it being used in the wild.
Until earlier this year, when Arbor
Networks published a blog post where they
described some modified small agent with
modified configuration where the domains
that were embedded in this configuration
were linked to old Sednit domains. So
let's go back to LoJack architecture and
look at where this attack took place. So
it took place at this level here. So from
there we did some detection for this
malware and it was... and we hunted to
gather as much samples as as we could. And
it was fairly simple because they always
modified the same exact version of the
agent and they modified, so that's what we
can see here, so they modified the command
and control server. And here we see the
encrypted version of course. So by looking
at this we will look at ESET's telemetry
and found out that there was a few
organizations that were hit mostly in the
Balkans, in Central Europe as well as in
Eastern Europe. These were military and
diplomatic organizations. And what's
interesting is that we also found other
Sednit tools in the same organization. So
at this point we wondered how this malware
got there, but since there was other
backdoors of Sednit in the organization we
thought it might be the infection vector,
but by digging a little bit deeper we
found another interesting component. And
if we go back to the LoJack architecture,
the component that we found is at this
step here. So at this step in the LoJack
architecture it's autochk.exe that lives
there. But what we found is another file
called autoche.exe instead of autochk. And
it does pretty much the same thing. So it
also installs a service and it also drops
rpcnetp.exe. But it is the rpcnetp version
that has a modified server in it. So
Sednit domain basically. And we continue
to look at what we can find in this
organization and we found another tool
which is called info_efi.exe, and that
allows to drop... to dump a lot of
information about very low level settings
of the machine. And this tool uses Read
Write Everything's driver. And
Read Write Everything is a software that allows you
to manipulate very low level setting of
your machine. So using this tool you can
read and write to PCI configuration
register, to memory-mapped IOs, to IO port
space and you can also access physical
memory and this tool uses a kernel driver
of course - if you want to do those things
you need a kernel driver. And this kernel
driver is properly signed so that you can
push it on even a recent version of
Windows. And so yeah, that's the driver
that was used by info_efi here. And by
Googling a little bit around what we found
out is that this specific driver was used
in the past by security researchers to
exploit vulnerabilities at the firmware
level. So, yeah, the last thing that was
missing here to mimic the whole LoJack
solution was a UEFI BIOS module. So at
this point we wondered, did they get
there. So, because of the tool dumping
information about the BIOS that I just
spoke about, we were pretty confident that
something more was happening there. And by
digging a little bit deeper, we found
other tools that strengthen our
suspicions. So the first tool is called
ReWriter_read. And it is a tool used to
dump the content of the SPI flash memory,
and it also uses Read Write Everything's driver and
it uses these specific IO control codes.
So it allows it to read and write to
memory-mapped IO space as well as read and
write to PCI configuration registers.
What's interesting for us as reverse
engineer is that this tool contains a lot
of debug strings which really made our job
easier. And it consists of the following
operations. So the first thing it will do
is that it will log information on the
BIOS_CNTL register and we'll talk a lot of
detail about this register just a little bit later
in this talk. Then it locates the BIOS
region base address. And finally it reads
the UEFI firmware content and dump it to a
file. So another tool that we found is
really complementary to the tool to
ReWriter_read and it is called
ReWriter_binary. So it also contains a lot
of debug strings. It also uses
RWEverything's driver. And now the UEFI
firmware is dumped into memory, the next
step is to add the rootkit to the firmware
and to write it back to the SPI flash
memory and that's exactly what this tool
does. Okay. So now let's talk about the
patching of the UEFI firmware. But before
we dig into the subjects there are a
couple things that I wanted to introduce
here just to make sure that we're on the
same page. So the first thing I want to
talk about is UEFI and UEFI stands for
Unified Extensible Firmware Interface and
it is a standardized specification that
defines the interface that exists between
the operating system and the firmware. And
it's kind of a replacement for the legacy
BIOS. So, a UEFI compliant firmware will
provide a set of services to UEFI
applications and here read the operating
system loader. There are other UEFI
applications, but usually it's the
operating system loader that runs. So the
first set of services is called the boot
services and these are services that are
available during the firmware lifetime but
once the operating system is loaded, these
services are not available anymore and
there are the runtime services that are
also available during firmware lifetime.
But once the operating system is loaded
they are still available, so that a kernel
driver for instance can make call in these
services. An example of these services
allows the operating system to read and
write to UEFI variables. And what's
interesting with UEFI is that there is no
more master boot record and volume boot
record involved in the boot process
meaning that there is no easy way to
hijack the early boot control flow. So the
second thing I want to introduce here are
the driver execution environment drivers -
so the DXE drivers. So DXE drivers are
PE/COFF images meaning that they are
basically Windows executables, and they
are kind of the core of UEFI firmware so
that they can do many things, some of them
will be used to abstract the hardware.
Some of them will be used to produce the
UEFI standard interface, so the boot
services and the runtime services, and
they can also be used by firmware vendors
or OEMs to extend the firmware by
registering new services - the so-called
protocols in the UEFI specification. And,
the DXE drivers are loaded during the DXE
phase of the platform initialization and
they are loaded by the DXE dispatcher that
will also be referred to as the DXE Core.
The last thing that I'm going to do: I
want to introduce for now is the UEFI
firmware layout - so the UEFI firmware
is located in the BIOS region of the SPI
flash memory. And this region will contain
multiple volume. But let's look at it with
a little bit more detail in this tool here
which is UEFI tool, that is an open source
software that allows you to manipulate
UEFI firmware images. So here I loaded the
typical content of SPI flash memory dump
in this tool and let's look at what we
have. So, the first thing that we see here
is the descriptor region, so it contains...
this region contains metadata about how
the remaining data in the SPI flash memory
is laid out. The second region that we
find here is the ME region which contains
the Intel Management Engine firmware. And
finally we have the BIOS region which is
really the main interest... the main thing
that we want to look at today. So the BIOS
region contains multiple volumes. So let's
look at one volume in a little bit more
detail. So here we have a volume of type
firmware filesystem version 2 and this
volume contains multiple files and these
files are identified by GUIDs. So that's
what we can see under the name column
here. And a file doesn't contain directly
the UEFI executable, but it is composed of
multiple sections and one of these section
is the actual UEFI executable, but there
are other section and in this case we see
a DXE dependency section that allows to
define dependencies for this specific UEFI
image and we also see a version section
and a user interface section which allows
to give us a human readable name for this
file instead of the GUID which is very
pretty difficult to remember for humans.
OK, so now that we have all this in mind
let's go back to ReWriter_binary. So what
ReWriter_binary will do is that it will
parse all of the firmware volumes that it
can find looking for 4 specific files. So
it looks for Ip4Dxe, NtfsDxe, SmiFlash,
and the DXE Core. So why does it look for
Ip4Dxe and the DXE Core? Well these files
are looked for to find the firmware volume
where to install the UEFI rootkit. So
usually in UEFI firmwares all of the DXE
drivers all in the same volume, so when
the tool will parse... will find in fact
Ip4Dxe, it will know it is currently
parsing the volume with all of the DXE
drivers in it and it will keep it as a
candidate for the UEFI rootkit
installation. And it looks for the DXE
Core basically for the same reason, but
sometimes the DXE Core is in a different
volume, so when it will find it, it will
keep the volume as another candidate for
the UEFI rootkit installation and the
chosen volume will be the one with enough
free space available in it. Now, NtfsDxe.
So NtfsDxe is the American Megatron Inc.
NTFS driver and if the tool finds it, it
will remove it, and the reason for that is
that the UEFI rootkit embeds its own NTFS
driver, so to avoid any conflict with
another NTFS driver it just removes it.
And now SmiFlash, so, SmiFlash is looked
for... and, you know, the tool will... if
the tool finds it, it will keep some
metadata about it in the structure, but in
the version of the tool that we analyzed
it's not used anywhere. But interestingly,
SmiFlash is a known vulnerable DXE driver.
So what we believe is that Sednit might
have been fiddling in another version of
the tool with some exploit for this driver
in order to be able to bypass write
protection mechanisms to the BIOS region
of the SPI flash memory. So now that it
has found the volume where to install the
rootkit, it will add the rootkit, right.
So the first thing it does, it will create
a firmware file system file header, then
it will append the rootkit file, which is
a compressed section that contains two
other sections, one of one of these is the
actual UEFI rootkit image and the other
one is a user interface section defining
the name for this rootkit which is SecDXE,
as in security DXE. And then it will take
this blob of data and write it at the end
of the firmware volume that was chosen.
So now that the UEFI rootkit is inside the
firmware into memory, the next step is to
write it back to the SPI flash memory. And
once again there's a couple of things that
I want to introduce here. So I want to
talk about BIOS write protection
mechanisms. So the chipset exposes write
protection mechanisms that need to be
properly configured by the firmware. So
there are no such thing as, you know, BIOS
write particular mechanism enabled by
default. It's really the job of the
firmware to do that. And today will only
cover relevant protections to our
research. So only the protection mechanism
that are looked for by
REWriter_binary. And yeah the protection
we'll talk about are exposed via the BIOS
control register that we've seen a little
bit earlier in this talk. So, if you're a
kernel driver and you want to write to be
BIOS region of the SPI flash memory, what
you need to do first is you need to set
the BIOS Write Enable field of the BIOS
control register to 1 and then you're able
to write to the SPI flash memory. But of
course you don't want any kernel driver to
be able to modify your UEFI firmware and
potentially brick your machine. So there's
a protection mechanism there which is
another field in the BIOS control register
and this field is called BIOS lock enable
and it allows to lock BIOS Writer Enable to
0. And this field is readable in WLO. WLO
means write lock once. And what it means
is that once the firmware has set this bit
there's no other way to set it back to 0
than performing a full platform reset.
But there's a problem here, and it lies in the
fact that BIOS lock enable implementation
is vulnerable. So how it works is that
when BIOS write enable is set to 1, it's
value will actually change in the BIOS
control register for a small amount of
time. And then the platform will issue a
system management interrupt and the SMI
handler will set BIOS write enable back to
0. But, yeah, the firmware must implement
this SMI, otherwise this mechanism is
totally useless. But maybe you've guessed
it. But what happens if we write to the
SPI flash memory before the SMI handler
sets BIOS write enable back to 0? So there
is a race condition vulnerability here.
And there is a paper about it which is
called "speed racer". And to exploit this
what you need to do is, you need one
thread that continuously sets BIOS write
enable to 1, while another thread tries to
write the data to the SPI flash memory.
And according to this paper it works on
multicore processors as well as on single
core processors with hyper-threading
enabled. So Intel came up with a fix for
this issue and was introduced in the
platform controller hub family of Intel
chipsets around 2008. And what they did
is, that they added a field in the BIOS
control register. And this field is called
SMM BIOS write protect disable. And the
name is a little bit misleading, but if
you remove disable, that's actually what
it does. And if this mechanism is
activated, there will be no other way to
write to the SPI, to the BIOS region of
the SPI flash memory, than if you don't
have all of the cores of your processor
running into SMM, meaning that the job of
writing to the SPI flash memory is now only
available to system management mode. And
once again the firmware must set this bit.
Otherwise this mechanism is not activated,
right. Okay so let's go back to
ReWriter_Binary. So of course if I talk
about all of these mechanisms it's because
ReWriter_Binary checks for them. So it
will check if the platform is properly
configured and it implements the exploit
for the race condition that I just spoke
about. So let's look at the writing
process decision tree. So the first thing
that it will look for is if BIOS write
enable is set, and if BIOS write enable is
set there, then there's nothing stopping
it from writing the UEFI image. But if it
is not set, then it will check "Oh, is
BIOS lock enable activated?". And this, if
this mechanism is not activated then it
will just flip BIOS write enable to 1, and
then it will write the UEFI image. But if
it is activated, the last thing it will
check for is "Is SMM BIOS write protect
set?". And if it is not set, then it will
exploit the race condition that we spoke
about. And if it is set, then the tool
will just fail. So the tool only works if
the platform is misconfigured. And we
spoke about SmiFlash, the vulnerable DXE
driver. So yeah, what we think is that by
being able to exploit this vulnerability,
they would have been able to have a tool
that works even when the platform is
properly configured. So it's a very good
example of; I mean if firmware vendors
would have done their job correctly here,
this tool would have failed at flashing
the UEFI firmware, so that's a great
example of how, you know, firmware
security is. So here let's just take a
step back and look at what we have. So
what we have is a software implementation
to flash the firmware remotely post
exploitation, meaning that as an attacker
I can, you know, infect my target the way
I usually do - let's say by sending a
phishing email. And once I have a foothold
in the machine, I can use this tool to
deploy the UEFI rootkit. And one we knew
about in the past was Hacking Team's UEFI
rootkit and it needed physical access to
be deployed. So it's so much more
convenient to be able to do it remotely.
And let's note here that there is no proof
of Hacking Team's rootkit being used in an
actual cyber attack. It has never been
found on a victim's machine or at least if
it had, it hasn't been publicly disclosed.
So what we did at this point is that we
extracted the UEFI rootkit from the tool
and we looked at ESET's UEFI scanner
telemetry to see if we can find something.
Turns out that we found the UEFI rootkit
in the SPI flash memory of a victim's
machine, making it the first publicly
known UEFI rootkit to be used in an actual
cyber attack. Okay.
So now let's look at the UEFI
rootkit itself. So the UEFI
rootkit is a DXE driver. So it is loaded
by the DXE dispatcher every time that the
machine will boot. Its file name is SecDxe
as we've seen earlier and here's the file
GUID for future reference. So let's look
at the UEFI rootkit workflow. So UEFI
firmware we'll go through multiple phases
when it boots. The first phase is the
security phase, the second one is the pre
EFI initialization phase, and then there
is the driver execution environment phase
and that's where it begins to be
interesting for this rootkit. So that's
where the DXE dispatcher lives. So that's
when all of the DXE drivers will be
loaded. So at some point the UEFI rootkit
will be loaded. And what will happen is
that the rootkit will create an event
attached to EFI GROUP_READY_TO_BOOT. And
it will bind a notify function to this
event. So in the next phase, when the boot
manager will run, at some point it will
signal this event and the notify function
will be called. So, the notify function
does 3 things. The first thing is that it
will install an NTFS driver. Then it will
drop autoche.exe and rpcnetp.exe using
this NTFS driver. And finally it will
patch a value in the Windows Registry. So,
the NTFS driver is needed to get file
based access to Windows partition and
Sednit's operator did not write their own
NTFS driver. What did it is that they use
Hacking Team's NTFS driver from Hacking
Team's leak. And, yeah, so here's the code
responsible for dropping the files. So as
we can see here, it is dropping
rpcnetp.exe and here it is dropping
autoche.exe. And the last step is to patch
the Windows Registry. So how it does that
is that it will open the file backing the
HKLM\SYSTEM Registry hive and it doesn't
have all the logic to parse Windows
Registry structures, so it will only look
for a textual pattern and the textual
pattern it will look for is "autocheck
autochk " and it will change it to
"autocheck autoche " and it happens to be
modifying the BootExecute key. So, the
BootExecute key is the key responsible for
launching autochk.exe during Windows early
boot. So by modifying it to autoche
instead of autochk that's autoche.exe that
will be executed instead of autochk. And,
so here if we go back to the UEFI rootkit
workflow, when the operating system will
run, then it will execute autoche.exe.
Then autoche.exe will drop the small
agent, the rpcnetp.exe, and so on. But
what's interesting here is that it will
revert back the modification in the
Windows Registry from autoche to autochk.
So that as a Windows user, for instance,
if I look in the Windows Registry, I won't
find that anything, any modification
occurred there. So that's a pretty
interesting sealth technique that is
enabled by the fact that the malware is
coming from the firmware. Okay. So, the
last thing that I want to talk about now
is prevention and remediation, so what can
you do to protect yourself against this
kind of attack? And if ever you were...
you find out that you had a UEFI rootkit in
your machine, what can you do? So,
prevention. So the first thing and the
most important thing, which is also the
most accessible thing, thankfully, is that
you should keep your UEFI firmware up to
date to make sure that if, you know,
security researchers found some issues
with your firmware and they disclosed it
and the firmware vendor fixed them, you
want to make sure that you have the latest
patches available on your machine. Then
the second thing is that you should really
enable Secure Boot. But let's note here
that Secure Boot itself would not
effectively you against this specific
attack. And the reason for that is that
Secure Boot takes the content of the SPI
flash memory as its root of trust, meaning
that what's inside the SPI flash memory is
not subject for validation. So what does
it validates then, right? Well, Secure
Boot will check what's coming from outside
of the SPI flash memory meanings the PCI
option ROMs and probably the most
important thing, the operating system
loader. So it's really a mechanism that
checks that the operating system loader
hasn't been tampered with. So what can we
do then, right? Well, what we need is a
hardware root of trust. So we need to move
the root of trust from the SPI flash
memory to some piece of hardware. So it
must be in a, you know, one time
programmable chip that is programmed
during manufacturing time and that cannot
be written to ever after. An example of
this exists - technology like Intel
BootGuard implements this. And also Apple
T2 security chip has a hardware root of
trust. And then you kind of need to hope
that your firmware configures the security
mechanisms properly and there's not much
you can do about it if your firmware is
up-to-date. But thankfully there are
firmware security assessment tool
available out there and an example of that
is Intel CHIPSEC. So, with Intel CHIPSEC
which is an open source software tool, so
you can just download this tool, put it in
an USB key, boot from it and then this
tool will check for all of the security
mechanism that we spoke about today, it
will check if they are properly configured
and also it checks for a bunch more stuff.
And now also CHIPSEC checks if your
firmware has this LoJax rootkit. So if you
want to know if your firmware properly
configures these security mechanism that's
really the way to go. Now about
remediation. So, this slide is kind of
short. And the reason for that is that if
you find out that you have a UEFI rootkit
in your SPI flash, there's not pretty much
you can do. You really need to re-flash
your UEFI firmware and that's definitely
not something that is easy to do for
anybody. And well, if it's not an option
for you, then you kind of need to get rid
of your motherboard or your laptop and get
a new one basically. So that's how serious
this kind of attack is. Now, conclusion.
So, our research shows that UEFI rootkits
are not only toys for researchers to play
with, but they are real world threats used
in actual cyber attacks. So it might be
something that you want to keep in mind
when you'll be defining your threat model.
Also we won't stress this enough: firmware
must be built with security in mind from
the bottom up, and things are getting
better because there are more and more
security researchers looking into this,
but there's still work to do. And
hopefully, our research help share
knowledge about how to prevent and
mitigate UEFI-based threats. So that is
pretty much it for me today. So thank you
for having me and if ever you're
interested to know more details about this
research, the white paper is available at
welivesecurity.com and you can grab a copy
there. So, thanks.
Applause
Herald: Alright, you know the drill. We
have 5 minutes for Q&A. So please, quick
and short questions. Number 1 please.
Question: (incomprehensible) attacking
other operating systems (incomprehensible)
Answer: In this case, well, that's kind of
the... pretty much the only one we're aware
of, apart from Hacking Team's UEFI
rootkit, and this one only works on
Windows, so we have no; we don't know
about any other that target's Linux or Mac
OS for instance.
Herald: Please refrain from walking in
front of the cameras when you're leaving.
Thank you.
Could we get microphone number
2 please.
Q: Hello, thanks for the talk. On your
slides you mentioned a tool, open source,
for checking out the layout. What was the
name of the tool?
A: It's called UEFI tool. Laughter
Q: Nice.
A: So you can find it on GitHub.
Q: Thanks.
Herald: The internet please.
Q: Thank you. Does the rootkit also work
when the UEFI is in BIOS legacy mode?
A: Uhm... That is a pretty good question.
I think it should, but I am not sure about
it. That's a good question, I'd have to
look into this, to have a... laughing an
answer I'm 100 percent sure about. Sorry
for that.
Herald: Microphone number 3 please. It's
you in the back, are you? No that's 4,
I'm sorry.
Q: OK. So, does the UEFI dropper still
work with BitLocker enabled?
A: I know. Oh yeah. Yeah. We test that.
No, it doesn't work if BitLocker is
enabled, so it doesn't wait for the... for
BitLocker to have decrypted all of the
data. So no, it doesn't work if
BitLocker is enabled.
Herald: Number 1 please.
Q: Would it be possible to work within
full disk encryption. (incomprehensible)
the file system was decrypted and then
installed the dropper.
A: I'm not sure I heard all of the
question, but if it works if there's full
disk encryption? Is it the question right?
Q: Would it be possible to make it work
with full disk encryption?
A: I think it should be because the LoJack
software is a legitimate one, the anti-
theft solution. They are able to make it
work even if BitLocker is enabled or full
disk encryption. So yeah, it should be
possible to do so.
Herald: One more internet question please.
Q: Thank you. What if a rootkit doesn't
fit in the SPI flash. Is filling up the
SPI flash space completely a valid
prevention?
A: No I don't know... we could really call
it a prevention mechanism. But yeah, if
there is not enough free space available
on the firmware volumes the tool will just fail.
Herald: Number two please.
Q: Hi. You said that there is no real
possibility to secure everything, but what
are your daily choices that you use like,
on your personal computer, to be fully
secret?
A: Well... laughing I could say an
alternative platform, but... laughter
but yeah, if you have
a modern Intel CPU and you have
Secure Boot enabled and you have, you
know, all of the latest UEFI firmware
updates, that's kind of the best you can
do to be safe for... against that kind of
attack.
Q: I have... I have my like this...
Herald: Number 1 please.
Q: So, going back to the LoJack
configuration file vulnerability. Is the
configuration file on the operating system
file system?
A: No no no, the... In fact it's... there is
not a separate configuration file, the
configuration is embedded inside the
executable. So it is embedded into
rpcnetp.exe.
Herald: Unfortunately, we are already out
of time. So please thank our speaker
again.
applause
postroll music
subtitles created by c3subtitles.de
in the year 2019. Join, and help us!