0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/397 Thanks! 1 00:00:11,110 --> 00:00:13,719 All right, thank you, General Hudson, and 2 00:00:13,720 --> 00:00:15,759 I really like to take things apart, so in 3 00:00:15,760 --> 00:00:17,259 this talk, I'm going to be talking about 4 00:00:17,260 --> 00:00:19,389 Thunder Strike, which is a SFI 5 00:00:19,390 --> 00:00:22,089 firmware rootkit for Apple MacBook. 6 00:00:22,090 --> 00:00:24,399 And the talk is going to have 7 00:00:24,400 --> 00:00:26,409 a few parts. The first half is going to 8 00:00:26,410 --> 00:00:28,479 be about the sort of the journey 9 00:00:28,480 --> 00:00:30,639 of reverse engineering, the EFI boot 10 00:00:30,640 --> 00:00:33,189 rom in the MacBook. 11 00:00:33,190 --> 00:00:35,049 The second half is going to be about 12 00:00:35,050 --> 00:00:36,759 developing the Thunder strike 13 00:00:36,760 --> 00:00:38,889 vulnerability and then 14 00:00:38,890 --> 00:00:40,509 the third half is going to be that 15 00:00:40,510 --> 00:00:41,649 mitigation strategies. 16 00:00:41,650 --> 00:00:43,599 What can we do to prevent it that 17 00:00:43,600 --> 00:00:45,819 hopefully are better than EPOXI in 18 00:00:45,820 --> 00:00:46,820 the ports shut? 19 00:00:47,890 --> 00:00:50,169 So reverse engineering is a hobby 20 00:00:50,170 --> 00:00:51,159 of mine. 21 00:00:51,160 --> 00:00:53,289 One of my more famous projects is the 22 00:00:53,290 --> 00:00:55,479 magic lantern firmware for the Canon 23 00:00:55,480 --> 00:00:58,059 Cameras. It's a old runtime 24 00:00:58,060 --> 00:01:00,609 that lets you write your own software. 25 00:01:00,610 --> 00:01:02,799 I also thank 26 00:01:02,800 --> 00:01:03,800 you. 27 00:01:08,010 --> 00:01:10,259 I also really enjoy retro computing and 28 00:01:10,260 --> 00:01:12,359 digging through old computers and in the 29 00:01:12,360 --> 00:01:14,219 ROMs to see what sort of Easter eggs 30 00:01:14,220 --> 00:01:16,379 there are, such as this Mac 31 00:01:16,380 --> 00:01:18,479 that contains a four photos 32 00:01:18,480 --> 00:01:20,699 of the team that worked on it back in 33 00:01:20,700 --> 00:01:21,700 the mid 80s. 34 00:01:22,650 --> 00:01:24,779 And I'd really like to thank my firm, Two 35 00:01:24,780 --> 00:01:25,719 Sigma Investments. 36 00:01:25,720 --> 00:01:27,539 It's a high tech hedge fund in New York 37 00:01:27,540 --> 00:01:29,729 City that has encouraged 38 00:01:29,730 --> 00:01:32,189 me to do this research and to publish 39 00:01:32,190 --> 00:01:34,289 it. I'd especially like to thank my 40 00:01:34,290 --> 00:01:36,389 colleagues, Thor, Simon, Victor 41 00:01:36,390 --> 00:01:38,009 Tacony and Larry Rudolph for their 42 00:01:38,010 --> 00:01:39,569 assistance in preparing this for 43 00:01:39,570 --> 00:01:40,859 publication. 44 00:01:40,860 --> 00:01:42,719 You might ask, why is a hedge fund 45 00:01:42,720 --> 00:01:45,369 interested in this sort of vulnerability? 46 00:01:45,370 --> 00:01:47,429 And it really comes down to security 47 00:01:47,430 --> 00:01:49,319 that we care about the security of our 48 00:01:49,320 --> 00:01:50,999 data and of our systems. 49 00:01:51,000 --> 00:01:53,129 And we'd heard about some some 50 00:01:53,130 --> 00:01:55,079 attacks on Mac books and we were thinking 51 00:01:55,080 --> 00:01:56,039 about deploying them. 52 00:01:56,040 --> 00:01:58,289 So I was asked to use my reverse 53 00:01:58,290 --> 00:02:00,989 engineering skills to look into 54 00:02:00,990 --> 00:02:02,040 some of these attacks. 55 00:02:03,420 --> 00:02:05,279 So I started by going through and reading 56 00:02:05,280 --> 00:02:07,949 and watching conference presentations, 57 00:02:07,950 --> 00:02:10,138 and there's an enormous amount of 58 00:02:10,139 --> 00:02:12,059 marvelous presentations, in fact, a lot 59 00:02:12,060 --> 00:02:14,159 by people who are even 60 00:02:14,160 --> 00:02:16,499 here today, that that helped 61 00:02:16,500 --> 00:02:18,689 teach me about how systems boot 62 00:02:18,690 --> 00:02:20,939 and how to protect 63 00:02:20,940 --> 00:02:22,379 the boot process. 64 00:02:22,380 --> 00:02:25,229 Although most of them are looking at the 65 00:02:25,230 --> 00:02:27,449 the Intel and Windows side of things, 66 00:02:27,450 --> 00:02:28,859 the secure boot path. 67 00:02:28,860 --> 00:02:31,259 And comparatively few are looking 68 00:02:31,260 --> 00:02:33,599 at Apple's 69 00:02:33,600 --> 00:02:35,669 boot time security or things like 70 00:02:35,670 --> 00:02:37,469 Thunderbolt security. 71 00:02:37,470 --> 00:02:39,629 The Snares Black 72 00:02:39,630 --> 00:02:41,699 Hat presentation in 2012 was one 73 00:02:41,700 --> 00:02:43,340 that actually started me on this project. 74 00:02:44,430 --> 00:02:46,289 So with most reverse engineering 75 00:02:46,290 --> 00:02:47,849 projects, the first thing that you need 76 00:02:47,850 --> 00:02:49,949 to do is get into the system to get 77 00:02:49,950 --> 00:02:52,079 a feel for what's there. 78 00:02:52,080 --> 00:02:54,299 Apple uses these little screws 79 00:02:54,300 --> 00:02:56,489 to make it a little bit more difficult 80 00:02:56,490 --> 00:02:57,899 to get in. 81 00:02:57,900 --> 00:02:59,909 I did it the old fashioned way, made a 82 00:02:59,910 --> 00:03:01,379 bit of a mess. 83 00:03:01,380 --> 00:03:03,479 But you can also buy screwdrivers 84 00:03:03,480 --> 00:03:04,949 for a few dollars or a few euros. 85 00:03:06,750 --> 00:03:08,939 So once you get inside, Apple has done 86 00:03:08,940 --> 00:03:10,919 a beautiful job on the esthetics of this 87 00:03:10,920 --> 00:03:12,569 machine, despite the fact that they make 88 00:03:12,570 --> 00:03:13,979 it so hard to get into. 89 00:03:13,980 --> 00:03:15,629 They've they've really paid a lot of 90 00:03:15,630 --> 00:03:16,919 attention to the esthetics and the 91 00:03:16,920 --> 00:03:18,209 layout. 92 00:03:18,210 --> 00:03:20,279 Usually what happens with malware is 93 00:03:20,280 --> 00:03:22,229 it comes in over the Wi-Fi or the 94 00:03:22,230 --> 00:03:24,389 Ethernet gets a buffer overflow 95 00:03:24,390 --> 00:03:26,579 into into RAM, get some code 96 00:03:26,580 --> 00:03:28,649 running on the CPU that eventually 97 00:03:28,650 --> 00:03:30,719 writes something to the to 98 00:03:30,720 --> 00:03:31,720 the hard drive. 99 00:03:32,430 --> 00:03:34,469 What this talk about, though, is the boot 100 00:03:34,470 --> 00:03:37,439 from now, which is this chip over here. 101 00:03:37,440 --> 00:03:39,509 If we zoom into it, we can read out 102 00:03:39,510 --> 00:03:41,639 the part number, the two five 103 00:03:41,640 --> 00:03:43,050 six four zero six, 104 00:03:44,070 --> 00:03:46,109 and we can look up the data sheet. 105 00:03:46,110 --> 00:03:48,359 It's a sixty four megabit, eight 106 00:03:48,360 --> 00:03:50,789 megabyte serial flash 107 00:03:50,790 --> 00:03:52,319 and we call it a boot rom. 108 00:03:52,320 --> 00:03:54,179 But it's really an easy problem with 109 00:03:54,180 --> 00:03:55,889 flash memory in it. 110 00:03:55,890 --> 00:03:58,079 S.P.I means that it has 111 00:03:58,080 --> 00:04:00,479 data in, data out and 112 00:04:00,480 --> 00:04:02,789 external clock that's controlled 113 00:04:02,790 --> 00:04:04,879 by external hardware. 114 00:04:06,180 --> 00:04:08,279 You put a lot of other researchers 115 00:04:08,280 --> 00:04:10,229 have done is used the the bus pirate, 116 00:04:10,230 --> 00:04:12,659 which is a off the shelf logic 117 00:04:12,660 --> 00:04:15,419 analyzer tool, and 118 00:04:15,420 --> 00:04:16,919 it comes to these test clips so you can 119 00:04:16,920 --> 00:04:18,389 easily hook it up. 120 00:04:18,390 --> 00:04:20,578 The problem is that the bus pirates kind 121 00:04:20,579 --> 00:04:22,589 of slow. It takes a couple hours to to 122 00:04:22,590 --> 00:04:24,119 read and write the ROM and it's very 123 00:04:24,120 --> 00:04:25,259 fiddly. 124 00:04:25,260 --> 00:04:27,299 Since I do a lot of work with ROMs, I've 125 00:04:27,300 --> 00:04:28,380 actually built a 126 00:04:29,730 --> 00:04:32,189 a spy flash reader 127 00:04:32,190 --> 00:04:33,869 based on a teensy, which is kind of like 128 00:04:33,870 --> 00:04:36,159 nor do we know the sources are 129 00:04:36,160 --> 00:04:38,429 GPL and you can download them and 130 00:04:38,430 --> 00:04:39,430 have at it. 131 00:04:40,200 --> 00:04:41,939 This one can read the wrong in a few 132 00:04:41,940 --> 00:04:44,939 seconds and write it in about a minute. 133 00:04:44,940 --> 00:04:46,949 One word of caution. 134 00:04:46,950 --> 00:04:49,079 If you're doing reverse engineering of 135 00:04:49,080 --> 00:04:51,449 this, disconnect the battery before you 136 00:04:51,450 --> 00:04:53,669 hook up the external programmer. 137 00:04:53,670 --> 00:04:55,469 Otherwise there you'll have conflicting 138 00:04:55,470 --> 00:04:56,579 voltages on the rails. 139 00:04:56,580 --> 00:04:59,129 And as the voice of experience, 140 00:04:59,130 --> 00:05:00,399 that's not a good thing. 141 00:05:01,710 --> 00:05:02,710 So 142 00:05:03,900 --> 00:05:05,579 two years ago, when Snare was doing his 143 00:05:05,580 --> 00:05:07,739 work, he found that if he changed 144 00:05:07,740 --> 00:05:09,809 the ram at all, the machine wouldn't 145 00:05:09,810 --> 00:05:12,659 boot. And he conjectured 146 00:05:12,660 --> 00:05:14,519 that there's something checking a 147 00:05:14,520 --> 00:05:15,870 signature on the boot room. 148 00:05:17,190 --> 00:05:18,869 And that made me very curious. 149 00:05:18,870 --> 00:05:20,429 You know, what is doing that check? 150 00:05:21,570 --> 00:05:23,669 So I repeated his his 151 00:05:23,670 --> 00:05:25,769 work and I made a one by change to 152 00:05:25,770 --> 00:05:26,999 somewhere in the room. 153 00:05:27,000 --> 00:05:29,069 And the result is 154 00:05:29,070 --> 00:05:31,349 pretty much a bricked machine, that 155 00:05:31,350 --> 00:05:34,229 there's no lights, no sound, 156 00:05:34,230 --> 00:05:36,419 no sign of any life at all from 157 00:05:36,420 --> 00:05:37,769 the outside. 158 00:05:37,770 --> 00:05:40,049 But since we have the bottom 159 00:05:40,050 --> 00:05:41,399 off, we can flip it over and we can look 160 00:05:41,400 --> 00:05:42,509 at the inside. 161 00:05:42,510 --> 00:05:44,729 And when we power it up, 162 00:05:44,730 --> 00:05:47,189 the fans spin up the 163 00:05:47,190 --> 00:05:49,379 CPU cooling fans and then a few seconds 164 00:05:49,380 --> 00:05:51,179 later they spin down. 165 00:05:52,480 --> 00:05:55,269 And that indicates that something 166 00:05:55,270 --> 00:05:56,999 is check in the room. 167 00:05:57,000 --> 00:05:58,359 It could be an external piece of 168 00:05:58,360 --> 00:06:00,099 hardware, which is a lot of folks have 169 00:06:00,100 --> 00:06:02,499 conjectured or it might just be something 170 00:06:02,500 --> 00:06:03,879 in the boot room itself, 171 00:06:05,230 --> 00:06:07,349 which, of course, we just 172 00:06:07,350 --> 00:06:09,879 to question what is doing that 173 00:06:09,880 --> 00:06:12,069 if it is only software, 174 00:06:12,070 --> 00:06:13,209 we could perhaps 175 00:06:14,680 --> 00:06:16,809 bypass that check 176 00:06:16,810 --> 00:06:18,549 in. The easiest way to figure that out 177 00:06:18,550 --> 00:06:20,499 would be to change the first instruction 178 00:06:20,500 --> 00:06:22,689 they could run and find 179 00:06:22,690 --> 00:06:24,069 out what that is. 180 00:06:24,070 --> 00:06:26,349 We go back to the late 70s, 181 00:06:26,350 --> 00:06:28,709 early 80s for the 182 00:06:28,710 --> 00:06:30,969 80, because when you're modern, actually 183 00:06:30,970 --> 00:06:33,099 664 starts up it boots in 184 00:06:33,100 --> 00:06:35,169 real mode and reads the 185 00:06:35,170 --> 00:06:37,299 first instruction from 186 00:06:37,300 --> 00:06:39,339 what at the time was the top of physical 187 00:06:39,340 --> 00:06:41,409 memory at one megabyte and 188 00:06:41,410 --> 00:06:43,659 then does a jump somewhere elsewhere 189 00:06:43,660 --> 00:06:45,639 in memory to finish the initialization 190 00:06:47,110 --> 00:06:49,089 using the bus pirate or the flash from 191 00:06:49,090 --> 00:06:51,309 Tooele or my S.P.I Flash Reader. 192 00:06:51,310 --> 00:06:53,379 We can disassemble that part of the 193 00:06:53,380 --> 00:06:55,599 ROM and we find that 194 00:06:55,600 --> 00:06:57,879 indeed it starts the cache invalidate 195 00:06:57,880 --> 00:06:59,979 that's actually new, but it has 196 00:06:59,980 --> 00:07:02,049 a jump lower in memory 197 00:07:02,050 --> 00:07:04,389 to finish the initialization. 198 00:07:04,390 --> 00:07:06,459 What if we changed the address that that 199 00:07:06,460 --> 00:07:09,189 jumps to? So rather than jumping 200 00:07:09,190 --> 00:07:11,379 off to there, it just creates an infinite 201 00:07:11,380 --> 00:07:13,549 loop and will 202 00:07:13,550 --> 00:07:15,699 just spin there when 203 00:07:15,700 --> 00:07:18,279 we flash using the system programmer, 204 00:07:18,280 --> 00:07:20,589 when we flash this into the room, 205 00:07:20,590 --> 00:07:22,539 there are two possibilities that could 206 00:07:22,540 --> 00:07:23,799 happen. 207 00:07:23,800 --> 00:07:26,019 The fans might spin up and then spin 208 00:07:26,020 --> 00:07:28,149 down again, which would mean that 209 00:07:28,150 --> 00:07:29,919 there is something outside that's 210 00:07:29,920 --> 00:07:31,450 actually check in that room 211 00:07:32,500 --> 00:07:34,359 or the fans might just keep spinning 212 00:07:34,360 --> 00:07:36,549 continuously, which would indicate 213 00:07:36,550 --> 00:07:39,060 that that is only a software check. 214 00:07:41,380 --> 00:07:42,639 I'm up here today, so there's probably 215 00:07:42,640 --> 00:07:44,289 not too much of a surprise as to what 216 00:07:44,290 --> 00:07:46,599 happens. But yes, the fans stay 217 00:07:46,600 --> 00:07:48,699 on. So this gives us 218 00:07:48,700 --> 00:07:50,799 one bit of output before the rest 219 00:07:50,800 --> 00:07:52,839 of the system has started that we now 220 00:07:52,840 --> 00:07:54,939 know a way to signal 221 00:07:54,940 --> 00:07:56,199 what's going on. 222 00:07:56,200 --> 00:07:58,629 And this infinite loop is a very common 223 00:07:58,630 --> 00:08:00,379 reverse engineering technique. 224 00:08:00,380 --> 00:08:02,739 You can drop it somewhere in the code. 225 00:08:02,740 --> 00:08:04,899 And if the system hangs, that means that 226 00:08:04,900 --> 00:08:06,909 your code is running. 227 00:08:06,910 --> 00:08:09,069 But this also means that there 228 00:08:09,070 --> 00:08:11,289 is no external hardware. 229 00:08:11,290 --> 00:08:13,209 Apple used to have a TPM on their 230 00:08:13,210 --> 00:08:15,219 motherboard, but they they actually 231 00:08:15,220 --> 00:08:17,409 removed it because 232 00:08:17,410 --> 00:08:18,790 they weren't using it at the time. 233 00:08:20,200 --> 00:08:21,879 So there's a quick recap. 234 00:08:21,880 --> 00:08:24,159 We now we can now 235 00:08:24,160 --> 00:08:26,379 reprogram the RAM with the 236 00:08:26,380 --> 00:08:28,209 system, Pergament Hardware, and we know 237 00:08:28,210 --> 00:08:29,889 that there's no external hardware that's 238 00:08:29,890 --> 00:08:32,379 actually checking the ROM validity, 239 00:08:32,380 --> 00:08:34,449 but something is checking the 240 00:08:34,450 --> 00:08:36,668 validity and we need to find 241 00:08:36,669 --> 00:08:38,379 that piece of code. 242 00:08:38,380 --> 00:08:40,538 So to figure out how 243 00:08:40,539 --> 00:08:42,428 the RAM is organized, we can go to 244 00:08:42,429 --> 00:08:43,359 Intel's F.I. 245 00:08:43,360 --> 00:08:45,459 specification for their 246 00:08:45,460 --> 00:08:47,949 firmware volume and 247 00:08:47,950 --> 00:08:50,379 it has this field labeled signature, 248 00:08:50,380 --> 00:08:52,599 which sounds perhaps likely, 249 00:08:52,600 --> 00:08:54,729 except it's literally just the 250 00:08:54,730 --> 00:08:57,100 four characters underscore Fage. 251 00:08:58,420 --> 00:09:00,579 There's this checksum, but it only 252 00:09:00,580 --> 00:09:01,580 covers the header. 253 00:09:02,710 --> 00:09:05,309 And the other interesting thing 254 00:09:05,310 --> 00:09:08,109 in this section is the zero vector, 255 00:09:08,110 --> 00:09:10,179 which isn't really defined 256 00:09:10,180 --> 00:09:11,259 what it's used for. 257 00:09:11,260 --> 00:09:12,580 So we'll come back to that 258 00:09:14,230 --> 00:09:16,509 if we do a hex dump and there will be 259 00:09:16,510 --> 00:09:19,559 some hex dumps in this presentation. 260 00:09:19,560 --> 00:09:22,269 If we do have some of the the top segment 261 00:09:22,270 --> 00:09:24,309 of the ROM, basically the last sixty four 262 00:09:24,310 --> 00:09:26,679 kilobytes we can spot that 263 00:09:26,680 --> 00:09:29,619 underscore for signature pretty easily. 264 00:09:29,620 --> 00:09:31,749 And there's the sixteen bit checksum 265 00:09:31,750 --> 00:09:33,939 here covering these 266 00:09:33,940 --> 00:09:36,579 hex forty eight bytes of header 267 00:09:36,580 --> 00:09:38,679 and the zero vector we can see is not 268 00:09:38,680 --> 00:09:41,319 zero, it contains something 269 00:09:41,320 --> 00:09:42,909 this first eight bytes for always the 270 00:09:42,910 --> 00:09:45,309 same in every firmware volume in 271 00:09:45,310 --> 00:09:46,239 the ROM. 272 00:09:46,240 --> 00:09:49,149 But these last eight bytes varied between 273 00:09:49,150 --> 00:09:50,440 each of the firmware volumes. 274 00:09:53,160 --> 00:09:55,829 And that that's interesting, 275 00:09:57,750 --> 00:09:59,909 the way to 276 00:09:59,910 --> 00:10:01,769 try to figure out where things are in the 277 00:10:01,770 --> 00:10:03,999 room, we can use a tool like strings. 278 00:10:04,000 --> 00:10:05,969 And what's interesting is this from image 279 00:10:05,970 --> 00:10:08,309 actually doesn't have very many strings, 280 00:10:08,310 --> 00:10:10,559 but we can find things like 281 00:10:10,560 --> 00:10:12,269 that for signature. 282 00:10:12,270 --> 00:10:14,339 And then a few bytes later, this really 283 00:10:14,340 --> 00:10:16,649 tantalizing string that says rom 284 00:10:16,650 --> 00:10:17,999 integrity. 285 00:10:18,000 --> 00:10:20,189 So let's fire up our interactive 286 00:10:20,190 --> 00:10:21,449 dissembler. 287 00:10:21,450 --> 00:10:24,119 I'm using Hopper in this case 288 00:10:24,120 --> 00:10:26,729 on that section of the ROM 289 00:10:26,730 --> 00:10:29,249 and apologized a little small. 290 00:10:29,250 --> 00:10:30,839 The slides will be available if you 291 00:10:30,840 --> 00:10:32,999 actually want to dig through it later. 292 00:10:33,000 --> 00:10:36,419 We can see that it does a comparison 293 00:10:36,420 --> 00:10:38,459 of that signature there. 294 00:10:38,460 --> 00:10:40,979 And then there's this chunk of code here 295 00:10:40,980 --> 00:10:43,139 that computes some stuff with the 296 00:10:43,140 --> 00:10:45,359 length and then it does something with 297 00:10:45,360 --> 00:10:47,579 the offset eight into the zero 298 00:10:47,580 --> 00:10:49,679 vector at the start of that 299 00:10:49,680 --> 00:10:50,680 Fermor volume. 300 00:10:51,630 --> 00:10:53,699 One thing Hopper can do is give 301 00:10:53,700 --> 00:10:55,319 a pseudocode that we can then massage 302 00:10:55,320 --> 00:10:57,059 into something that looks kind of like 303 00:10:57,060 --> 00:10:59,219 see, and what 304 00:10:59,220 --> 00:11:01,649 we can see is that it's calling 305 00:11:01,650 --> 00:11:03,869 a function on the 306 00:11:03,870 --> 00:11:06,109 data part of the the 307 00:11:06,110 --> 00:11:08,129 firmware volume, storing the result in 308 00:11:08,130 --> 00:11:10,349 that in that address. 309 00:11:10,350 --> 00:11:13,049 And then it compares it to 310 00:11:13,050 --> 00:11:14,819 that part of the zero vector. 311 00:11:14,820 --> 00:11:17,009 So this this function is 312 00:11:17,010 --> 00:11:19,109 clearly involved in somehow and check 313 00:11:19,110 --> 00:11:22,229 in on on that validity. 314 00:11:22,230 --> 00:11:24,299 Using Hopper, we can interactively step 315 00:11:24,300 --> 00:11:26,489 into the into that 316 00:11:26,490 --> 00:11:28,559 function and we find that it does 317 00:11:28,560 --> 00:11:30,599 a bunch of stuff in a loop reading over 318 00:11:30,600 --> 00:11:32,729 the bytes of data, but 319 00:11:32,730 --> 00:11:34,979 also accesses this table 320 00:11:34,980 --> 00:11:36,690 32 bits at a time. 321 00:11:38,130 --> 00:11:40,919 As Rudolf suggested 322 00:11:40,920 --> 00:11:43,049 two days ago, when you run into 323 00:11:43,050 --> 00:11:45,449 these random hex values, 324 00:11:45,450 --> 00:11:47,759 toss them into a search engine and 325 00:11:47,760 --> 00:11:49,139 you never know what you're going to find 326 00:11:50,660 --> 00:11:52,019 in this case. 327 00:11:52,020 --> 00:11:53,609 There's that constanten. 328 00:11:53,610 --> 00:11:55,319 There's the next five constants. 329 00:11:55,320 --> 00:11:57,419 So a lot of our 330 00:11:57,420 --> 00:11:58,589 reverse engineering is done. 331 00:11:58,590 --> 00:12:00,719 We now can probably guess 332 00:12:00,720 --> 00:12:03,149 this function is 60, 32, 333 00:12:03,150 --> 00:12:05,849 and in fact, we can now 334 00:12:05,850 --> 00:12:07,919 make a one by change to the firmware, 335 00:12:07,920 --> 00:12:10,439 manually compute that CSC 32, 336 00:12:10,440 --> 00:12:13,289 reflash it with the insistent programmer 337 00:12:13,290 --> 00:12:15,959 and it now works. 338 00:12:15,960 --> 00:12:18,629 So we have a new bullet point that 339 00:12:18,630 --> 00:12:19,859 there's only about time. 340 00:12:19,860 --> 00:12:22,109 Seriously, 32 to check of of 341 00:12:22,110 --> 00:12:24,179 the ROM. This is not a cryptographic 342 00:12:24,180 --> 00:12:26,369 check. This is only to 343 00:12:26,370 --> 00:12:28,349 ensure that the RAM is not accidentally 344 00:12:28,350 --> 00:12:31,319 been corrupted or that 345 00:12:31,320 --> 00:12:34,439 somehow it has been programed. 346 00:12:34,440 --> 00:12:36,599 So simply by regenerating 347 00:12:36,600 --> 00:12:39,029 that CRC, you can you can change 348 00:12:39,030 --> 00:12:40,030 the ROM. 349 00:12:41,010 --> 00:12:42,719 You might ask why isn't there a 350 00:12:42,720 --> 00:12:43,769 cryptographic check? 351 00:12:44,940 --> 00:12:47,189 Other researchers have looked into this 352 00:12:47,190 --> 00:12:49,319 and come to the conclusion 353 00:12:49,320 --> 00:12:51,659 that the flash 354 00:12:51,660 --> 00:12:53,759 ROMs are only checked 355 00:12:53,760 --> 00:12:55,499 when they're being updated. 356 00:12:55,500 --> 00:12:57,479 And once it's written, it's never checked 357 00:12:57,480 --> 00:12:58,480 again. 358 00:12:59,190 --> 00:13:02,039 One possible reason for that is 359 00:13:02,040 --> 00:13:04,769 for speed to have a fast reboot time, 360 00:13:04,770 --> 00:13:06,929 but doing the CRC requires 361 00:13:06,930 --> 00:13:08,699 reading through the whole ROM anyway, so 362 00:13:08,700 --> 00:13:10,019 it's not like you're going to save that 363 00:13:10,020 --> 00:13:11,020 much time. 364 00:13:12,000 --> 00:13:13,259 The real reason is that malicious 365 00:13:13,260 --> 00:13:15,299 software can just skip the checks that if 366 00:13:15,300 --> 00:13:17,759 you can write to the ROM, you can just 367 00:13:17,760 --> 00:13:20,099 change that, whatever the function is, 368 00:13:20,100 --> 00:13:22,499 and to always return true, or 369 00:13:22,500 --> 00:13:24,689 it can return a pre computed hash 370 00:13:24,690 --> 00:13:25,690 value. 371 00:13:26,250 --> 00:13:28,229 So without any sort of cryptographic 372 00:13:28,230 --> 00:13:30,509 hardware to help out the software, only 373 00:13:30,510 --> 00:13:33,100 attempt is doomed to failure. 374 00:13:34,740 --> 00:13:36,359 Earlier I mentioned that there weren't a 375 00:13:36,360 --> 00:13:38,489 lot of strings in the ROM image 376 00:13:39,900 --> 00:13:41,969 and all eight megabytes, very 377 00:13:41,970 --> 00:13:43,769 little of it had any actual human 378 00:13:43,770 --> 00:13:45,689 readable strings. 379 00:13:45,690 --> 00:13:47,819 Most of that was up here in the early 380 00:13:47,820 --> 00:13:49,739 boot code and there are two copies. 381 00:13:49,740 --> 00:13:51,329 I don't fully understand why 382 00:13:52,620 --> 00:13:54,779 this is a graph of the entropy of 383 00:13:54,780 --> 00:13:57,119 the ROM you generate 384 00:13:57,120 --> 00:13:59,219 with a beanstalk, which is a really great 385 00:13:59,220 --> 00:14:00,269 free software tool. 386 00:14:01,470 --> 00:14:03,779 The zero entropy regions are free 387 00:14:03,780 --> 00:14:06,029 space. They're all FS and the rest 388 00:14:06,030 --> 00:14:08,699 of the room is very high entropy, 389 00:14:08,700 --> 00:14:11,250 which could be encrypted or compressed. 390 00:14:12,540 --> 00:14:14,969 So when we have 391 00:14:14,970 --> 00:14:16,319 to figure out what part of the room to 392 00:14:16,320 --> 00:14:18,389 look at, we can decode 393 00:14:18,390 --> 00:14:20,549 the flash descriptor region of 394 00:14:20,550 --> 00:14:22,679 the ROM and Flash from what 395 00:14:22,680 --> 00:14:25,459 tells us that the BIOS is 396 00:14:25,460 --> 00:14:27,809 the latter part of it from one nine 397 00:14:27,810 --> 00:14:30,059 zero zero zero zero and until 398 00:14:30,060 --> 00:14:31,060 the end. 399 00:14:31,920 --> 00:14:33,989 So let's let's look at what's stored 400 00:14:33,990 --> 00:14:36,389 at the start of that byas region again. 401 00:14:36,390 --> 00:14:38,519 We can go back to our Hexton 402 00:14:39,720 --> 00:14:42,779 and it looks like a firmware 403 00:14:42,780 --> 00:14:44,969 firmware image, 404 00:14:44,970 --> 00:14:47,369 assuming a firmware image file 405 00:14:47,370 --> 00:14:48,569 section. 406 00:14:48,570 --> 00:14:50,669 So we've got three bytes for 407 00:14:50,670 --> 00:14:53,549 the length. About 15 K for this section, 408 00:14:53,550 --> 00:14:55,709 the next fight is the section 409 00:14:55,710 --> 00:14:57,839 type in type one is 410 00:14:57,840 --> 00:15:00,059 a compressed section which matches well 411 00:15:00,060 --> 00:15:02,369 with with what we thought. 412 00:15:02,370 --> 00:15:04,529 So we then turn to the 413 00:15:04,530 --> 00:15:06,689 compression section documentation 414 00:15:06,690 --> 00:15:08,819 and we see the next four bites 415 00:15:08,820 --> 00:15:10,349 are going to be the uncompressed length, 416 00:15:10,350 --> 00:15:11,529 about thirty six case. 417 00:15:11,530 --> 00:15:13,139 We've got a little better than two, two 418 00:15:13,140 --> 00:15:14,140 to one. 419 00:15:14,670 --> 00:15:16,919 The next fight then is the compression 420 00:15:16,920 --> 00:15:19,049 type and they've got type two, 421 00:15:19,050 --> 00:15:21,449 which is not defined in 422 00:15:21,450 --> 00:15:22,799 the specification. 423 00:15:22,800 --> 00:15:24,899 So that's a bit 424 00:15:24,900 --> 00:15:26,339 of a problem. 425 00:15:26,340 --> 00:15:28,019 But I did notice, though, is that these 426 00:15:28,020 --> 00:15:30,089 next four bytes in all 427 00:15:30,090 --> 00:15:31,669 of the firmware sections were the same. 428 00:15:32,790 --> 00:15:34,409 What do we do when we see something like 429 00:15:34,410 --> 00:15:36,929 that tossed into the search engine 430 00:15:36,930 --> 00:15:39,479 and we get a perfect hit for 431 00:15:39,480 --> 00:15:41,819 LACMA at compression 432 00:15:41,820 --> 00:15:43,080 level, negative seven. 433 00:15:44,400 --> 00:15:46,679 So to verify this, 434 00:15:46,680 --> 00:15:48,779 we can use a tool like DD 435 00:15:48,780 --> 00:15:51,029 to extract the 436 00:15:51,030 --> 00:15:53,399 compressed bytes, skipping 437 00:15:53,400 --> 00:15:55,499 that nine byte section header, 438 00:15:55,500 --> 00:15:57,749 filtering it through Elzy CAD, 439 00:15:57,750 --> 00:16:00,089 which will decompress it if it's a valid 440 00:16:00,090 --> 00:16:02,939 LACMA format and 441 00:16:02,940 --> 00:16:04,619 no complaints from multi-cap. 442 00:16:04,620 --> 00:16:05,620 That's that's great. 443 00:16:06,660 --> 00:16:08,789 The file sizes match up with what we 444 00:16:08,790 --> 00:16:09,790 saw in the header 445 00:16:10,920 --> 00:16:13,109 and there are now human readable 446 00:16:13,110 --> 00:16:14,009 strings. 447 00:16:14,010 --> 00:16:16,679 These are just absolute golden 448 00:16:16,680 --> 00:16:18,329 if you're doing reverse engineering 449 00:16:18,330 --> 00:16:20,159 especially. Printf strange, there's a 450 00:16:20,160 --> 00:16:22,349 percent zero percent zero 451 00:16:22,350 --> 00:16:23,639 s and what not. 452 00:16:23,640 --> 00:16:25,709 Those are what tell you how 453 00:16:25,710 --> 00:16:27,599 things are happening inside the code. 454 00:16:27,600 --> 00:16:29,789 So once you have that sort of thing, 455 00:16:29,790 --> 00:16:31,619 it's very, very easy to start figuring 456 00:16:31,620 --> 00:16:33,000 out what else is going on. 457 00:16:34,200 --> 00:16:36,449 So we now know how 458 00:16:36,450 --> 00:16:37,859 the Fermor volumes are compressed. 459 00:16:37,860 --> 00:16:39,299 It's type two. 460 00:16:39,300 --> 00:16:40,889 We can flashmob could with the system 461 00:16:40,890 --> 00:16:42,720 programmer after recompression. 462 00:16:43,860 --> 00:16:45,749 I'm not the first person to figure this 463 00:16:45,750 --> 00:16:47,729 out. I'm quite certainly not the first 464 00:16:47,730 --> 00:16:49,469 person, but I've never seen anyone else 465 00:16:49,470 --> 00:16:51,029 write it down. So I wanted to make sure 466 00:16:51,030 --> 00:16:52,829 that this is now out. 467 00:16:52,830 --> 00:16:54,929 There were other people can can start 468 00:16:54,930 --> 00:16:56,699 working with these firmware volumes. 469 00:16:58,860 --> 00:16:59,860 Thank you. 470 00:17:06,079 --> 00:17:08,509 So why can't we write to the boot, 471 00:17:08,510 --> 00:17:10,879 the boot from flash, from software? 472 00:17:10,880 --> 00:17:12,828 Why do we still have to use this hardware 473 00:17:12,829 --> 00:17:13,929 programmer? 474 00:17:13,930 --> 00:17:15,679 It turns out that the Flash is not 475 00:17:15,680 --> 00:17:18,019 directly connected to the CPU, that 476 00:17:18,020 --> 00:17:19,999 in the flash over here is actually 477 00:17:20,000 --> 00:17:22,129 connected to the platform controller 478 00:17:22,130 --> 00:17:24,199 hub and access to it is 479 00:17:24,200 --> 00:17:26,029 mediated by things like the management 480 00:17:26,030 --> 00:17:27,030 engine. 481 00:17:27,619 --> 00:17:29,839 When the system Boutte's the 482 00:17:29,840 --> 00:17:32,089 the UniFi Forum 483 00:17:32,090 --> 00:17:34,339 recommends that all of these 484 00:17:34,340 --> 00:17:37,549 regions be locked as quickly as possible. 485 00:17:37,550 --> 00:17:40,459 This is done via registers like 486 00:17:40,460 --> 00:17:42,619 lockdown down that 487 00:17:42,620 --> 00:17:45,169 control, access to the configuration, 488 00:17:45,170 --> 00:17:47,239 the read write access, and they 489 00:17:47,240 --> 00:17:49,129 can only be cleared during a hardware 490 00:17:49,130 --> 00:17:50,130 reset. 491 00:17:50,930 --> 00:17:53,419 So this means that 492 00:17:53,420 --> 00:17:55,459 once the system is booted, you can't 493 00:17:55,460 --> 00:17:57,649 write to to those parts 494 00:17:57,650 --> 00:17:58,650 of the room. 495 00:17:59,270 --> 00:18:01,339 But we know that Apple updates 496 00:18:01,340 --> 00:18:03,469 the firmware that they pretty 497 00:18:03,470 --> 00:18:05,689 regularly ship EFI 498 00:18:05,690 --> 00:18:07,999 and EMC firmware updates that that write 499 00:18:08,000 --> 00:18:10,189 new code into this ROM 500 00:18:10,190 --> 00:18:12,499 and it has a really nice GUI that will 501 00:18:12,500 --> 00:18:14,059 make sure it's the right version for your 502 00:18:14,060 --> 00:18:15,169 system and whatnot. 503 00:18:15,170 --> 00:18:17,299 But under the covers, it's using a 504 00:18:17,300 --> 00:18:20,029 tool, a command line tool called Bless 505 00:18:20,030 --> 00:18:22,189 that takes 506 00:18:22,190 --> 00:18:24,319 the ESCAP file that is stored 507 00:18:24,320 --> 00:18:26,929 in the image that you download and 508 00:18:26,930 --> 00:18:29,899 copies it to the EFI system partition 509 00:18:29,900 --> 00:18:32,119 and then sets a EFI 510 00:18:32,120 --> 00:18:34,279 in VRAM variable so that the next 511 00:18:34,280 --> 00:18:36,139 time the system Boutte's, it sees that 512 00:18:36,140 --> 00:18:37,819 variable and does what's called a 513 00:18:37,820 --> 00:18:38,989 recovery mode boot. 514 00:18:40,430 --> 00:18:42,949 So the account files another 515 00:18:42,950 --> 00:18:45,289 undocumented blob that 516 00:18:45,290 --> 00:18:46,879 we need to figure out what's actually in 517 00:18:46,880 --> 00:18:48,469 it. What are they, what are they doing in 518 00:18:48,470 --> 00:18:49,470 there. 519 00:18:49,970 --> 00:18:52,579 So hex dumps are 520 00:18:52,580 --> 00:18:54,229 spent too much of my life staring at hex 521 00:18:54,230 --> 00:18:56,359 dumps and it's kind of a 522 00:18:56,360 --> 00:18:58,549 good way to to get accustomed to what's 523 00:18:58,550 --> 00:19:00,229 going on in the machine. 524 00:19:00,230 --> 00:19:02,959 We can easily spot the file 525 00:19:02,960 --> 00:19:05,029 volume signature there, but it's 526 00:19:05,030 --> 00:19:06,649 not at the start of the file. 527 00:19:06,650 --> 00:19:09,049 It's actually offset by about 50 528 00:19:09,050 --> 00:19:11,269 bytes. And we see that there's a 50 byte 529 00:19:11,270 --> 00:19:13,219 value among all those zeros 530 00:19:14,480 --> 00:19:16,279 based on the firmware volume 531 00:19:16,280 --> 00:19:17,839 specification. We know that that's the 532 00:19:17,840 --> 00:19:19,429 size of the volume. 533 00:19:19,430 --> 00:19:21,140 And we see there's a similar value 534 00:19:22,640 --> 00:19:24,679 elsewhere in the header, which actually 535 00:19:24,680 --> 00:19:27,049 matches the size of the total 536 00:19:27,050 --> 00:19:28,050 file. 537 00:19:29,150 --> 00:19:30,949 One thing that you encounter a lot, if 538 00:19:30,950 --> 00:19:32,429 you do F.I. 539 00:19:32,430 --> 00:19:34,519 Firmware reverse engineering is 540 00:19:34,520 --> 00:19:36,589 that there are these 16 byte 541 00:19:36,590 --> 00:19:38,929 guides, which 542 00:19:38,930 --> 00:19:40,939 they can be frustrating, but they're also 543 00:19:40,940 --> 00:19:43,549 marvelous search engine 544 00:19:43,550 --> 00:19:44,479 targets. 545 00:19:44,480 --> 00:19:46,549 So when we toss that in 546 00:19:46,550 --> 00:19:48,229 into whatever search engine, we get a 547 00:19:48,230 --> 00:19:51,109 perfect head on yet another 548 00:19:51,110 --> 00:19:52,789 SFI specification document. 549 00:19:53,900 --> 00:19:56,509 And as expected, here's the header size, 550 00:19:56,510 --> 00:19:58,729 here's the image size and 551 00:19:58,730 --> 00:20:00,589 the rest of the fields are all zero. 552 00:20:01,640 --> 00:20:03,739 But one thing that that we notice there 553 00:20:03,740 --> 00:20:05,839 is that the there's an extra 554 00:20:05,840 --> 00:20:07,669 two hundred and twenty hex bytes at the 555 00:20:07,670 --> 00:20:09,469 end of the file. 556 00:20:09,470 --> 00:20:10,849 So let's look at that 557 00:20:12,470 --> 00:20:13,880 again, hex dump in it. 558 00:20:14,990 --> 00:20:16,729 And it's all high entropy. 559 00:20:16,730 --> 00:20:18,499 There's nothing, there's nothing human 560 00:20:18,500 --> 00:20:21,049 readable. It's just random values. 561 00:20:21,050 --> 00:20:22,609 Well, on the off chance that this might 562 00:20:22,610 --> 00:20:24,709 be another goed, what do 563 00:20:24,710 --> 00:20:25,710 we do? 564 00:20:26,120 --> 00:20:27,409 We search for it. 565 00:20:27,410 --> 00:20:30,229 We get one hit and 566 00:20:30,230 --> 00:20:32,389 it's a mailing list post from 567 00:20:32,390 --> 00:20:33,559 just a couple of months ago. 568 00:20:34,760 --> 00:20:36,559 I wish I had actually found this much, 569 00:20:36,560 --> 00:20:37,640 much longer ago. 570 00:20:38,750 --> 00:20:40,829 And it's describing a RSA twenty 571 00:20:40,830 --> 00:20:43,159 forty eight shot six 572 00:20:43,160 --> 00:20:46,069 signing and gives us a structure 573 00:20:46,070 --> 00:20:48,139 that's two hundred and ten hex 574 00:20:48,140 --> 00:20:50,569 bytes. So this matches very closely 575 00:20:50,570 --> 00:20:52,099 to the trailer that we're seeing. 576 00:20:52,100 --> 00:20:54,199 So this is a pretty good idea of 577 00:20:54,200 --> 00:20:55,999 what's going on there. 578 00:20:56,000 --> 00:20:57,000 So 579 00:20:58,730 --> 00:21:00,859 my next step would be let's let's 580 00:21:00,860 --> 00:21:03,049 try to check that and 581 00:21:03,050 --> 00:21:04,459 Supergirl program. 582 00:21:04,460 --> 00:21:06,049 I realized Perl may be worse than 583 00:21:06,050 --> 00:21:08,599 assembly for some people, but it's 584 00:21:08,600 --> 00:21:09,799 handy. 585 00:21:09,800 --> 00:21:12,409 So it reads in the the cat file 586 00:21:12,410 --> 00:21:14,779 and extracts out the firmware volume 587 00:21:14,780 --> 00:21:16,579 and then the RSA public key and the 588 00:21:16,580 --> 00:21:19,039 signature based on that that structure 589 00:21:19,040 --> 00:21:21,409 that we found in that mailing list post. 590 00:21:21,410 --> 00:21:23,569 It then uses the default RSA 591 00:21:23,570 --> 00:21:25,759 exponent since there's not one stored 592 00:21:25,760 --> 00:21:26,989 in there. 593 00:21:26,990 --> 00:21:29,269 And I really need to give huge thanks 594 00:21:29,270 --> 00:21:31,429 to my colleague Victor de Coveny, 595 00:21:31,430 --> 00:21:33,619 who suggested swapping the byte 596 00:21:33,620 --> 00:21:35,899 order to put it into a big 597 00:21:35,900 --> 00:21:36,900 Indian. 598 00:21:37,670 --> 00:21:39,349 And once we've done that, we built the 599 00:21:39,350 --> 00:21:40,339 RSA key. 600 00:21:40,340 --> 00:21:42,919 We verify the signature 601 00:21:42,920 --> 00:21:44,539 and it's OK. 602 00:21:44,540 --> 00:21:46,849 So we now know 603 00:21:46,850 --> 00:21:48,619 how Apple is signing their firmware 604 00:21:48,620 --> 00:21:50,299 updates, which. 605 00:21:58,970 --> 00:22:00,319 Not only do we know how they're being 606 00:22:00,320 --> 00:22:02,539 signed, but we know 607 00:22:02,540 --> 00:22:04,849 that the blessed tool doesn't check 608 00:22:04,850 --> 00:22:07,039 the signature, that something in 609 00:22:07,040 --> 00:22:08,839 the boot process that does it. 610 00:22:09,860 --> 00:22:12,199 And as a word of warning, if you bless 611 00:22:12,200 --> 00:22:14,419 an invalid file, 612 00:22:14,420 --> 00:22:16,519 plus will happily copy to the partitions 613 00:22:16,520 --> 00:22:18,049 that the variable and you will break your 614 00:22:18,050 --> 00:22:20,149 machine, you will have to do a full in 615 00:22:20,150 --> 00:22:22,519 system programing 616 00:22:22,520 --> 00:22:25,489 reflash of the ram to to clear that. 617 00:22:25,490 --> 00:22:28,249 So but, 618 00:22:28,250 --> 00:22:30,319 you know, where are the signatures being 619 00:22:30,320 --> 00:22:31,039 checked? 620 00:22:31,040 --> 00:22:34,459 We know somewhere in that update process, 621 00:22:34,460 --> 00:22:35,539 but it could be hardware. 622 00:22:35,540 --> 00:22:37,609 Again, the management engineer 623 00:22:37,610 --> 00:22:39,169 or the assembly perhaps could be helping 624 00:22:39,170 --> 00:22:42,649 out or might just be software. 625 00:22:42,650 --> 00:22:44,899 So if we do a binary grep 626 00:22:44,900 --> 00:22:46,819 for those, there's two that we just 627 00:22:46,820 --> 00:22:47,809 found. 628 00:22:47,810 --> 00:22:49,909 We find one file in the 629 00:22:49,910 --> 00:22:52,219 uncompressed forum that matches 630 00:22:52,220 --> 00:22:54,469 and it actually matches all three 631 00:22:54,470 --> 00:22:55,470 of them. 632 00:22:55,970 --> 00:22:58,249 So if we look at the bit of code that 633 00:22:58,250 --> 00:23:00,289 that works with them, we find that it 634 00:23:00,290 --> 00:23:02,899 does the the Jewed compares 635 00:23:02,900 --> 00:23:05,089 as we'd expect it checks the file 636 00:23:05,090 --> 00:23:08,119 size along with that HEX 220 637 00:23:08,120 --> 00:23:09,260 byte trailer. 638 00:23:11,810 --> 00:23:13,969 And it also then references 639 00:23:13,970 --> 00:23:16,609 this G. UID, which is the DC 640 00:23:16,610 --> 00:23:17,720 services table, 641 00:23:18,890 --> 00:23:21,469 which becomes very interesting. 642 00:23:21,470 --> 00:23:23,269 If we step a little bit further in the 643 00:23:23,270 --> 00:23:26,179 code to what refers to the table, 644 00:23:26,180 --> 00:23:28,369 we find that it passes the 645 00:23:28,370 --> 00:23:29,420 firmware volume, 646 00:23:31,190 --> 00:23:33,529 the contents of the firmware volume 647 00:23:33,530 --> 00:23:35,659 through a function pointer at Offset Hex 648 00:23:35,660 --> 00:23:37,759 ninety eight in the services 649 00:23:37,760 --> 00:23:38,749 table. 650 00:23:38,750 --> 00:23:40,909 To find out where that is, we go back 651 00:23:40,910 --> 00:23:43,009 to the specification and they don't give 652 00:23:43,010 --> 00:23:45,079 us offsets. But we can count eight bytes 653 00:23:45,080 --> 00:23:46,729 at a time because we're we're in long 654 00:23:46,730 --> 00:23:48,739 mode here and we find that that it's 655 00:23:48,740 --> 00:23:51,079 calling process firmware, a volume 656 00:23:51,080 --> 00:23:53,209 that takes the RAM copy 657 00:23:53,210 --> 00:23:55,579 of the the firmware volume 658 00:23:55,580 --> 00:23:57,739 and essentially mounts it and makes 659 00:23:57,740 --> 00:23:59,809 it available to other 660 00:23:59,810 --> 00:24:01,429 functions in the firmware. 661 00:24:02,660 --> 00:24:04,759 If that succeeds, it then calls another 662 00:24:04,760 --> 00:24:07,369 function. It offset Hex 80 663 00:24:07,370 --> 00:24:09,949 and this is dispatch, 664 00:24:09,950 --> 00:24:12,079 which will execute any code that was 665 00:24:12,080 --> 00:24:13,579 in the firmware volume that was just 666 00:24:13,580 --> 00:24:15,109 mounted. 667 00:24:15,110 --> 00:24:17,239 So simply a little messy. 668 00:24:17,240 --> 00:24:19,369 Let's translate that to some pseudocode 669 00:24:20,510 --> 00:24:23,119 we see it. Does the the 670 00:24:23,120 --> 00:24:24,230 grid check 671 00:24:25,280 --> 00:24:27,649 it? Does the RSA 672 00:24:27,650 --> 00:24:29,749 check on the shot two, three, six. 673 00:24:29,750 --> 00:24:31,939 It then calls process for more volume 674 00:24:31,940 --> 00:24:33,200 and dispatch 675 00:24:36,290 --> 00:24:38,449 and that then 676 00:24:38,450 --> 00:24:40,699 jumps into the flasher that's in the 677 00:24:40,700 --> 00:24:41,750 in the ESCAP file. 678 00:24:42,800 --> 00:24:45,289 So we can now, 679 00:24:45,290 --> 00:24:46,969 because of what we've learned already, we 680 00:24:46,970 --> 00:24:50,089 know how to make modifications to the ROM 681 00:24:50,090 --> 00:24:52,189 to find out how to try things 682 00:24:52,190 --> 00:24:54,709 out. So one question 683 00:24:54,710 --> 00:24:57,109 that I had is, is this 684 00:24:57,110 --> 00:24:58,999 this RSA check the only place that is 685 00:24:59,000 --> 00:25:01,129 done or is something in the management 686 00:25:01,130 --> 00:25:02,779 engine or some of their hardware also 687 00:25:02,780 --> 00:25:05,059 doing it? So I 688 00:25:05,060 --> 00:25:07,519 just commented out, I can just 689 00:25:07,520 --> 00:25:09,169 put jumps around that so it doesn't get 690 00:25:09,170 --> 00:25:10,170 executed. 691 00:25:10,840 --> 00:25:13,209 And then I can generate a 692 00:25:13,210 --> 00:25:14,589 bogus ESCAP file. 693 00:25:14,590 --> 00:25:17,129 Now here's the trailer on it with the 694 00:25:17,130 --> 00:25:19,509 the usual guides and whatnot, 695 00:25:19,510 --> 00:25:21,579 but that is pretty clearly 696 00:25:21,580 --> 00:25:24,309 not a valid RSA signature 697 00:25:24,310 --> 00:25:25,330 in the file. 698 00:25:27,190 --> 00:25:29,649 So if I bless this camp 699 00:25:29,650 --> 00:25:31,899 and the machine breaks, that 700 00:25:31,900 --> 00:25:34,119 means that some piece of hardware is also 701 00:25:34,120 --> 00:25:35,079 checking it. 702 00:25:35,080 --> 00:25:37,809 But if the 703 00:25:37,810 --> 00:25:39,819 system accepts this has kept file and 704 00:25:39,820 --> 00:25:42,099 updates the firmware with its contents, 705 00:25:42,100 --> 00:25:43,799 and that means that it is just software. 706 00:25:44,920 --> 00:25:46,329 Once again, I'm up here giving this 707 00:25:46,330 --> 00:25:48,549 presentation, so you 708 00:25:48,550 --> 00:25:49,749 probably guess what happens. 709 00:25:49,750 --> 00:25:50,920 The firmware gets updated, 710 00:25:52,150 --> 00:25:54,309 which again is pretty 711 00:25:54,310 --> 00:25:57,189 fascinating. This means that 712 00:25:57,190 --> 00:25:59,289 there isn't the firmware 713 00:25:59,290 --> 00:26:01,089 signatures are only being verified by 714 00:26:01,090 --> 00:26:03,579 software. There is no hardware 715 00:26:03,580 --> 00:26:04,580 involved. 716 00:26:05,860 --> 00:26:07,959 So next question is, 717 00:26:07,960 --> 00:26:10,089 can we could we 718 00:26:10,090 --> 00:26:12,429 do this sort of change without 719 00:26:12,430 --> 00:26:14,649 internal access to the system right now 720 00:26:14,650 --> 00:26:16,119 to make these changes, we have to open 721 00:26:16,120 --> 00:26:18,430 the machine and to the RAAM. 722 00:26:19,690 --> 00:26:21,849 And based on the work that Schnorrer 723 00:26:21,850 --> 00:26:24,189 did with the Thunderbolt port, I thought 724 00:26:24,190 --> 00:26:25,629 we might be able to. 725 00:26:25,630 --> 00:26:27,729 So Thunderbolt brings the 726 00:26:27,730 --> 00:26:30,189 internal Pybus to the outside 727 00:26:30,190 --> 00:26:32,409 world. And when the system 728 00:26:32,410 --> 00:26:34,509 starts up, it it enumerates 729 00:26:34,510 --> 00:26:36,669 all the devices on the bus and it asks 730 00:26:36,670 --> 00:26:39,309 if they have any option ROMs that 731 00:26:39,310 --> 00:26:40,989 should be executed. 732 00:26:40,990 --> 00:26:43,119 Option rooms are a legacy feature that 733 00:26:43,120 --> 00:26:45,429 literally goes back to the very first 734 00:26:45,430 --> 00:26:47,589 IBM PC with that 735 00:26:47,590 --> 00:26:48,760 Intel 80 80. 736 00:26:49,870 --> 00:26:52,119 The virus was typically a mask 737 00:26:52,120 --> 00:26:54,309 or you've from and there were these 738 00:26:54,310 --> 00:26:56,469 six sockets where you 739 00:26:56,470 --> 00:26:58,149 could put in optional ROMs that would 740 00:26:58,150 --> 00:27:00,249 have things like basic and device 741 00:27:00,250 --> 00:27:02,289 drivers for four other things. 742 00:27:02,290 --> 00:27:04,539 And the NASA expansion bus 743 00:27:04,540 --> 00:27:07,179 cars could also carry their own ROMs 744 00:27:07,180 --> 00:27:09,909 that would then become available 745 00:27:09,910 --> 00:27:10,910 for the BIOS. 746 00:27:11,980 --> 00:27:13,479 So that's what we're talking about. 747 00:27:13,480 --> 00:27:15,699 A legacy feature going back thirty five 748 00:27:15,700 --> 00:27:16,700 years here. 749 00:27:17,830 --> 00:27:19,899 Using it as an attack vector is not a 750 00:27:19,900 --> 00:27:21,399 particularly new idea. 751 00:27:21,400 --> 00:27:24,849 John Heasman at Blackhead in 2007 752 00:27:24,850 --> 00:27:27,059 showed how to put a attack 753 00:27:27,060 --> 00:27:28,869 factor onto an expansion card 754 00:27:30,100 --> 00:27:32,289 and snares work on 755 00:27:32,290 --> 00:27:34,829 the was pretty damn awesome. 756 00:27:34,830 --> 00:27:37,179 He built a gigabit Ethernet 757 00:27:37,180 --> 00:27:38,710 Thunderbolt adapter that could 758 00:27:39,850 --> 00:27:42,729 could Back-Door the Austin kernel 759 00:27:42,730 --> 00:27:45,039 and that was done in 2012 760 00:27:45,040 --> 00:27:47,289 that Flor's actually still in Mac 761 00:27:47,290 --> 00:27:48,669 books. 762 00:27:48,670 --> 00:27:50,769 So if you put 763 00:27:50,770 --> 00:27:52,899 one of these Thunderbolt adapters with 764 00:27:52,900 --> 00:27:55,059 a with the option 765 00:27:55,060 --> 00:27:57,519 rom exploit on it and beat the system. 766 00:27:57,520 --> 00:28:00,009 This is one that I built that 767 00:28:00,010 --> 00:28:02,169 will capture your 768 00:28:02,170 --> 00:28:04,029 fireball password. 769 00:28:04,030 --> 00:28:06,099 I have since changed it to a password, 770 00:28:06,100 --> 00:28:07,929 one which is much more secure. 771 00:28:16,610 --> 00:28:18,769 So the problem is that 772 00:28:18,770 --> 00:28:20,959 option rooms can't write to 773 00:28:20,960 --> 00:28:23,479 the Flash because 774 00:28:23,480 --> 00:28:25,729 they are loaded in the dark 775 00:28:25,730 --> 00:28:27,859 phase of the boot, but the 776 00:28:27,860 --> 00:28:30,169 flash is locked during the P.I. 777 00:28:30,170 --> 00:28:31,170 phase. 778 00:28:31,820 --> 00:28:33,979 However, except 779 00:28:33,980 --> 00:28:35,899 during boot rom firmware updates, in 780 00:28:35,900 --> 00:28:38,239 which case the flash is not locked. 781 00:28:38,240 --> 00:28:40,429 And we saw that the the 782 00:28:40,430 --> 00:28:42,709 flash the 783 00:28:42,710 --> 00:28:44,449 flash code is running in sixty four bit 784 00:28:44,450 --> 00:28:46,879 mode, which means the firmware update 785 00:28:46,880 --> 00:28:49,279 program is now also running in the dark 786 00:28:49,280 --> 00:28:52,459 phase along with the option ROMs, 787 00:28:52,460 --> 00:28:54,619 which leads me to question our option 788 00:28:54,620 --> 00:28:57,049 ROMs also loaded during 789 00:28:57,050 --> 00:28:58,160 those firmware updates 790 00:28:59,360 --> 00:29:01,309 and the way that I wanted to figure that 791 00:29:01,310 --> 00:29:03,379 out, I could go through and do a bunch of 792 00:29:03,380 --> 00:29:04,789 reverse engineering and walking through 793 00:29:04,790 --> 00:29:07,109 code and stuff, but that's too much work. 794 00:29:07,110 --> 00:29:09,709 So I go back to the infinite loop trick 795 00:29:09,710 --> 00:29:11,929 and I built an auction room that 796 00:29:11,930 --> 00:29:13,219 just doesn't infinite loop 797 00:29:14,750 --> 00:29:16,879 that the I firmware is 798 00:29:16,880 --> 00:29:17,939 single threaded. 799 00:29:17,940 --> 00:29:19,819 So this will basically lock up the 800 00:29:19,820 --> 00:29:21,249 machine. 801 00:29:21,250 --> 00:29:23,419 So now if I connect the 802 00:29:23,420 --> 00:29:25,009 Thunderbolt device with that infinite 803 00:29:25,010 --> 00:29:27,109 loop option rom and 804 00:29:27,110 --> 00:29:28,969 power on the machine after Blessin and 805 00:29:28,970 --> 00:29:29,970 ASKAP file, 806 00:29:31,070 --> 00:29:33,169 if it goes into the firmware update, that 807 00:29:33,170 --> 00:29:34,879 means that the option rooms are not 808 00:29:34,880 --> 00:29:37,849 loaded during a recovery mode boot. 809 00:29:37,850 --> 00:29:40,039 But if the fans just spin 810 00:29:40,040 --> 00:29:41,749 and the machine appears to be bricked, 811 00:29:41,750 --> 00:29:43,849 then that means that the option rooms are 812 00:29:43,850 --> 00:29:45,400 being loaded and executed. 813 00:29:46,700 --> 00:29:47,700 So. 814 00:29:48,390 --> 00:29:50,509 You guys know what the answer is, yes, 815 00:29:50,510 --> 00:29:52,369 option arms are loaded during the 816 00:29:52,370 --> 00:29:53,370 recovery mode boot. 817 00:30:02,840 --> 00:30:04,819 However, there's a minor roadblock that 818 00:30:04,820 --> 00:30:05,820 there is a 819 00:30:06,950 --> 00:30:09,049 32 bit murd signature check of 820 00:30:09,050 --> 00:30:11,479 the cap file before the option 821 00:30:11,480 --> 00:30:13,279 gets executed. 822 00:30:13,280 --> 00:30:15,469 So is there a way that we could 823 00:30:15,470 --> 00:30:16,609 bypass that check? 824 00:30:18,040 --> 00:30:20,169 If we go back to that pseudocode for 825 00:30:20,170 --> 00:30:23,349 the the flasher verification, 826 00:30:23,350 --> 00:30:25,779 remember that process for volume 827 00:30:25,780 --> 00:30:28,419 is being called via a function pointer 828 00:30:28,420 --> 00:30:30,849 that Cinram not in Romme. 829 00:30:30,850 --> 00:30:33,119 So the option 830 00:30:33,120 --> 00:30:35,289 could replace that that function 831 00:30:35,290 --> 00:30:37,420 pointer in a process called Hook In. 832 00:30:38,770 --> 00:30:40,959 So we can modify 833 00:30:40,960 --> 00:30:43,029 the option right now to 834 00:30:43,030 --> 00:30:45,909 hook the process, firmware volume 835 00:30:45,910 --> 00:30:47,979 function pointer and replace it with its 836 00:30:47,980 --> 00:30:50,229 own and also then stores the old one 837 00:30:50,230 --> 00:30:51,609 so that it can reuse it later. 838 00:30:52,930 --> 00:30:55,189 If you have a sufficiently large option, 839 00:30:55,190 --> 00:30:57,579 Ram, you just put your whole firmware 840 00:30:57,580 --> 00:31:00,309 exploit in there and and 841 00:31:00,310 --> 00:31:01,869 it's game over. 842 00:31:01,870 --> 00:31:03,999 However, the one that we're 843 00:31:04,000 --> 00:31:06,309 using, the gigabit Ethernet 844 00:31:06,310 --> 00:31:08,409 adapter, only has about thirty two 845 00:31:08,410 --> 00:31:10,629 K of space available and so we can't put 846 00:31:10,630 --> 00:31:12,479 a full eight mag rom image in there. 847 00:31:13,690 --> 00:31:15,579 But what we came up with is actually even 848 00:31:15,580 --> 00:31:17,859 more interesting that we 849 00:31:17,860 --> 00:31:20,169 can instead 850 00:31:20,170 --> 00:31:22,389 put in an RSA public key that we 851 00:31:22,390 --> 00:31:24,789 control and 852 00:31:24,790 --> 00:31:26,889 the process from our volume function 853 00:31:26,890 --> 00:31:29,199 will search through the firmware volume 854 00:31:29,200 --> 00:31:31,089 looking for Apple's public key. 855 00:31:31,090 --> 00:31:33,609 If it finds it, it MWM copies 856 00:31:33,610 --> 00:31:34,599 it. 857 00:31:34,600 --> 00:31:36,669 Our public key over it, 858 00:31:36,670 --> 00:31:38,859 then fixes up the CRC 32 859 00:31:38,860 --> 00:31:40,809 since we now know how to do that. 860 00:31:40,810 --> 00:31:42,589 And then it calls the old process for 861 00:31:42,590 --> 00:31:45,999 more volume on this now modified 862 00:31:46,000 --> 00:31:47,559 image. 863 00:31:47,560 --> 00:31:48,560 And 864 00:31:49,990 --> 00:31:52,240 when we so 865 00:31:53,260 --> 00:31:56,049 when we now get the machine with 866 00:31:56,050 --> 00:31:58,299 again with the Thunderbolt device, with 867 00:31:58,300 --> 00:32:00,219 what we're called the Thunder Strike 868 00:32:00,220 --> 00:32:02,589 exploit, because all cool exploits have 869 00:32:02,590 --> 00:32:03,609 have names these days. 870 00:32:05,860 --> 00:32:07,060 So when we put up the machine, 871 00:32:08,560 --> 00:32:10,779 the here's the exploit code 872 00:32:10,780 --> 00:32:12,879 running in the recovery mode 873 00:32:12,880 --> 00:32:15,009 boot and we're not worried about 874 00:32:15,010 --> 00:32:17,019 stealthiness is proof of concept. 875 00:32:17,020 --> 00:32:18,939 And now here is Apple's own firmware 876 00:32:18,940 --> 00:32:21,339 update routine, flashing 877 00:32:21,340 --> 00:32:23,579 our option rom with our 878 00:32:23,580 --> 00:32:25,659 RSA key into the boot rom on 879 00:32:25,660 --> 00:32:26,949 the motherboard. 880 00:32:26,950 --> 00:32:28,029 And once that's done, 881 00:32:29,320 --> 00:32:31,449 we now own the system and we can flash 882 00:32:31,450 --> 00:32:33,669 whatever we want using Apple's own update 883 00:32:33,670 --> 00:32:34,659 tools. 884 00:32:34,660 --> 00:32:35,660 So. 885 00:32:45,820 --> 00:32:47,859 So all exploits also get logos and I 886 00:32:47,860 --> 00:32:49,499 think theme songs and websites now, 887 00:32:51,640 --> 00:32:53,799 so we now know 888 00:32:53,800 --> 00:32:55,899 how to circumvent flash security 889 00:32:55,900 --> 00:32:57,039 with the option rooms. 890 00:32:57,040 --> 00:32:59,109 And because we've replaced the 891 00:32:59,110 --> 00:33:01,199 key, this boot camp be 892 00:33:01,200 --> 00:33:03,969 removed without 893 00:33:03,970 --> 00:33:06,219 through software alone because we control 894 00:33:06,220 --> 00:33:08,109 the key that the firmware is going to 895 00:33:08,110 --> 00:33:10,359 use, that there's no 896 00:33:11,380 --> 00:33:13,569 official channel that that can 897 00:33:13,570 --> 00:33:15,039 remove it. 898 00:33:15,040 --> 00:33:16,959 So how would something like thunder 899 00:33:16,960 --> 00:33:18,879 strike if it were to be weaponized 900 00:33:18,880 --> 00:33:20,799 actually be deployed? 901 00:33:20,800 --> 00:33:23,019 One option is something like 902 00:33:23,020 --> 00:33:24,819 what the NSA is doing, where they 903 00:33:24,820 --> 00:33:27,639 intercept shipments of hardware and 904 00:33:27,640 --> 00:33:29,919 make modifications, 905 00:33:29,920 --> 00:33:31,719 as they're seen here doing to Cisco 906 00:33:31,720 --> 00:33:32,720 routers. 907 00:33:33,490 --> 00:33:35,769 The other ones, the evil made attack 908 00:33:35,770 --> 00:33:38,319 that folks hypothesize in which 909 00:33:38,320 --> 00:33:40,359 you're at a conference, say, in Hamburg 910 00:33:40,360 --> 00:33:42,819 and you go down to the hotel 911 00:33:42,820 --> 00:33:45,099 to get some breakfast in room service 912 00:33:45,100 --> 00:33:47,289 comes in and they they make the bed 913 00:33:47,290 --> 00:33:49,689 and back toward your laptop and 914 00:33:49,690 --> 00:33:50,769 leave some fresh towels. 915 00:33:53,570 --> 00:33:56,569 Or when you're flying 916 00:33:56,570 --> 00:33:58,819 through international borders, 917 00:33:58,820 --> 00:33:59,989 in fact, the U.S. 918 00:33:59,990 --> 00:34:02,179 courts have said that 919 00:34:02,180 --> 00:34:04,339 there is no protection 920 00:34:04,340 --> 00:34:06,439 for citizens or visitors 921 00:34:06,440 --> 00:34:08,269 alike at the US border. 922 00:34:08,270 --> 00:34:10,638 In fact, in this 923 00:34:10,639 --> 00:34:12,819 decision against the 924 00:34:12,820 --> 00:34:13,819 a U.S. 925 00:34:13,820 --> 00:34:15,948 citizen photographer that they 926 00:34:15,949 --> 00:34:17,509 said that the laptops are the most 927 00:34:17,510 --> 00:34:19,859 dangerous contraband and 928 00:34:19,860 --> 00:34:22,039 there's no you know, 929 00:34:22,040 --> 00:34:23,719 you have no expectation of privacy. 930 00:34:25,520 --> 00:34:27,619 So this 931 00:34:27,620 --> 00:34:29,839 this all this venerability is in 932 00:34:29,840 --> 00:34:32,359 pretty much every MacBook 933 00:34:32,360 --> 00:34:34,669 since about 2011 when Thunderbolt showed 934 00:34:34,670 --> 00:34:36,769 up. I've personally tested about six 935 00:34:36,770 --> 00:34:38,479 or seven and found it in there. 936 00:34:40,219 --> 00:34:42,289 The pre thunderbolt devices 937 00:34:42,290 --> 00:34:43,290 are not affected. 938 00:34:52,310 --> 00:34:54,439 These also have mask from so right 939 00:34:54,440 --> 00:34:55,829 into that would be a more challenge 940 00:34:55,830 --> 00:34:56,830 anyway, 941 00:34:58,370 --> 00:35:00,889 you guys might also have heard of another 942 00:35:00,890 --> 00:35:03,349 exploit called Stuxnet that spread 943 00:35:03,350 --> 00:35:05,869 via shared USB 944 00:35:07,160 --> 00:35:09,469 media and was able to 945 00:35:09,470 --> 00:35:11,959 get all the way into the air gapped 946 00:35:11,960 --> 00:35:14,539 scatter systems of Iran's 947 00:35:14,540 --> 00:35:16,849 nuclear refinement system. 948 00:35:16,850 --> 00:35:19,039 It turns out that option rooms on 949 00:35:19,040 --> 00:35:20,989 extra on thunderbolt devices can be 950 00:35:20,990 --> 00:35:23,629 written from that early boot code. 951 00:35:23,630 --> 00:35:25,489 So this allows thunder strike to actually 952 00:35:25,490 --> 00:35:27,739 spread virally through shared 953 00:35:27,740 --> 00:35:28,729 devices. 954 00:35:28,730 --> 00:35:30,949 So you get you know, you have 955 00:35:30,950 --> 00:35:33,019 a Thunderbolt Ethernet device that 956 00:35:33,020 --> 00:35:35,449 you share between machines at work and it 957 00:35:35,450 --> 00:35:37,250 is able to go across them. 958 00:35:38,570 --> 00:35:41,169 So, you know, all 959 00:35:41,170 --> 00:35:43,369 Thunderbolt Max Mac books are vulnerable. 960 00:35:43,370 --> 00:35:44,570 They can spread virally. 961 00:35:45,740 --> 00:35:48,889 What can we do to prevent this? 962 00:35:48,890 --> 00:35:51,259 So I've been in contact with Apple 963 00:35:51,260 --> 00:35:54,289 and they have a 964 00:35:54,290 --> 00:35:56,529 they on their new machines, 965 00:35:56,530 --> 00:35:58,999 the Mac Minis, an iMac retinas 966 00:35:59,000 --> 00:36:00,799 that we've tested, they're no longer an 967 00:36:00,800 --> 00:36:02,779 option. Ramsland, firmware updates. 968 00:36:02,780 --> 00:36:04,939 They will be rolling this out for the 969 00:36:04,940 --> 00:36:06,229 other Macs. 970 00:36:06,230 --> 00:36:08,449 However, they're still loading option 971 00:36:08,450 --> 00:36:09,349 ROMs on normal. 972 00:36:09,350 --> 00:36:11,959 Boutte's snares attack from 2012 973 00:36:11,960 --> 00:36:13,279 still works. 974 00:36:13,280 --> 00:36:15,260 You can still get back doored 975 00:36:16,970 --> 00:36:18,679 via the Austin kernel. 976 00:36:19,850 --> 00:36:21,859 It's also possible on the older machines 977 00:36:21,860 --> 00:36:23,599 to do a downgrade attack that you can 978 00:36:23,600 --> 00:36:26,029 downgrade to an older, vulnerable version 979 00:36:26,030 --> 00:36:27,739 of the firmware and then attack it that 980 00:36:27,740 --> 00:36:28,740 way. 981 00:36:29,270 --> 00:36:31,369 And Thunder Strike V two could 982 00:36:31,370 --> 00:36:33,469 use the dark Jedi 983 00:36:33,470 --> 00:36:35,599 sleep attack, which you may 984 00:36:35,600 --> 00:36:36,739 have heard of. 985 00:36:36,740 --> 00:36:38,209 It was introduced yesterday 986 00:36:39,320 --> 00:36:40,880 here at thirty one C three 987 00:36:42,050 --> 00:36:44,809 by and Quarrie. 988 00:36:44,810 --> 00:36:47,569 And what they found is that 989 00:36:47,570 --> 00:36:50,059 during a S3 sleep, 990 00:36:50,060 --> 00:36:52,249 all of the lock bits 991 00:36:52,250 --> 00:36:54,319 are cleared, including lock down in the 992 00:36:54,320 --> 00:36:56,449 BIOS control the thunderbolt 993 00:36:56,450 --> 00:36:58,729 option. RAM is in a prime position 994 00:36:58,730 --> 00:37:00,499 to be able to do this sort of attack. 995 00:37:00,500 --> 00:37:01,969 It doesn't need to be privileged 996 00:37:01,970 --> 00:37:02,899 execution. 997 00:37:02,900 --> 00:37:05,359 It's already running in ring zero. 998 00:37:05,360 --> 00:37:07,549 So there was not 999 00:37:07,550 --> 00:37:08,839 enough club mate for me to actually 1000 00:37:08,840 --> 00:37:10,039 implement this last night. 1001 00:37:10,040 --> 00:37:12,529 But, you know, look for it in a 1002 00:37:12,530 --> 00:37:14,030 upcoming paper perhaps 1003 00:37:15,650 --> 00:37:17,809 so Apple could add TPM hardware 1004 00:37:17,810 --> 00:37:19,459 back to their Macs. 1005 00:37:19,460 --> 00:37:21,889 It wouldn't prevent the dark Jedi 1006 00:37:21,890 --> 00:37:23,689 attack, but it would at least let you 1007 00:37:23,690 --> 00:37:25,969 detect it on the next boot. 1008 00:37:25,970 --> 00:37:28,289 Um, they could also implement drivers 1009 00:37:28,290 --> 00:37:30,379 sign in the 1010 00:37:30,380 --> 00:37:32,659 future if EFI protocols have it as 1011 00:37:32,660 --> 00:37:33,889 almost mandatory. 1012 00:37:33,890 --> 00:37:35,989 But the version they have has 1013 00:37:35,990 --> 00:37:38,899 this rather ill-Defined security 1014 00:37:38,900 --> 00:37:41,209 architecture specific security protocol, 1015 00:37:41,210 --> 00:37:42,679 and they do implement that. 1016 00:37:42,680 --> 00:37:45,429 But this is the entirety of the 1017 00:37:45,430 --> 00:37:46,789 the implementation. 1018 00:37:46,790 --> 00:37:48,379 And it turns out that actually Proteau 1019 00:37:48,380 --> 00:37:49,579 can never be null. 1020 00:37:49,580 --> 00:37:52,129 So it just unconditionally 1021 00:37:52,130 --> 00:37:53,659 approves every option around that it 1022 00:37:53,660 --> 00:37:55,729 encounters, which does not 1023 00:37:55,730 --> 00:37:57,019 provide any security at all. 1024 00:37:58,700 --> 00:38:00,949 So because I don't 1025 00:38:00,950 --> 00:38:02,740 think option ROMs are a great idea and 1026 00:38:03,770 --> 00:38:06,109 none of my devices need it, 1027 00:38:06,110 --> 00:38:08,239 I've modified all of my Mac 1028 00:38:08,240 --> 00:38:10,639 books to to bypass this call 1029 00:38:10,640 --> 00:38:11,780 process option rom 1030 00:38:12,950 --> 00:38:15,169 and then strike actually does this 1031 00:38:15,170 --> 00:38:17,629 on the systems that it infects. 1032 00:38:17,630 --> 00:38:19,309 So you can't actually use thunder strike 1033 00:38:19,310 --> 00:38:20,359 to remove thunder strike. 1034 00:38:20,360 --> 00:38:21,860 It's close the door behind it. 1035 00:38:30,890 --> 00:38:33,109 However, closing down the 1036 00:38:33,110 --> 00:38:34,880 option arms might not even be enough. 1037 00:38:36,050 --> 00:38:37,129 How many have you plugged into the 1038 00:38:37,130 --> 00:38:38,269 projector up here? 1039 00:38:38,270 --> 00:38:39,949 How many of you actually verified what 1040 00:38:39,950 --> 00:38:42,319 the connector was that Ed Black 1041 00:38:42,320 --> 00:38:43,429 had earlier this year? 1042 00:38:43,430 --> 00:38:45,769 The Alloy Viper was deployed. 1043 00:38:45,770 --> 00:38:46,999 It's a decoy. 1044 00:38:47,000 --> 00:38:47,959 Vijay adapters. 1045 00:38:47,960 --> 00:38:49,789 Kind of hard to see there, but it does 1046 00:38:49,790 --> 00:38:52,429 change to a real VGA adapter 1047 00:38:52,430 --> 00:38:54,619 going through a slot screamer, which 1048 00:38:54,620 --> 00:38:56,929 is doing active DMA attacks against 1049 00:38:56,930 --> 00:38:59,449 the PCI buzz of the running 1050 00:38:59,450 --> 00:39:02,209 system. And it can back Doros 10 1051 00:39:02,210 --> 00:39:03,319 with a little bit more work. 1052 00:39:03,320 --> 00:39:04,939 It could actually launch a Thunder strike 1053 00:39:04,940 --> 00:39:06,769 attack as well. 1054 00:39:06,770 --> 00:39:08,839 So I believe that 1055 00:39:08,840 --> 00:39:10,939 we need a way to disable 1056 00:39:10,940 --> 00:39:13,699 PKU functions on Thunderbolt entirely, 1057 00:39:13,700 --> 00:39:15,049 that if you just want to use it for your 1058 00:39:15,050 --> 00:39:17,179 display, you shouldn't have to 1059 00:39:17,180 --> 00:39:19,069 expose your system to this sort of 1060 00:39:19,070 --> 00:39:20,070 attack. 1061 00:39:20,690 --> 00:39:21,979 I don't know a little bit of work trying 1062 00:39:21,980 --> 00:39:23,899 to do this. This would be a lot easier 1063 00:39:23,900 --> 00:39:26,209 for Apple to implement as a 1064 00:39:26,210 --> 00:39:28,339 configuration option, just like they do 1065 00:39:28,340 --> 00:39:29,689 right now. But if you said a firmware 1066 00:39:29,690 --> 00:39:32,029 password, the machine 1067 00:39:32,030 --> 00:39:34,189 won't boot from external media because 1068 00:39:34,190 --> 00:39:35,509 that's a security risk. 1069 00:39:35,510 --> 00:39:37,219 If you have a firmer password, it 1070 00:39:37,220 --> 00:39:38,419 shouldn't live in option rooms. 1071 00:39:38,420 --> 00:39:40,309 You should be able to turn off these 1072 00:39:40,310 --> 00:39:41,310 things. 1073 00:39:41,990 --> 00:39:44,059 You could also go a little more extreme. 1074 00:39:44,060 --> 00:39:46,309 Last year at thirty three, Peter 1075 00:39:46,310 --> 00:39:48,829 Susur suggested hard wiring, 1076 00:39:48,830 --> 00:39:50,989 right? Protect pens and disordering 1077 00:39:50,990 --> 00:39:53,239 programable controllers and he 1078 00:39:53,240 --> 00:39:54,859 went through a bunch of work on how to 1079 00:39:54,860 --> 00:39:57,859 harden a think pad against 1080 00:39:57,860 --> 00:39:59,569 external attacks. 1081 00:39:59,570 --> 00:40:01,639 And if you do go that far, you 1082 00:40:01,640 --> 00:40:03,469 also should consider using some sort of 1083 00:40:03,470 --> 00:40:06,349 tamper evident coverings over the screws 1084 00:40:06,350 --> 00:40:08,599 to figure out if anyone has opened 1085 00:40:08,600 --> 00:40:09,649 your machine. 1086 00:40:09,650 --> 00:40:12,409 This is suggested by Eric Michoud 1087 00:40:12,410 --> 00:40:14,570 last year, also at thirty three. 1088 00:40:16,130 --> 00:40:18,409 So to sum up, how bad 1089 00:40:18,410 --> 00:40:20,989 could an actual weaponized version of 1090 00:40:20,990 --> 00:40:22,249 Thunder strike be? 1091 00:40:22,250 --> 00:40:24,559 You know, there's nothing looking for 1092 00:40:24,560 --> 00:40:27,379 from over Kitchen Austin right now. 1093 00:40:27,380 --> 00:40:29,449 It's in control of the system from 1094 00:40:29,450 --> 00:40:31,069 the very first instruction. 1095 00:40:31,070 --> 00:40:33,019 It can backdoor the kernel, it can lock 1096 00:40:33,020 --> 00:40:35,839 keystrokes, it can exfiltrate data. 1097 00:40:35,840 --> 00:40:38,269 It can't be removed by software 1098 00:40:38,270 --> 00:40:40,429 since it controls the RSA keys. 1099 00:40:40,430 --> 00:40:42,799 It also controls the update routines. 1100 00:40:42,800 --> 00:40:44,899 You can reinstall Austin and 1101 00:40:44,900 --> 00:40:45,859 it'll still be there. 1102 00:40:45,860 --> 00:40:47,419 You can swap out your SSD. 1103 00:40:47,420 --> 00:40:48,679 It'll still be there. 1104 00:40:48,680 --> 00:40:50,989 You can swap out your laptop and 1105 00:40:50,990 --> 00:40:53,089 your thunderbolt device might 1106 00:40:53,090 --> 00:40:54,589 reinfect your new one. 1107 00:40:54,590 --> 00:40:56,090 So it's very persistent. 1108 00:40:57,140 --> 00:40:59,659 It can also hide in things like Samim 1109 00:40:59,660 --> 00:41:01,849 virtualization or maybe even 1110 00:41:01,850 --> 00:41:04,009 the management engine, though that's 1111 00:41:04,010 --> 00:41:06,499 another area of interesting research. 1112 00:41:06,500 --> 00:41:09,349 It can spread virally via shared devices 1113 00:41:09,350 --> 00:41:11,779 and it affects all current models 1114 00:41:11,780 --> 00:41:14,299 of intimate books with Thunderbolt. 1115 00:41:14,300 --> 00:41:16,519 So that's a pretty bad 1116 00:41:16,520 --> 00:41:17,719 combination of things. 1117 00:41:17,720 --> 00:41:18,889 If somebody were to actually take this 1118 00:41:18,890 --> 00:41:21,229 and turn it into more 1119 00:41:21,230 --> 00:41:22,729 than a proof of concept. 1120 00:41:22,730 --> 00:41:24,979 But what would really make it worse 1121 00:41:24,980 --> 00:41:27,169 is I think this is actually remotely 1122 00:41:27,170 --> 00:41:29,539 insoluble, combining 1123 00:41:29,540 --> 00:41:31,759 the the deep Jedi coma attack 1124 00:41:31,760 --> 00:41:34,369 with option ROMs embedded in the system. 1125 00:41:34,370 --> 00:41:35,899 I think this could actually be launched 1126 00:41:35,900 --> 00:41:38,449 with just merely a crude exploit 1127 00:41:38,450 --> 00:41:40,459 onto the system. 1128 00:41:40,460 --> 00:41:43,299 So on that cheery note, 1129 00:41:43,300 --> 00:41:44,869 I'll take some questions. 1130 00:41:44,870 --> 00:41:47,419 And also we'll be having a workshop 1131 00:41:47,420 --> 00:41:48,919 for folks who want to do a little more 1132 00:41:48,920 --> 00:41:51,049 deep dove into the into the firmware 1133 00:41:51,050 --> 00:41:53,689 images in Halsy 1134 00:41:53,690 --> 00:41:55,939 in a little while after after the talk. 1135 00:42:07,810 --> 00:42:08,810 Thank you very much. 1136 00:42:10,240 --> 00:42:12,459 We have some time for questions, other 1137 00:42:12,460 --> 00:42:14,109 questions from the Internet. 1138 00:42:14,110 --> 00:42:15,039 Yes, thank you. 1139 00:42:15,040 --> 00:42:16,809 There's one question from the Internet 1140 00:42:16,810 --> 00:42:18,699 How many Macs have been destroyed making 1141 00:42:18,700 --> 00:42:19,700 this presentation? 1142 00:42:21,280 --> 00:42:23,619 I have been quite lucky, 1143 00:42:23,620 --> 00:42:25,389 both with Magic Lantern and with this 1144 00:42:25,390 --> 00:42:27,489 project. I have managed to not brick 1145 00:42:27,490 --> 00:42:28,490 any machines. 1146 00:42:35,200 --> 00:42:37,239 OK, you can also line up behind the 1147 00:42:37,240 --> 00:42:39,429 microphones if you have questions, there 1148 00:42:39,430 --> 00:42:40,479 was the second question from the 1149 00:42:40,480 --> 00:42:41,480 Internet. 1150 00:42:44,980 --> 00:42:47,139 Then microphone number one, please, thank 1151 00:42:47,140 --> 00:42:49,489 you, was very, very cool presentation. 1152 00:42:49,490 --> 00:42:52,299 Um, if you have been thunderstruck 1153 00:42:52,300 --> 00:42:54,879 and you bless an original firmware, 1154 00:42:54,880 --> 00:42:56,649 uh, will you break the machine? 1155 00:42:56,650 --> 00:42:57,609 Yes. 1156 00:42:57,610 --> 00:42:59,499 Is that something that Thunderstruck can 1157 00:42:59,500 --> 00:43:00,099 prevent? 1158 00:43:00,100 --> 00:43:02,229 Yes, it's the proof of concept 1159 00:43:02,230 --> 00:43:03,789 is very, very simple, that it could 1160 00:43:03,790 --> 00:43:06,189 actually be much more sophisticated. 1161 00:43:06,190 --> 00:43:08,319 It could detect that this is a 1162 00:43:08,320 --> 00:43:10,869 sign an Apple Sinophile 1163 00:43:10,870 --> 00:43:12,219 and do something different. 1164 00:43:13,360 --> 00:43:14,769 It has total control of the update 1165 00:43:14,770 --> 00:43:15,699 process. 1166 00:43:15,700 --> 00:43:18,009 So it could do it could even 1167 00:43:18,010 --> 00:43:20,109 allow the update to go and then 1168 00:43:20,110 --> 00:43:22,299 patch it after the fact, 1169 00:43:22,300 --> 00:43:23,829 depending on how sophisticated you want 1170 00:43:23,830 --> 00:43:25,899 it to be. Or it might just pretend 1171 00:43:25,900 --> 00:43:28,299 to to run the update and then 1172 00:43:28,300 --> 00:43:29,469 and then ignore it. 1173 00:43:29,470 --> 00:43:30,669 OK, thanks. 1174 00:43:30,670 --> 00:43:32,979 Microphone number two, I understand 1175 00:43:32,980 --> 00:43:35,229 that you have to request the if 1176 00:43:35,230 --> 00:43:37,329 I upgrade while that device is 1177 00:43:37,330 --> 00:43:39,399 attached in order to exploit or 1178 00:43:39,400 --> 00:43:40,989 is it possible to do it just like by 1179 00:43:40,990 --> 00:43:42,939 attaching it without having to if I 1180 00:43:42,940 --> 00:43:45,069 upgrade so the option can 1181 00:43:45,070 --> 00:43:47,139 initiate a SFI update that 1182 00:43:47,140 --> 00:43:49,509 it can basically anything 1183 00:43:49,510 --> 00:43:51,279 that the kernel could do, the option arm 1184 00:43:51,280 --> 00:43:53,349 could do, but have to be doing the 1185 00:43:53,350 --> 00:43:54,849 boot Facebook and just attach it while 1186 00:43:54,850 --> 00:43:57,009 the thing is running if I want to. 1187 00:43:57,010 --> 00:43:59,139 So in this case with this with 1188 00:43:59,140 --> 00:44:01,359 a passive device like the gigabit 1189 00:44:01,360 --> 00:44:03,069 Ethernet adapter, the machine does have 1190 00:44:03,070 --> 00:44:04,070 to be rebooted 1191 00:44:05,440 --> 00:44:07,329 while it's running to its second screen. 1192 00:44:07,330 --> 00:44:09,129 Should be possible, but I have to reboot 1193 00:44:09,130 --> 00:44:09,759 it basically. 1194 00:44:09,760 --> 00:44:11,169 Yes, you do have to reboot it. 1195 00:44:11,170 --> 00:44:13,089 So, you know, from the perspective of 1196 00:44:13,090 --> 00:44:14,649 someone who's been attacked, they come 1197 00:44:14,650 --> 00:44:15,639 back and they find their machine is 1198 00:44:15,640 --> 00:44:18,159 rebooted or their machine is shut down 1199 00:44:18,160 --> 00:44:20,139 and they would say curses. 1200 00:44:21,280 --> 00:44:23,199 You know, it's pretty rare that Macs 1201 00:44:23,200 --> 00:44:24,879 crash, but they do crash occasionally. 1202 00:44:24,880 --> 00:44:27,069 So it's not out of the question, you 1203 00:44:27,070 --> 00:44:28,690 know, that that would tip them off 1204 00:44:30,160 --> 00:44:31,270 microphone number four. 1205 00:44:32,470 --> 00:44:34,899 So this attack would be Mizuki's 1206 00:44:34,900 --> 00:44:37,089 is on PCs with Thunderbolt biosecure 1207 00:44:37,090 --> 00:44:39,019 boots requiring option. 1208 00:44:39,020 --> 00:44:40,119 I'm right. 1209 00:44:40,120 --> 00:44:41,439 Absolutely. 1210 00:44:41,440 --> 00:44:43,719 So a case where security 1211 00:44:43,720 --> 00:44:45,139 does actually protect against 1212 00:44:45,140 --> 00:44:46,449 vulnerability being demonstrated on 1213 00:44:46,450 --> 00:44:47,649 stage? 1214 00:44:47,650 --> 00:44:48,609 I believe so. 1215 00:44:48,610 --> 00:44:49,610 Awesome. Thank you. 1216 00:44:50,630 --> 00:44:52,789 Microphone number five, hi, 1217 00:44:52,790 --> 00:44:53,149 thanks. 1218 00:44:53,150 --> 00:44:55,339 Thanks for your talk here 1219 00:44:55,340 --> 00:44:57,829 and back, as 1220 00:44:57,830 --> 00:44:58,880 can you imagine, 1221 00:44:59,900 --> 00:45:02,149 working on other laptops to 1222 00:45:02,150 --> 00:45:04,699 sensors, the Sun PCI Express 1223 00:45:04,700 --> 00:45:07,069 option, something could be done 1224 00:45:07,070 --> 00:45:09,379 on not Apple devices to. 1225 00:45:10,550 --> 00:45:12,679 In some other fashion, 1226 00:45:12,680 --> 00:45:15,019 so Jon Huntsman's work was on a 1227 00:45:15,020 --> 00:45:17,869 PC using just a generic PCI 1228 00:45:17,870 --> 00:45:20,059 card that had a programable option from 1229 00:45:20,060 --> 00:45:22,519 a lot of SATA controllers have them and 1230 00:45:22,520 --> 00:45:24,469 are potentially vulnerable. 1231 00:45:24,470 --> 00:45:26,689 The the ease 1232 00:45:26,690 --> 00:45:29,389 of sort of evil made attacking 1233 00:45:29,390 --> 00:45:31,250 a MacBook via Thunderbolt is much, much 1234 00:45:32,390 --> 00:45:34,339 simpler than having to open up a PC and 1235 00:45:34,340 --> 00:45:35,340 put a card into it. 1236 00:45:37,190 --> 00:45:38,149 OK. 1237 00:45:38,150 --> 00:45:39,559 Microphone number one. 1238 00:45:39,560 --> 00:45:41,659 So this would also apply to other 1239 00:45:41,660 --> 00:45:44,029 machines with Sundwall, for example, is a 1240 00:45:44,030 --> 00:45:46,429 better Lenovo's have thunderbolt 1241 00:45:46,430 --> 00:45:48,619 now and if 1242 00:45:48,620 --> 00:45:50,809 you switch off the TPM 1243 00:45:50,810 --> 00:45:53,149 chip, then you're probably vulnerable. 1244 00:45:53,150 --> 00:45:55,249 Or if somebody has a private 1245 00:45:55,250 --> 00:45:57,259 key and sign some malware with a private 1246 00:45:57,260 --> 00:45:59,269 key, then you are all vulnerable, I 1247 00:45:59,270 --> 00:46:00,270 think. 1248 00:46:00,730 --> 00:46:03,529 Exactly. And is, as Matthew 1249 00:46:03,530 --> 00:46:05,209 pointed out, that if you have a secure 1250 00:46:05,210 --> 00:46:06,649 reboot that actually signs the option 1251 00:46:06,650 --> 00:46:08,629 ROMs, then they would they would not be 1252 00:46:08,630 --> 00:46:11,059 vulnerable to this, although 1253 00:46:11,060 --> 00:46:12,559 a device with Thunderbolt would 1254 00:46:12,560 --> 00:46:15,109 potentially be subject to the 1255 00:46:15,110 --> 00:46:17,299 to the slot screamer attack, which was 1256 00:46:17,300 --> 00:46:19,679 an active PCI DMA 1257 00:46:19,680 --> 00:46:20,680 device. 1258 00:46:21,820 --> 00:46:24,009 Another question from the Internet. 1259 00:46:24,010 --> 00:46:26,199 Yes, thank you. I've got two 1260 00:46:26,200 --> 00:46:27,279 other questions. 1261 00:46:27,280 --> 00:46:29,619 The first one is, could you imagine of a 1262 00:46:29,620 --> 00:46:32,259 pure software solution as well? 1263 00:46:32,260 --> 00:46:34,389 And the second one is, is there a way 1264 00:46:34,390 --> 00:46:36,609 to detect that the, um, 1265 00:46:36,610 --> 00:46:38,439 um, the ROM is tampered with? 1266 00:46:40,100 --> 00:46:42,649 So to the software question, 1267 00:46:42,650 --> 00:46:44,539 I could imagine perhaps someone could 1268 00:46:44,540 --> 00:46:46,669 produce bug free software and 1269 00:46:46,670 --> 00:46:49,369 bios updates, but the 1270 00:46:49,370 --> 00:46:51,529 the number of presentations 1271 00:46:51,530 --> 00:46:53,659 that find flaws in 1272 00:46:53,660 --> 00:46:56,119 in software, particularly 1273 00:46:56,120 --> 00:46:58,069 in BIOS updates, makes me think of 1274 00:46:58,070 --> 00:46:58,399 software. 1275 00:46:58,400 --> 00:47:00,489 Only solution is unlikely. 1276 00:47:00,490 --> 00:47:01,490 And 1277 00:47:03,050 --> 00:47:04,799 what was the second question again? 1278 00:47:04,800 --> 00:47:07,309 Um, is there any possibility to detect 1279 00:47:07,310 --> 00:47:10,069 that the ROM is temporary? 1280 00:47:10,070 --> 00:47:12,709 So in the proof of concept, it's 1281 00:47:12,710 --> 00:47:14,659 quite trivial. It actually advertises 1282 00:47:14,660 --> 00:47:16,879 itself with the with the logo. 1283 00:47:16,880 --> 00:47:19,099 But a weaponized version would 1284 00:47:19,100 --> 00:47:21,019 be very hard to detect that if it's 1285 00:47:21,020 --> 00:47:23,269 hiding in the system management mode, it 1286 00:47:23,270 --> 00:47:25,669 can detect attempts to write 1287 00:47:25,670 --> 00:47:28,159 to the extent to read from the ROM 1288 00:47:28,160 --> 00:47:30,469 and serve up a clean copy, or 1289 00:47:30,470 --> 00:47:32,599 it could put the system into 1290 00:47:32,600 --> 00:47:35,119 virtualization and just provide 1291 00:47:35,120 --> 00:47:37,429 a complete virtual from that looks 1292 00:47:37,430 --> 00:47:38,430 intact. 1293 00:47:39,900 --> 00:47:42,119 Microphone number two, are 1294 00:47:42,120 --> 00:47:44,489 you missing any features like booting 1295 00:47:44,490 --> 00:47:46,619 from network if you disable the option 1296 00:47:46,620 --> 00:47:47,459 ROMs? 1297 00:47:47,460 --> 00:47:49,589 Now the it turns 1298 00:47:49,590 --> 00:47:51,839 out that the modern Mac books have the 1299 00:47:51,840 --> 00:47:53,909 driver for the gigabit 1300 00:47:53,910 --> 00:47:56,069 either adapter bundled into into their 1301 00:47:56,070 --> 00:47:56,999 room already. 1302 00:47:57,000 --> 00:47:58,229 So the option room is completely 1303 00:47:58,230 --> 00:47:59,249 superfluous. 1304 00:47:59,250 --> 00:48:01,169 It serves no purpose. 1305 00:48:01,170 --> 00:48:02,399 Thanks No. 1306 00:48:02,400 --> 00:48:04,679 One. OK, two quick questions. 1307 00:48:04,680 --> 00:48:06,779 First, if you mentioned, I 1308 00:48:06,780 --> 00:48:08,579 think that you have to bless a former 1309 00:48:08,580 --> 00:48:10,409 update to launch the attack. 1310 00:48:10,410 --> 00:48:12,479 So if I said a firmer password and 1311 00:48:12,480 --> 00:48:14,339 shut down my computer before I leave it 1312 00:48:14,340 --> 00:48:16,079 in my hotel room, can I prevent it? 1313 00:48:16,080 --> 00:48:18,209 Now, the former password is 1314 00:48:18,210 --> 00:48:20,639 actually checked after option rooms. 1315 00:48:20,640 --> 00:48:22,739 So there's a another 1316 00:48:24,240 --> 00:48:26,249 there's a much simpler attack that an 1317 00:48:26,250 --> 00:48:27,689 option can actually clear your firmware 1318 00:48:27,690 --> 00:48:28,690 password. 1319 00:48:29,460 --> 00:48:31,619 And to the other point, your part 1320 00:48:31,620 --> 00:48:33,629 of your question, the option doesn't 1321 00:48:33,630 --> 00:48:35,549 actually even need a boot OS 10. 1322 00:48:35,550 --> 00:48:37,889 It can it can just set the environ 1323 00:48:37,890 --> 00:48:40,139 variable and initiate a recovery 1324 00:48:40,140 --> 00:48:42,989 and then initiate a recovery mode reboot 1325 00:48:42,990 --> 00:48:44,819 from the option room because it's in 1326 00:48:44,820 --> 00:48:45,239 zero. 1327 00:48:45,240 --> 00:48:48,189 It can do pretty much anything. 1328 00:48:48,190 --> 00:48:49,799 Microphone number three. 1329 00:48:49,800 --> 00:48:52,109 So do you 1330 00:48:52,110 --> 00:48:54,509 think that a opensource 1331 00:48:54,510 --> 00:48:56,609 solution, do you think that an 1332 00:48:56,610 --> 00:48:58,379 open source solution as opposed to an 1333 00:48:58,380 --> 00:49:00,690 open standard solution? 1334 00:49:03,400 --> 00:49:05,809 Would be able to avoid this problem 1335 00:49:05,810 --> 00:49:07,869 or have you investigated in 1336 00:49:07,870 --> 00:49:09,729 particular, Corbould, if Corbould is 1337 00:49:09,730 --> 00:49:11,749 vulnerable to this problem, I believe 1338 00:49:11,750 --> 00:49:13,929 GROBART is not vulnerable to either 1339 00:49:13,930 --> 00:49:15,909 thunder strike or to the jet Ikoma 1340 00:49:15,910 --> 00:49:17,279 attacks. 1341 00:49:17,280 --> 00:49:19,359 I have not done really any work 1342 00:49:19,360 --> 00:49:21,549 with Corbitt, so I'm not 1343 00:49:21,550 --> 00:49:23,829 sure, although in general 1344 00:49:23,830 --> 00:49:25,449 we should talk then we should. 1345 00:49:25,450 --> 00:49:27,759 In general, I think that having open 1346 00:49:27,760 --> 00:49:29,889 source for the for the early 1347 00:49:29,890 --> 00:49:32,259 Bhoot is really vital 1348 00:49:32,260 --> 00:49:34,449 both to trust that the system 1349 00:49:34,450 --> 00:49:36,039 is doing what we think it is. 1350 00:49:36,040 --> 00:49:37,269 And this is one of the reasons I'm really 1351 00:49:37,270 --> 00:49:39,549 excited about things like Bunny's laptop 1352 00:49:39,550 --> 00:49:41,409 that we're all of the source for. 1353 00:49:41,410 --> 00:49:43,269 Every piece in the system is available so 1354 00:49:43,270 --> 00:49:45,069 that we can actually understand how it 1355 00:49:45,070 --> 00:49:46,070 all works. 1356 00:49:48,300 --> 00:49:50,759 OK, so 1357 00:49:50,760 --> 00:49:53,039 we are running out of time, so please 1358 00:49:53,040 --> 00:49:55,049 keep your questions and if possible, the 1359 00:49:55,050 --> 00:49:57,149 answer short microphone number four. 1360 00:49:57,150 --> 00:49:59,369 Yes, as you've shown, the firmware 1361 00:49:59,370 --> 00:50:01,589 update not only contains a signature, 1362 00:50:01,590 --> 00:50:03,479 but also a public key. 1363 00:50:03,480 --> 00:50:05,639 What happens if you replace a public 1364 00:50:05,640 --> 00:50:07,559 key and then just create another 1365 00:50:07,560 --> 00:50:08,560 signature? 1366 00:50:09,140 --> 00:50:10,140 Have you tried that? 1367 00:50:10,970 --> 00:50:12,889 Oh, I'm sorry. 1368 00:50:12,890 --> 00:50:15,379 Oh, yes, actually, the 1369 00:50:15,380 --> 00:50:17,059 I didn't go into the presentation. 1370 00:50:17,060 --> 00:50:18,829 I have a paper that I hope will be coming 1371 00:50:18,830 --> 00:50:20,599 out sometime soon that actually goes into 1372 00:50:20,600 --> 00:50:22,219 a lot more technical detail. 1373 00:50:22,220 --> 00:50:24,289 The the public key in 1374 00:50:24,290 --> 00:50:25,759 the signature is actually ignored. 1375 00:50:25,760 --> 00:50:27,499 You can write whatever you want there and 1376 00:50:27,500 --> 00:50:29,149 it doesn't matter. 1377 00:50:29,150 --> 00:50:31,249 The the public key is actually 1378 00:50:31,250 --> 00:50:33,559 stored in in the in the boot from 1379 00:50:33,560 --> 00:50:35,449 there. Actually five public keys, but 1380 00:50:35,450 --> 00:50:37,489 only key zero is ever read. 1381 00:50:37,490 --> 00:50:39,649 And that is the one that is actually used 1382 00:50:39,650 --> 00:50:42,379 to to validate the signature. 1383 00:50:42,380 --> 00:50:43,369 Thanks. 1384 00:50:43,370 --> 00:50:45,589 Microphone number two, have you looked 1385 00:50:45,590 --> 00:50:47,719 at other attack vectors 1386 00:50:47,720 --> 00:50:49,499 than Thunderbolt or PCI? 1387 00:50:49,500 --> 00:50:51,469 Ilene's like express cards. 1388 00:50:51,470 --> 00:50:53,689 I have not, but I've 1389 00:50:53,690 --> 00:50:55,609 I've received email from someone who has 1390 00:50:55,610 --> 00:50:57,469 looked at it and suggests that it would 1391 00:50:57,470 --> 00:51:00,529 also be vulnerable to this sort of attack 1392 00:51:00,530 --> 00:51:02,299 on microphone number one again. 1393 00:51:02,300 --> 00:51:04,369 And I launched this attack from another 1394 00:51:04,370 --> 00:51:05,689 MacBook with a Thunderbolt cable. 1395 00:51:05,690 --> 00:51:06,800 Or do I need special hardware? 1396 00:51:10,000 --> 00:51:11,139 That's an interesting question, 1397 00:51:12,220 --> 00:51:13,989 I have not looked into that, whether or 1398 00:51:13,990 --> 00:51:15,939 not if you boot into a target drive mode, 1399 00:51:15,940 --> 00:51:18,040 could you could you fake it out? 1400 00:51:19,480 --> 00:51:21,549 Possibly that might be 1401 00:51:21,550 --> 00:51:22,550 cheaper that. 1402 00:51:24,390 --> 00:51:26,369 I don't know, I haven't looked enough 1403 00:51:26,370 --> 00:51:27,370 into that part of the firmware 1404 00:51:28,590 --> 00:51:30,509 microphone number five. 1405 00:51:30,510 --> 00:51:32,639 Yes, you said that 1406 00:51:32,640 --> 00:51:34,709 with your like you can close the 1407 00:51:34,710 --> 00:51:36,869 door behind you for this exploit. 1408 00:51:36,870 --> 00:51:39,299 Can you provide the service to close 1409 00:51:39,300 --> 00:51:40,300 all our Mike Brooks 1410 00:51:41,580 --> 00:51:43,609 if anyone would like to borrow a 1411 00:51:43,610 --> 00:51:44,849 Thunderbolt Ethernet adapter? 1412 00:51:48,340 --> 00:51:50,799 So right now, my proof of concept is 1413 00:51:50,800 --> 00:51:52,659 has a lot of hardcoded things for the 1414 00:51:52,660 --> 00:51:54,729 specific version, so 1415 00:51:54,730 --> 00:51:57,159 I verified that the the 1416 00:51:57,160 --> 00:51:59,229 sort of exploit works against the other 1417 00:51:59,230 --> 00:52:02,309 ones, but I've only actually implemented 1418 00:52:02,310 --> 00:52:05,379 the 10 CUMA one MacBook. 1419 00:52:05,380 --> 00:52:07,509 So if you have one of those, I'd be happy 1420 00:52:07,510 --> 00:52:09,460 to to let you upgrade 1421 00:52:11,230 --> 00:52:12,739 microphone number three. 1422 00:52:12,740 --> 00:52:15,009 OK, so I'm wondering, since the option 1423 00:52:15,010 --> 00:52:17,109 Rum's only loaded during boot and you 1424 00:52:17,110 --> 00:52:19,389 can basically, as far as I know, prevent 1425 00:52:19,390 --> 00:52:21,549 access via the system running by 1426 00:52:21,550 --> 00:52:23,379 setting a firmware password. 1427 00:52:23,380 --> 00:52:25,809 And you said it's possible to write 1428 00:52:25,810 --> 00:52:27,999 the option rom if you are 1429 00:52:28,000 --> 00:52:29,379 early in the process. 1430 00:52:29,380 --> 00:52:31,479 Is there any way, once you've booted 1431 00:52:31,480 --> 00:52:33,579 to check if your adapter has 1432 00:52:33,580 --> 00:52:34,580 been infected? 1433 00:52:35,740 --> 00:52:36,740 I. 1434 00:52:38,010 --> 00:52:40,469 Potentially so from a clean system, 1435 00:52:41,610 --> 00:52:43,859 you could read out the option and find 1436 00:52:43,860 --> 00:52:46,050 out if it contains an exploit in it. 1437 00:52:47,070 --> 00:52:49,169 But once from an infected 1438 00:52:49,170 --> 00:52:51,449 system, if it were being sufficiently 1439 00:52:51,450 --> 00:52:53,699 stealthy, it could mask that attempt 1440 00:52:53,700 --> 00:52:54,700 to read. 1441 00:52:56,400 --> 00:52:58,269 And you had a second question that 1442 00:52:58,270 --> 00:53:00,149 actually I thought was quite good, that 1443 00:53:02,400 --> 00:53:04,589 regarding DMA, there's 1444 00:53:04,590 --> 00:53:06,569 a lot of interesting work being done with 1445 00:53:06,570 --> 00:53:09,150 Thunderbolt and DNA attacks, especially 1446 00:53:11,040 --> 00:53:13,699 looking into how well does 1447 00:53:13,700 --> 00:53:15,779 in the amamou actually protect 1448 00:53:15,780 --> 00:53:18,599 you. And it's not clear 1449 00:53:18,600 --> 00:53:20,789 that it provides as much protection is 1450 00:53:20,790 --> 00:53:21,790 as we would like. 1451 00:53:23,510 --> 00:53:24,799 Microphone number four. 1452 00:53:24,800 --> 00:53:26,809 OK, forgive me if this is a stupid 1453 00:53:26,810 --> 00:53:28,699 question, but other than open sourcing 1454 00:53:28,700 --> 00:53:30,439 the process entirely, which is a no 1455 00:53:30,440 --> 00:53:32,809 brainer, could vendors protect 1456 00:53:32,810 --> 00:53:35,299 against this kind of attack by using 1457 00:53:35,300 --> 00:53:37,819 something like timing based attestation 1458 00:53:37,820 --> 00:53:39,289 of the firmware? 1459 00:53:39,290 --> 00:53:41,569 So knowing the timing 1460 00:53:41,570 --> 00:53:43,999 signature that the legitimate firmware 1461 00:53:44,000 --> 00:53:46,129 has and measuring that in 1462 00:53:46,130 --> 00:53:49,009 the operating system, also another 1463 00:53:49,010 --> 00:53:50,689 kind of electronic device that measures 1464 00:53:50,690 --> 00:53:53,119 that, that then if an attacker uploads 1465 00:53:53,120 --> 00:53:54,799 their own malicious firmware, they at 1466 00:53:54,800 --> 00:53:56,959 least have to emulate the timing 1467 00:53:56,960 --> 00:53:59,899 side channel of the legitimate firmware. 1468 00:53:59,900 --> 00:54:02,209 So to the first part of the question, 1469 00:54:02,210 --> 00:54:03,919 I don't think so. 1470 00:54:03,920 --> 00:54:06,049 The Meitner presented a really 1471 00:54:06,050 --> 00:54:08,269 neat piece of malware called a tick 1472 00:54:08,270 --> 00:54:10,009 that I think was 51 bytes, and it was 1473 00:54:10,010 --> 00:54:12,019 capable of beating the time timing based 1474 00:54:12,020 --> 00:54:13,339 attestation. 1475 00:54:13,340 --> 00:54:15,499 The other is that it could put 1476 00:54:15,500 --> 00:54:16,910 the system under vocalized 1477 00:54:18,650 --> 00:54:20,269 environment or it could just rewrite the 1478 00:54:20,270 --> 00:54:22,339 timestamp counter that it's you know, 1479 00:54:22,340 --> 00:54:23,659 it's in ring zero. 1480 00:54:23,660 --> 00:54:25,099 It's in real mode. 1481 00:54:25,100 --> 00:54:27,679 It can do really whatever it wants. 1482 00:54:27,680 --> 00:54:29,479 Thank you. Another question from number 1483 00:54:29,480 --> 00:54:30,480 four. 1484 00:54:32,090 --> 00:54:34,249 Um, just very two 1485 00:54:34,250 --> 00:54:36,499 very short questions, uh, 1486 00:54:36,500 --> 00:54:38,659 the one was to verify, again, you 1487 00:54:38,660 --> 00:54:41,269 said the current IMEX and McManis 1488 00:54:41,270 --> 00:54:43,579 are not affected and future Mac books 1489 00:54:43,580 --> 00:54:45,739 will won't have this 1490 00:54:45,740 --> 00:54:47,509 problem that. 1491 00:54:47,510 --> 00:54:49,789 So Apple 1492 00:54:49,790 --> 00:54:52,069 has produced a fix that they are 1493 00:54:52,070 --> 00:54:54,199 shipping in the current Mac minis 1494 00:54:54,200 --> 00:54:56,479 and iMac retina's that 1495 00:54:56,480 --> 00:54:58,579 protects against the proof 1496 00:54:58,580 --> 00:55:00,109 of concept. 1497 00:55:00,110 --> 00:55:02,419 However, it leaves out 1498 00:55:02,420 --> 00:55:04,639 a huge hole in terms 1499 00:55:04,640 --> 00:55:06,649 of the option ROMs that I believe could 1500 00:55:06,650 --> 00:55:08,779 be a thunder strike V 1501 00:55:08,780 --> 00:55:10,969 two, which would fairly easily be able to 1502 00:55:10,970 --> 00:55:12,289 attack. 1503 00:55:12,290 --> 00:55:14,359 And the second question was, 1504 00:55:14,360 --> 00:55:15,360 um. 1505 00:55:15,950 --> 00:55:18,369 Um, proprietory 2pm 1506 00:55:18,370 --> 00:55:20,749 modules have been, uh, 1507 00:55:20,750 --> 00:55:22,639 criticized, um, 1508 00:55:24,310 --> 00:55:26,959 what do you think is is other 1509 00:55:26,960 --> 00:55:29,629 more helpful or are they 1510 00:55:29,630 --> 00:55:30,589 in any kind? 1511 00:55:30,590 --> 00:55:33,499 Uh, do they have any drawbacks 1512 00:55:33,500 --> 00:55:35,239 if they're not open source? 1513 00:55:35,240 --> 00:55:37,229 So is it better to have a machine with 1514 00:55:37,230 --> 00:55:39,079 the TPM module or without one? 1515 00:55:41,650 --> 00:55:43,749 To perhaps 2pm is not not 1516 00:55:43,750 --> 00:55:45,969 exactly the right word, but some 1517 00:55:45,970 --> 00:55:47,260 systems have sort of 1518 00:55:48,380 --> 00:55:50,589 a coup processers 1519 00:55:50,590 --> 00:55:52,389 or sometimes even hardware devices that 1520 00:55:52,390 --> 00:55:54,639 will leave the main CPU and reset until 1521 00:55:54,640 --> 00:55:56,799 they do cryptographic verification of 1522 00:55:56,800 --> 00:55:57,759 the boot rom. 1523 00:55:57,760 --> 00:56:00,039 So that's the sort of technology 1524 00:56:00,040 --> 00:56:02,499 that I think is really necessary 1525 00:56:02,500 --> 00:56:04,749 to detect these sort of attacks. 1526 00:56:04,750 --> 00:56:06,879 There's a huge number of papers about 1527 00:56:06,880 --> 00:56:09,399 defeating TPIMs and security via 1528 00:56:09,400 --> 00:56:11,529 the other techniques, so I'm not 1529 00:56:11,530 --> 00:56:13,090 sure how well, 1530 00:56:14,230 --> 00:56:17,169 you know, proprietary TPM versus 1531 00:56:17,170 --> 00:56:19,029 some more open source one would really be 1532 00:56:19,030 --> 00:56:20,030 able to do. 1533 00:56:20,940 --> 00:56:23,039 OK, one final question from number two, 1534 00:56:24,120 --> 00:56:26,159 just to make sure it's not that I can't 1535 00:56:26,160 --> 00:56:27,509 leave my computer in a room, I can't 1536 00:56:27,510 --> 00:56:29,219 leave any of my Thunderball devices 1537 00:56:29,220 --> 00:56:29,529 either. 1538 00:56:29,530 --> 00:56:30,530 Right. 1539 00:56:30,780 --> 00:56:32,939 That's that's a great 1540 00:56:32,940 --> 00:56:34,109 point. Yes. 1541 00:56:34,110 --> 00:56:35,729 You should keep your your thunderbolt 1542 00:56:35,730 --> 00:56:37,889 devices with you along with the computer. 1543 00:56:37,890 --> 00:56:39,059 And having said that. 1544 00:56:40,880 --> 00:56:43,009 Would it theoretically be possible if you 1545 00:56:43,010 --> 00:56:44,509 do achieve good execution from the 1546 00:56:44,510 --> 00:56:46,909 Thunderbolt device to actually perform 1547 00:56:46,910 --> 00:56:48,619 tests through that code? 1548 00:56:48,620 --> 00:56:50,719 Could I create a Thunderbolt device 1549 00:56:50,720 --> 00:56:53,059 that actually uses an option room 1550 00:56:53,060 --> 00:56:54,379 to check my own? 1551 00:56:54,380 --> 00:56:56,959 If I you could. 1552 00:56:56,960 --> 00:56:58,969 Unless you're running, unless you've 1553 00:56:58,970 --> 00:57:00,499 already been hit, in which case the 1554 00:57:00,500 --> 00:57:02,679 option won't be loaded at all. 1555 00:57:03,950 --> 00:57:06,169 OK, that so all 1556 00:57:06,170 --> 00:57:08,239 of my machines are protected in this way 1557 00:57:08,240 --> 00:57:10,519 that they will not load option 1558 00:57:10,520 --> 00:57:13,309 rooms, which is also, 1559 00:57:13,310 --> 00:57:14,510 you know, the sort of thing that 1560 00:57:15,650 --> 00:57:16,819 would be great if it a configuration 1561 00:57:16,820 --> 00:57:18,439 option just to be able to say, you know, 1562 00:57:18,440 --> 00:57:20,150 don't do this first, then you'd know. 1563 00:57:21,180 --> 00:57:23,489 If it doesn't execute, then you'd know 1564 00:57:23,490 --> 00:57:25,619 if it had some way to let you know that 1565 00:57:25,620 --> 00:57:27,809 it had executed, I 1566 00:57:27,810 --> 00:57:29,279 suppose it depends how targeted of an 1567 00:57:29,280 --> 00:57:31,170 attack you you're expecting. 1568 00:57:34,370 --> 00:57:36,589 OK, so please give again a round 1569 00:57:36,590 --> 00:57:37,590 of applause to general.