1 00:00:00,030 --> 00:00:05,069 we are going to kick off our Talk's 2 00:00:02,129 --> 00:00:07,020 today with Alex Morozov from silence he 3 00:00:05,069 --> 00:00:08,760 wrote a book called boot kits root kits 4 00:00:07,020 --> 00:00:10,799 and boot kits that backwards or forwards 5 00:00:08,760 --> 00:00:12,990 and he's going to talk to us today about 6 00:00:10,800 --> 00:00:15,509 subverting the BIOS I know you've all 7 00:00:12,990 --> 00:00:19,529 had lunch so stay awake and enjoy the 8 00:00:15,509 --> 00:00:21,630 talk hello everyone my name is Alex 9 00:00:19,529 --> 00:00:23,609 Marat Safin and I will present him today 10 00:00:21,630 --> 00:00:27,538 between the bias where the guardians of 11 00:00:23,609 --> 00:00:29,789 the virus failing so actually the talk 12 00:00:27,539 --> 00:00:31,410 will be focusing on some of the 13 00:00:29,789 --> 00:00:34,440 technologies which is supposed to 14 00:00:31,410 --> 00:00:37,559 protect the firm where you fight firmer 15 00:00:34,440 --> 00:00:41,780 specifically and this kind of treads 16 00:00:37,559 --> 00:00:45,480 actually always under the radar of 17 00:00:41,780 --> 00:00:48,000 normal malicious and to our normal 18 00:00:45,480 --> 00:00:52,440 security software and antivirus software 19 00:00:48,000 --> 00:00:54,480 and also actually this research being 20 00:00:52,440 --> 00:00:57,899 done for blackhat where I guess this 21 00:00:54,480 --> 00:01:01,288 year for specifically for blue hat it 22 00:00:57,899 --> 00:01:03,719 will be a bit extended and also I'm 23 00:01:01,289 --> 00:01:06,570 currently actually leading embedded 24 00:01:03,719 --> 00:01:09,450 security at Nvidia but before of that I 25 00:01:06,570 --> 00:01:11,220 actually been at silence as principal 26 00:01:09,450 --> 00:01:14,970 security researcher and this research 27 00:01:11,220 --> 00:01:17,400 being done at the science time before of 28 00:01:14,970 --> 00:01:22,500 that I actually been a security lead for 29 00:01:17,400 --> 00:01:24,990 Intel ufi firmware security and yeah I 30 00:01:22,500 --> 00:01:26,580 actually out one of the outers of the 31 00:01:24,990 --> 00:01:29,850 boot boot kids and rootkits advanced it 32 00:01:26,580 --> 00:01:32,939 more analysis so what we are talking 33 00:01:29,850 --> 00:01:35,220 about today so we will start about the 34 00:01:32,939 --> 00:01:37,889 attacks on the BIOS update and how 35 00:01:35,220 --> 00:01:41,670 actually the updates for the you fight 36 00:01:37,890 --> 00:01:44,250 firmware is failing and why is it it is 37 00:01:41,670 --> 00:01:47,970 failing it which kind of attacks that 38 00:01:44,250 --> 00:01:51,119 hacker can use it for get in without 39 00:01:47,970 --> 00:01:54,420 physical access and after that I will 40 00:01:51,119 --> 00:01:57,299 explain first known into boot guard 41 00:01:54,420 --> 00:01:59,520 attack and it is technology which is 42 00:01:57,299 --> 00:02:03,390 actually protect the secure boot from 43 00:01:59,520 --> 00:02:05,060 the hardware side and specifically I 44 00:02:03,390 --> 00:02:08,669 will focus on american megatrends 45 00:02:05,060 --> 00:02:10,860 implementation and we will talking about 46 00:02:08,669 --> 00:02:13,799 how the technology works and where is it 47 00:02:10,860 --> 00:02:15,750 like sensitive places and 48 00:02:13,800 --> 00:02:18,300 how the attacker can actually bypass 49 00:02:15,750 --> 00:02:21,570 this technology and discuss the wounds 50 00:02:18,300 --> 00:02:24,270 which is I use it for bypass it and I 51 00:02:21,570 --> 00:02:30,660 will give you details about some BIOS 52 00:02:24,270 --> 00:02:32,610 guard implementation - so boot guard 53 00:02:30,660 --> 00:02:35,400 it's totally actually undocumented 54 00:02:32,610 --> 00:02:37,890 technology and if you interested it will 55 00:02:35,400 --> 00:02:40,140 be some details which is actually not 56 00:02:37,890 --> 00:02:42,750 published before my talk at blackhat and 57 00:02:40,140 --> 00:02:44,820 today I will also talk about the - which 58 00:02:42,750 --> 00:02:46,140 is make some validation for the endo 59 00:02:44,820 --> 00:02:48,660 boot guard but let's start from the 60 00:02:46,140 --> 00:02:50,250 beginning so why actually the bias is 61 00:02:48,660 --> 00:02:54,090 very interesting place for the route 62 00:02:50,250 --> 00:02:57,270 kids in the past time actually a rootkit 63 00:02:54,090 --> 00:02:59,760 started from Realtree and just like load 64 00:02:57,270 --> 00:03:02,310 some malicious driver inside the kernel 65 00:02:59,760 --> 00:03:05,970 or like abuse some driver objects inside 66 00:03:02,310 --> 00:03:08,610 the kernel and after some time when the 67 00:03:05,970 --> 00:03:12,410 secure boot and code sign and policies 68 00:03:08,610 --> 00:03:15,450 for kernel what driver appears its 69 00:03:12,410 --> 00:03:18,720 before secure boot actually appears it's 70 00:03:15,450 --> 00:03:22,980 it been a time for the boot boot kids 71 00:03:18,720 --> 00:03:26,310 because like attacker start thinking how 72 00:03:22,980 --> 00:03:28,530 how we can actually get in and get a 73 00:03:26,310 --> 00:03:32,190 lipid a little bit deeper with the 74 00:03:28,530 --> 00:03:34,110 system boot flow and attack the MBR a 75 00:03:32,190 --> 00:03:40,440 Master Boot Record and volume Boot 76 00:03:34,110 --> 00:03:43,890 Record and okay but after that in 2012 77 00:03:40,440 --> 00:03:46,650 the secure boot been introduced and in 78 00:03:43,890 --> 00:03:49,640 nowadays actually all the systems came 79 00:03:46,650 --> 00:03:53,910 with active secure boot and it's very 80 00:03:49,640 --> 00:03:57,359 but some some cases with wanna cry and 81 00:03:53,910 --> 00:03:59,310 other malicious dresses show so I ran 82 00:03:57,360 --> 00:04:01,350 somewhere shows like it's still a lot of 83 00:03:59,310 --> 00:04:04,280 systems which is doesn't use the secure 84 00:04:01,350 --> 00:04:08,340 boot read but it's supposed to be there 85 00:04:04,280 --> 00:04:11,670 and if we're thinking about work very 86 00:04:08,340 --> 00:04:14,940 complex sophisticated treads and it can 87 00:04:11,670 --> 00:04:17,039 be biased and specifically for like data 88 00:04:14,940 --> 00:04:19,680 centers and the clouds it's very 89 00:04:17,040 --> 00:04:22,020 sensitive place if the attacker came 90 00:04:19,680 --> 00:04:24,150 with supply and chain attack on the 91 00:04:22,019 --> 00:04:26,299 server inside the firmware this can 92 00:04:24,150 --> 00:04:29,030 expose all the guests 93 00:04:26,300 --> 00:04:30,919 on the server if it will be like no 94 00:04:29,030 --> 00:04:33,520 specific protections like memory 95 00:04:30,919 --> 00:04:37,969 encryption or something else right so 96 00:04:33,520 --> 00:04:39,740 very interesting place for the attacker 97 00:04:37,970 --> 00:04:42,380 its system management mode which is 98 00:04:39,740 --> 00:04:45,830 currently one of the most privileged it 99 00:04:42,380 --> 00:04:50,360 mods inside inside the intel x86 100 00:04:45,830 --> 00:04:52,930 architecture and actually why is the 101 00:04:50,360 --> 00:04:55,940 last line showing like we're going from 102 00:04:52,930 --> 00:04:58,430 system management mode to the operating 103 00:04:55,940 --> 00:05:00,440 system level to rank zero because 104 00:04:58,430 --> 00:05:03,110 actually yes you can parse all the 105 00:05:00,440 --> 00:05:05,240 physical memory from there but if you 106 00:05:03,110 --> 00:05:07,130 want to track some specific applications 107 00:05:05,240 --> 00:05:09,319 it's very interesting to be present on 108 00:05:07,130 --> 00:05:13,090 the operating system level and it's 109 00:05:09,319 --> 00:05:17,090 actually not difficult to inject some 110 00:05:13,090 --> 00:05:19,130 some malicious drivers or something else 111 00:05:17,090 --> 00:05:21,679 from this level because you control of 112 00:05:19,130 --> 00:05:23,990 the memory space and you can just like 113 00:05:21,680 --> 00:05:28,699 modify some structures if it will be not 114 00:05:23,990 --> 00:05:32,900 no integrity checks and I want to say 115 00:05:28,699 --> 00:05:36,080 actually as more mitigation we have as 116 00:05:32,900 --> 00:05:39,169 more complexities growth so currently 117 00:05:36,080 --> 00:05:43,250 all the route kids it's growing closer 118 00:05:39,169 --> 00:05:50,210 and closer to hardware we have from some 119 00:05:43,250 --> 00:05:53,599 like known cases examples like our LK 120 00:05:50,210 --> 00:05:56,539 loader from hacking team or some implant 121 00:05:53,599 --> 00:06:01,880 which has been disclosed with world 7 122 00:05:56,539 --> 00:06:04,490 leaks and this kind of treads actually 123 00:06:01,880 --> 00:06:08,830 can bypass all the modern mitigations if 124 00:06:04,490 --> 00:06:15,219 the bias doesn't have any protections or 125 00:06:08,830 --> 00:06:18,190 deliver unsign and updates right so and 126 00:06:15,219 --> 00:06:20,930 this why it's actually I copied from the 127 00:06:18,190 --> 00:06:22,909 presentation from Intel which has been 128 00:06:20,930 --> 00:06:26,830 presented in this black hat and we can 129 00:06:22,909 --> 00:06:32,479 see like a growth of the bias incidence 130 00:06:26,830 --> 00:06:35,150 which is actually been involved with the 131 00:06:32,479 --> 00:06:39,050 enthalpy chart and interesting think 132 00:06:35,150 --> 00:06:40,200 actually configuration configuration of 133 00:06:39,050 --> 00:06:44,100 waste issues 134 00:06:40,200 --> 00:06:46,800 has a very high rate here when like the 135 00:06:44,100 --> 00:06:52,050 platform has the issues and by default 136 00:06:46,800 --> 00:06:57,450 configure unsecure way and it's actually 137 00:06:52,050 --> 00:07:00,120 very very bad when this kind of things 138 00:06:57,450 --> 00:07:04,969 happens because for supply chain attacks 139 00:07:00,120 --> 00:07:07,080 it the perfect vector right and Google 140 00:07:04,970 --> 00:07:09,420 introduces a cheap which is Google 141 00:07:07,080 --> 00:07:12,300 Chetan recently and it's very interested 142 00:07:09,420 --> 00:07:15,120 in case when the company developed 143 00:07:12,300 --> 00:07:19,050 something for like armoring root of 144 00:07:15,120 --> 00:07:21,600 trust on the hardware side because if it 145 00:07:19,050 --> 00:07:26,460 doesn't trust the hardware how we can 146 00:07:21,600 --> 00:07:28,170 protect protect root of trust for the 147 00:07:26,460 --> 00:07:31,049 secure boot and other things and trust 148 00:07:28,170 --> 00:07:33,690 like peripheral devices they're right 149 00:07:31,050 --> 00:07:38,610 somebody just inject just install like 150 00:07:33,690 --> 00:07:41,520 beside wise and then get access to visit 151 00:07:38,610 --> 00:07:44,160 G my attack if it will be like unsecured 152 00:07:41,520 --> 00:07:47,729 way or VTD will be doesn't ensure 153 00:07:44,160 --> 00:07:49,830 initialized very early so it's very 154 00:07:47,730 --> 00:07:52,700 interesting case where where the company 155 00:07:49,830 --> 00:07:56,880 not really related with this like 156 00:07:52,700 --> 00:08:00,650 hardware development or related with ik 157 00:07:56,880 --> 00:08:02,969 and customers things like big cells but 158 00:08:00,650 --> 00:08:05,130 develop the chip which is actually 159 00:08:02,970 --> 00:08:07,410 protects the root of trust I I like this 160 00:08:05,130 --> 00:08:11,960 approach but I also very interested to 161 00:08:07,410 --> 00:08:11,960 get one for working house can break it 162 00:08:13,040 --> 00:08:21,570 so yeah let's talk a bit about the BIOS 163 00:08:16,650 --> 00:08:25,289 update issues u5 firmware actually it's 164 00:08:21,570 --> 00:08:27,950 very huge if I firmware ecosystem is 165 00:08:25,290 --> 00:08:31,380 very huge now its automotive and 166 00:08:27,950 --> 00:08:34,650 actually it's not only x86 system it's a 167 00:08:31,380 --> 00:08:39,780 lot of arm CPUs developers like 168 00:08:34,650 --> 00:08:44,550 companies use EFI firmware too and it's 169 00:08:39,780 --> 00:08:46,439 like very very huge world and some of 170 00:08:44,550 --> 00:08:48,270 the companies actually developed some 171 00:08:46,440 --> 00:08:51,630 frameworks like american megatrends 172 00:08:48,270 --> 00:08:54,240 insight and phoenix and on top of these 173 00:08:51,630 --> 00:08:57,390 frameworks companies developed the 174 00:08:54,240 --> 00:09:01,740 olan firmware and a lot of companies 175 00:08:57,390 --> 00:09:03,959 like gigabyte Asustek and others doesn't 176 00:09:01,740 --> 00:09:06,930 care too much about the security side 177 00:09:03,959 --> 00:09:09,689 because like they small and they just 178 00:09:06,930 --> 00:09:12,569 want to ship product as fast as they can 179 00:09:09,690 --> 00:09:15,779 and it's a lot of like hardware features 180 00:09:12,570 --> 00:09:18,209 came always within new hardware and they 181 00:09:15,779 --> 00:09:22,939 don't have really even like security 182 00:09:18,209 --> 00:09:26,849 validation process for their favors and 183 00:09:22,940 --> 00:09:29,940 also now it's no more release a bias on 184 00:09:26,850 --> 00:09:34,529 new hardware but we have legacy inside 185 00:09:29,940 --> 00:09:37,350 you 5 firmware and let's actually look 186 00:09:34,529 --> 00:09:40,980 inside the firmware update image how 187 00:09:37,350 --> 00:09:43,920 many other firm worst came with a bias 188 00:09:40,980 --> 00:09:48,300 update image so actually just recently 189 00:09:43,920 --> 00:09:51,810 you know like Infineon case with TPM 190 00:09:48,300 --> 00:09:54,870 issue right so and actually TPM updates 191 00:09:51,810 --> 00:09:58,290 sometimes came also with the BIOS update 192 00:09:54,870 --> 00:10:00,630 image and we do have like network 193 00:09:58,290 --> 00:10:02,670 adapters we do have graphics sensors 194 00:10:00,630 --> 00:10:05,430 embedded controller even power 195 00:10:02,670 --> 00:10:08,279 management Oh nowadays actually the 196 00:10:05,430 --> 00:10:14,969 batteries has a firmware to inside your 197 00:10:08,279 --> 00:10:18,779 laptops so mg SMC BMC like a lot of a 198 00:10:14,970 --> 00:10:21,959 lot of different farmers and if like the 199 00:10:18,779 --> 00:10:25,550 door like u5 firmware update is doesn't 200 00:10:21,959 --> 00:10:28,979 have identification or proper update 201 00:10:25,550 --> 00:10:32,040 validation process it's open door I 202 00:10:28,980 --> 00:10:36,350 write for others to break other well 203 00:10:32,040 --> 00:10:38,699 also firmware and it's very interesting 204 00:10:36,350 --> 00:10:41,520 what kind of things we will discuss 205 00:10:38,700 --> 00:10:44,640 today so we will touch a CMS a bit 206 00:10:41,520 --> 00:10:48,390 management engine and mostly focus it on 207 00:10:44,640 --> 00:10:50,279 the boot guard so all the 208 00:10:48,390 --> 00:10:55,439 vulnerabilities which I will discuss in 209 00:10:50,279 --> 00:10:58,079 this talk it's based on my my research 210 00:10:55,440 --> 00:11:00,089 on american megatrends and he'll be 211 00:10:58,079 --> 00:11:03,439 covered some issues from gigabyte ah so 212 00:11:00,089 --> 00:11:03,440 specula nova and msi 213 00:11:05,000 --> 00:11:13,290 so this figure actually shows how many 214 00:11:09,900 --> 00:11:18,420 simple protections like locking bits we 215 00:11:13,290 --> 00:11:23,189 have inside modern hardware from Intel 216 00:11:18,420 --> 00:11:27,329 and some of them is pretty simple it's 217 00:11:23,190 --> 00:11:31,410 just like lock beat for doesn't update 218 00:11:27,330 --> 00:11:34,530 or read spy flash protection Oh spy 219 00:11:31,410 --> 00:11:40,650 flash or we have a bias right protection 220 00:11:34,530 --> 00:11:43,800 bit which is doesn't allow from the 221 00:11:40,650 --> 00:11:45,810 operating system to get in SMM without 222 00:11:43,800 --> 00:11:48,270 disabling this bit which is can be 223 00:11:45,810 --> 00:11:51,060 disabled only from ism by specific 224 00:11:48,270 --> 00:11:53,900 driver and we have a bias walk bit which 225 00:11:51,060 --> 00:11:56,790 is working the bias from the update and 226 00:11:53,900 --> 00:11:59,760 we have fancy technologies like bias 227 00:11:56,790 --> 00:12:02,069 guard and boot guard boot guard actually 228 00:11:59,760 --> 00:12:04,830 armoring the secure boot making root of 229 00:12:02,070 --> 00:12:07,590 trust much more secure and starting 230 00:12:04,830 --> 00:12:10,350 earlier than bias for validation through 231 00:12:07,590 --> 00:12:12,840 the chain of trust and bias guard 232 00:12:10,350 --> 00:12:14,850 actually armoring the updates and both 233 00:12:12,840 --> 00:12:16,560 this technology is working with a CMS 234 00:12:14,850 --> 00:12:22,470 which is actually executed in 235 00:12:16,560 --> 00:12:24,030 identification cache and specifically 236 00:12:22,470 --> 00:12:26,820 for this talk i've been found 237 00:12:24,030 --> 00:12:28,199 i actually found some some 238 00:12:26,820 --> 00:12:30,750 vulnerabilities which is which is 239 00:12:28,200 --> 00:12:33,330 actually pretty simple some of the 240 00:12:30,750 --> 00:12:36,780 vendors just don't use the protection 241 00:12:33,330 --> 00:12:39,240 bids and some of the some of the vendors 242 00:12:36,780 --> 00:12:42,780 don't use the policies for the spy flash 243 00:12:39,240 --> 00:12:46,020 regions for like isolate some of the 244 00:12:42,780 --> 00:12:48,060 regions to be updated or right be 245 00:12:46,020 --> 00:12:51,840 written from from the bios update 246 00:12:48,060 --> 00:12:55,140 process and also some of the vendors 247 00:12:51,840 --> 00:12:57,240 just don't use the sign digital sign for 248 00:12:55,140 --> 00:12:59,970 the updates out gentrification which is 249 00:12:57,240 --> 00:13:04,320 a lot Iker modifies the bios image and 250 00:12:59,970 --> 00:13:08,040 deliver something malicious and some of 251 00:13:04,320 --> 00:13:11,510 the vendors like gigabyte don't use boot 252 00:13:08,040 --> 00:13:14,520 guard properly and it's a lot harder to 253 00:13:11,510 --> 00:13:16,630 actually bypass this technology and i 254 00:13:14,520 --> 00:13:19,720 will introduce one 255 00:13:16,630 --> 00:13:25,930 the first known bypasses for this 256 00:13:19,720 --> 00:13:29,290 technology today so how different 257 00:13:25,930 --> 00:13:32,709 vendors care about the biosecurity and 258 00:13:29,290 --> 00:13:34,510 you can see here like different vendors 259 00:13:32,710 --> 00:13:36,490 some of them focus it on enterprise 260 00:13:34,510 --> 00:13:40,840 market some of them on the game industry 261 00:13:36,490 --> 00:13:44,590 and you can see the difference and also 262 00:13:40,840 --> 00:13:47,980 like a lot of people think like Apple is 263 00:13:44,590 --> 00:13:49,600 a good example of perfect hardware 264 00:13:47,980 --> 00:13:53,410 vendor which is not actually true 265 00:13:49,600 --> 00:13:57,100 because they also don't use all of the 266 00:13:53,410 --> 00:14:00,520 mitigations and as examples they don't 267 00:13:57,100 --> 00:14:03,250 use boot boot guard and they just have a 268 00:14:00,520 --> 00:14:06,100 secure boot which is started after the 269 00:14:03,250 --> 00:14:08,590 BIOS already like passes at a stage 270 00:14:06,100 --> 00:14:10,540 platform initialization stage but I 271 00:14:08,590 --> 00:14:12,340 think it will be improved soon because 272 00:14:10,540 --> 00:14:16,750 they have very strong security team for 273 00:14:12,340 --> 00:14:21,340 you fight farmer and on other side we 274 00:14:16,750 --> 00:14:23,670 have a Dell which has actually been very 275 00:14:21,340 --> 00:14:29,320 responsive for my issues and also like 276 00:14:23,670 --> 00:14:31,810 they don't have it too much and I like 277 00:14:29,320 --> 00:14:35,320 how they protect the BIOS update routine 278 00:14:31,810 --> 00:14:37,780 with uber buzz guard because they do it 279 00:14:35,320 --> 00:14:43,090 a bit different way and it was very hard 280 00:14:37,780 --> 00:14:45,339 to break it so and some of the vendors 281 00:14:43,090 --> 00:14:48,640 it's a screenshot from the tool not 282 00:14:45,340 --> 00:14:51,880 known as a chip sack and we can see like 283 00:14:48,640 --> 00:14:54,400 don't have any of simple protections on 284 00:14:51,880 --> 00:14:59,380 resin actually the screenshot been done 285 00:14:54,400 --> 00:15:02,290 for for seven generation cab you like 286 00:14:59,380 --> 00:15:04,840 from window and the card were being 287 00:15:02,290 --> 00:15:07,959 released in January this year doesn't 288 00:15:04,840 --> 00:15:13,560 have any protections and they just don't 289 00:15:07,960 --> 00:15:15,130 care and specifically on this hardware I 290 00:15:13,560 --> 00:15:17,469 undo akathisia 291 00:15:15,130 --> 00:15:20,200 I make a demo with you if I ran 292 00:15:17,470 --> 00:15:23,980 somewhere it's pretty simple way but 293 00:15:20,200 --> 00:15:27,970 it's show way in visual way how it can 294 00:15:23,980 --> 00:15:30,520 be bypassed so it's already released in 295 00:15:27,970 --> 00:15:34,149 my other talk the details 296 00:15:30,520 --> 00:15:36,730 if if we if we go some specific 297 00:15:34,149 --> 00:15:40,300 exploitation flow so Weiss walk been not 298 00:15:36,730 --> 00:15:45,000 even enabled and attacker is able to 299 00:15:40,300 --> 00:15:48,640 modify bias right protection bead so and 300 00:15:45,000 --> 00:15:50,680 we as attacker we can arbitrary right to 301 00:15:48,640 --> 00:15:54,310 the spy flash chip and make it 302 00:15:50,680 --> 00:15:57,250 persistent from the operating system 303 00:15:54,310 --> 00:15:58,810 level so specifically this demo show as 304 00:15:57,250 --> 00:16:04,029 we have a dog 305 00:15:58,810 --> 00:16:07,329 eggs document which is job some infected 306 00:16:04,029 --> 00:16:11,890 a ufi firmware image on the file system 307 00:16:07,330 --> 00:16:18,459 and then sign a driver from american 308 00:16:11,890 --> 00:16:21,370 megatrends being update using this 309 00:16:18,459 --> 00:16:24,939 update to deliver malicious firmware 310 00:16:21,370 --> 00:16:27,130 without any modifications inside the 311 00:16:24,940 --> 00:16:31,899 driver but I use a privilege escalation 312 00:16:27,130 --> 00:16:34,870 in this driver so and don't verify the 313 00:16:31,899 --> 00:16:37,570 signature and delivers the malicious 314 00:16:34,870 --> 00:16:39,990 update it's not a rocket science and it 315 00:16:37,570 --> 00:16:43,540 shows actually it's possible ways for 316 00:16:39,990 --> 00:16:46,050 remote attacks on a lot of a lot of 317 00:16:43,540 --> 00:16:49,240 different farmers and the main route of 318 00:16:46,050 --> 00:16:51,760 actually also problem not a lot of 319 00:16:49,240 --> 00:16:54,779 people really update the biases even the 320 00:16:51,760 --> 00:16:58,439 companies it's hard right so we have a 321 00:16:54,779 --> 00:17:01,810 zoo from different vendors and different 322 00:16:58,440 --> 00:17:03,579 hardware and it's hard to control how 323 00:17:01,810 --> 00:17:06,849 many hard will have resident update 324 00:17:03,579 --> 00:17:11,709 which is or how many it doesn't have it 325 00:17:06,849 --> 00:17:15,369 so and from a tiger perspective if some 326 00:17:11,709 --> 00:17:17,620 malicious if malware came on the 327 00:17:15,369 --> 00:17:20,589 operating system level which can 328 00:17:17,619 --> 00:17:23,589 actually try to check how the firmware 329 00:17:20,589 --> 00:17:29,620 is up-to-date or check for known issues 330 00:17:23,589 --> 00:17:32,260 and try to actually attack it so how 331 00:17:29,620 --> 00:17:36,719 many people update the buyers in this 332 00:17:32,260 --> 00:17:36,720 room okay 333 00:17:37,100 --> 00:17:49,040 that's good to know how many people not 334 00:17:40,940 --> 00:17:51,710 updated and it's this picture actually 335 00:17:49,040 --> 00:17:55,370 shows the flow how from the operating 336 00:17:51,710 --> 00:18:00,770 system level we can get in spy flash 337 00:17:55,370 --> 00:18:03,560 persistently and think is like we need 338 00:18:00,770 --> 00:18:08,180 of course I don't know memory corruption 339 00:18:03,560 --> 00:18:10,370 or some bug inside browser or flash or 340 00:18:08,180 --> 00:18:12,680 whatever we just came up through there 341 00:18:10,370 --> 00:18:16,820 or spread phishing email visit docx or 342 00:18:12,680 --> 00:18:20,200 PDF then of course we need get into the 343 00:18:16,820 --> 00:18:23,720 kernel mode because without kernel mode 344 00:18:20,200 --> 00:18:26,270 we can't communicate with the SMI 345 00:18:23,720 --> 00:18:28,280 handlers or some services which is 346 00:18:26,270 --> 00:18:32,270 responsible for the BIOS update or 347 00:18:28,280 --> 00:18:35,540 writing to the spy flash so after that 348 00:18:32,270 --> 00:18:38,030 we map it or use a specific application 349 00:18:35,540 --> 00:18:41,899 from the vendor to map the update image 350 00:18:38,030 --> 00:18:45,800 for some specific memory region and 351 00:18:41,900 --> 00:18:48,950 after that we call inside the system 352 00:18:45,800 --> 00:18:51,980 management mode the service which is 353 00:18:48,950 --> 00:18:55,520 actually named it as it's my handler to 354 00:18:51,980 --> 00:19:01,520 get this image read inside this mam and 355 00:18:55,520 --> 00:19:04,820 update the spy flash or it can be 356 00:19:01,520 --> 00:19:08,120 actually done in different way but some 357 00:19:04,820 --> 00:19:14,510 of vendors which I checked doing the 358 00:19:08,120 --> 00:19:17,570 that way so and even if the drivers even 359 00:19:14,510 --> 00:19:19,910 if BIOS update is sign it if any 360 00:19:17,570 --> 00:19:23,530 vulnerabilities inside this is my flash 361 00:19:19,910 --> 00:19:28,700 always is SMI handlers which is if 362 00:19:23,530 --> 00:19:31,850 speaking simply explain it it's like cow 363 00:19:28,700 --> 00:19:35,090 back function from bias to operating 364 00:19:31,850 --> 00:19:39,320 system level for reading and writing the 365 00:19:35,090 --> 00:19:41,209 spy flash and in the past the lot of 366 00:19:39,320 --> 00:19:46,040 them use it just is my flash driver 367 00:19:41,210 --> 00:19:50,500 which is doesn't identification it's 368 00:19:46,040 --> 00:19:50,500 being like a lot of issues there and 369 00:19:50,630 --> 00:19:55,580 after some time some of the vendors 370 00:19:52,760 --> 00:19:57,919 start using security so my flash which 371 00:19:55,580 --> 00:20:02,270 is fully date digital sign for the BIOS 372 00:19:57,919 --> 00:20:06,380 updates and actually I found one issue 373 00:20:02,270 --> 00:20:10,789 on Asus tag with this second semi flash 374 00:20:06,380 --> 00:20:15,710 driver and even if by high net you can 375 00:20:10,789 --> 00:20:19,129 attack sex to my flash to modify the 376 00:20:15,710 --> 00:20:23,059 flow for for for the flash and update 377 00:20:19,130 --> 00:20:27,350 without any sign verification here is a 378 00:20:23,059 --> 00:20:30,649 bit about this my flash issues so this 379 00:20:27,350 --> 00:20:34,370 specific dragger are responsible for 380 00:20:30,650 --> 00:20:38,179 writing reading and like enabling this 381 00:20:34,370 --> 00:20:40,668 kind of function and also it is like 382 00:20:38,179 --> 00:20:45,559 getting some information about how spy 383 00:20:40,669 --> 00:20:50,230 flash how many memories has and how how 384 00:20:45,559 --> 00:20:50,230 actually bios update feed for for this 385 00:20:50,650 --> 00:20:56,299 circuit of my flesh it's a bit more 386 00:20:53,000 --> 00:20:59,659 interesting because it's validate the 387 00:20:56,299 --> 00:21:03,379 update for for for digital sign and it's 388 00:20:59,659 --> 00:21:07,600 voting image and get information about 389 00:21:03,380 --> 00:21:10,549 sign and validate the sign and actually 390 00:21:07,600 --> 00:21:12,649 here is the number of is my handlers 391 00:21:10,549 --> 00:21:15,080 which is can code from the operating 392 00:21:12,650 --> 00:21:17,480 system level and all of them being 393 00:21:15,080 --> 00:21:22,730 vulnerable for simple call out attacks 394 00:21:17,480 --> 00:21:27,950 which is pretty much simple to exploit 395 00:21:22,730 --> 00:21:32,620 and what I did and of course it's why 396 00:21:27,950 --> 00:21:35,809 why is guard been created by Intel and 397 00:21:32,620 --> 00:21:37,908 actually Visegrad guard it's pretty 398 00:21:35,809 --> 00:21:41,389 interesting technology and it's 399 00:21:37,909 --> 00:21:46,600 available on most of the platforms which 400 00:21:41,390 --> 00:21:49,460 is used V Pro so it's a bit about 401 00:21:46,600 --> 00:21:52,549 responsible discs were fun so and you 402 00:21:49,460 --> 00:21:54,950 can see how actually how much time you 403 00:21:52,549 --> 00:21:58,370 need to patch the issues for the bias 404 00:21:54,950 --> 00:22:02,380 even if it will be like one bit change 405 00:21:58,370 --> 00:22:02,379 inside the BIOS code 406 00:22:03,090 --> 00:22:10,000 but most interesting part it's like how 407 00:22:06,420 --> 00:22:12,640 some of the vendors react so I submit 408 00:22:10,000 --> 00:22:15,970 the issues to a stack and after a month 409 00:22:12,640 --> 00:22:18,340 of my email they send me I send it 410 00:22:15,970 --> 00:22:21,340 flower follow-up email and they say okay 411 00:22:18,340 --> 00:22:23,649 it's no issues I said how come actually 412 00:22:21,340 --> 00:22:26,500 I found the issues I send details no no 413 00:22:23,650 --> 00:22:29,920 we push it already so I make a bean dip 414 00:22:26,500 --> 00:22:31,930 of BIOS update and then I see like they 415 00:22:29,920 --> 00:22:34,780 push it exactly my issues a new update 416 00:22:31,930 --> 00:22:39,330 just like few weeks after I send it in 417 00:22:34,780 --> 00:22:42,670 well and after some pressure to a stack 418 00:22:39,330 --> 00:22:44,679 they actually submit me send me another 419 00:22:42,670 --> 00:22:50,950 email where they say okay yeah we 420 00:22:44,680 --> 00:22:55,390 recognize it was your issues and it's 421 00:22:50,950 --> 00:22:58,300 also like shows the level of of the 422 00:22:55,390 --> 00:23:00,490 vendors how they redid to communicate 423 00:22:58,300 --> 00:23:02,620 with researchers and research community 424 00:23:00,490 --> 00:23:07,450 which is actually without any money 425 00:23:02,620 --> 00:23:10,179 tried to help to fix and try to actually 426 00:23:07,450 --> 00:23:14,080 make their products more secure right 427 00:23:10,180 --> 00:23:19,350 it's no bug bounties from us it's like 428 00:23:14,080 --> 00:23:19,350 they just we just given them for free 429 00:23:21,180 --> 00:23:29,050 and if we switch on the mitigation 430 00:23:26,310 --> 00:23:31,270 technology I want to talk about the into 431 00:23:29,050 --> 00:23:35,190 boot guard which is pretty interesting 432 00:23:31,270 --> 00:23:38,950 technology it start with a date root 433 00:23:35,190 --> 00:23:42,310 root of chain of trust from early 434 00:23:38,950 --> 00:23:44,230 beginning even before the bias started 435 00:23:42,310 --> 00:23:49,510 and it's actually very good from the 436 00:23:44,230 --> 00:23:53,830 security perspective but it's also like 437 00:23:49,510 --> 00:23:56,800 always you some of the things come for 438 00:23:53,830 --> 00:23:58,570 the manufacturing and third parties 439 00:23:56,800 --> 00:24:03,040 implementation I mean like hardware 440 00:23:58,570 --> 00:24:05,200 vendors and I Belize and it's where 441 00:24:03,040 --> 00:24:07,649 they're failed but let's talk a bit 442 00:24:05,200 --> 00:24:11,160 about different shades of secure boot a 443 00:24:07,650 --> 00:24:13,910 regional secure boot been introduced on 444 00:24:11,160 --> 00:24:18,350 in 2012 445 00:24:13,910 --> 00:24:20,420 and actually a root of trust been fully 446 00:24:18,350 --> 00:24:23,510 based on the buyers that's mean any 447 00:24:20,420 --> 00:24:28,910 issue inside the system management mode 448 00:24:23,510 --> 00:24:33,170 or not only sometimes can break it root 449 00:24:28,910 --> 00:24:35,050 of trust so or attack surface based on 450 00:24:33,170 --> 00:24:37,850 farmer sir 451 00:24:35,050 --> 00:24:39,950 after some time it's been introduced at 452 00:24:37,850 --> 00:24:43,879 measured boot and verified boot schemes 453 00:24:39,950 --> 00:24:47,570 and measure it Buddha is actually based 454 00:24:43,880 --> 00:24:50,960 on TPM where the root of trust in is TPM 455 00:24:47,570 --> 00:24:56,389 but all the secrets and all the code 456 00:24:50,960 --> 00:24:59,480 implementation stirred inside buyers so 457 00:24:56,390 --> 00:25:04,040 and it's still attack surface will be in 458 00:24:59,480 --> 00:25:07,670 firmer right and only verified boot has 459 00:25:04,040 --> 00:25:10,220 some field program infuse hash value 460 00:25:07,670 --> 00:25:12,890 which is log root of trust inside the 461 00:25:10,220 --> 00:25:18,100 hardware and here is firmware and 462 00:25:12,890 --> 00:25:23,090 hardware attack surface came so let's 463 00:25:18,100 --> 00:25:27,679 talk a bit why boot guard has been 464 00:25:23,090 --> 00:25:29,929 created so classical secure boot can be 465 00:25:27,680 --> 00:25:32,590 starts from the Dixie phase which is 466 00:25:29,930 --> 00:25:36,020 most threatened face just before 467 00:25:32,590 --> 00:25:39,230 firmware plus the control to the 468 00:25:36,020 --> 00:25:43,629 operating system but loaders and it can 469 00:25:39,230 --> 00:25:47,240 be impacted with any SMM issues or like 470 00:25:43,630 --> 00:25:48,740 SMM or bios implant not all of the bios 471 00:25:47,240 --> 00:25:53,780 in points but from with some unbiased 472 00:25:48,740 --> 00:25:56,720 implants definitely and also it was no 473 00:25:53,780 --> 00:25:59,090 verification for early boot stages like 474 00:25:56,720 --> 00:26:03,590 second platform initialization boot 475 00:25:59,090 --> 00:26:07,580 phases from other side measure it boot 476 00:26:03,590 --> 00:26:10,429 starts just before pay face which is 477 00:26:07,580 --> 00:26:15,320 platform installation and can be also 478 00:26:10,430 --> 00:26:17,360 impacted with the same issues and as we 479 00:26:15,320 --> 00:26:19,990 said before the root of trust moved 480 00:26:17,360 --> 00:26:24,729 visibly fight boot to the hardware and 481 00:26:19,990 --> 00:26:26,160 it's how actually into boot guard 482 00:26:24,730 --> 00:26:31,560 protect 483 00:26:26,160 --> 00:26:38,700 in most like stricted mod the chain of 484 00:26:31,560 --> 00:26:41,399 trust and also for foremost strongest 485 00:26:38,700 --> 00:26:43,860 protection verification should rely on 486 00:26:41,400 --> 00:26:47,760 microcode identification as example 487 00:26:43,860 --> 00:26:50,250 microcode is out indicate a CMS for 488 00:26:47,760 --> 00:26:53,129 being executed this picture I copied 489 00:26:50,250 --> 00:26:55,890 from Vincent Zimmer's block and it's 490 00:26:53,130 --> 00:27:00,230 actually first picture which is show 491 00:26:55,890 --> 00:27:03,660 some details about food guard technology 492 00:27:00,230 --> 00:27:07,710 but it's no open specification and it's 493 00:27:03,660 --> 00:27:11,970 actually pretty old picture and I start 494 00:27:07,710 --> 00:27:14,430 actually my research from here and start 495 00:27:11,970 --> 00:27:19,860 figuring out how actually boot guard 496 00:27:14,430 --> 00:27:21,390 flow works and this picture actually 497 00:27:19,860 --> 00:27:25,439 demonstrates some high level overview 498 00:27:21,390 --> 00:27:27,360 how it's started so we have a CPU reset 499 00:27:25,440 --> 00:27:31,290 which is passed control to the CPU 500 00:27:27,360 --> 00:27:33,600 microcode and identification and wrote 501 00:27:31,290 --> 00:27:35,629 from BIOS update image actually ACM 502 00:27:33,600 --> 00:27:37,679 start and BIOS update image and if 503 00:27:35,630 --> 00:27:40,800 identification from micro code files 504 00:27:37,680 --> 00:27:42,120 attacker just can use some malicious or 505 00:27:40,800 --> 00:27:49,280 modified ACMs 506 00:27:42,120 --> 00:27:54,179 and ECM verifies the flow after that and 507 00:27:49,280 --> 00:27:56,220 pass the control to reset vector and IBB 508 00:27:54,180 --> 00:27:59,070 which is initial boot block it's some 509 00:27:56,220 --> 00:28:02,280 hashes values which is very find a 510 00:27:59,070 --> 00:28:05,399 second zap a face and after that just 511 00:28:02,280 --> 00:28:10,220 pass the control to the classical secure 512 00:28:05,400 --> 00:28:10,220 boot and operating system will be loaded 513 00:28:10,970 --> 00:28:17,430 into boot guard technology has a few 514 00:28:13,740 --> 00:28:19,830 different operating modes and most 515 00:28:17,430 --> 00:28:21,750 strongest not its verified boot when the 516 00:28:19,830 --> 00:28:24,990 root of trust as I say lock it in the 517 00:28:21,750 --> 00:28:27,390 hardware and you can also use in the 518 00:28:24,990 --> 00:28:28,890 both mods like measure it boot bruce 519 00:28:27,390 --> 00:28:34,500 verified boot which is most strongest 520 00:28:28,890 --> 00:28:36,330 mode for the intel good guard this 521 00:28:34,500 --> 00:28:38,300 picture i also copied from vincent 522 00:28:36,330 --> 00:28:43,760 Zimmer's blog post 523 00:28:38,300 --> 00:28:49,580 and let's and let's look how actually 524 00:28:43,760 --> 00:28:51,830 policy policy verification works so on 525 00:28:49,580 --> 00:28:55,399 the different phases we have a different 526 00:28:51,830 --> 00:28:59,510 policy and I start figuring out how it 527 00:28:55,400 --> 00:29:01,640 really works so and the start point it's 528 00:28:59,510 --> 00:29:05,720 actually filled program and views after 529 00:29:01,640 --> 00:29:08,240 that we do have like IBB which is 530 00:29:05,720 --> 00:29:15,230 initial boot block and ICM actually 531 00:29:08,240 --> 00:29:18,530 verify IBB and this picture actually 532 00:29:15,230 --> 00:29:21,140 demonstrate in my opinion like real 533 00:29:18,530 --> 00:29:26,360 world picture at least for some of the 534 00:29:21,140 --> 00:29:30,550 bias vendors and I as I say on beginning 535 00:29:26,360 --> 00:29:35,840 i reconstructed american megatrends bias 536 00:29:30,550 --> 00:29:39,830 and this probably looks very close as it 537 00:29:35,840 --> 00:29:42,678 is in standard so and also it's been 538 00:29:39,830 --> 00:29:48,500 extracted by reverse engineering so we 539 00:29:42,679 --> 00:29:53,960 have a que manifest which is store hash 540 00:29:48,500 --> 00:29:56,600 of IBB public key and om root public key 541 00:29:53,960 --> 00:29:59,710 and actually I am route public key is 542 00:29:56,600 --> 00:30:04,129 should be logged by field program infuse 543 00:29:59,710 --> 00:30:07,670 if it is not actually it can be an issue 544 00:30:04,130 --> 00:30:12,980 but it's not enough I will say why a 545 00:30:07,670 --> 00:30:15,380 little bit later on my voice and this 546 00:30:12,980 --> 00:30:20,120 kind of policies stir it inside the BIOS 547 00:30:15,380 --> 00:30:23,059 update image so any attacker has access 548 00:30:20,120 --> 00:30:25,250 to the bios update image it's mean like 549 00:30:23,059 --> 00:30:30,080 he can download from this vendor side 550 00:30:25,250 --> 00:30:32,870 and play it on top of it a bit so only 551 00:30:30,080 --> 00:30:34,699 this part rely on the hardware all this 552 00:30:32,870 --> 00:30:40,850 part actually store inside the firmware 553 00:30:34,700 --> 00:30:44,300 and it's actually this picture 554 00:30:40,850 --> 00:30:46,850 demonstrates the route of trust and this 555 00:30:44,300 --> 00:30:50,270 been specifically released before my 556 00:30:46,850 --> 00:30:52,790 talk on blackhat by Dell and it's most 557 00:30:50,270 --> 00:30:55,470 actually detail it 558 00:30:52,790 --> 00:30:57,690 information about how boot guard works 559 00:30:55,470 --> 00:31:01,070 from some of the vendor which is has 560 00:30:57,690 --> 00:31:03,870 access to the documentation 561 00:31:01,070 --> 00:31:07,649 yeah and it's actually the same thing 562 00:31:03,870 --> 00:31:12,290 but relying on Dell documentation which 563 00:31:07,650 --> 00:31:15,870 is we seen before and I actually checked 564 00:31:12,290 --> 00:31:19,290 different vendors configuration for the 565 00:31:15,870 --> 00:31:23,159 boot guard and buyers guard and we can 566 00:31:19,290 --> 00:31:26,879 see how different it is for different 567 00:31:23,160 --> 00:31:29,790 vendors and some of them using the boot 568 00:31:26,880 --> 00:31:34,080 guard but don't use the BIOS guard which 569 00:31:29,790 --> 00:31:39,120 is actually make BIOS update process 570 00:31:34,080 --> 00:31:42,840 much more unsecure and most actually 571 00:31:39,120 --> 00:31:48,989 worst ones its gigabyte MSI and a so 572 00:31:42,840 --> 00:31:51,570 straggling but also some of the vendors 573 00:31:48,990 --> 00:31:57,090 like Lenovo on some of the platforms 574 00:31:51,570 --> 00:31:59,370 don't use at all the boot guard but so 575 00:31:57,090 --> 00:32:02,520 it's possible because it should cost 576 00:31:59,370 --> 00:32:06,780 some money right for more expensive 577 00:32:02,520 --> 00:32:14,850 systems they do but this kind of systems 578 00:32:06,780 --> 00:32:18,270 I a bit research for my talk so as you 579 00:32:14,850 --> 00:32:24,719 can see trust no-one because if you see 580 00:32:18,270 --> 00:32:27,090 on on some information feature 581 00:32:24,720 --> 00:32:30,210 information on the website they use 582 00:32:27,090 --> 00:32:32,959 something or not it's just say they have 583 00:32:30,210 --> 00:32:35,640 this technology in your hardware but how 584 00:32:32,960 --> 00:32:39,060 properly they use you don't know Willian 585 00:32:35,640 --> 00:32:41,100 and for specifically for preventing 586 00:32:39,060 --> 00:32:43,649 supply chain attacks it's very important 587 00:32:41,100 --> 00:32:45,840 to actually make some validation process 588 00:32:43,650 --> 00:32:51,780 for the hardware before it will be 589 00:32:45,840 --> 00:32:55,139 shipped to the data centers first 590 00:32:51,780 --> 00:32:58,200 information about the boot guard came 591 00:32:55,140 --> 00:33:00,780 from Alex Ermolov on last year zero 592 00:32:58,200 --> 00:33:03,870 night talk and it's interesting because 593 00:33:00,780 --> 00:33:05,170 he found the system from gigabyte which 594 00:33:03,870 --> 00:33:08,500 is 595 00:33:05,170 --> 00:33:11,770 the boot guard but the boot guard not 596 00:33:08,500 --> 00:33:18,090 been enabled and not been actually 597 00:33:11,770 --> 00:33:21,190 configured so if attacker know how 598 00:33:18,090 --> 00:33:27,179 modify this technology in active stage 599 00:33:21,190 --> 00:33:30,910 and then deliver malicious update the 600 00:33:27,180 --> 00:33:34,410 actually attacker can just walk the 601 00:33:30,910 --> 00:33:37,930 route kid inside your firmware and 602 00:33:34,410 --> 00:33:40,570 because that hacker has a private key 603 00:33:37,930 --> 00:33:44,890 for the all the policies and it will be 604 00:33:40,570 --> 00:33:47,110 locked by fueled programming views it's 605 00:33:44,890 --> 00:33:49,810 no way how you can update or extract 606 00:33:47,110 --> 00:33:53,040 this rootkit so it will be locket 607 00:33:49,810 --> 00:33:56,649 forever it just need like what of 608 00:33:53,040 --> 00:34:01,990 probably it's you just provide this to 609 00:33:56,650 --> 00:34:04,630 trash the hardware so it's how it looks 610 00:34:01,990 --> 00:34:08,830 in in config in policies inside 611 00:34:04,630 --> 00:34:11,290 Fito into flash image though and you can 612 00:34:08,830 --> 00:34:15,400 see like boot guard doesn't enable it 613 00:34:11,290 --> 00:34:19,989 and om public hash key is zeros so and 614 00:34:15,400 --> 00:34:21,190 also in this case field programming fuse 615 00:34:19,989 --> 00:34:24,279 not been set up 616 00:34:21,190 --> 00:34:26,320 so that's mean like attacker modifies 617 00:34:24,280 --> 00:34:29,610 the public hash key delivers the 618 00:34:26,320 --> 00:34:32,500 malicious update and lock the fuse so 619 00:34:29,610 --> 00:34:35,260 but here 620 00:34:32,500 --> 00:34:41,050 why would guard not been enabled it's 621 00:34:35,260 --> 00:34:44,940 not bypass it just like Alex use it boot 622 00:34:41,050 --> 00:34:47,410 guard for enabling the boot guard and 623 00:34:44,940 --> 00:34:53,040 show how the rootkit can be locked 624 00:34:47,409 --> 00:34:56,080 inside the platform as a POC but as 625 00:34:53,040 --> 00:34:58,570 somebody on Twitter says you never 626 00:34:56,080 --> 00:35:01,110 attack the standard you always attack oh 627 00:34:58,570 --> 00:35:05,610 yeah you always attack implementation 628 00:35:01,110 --> 00:35:09,730 and I actually get to look inside how 629 00:35:05,610 --> 00:35:15,510 specific platforms works for validate 630 00:35:09,730 --> 00:35:15,510 the bias as a boot guard and 631 00:35:16,340 --> 00:35:20,600 as we can see like came when you first 632 00:35:18,950 --> 00:35:24,169 and it's startin to you Pfeiffer very 633 00:35:20,600 --> 00:35:29,630 much I'll construct some of the field 634 00:35:24,170 --> 00:35:32,990 for from the this structure and we can 635 00:35:29,630 --> 00:35:35,750 see here is a public key and if a tiger 636 00:35:32,990 --> 00:35:38,149 if root of trust not locked in the card 637 00:35:35,750 --> 00:35:40,400 where attacker just can change all the 638 00:35:38,150 --> 00:35:49,040 keys right so modify all the policies if 639 00:35:40,400 --> 00:35:52,040 he knows where stored where what and we 640 00:35:49,040 --> 00:35:55,550 do have IBM cache which is also need to 641 00:35:52,040 --> 00:35:58,700 be change it for for for that hack on 642 00:35:55,550 --> 00:36:00,950 the boot guard but I will discuss all 643 00:35:58,700 --> 00:36:05,299 the flow a bit later also I will 644 00:36:00,950 --> 00:36:09,350 construct initial blog boot manifest it 645 00:36:05,300 --> 00:36:12,530 is here so we have IBB hashes which is 646 00:36:09,350 --> 00:36:15,740 actually validate ii pay phase and i 647 00:36:12,530 --> 00:36:19,700 will be offset which is shows where it 648 00:36:15,740 --> 00:36:25,100 specifically located protected regions 649 00:36:19,700 --> 00:36:27,710 in size if you fi bias so and also we 650 00:36:25,100 --> 00:36:33,290 have a RSA signature which is can be 651 00:36:27,710 --> 00:36:37,490 changed and public key of course - so if 652 00:36:33,290 --> 00:36:40,670 I - some time ago already shows and 653 00:36:37,490 --> 00:36:43,129 parse in the feed boot guard policy and 654 00:36:40,670 --> 00:36:46,370 Kim Yuna first policy and also shows 655 00:36:43,130 --> 00:36:51,980 where the ECM stored so you can easily 656 00:36:46,370 --> 00:36:55,009 extract that it's because in GDK we have 657 00:36:51,980 --> 00:36:59,360 a values for the feed structure which is 658 00:36:55,010 --> 00:37:04,510 shows where where where it's based off 659 00:36:59,360 --> 00:37:07,940 set for for the specific policies and 660 00:37:04,510 --> 00:37:11,030 it's actually how initial boot block 661 00:37:07,940 --> 00:37:18,890 looks like so we have cash value and 662 00:37:11,030 --> 00:37:21,080 offset so and it's example specifically 663 00:37:18,890 --> 00:37:26,319 for this IB B which is the window 664 00:37:21,080 --> 00:37:30,319 covered by these hashes and also if the 665 00:37:26,320 --> 00:37:33,979 vendor make a mistake on the 666 00:37:30,319 --> 00:37:37,219 hovering the BIOS update with IBB hashes 667 00:37:33,979 --> 00:37:39,769 so it can be some window which has been 668 00:37:37,219 --> 00:37:41,869 unprotected an attacker can use it for 669 00:37:39,769 --> 00:37:46,339 modifying that if it will be like 670 00:37:41,869 --> 00:37:52,789 executable code it's like the flow for 671 00:37:46,339 --> 00:37:57,170 delivering some rootkit also interesting 672 00:37:52,789 --> 00:38:01,969 part it's authenticated code model which 673 00:37:57,170 --> 00:38:05,479 is all the ACMs which is i seen before 674 00:38:01,969 --> 00:38:08,719 like it's shivered by intel and it has 675 00:38:05,479 --> 00:38:12,049 some header which is actually pointing 676 00:38:08,719 --> 00:38:13,640 to entry point inside the ACM model and 677 00:38:12,049 --> 00:38:18,579 they say model actually executes since 678 00:38:13,640 --> 00:38:24,589 the hash in the cache and we do have a 679 00:38:18,579 --> 00:38:29,619 digital sign for four for each ACM model 680 00:38:24,589 --> 00:38:32,828 and it's actually will be verified by 681 00:38:29,619 --> 00:38:32,829 micro code 682 00:38:36,960 --> 00:38:46,859 so what kind of things actually what 683 00:38:41,490 --> 00:38:52,430 kind of parameters for for a cm we have 684 00:38:46,859 --> 00:38:55,710 so it's x86 code specifically 32-bit 685 00:38:52,430 --> 00:38:58,680 execute in a serum which is kind of 686 00:38:55,710 --> 00:39:05,190 caches Ram also known as non-addicted 687 00:38:58,680 --> 00:39:08,029 mod and it's all the ACMs it's CPU and 688 00:39:05,190 --> 00:39:10,619 chipset specifics so it's because 689 00:39:08,030 --> 00:39:12,829 microcode willand eight the sign so if 690 00:39:10,619 --> 00:39:16,589 your cpu generation doesn't have 691 00:39:12,829 --> 00:39:21,720 verification for your ACM it will be not 692 00:39:16,589 --> 00:39:29,549 executed and ACM verify the community 693 00:39:21,720 --> 00:39:32,609 and IBM policy I start thinking about 694 00:39:29,550 --> 00:39:36,780 like okay we have executed executable 695 00:39:32,609 --> 00:39:42,299 code inside a CMS and I will construct 696 00:39:36,780 --> 00:39:45,480 some some format and build some loader 697 00:39:42,299 --> 00:39:48,900 simple loader for Friday but most 698 00:39:45,480 --> 00:39:52,470 interesting thing it's like how if we 699 00:39:48,900 --> 00:39:56,099 bend Eve different generation of of a 700 00:39:52,470 --> 00:39:58,618 CMS actually a CMS for different 701 00:39:56,099 --> 00:40:00,390 generation of CPUs how it will be looks 702 00:39:58,619 --> 00:40:05,220 like for one technology like a boot 703 00:40:00,390 --> 00:40:07,650 guard right so and actually ACM code 704 00:40:05,220 --> 00:40:10,740 it's pretty complex we have a flow even 705 00:40:07,650 --> 00:40:19,349 like we have some cryptic verifications 706 00:40:10,740 --> 00:40:21,930 there for sha-256 era say and it's 707 00:40:19,349 --> 00:40:28,230 everything is there right so and it's 708 00:40:21,930 --> 00:40:31,770 pretty complex technologies so its flow 709 00:40:28,230 --> 00:40:35,869 from a sim but most interesting part 710 00:40:31,770 --> 00:40:39,420 it's I make some bean dip with different 711 00:40:35,869 --> 00:40:41,819 different generation of CPUs so has both 712 00:40:39,420 --> 00:40:44,579 where's the sky wake and I doesn't found 713 00:40:41,819 --> 00:40:47,730 too much here I don't know maybe I've 714 00:40:44,579 --> 00:40:50,560 been just unlucky but I found the really 715 00:40:47,730 --> 00:40:53,710 small change but when I 716 00:40:50,560 --> 00:40:57,850 did some bindi fees broad well where's 717 00:40:53,710 --> 00:41:01,650 the sky wake I found like a lot of 718 00:40:57,850 --> 00:41:04,990 changes and this changes show me like 719 00:41:01,650 --> 00:41:07,990 this kind of parcels has a lot of issues 720 00:41:04,990 --> 00:41:11,649 like some of them integer overflows some 721 00:41:07,990 --> 00:41:13,569 of them really like mistakes in the code 722 00:41:11,650 --> 00:41:18,760 or whatever but it's a lot of patches 723 00:41:13,570 --> 00:41:21,220 being there so and let's talk a bit how 724 00:41:18,760 --> 00:41:24,010 how many components bias Guard has 725 00:41:21,220 --> 00:41:26,379 incites bias so we do have a platform 726 00:41:24,010 --> 00:41:29,260 initialization model model like boot 727 00:41:26,380 --> 00:41:31,570 guard pay SMA which is actually verify 728 00:41:29,260 --> 00:41:35,110 firmware boot guard from ISM I am when 729 00:41:31,570 --> 00:41:37,390 it will be like not fully rebooted the 730 00:41:35,110 --> 00:41:40,330 Carter will be not fully rebooted and 731 00:41:37,390 --> 00:41:43,810 it's just like warm aggressive and Dixie 732 00:41:40,330 --> 00:41:48,850 which is verify the boot guard for from 733 00:41:43,810 --> 00:41:54,180 s3 sleep mode here is a flow for the pay 734 00:41:48,850 --> 00:41:59,770 validation and we can see here actually 735 00:41:54,180 --> 00:42:04,390 in this flow its calculate the hash and 736 00:41:59,770 --> 00:42:07,840 it stores the hash but we also have a 737 00:42:04,390 --> 00:42:10,839 flock which is 0 or 1 in specific case 738 00:42:07,840 --> 00:42:14,230 and it shows it's really dated or not 739 00:42:10,840 --> 00:42:17,830 and it's passing to good guard dixie 740 00:42:14,230 --> 00:42:25,570 driver so and it's actually will a date 741 00:42:17,830 --> 00:42:34,990 pay firmware hash which is covered of 742 00:42:25,570 --> 00:42:37,900 the firmware in my case and what happens 743 00:42:34,990 --> 00:42:40,799 actually how how we fight would guard 744 00:42:37,900 --> 00:42:45,160 from Assam and validation flow works 745 00:42:40,800 --> 00:42:47,320 it's fine and verify ACM and verify all 746 00:42:45,160 --> 00:42:49,870 the keys I will be a bit speed up 747 00:42:47,320 --> 00:42:54,010 because I have just seven minutes I 748 00:42:49,870 --> 00:42:57,850 think so most interesting thing can this 749 00:42:54,010 --> 00:42:59,020 wide as I say it said flag for 0 to 1 750 00:42:57,850 --> 00:43:04,020 true or false 751 00:42:59,020 --> 00:43:04,020 when the validation is right and 752 00:43:04,409 --> 00:43:10,659 here is actually yeah I chose this issue 753 00:43:07,569 --> 00:43:12,729 on on blackhat now it's a rigid fix it 754 00:43:10,659 --> 00:43:14,739 on mostly on all the vendors and it's 755 00:43:12,729 --> 00:43:17,319 been fun because some of the vendors 756 00:43:14,739 --> 00:43:19,299 from like huge enterprises came to me 757 00:43:17,319 --> 00:43:22,569 and say oh we just recently patch it and 758 00:43:19,299 --> 00:43:25,899 I don't have a time to really like 759 00:43:22,569 --> 00:43:32,969 follow all process to discuss this issue 760 00:43:25,899 --> 00:43:37,808 and its small back actually and think is 761 00:43:32,969 --> 00:43:42,309 this logical back opens the door when 762 00:43:37,809 --> 00:43:44,969 you have like a story set to put some 763 00:43:42,309 --> 00:43:48,880 malicious components are caught inside 764 00:43:44,969 --> 00:43:53,349 your buyers and boot guard wheel doesn't 765 00:43:48,880 --> 00:43:56,679 help here and actually embedded as a 766 00:43:53,349 --> 00:44:00,699 company recently based on top of my 767 00:43:56,679 --> 00:44:05,319 research released same thing to Intel 768 00:44:00,699 --> 00:44:07,569 knock and it's a really budget and they 769 00:44:05,319 --> 00:44:10,779 do have some blog post which is a bit 770 00:44:07,569 --> 00:44:17,769 provide more detail about how they 771 00:44:10,779 --> 00:44:22,029 exploited here is my target platform and 772 00:44:17,769 --> 00:44:25,299 its sixth generation Quran skylake bias 773 00:44:22,029 --> 00:44:27,639 guard is enabled and boot boot guard is 774 00:44:25,299 --> 00:44:31,779 enabled by as guard is not here is 775 00:44:27,639 --> 00:44:33,639 vulnerabilities both as we can see it's 776 00:44:31,779 --> 00:44:35,469 for bypassing the boot guards need to 777 00:44:33,639 --> 00:44:37,839 vulnerabilities first its write read 778 00:44:35,469 --> 00:44:40,119 access to me and second one as a 779 00:44:37,839 --> 00:44:43,119 configuration for the boot guard is not 780 00:44:40,119 --> 00:44:45,969 locked why we need a vulnerability for a 781 00:44:43,119 --> 00:44:50,099 me because we need to lock the fuse and 782 00:44:45,969 --> 00:44:53,349 the fuse can be locked only from email 783 00:44:50,099 --> 00:44:57,659 so here is the details from intoa me 784 00:44:53,349 --> 00:45:01,689 tool so on this platform as we can see 785 00:44:57,659 --> 00:45:05,739 if PF doesn't set but the public key for 786 00:45:01,689 --> 00:45:09,189 from I am is is in a place and we fight 787 00:45:05,739 --> 00:45:12,099 boot and measured boot is enabled but 788 00:45:09,189 --> 00:45:16,569 also we can see like a me region has 789 00:45:12,099 --> 00:45:17,290 access for read and write so here is 790 00:45:16,569 --> 00:45:20,680 shows way 791 00:45:17,290 --> 00:45:23,830 we have most strong mode for boot guard 792 00:45:20,680 --> 00:45:26,109 enabled and funny fact from gigabyte 793 00:45:23,830 --> 00:45:28,870 official website they proposed this card 794 00:45:26,110 --> 00:45:33,550 work for like governmental for critical 795 00:45:28,870 --> 00:45:35,319 infrastructure for hospitals but don't 796 00:45:33,550 --> 00:45:38,650 care too much about the security and 797 00:45:35,320 --> 00:45:40,270 here is a flow which is shows how the 798 00:45:38,650 --> 00:45:42,730 boot guard can be bypassed so we 799 00:45:40,270 --> 00:45:44,890 actually because we control every all 800 00:45:42,730 --> 00:45:46,480 the structures or the policies inside 801 00:45:44,890 --> 00:45:52,750 the firmware we just modify all the 802 00:45:46,480 --> 00:45:55,420 things like and that's it and if it's 803 00:45:52,750 --> 00:45:59,050 not locked in the hardware so we just 804 00:45:55,420 --> 00:46:01,900 actually can bypass all the boot guard 805 00:45:59,050 --> 00:46:07,000 policies so here is the intel statement 806 00:46:01,900 --> 00:46:10,030 and intel says like third-party SI 807 00:46:07,000 --> 00:46:12,850 babies should actually lock the boot 808 00:46:10,030 --> 00:46:18,130 guard root of trust inside the hardware 809 00:46:12,850 --> 00:46:22,360 and and it's probably written in the 810 00:46:18,130 --> 00:46:24,880 specification too so it's gigabyte 811 00:46:22,360 --> 00:46:27,300 statement which is say like they release 812 00:46:24,880 --> 00:46:30,130 its update what the update should be 813 00:46:27,300 --> 00:46:33,070 separately from the bios update download 814 00:46:30,130 --> 00:46:35,110 from the website of vendor and installed 815 00:46:33,070 --> 00:46:40,660 and i don't know how many users will do 816 00:46:35,110 --> 00:46:43,540 that right this month actually last 817 00:46:40,660 --> 00:46:45,779 month i developed you fi to update for 818 00:46:43,540 --> 00:46:51,310 into a boot guard visual verification 819 00:46:45,780 --> 00:46:53,680 and it shows specifically how many 820 00:46:51,310 --> 00:46:55,720 firmware volumes and what kind of 821 00:46:53,680 --> 00:46:57,750 drivers is covered here is a blog post 822 00:46:55,720 --> 00:47:02,350 here is a link to the tool and 823 00:46:57,750 --> 00:47:05,770 specifically for blue heart this sunday 824 00:47:02,350 --> 00:47:08,620 I push the update for you if I to in now 825 00:47:05,770 --> 00:47:12,250 it supports surface laptops to and 826 00:47:08,620 --> 00:47:14,680 actually I've been surprised and on 827 00:47:12,250 --> 00:47:17,020 surface they did a bit in-house 828 00:47:14,680 --> 00:47:19,990 implementation of into boot guard 829 00:47:17,020 --> 00:47:21,970 technology and it's much better than 830 00:47:19,990 --> 00:47:25,450 others we under not all of the others 831 00:47:21,970 --> 00:47:27,569 but a lot of so here is a link on my 832 00:47:25,450 --> 00:47:29,410 blog cut research and actually I will be 833 00:47:27,570 --> 00:47:33,190 update 834 00:47:29,410 --> 00:47:36,009 after zero nights with all the my 835 00:47:33,190 --> 00:47:39,100 templates 4:01 editor and all the 836 00:47:36,010 --> 00:47:41,440 scripts for item thank you very much for 837 00:47:39,100 --> 00:47:43,360 your attention and if you have any 838 00:47:41,440 --> 00:47:45,970 questions I will be happy to answer and 839 00:47:43,360 --> 00:47:50,740 I hope you have the time yeah we do have 840 00:47:45,970 --> 00:47:52,200 three minutes okay microphone runners 841 00:47:50,740 --> 00:47:56,220 will be ready to take your questions 842 00:47:52,200 --> 00:47:56,220 make them interesting 843 00:48:07,700 --> 00:48:15,640 I I noticed that you mentioned that only 844 00:48:12,589 --> 00:48:19,029 some of the regions of buyers are 845 00:48:15,640 --> 00:48:24,740 protected behind the RSA signatures why 846 00:48:19,030 --> 00:48:27,980 why not sign the entire image instead so 847 00:48:24,740 --> 00:48:30,379 they sign so actually not like that 848 00:48:27,980 --> 00:48:32,809 the signature protect I BB which is 849 00:48:30,380 --> 00:48:36,319 contains the hashes and as you can see 850 00:48:32,809 --> 00:48:38,599 like hashes is sign it and you can't 851 00:48:36,319 --> 00:48:41,390 modify the hashes and hashes actually 852 00:48:38,599 --> 00:48:45,920 covered all the buyers usually what it 853 00:48:41,390 --> 00:48:48,470 is cannot so what what is the reason for 854 00:48:45,920 --> 00:48:50,450 for like even even allowing mechanism 855 00:48:48,470 --> 00:48:53,359 make more flexible the technology for 856 00:48:50,450 --> 00:48:55,520 third parties so so that they don't have 857 00:48:53,359 --> 00:48:59,270 to go through hassles of signing every 858 00:48:55,520 --> 00:49:04,520 release of bias or as examples they can 859 00:48:59,270 --> 00:49:08,960 sign different pieces of the image 860 00:49:04,520 --> 00:49:12,200 different way as example or one vendor 861 00:49:08,960 --> 00:49:15,319 control sign of one piece and another 862 00:49:12,200 --> 00:49:18,399 from another piece of image thank you I 863 00:49:15,319 --> 00:49:24,520 don't know it's my opinion but I'm not a 864 00:49:18,400 --> 00:49:27,170 hardware developer manufacturer and 865 00:49:24,520 --> 00:49:31,869 actually technology's undocumented is 866 00:49:27,170 --> 00:49:31,869 just gas I can be wrong 867 00:49:41,590 --> 00:49:50,820 no more questions just a simple one 868 00:49:46,660 --> 00:49:50,819 when's the book gonna be completed 869 00:49:51,450 --> 00:50:01,149 when's the book gonna be ready good the 870 00:49:54,490 --> 00:50:04,810 book Oh actually we made some early 871 00:50:01,150 --> 00:50:07,600 release for the DEF CON and it's been 872 00:50:04,810 --> 00:50:10,000 sold out so all the book it's already 873 00:50:07,600 --> 00:50:13,060 ready early access will be updated this 874 00:50:10,000 --> 00:50:17,710 month for all the chapters and printed 875 00:50:13,060 --> 00:50:19,299 in January sorry have you guys 876 00:50:17,710 --> 00:50:24,700 considered including anything about 877 00:50:19,300 --> 00:50:27,010 grayish we don't have so we already 878 00:50:24,700 --> 00:50:28,689 extend like a lot of chapters for the 879 00:50:27,010 --> 00:50:36,390 bias and we have a pressure from 880 00:50:28,690 --> 00:50:39,490 publisher to not add anything more so 881 00:50:36,390 --> 00:50:41,350 probably next book will be like open 882 00:50:39,490 --> 00:50:44,439 wiki book because it will be easier to 883 00:50:41,350 --> 00:50:52,690 add more and more contact and don't have 884 00:50:44,440 --> 00:50:54,880 logistics with publisher right so in a 885 00:50:52,690 --> 00:50:57,010 perfect world if you got to decide 886 00:50:54,880 --> 00:50:59,590 exactly how the disclosure process went 887 00:50:57,010 --> 00:51:02,980 with the vendors what would be your a 888 00:50:59,590 --> 00:51:05,740 perfect version you know like it's 889 00:51:02,980 --> 00:51:08,590 difficult because perfect world for the 890 00:51:05,740 --> 00:51:12,819 vendor it's one world perfect world for 891 00:51:08,590 --> 00:51:18,180 researcher I I am both side side right 892 00:51:12,820 --> 00:51:21,520 so it's difficult actually I think like 893 00:51:18,180 --> 00:51:24,850 at least I expect some collaboration 894 00:51:21,520 --> 00:51:27,310 from the vendor side because like if you 895 00:51:24,850 --> 00:51:31,779 send something then like send follow-up 896 00:51:27,310 --> 00:51:34,390 email and the vendor like reply no box 897 00:51:31,780 --> 00:51:36,760 but then release its update silently 898 00:51:34,390 --> 00:51:40,089 with your box budget it's a bad way 899 00:51:36,760 --> 00:51:44,730 right so here is like some should be 900 00:51:40,090 --> 00:51:49,000 best practices exist right for that like 901 00:51:44,730 --> 00:51:51,280 be polite with researcher and the 902 00:51:49,000 --> 00:51:53,970 searcher will be polite view people head 903 00:51:51,280 --> 00:51:53,970 with the vendor 904 00:51:55,310 --> 00:52:03,900 so because like in the u5 world it's not 905 00:52:01,800 --> 00:52:06,180 a lot of bug bounties actually intel 906 00:52:03,900 --> 00:52:08,790 offer one but it's covered on these 907 00:52:06,180 --> 00:52:11,190 their products and their CPUs it's also 908 00:52:08,790 --> 00:52:13,350 included the hardware box for u5 909 00:52:11,190 --> 00:52:15,060 firmware it's just for Xanax NC servers 910 00:52:13,350 --> 00:52:18,120 so it's not a lot 911 00:52:15,060 --> 00:52:21,920 so probably Microsoft will be introduced 912 00:52:18,120 --> 00:52:33,440 some bug bounty for surface I don't know 913 00:52:21,920 --> 00:52:33,440 thank you one more question here 914 00:52:40,589 --> 00:52:46,509 just out of curiosity you mentioned that 915 00:52:44,140 --> 00:52:49,569 vendors have a lot like obviously have 916 00:52:46,510 --> 00:52:52,420 bugs and then he asked us who updated 917 00:52:49,569 --> 00:52:55,029 our bias recently so the question is 918 00:52:52,420 --> 00:52:58,089 just again out of curiosity is there any 919 00:52:55,030 --> 00:53:00,099 common techniques or procedures to 920 00:52:58,089 --> 00:53:02,558 basically push the pressure on customer 921 00:53:00,099 --> 00:53:06,910 to update bias or how it's done in 922 00:53:02,559 --> 00:53:08,829 hardware you can't push the customer 923 00:53:06,910 --> 00:53:13,118 site and what you apply you update your 924 00:53:08,829 --> 00:53:16,660 bias or none okay I'm kidding 925 00:53:13,119 --> 00:53:19,059 so actually it's no pressure to to 926 00:53:16,660 --> 00:53:22,540 customers because it's like okay 927 00:53:19,059 --> 00:53:24,700 probably if updates as example for 928 00:53:22,540 --> 00:53:26,290 Windows software will be delivered by 929 00:53:24,700 --> 00:53:28,930 Windows Update process it will be 930 00:53:26,290 --> 00:53:31,410 perfect world but it's like this perfect 931 00:53:28,930 --> 00:53:35,290 world will be never happens because we 932 00:53:31,410 --> 00:53:37,720 need from the vendor they should prepare 933 00:53:35,290 --> 00:53:40,119 the update for specific time frame right 934 00:53:37,720 --> 00:53:42,129 to be delivered and also it should be 935 00:53:40,119 --> 00:53:44,020 like unified process to update the 936 00:53:42,130 --> 00:53:46,450 systems and this also will be never 937 00:53:44,020 --> 00:53:48,400 happens because all the vendors have 938 00:53:46,450 --> 00:53:52,058 some house features which is very 939 00:53:48,400 --> 00:53:53,920 specific for us rail hardware so and I 940 00:53:52,059 --> 00:53:55,839 don't know actually for the big 941 00:53:53,920 --> 00:53:57,940 companies it's important and 942 00:53:55,839 --> 00:54:00,160 specifically also for the data centers 943 00:53:57,940 --> 00:54:02,740 it's important to probably have some 944 00:54:00,160 --> 00:54:04,930 process at least make some health checks 945 00:54:02,740 --> 00:54:07,720 for their Hardware of biases what I 946 00:54:04,930 --> 00:54:12,578 think but it's basically like you know 947 00:54:07,720 --> 00:54:15,129 on customer itself no no unified 948 00:54:12,579 --> 00:54:18,760 solution here and it will be never 949 00:54:15,130 --> 00:54:19,990 happen sexually what I think okay so 950 00:54:18,760 --> 00:54:21,460 unfortunately we do have to end 951 00:54:19,990 --> 00:54:22,058 questions for Alex because we have the 952 00:54:21,460 --> 00:54:23,740 next set 953 00:54:22,059 --> 00:54:25,010 so round of applause for Alex thank you 954 00:54:23,740 --> 00:54:27,069 very much 955 00:54:25,010 --> 00:54:27,070 you