1 00:00:04,710 --> 00:00:09,890 It's my pleasure to introduce you to our permanent guest, Zero Knights, Alex Matrosov. 2 00:00:09,890 --> 00:00:11,550 With his report, we are betraying BIOS. 3 00:00:11,550 --> 00:00:12,890 What's wrong with BIOS guards? 4 00:00:12,890 --> 00:00:14,950 Let's give him a round of applause and listen to him. 5 00:00:37,090 --> 00:01:00,370 It's my pleasure to introduce you to our permanent guest, Zero Knights, Alex Matrosov. 6 00:01:00,510 --> 00:01:07,070 It's my pleasure to introduce you to our permanent guest, Zero Knights, Alex Matrosov. 7 00:01:07,070 --> 00:01:13,410 This report was already on BlackHat US this year, H2, and now on Zero Knights. 8 00:01:14,170 --> 00:01:36,230 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. 9 00:01:36,230 --> 00:01:38,170 We will talk about this today. 10 00:01:38,170 --> 00:01:42,990 For those who are not familiar with me, a few words about me. 11 00:01:43,030 --> 00:01:47,750 I have been involved in UEFI security for a long time and reverse engineering. 12 00:01:47,750 --> 00:01:50,350 Before that, I worked for Intel. 13 00:01:50,350 --> 00:01:54,540 Now I am the Head of Embedded Security at NVIDIA. 14 00:01:56,090 --> 00:02:00,870 I have been engaged in reverse engineering for almost 20 years. 15 00:02:00,870 --> 00:02:05,010 I am the co-author of the book called Rootkits & Bootkits. 16 00:02:05,090 --> 00:02:10,250 It will be printed in January of next year. 17 00:02:10,570 --> 00:02:16,810 All chapters will be available within two weeks. 18 00:02:16,830 --> 00:02:18,810 They are ready. 19 00:02:21,480 --> 00:02:27,500 We will start with the introduction of why BIOS attacks are important. 20 00:02:29,640 --> 00:02:34,420 We will talk about BIOS updates. 21 00:02:34,760 --> 00:02:37,680 BIOS updates are very important. 22 00:02:37,680 --> 00:02:42,280 And how serious the situation is with various vendors. 23 00:02:42,580 --> 00:02:45,880 After that, we will focus on Intel BootGuard. 24 00:02:45,880 --> 00:02:48,800 We will talk about vulnerabilities that were found before. 25 00:02:48,800 --> 00:02:54,460 And what my new research has brought in this direction. 26 00:02:54,460 --> 00:02:58,480 We will also talk about Intel BIOS Guard. 27 00:02:58,480 --> 00:03:00,790 And where to look further. 28 00:03:02,540 --> 00:03:05,060 This is a small religious conclusion. 29 00:03:05,060 --> 00:03:12,940 Why UEFI firmware is interesting from the point of view of implementation of rootkits. 30 00:03:13,160 --> 00:03:20,800 The fact is that we used to have a loader that was loaded at the operating system level into the user mode. 31 00:03:20,800 --> 00:03:24,120 And it acted as an installer. 32 00:03:24,540 --> 00:03:30,120 The rootkit was already delivering it to the kernel mode level. 33 00:03:31,060 --> 00:03:38,920 After a while, Microsoft began to worry that unregistered drivers were executed inside the kernel mode. 34 00:03:38,920 --> 00:03:40,960 And it introduced sign-in policies. 35 00:03:40,960 --> 00:03:47,040 This switched the focus from classic rootkits to bootkits. 36 00:03:47,040 --> 00:03:51,860 And returned the era of file boot viruses. 37 00:03:53,700 --> 00:03:59,100 After the implementation of Secure Boot UEFI was distributed. 38 00:03:59,100 --> 00:04:02,280 This is around 2012-2013. 39 00:04:03,960 --> 00:04:07,460 Accordingly, the bootkits were supposed to go back to the past. 40 00:04:07,460 --> 00:04:13,300 But as practice shows, there are still companies and those who use Windows XP. 41 00:04:13,300 --> 00:04:25,320 Nevertheless, for targeted attacks, I believe that SMM is a very interesting place where you can make a persistent rootkit. 42 00:04:26,660 --> 00:04:29,060 SMM is System Management Mode. 43 00:04:29,120 --> 00:04:33,260 In fact, in the last three years, all my reports were dedicated to BIOS. 44 00:04:33,260 --> 00:04:37,320 I talked a lot about what System Management Mode is and why it is interesting. 45 00:04:37,320 --> 00:04:50,620 In short, it is one of the most privileged modes in x86 processors and platforms. 46 00:04:53,260 --> 00:04:59,660 If you have the opportunity to execute the code inside the SMM, you have access to physical memory. 47 00:04:59,660 --> 00:05:04,220 Thus, you can parse everything that is there. 48 00:05:04,220 --> 00:05:06,800 You can also find all the guests. 49 00:05:06,800 --> 00:05:07,500 What does it mean? 50 00:05:07,500 --> 00:05:20,980 If you attacked a server that performs cloud services, you can find everything that is in these guests. 51 00:05:21,140 --> 00:05:22,760 If they are not protected in any way. 52 00:05:22,860 --> 00:05:25,300 This is what I talked about. 53 00:05:25,320 --> 00:05:33,480 The more mitigations we have, the more difficulties we have in the rootkits. 54 00:05:33,480 --> 00:05:41,320 This is a vector that shows that modern rootkits are getting closer and closer to the hardware. 55 00:05:41,320 --> 00:05:45,260 This is the truth in various directions, including embedded. 56 00:05:47,620 --> 00:05:55,480 I took this graph from the presentation of Intel, which was on the blockade this year. 57 00:05:56,420 --> 00:06:07,640 Interestingly, it shows a clear trend that the configuration bugs for hardware and firmware are increasing. 58 00:06:07,640 --> 00:06:26,020 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. 59 00:06:26,020 --> 00:06:31,900 And the number of incidents with configuration bugs is also increasing. 60 00:06:32,780 --> 00:06:37,780 Not so long ago, Google released an interesting thing. 61 00:06:37,780 --> 00:06:47,200 Google Titan chip, which protects the Root of Trust in hardware. 62 00:06:49,380 --> 00:06:55,680 This chip is the Root of Trust for the system. 63 00:06:55,680 --> 00:07:05,360 It also checks the consistency of all peripheral devices that we have on the platform. 64 00:07:05,540 --> 00:07:12,680 We have already talked a lot about this, but what is interesting about the Titan chip. 65 00:07:13,080 --> 00:07:25,660 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. 66 00:07:25,660 --> 00:07:28,180 Just to look at it from the attacker's point of view. 67 00:07:28,180 --> 00:07:37,200 If I manage to do this, I will definitely write about it somewhere and tell you if it is possible. 68 00:07:38,460 --> 00:07:41,080 Or if I find something interesting. 69 00:07:41,080 --> 00:07:48,340 But as it seems to me, especially for such large companies as Google, Microsoft, Amazon, this is a very important step. 70 00:07:48,340 --> 00:08:02,620 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. 71 00:08:02,620 --> 00:08:08,040 And Supply Chain Attacks is not a new vector. 72 00:08:08,120 --> 00:08:14,580 And as practice shows, it is very difficult to detect. 73 00:08:15,400 --> 00:08:21,880 And everything that is in the BIOS and all threats to the BIOS are not in scope. 74 00:08:21,880 --> 00:08:25,960 That is, you do not have antivirus software at this level. 75 00:08:25,960 --> 00:08:27,760 You do not have tools for forensics. 76 00:08:27,760 --> 00:08:30,240 You have practically nothing. 77 00:08:30,240 --> 00:08:37,580 All that exists is a few tools in open source, which I have already discussed in the past years in my presentations. 78 00:08:38,540 --> 00:08:50,440 And the first barrier for installing RootKit is signed BIOS updates. 79 00:08:50,440 --> 00:08:55,860 And why should UEFI firmware bother us? 80 00:08:55,860 --> 00:09:16,720 The fact is that in modern machines there are a large number of Intel Atom CPUs, which are also performed using UEFI firmware. 81 00:09:17,660 --> 00:09:23,180 Also, UEFI is a huge ecosystem. 82 00:09:23,260 --> 00:09:28,880 And there are manufacturers that make frameworks that are reused by other manufacturers. 83 00:09:28,880 --> 00:09:30,920 For example, American Megatrends. 84 00:09:30,920 --> 00:09:36,240 And now we do not have a BIOS legacy anywhere. 85 00:09:36,240 --> 00:09:39,900 There is UEFI everywhere, but now there is a legacy inside UEFI. 86 00:09:39,900 --> 00:09:57,120 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. 87 00:09:57,120 --> 00:10:08,120 It is also very interesting that a large number of other firmware is delivered with BIOS updates. 88 00:10:08,120 --> 00:10:21,280 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. 89 00:10:22,060 --> 00:10:27,980 Either this is an update for the firmware of the graphics, or some other DXI drivers that interact with them. 90 00:10:28,020 --> 00:10:29,420 Sensors. 91 00:10:29,820 --> 00:10:37,100 Modern laptops have a large number of sensors that are updated with BIOS. 92 00:10:37,100 --> 00:10:38,980 Embedded controller. 93 00:10:39,480 --> 00:10:43,500 Also inside the BIOS image. 94 00:10:44,340 --> 00:10:46,940 PMU is a power management unit. 95 00:10:47,660 --> 00:10:55,920 In fact, I will not list them all, but I think you understand how many different firmwares are contained in the BIOS update. 96 00:10:57,440 --> 00:11:06,320 If we do not have a correct BIOS image check, then this is the first step to attack something else. 97 00:11:06,320 --> 00:11:10,640 The rest of the components can also interact with the BIOS. 98 00:11:10,640 --> 00:11:23,480 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. 99 00:11:25,460 --> 00:11:30,020 Today we will talk more about these components, i.e. 100 00:11:30,020 --> 00:11:33,320 Boot Guard, BIOS Guard and ACM. 101 00:11:35,140 --> 00:11:47,380 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. 102 00:11:47,380 --> 00:11:50,450 These are Gigabyte, Asus Tech, Lenovo and MSI. 103 00:11:52,400 --> 00:12:16,380 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. 104 00:12:17,060 --> 00:12:20,880 But also, if you notice, we have two groups of bits, i.e. 105 00:12:20,880 --> 00:12:27,040 we have BIOS Control Bits and Flop Down Bits, i.e. 106 00:12:27,040 --> 00:12:29,100 Spy Flash Write Protection. 107 00:12:29,100 --> 00:12:31,520 Why are they divided into two different groups? 108 00:12:31,520 --> 00:12:42,100 Because, roughly speaking, BIOS Control Bits can be modified when attacking the SMM, and there is no Spy Flash Policy. 109 00:12:42,120 --> 00:12:51,900 But the problem is that not all manufacturers use the same thing, do not use both methods of BIOS protection, i.e. 110 00:12:51,900 --> 00:12:57,640 either use only BIOS Control Bits, or partially use Spy Flash Bits. 111 00:12:57,640 --> 00:12:59,620 And, in fact, PRXs, i.e. 112 00:12:59,620 --> 00:13:08,780 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. 113 00:13:09,120 --> 00:13:24,000 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. 114 00:13:27,200 --> 00:13:35,140 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. 115 00:13:35,260 --> 00:13:42,620 What Intel showed on its slides, saying that the number of such vulnerabilities increases every year. 116 00:13:43,940 --> 00:13:54,180 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. 117 00:13:55,000 --> 00:14:06,740 I also found vulnerabilities related to unsigned images, and specifically with their parsing, with parsing of signed images, which allows us to bypass this. 118 00:14:07,000 --> 00:14:17,420 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. 119 00:14:17,420 --> 00:14:22,400 If one of them is not present in the system, then this bypass method will not work. 120 00:14:23,520 --> 00:14:31,040 In the process of research, I managed to compare various hardware of these vendors, which are listed on the left side. 121 00:14:31,280 --> 00:14:38,020 And as we see, it would seem, many people believe that, for example, Apple hardware is better protected than everyone else. 122 00:14:38,020 --> 00:14:52,720 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. 123 00:14:52,720 --> 00:14:59,160 And also, for example, they do not use Bioslock Enabled and SMM-BVP bits at all. 124 00:14:59,160 --> 00:15:07,880 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. 125 00:15:08,560 --> 00:15:19,220 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. 126 00:15:20,340 --> 00:15:22,460 Here is a good example. 127 00:15:22,480 --> 00:15:31,300 This is one of the GIGABYTE platforms, on which we see that absolutely no protection in the configuration bits is installed. 128 00:15:31,300 --> 00:15:36,980 That is, in fact, we do not care at all about how the BIOS is protected. 129 00:15:36,980 --> 00:15:50,740 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. 130 00:15:50,740 --> 00:16:11,060 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. 131 00:16:13,040 --> 00:16:23,480 At BlackHat Asia, I showed a demo with UEFI ransomware, when, in fact, it was a POC for a remote attack. 132 00:16:23,480 --> 00:16:34,740 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. 133 00:16:34,740 --> 00:16:49,120 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. 134 00:16:49,640 --> 00:16:53,820 If we speak from the point of view of such a blockchain, it looks like this. 135 00:16:53,820 --> 00:17:00,280 We have a way to deliver updates from the operating system level. 136 00:17:00,500 --> 00:17:12,840 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. 137 00:17:12,840 --> 00:17:25,280 That is, our update driver relocates a special memory area of the update code, and then calls the SMI handler. 138 00:17:25,280 --> 00:17:35,040 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. 139 00:17:37,830 --> 00:17:50,270 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. 140 00:17:50,270 --> 00:18:01,790 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. 141 00:18:01,790 --> 00:18:11,410 But checking the update signature is not an easy task, or rather, it has several quite complex parsers. 142 00:18:11,410 --> 00:18:33,350 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. 143 00:18:33,850 --> 00:18:36,910 Actually, what I managed to do. 144 00:18:36,910 --> 00:18:42,250 These are the vulnerabilities I found in the SMIFlash driver on a specific platform. 145 00:18:42,250 --> 00:18:47,350 And what upset me a little, the platform was released in January this year. 146 00:18:47,410 --> 00:18:49,770 It was based on Kaby Lake. 147 00:18:50,830 --> 00:18:56,790 Actually, it was Kaby Lake from Gigabyte, Kaby Lake from Lenovo and Kaby Lake from MSI. 148 00:18:56,790 --> 00:19:01,290 I bought three for this research, and all of them upset me. 149 00:19:04,330 --> 00:19:09,410 The SMIFlash security was vulnerable only to one vendor, ASUSTEC. 150 00:19:09,410 --> 00:19:11,630 To be more precise, to a specific vulnerability. 151 00:19:11,630 --> 00:19:21,870 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. 152 00:19:21,870 --> 00:19:24,990 What does it mean in red? 153 00:19:25,310 --> 00:19:33,690 These are the SMI handler numbers to call these functions, which are responsible for a secure update installation. 154 00:19:34,290 --> 00:19:46,590 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. 155 00:19:48,830 --> 00:20:02,850 Because of this, BIOSGuard was developed, which does not check SMM updates, but checks them in microcode and on some other levels. 156 00:20:06,940 --> 00:20:14,240 A lot of vulnerabilities were found, but the problem is that Responsible Disclosure is always fun. 157 00:20:15,260 --> 00:20:24,120 As we can see, many vendors do not quickly close the vulnerabilities, which would seem to just change one bit in the update. 158 00:20:25,380 --> 00:20:29,300 Some vendors just say that there were no vulnerabilities. 159 00:20:29,940 --> 00:20:40,560 And the funniest thing is that when I sent information about the vulnerabilities to Asustek in SecSMIFlash and others, they just ignored my answer. 160 00:20:40,560 --> 00:20:45,560 They said that we received a letter, but then they just ignored my answer and released the update. 161 00:20:45,560 --> 00:20:48,020 I thought it was not quite right. 162 00:20:49,520 --> 00:20:51,660 I wrote about it on Twitter. 163 00:20:52,420 --> 00:20:56,000 And then they sent me the following letter. 164 00:20:58,750 --> 00:21:04,130 They said that the vulnerabilities that you found are really yours. 165 00:21:04,330 --> 00:21:05,990 And yes, they are yours. 166 00:21:05,990 --> 00:21:06,490 And that's it. 167 00:21:06,490 --> 00:21:07,830 They didn't even apologize. 168 00:21:09,890 --> 00:21:23,610 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. 169 00:21:23,610 --> 00:21:29,930 He doesn't need all this pain with communicating with the vendor. 170 00:21:30,190 --> 00:21:39,830 But, as I said, Asus is a well-known company, but they don't have a big security department that would process all this. 171 00:21:39,830 --> 00:21:43,790 You can understand them, but I don't care. 172 00:21:45,890 --> 00:21:49,390 Now let's switch to Intel BootGuard. 173 00:21:49,530 --> 00:21:52,870 For this research, it was my main target. 174 00:21:53,710 --> 00:21:58,750 I wonder why Intel BootGuard was invented. 175 00:21:58,750 --> 00:22:05,490 The fact is that the first implementation of Secure Boot in UEFI has existed since 2012. 176 00:22:05,570 --> 00:22:13,310 But the problem is that the verification of the trust chain in UEFI has always started with the Dixit level. 177 00:22:13,310 --> 00:22:21,670 That is, from the level when, after its implementation, the management is transferred to the operating system loader. 178 00:22:21,670 --> 00:22:23,570 And this is quite late. 179 00:22:23,570 --> 00:22:33,750 And, so to speak, you can attack such an approach with any vulnerability inside SMM and BIOS. 180 00:22:33,770 --> 00:22:41,610 After that, the implementation of BootGuard appeared, because Intel thought that it was necessary to somehow protect Secure Boot. 181 00:22:42,230 --> 00:22:47,430 But, in fact, it did not get much spread in 2013. 182 00:22:47,430 --> 00:22:58,610 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. 183 00:22:59,070 --> 00:23:04,770 By the way, Sasha Yermolov talked about it last year at Zero Nights. 184 00:23:04,850 --> 00:23:09,410 In fact, there are two modes of Intel BootGuard. 185 00:23:09,410 --> 00:23:12,130 One of them is Measured Boot, the other is Verified Boot. 186 00:23:12,850 --> 00:23:19,390 Measured Boot, so to speak, transfers the root of the trust to TPM. 187 00:23:19,390 --> 00:23:35,110 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. 188 00:23:35,110 --> 00:23:43,750 Verified Boot is a tougher mode, when we have, so to speak, the core of trust inside the hardware, it is Field Programming Fuse. 189 00:23:46,150 --> 00:23:58,490 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. 190 00:23:59,250 --> 00:24:05,550 Thus, it turns out that we need to attack both hardware and firmware. 191 00:24:05,710 --> 00:24:17,490 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. 192 00:24:21,390 --> 00:24:26,130 Why was Boot Guard created? 193 00:24:26,130 --> 00:24:51,710 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. 194 00:24:51,710 --> 00:25:02,510 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. 195 00:25:02,510 --> 00:25:06,130 But let's see how it was implemented. 196 00:25:06,130 --> 00:25:23,490 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. 197 00:25:23,550 --> 00:25:25,970 And today I will explain how it all works. 198 00:25:26,590 --> 00:25:39,950 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. 199 00:25:39,950 --> 00:25:42,330 ACM is Authenticated Compute Module. 200 00:25:42,330 --> 00:25:49,450 As a rule, all ACMs related to Intel technologies are developed by Intel and signed, the same signature is checked in the microcode. 201 00:25:49,450 --> 00:26:08,790 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, 202 00:26:08,790 --> 00:26:12,150 IBB block, which checks the stage of Sec and Pay. 203 00:26:12,610 --> 00:26:18,050 After that, they are executed, and we get the management of the classic Secure Boot at the level of Dixie. 204 00:26:18,050 --> 00:26:33,890 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. 205 00:26:37,040 --> 00:26:51,740 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. 206 00:26:52,180 --> 00:27:05,340 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. 207 00:27:07,420 --> 00:27:18,020 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. 208 00:27:18,060 --> 00:27:30,460 Accordingly, it turns out that Field Programming Fuse, as Vincent says, is a policy check, which is done before the PA block starts. 209 00:27:30,460 --> 00:27:38,180 In this case, before the PA block starts, there is an Initial Boot Block, which checks the integrity of these two levels. 210 00:27:38,180 --> 00:27:45,240 And after that, by the way, the integrity of the Initial Boot Block is checked by ICM. 211 00:27:46,100 --> 00:27:54,540 Thus, Chain of Trust looks like this, and this picture shows it. 212 00:27:55,500 --> 00:28:04,540 As you remember, I said that in order to bypass the method that we will discuss now, Intel Boot Guard, two vulnerabilities are needed. 213 00:28:04,540 --> 00:28:07,000 And here, in principle, it will be clear why. 214 00:28:07,420 --> 00:28:16,400 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. 215 00:28:17,040 --> 00:28:24,800 That is, in order for us to re-write or modify the FPF, we need not to re-write it, but to program it. 216 00:28:24,800 --> 00:28:26,700 You can't re-write it, it's one-time. 217 00:28:27,760 --> 00:28:31,780 You need access to it, and to read-write. 218 00:28:33,880 --> 00:28:37,440 Accordingly, all other policies are stored inside the firmware image. 219 00:28:37,460 --> 00:28:56,540 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, 220 00:28:56,540 --> 00:29:01,180 the attacker can change them and modify the FPF. 221 00:29:01,180 --> 00:29:04,360 And thus fix the harmful firmware. 222 00:29:04,360 --> 00:29:10,360 I'll tell you more about it later, but this is how the attacker works. 223 00:29:12,300 --> 00:29:27,000 What's interesting, right before my presentation at Black Hat, Dell published this article about how they implemented their own Intel Boot Guard. 224 00:29:27,000 --> 00:29:35,940 In principle, everything is the same, and this completely confirms what I did in my researches, which is nice, I was not mistaken. 225 00:29:37,680 --> 00:29:46,280 Then I started looking at what different modes are used, and there are access modes for various vendors. 226 00:29:46,340 --> 00:29:51,660 As we can see, in principle, access to EMEA is simply blocked for many. 227 00:29:51,660 --> 00:30:04,980 But there is a GIGABYTE BRICS system, which is certified for various state agencies, for ATMs, hospitals, and for critical infrastructure. 228 00:30:04,980 --> 00:30:08,340 And it has read-write enabled access. 229 00:30:08,340 --> 00:30:15,460 There was also access to the embedded controller, but I will not talk about it in today's presentation. 230 00:30:17,240 --> 00:30:26,600 There was also access, one-time programmable fuse was not installed, and BIOS Guard was not used. 231 00:30:26,740 --> 00:30:30,620 That is, BIOS updates were checked only with the use of Secure SMI Flash. 232 00:30:31,440 --> 00:30:39,360 In fact, the combination of Boot Guard and BIOS Guard significantly complicates this attack. 233 00:30:40,380 --> 00:30:46,780 Thus, if BIOS Guard is not present, but Boot Guard is active, it is a little strange. 234 00:30:48,660 --> 00:30:53,220 And again, you can see how it is done in Apple. 235 00:30:53,220 --> 00:30:57,920 And we see that Apple does not use either Intel Boot Guard or Intel BIOS Guard. 236 00:30:57,920 --> 00:31:03,780 And at the moment their Secure Boot is a little weaker without these schemes. 237 00:31:04,020 --> 00:31:10,320 And I think they work on something more interesting and not sharpened for Intel. 238 00:31:10,320 --> 00:31:11,420 We'll see. 239 00:31:12,640 --> 00:31:15,500 But as they say, trust no one. 240 00:31:15,500 --> 00:31:24,060 Because one thing is when the vendor says I use the technology, and another thing is how the vendor implemented this protection. 241 00:31:24,200 --> 00:31:29,420 I already mentioned the presentation of Sasha Yermolov, which was last year. 242 00:31:29,460 --> 00:31:42,760 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. 243 00:31:43,560 --> 00:31:45,220 That is, it was not configured. 244 00:31:45,220 --> 00:31:45,960 It was just empty. 245 00:31:45,960 --> 00:31:49,400 The vendor did not launch it, but did not configure it. 246 00:31:49,400 --> 00:31:58,980 Thus, a fraudster can simply insert a rootkit into the firmware and launch it inside the platform. 247 00:32:02,040 --> 00:32:08,880 But, as they say, the attacker always looks at the implementation, not at the specification. 248 00:32:08,880 --> 00:32:14,720 I decided that such problems can also exist in activated firmwares. 249 00:32:14,720 --> 00:32:22,040 Actually, I started to look at how this data can be stored. 250 00:32:22,120 --> 00:32:28,560 All these structures were extracted in the process of reverse engineering. 251 00:32:28,740 --> 00:32:38,980 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. 252 00:32:39,900 --> 00:32:42,980 I found parsers. 253 00:32:42,980 --> 00:32:51,220 The fact is that there is a driver which verifies the trust chain of the Boot Guard from SMM. 254 00:32:51,220 --> 00:33:01,740 I established most of these structures from it and found the sensitive places for the attack. 255 00:33:03,040 --> 00:33:09,780 Here you can see that there is an IBBM hash, there is an OMRootPublicKey and, accordingly, a signature. 256 00:33:11,160 --> 00:33:13,120 And this is a k-manifest. 257 00:33:14,120 --> 00:33:17,580 We see that the Root of Trust is built in the following way. 258 00:33:17,580 --> 00:33:26,500 We have an initialBootBlockManifest which depends on the k-manifest and the k-manifest, in turn, must be locked inside the FPF. 259 00:33:26,500 --> 00:33:29,820 But, as practice shows, this is not always the case. 260 00:33:31,580 --> 00:33:36,420 Thus, the Boot Policy Manifest looks like this. 261 00:33:36,420 --> 00:33:44,420 Here, in fact, it is worth noting that we have an IBB hash as well as IBB offsets. 262 00:33:44,420 --> 00:33:48,520 That is, we have a set of hashes and offsets. 263 00:33:48,520 --> 00:33:55,360 These offsets determine which part of the firmware image these hashes cover. 264 00:33:55,500 --> 00:34:00,120 And, in fact, the UFI tool, which I mentioned, was implemented specifically for this study. 265 00:34:00,680 --> 00:34:06,200 It checks, so to speak, how well all the firmware volumes are covered. 266 00:34:06,200 --> 00:34:12,400 If at least one driver is not covered, the attacker can use it to modify and attack. 267 00:34:16,330 --> 00:34:26,330 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. 268 00:34:26,330 --> 00:34:36,190 After this Zero-Nice report, I will also add all the templates for 0.1 hex editor to my blockhat repository. 269 00:34:36,710 --> 00:34:38,430 It will be possible to parse it all. 270 00:34:38,770 --> 00:34:45,370 But, in principle, if you want to see these structures, they are already available in the UFI tool code. 271 00:34:45,370 --> 00:34:48,770 I launched it just a few weeks ago. 272 00:34:49,450 --> 00:34:59,550 It is all possible to find, because there is a documented fit, this is how the initial boot block looks like. 273 00:34:59,550 --> 00:35:05,810 That is, there are hashes, the green ones are offset, the red ones are hashes. 274 00:35:06,190 --> 00:35:17,070 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. 275 00:35:17,070 --> 00:35:24,190 We see here that all the important firmwares are covered with volumes, and it will be difficult to attack such a firmware. 276 00:35:27,110 --> 00:35:29,470 By the way, it was a Dell firmware. 277 00:35:32,030 --> 00:35:44,750 Accordingly, in addition to everything else, it was interesting to see how the authentication code of ACM modules was checked , and how it looks. 278 00:35:44,750 --> 00:35:59,670 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. 279 00:36:03,490 --> 00:36:16,610 It was very interesting to see what we can do with ACM, what it is, and what checks are taking place inside it. 280 00:36:16,610 --> 00:36:26,110 First of all, ACM is a 32-bit code for x86 platform, and the first question is, if it is executed, where is it? 281 00:36:26,170 --> 00:36:42,170 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. 282 00:36:42,450 --> 00:36:55,030 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. 283 00:36:55,030 --> 00:36:59,610 By the way, addresses change quite rarely, they are hard-coded. 284 00:37:03,110 --> 00:37:15,230 Also, an interesting point is that ACM checks k-manifest and IBBM-manifest and verifies them before sending them to BIOS management. 285 00:37:17,110 --> 00:37:26,630 To make it more interesting to reverse, I made a CPU module for IDE, it is quite simple, Python script, just a loader. 286 00:37:30,070 --> 00:37:35,990 This graph shows the connectivity of various basic blocks inside ACM. 287 00:37:35,990 --> 00:37:38,210 As we can see, there is a lot of stuff. 288 00:37:40,210 --> 00:37:53,210 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. 289 00:37:53,210 --> 00:38:11,290 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. 290 00:38:11,290 --> 00:38:14,710 It is interesting to see what vulnerabilities could be there. 291 00:38:15,090 --> 00:38:21,170 I thought, why not use bindif to compare ACM? 292 00:38:21,170 --> 00:38:32,030 In fact, ACM is the same x86 code, and we can use bindif to compare it, because we can now load it into ID. 293 00:38:32,030 --> 00:38:38,490 I compared different generations of processors, took Haswell vs. 294 00:38:38,490 --> 00:38:42,070 Skylake, and took Broadwell vs. 295 00:38:42,070 --> 00:38:48,030 Skylake, and for some reason, I was unlucky with Haswell, because it seems to me that... 296 00:38:48,030 --> 00:38:50,190 By the way, here is an interesting point. 297 00:38:52,430 --> 00:38:56,850 ACM may not be updated, even if we have the newest build state. 298 00:38:56,850 --> 00:38:59,190 There may be an old version of ACM. 299 00:38:59,190 --> 00:39:04,010 And most likely, on my platforms, the version of ACM was not completely updated. 300 00:39:04,010 --> 00:39:07,810 It may not be the same as Haswell, but not the latest one. 301 00:39:07,810 --> 00:39:10,290 That's why I didn't find a lot of differences. 302 00:39:10,290 --> 00:39:15,470 I mean, I found just a little bit, which I didn't like. 303 00:39:16,210 --> 00:39:19,750 And I thought, why not compare Broadwell? 304 00:39:19,750 --> 00:39:27,250 And in this case, I was pretty lucky, because there were a lot of differences between Broadwell and Skylake. 305 00:39:27,250 --> 00:39:31,290 And I thought, well, this is some new functionality, which is just different. 306 00:39:31,290 --> 00:39:46,710 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. 307 00:39:46,710 --> 00:39:51,810 That is, there were several integer overflows, and they were patched, which is interesting. 308 00:39:51,810 --> 00:40:04,750 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. 309 00:40:04,750 --> 00:40:08,590 But again, you can think in the direction of downgrade. 310 00:40:08,590 --> 00:40:21,510 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. 311 00:40:21,510 --> 00:40:25,470 That is, you can somehow get to it if you want to. 312 00:40:25,910 --> 00:40:30,950 Now let's talk about what BootGuard components are present in the system. 313 00:40:30,950 --> 00:40:41,390 That is, we have a SMM Verify BootGuard driver and I extracted all the main structures from it. 314 00:40:41,390 --> 00:40:47,790 PEI is needed to check everything before loading. 315 00:40:49,370 --> 00:40:58,370 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. 316 00:40:58,370 --> 00:41:04,070 That is, there is a soft reset and it does not carry out a full cycle of iron loading. 317 00:41:04,070 --> 00:41:14,170 And in this limited case, PEI is taken from the cache and just verifies that the Intel BootGuard chain was previously checked correctly. 318 00:41:14,170 --> 00:41:17,910 And there is also SleepMode, which is interesting. 319 00:41:17,910 --> 00:41:27,530 That is, when you go to S3, that is, SleepMode, there is a different driver that, as it turned out, contains vulnerabilities. 320 00:41:27,530 --> 00:41:29,070 I'll tell you about it now. 321 00:41:30,670 --> 00:41:42,490 Here is a pseudo-code in C language that shows how to check in BootGuard PEI. 322 00:41:42,490 --> 00:41:47,710 And I advise you to pay attention to the block that is circled in red. 323 00:41:47,710 --> 00:41:49,870 That is, it contains a logical error. 324 00:41:49,870 --> 00:41:51,550 The logical error of the following image. 325 00:41:51,550 --> 00:41:54,210 Because, in fact, the following happens. 326 00:41:54,210 --> 00:41:59,990 The flag is set that Intel BootGuard was previously checked correctly. 327 00:42:00,110 --> 00:42:05,050 And then, in the subsequent stages, this flag is checked. 328 00:42:05,050 --> 00:42:07,250 Oh, Intel BootGuard is true. 329 00:42:09,790 --> 00:42:18,250 And for BIOSes, for specific driver implementations, it means that Intel BootGuard configuration and verification are correct. 330 00:42:19,650 --> 00:42:31,710 A very important point is the vendor hash without which, in fact, I had trouble for a week. 331 00:42:31,710 --> 00:42:37,210 Because at first I thought that if I recalculate the entire initial boot block, everything will work for me. 332 00:42:37,210 --> 00:42:42,370 But it turned out that there is another hash that had to be recalculated. 333 00:42:42,610 --> 00:42:47,190 And it also covers the entire image. 334 00:42:51,190 --> 00:42:56,850 Here is the information about Verify Firmware BootGuard, SMM Driver and Validation Flow. 335 00:42:56,850 --> 00:42:59,530 Here, in fact, the algorithm is described as it is checked. 336 00:42:59,530 --> 00:43:10,170 But a very interesting point is that from this SMM Driver there is a communication with IMEI interface and they go through HESI interface. 337 00:43:10,350 --> 00:43:15,770 That is, through this interface the FPF hash is checked. 338 00:43:15,830 --> 00:43:22,410 And if something is wrong, the status of EFI Security Evaluation is returned. 339 00:43:24,550 --> 00:43:29,310 And we go back to what I said. 340 00:43:29,310 --> 00:43:31,070 There was a logical mistake. 341 00:43:31,070 --> 00:43:36,350 What is most interesting, I showed this slide at the BlackHat conference. 342 00:43:36,350 --> 00:43:43,950 And after my presentation, a very famous vendor came up to me and said, you know, we patched this vulnerability just a week ago. 343 00:43:45,170 --> 00:43:48,510 In fact, it was a zero-day for many vendors. 344 00:43:48,710 --> 00:43:51,430 And now I will tell you why. 345 00:43:52,250 --> 00:44:06,290 I wrote such a provocative title for this slide because, in fact, the problem is that we just check the flag on S3. 346 00:44:06,530 --> 00:44:29,030 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, 347 00:44:29,030 --> 00:44:31,490 Intel BootGuard Flow worked correctly. 348 00:44:31,490 --> 00:44:40,930 That is, this check is, in fact, a return from sleep mode and a check for Intel BootGuard from there. 349 00:44:46,090 --> 00:45:03,990 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. 350 00:45:04,070 --> 00:45:05,610 And, in fact, the vulnerability is the same. 351 00:45:05,610 --> 00:45:09,430 It is written in this blog and there are links to this study. 352 00:45:10,070 --> 00:45:12,150 And I understand why. 353 00:45:12,150 --> 00:45:18,450 Because this vulnerability was found in the American Megatrends BIOS implementation. 354 00:45:19,270 --> 00:45:26,930 And so, in fact, all American Megatrends clients were almost subject to it. 355 00:45:26,930 --> 00:45:32,470 Because few people change this code for Intel BootGuard. 356 00:45:32,470 --> 00:45:36,290 In principle, they were unlikely to need it in most cases. 357 00:45:39,290 --> 00:45:42,410 This is the platform that I attacked. 358 00:45:42,710 --> 00:45:46,010 Here are the vulnerabilities described, what I was talking about. 359 00:45:46,150 --> 00:45:50,690 Interestingly, these are the modes of Intel BootGuard. 360 00:45:50,810 --> 00:45:58,250 And as we can see, Intel BootGuard is enabled with the most serious policies. 361 00:45:58,250 --> 00:46:02,530 That is, Verified Boot plus Measured Boot. 362 00:46:02,530 --> 00:46:05,290 And we also see that we have IMEI access. 363 00:46:05,290 --> 00:46:11,170 If you look closely, there is also a DCI interface, about which Positive Technologies talked a lot, activated. 364 00:46:11,170 --> 00:46:13,070 In fact, I could do the same. 365 00:46:13,070 --> 00:46:18,610 In fact, I did it to debug some Dixie drivers. 366 00:46:20,170 --> 00:46:30,410 In fact, here we see that the profile with the help of IMEI info tool is the most severe. 367 00:46:30,910 --> 00:46:34,910 That is, Intel Measured Boot and Verified Boot. 368 00:46:35,490 --> 00:46:38,730 This is a copy of a special site. 369 00:46:38,730 --> 00:46:47,170 And this platform has various certifications for the government, hospitals, critical infrastructure. 370 00:46:57,550 --> 00:47:08,970 As we can see, certification does not always correspond to reality. 371 00:47:08,970 --> 00:47:13,530 Here are the steps that need to be taken to bypass BootGuard. 372 00:47:14,150 --> 00:47:23,750 As I said, you need to recalculate all the manifests, replace all the keys with your own and change the hashes for IBB. 373 00:47:23,750 --> 00:47:33,470 By the way, the hashes can not always be changed, because they should be protected by the signatures that exist. 374 00:47:33,470 --> 00:47:41,690 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. 375 00:47:41,690 --> 00:47:56,230 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. 376 00:47:56,230 --> 00:48:02,530 That is, if you try to update, the system will not let you do it. 377 00:48:02,530 --> 00:48:09,490 Most likely you will think, that the vendor has changed something and you will just forget about it. 378 00:48:09,490 --> 00:48:12,230 But in fact, everything is much more complicated. 379 00:48:13,390 --> 00:48:23,470 That is, if we do not have the root of trust locked hardware in the hardware, we can change all this well. 380 00:48:23,630 --> 00:48:25,490 Here is the official Intel statement. 381 00:48:25,490 --> 00:48:30,730 They say that we tell all vendors to lock, bla-bla-bla. 382 00:48:30,730 --> 00:48:37,470 But the problem is that not all vendors follow everything that Intel says. 383 00:48:37,470 --> 00:48:45,650 If they have the opportunity not to do it, they will try not to do it, as it complicates the production processes. 384 00:48:45,870 --> 00:48:50,510 Many companies simply do not have the resources to follow all these policies. 385 00:48:50,990 --> 00:48:55,510 And here is the statement from GIGABYTE. 386 00:48:56,590 --> 00:49:02,650 As we can see, they said that they released a separate lock for IMEI as a separate tool. 387 00:49:02,650 --> 00:49:13,290 In fact, this is not a fix inside the BIOS update, but you need to install a separate tool, launch it, and lock IMEI. 388 00:49:13,290 --> 00:49:14,890 How many people will do it? 389 00:49:14,890 --> 00:49:16,690 I think almost no one. 390 00:49:17,610 --> 00:49:19,190 Even I did not do it. 391 00:49:19,190 --> 00:49:22,330 I like my separate IMEI for my target platform. 392 00:49:24,690 --> 00:49:31,190 Here are the links to the blog post that I wrote with some details of this attack. 393 00:49:31,190 --> 00:49:39,870 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. 394 00:49:41,510 --> 00:49:47,410 I probably won't have time to tell you anything interesting about BIOS guard, but there is not much information here. 395 00:49:47,410 --> 00:49:54,390 All I can say is that BIOS guard was created to do armoring updates, and boot guard was created to do armoring secure boot. 396 00:49:55,630 --> 00:50:00,970 It is worth noting that BIOS guard should be here. 397 00:50:00,970 --> 00:50:07,370 These are the drivers used to implement BIOS guard inside the American Megatrends firmware. 398 00:50:07,610 --> 00:50:12,070 Interestingly, there are much more drivers than in Intel boot guard. 399 00:50:12,070 --> 00:50:27,390 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. 400 00:50:30,110 --> 00:50:36,150 Here is a brief description of the flow and what Dixie drivers do. 401 00:50:36,350 --> 00:50:40,670 But, as I said, I've been talking about boot guard for too long. 402 00:50:44,970 --> 00:51:01,250 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, 403 00:51:01,250 --> 00:51:03,070 which is interesting. 404 00:51:05,630 --> 00:51:10,150 This is the repository with the slides that you have seen today. 405 00:51:10,270 --> 00:51:16,610 The slides are partially modified, but the main research was done for BlackHat this year. 406 00:51:16,610 --> 00:51:22,470 I will also put all the templates for 0.1 editor and the loader for AIDA there. 407 00:51:23,810 --> 00:51:25,410 Thank you for your attention.