It's my pleasure to introduce you to our permanent guest, Zero Knights, Alex Matrosov.
With his report, we are betraying BIOS.
What's wrong with BIOS guards?
Let's give him a round of applause and listen to him.
It's my pleasure to introduce you to our permanent guest, Zero Knights, Alex Matrosov.
This report was already on BlackHat US this year, H2, and now on Zero Knights.
In fact, the main difference between these presentations is that in addition to the vulnerabilities in Intel BootGuard, there is now an implementation of the UEFI tool that can validate the configuration of the BootGuard and select segments that are not covered by Intel BootGuard.
We will talk about this today.
For those who are not familiar with me, a few words about me.
I have been involved in UEFI security for a long time and reverse engineering.
Before that, I worked for Intel.
Now I am the Head of Embedded Security at NVIDIA.
I have been engaged in reverse engineering for almost 20 years.
I am the co-author of the book called Rootkits & Bootkits.
It will be printed in January of next year.
All chapters will be available within two weeks.
They are ready.
We will start with the introduction of why BIOS attacks are important.
We will talk about BIOS updates.
BIOS updates are very important.
And how serious the situation is with various vendors.
After that, we will focus on Intel BootGuard.
We will talk about vulnerabilities that were found before.
And what my new research has brought in this direction.
We will also talk about Intel BIOS Guard.
And where to look further.
This is a small religious conclusion.
Why UEFI firmware is interesting from the point of view of implementation of rootkits.
The fact is that we used to have a loader that was loaded at the operating system level into the user mode.
And it acted as an installer.
The rootkit was already delivering it to the kernel mode level.
After a while, Microsoft began to worry that unregistered drivers were executed inside the kernel mode.
And it introduced sign-in policies.
This switched the focus from classic rootkits to bootkits.
And returned the era of file boot viruses.
After the implementation of Secure Boot UEFI was distributed.
This is around 2012-2013.
Accordingly, the bootkits were supposed to go back to the past.
But as practice shows, there are still companies and those who use Windows XP.
Nevertheless, for targeted attacks, I believe that SMM is a very interesting place where you can make a persistent rootkit.
SMM is System Management Mode.
In fact, in the last three years, all my reports were dedicated to BIOS.
I talked a lot about what System Management Mode is and why it is interesting.
In short, it is one of the most privileged modes in x86 processors and platforms.
If you have the opportunity to execute the code inside the SMM, you have access to physical memory.
Thus, you can parse everything that is there.
You can also find all the guests.
What does it mean?
If you attacked a server that performs cloud services, you can find everything that is in these guests.
If they are not protected in any way.
This is what I talked about.
The more mitigations we have, the more difficulties we have in the rootkits.
This is a vector that shows that modern rootkits are getting closer and closer to the hardware.
This is the truth in various directions, including embedded.
I took this graph from the presentation of Intel, which was on the blockade this year.
Interestingly, it shows a clear trend that the configuration bugs for hardware and firmware are increasing.
In general, this graph shows that with each year the number of various incidents on Intel products, which are related to UEFI and are also Intel products, is increasing.
And the number of incidents with configuration bugs is also increasing.
Not so long ago, Google released an interesting thing.
Google Titan chip, which protects the Root of Trust in hardware.
This chip is the Root of Trust for the system.
It also checks the consistency of all peripheral devices that we have on the platform.
We have already talked a lot about this, but what is interesting about the Titan chip.
By the way, it would be great to see it, but I was recently at the Microsoft BlueHat conference, and one of the Google employees promised to show me an empty chip without any configuration.
Just to look at it from the attacker's point of view.
If I manage to do this, I will definitely write about it somewhere and tell you if it is possible.
Or if I find something interesting.
But as it seems to me, especially for such large companies as Google, Microsoft, Amazon, this is a very important step.
Because how can you trust equipment that comes to you from an incomprehensible warehouse, and then you put this server in the rack, launch it, and expand your cloud on new computing capabilities.
And Supply Chain Attacks is not a new vector.
And as practice shows, it is very difficult to detect.
And everything that is in the BIOS and all threats to the BIOS are not in scope.
That is, you do not have antivirus software at this level.
You do not have tools for forensics.
You have practically nothing.
All that exists is a few tools in open source, which I have already discussed in the past years in my presentations.
And the first barrier for installing RootKit is signed BIOS updates.
And why should UEFI firmware bother us?
The fact is that in modern machines there are a large number of Intel Atom CPUs, which are also performed using UEFI firmware.
Also, UEFI is a huge ecosystem.
And there are manufacturers that make frameworks that are reused by other manufacturers.
For example, American Megatrends.
And now we do not have a BIOS legacy anywhere.
There is UEFI everywhere, but now there is a legacy inside UEFI.
And this means that even when you install a new BIOS, it does not mean that all components of this BIOS are updated, and they all correspond to the latest changes from the manufacturer.
It is also very interesting that a large number of other firmware is delivered with BIOS updates.
And as we can see, if you have an integrated network card on your laptop and in your system, if you have an integrated Intel graphics, then you always have something inside the firmware.
Either this is an update for the firmware of the graphics, or some other DXI drivers that interact with them.
Sensors.
Modern laptops have a large number of sensors that are updated with BIOS.
Embedded controller.
Also inside the BIOS image.
PMU is a power management unit.
In fact, I will not list them all, but I think you understand how many different firmwares are contained in the BIOS update.
If we do not have a correct BIOS image check, then this is the first step to attack something else.
The rest of the components can also interact with the BIOS.
This can be a multi-step attack, when the attacker attacks the embedded controller, and then from it he can make some kind of persistence, to be closer to the operating system and extract something interesting from it.
Today we will talk more about these components, i.e.
Boot Guard, BIOS Guard and ACM.
All vulnerabilities that were found in this report, are mainly related to the firmwares based on American Megatrends, and to the vendors of the following manufacturers.
These are Gigabyte, Asus Tech, Lenovo and MSI.
If we talk from the point of view of such primitive firmware protection methods from modification, then, of course, these are log bits, which, in fact, prohibit modifying the BIOS from the operating system level, and, accordingly, various bits that are responsible for write protection.
But also, if you notice, we have two groups of bits, i.e.
we have BIOS Control Bits and Flop Down Bits, i.e.
Spy Flash Write Protection.
Why are they divided into two different groups?
Because, roughly speaking, BIOS Control Bits can be modified when attacking the SMM, and there is no Spy Flash Policy.
But the problem is that not all manufacturers use the same thing, do not use both methods of BIOS protection, i.e.
either use only BIOS Control Bits, or partially use Spy Flash Bits.
And, in fact, PRXs, i.e.
Spy Flash Protection, can be set to specific regions only for reading or only for writing, and this is actually a very good thing, but for some reason it is not used by everyone.
And on the other hand, we have technologies that are developed by Intel, they are not documented, as a rule, only on the public, you can see a very high-level description, and we will talk about them in detail today, what I managed to find within the framework of reverse engineering.
These are the vulnerabilities that were found only for this report, there is nothing complicated, this is just, roughly speaking, the wrong configuration of the platform.
What Intel showed on its slides, saying that the number of such vulnerabilities increases every year.
These vulnerabilities are of exactly the same nature, I just did not indicate the platforms, almost all platforms of this manufacturer do not exist, that is, SpyFlashPolicies is not used.
I also found vulnerabilities related to unsigned images, and specifically with their parsing, with parsing of signed images, which allows us to bypass this.
These vulnerabilities are specifically in BootGuard, and how to bypass BootGuard with the method that I will show you today, can only be done with the use of two vulnerabilities.
If one of them is not present in the system, then this bypass method will not work.
In the process of research, I managed to compare various hardware of these vendors, which are listed on the left side.
And as we see, it would seem, many people believe that, for example, Apple hardware is better protected than everyone else.
Yes, the Apple Firmware Security team is quite strong, and they have great success in promoting and bringing Apple to one of the most protected platforms in terms of UEFI firmware, but nevertheless, they still have a lot to strive for.
And also, for example, they do not use Bioslock Enabled and SMM-BVP bits at all.
But they have slightly different methods of protection from attacks that are prevented by these bits, but they do not exist, which would seem very strange.
Also, we see that updates, the signature on the update of their BIOS is not checked, but the BIOS of vendors such as ASUSTEC, MSI and GIGABYTE.
Here is a good example.
This is one of the GIGABYTE platforms, on which we see that absolutely no protection in the configuration bits is installed.
That is, in fact, we do not care at all about how the BIOS is protected.
But in principle, you can understand these manufacturers, because the main tendency is that from the point of view of BIOS teams, these are very small teams that are primarily aimed at the release of new products to the market, not for security.
But the platform that I used for this research was certified for critical infrastructure in hospitals and various state structures, which, in fact, hints that it should be safe, but not quite so.
At BlackHat Asia, I showed a demo with UEFI ransomware, when, in fact, it was a POC for a remote attack.
That is, I installed this POC UEFI ransomware through a docx document, which, in principle, could arrive in the email, and then, accordingly, the vector was the following.
The problem was that we did not have a BIOS log, updates were not checked, and, in fact, we did not know that there was a vulnerability in one of the SMI handlers, which allowed us to deliver a harmful code.
If we speak from the point of view of such a blockchain, it looks like this.
We have a way to deliver updates from the operating system level.
Accordingly, as a rule, this method has some kind of KernelModDriver, which calls a special SMI handler, most often it is SMIFlash or SecureSMIFlash, and thus, accordingly, the update is delivered.
That is, our update driver relocates a special memory area of the update code, and then calls the SMI handler.
The SMI handler from this memory reads this update, and the next step is to check its signature, or just directly write the SPIFlash type.
Accordingly, I found some vulnerabilities in SMIFlash, but this driver is no longer used by many manufacturers, because it does not check the update signature.
But SecureSMIFlash is used, and it would seem that we have an SMIFlash driver, which is executed inside SMM, and which, accordingly, should check the updates.
But checking the update signature is not an easy task, or rather, it has several quite complex parsers.
And since there are complex parsers, as you understand, inside SMM we do not have ASCII LAR, we do not have DEP, and all this allows us, any small bug related to memory corruption, allows us to do code execution and raise the privileges to the SMM level.
Actually, what I managed to do.
These are the vulnerabilities I found in the SMIFlash driver on a specific platform.
And what upset me a little, the platform was released in January this year.
It was based on Kaby Lake.
Actually, it was Kaby Lake from Gigabyte, Kaby Lake from Lenovo and Kaby Lake from MSI.
I bought three for this research, and all of them upset me.
The SMIFlash security was vulnerable only to one vendor, ASUSTEC.
To be more precise, to a specific vulnerability.
I did not have much time to look at it, since my main target for this research was Intel BootGuard, and all the main time was spent on its research.
What does it mean in red?
These are the SMI handler numbers to call these functions, which are responsible for a secure update installation.
All these three SMI handler numbers allow you to increase the privileges to the SMM level when using a classic SMM callout attack, including on Kaby Lake.
Because of this, BIOSGuard was developed, which does not check SMM updates, but checks them in microcode and on some other levels.
A lot of vulnerabilities were found, but the problem is that Responsible Disclosure is always fun.
As we can see, many vendors do not quickly close the vulnerabilities, which would seem to just change one bit in the update.
Some vendors just say that there were no vulnerabilities.
And the funniest thing is that when I sent information about the vulnerabilities to Asustek in SecSMIFlash and others, they just ignored my answer.
They said that we received a letter, but then they just ignored my answer and released the update.
I thought it was not quite right.
I wrote about it on Twitter.
And then they sent me the following letter.
They said that the vulnerabilities that you found are really yours.
And yes, they are yours.
And that's it.
They didn't even apologize.
Well, this is a little bit about the fact that Responsible Disclosure is great, but not all vendors understand that the researcher spent time and sent the vulnerabilities for free.
He doesn't need all this pain with communicating with the vendor.
But, as I said, Asus is a well-known company, but they don't have a big security department that would process all this.
You can understand them, but I don't care.
Now let's switch to Intel BootGuard.
For this research, it was my main target.
I wonder why Intel BootGuard was invented.
The fact is that the first implementation of Secure Boot in UEFI has existed since 2012.
But the problem is that the verification of the trust chain in UEFI has always started with the Dixit level.
That is, from the level when, after its implementation, the management is transferred to the operating system loader.
And this is quite late.
And, so to speak, you can attack such an approach with any vulnerability inside SMM and BIOS.
After that, the implementation of BootGuard appeared, because Intel thought that it was necessary to somehow protect Secure Boot.
But, in fact, it did not get much spread in 2013.
And many vendors, in fact, had all the vPro systems on Core i7, which already had a pre-set function of BootGuard, but not all vendors activated it.
By the way, Sasha Yermolov talked about it last year at Zero Nights.
In fact, there are two modes of Intel BootGuard.
One of them is Measured Boot, the other is Verified Boot.
Measured Boot, so to speak, transfers the root of the trust to TPM.
And here is the same problem, that all the interaction from BIOS goes with TPM from DX drivers, and thus any SMM attack bypasses Measured Boot.
Verified Boot is a tougher mode, when we have, so to speak, the core of trust inside the hardware, it is Field Programming Fuse.
It is a once-programmed fuse, when the system developers have to sew specialized hashes into it, which I will talk about later, and no longer change it.
Thus, it turns out that we need to attack both hardware and firmware.
From the point of view of various hardware attacks, it is not very difficult to extract such a hash, but, so to speak, from the classical BIOS attacks, it changes the surface quite a lot.
Why was Boot Guard created?
We have already talked about it a little, but in fact, this scheme protects Secure Boot quite strongly, and in general, with other approaches, in fact, Boot Guard starts its execution from the Reset Vector, that is, before the BIOS starts to execute.
Thus, it turns out that the BIOS is verified at the early stages, and for Rootkit, in fact, it is much more difficult to get around all this.
But let's see how it was implemented.
The fact is that there is no good documentation from Intel on this matter, there is some very high-level description, this picture was taken from Vincent Zimmer's blog, and, in general, nothing is clear from it.
And today I will explain how it all works.
There is, accordingly, Boot Guard Flow, how it is loaded, as I said, and how the CPU Reset Vector starts, when we have a microcode checking the signature of the ACM.
ACM is Authenticated Compute Module.
As a rule, all ACMs related to Intel technologies are developed by Intel and signed, the same signature is checked in the microcode.
After that, the management is transferred, after the Intel ACM has been completed, it checks the initial loading stage of the Secure Boot, transfers it to the Soft Reset Vector, and after that we get the management of the so-called Initial Boot Guard,
IBB block, which checks the stage of Sec and Pay.
After that, they are executed, and we get the management of the classic Secure Boot at the level of Dixie.
It turns out that everything is authenticated before it, and if something is broken, or some unsigned Dixie driver is loaded, then the system will not be loaded to this level.
There are several modes of operation of the Intel Boot Guard, which I talked about, Measured Boot and Verified Boot, but as a rule, those vendors that really care about safety, they use the combined scheme Measured Boot plus Verified Boot.
Thus, they use the Field Programming Fuse, that is, it is locked in the hardware, but nevertheless, TPM is still used in some operating modes.
This scheme, again, is taken from Vincent Zimmer's blog, but to make it look a little clearer, I will tell you what is what.
Accordingly, it turns out that Field Programming Fuse, as Vincent says, is a policy check, which is done before the PA block starts.
In this case, before the PA block starts, there is an Initial Boot Block, which checks the integrity of these two levels.
And after that, by the way, the integrity of the Initial Boot Block is checked by ICM.
Thus, Chain of Trust looks like this, and this picture shows it.
As you remember, I said that in order to bypass the method that we will discuss now, Intel Boot Guard, two vulnerabilities are needed.
And here, in principle, it will be clear why.
The fact is that this part is locked in the hardware, that is, we have a management engine, which can read-write Field Programming Fuse.
That is, in order for us to re-write or modify the FPF, we need not to re-write it, but to program it.
You can't re-write it, it's one-time.
You need access to it, and to read-write.
Accordingly, all other policies are stored inside the firmware image.
That is, when I started looking at this technology, at the first approach and reversing, I thought, okay, if Field Programming Fuse is not used in the process of protection, or the vendor forgot to use it, but all other policies are configured, but since they are stored in the firmware image,
the attacker can change them and modify the FPF.
And thus fix the harmful firmware.
I'll tell you more about it later, but this is how the attacker works.
What's interesting, right before my presentation at Black Hat, Dell published this article about how they implemented their own Intel Boot Guard.
In principle, everything is the same, and this completely confirms what I did in my researches, which is nice, I was not mistaken.
Then I started looking at what different modes are used, and there are access modes for various vendors.
As we can see, in principle, access to EMEA is simply blocked for many.
But there is a GIGABYTE BRICS system, which is certified for various state agencies, for ATMs, hospitals, and for critical infrastructure.
And it has read-write enabled access.
There was also access to the embedded controller, but I will not talk about it in today's presentation.
There was also access, one-time programmable fuse was not installed, and BIOS Guard was not used.
That is, BIOS updates were checked only with the use of Secure SMI Flash.
In fact, the combination of Boot Guard and BIOS Guard significantly complicates this attack.
Thus, if BIOS Guard is not present, but Boot Guard is active, it is a little strange.
And again, you can see how it is done in Apple.
And we see that Apple does not use either Intel Boot Guard or Intel BIOS Guard.
And at the moment their Secure Boot is a little weaker without these schemes.
And I think they work on something more interesting and not sharpened for Intel.
We'll see.
But as they say, trust no one.
Because one thing is when the vendor says I use the technology, and another thing is how the vendor implemented this protection.
I already mentioned the presentation of Sasha Yermolov, which was last year.
He told that he found a platform which had the presence of Intel Boot Guard, but which did not use its presence in any way.
That is, it was not configured.
It was just empty.
The vendor did not launch it, but did not configure it.
Thus, a fraudster can simply insert a rootkit into the firmware and launch it inside the platform.
But, as they say, the attacker always looks at the implementation, not at the specification.
I decided that such problems can also exist in activated firmwares.
Actually, I started to look at how this data can be stored.
All these structures were extracted in the process of reverse engineering.
Thus, I managed to establish that almost the entire trust chain can be changed except for the hash which is stored in the FPF inside the firmware image.
I found parsers.
The fact is that there is a driver which verifies the trust chain of the Boot Guard from SMM.
I established most of these structures from it and found the sensitive places for the attack.
Here you can see that there is an IBBM hash, there is an OMRootPublicKey and, accordingly, a signature.
And this is a k-manifest.
We see that the Root of Trust is built in the following way.
We have an initialBootBlockManifest which depends on the k-manifest and the k-manifest, in turn, must be locked inside the FPF.
But, as practice shows, this is not always the case.
Thus, the Boot Policy Manifest looks like this.
Here, in fact, it is worth noting that we have an IBB hash as well as IBB offsets.
That is, we have a set of hashes and offsets.
These offsets determine which part of the firmware image these hashes cover.
And, in fact, the UFI tool, which I mentioned, was implemented specifically for this study.
It checks, so to speak, how well all the firmware volumes are covered.
If at least one driver is not covered, the attacker can use it to modify and attack.
Accordingly, with the help of the UFI tool, which is an open source tool, you can easily find the ECM module and extract all these policies and manifests.
After this Zero-Nice report, I will also add all the templates for 0.1 hex editor to my blockhat repository.
It will be possible to parse it all.
But, in principle, if you want to see these structures, they are already available in the UFI tool code.
I launched it just a few weeks ago.
It is all possible to find, because there is a documented fit, this is how the initial boot block looks like.
That is, there are hashes, the green ones are offset, the red ones are hashes.
It can be seen that I counted, when I was doing this screenshot, I did not have the UFI tool yet, which is now there and looks at everything, validates how well it is covered.
We see here that all the important firmwares are covered with volumes, and it will be difficult to attack such a firmware.
By the way, it was a Dell firmware.
Accordingly, in addition to everything else, it was interesting to see how the authentication code of ACM modules was checked , and how it looks.
That is, in fact, it is a binary blob, it has a header, and in this header there is an offset address of the input point, and there is a signature, which is checked by the microcode.
It was very interesting to see what we can do with ACM, what it is, and what checks are taking place inside it.
First of all, ACM is a 32-bit code for x86 platform, and the first question is, if it is executed, where is it?
In fact, the microcode loads ACM into cache and makes the cache non-invicted, that is, Intel calls this mode cache-as-ram or non-invicted mode, and executes this code inside this cache.
An interesting point is that ACM is in this address space all the time while the hardware is running until the next reboot, but it will most likely be loaded back into the same one.
By the way, addresses change quite rarely, they are hard-coded.
Also, an interesting point is that ACM checks k-manifest and IBBM-manifest and verifies them before sending them to BIOS management.
To make it more interesting to reverse, I made a CPU module for IDE, it is quite simple, Python script, just a loader.
This graph shows the connectivity of various basic blocks inside ACM.
As we can see, there is a lot of stuff.
If we look at the functions that are called from the input point, we see that we have get-k-manifest, get-ibb-manifest, and as we remember, there is a lot of stuff inside these structures.
At least there is a SHA-256 implementation inside ACM, a straight implementation, which in itself is quite a lot of C code, without any mitigation inside the cache, of course.
It is interesting to see what vulnerabilities could be there.
I thought, why not use bindif to compare ACM?
In fact, ACM is the same x86 code, and we can use bindif to compare it, because we can now load it into ID.
I compared different generations of processors, took Haswell vs.
Skylake, and took Broadwell vs.
Skylake, and for some reason, I was unlucky with Haswell, because it seems to me that...
By the way, here is an interesting point.
ACM may not be updated, even if we have the newest build state.
There may be an old version of ACM.
And most likely, on my platforms, the version of ACM was not completely updated.
It may not be the same as Haswell, but not the latest one.
That's why I didn't find a lot of differences.
I mean, I found just a little bit, which I didn't like.
And I thought, why not compare Broadwell?
And in this case, I was pretty lucky, because there were a lot of differences between Broadwell and Skylake.
And I thought, well, this is some new functionality, which is just different.
It turned out that, first of all, the implementation of ASN 1 parser, which was inside ACM, was changed, and the implementation of SHA-256 was also changed.
That is, there were several integer overflows, and they were patched, which is interesting.
But the problem is that it is quite difficult to attack vulnerabilities in ACM, because you cannot specifically replace ACM, since it is checked by a microcode signature.
But again, you can think in the direction of downgrade.
That is, we take an old vulnerable version, load it, plus, so to speak, for the audience to think, ACM is loaded all the time inside the cache.
That is, you can somehow get to it if you want to.
Now let's talk about what BootGuard components are present in the system.
That is, we have a SMM Verify BootGuard driver and I extracted all the main structures from it.
PEI is needed to check everything before loading.
PEI driver, SMM driver and Dixie driver are needed so that, for example, you do a reset and the system does not always reach, so to speak, a hard reset.
That is, there is a soft reset and it does not carry out a full cycle of iron loading.
And in this limited case, PEI is taken from the cache and just verifies that the Intel BootGuard chain was previously checked correctly.
And there is also SleepMode, which is interesting.
That is, when you go to S3, that is, SleepMode, there is a different driver that, as it turned out, contains vulnerabilities.
I'll tell you about it now.
Here is a pseudo-code in C language that shows how to check in BootGuard PEI.
And I advise you to pay attention to the block that is circled in red.
That is, it contains a logical error.
The logical error of the following image.
Because, in fact, the following happens.
The flag is set that Intel BootGuard was previously checked correctly.
And then, in the subsequent stages, this flag is checked.
Oh, Intel BootGuard is true.
And for BIOSes, for specific driver implementations, it means that Intel BootGuard configuration and verification are correct.
A very important point is the vendor hash without which, in fact, I had trouble for a week.
Because at first I thought that if I recalculate the entire initial boot block, everything will work for me.
But it turned out that there is another hash that had to be recalculated.
And it also covers the entire image.
Here is the information about Verify Firmware BootGuard, SMM Driver and Validation Flow.
Here, in fact, the algorithm is described as it is checked.
But a very interesting point is that from this SMM Driver there is a communication with IMEI interface and they go through HESI interface.
That is, through this interface the FPF hash is checked.
And if something is wrong, the status of EFI Security Evaluation is returned.
And we go back to what I said.
There was a logical mistake.
What is most interesting, I showed this slide at the BlackHat conference.
And after my presentation, a very famous vendor came up to me and said, you know, we patched this vulnerability just a week ago.
In fact, it was a zero-day for many vendors.
And now I will tell you why.
I wrote such a provocative title for this slide because, in fact, the problem is that we just check the flag on S3.
That is, if we, for example, attacked SMM, modified the driver or some code inside SMM in the current state of System Management Mode and went to sleep, returned from it and, so to speak, modified this flag in memory, then the system will think that everything is protected correctly,
Intel BootGuard Flow worked correctly.
That is, this check is, in fact, a return from sleep mode and a check for Intel BootGuard from there.
An interesting point is that, in fact, Sasha Ermolov also looked at the same place and he found the same implementation of the S3 check on Intel Nuki, this CVE.
And, in fact, the vulnerability is the same.
It is written in this blog and there are links to this study.
And I understand why.
Because this vulnerability was found in the American Megatrends BIOS implementation.
And so, in fact, all American Megatrends clients were almost subject to it.
Because few people change this code for Intel BootGuard.
In principle, they were unlikely to need it in most cases.
This is the platform that I attacked.
Here are the vulnerabilities described, what I was talking about.
Interestingly, these are the modes of Intel BootGuard.
And as we can see, Intel BootGuard is enabled with the most serious policies.
That is, Verified Boot plus Measured Boot.
And we also see that we have IMEI access.
If you look closely, there is also a DCI interface, about which Positive Technologies talked a lot, activated.
In fact, I could do the same.
In fact, I did it to debug some Dixie drivers.
In fact, here we see that the profile with the help of IMEI info tool is the most severe.
That is, Intel Measured Boot and Verified Boot.
This is a copy of a special site.
And this platform has various certifications for the government, hospitals, critical infrastructure.
As we can see, certification does not always correspond to reality.
Here are the steps that need to be taken to bypass BootGuard.
As I said, you need to recalculate all the manifests, replace all the keys with your own and change the hashes for IBB.
By the way, the hashes can not always be changed, because they should be protected by the signatures that exist.
It is necessary to look at the implementation of specific vendors, but such an attack allows you to modify the firmware, insert an implant into it and load it.
Moreover, if the FPF was not used, we can make a completely persistent implant that can not be updated to anyone except the malicious one.
That is, if you try to update, the system will not let you do it.
Most likely you will think, that the vendor has changed something and you will just forget about it.
But in fact, everything is much more complicated.
That is, if we do not have the root of trust locked hardware in the hardware, we can change all this well.
Here is the official Intel statement.
They say that we tell all vendors to lock, bla-bla-bla.
But the problem is that not all vendors follow everything that Intel says.
If they have the opportunity not to do it, they will try not to do it, as it complicates the production processes.
Many companies simply do not have the resources to follow all these policies.
And here is the statement from GIGABYTE.
As we can see, they said that they released a separate lock for IMEI as a separate tool.
In fact, this is not a fix inside the BIOS update, but you need to install a separate tool, launch it, and lock IMEI.
How many people will do it?
I think almost no one.
Even I did not do it.
I like my separate IMEI for my target platform.
Here are the links to the blog post that I wrote with some details of this attack.
And here is also a link to the UEFI tool, which validates the boot guard policy and shows you if there is a possibility of modification.
I probably won't have time to tell you anything interesting about BIOS guard, but there is not much information here.
All I can say is that BIOS guard was created to do armoring updates, and boot guard was created to do armoring secure boot.
It is worth noting that BIOS guard should be here.
These are the drivers used to implement BIOS guard inside the American Megatrends firmware.
Interestingly, there are much more drivers than in Intel boot guard.
In fact, I wanted to tell you about one vulnerability for Intel BIOS guard, but Intel hasn't patched it yet, so I can't tell you about it.
Here is a brief description of the flow and what Dixie drivers do.
But, as I said, I've been talking about boot guard for too long.
Interestingly, there are these Intel BIOS guard commands, and you should take a closer look at them, because these are also commands that are called in a special way, not like SMI handlers, but as you can see, inside SMM there is boot guard read, write and erase,
which is interesting.
This is the repository with the slides that you have seen today.
The slides are partially modified, but the main research was done for BlackHat this year.
I will also put all the templates for 0.1 editor and the loader for AIDA there.
Thank you for your attention.