1 00:00:01,620 --> 00:00:02,300 Hello? 2 00:00:02,300 --> 00:00:03,180 Is this thing on? 3 00:00:04,680 --> 00:00:06,200 Hi, everyone. 4 00:00:06,200 --> 00:00:08,540 Welcome to our talk, Bites in Disguise. 5 00:00:08,700 --> 00:00:14,940 If you happen to watch this as it's being released by DEF CON, we want to thank you for tuning in on a Sunday morning. 6 00:00:15,060 --> 00:00:16,460 You brave souls. 7 00:00:16,560 --> 00:00:21,500 If you're watching this on YouTube at some point later on, well, thank you, you lazy f**ks. 8 00:00:21,640 --> 00:00:23,140 My name is Mickey. 9 00:00:23,160 --> 00:00:24,240 And I'm Jesse. 10 00:00:24,420 --> 00:00:25,600 I'm on the left. 11 00:00:25,600 --> 00:00:29,600 Jesse's on the right, just so you'd know to associate our faces with our voices now. 12 00:00:30,120 --> 00:00:35,500 We're both principal security researchers at Eclipseum, and we deal with hardware and firmware on a daily basis. 13 00:00:35,500 --> 00:00:39,200 Now that we have all the formalities out of the way, we can start with the actual talk. 14 00:00:39,200 --> 00:00:43,140 We'd like to start with a little bit of structure. 15 00:00:43,180 --> 00:00:44,280 What are we going to talk about? 16 00:00:44,280 --> 00:00:45,760 The agenda and high level. 17 00:00:46,340 --> 00:00:58,480 We want you to understand the background and the why, because it's very important for you to see things from a different viewpoint, our own viewpoint. 18 00:00:58,480 --> 00:01:07,560 We hope that by showing you what motivated us to look into this research, you'll be able to understand and maybe go out on your own and explore this yourselves. 19 00:01:08,040 --> 00:01:18,040 Once we've established that, we can show you what we did from an attack surface perspective, how we look at things from a hardware firmware perspective. 20 00:01:18,920 --> 00:01:29,360 After that, we can continue and walk you through some of the hiding places inside computers, servers, laptops, or any other computer platform. 21 00:01:29,380 --> 00:01:42,780 We thought about the best way to do this and we decided that it will be best if we start explaining each hiding spot and immediately after that, go through the attack surface scenarios and examples for that spot. 22 00:01:43,460 --> 00:01:56,800 Once that's all done, we'll discuss a little bit of what's in store for these types of threats in the future of the security industry and what can we do to protect against them. 23 00:01:56,800 --> 00:02:19,540 In the past, we've seen a lot of research talking about bad devices being abused like bad USB, rubber duckies, OMG cables, which are the best cables, all these malicious devices, dropping code, executing it from a separate device, hiding things off the platform. 24 00:02:19,700 --> 00:02:22,320 But the main issue is persistence. 25 00:02:22,380 --> 00:02:33,760 If your payload has to be plugged into the target to replay every time, even if it still stays undetectable, having a thumb drive stick out of your computer would be noticed by a user. 26 00:02:33,780 --> 00:02:35,480 You can't really hide that. 27 00:02:35,480 --> 00:02:45,080 So what if you could have your loader persistent and just have the payload itself, that's the malicious code, stored somewhere in your device. 28 00:02:45,080 --> 00:02:57,580 The easiest things to find about this type of research that was done in the past is fileless malware and fileless exploits and in-memory execution and anything that doesn't touch disk. 29 00:02:57,680 --> 00:02:59,360 And remember, don't touch disk. 30 00:02:59,360 --> 00:03:10,900 And one of those examples is a talk that was done last year at DEF CON by Topher and Mike that discussed about abusing this exact thing in UEFI variable. 31 00:03:11,060 --> 00:03:15,700 We usually describe this in the slide and say, look, past research done this and that. 32 00:03:15,700 --> 00:03:21,420 But since we know these guys, we thought we'd just ask them and record them and just replay it for you guys. 33 00:03:21,420 --> 00:03:23,300 So here's Topher and Mike. 34 00:03:23,620 --> 00:03:26,180 Topher is the left in the picture and Mike is on the right. 35 00:03:26,180 --> 00:03:28,440 So I hope you enjoy and help us embarrass them. 36 00:03:29,760 --> 00:03:31,160 Hey, I'm Topher Timson. 37 00:03:31,240 --> 00:03:32,600 Hey, I'm Michael Lebowitz. 38 00:03:32,600 --> 00:03:37,380 Last year at DEF CON, Mike and I gave a talk entitled EDR is coming, hide your shit. 39 00:03:37,380 --> 00:03:53,460 The reason that we did this research and gave this presentation is because we've been red teaming for a number of years now, and we were running into the problem that a lot of our malicious payloads and our malware were being eaten up by whether it be AV solutions or EDR solutions. 40 00:03:53,720 --> 00:03:57,860 And the blue team was discovering us and ruining our engagements. 41 00:03:57,860 --> 00:04:03,800 And, you know, when your lovingly crafted payload becomes some analyst sample, everyone's going to have a bad evening. 42 00:04:03,800 --> 00:04:12,600 So in looking at new areas in which we could hide our shit, we effectively wanted to get off of disk. 43 00:04:12,600 --> 00:04:20,180 The rationale for this was because having things on disk leaves it vulnerable to AV scanning it. 44 00:04:20,180 --> 00:04:25,780 It allows analysts to look at hashes of the binaries. 45 00:04:25,780 --> 00:04:36,760 The EDR solution sees that they're executing these binaries and all the activity that they're doing is shown to the analyst in whatever EDR platforms console they're using. 46 00:04:37,180 --> 00:04:42,200 In looking at ways to hide our shit, we looked into UEFI. 47 00:04:42,200 --> 00:04:45,680 So I used to do some UEFI security research. 48 00:04:45,680 --> 00:04:52,060 So I was already somewhat familiar with how UEFI worked as this firmware platform. 49 00:04:52,060 --> 00:04:57,440 And variables are something that were exposed after boot services. 50 00:04:57,440 --> 00:05:02,340 So they were available at runtime and actually booting the platform. 51 00:05:02,340 --> 00:05:09,620 Windows 10 re-added a UEFI API that allowed you to read and write UEFI firmware variables. 52 00:05:09,620 --> 00:05:19,740 And I had already known, or at least I had suspected, that EDR platforms were not at all scanning the UEFI firmware variable space in NVRAM. 53 00:05:19,740 --> 00:05:29,300 Everything that we had seen, it was all about what's on the hard drive, what's being executed from the hard drive, and we saw no notion of anything having to do with firmware. 54 00:05:29,300 --> 00:05:39,200 So we put our payload there, and lo and behold, analysts were completely blind and the EDR solution and AV solutions never saw our actual malicious payloads. 55 00:05:39,200 --> 00:05:49,980 They would see the binaries that we dropped on disk that would execute the payloads out of the UEFI variable, but those are seemingly benign and they're like four kilobyte binaries. 56 00:05:50,020 --> 00:06:05,560 In our talk, I handled the Windows platform piece, and my C-sharp binary to do reflective loading of a UEFI variable is like 15 lines of code, and nobody sees it at all in their UEFI platforms at the time. 57 00:06:05,560 --> 00:06:18,160 A couple of vendors have added some mitigations to this and are seemingly less blind, but it's still a problem facing a lot of these security solutions where if you hide stuff off of disk, they're not seen. 58 00:06:18,280 --> 00:06:41,840 As ever said, we want to muddy the water for analysis, and the analysis is highly correlated to the process image that you're running, and UEFI is an area that we're both familiar with, and UEFI access is available in Ring 3, and anytime you have delegated access in Ring 3 to something that is like a system firmware component, 59 00:06:41,840 --> 00:06:43,380 you're in for a good time. 60 00:06:43,440 --> 00:07:07,640 And I had previously done some research where I put malicious content into a RAM disk, and so now I had done this such that the malicious content was essentially benign and a very simple loader that could load the end payload from UEFI and then persist across the RAM disk boundary and then infect the EDR platform on the host system. 61 00:07:07,640 --> 00:07:19,640 So in total, a three-stage payload system with only one part, the tiniest loader on disk, but in a sort of awkward place in disk that's hard to find. 62 00:07:19,640 --> 00:07:38,660 And the whole rationale behind this was making it easier for offensive security practitioners and people on red teams to evade detection, because anytime you execute something to get that initial access, that will leave a lot of traces, particularly in EDR. 63 00:07:38,660 --> 00:07:50,760 But we were all about reducing that threat to detection for us after the fact, and by hiding your shit in places that these platforms are blind to, you can persist for longer. 64 00:07:50,800 --> 00:08:04,040 And in reality, what we're really trying to do is bring net happiness to the world, because we're now happy that we can persist for longer and run our engagements for longer, but the blue team's also happy because they don't have to work till midnight hunting us down. 65 00:08:04,040 --> 00:08:12,260 It's true as it is now, it was then, we need to flatten the curve, the curve of risk of you being detected over time. 66 00:08:12,260 --> 00:08:16,240 But no good thing lasts forever, and eventually your breach is going to get detected. 67 00:08:16,240 --> 00:08:18,900 But we just want that to go a little bit longer. 68 00:08:19,520 --> 00:08:22,160 Thank you Topher and Mike for that amazing summary. 69 00:08:22,680 --> 00:08:36,820 Just to recap some of the things that we want to emphasize here is, we want to avoid detection, we want to make it harder for forensic analysts to find our payload, we want to have code caves that we can abuse later on. 70 00:08:36,880 --> 00:08:45,440 Basically storing anything in non-conventional storage that the analysts are not looking at, hiding their blind spots. 71 00:08:45,600 --> 00:08:48,640 A little bit about UEFI variables. 72 00:08:48,720 --> 00:08:58,280 We've seen last year, we know EDR and AV have started looking into these and now we've seen Microsoft adding capabilities, we'll talk about them later. 73 00:08:58,680 --> 00:09:18,860 But using get and set variable is something that an attacker uses that is exposed by the Windows API, which is nice and handy if you get that coveted admin privilege, but it's not that handy when you are worried about AV and EDR hooking and monitoring your behavior. 74 00:09:18,860 --> 00:09:31,280 So think about it like this, these API calls are not commonly used and if you call them, you will raise so many red flags, you just want to hide under a rock. 75 00:09:31,800 --> 00:09:41,280 But under the hood, these API calls are basically a Windows wrapper to something called Runtime Services. 76 00:09:41,280 --> 00:09:59,960 UEFI-based BIOS has these function calls in memory, which are called Runtime Services that are obviously, well, as the name suggests, they're available during runtime, but they're only in ring zero, which means the Windows API calls those Runtime Services from a ring zero context. 77 00:09:59,960 --> 00:10:09,680 However, if you as an attacker can get code executing in ring zero, you can call those Runtime Services directly. 78 00:10:09,680 --> 00:10:23,580 The trick is they have a magic header in memory that you can search for and then you can find the Runtime Services table and then from there extrapolate the calls for setting a variable and getting a variable. 79 00:10:23,760 --> 00:10:33,760 All that's nice and dandy in theory, but to get that running in ring zero with modern protections that Windows is incorporating is going to be tricky. 80 00:10:34,360 --> 00:10:43,720 Okay, first step in understanding what we have at our disposal is do a proper attack surface enumeration or proper scoping. 81 00:10:43,720 --> 00:10:46,180 Let's talk about some of the ways that you can do that. 82 00:10:46,180 --> 00:10:53,180 First and most obvious way is to get your hands on your machine and pop open the box and look at what you're attacking. 83 00:10:53,180 --> 00:11:03,160 It can be a laptop, desktop, server, industrial controller, whatever you think falls under the definition of the word computer. 84 00:11:03,180 --> 00:11:10,060 But whatever you do, for the love of God, remember to unplug it from power before you take it apart. 85 00:11:11,720 --> 00:11:14,900 Some of the key things to remember when you take things apart. 86 00:11:15,160 --> 00:11:18,700 Remember where you put the screws you took out. 87 00:11:18,700 --> 00:11:20,200 Don't lose them. 88 00:11:20,200 --> 00:11:27,940 Remember which screw goes to which hole because some of them are longer than the others. 89 00:11:27,940 --> 00:11:36,720 And for some diabolical reason, vendors tend to not adhere to the same standard across devices. 90 00:11:36,780 --> 00:11:53,600 So while Dell laptops tend to have the same length of screws holding their chassis in, some other third-party vendors would have, and I shit you not, 14 different screws that have six different lengths in the bottom of the laptop. 91 00:11:54,780 --> 00:11:58,560 Also remember to group them and label them. 92 00:11:59,020 --> 00:12:03,100 And if you have any static electricity, remember to dispose of it. 93 00:12:03,100 --> 00:12:11,000 If you don't have any static electricity, you know, wristbands or anything, just YOLO and hope that you don't break your machine. 94 00:12:13,220 --> 00:12:18,720 Once you got it open, you need to get a magnifying glass or a jeweler's loop. 95 00:12:19,460 --> 00:12:24,500 You can pick these up at like a couple of bucks on Amazon or eBay. 96 00:12:25,720 --> 00:12:33,760 Many computers have a lot of chips that look similar and have some very similar markings. 97 00:12:33,760 --> 00:12:49,720 For example, spy chips made by Windbond will have very, very similar labels on them, but you'd find a couple of them on the same computer and when you won't be sure what's what, we recommend that you take a picture. 98 00:12:49,720 --> 00:12:50,720 Use your phone. 99 00:12:50,720 --> 00:12:55,040 You have this device that gives you access to all the cat images on the internet. 100 00:12:55,100 --> 00:12:56,480 Use it to take pictures. 101 00:12:56,900 --> 00:13:03,040 If you can label the pictures, label them, but just take a picture of it with your phone and save it for later. 102 00:13:03,040 --> 00:13:04,200 I know this sounds basic. 103 00:13:04,200 --> 00:13:12,680 Everything I say sounds super basic, but these are things that you'd wish you'd thought of at some point. 104 00:13:12,680 --> 00:13:18,440 I myself had written these down and it's lessons learned in blood. 105 00:13:18,680 --> 00:13:24,580 If you're afraid to open your $1,500 laptop, don't worry. 106 00:13:24,620 --> 00:13:27,280 Someone on the internet has probably done it for you. 107 00:13:27,280 --> 00:13:31,540 So you need to google the shit out of teardown images. 108 00:13:31,540 --> 00:13:52,980 Seriously, start googling the words teardown or memory upgrade or SSD upgrade or any of those and you'd find a lot of repair shops or repair tutorials or upgrade tutorials online that have HD videos and images of the computers you're looking at. 109 00:13:52,980 --> 00:14:11,320 You might not be able to go down to the very low resolution of what chip is what in what capacity, but you'll be able to get a sense of how many exist or how many you can risk opening your laptop for. 110 00:14:11,320 --> 00:14:27,300 If you open it and it's only like a BIOS chip and one more versus six others that you suspect might be holding firmware, then your risk assessment about opening it might change. 111 00:14:27,320 --> 00:14:29,940 One more option is look for schematics. 112 00:14:29,940 --> 00:14:52,240 Now, it's a bit of a weird adventure and you'll find yourself entering the world of repair shops and schematics websites in Vietnam, but you'd be able to find a lot of PDFs that describe how devices interconnect including non-volatile and firmware storage devices. 113 00:14:52,280 --> 00:15:07,300 You might be finding a lot of EEPROMs that are on the board and the schematics will tell you exactly what address you need to communicate with to read or write from, which SMBus line has what controller allows you. 114 00:15:07,300 --> 00:15:13,600 It will basically allow you to understand which device does what and how. 115 00:15:13,620 --> 00:15:29,840 I wouldn't put too much effort into this attack surface scoping method because schematics tend to be confidential and secret and if you happen to find one of a more recent platform, it's going to be really rare. 116 00:15:30,000 --> 00:15:37,760 But if you want to practice on an old one, buy a laptop from eBay and see if you can find its schematics. 117 00:15:37,760 --> 00:15:38,940 Go ahead, go for it. 118 00:15:38,940 --> 00:15:41,900 You could spend like 100, 200 bucks on this. 119 00:15:43,810 --> 00:15:51,150 My favorite part is looking for official documentation. 120 00:15:51,150 --> 00:16:00,690 And the biggest tip we could give you for looking for those is statement of volatilities or declarations of volatilities. 121 00:16:00,690 --> 00:16:16,930 The best way to do this is just google in quotes of volatility and just add the file type pdf and include the words flash or cmos or spy or whatever from keywords that you can find from other documents you will find in the process. 122 00:16:17,110 --> 00:16:26,410 These documents basically state what volatile and non-volatile components are in a platform. 123 00:16:26,410 --> 00:16:39,770 Now, not every computer has this type of document associated with it, but from finding these documents online, you can understand what is in most common platforms. 124 00:16:39,910 --> 00:16:49,970 Some of these documents contain hilarities like this one saying 128 bytes are protected by intel. 125 00:16:49,970 --> 00:16:53,410 The other 128 bytes are not right protected. 126 00:16:53,710 --> 00:16:55,850 So what the shit? 127 00:16:55,850 --> 00:17:05,470 Why would you put this in a document that tells me I have 256 bytes of non-volatile storage? 128 00:17:05,470 --> 00:17:06,550 Half of it's protected. 129 00:17:06,550 --> 00:17:07,830 The other half's not. 130 00:17:07,830 --> 00:17:08,990 Go have fun. 131 00:17:09,490 --> 00:17:12,650 Okay, we have a demo about that. 132 00:17:14,210 --> 00:17:23,690 Now, I wanted to put a picture of the pdf here, but I couldn't find a good enough resolution so I had to crop a snippet of the table. 133 00:17:24,450 --> 00:17:36,190 And the table that you see here is somewhat a representation of what you'll see in a statement of volatility document. 134 00:17:36,430 --> 00:17:44,810 You'll see a breaking down by type, size, if it's volatile, non-volatile, what's it used for, how to clear it. 135 00:17:44,810 --> 00:17:48,610 Sometimes it's not going to be documented on how to clear it or not. 136 00:17:48,610 --> 00:17:49,670 Sometimes it will be. 137 00:17:49,670 --> 00:17:55,050 There's sometimes in some platforms jumpers you need to remove and and put back. 138 00:17:55,450 --> 00:18:04,530 But the key point that I want to tell you here is even though you see documents saying is this user modifiable? 139 00:18:04,530 --> 00:18:05,730 Yes and no. 140 00:18:05,730 --> 00:18:13,630 You never know if it means is it user space modifiable or is it modifiable from a user at all. 141 00:18:13,630 --> 00:18:23,390 And whatever you do, as a rule to live by, always challenge the basic assumptions that you encounter in official documentation. 142 00:18:23,550 --> 00:18:25,950 Especially some that you can prove easily wrong. 143 00:18:25,950 --> 00:18:35,890 I can tell you that even though some of these are not saying it's not user modifiable, you will see in a few minutes a demo saying that it is. 144 00:18:37,150 --> 00:18:47,950 Yeah, to follow up on that a little, user modifiable in this case means that it's intended to be presented to the user to be demodifiable like the BIOS password. 145 00:18:47,950 --> 00:18:51,150 The user is intended to be able to modify this. 146 00:18:51,390 --> 00:18:58,890 But system software or other software running on this on the device could be modifying these components. 147 00:18:58,890 --> 00:19:02,870 It just is not making that directly accessible to the customer. 148 00:19:02,870 --> 00:19:05,510 It doesn't mean that it's not modifiable at all. 149 00:19:05,530 --> 00:19:17,070 Now that we showed you a way or multiple ways to find information and explore it by yourself, we can go ahead and start diving a little bit deeper into some individual components that we talked about before. 150 00:19:17,090 --> 00:19:20,590 We'll go through them one at a time and we'll describe them. 151 00:19:20,590 --> 00:19:27,050 And then we'll later proceed into explaining what the pros and cons are from an attacker's perspective. 152 00:19:27,110 --> 00:19:29,410 And hopefully we can have fun while doing it. 153 00:19:32,140 --> 00:19:37,300 First things first, remember that 128 byte that we saw before? 154 00:19:38,200 --> 00:19:45,120 If we looked at the CMOS example in the previous slide, it said it's not user modifiable. 155 00:19:45,120 --> 00:19:53,340 And I know Jesse explained that it's what the user can modify sometimes by using a GUI like the BIOS password. 156 00:19:53,340 --> 00:20:01,940 But I wanted to emphasize that whatever the document says doesn't literally mean what you think it means. 157 00:20:01,940 --> 00:20:03,460 You need to go double check. 158 00:20:05,240 --> 00:20:08,380 So basically, back to the CMOS topic. 159 00:20:08,640 --> 00:20:15,640 If you are young and you have no idea what CMOS stands for, I am jealous. 160 00:20:15,640 --> 00:20:23,580 If you are somewhat old and you had to remove a battery from your computer motherboard, my heart's with you. 161 00:20:23,680 --> 00:20:33,720 It's really a relic that's used to have settings set for BIOS bring up, for the system bring up. 162 00:20:34,180 --> 00:20:47,980 It's a tiny bit of non-volatile RAM that is only non-volatile as long as their current and that current is supplied by the little lithium battery on the motherboard. 163 00:20:48,240 --> 00:20:53,660 The main thing I've seen this used is the real-time clock. 164 00:20:54,060 --> 00:21:03,140 So you know how you have a power surge and the microwave clock goes out, but your computer has the same clock afterwards? 165 00:21:03,140 --> 00:21:07,180 Probably because it keeps that real-time clock timer going internally. 166 00:21:07,940 --> 00:21:12,700 In modern platforms, the CMOS is located inside the chipset. 167 00:21:12,700 --> 00:21:14,620 So you really can't see it. 168 00:21:14,820 --> 00:21:17,360 It's it's itty-bitty. 169 00:21:17,620 --> 00:21:20,080 Not like other chips that we're going to talk about later. 170 00:21:22,040 --> 00:21:27,660 The pros of CMOS is that it has a few unused bytes. 171 00:21:27,680 --> 00:21:31,560 You can access it through IO ports. 172 00:21:31,560 --> 00:21:35,020 You can do in-and-out instructions to get to it. 173 00:21:35,020 --> 00:21:38,100 It exists almost everywhere. 174 00:21:39,000 --> 00:21:42,840 The cons are that it's super tiny. 175 00:21:42,840 --> 00:21:50,160 It only contains 256 bytes separated to two regions, lower CMOS and upper CMOS. 176 00:21:50,160 --> 00:22:01,160 If you mess up the wrong bytes, you might cause yourself some trouble and you might need to reset the CMOS or fuck up the platform. 177 00:22:01,160 --> 00:22:09,580 We don't know exactly what each modification of each bit might might do, but it's well documented. 178 00:22:09,580 --> 00:22:14,440 And then if you want to go to explore what you can do with it, it's all over Wikipedia. 179 00:22:15,640 --> 00:22:29,480 One other thing that we we think might happen is that if there are certain PCR measurements done by TPM, modifying CMOS might trigger an alert. 180 00:22:29,480 --> 00:22:37,880 For example, BitLocker has PCRs it's monitoring and if those PCR change, then it goes into BitLocker recovery mode. 181 00:22:38,820 --> 00:22:45,960 In short, we're pretty sure you can you can have fun with this, but don't mess up bytes that are not zero. 182 00:22:48,820 --> 00:22:51,880 So you don't think we're full of shit? 183 00:22:52,880 --> 00:22:56,280 Here's a short demo of how to abuse CMOS. 184 00:22:56,320 --> 00:23:01,620 In the demo you're about to see, we have the steps written on the right. 185 00:23:01,680 --> 00:23:15,080 Basically, we read the CMOS, we write a random payload to the lower part of CMOS, you read it, so we show you that there is a change there. 186 00:23:15,080 --> 00:23:18,980 We restore it back and then we read it again to show that we changed it back. 187 00:23:19,240 --> 00:23:21,680 Let's go and run the demo. 188 00:24:01,220 --> 00:24:10,540 We're going to have the code for this demo up on GitHub after the talk is published and keep an eye on that GitHub because we're going to keep adding more and more code to it as we go on. 189 00:24:12,220 --> 00:24:14,200 So let's take a look at SpyFlash. 190 00:24:14,960 --> 00:24:28,240 In order to know where to start executing code from in the first place, that code is stored in the SpyFlash and when the system turns on it starts executing instructions from there. 191 00:24:28,760 --> 00:24:40,340 Traditionally that was known as BIOS, but these days almost all systems have transitioned over to using a UEFI firmware instead and this firmware is stored in the SpyFlash. 192 00:24:40,620 --> 00:24:44,220 There's a few different regions within the SpyFlash. 193 00:24:44,500 --> 00:24:50,400 If you have an Intel platform, you'll have a region for the manageability engine or the ME. 194 00:24:51,060 --> 00:24:53,360 It's also known as the CSME. 195 00:24:53,360 --> 00:24:57,820 AMD platforms will have a PSP region for the platform security controller. 196 00:24:57,960 --> 00:25:07,920 There's also a flash descriptor which contains essentially a map for how the contents of the SpyFlash are organized as well as access permissions for these regions. 197 00:25:10,220 --> 00:25:20,040 So taking a look at the the contents of the SpyFlash itself, there's a couple constraints that determine the location of a couple of the regions in there. 198 00:25:20,500 --> 00:25:34,560 First, when the system boots up, the top of that SpyFlash is mapped to the top of the four gigabyte address space in order for the x86 reset vector to start executing code from there. 199 00:25:34,600 --> 00:25:40,500 Because of this, the top of the BIOS region needs to correspond to the top of the SpyFlash. 200 00:25:40,500 --> 00:25:42,300 It can vary in size. 201 00:25:42,300 --> 00:25:50,180 So you can have a eight meg BIOS region or a four meg BIOS region. 202 00:25:50,180 --> 00:25:58,620 The size can vary, but the top of that region needs to correspond to the top of the spy chip itself. 203 00:25:59,940 --> 00:26:12,560 Additionally, the flash descriptor region, which is essentially the map and permissions and what is actually stored throughout the spy chip, that starts at the beginning of of the SpyFlash. 204 00:26:12,820 --> 00:26:23,840 It contains some platform configuration for the device as well as the map determining where these regions are stored within the SpyFlash itself. 205 00:26:24,200 --> 00:26:28,060 There can be some additional regions like the ME region. 206 00:26:28,220 --> 00:26:33,980 Some platforms will have a GigE region or an embedded controller region. 207 00:26:33,980 --> 00:26:41,000 There can be a platform data region which is for OEM specific additional components. 208 00:26:41,160 --> 00:26:48,120 The region mapping in the flash descriptor also doesn't need to include all of the contents of the spy region. 209 00:26:48,120 --> 00:26:56,180 So there can be some padding regions or padding areas that aren't actually included in the map as well. 210 00:26:57,660 --> 00:27:14,600 To take a look at the flash descriptor itself, starting at the very beginning of the spy contents, there's a signature at 10 hex, offset 10 hex, that is used to determine if there is a flash descriptor in this area. 211 00:27:15,320 --> 00:27:32,660 And then there's a mapping, there's a variety of different components and access control lists to determine if the CPU has access to read and write of a particular spy region, or the ME has access to read and write to a particular spy region, or the NIC, 212 00:27:32,660 --> 00:27:36,820 the GigE controller has access to read and write directly to that spy region. 213 00:27:36,820 --> 00:27:41,140 So those access controls are stored in the flash descriptor. 214 00:27:43,500 --> 00:27:49,620 So there are a lot of cases where the CPU can't directly read and write to the ME region. 215 00:27:50,120 --> 00:27:57,300 And most systems these days will have that BIOS region protected via hardware mechanisms in the chipset. 216 00:27:57,520 --> 00:28:08,380 Occasionally we run into systems where that is still not protected properly and you can just directly write to the spy and BIOS region from code running on the CPU. 217 00:28:08,920 --> 00:28:17,700 But even in the case that that BIOS region is properly protected, there can be bugs in the BIOS update mechanism itself. 218 00:28:17,980 --> 00:28:21,100 Sometimes that doesn't provide signature verification. 219 00:28:21,100 --> 00:28:33,540 Sometimes it will do signature verification for part of the region but still copy data into that spy flash for you. 220 00:28:33,540 --> 00:28:41,500 However, the gigabit region itself is generally unprotected and you have full read and write access to that from the CPU. 221 00:28:42,000 --> 00:29:01,600 We also sometimes run into cases where the flash descriptor itself has incorrect permissions and that can be rewritten via software to modify the existing region definitions or even define new regions in the spy flash layout and change the permissions for those regions. 222 00:29:01,600 --> 00:29:07,200 So if you have that issue, there's a lot of ways that you can take advantage of that. 223 00:29:07,520 --> 00:29:16,500 Another interesting storage location is the SPD or Serial Presence Detect chip in DRAM memory modules. 224 00:29:16,700 --> 00:29:26,120 Although some recent devices like laptops and tablets only have soldered down memory which is not replaceable, the vast majority of systems include replaceable memory. 225 00:29:26,120 --> 00:29:29,060 There are a lot of different types of memory. 226 00:29:29,280 --> 00:29:33,040 There's a DRAM2, DRAM3, DRAM4. 227 00:29:33,520 --> 00:29:42,520 Each of these different memory modules have different parameters or configuration that needs to be done in order to be used. 228 00:29:42,700 --> 00:29:57,060 And the SPD has been created as a standard way for a replaceable memory module to provide this information to the system so that the system knows how to talk to the memory module and use it. 229 00:29:58,240 --> 00:30:05,140 So the SPD is essentially a tiny EEPROM on those DRAM memory modules. 230 00:30:05,140 --> 00:30:15,400 It includes both the memory module type, like if it's DDR2, DDR3, DDR4, as well as the size of the module itself. 231 00:30:15,760 --> 00:30:36,180 There's information about the layout of the memory module as well, including the number of banks, if it includes features like ECC, as well as timing and voltage requirements that are necessary for the system to understand, to know how to talk to and use this memory module. 232 00:30:36,720 --> 00:30:46,160 When the system is booting up, it reads this SPD EEPROM in order to determine this information so that it knows how to configure the memory controller. 233 00:30:46,860 --> 00:30:58,760 Modifying certain parts of this configuration data can cause the system to not boot up anymore and the system just will be bricked until this module is physically removed from the system. 234 00:30:58,760 --> 00:31:06,720 In some systems, this SPD, the lower half of the SPD, which contains this critical data, is locked. 235 00:31:06,960 --> 00:31:15,240 Sometimes that's not protected though, and modifying that region can can brick the system or cause other unexpected behavior. 236 00:31:16,100 --> 00:31:28,640 But generally, the upper half of that SPD is writable and we can use that to store small amounts of data for payloads, such as encryption keys or other interesting data. 237 00:31:29,500 --> 00:31:34,240 So for accessing the SPD, we need to have it unlocked. 238 00:31:34,240 --> 00:31:42,120 It's essentially an SPD EEPROM that is connected over an SMBus interface. 239 00:31:42,120 --> 00:31:51,360 So there's an SMBus controller in the chipset that is used to talk to this SMBus device in the memory module. 240 00:31:51,360 --> 00:31:55,840 That includes a protection mechanism to prevent writes to it. 241 00:31:55,840 --> 00:32:05,600 And if that bit is set, we can't write to the SPD itself, but we've run into systems where that bit is not set properly. 242 00:32:05,720 --> 00:32:16,560 It is a very small amount of data that you can store things in, but there are some usage scenarios where that actually makes sense and you don't need a lot of data. 243 00:32:16,660 --> 00:32:23,380 And there are also attack scenarios where maybe bricking a device makes sense in the attack class. 244 00:32:23,380 --> 00:32:34,220 And we want to make sure that people understand that that is also a concern, that if you can write to this SPD, there are bricking scenarios that can come into play here. 245 00:32:34,600 --> 00:32:37,240 Next, we have USB controllers. 246 00:32:37,240 --> 00:32:55,070 Now, these USB controllers that could be found on your motherboard or part of an external PCI card that is plugged into your motherboard or part of an external USB-C device that is connected to your computer or M.2 modules inside your laptop. 247 00:32:55,280 --> 00:33:08,940 Some of these have updatable firmware and it's depressingly common how many of these have unsigned firmware updates. 248 00:33:09,220 --> 00:33:14,680 And you as an attacker can store whatever payload you want on them. 249 00:33:14,680 --> 00:33:23,640 For example, we can have not just USB controllers that exist as USB bridges or on your motherboard. 250 00:33:23,640 --> 00:33:25,680 It doesn't have to be a USB controller. 251 00:33:25,680 --> 00:33:31,900 It will be actually a PCI device that exposes a USB 3.1 interface. 252 00:33:31,900 --> 00:33:43,400 If you have USB-C ports on your desktop, most likely you'll have one of these PCI to USB components. 253 00:33:43,400 --> 00:33:47,000 Not necessarily all of them are PCI to USB. 254 00:33:47,000 --> 00:33:50,940 Some of them are USB to SATA. 255 00:33:51,260 --> 00:34:04,620 For example, there is an external hard drive enclosure that has this exact, well I won't say issue, but exact design which has a controller that talks over USB 3.1 on one end. 256 00:34:04,620 --> 00:34:12,960 On the other end, it talks to a SATA hard disk drive and it has updatable firmware and you can update that firmware from from the computer. 257 00:34:13,260 --> 00:34:28,040 The next demo we have is one of these USB controllers embedded in your motherboard that we update the firmware to include a malicious payload, in this case a Metasploit shellcode. 258 00:34:28,040 --> 00:34:39,860 So what you're going to see is a program that we have adapted to read the firmware from this USB controller, load it into memory and execute it. 259 00:34:39,940 --> 00:34:52,200 And I know it's going to look dumb, but we're basically we're clicking on a file that's running as admin and then we get a connect back in Kali. 260 00:34:52,240 --> 00:34:54,340 It's not dumb, I promise you. 261 00:34:54,340 --> 00:34:55,940 I'll show you the code right after. 262 00:35:21,690 --> 00:35:37,510 Okay, breaking down the video you just saw, on the right side that the we have a binary visualization of the firmware image we're writing to the device to save our payload. 263 00:35:37,510 --> 00:35:43,390 What's circled in red is the actual Metasploit code that we have in the firmware. 264 00:35:43,390 --> 00:35:46,810 What's colored black is empty space. 265 00:35:47,430 --> 00:35:49,570 Everything else is actual code. 266 00:35:49,570 --> 00:35:54,450 So you'd see there is about a third of it, almost half of the image. 267 00:35:54,450 --> 00:35:56,490 It's 128 kilobytes. 268 00:35:56,490 --> 00:36:01,630 Out of that, so much space is is empty for us to use as attackers. 269 00:36:01,630 --> 00:36:08,250 The fact that I put a few hundred bytes as payload for a demo looks tiny. 270 00:36:09,930 --> 00:36:24,010 If we look at the the code that we have loading this exploit, the first part gets the hidden bytes looking for a magic header, which is leetleet, because obviously. 271 00:36:24,270 --> 00:36:30,010 And once we find the leetleet, we fill up a buffer with the bytes from the firmware. 272 00:36:30,250 --> 00:36:41,090 After we have the payload, we're loading their payload from UEFI. 273 00:36:41,090 --> 00:36:47,030 But in this case, we use interoperability and marshalling, so there's no p invokes. 274 00:36:47,150 --> 00:36:49,690 Topher helped us speak this up. 275 00:36:49,950 --> 00:36:53,710 And we load them in memory and we execute them. 276 00:36:53,730 --> 00:36:54,450 Simple as that. 277 00:36:54,450 --> 00:36:56,590 All this code is going to be available on GitHub. 278 00:36:57,830 --> 00:37:04,230 Generally speaking, as an attacker, you'd break this attack into two distinct steps. 279 00:37:04,230 --> 00:37:06,750 One is hiding the payload. 280 00:37:06,890 --> 00:37:09,750 The second is retrieving and running it. 281 00:37:09,750 --> 00:37:26,230 When you hide it, you have to get the firmware image, incorporate your payload in the firmware image in bytes that will not disrupt normal behavior or functionality, and upload that new image to your target device or firmware. 282 00:37:26,510 --> 00:37:38,170 When you retrieve it, you have to read the firmware like any other mechanism or use the built-in mechanisms or known tools, extract your hidden bytes, and then do the malicious. 283 00:37:38,590 --> 00:37:43,090 Let's review a little bit of the attack surface from an internal asset perspective. 284 00:37:43,090 --> 00:37:49,130 You have USB controllers that are embedded in your devices that have their own firmware. 285 00:37:49,290 --> 00:37:54,770 You have PCI bridges that act as PCI to USB devices. 286 00:37:54,770 --> 00:37:58,990 You have trackpads and touch points and touchpads. 287 00:37:58,990 --> 00:38:01,610 If you have a ThinkPad Lenovo, it's a point. 288 00:38:01,610 --> 00:38:02,610 I don't know what it's called. 289 00:38:02,610 --> 00:38:04,250 You have one of those trackpads. 290 00:38:04,350 --> 00:38:08,090 It can have sometimes its own internal flash. 291 00:38:08,570 --> 00:38:28,070 The monitors you're using, if you ever plugged in a USB cable from your laptop to your monitor, just so you can use the little USB hub on the side of the monitor, if you're one of those blessed few that do that, then you should know that that monitor has a USB hub in it, 292 00:38:28,070 --> 00:38:29,290 and it has firmware. 293 00:38:29,290 --> 00:38:33,390 Most likely you can modify it from your computer. 294 00:38:33,470 --> 00:38:37,150 Webcams tend to have firmware related to them. 295 00:38:37,150 --> 00:39:04,290 Fingerprint readers, accelerometers, integrated sensor hubs, power delivery systems, power management ICs, everything you can think of that's inside your computer not necessarily has a separate component to hold firmware, but it most likely has some internal firmware either on the integrated controller or off it. 296 00:39:04,390 --> 00:39:06,090 You like to add something, Jesse? 297 00:39:06,090 --> 00:39:11,670 In addition to these controllers, there's also all of the endpoint devices themselves. 298 00:39:11,670 --> 00:39:27,530 There can be a wireless network card or a cellular modem, and these are often PCI or USB devices themselves that also have updatable firmware. 299 00:39:27,530 --> 00:39:40,070 In addition to the controllers, there's generally USB devices or PCI devices in the system itself, and then all of the other fun stuff that Mickey just talked about. 300 00:39:43,300 --> 00:39:54,540 Speaking of wireless devices and external assets, there is also all the stuff that you have that you can possibly plug into your computer. 301 00:39:54,540 --> 00:40:01,620 Think of all the ports you have on your machine, if it's your laptop or if it's your desktop or whatever device you're looking at. 302 00:40:01,620 --> 00:40:10,640 Whatever ports you can use, Thunderbolt 3, USB-C 3.1, whatever USB format it is. 303 00:40:11,260 --> 00:40:13,460 Proprietary connectors for docking stations. 304 00:40:13,460 --> 00:40:17,000 Docking stations have a lot of parts in them that have their own firmware. 305 00:40:17,500 --> 00:40:23,440 So, ask yourself, how often do you check the firmware on the dock that you plug your laptop to at work? 306 00:40:23,760 --> 00:40:26,420 And then, obviously, the over-the-air updates. 307 00:40:26,580 --> 00:40:39,080 In addition to the Bluetooth controller in the motherboard itself, you might have Bluetooth devices that are commonly paired with your system, like keyboards and mice and wireless headsets. 308 00:40:39,400 --> 00:40:42,380 Sometimes those have firmware as well. 309 00:40:42,380 --> 00:40:55,680 That's probably less likely to be an attack scenario because they're less universal than some of these other things that we're talking about, but it is something to be aware of and keep in mind. 310 00:40:55,860 --> 00:41:02,740 Another example that we think is something that we should all pay attention to is the Gigabit Ethernet. 311 00:41:03,360 --> 00:41:10,840 If you have a LAN port on your laptop, congratulations, you have a code cave. 312 00:41:11,140 --> 00:41:25,620 In most, I think, the almost every instance that I've encountered of a Gigabit region in SpyFlash on a system, it was read-write capable. 313 00:41:25,620 --> 00:41:31,460 I have yet to encounter one instance where it's, if it exists, it is read-only. 314 00:41:31,460 --> 00:41:37,180 This region in in SpyFlash usually contains the configuration data for the device. 315 00:41:37,800 --> 00:41:49,780 Stuff like MAC address or any other setup configuration that was initially set up by the vendor manufacturing the computer or selling it. 316 00:41:49,980 --> 00:41:51,680 Usually, there are two images. 317 00:41:51,680 --> 00:42:03,460 One is the one being used, the other one is a backup, and there are so many unused bytes in that region that we'll show you in a second, but it's really open for abuse. 318 00:42:04,680 --> 00:42:10,480 Now, some systems are mandated to have such things like servers, for example. 319 00:42:10,480 --> 00:42:24,240 There's no server without a network adapter connected to it, and if it's an Intel platform, you will find a GigE region in Spy that you can read and write from. 320 00:42:24,240 --> 00:42:39,880 If you have a desktop computer and you bought a Gigabit Ethernet card that you plug in, sometimes these devices will expose their internal non-volatile memory to the user over memory access. 321 00:42:39,880 --> 00:42:53,040 So, you would query the PCI device, get the PCI config space, find the base address register where the flash is mapped to, and then you can read and write directly to the flash over memory. 322 00:42:53,360 --> 00:42:57,440 There's also other discrete PCI devices, but we'll not talk about them right now. 323 00:42:57,620 --> 00:43:02,220 Let's look at an example of the GigE region in a HEX editor. 324 00:43:04,740 --> 00:43:19,660 First region would have the main data, and then we scroll past all the unused bytes and empty bytes, and then we get to the backup region that has the backup data, and then we keep looking and there's a whole bunch of other empty bytes. 325 00:43:19,860 --> 00:43:33,740 If we take a closer look at this example, which we have eight kilobytes of data, 72 and a half percent of it is not used, which is quite a lot of space. 326 00:43:34,060 --> 00:43:49,580 And if I were an attacker and I had a known point to hide payload or data on every common platform on the market, this would be a very, very good piece of information to have. 327 00:43:50,060 --> 00:43:51,760 But how do we access it? 328 00:43:51,760 --> 00:43:53,260 I mean, it's great. 329 00:43:53,260 --> 00:43:56,940 It's in SPI Flash, but how do we read and write from it? 330 00:43:57,000 --> 00:44:01,760 The easiest way to do this on Intel platforms is using the Flash programming tool. 331 00:44:03,280 --> 00:44:09,080 It's an internal tool that it's not supposed to be public, but you can find it on the internet. 332 00:44:09,080 --> 00:44:15,500 I'm not going to say where, but you can use it to update your BIOS and update your ME. 333 00:44:15,500 --> 00:44:21,360 Some vendors might have it in their update packages, some don't. 334 00:44:21,360 --> 00:44:22,900 There are other utilities. 335 00:44:23,240 --> 00:44:50,180 If you have a card made by a different brand manufacturer and you look for firmware updates, for example, if you have like a Broadcom card or an Intel card or any device whatsoever, any card that you find the firmware updates for, always, always look for the same updates for the same hardware on a different OEM. 336 00:44:50,620 --> 00:45:03,080 If Lenovo has an update for a Broadcom-based card and Dell has an update for the same Broadcom-based card, you would see two different software implementations. 337 00:45:03,080 --> 00:45:10,320 One of them might include a pre-existing tool that you can abuse or use to your advantage. 338 00:45:11,440 --> 00:45:15,620 Now, the best part of this, in my eyes, it's the Confused Deputy. 339 00:45:15,620 --> 00:45:30,240 Now, last year, we gave a talk about how drivers in Windows are screwed, basically, and you can abuse a lot of these firmware updating drivers to gain access to lower levels of the platform. 340 00:45:30,380 --> 00:45:36,940 And a lot, a big number of those would have access to IO ports. 341 00:45:37,180 --> 00:45:57,040 And given access to IO ports, arbitrary IO might not seem like a big deal at first, but once you think that, once you remember that arbitrary IO can give you legacy PCI access, and with legacy PCI access, you can do a lot of things like hardware sequencing into the SPI controller on Intel platforms, 342 00:45:57,040 --> 00:46:13,400 and that some of these drivers, if they are loaded on the system, some of these don't require you to be an admin to send them IOctals, this becomes more and more realistic as an attacker, from an attacker's perspective. 343 00:46:13,540 --> 00:46:26,340 Let's see a demo of how we can read and write to the GIGI region on an actual computer with a custom payload, or just a demo payload that we have. 344 00:46:28,140 --> 00:46:44,650 Here we see PowerShell prompt where we dump the GIGI region, and then we clear the screen, we show that the end of it has nothing but Fs. 345 00:46:47,340 --> 00:46:53,340 Now we're going to flash a malicious version, well, so-called malicious, just for demo purposes. 346 00:46:58,520 --> 00:47:08,340 At the end of it, we put the ICAR test string and just explanation of this might be malicious code or shellcode. 347 00:47:09,240 --> 00:47:11,160 Now we flash it. 348 00:47:17,480 --> 00:47:21,720 Now it's flashed, that data is on the computer now. 349 00:47:26,780 --> 00:47:29,040 We dump the new content, 350 00:47:32,230 --> 00:47:41,150 we're checking what's in the new content, to be sure we're not checking the same one we wrote, and we find our malicious payload there. 351 00:47:42,530 --> 00:48:00,870 So just to recap, we dumped the GIGI region from Spy using existing tools, modified it, added our own malicious payload, flashed it back onto Spy, and read it back again to make sure that we have the changes persist. 352 00:48:00,870 --> 00:48:05,090 A few tips and tricks of how you can hide your payload in firmware. 353 00:48:05,350 --> 00:48:11,990 If you have empty regions like we showed you, you can just add your payload there, you won't touch the firmware. 354 00:48:11,990 --> 00:48:21,170 Usually what happens when firmware is signed or validated, it will only verify the block of code, it won't verify the whole image. 355 00:48:21,170 --> 00:48:46,750 So if you have, let's say you have 128 kilobytes of SpyFlash for your controller, and the firmware image is 60 kilobytes, the image would have a header defining where it starts, where it ends, what parts it includes, what segments, and it would also include all the verification fields like signature or cryptographic signature or CRCs or whatever is included. 356 00:48:46,750 --> 00:48:51,610 But past that, there is empty space that is not included or not defined. 357 00:48:51,610 --> 00:48:56,510 But when you read and write the firmware from the controller, it would read and write the whole chip. 358 00:48:57,430 --> 00:49:07,480 Another way is if you have unverified firmware, you can put your payload inside segments of the that are empty. 359 00:49:07,580 --> 00:49:18,240 So if someone built a firmware with a lot of padding in it, or there's different segments that they kept a lot of padding in there, you can abuse that if it's big enough. 360 00:49:18,240 --> 00:49:27,980 If it's not big enough, and you need a lot of small segments, you can easily break it down to multiple parts with magic bytes. 361 00:49:27,980 --> 00:49:42,920 Like we've seen in the demo before, you can load your shellcode with a magic byte and magic sequence of bytes and then a length to read from, and then you can all concatenate it later into your own shellcode and execute. 362 00:49:43,060 --> 00:49:56,780 For this talk, we're going to release some code on GitHub, and it will give you the capability of doing a lot of things low-level again, but with specifically reading and writing firmware. 363 00:49:56,780 --> 00:50:01,760 The practicality is that a lot of people are probably saying, well, what's the point? 364 00:50:01,760 --> 00:50:03,020 You got to be admin. 365 00:50:03,040 --> 00:50:05,920 This is all bullshit, but not necessarily. 366 00:50:05,920 --> 00:50:12,320 Like we said before, some drivers, if they exist on the system, they can be accessed from user space. 367 00:50:12,600 --> 00:50:16,920 So all you have to do is just see if the device exists and send it iOctals. 368 00:50:16,980 --> 00:50:25,300 Another point to mention is this scenario is relevant if you already have execution on the target. 369 00:50:25,320 --> 00:50:31,300 There's no point of gaining persistence or hiding your payload if you're just getting into the system. 370 00:50:31,300 --> 00:50:45,580 A big focus on the confused deputy angle is where we have a lot of signed drivers and signed tools and existing tools that allow you to do a bunch of actions that you normally wouldn't be able to. 371 00:50:45,580 --> 00:50:47,440 There is a lot to explore there. 372 00:50:47,440 --> 00:50:57,080 There are a lot of, for example, Dell has .NET tools that are used to communicate with the monitor and update firmware on it. 373 00:50:57,080 --> 00:51:17,860 It's not necessarily admin privileged access, but you can literally go and see how your code can interact with some other vendor code to communicate over USB to a device and read the EEPROM content on it or write to it. 374 00:51:17,860 --> 00:51:33,440 We are going to release some code on GitHub to use some existing code that we found that might help everyone to play with this even further, specifically in C-sharp because C-sharp is the new Java. 375 00:51:33,440 --> 00:51:36,680 I guess it's easier to understand. 376 00:51:36,680 --> 00:51:38,800 It's managed code. 377 00:51:38,800 --> 00:51:40,040 Why the hell not? 378 00:51:40,040 --> 00:51:48,580 In our example, we're releasing code that uses the PMX driver, which is included in a lot of Intel utilities. 379 00:51:48,580 --> 00:51:51,920 It is dating back to 1998. 380 00:51:51,920 --> 00:51:54,400 It can read and write physical memory. 381 00:51:54,400 --> 00:52:02,980 It can read and write debug registers, control registers, model-specific registers, IOs, and so much more. 382 00:52:03,180 --> 00:52:04,220 You can load it. 383 00:52:04,220 --> 00:52:07,020 If you're admin, you can load it in Windows and play with it. 384 00:52:07,020 --> 00:52:15,660 Imagine read, write everything, but not read, write everything that was blocked by Windows. 385 00:52:16,600 --> 00:52:19,760 It's confusing, I know, but its name was read, write everything. 386 00:52:19,760 --> 00:52:24,940 We will also release code that's using AceMedia tools. 387 00:52:25,240 --> 00:52:41,420 There is a tool made by, and I hope I'm not butchering your name, Stefano Moioli, and it's a tool released on GitHub that reads the firmware off AceMedia chipsets, very common chipsets that are found in a lot of places. 388 00:52:41,540 --> 00:52:53,060 And that code can be used to adapt calls to the driver that you can load, or can be adapted to write the firmware to the device. 389 00:52:53,060 --> 00:53:02,800 In the demo we've shown earlier, we've used Stefano's code to read the payload from the firmware and execute it in our own custom program. 390 00:53:02,800 --> 00:53:09,160 We also used update tools from AceMedia to write the malicious firmware into the device. 391 00:53:09,160 --> 00:53:11,840 Funny story about AceMedia controllers. 392 00:53:11,840 --> 00:53:15,440 I bought, for the talk, I bought a couple of devices off Amazon. 393 00:53:15,520 --> 00:53:23,500 Both of them are AceMedia controllers, and I have an Intel NUC, it's called Hades Canyon, it's a NUC8. 394 00:53:23,500 --> 00:53:37,940 Anyway, I decided to plug in the Thunderbolt controller to PCI adapter that I have, plug in the PCI cards, and connect it to the NUC and work on the demo. 395 00:53:38,140 --> 00:53:48,780 And I'm like working, having fun, writing malicious firmware images, reading them back, writing, flashing it, flashing new ones, flashing backups. 396 00:53:48,980 --> 00:53:51,550 And then I realized I have two controllers. 397 00:53:52,940 --> 00:54:02,600 Yours truly has not noticed that I have a built-in onboard AceMedia controller in the NUC, I've been flashing that the whole time. 398 00:54:03,760 --> 00:54:07,160 Talk about a scary moment right there. 399 00:54:07,620 --> 00:54:09,440 So yeah, it's a funny story. 400 00:54:10,380 --> 00:54:19,560 I don't want to be all doom and gloom, but I have to be all doom and gloom here, because nobody is looking in the firmware. 401 00:54:20,140 --> 00:54:25,560 There is so much space in non-volatile memory. 402 00:54:25,560 --> 00:54:33,340 I mean, if you look at it in bytes, it's not a lot of bytes, but it's a lot of bytes that are not supervised. 403 00:54:38,070 --> 00:54:40,350 Is EDR catching up? 404 00:54:40,350 --> 00:54:42,650 Well, yes and no. 405 00:54:43,330 --> 00:54:55,650 Microsoft Defender has released a couple months ago, a press release and notification that they are now looking into the UEFI file system, which is awesome. 406 00:54:56,390 --> 00:55:00,270 But why just UEFI? 407 00:55:00,270 --> 00:55:03,470 There's so many other places on the platform that you can look into. 408 00:55:03,990 --> 00:55:05,370 I mean, great. 409 00:55:05,490 --> 00:55:14,050 We have EDR is coming, hide your shit talk last year, where Topher and Mike showed that they can hide malicious payloads in UEFI variables. 410 00:55:14,250 --> 00:55:23,310 And then less than a year later, all of a sudden EDR is looking in UEFI variables, but that's just the tip of the iceberg, right? 411 00:55:23,330 --> 00:55:25,750 We have solutions coming out. 412 00:55:25,750 --> 00:55:46,870 Like we know Dell has a BIOS scanner, CrowdStrike scans firmware, HP has their own hardware, the SureStart solution that is literally a hardware root of trust on the platform that scans BIOS, verifies the BIOS image, verifies a lot of parts in it, including all the Intel parts as well, 413 00:55:46,870 --> 00:55:50,510 BootGuard, BIOSGuard, all kinds of solutions. 414 00:55:50,690 --> 00:56:02,470 We have open source firmware solutions that allow you to update to legitimate images to make sure that you're up to date and check by Richard Hughes. 415 00:56:02,470 --> 00:56:12,830 But beyond the BIOS, beyond the firmware on the SPI, big parts of the firmware on the SPI, no one's doing anything. 416 00:56:12,830 --> 00:56:27,390 There is external devices firmware and internal devices firmware, and a lot of stuff that you can see in the volatility reports that do not fall into the SPI BIOS regions that are not verified. 417 00:56:28,270 --> 00:56:35,370 And also like this, like Microsoft's, it is Defender ATP, so it's not rolled out everywhere. 418 00:56:35,370 --> 00:56:41,130 It's only that the premium version so that you need to pay more for. 419 00:56:41,130 --> 00:56:43,390 What can we do about it? 420 00:56:43,490 --> 00:56:57,270 We can use OEM tools or vendor tools to read the storage, to access whatever non-volatile components we have on the platform. 421 00:56:57,470 --> 00:57:25,250 If they exist, some tools exist, we can hack some sort of interface to vendor tools or we can adapt existing tools like open source code from Stefano and the SASM tool on GitHub or Chipset that allows us to access the CMOS, GIGI, SPI, SPD, a lot of things that we can do there. 422 00:57:25,430 --> 00:57:44,290 And maybe we can add open source tools that check for everyone's safety and help notify vendors that not only do you have to verify the firmware image, but you also need to check all the unused space on firmware on your non-volatile device just to see that you're not being abused here. 423 00:57:45,370 --> 00:57:48,410 And with that, we've reached the end of our presentation. 424 00:57:48,610 --> 00:57:53,290 Thank you for bearing with us and watching the slides while we talk. 425 00:57:53,410 --> 00:58:06,450 If you have any further questions that you'd like to ask us, feel free to reach out on Twitter, Discord, Slack, whatever will be available to answer questions for this talk on the DEF CON Discord server. 426 00:58:06,590 --> 00:58:11,290 But feel free to ping us later on social media if you have any questions.