WEBVTT 00:01.620 --> 00:02.300 Hello? 00:02.300 --> 00:03.180 Is this thing on? 00:04.680 --> 00:06.200 Hi, everyone. 00:06.200 --> 00:08.540 Welcome to our talk, Bites in Disguise. 00:08.700 --> 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. 00:15.060 --> 00:16.460 You brave souls. 00:16.560 --> 00:21.500 If you're watching this on YouTube at some point later on, well, thank you, you lazy f**ks. 00:21.640 --> 00:23.140 My name is Mickey. 00:23.160 --> 00:24.240 And I'm Jesse. 00:24.420 --> 00:25.600 I'm on the left. 00:25.600 --> 00:29.600 Jesse's on the right, just so you'd know to associate our faces with our voices now. 00:30.120 --> 00:35.500 We're both principal security researchers at Eclipseum, and we deal with hardware and firmware on a daily basis. 00:35.500 --> 00:39.200 Now that we have all the formalities out of the way, we can start with the actual talk. 00:39.200 --> 00:43.140 We'd like to start with a little bit of structure. 00:43.180 --> 00:44.280 What are we going to talk about? 00:44.280 --> 00:45.760 The agenda and high level. 00:46.340 --> 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. 00:58.480 --> 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. 01:08.040 --> 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. 01:18.920 --> 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. 01:29.380 --> 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. 01:43.460 --> 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. 01:56.800 --> 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. 02:19.700 --> 02:22.320 But the main issue is persistence. 02:22.380 --> 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. 02:33.780 --> 02:35.480 You can't really hide that. 02:35.480 --> 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. 02:45.080 --> 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. 02:57.680 --> 02:59.360 And remember, don't touch disk. 02:59.360 --> 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. 03:11.060 --> 03:15.700 We usually describe this in the slide and say, look, past research done this and that. 03:15.700 --> 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. 03:21.420 --> 03:23.300 So here's Topher and Mike. 03:23.620 --> 03:26.180 Topher is the left in the picture and Mike is on the right. 03:26.180 --> 03:28.440 So I hope you enjoy and help us embarrass them. 03:29.760 --> 03:31.160 Hey, I'm Topher Timson. 03:31.240 --> 03:32.600 Hey, I'm Michael Lebowitz. 03:32.600 --> 03:37.380 Last year at DEF CON, Mike and I gave a talk entitled EDR is coming, hide your shit. 03:37.380 --> 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. 03:53.720 --> 03:57.860 And the blue team was discovering us and ruining our engagements. 03:57.860 --> 04:03.800 And, you know, when your lovingly crafted payload becomes some analyst sample, everyone's going to have a bad evening. 04:03.800 --> 04:12.600 So in looking at new areas in which we could hide our shit, we effectively wanted to get off of disk. 04:12.600 --> 04:20.180 The rationale for this was because having things on disk leaves it vulnerable to AV scanning it. 04:20.180 --> 04:25.780 It allows analysts to look at hashes of the binaries. 04:25.780 --> 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. 04:37.180 --> 04:42.200 In looking at ways to hide our shit, we looked into UEFI. 04:42.200 --> 04:45.680 So I used to do some UEFI security research. 04:45.680 --> 04:52.060 So I was already somewhat familiar with how UEFI worked as this firmware platform. 04:52.060 --> 04:57.440 And variables are something that were exposed after boot services. 04:57.440 --> 05:02.340 So they were available at runtime and actually booting the platform. 05:02.340 --> 05:09.620 Windows 10 re-added a UEFI API that allowed you to read and write UEFI firmware variables. 05:09.620 --> 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. 05:19.740 --> 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. 05:29.300 --> 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. 05:39.200 --> 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. 05:50.020 --> 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. 06:05.560 --> 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. 06:18.280 --> 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, 06:41.840 --> 06:43.380 you're in for a good time. 06:43.440 --> 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. 07:07.640 --> 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. 07:19.640 --> 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. 07:38.660 --> 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. 07:50.800 --> 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. 08:04.040 --> 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. 08:12.260 --> 08:16.240 But no good thing lasts forever, and eventually your breach is going to get detected. 08:16.240 --> 08:18.900 But we just want that to go a little bit longer. 08:19.520 --> 08:22.160 Thank you Topher and Mike for that amazing summary. 08:22.680 --> 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. 08:36.880 --> 08:45.440 Basically storing anything in non-conventional storage that the analysts are not looking at, hiding their blind spots. 08:45.600 --> 08:48.640 A little bit about UEFI variables. 08:48.720 --> 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. 08:58.680 --> 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. 09:18.860 --> 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. 09:31.800 --> 09:41.280 But under the hood, these API calls are basically a Windows wrapper to something called Runtime Services. 09:41.280 --> 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. 09:59.960 --> 10:09.680 However, if you as an attacker can get code executing in ring zero, you can call those Runtime Services directly. 10:09.680 --> 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. 10:23.760 --> 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. 10:34.360 --> 10:43.720 Okay, first step in understanding what we have at our disposal is do a proper attack surface enumeration or proper scoping. 10:43.720 --> 10:46.180 Let's talk about some of the ways that you can do that. 10:46.180 --> 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. 10:53.180 --> 11:03.160 It can be a laptop, desktop, server, industrial controller, whatever you think falls under the definition of the word computer. 11:03.180 --> 11:10.060 But whatever you do, for the love of God, remember to unplug it from power before you take it apart. 11:11.720 --> 11:14.900 Some of the key things to remember when you take things apart. 11:15.160 --> 11:18.700 Remember where you put the screws you took out. 11:18.700 --> 11:20.200 Don't lose them. 11:20.200 --> 11:27.940 Remember which screw goes to which hole because some of them are longer than the others. 11:27.940 --> 11:36.720 And for some diabolical reason, vendors tend to not adhere to the same standard across devices. 11:36.780 --> 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. 11:54.780 --> 11:58.560 Also remember to group them and label them. 11:59.020 --> 12:03.100 And if you have any static electricity, remember to dispose of it. 12:03.100 --> 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. 12:13.220 --> 12:18.720 Once you got it open, you need to get a magnifying glass or a jeweler's loop. 12:19.460 --> 12:24.500 You can pick these up at like a couple of bucks on Amazon or eBay. 12:25.720 --> 12:33.760 Many computers have a lot of chips that look similar and have some very similar markings. 12:33.760 --> 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. 12:49.720 --> 12:50.720 Use your phone. 12:50.720 --> 12:55.040 You have this device that gives you access to all the cat images on the internet. 12:55.100 --> 12:56.480 Use it to take pictures. 12:56.900 --> 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. 13:03.040 --> 13:04.200 I know this sounds basic. 13:04.200 --> 13:12.680 Everything I say sounds super basic, but these are things that you'd wish you'd thought of at some point. 13:12.680 --> 13:18.440 I myself had written these down and it's lessons learned in blood. 13:18.680 --> 13:24.580 If you're afraid to open your $1,500 laptop, don't worry. 13:24.620 --> 13:27.280 Someone on the internet has probably done it for you. 13:27.280 --> 13:31.540 So you need to google the shit out of teardown images. 13:31.540 --> 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. 13:52.980 --> 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. 14:11.320 --> 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. 14:27.320 --> 14:29.940 One more option is look for schematics. 14:29.940 --> 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. 14:52.280 --> 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. 15:07.300 --> 15:13.600 It will basically allow you to understand which device does what and how. 15:13.620 --> 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. 15:30.000 --> 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. 15:37.760 --> 15:38.940 Go ahead, go for it. 15:38.940 --> 15:41.900 You could spend like 100, 200 bucks on this. 15:43.810 --> 15:51.150 My favorite part is looking for official documentation. 15:51.150 --> 16:00.690 And the biggest tip we could give you for looking for those is statement of volatilities or declarations of volatilities. 16:00.690 --> 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. 16:17.110 --> 16:26.410 These documents basically state what volatile and non-volatile components are in a platform. 16:26.410 --> 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. 16:39.910 --> 16:49.970 Some of these documents contain hilarities like this one saying 128 bytes are protected by intel. 16:49.970 --> 16:53.410 The other 128 bytes are not right protected. 16:53.710 --> 16:55.850 So what the shit? 16:55.850 --> 17:05.470 Why would you put this in a document that tells me I have 256 bytes of non-volatile storage? 17:05.470 --> 17:06.550 Half of it's protected. 17:06.550 --> 17:07.830 The other half's not. 17:07.830 --> 17:08.990 Go have fun. 17:09.490 --> 17:12.650 Okay, we have a demo about that. 17:14.210 --> 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. 17:24.450 --> 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. 17:36.430 --> 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. 17:44.810 --> 17:48.610 Sometimes it's not going to be documented on how to clear it or not. 17:48.610 --> 17:49.670 Sometimes it will be. 17:49.670 --> 17:55.050 There's sometimes in some platforms jumpers you need to remove and and put back. 17:55.450 --> 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? 18:04.530 --> 18:05.730 Yes and no. 18:05.730 --> 18:13.630 You never know if it means is it user space modifiable or is it modifiable from a user at all. 18:13.630 --> 18:23.390 And whatever you do, as a rule to live by, always challenge the basic assumptions that you encounter in official documentation. 18:23.550 --> 18:25.950 Especially some that you can prove easily wrong. 18:25.950 --> 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. 18:37.150 --> 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. 18:47.950 --> 18:51.150 The user is intended to be able to modify this. 18:51.390 --> 18:58.890 But system software or other software running on this on the device could be modifying these components. 18:58.890 --> 19:02.870 It just is not making that directly accessible to the customer. 19:02.870 --> 19:05.510 It doesn't mean that it's not modifiable at all. 19:05.530 --> 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. 19:17.090 --> 19:20.590 We'll go through them one at a time and we'll describe them. 19:20.590 --> 19:27.050 And then we'll later proceed into explaining what the pros and cons are from an attacker's perspective. 19:27.110 --> 19:29.410 And hopefully we can have fun while doing it. 19:32.140 --> 19:37.300 First things first, remember that 128 byte that we saw before? 19:38.200 --> 19:45.120 If we looked at the CMOS example in the previous slide, it said it's not user modifiable. 19:45.120 --> 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. 19:53.340 --> 20:01.940 But I wanted to emphasize that whatever the document says doesn't literally mean what you think it means. 20:01.940 --> 20:03.460 You need to go double check. 20:05.240 --> 20:08.380 So basically, back to the CMOS topic. 20:08.640 --> 20:15.640 If you are young and you have no idea what CMOS stands for, I am jealous. 20:15.640 --> 20:23.580 If you are somewhat old and you had to remove a battery from your computer motherboard, my heart's with you. 20:23.680 --> 20:33.720 It's really a relic that's used to have settings set for BIOS bring up, for the system bring up. 20:34.180 --> 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. 20:48.240 --> 20:53.660 The main thing I've seen this used is the real-time clock. 20:54.060 --> 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? 21:03.140 --> 21:07.180 Probably because it keeps that real-time clock timer going internally. 21:07.940 --> 21:12.700 In modern platforms, the CMOS is located inside the chipset. 21:12.700 --> 21:14.620 So you really can't see it. 21:14.820 --> 21:17.360 It's it's itty-bitty. 21:17.620 --> 21:20.080 Not like other chips that we're going to talk about later. 21:22.040 --> 21:27.660 The pros of CMOS is that it has a few unused bytes. 21:27.680 --> 21:31.560 You can access it through IO ports. 21:31.560 --> 21:35.020 You can do in-and-out instructions to get to it. 21:35.020 --> 21:38.100 It exists almost everywhere. 21:39.000 --> 21:42.840 The cons are that it's super tiny. 21:42.840 --> 21:50.160 It only contains 256 bytes separated to two regions, lower CMOS and upper CMOS. 21:50.160 --> 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. 22:01.160 --> 22:09.580 We don't know exactly what each modification of each bit might might do, but it's well documented. 22:09.580 --> 22:14.440 And then if you want to go to explore what you can do with it, it's all over Wikipedia. 22:15.640 --> 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. 22:29.480 --> 22:37.880 For example, BitLocker has PCRs it's monitoring and if those PCR change, then it goes into BitLocker recovery mode. 22:38.820 --> 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. 22:48.820 --> 22:51.880 So you don't think we're full of shit? 22:52.880 --> 22:56.280 Here's a short demo of how to abuse CMOS. 22:56.320 --> 23:01.620 In the demo you're about to see, we have the steps written on the right. 23:01.680 --> 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. 23:15.080 --> 23:18.980 We restore it back and then we read it again to show that we changed it back. 23:19.240 --> 23:21.680 Let's go and run the demo. 24:01.220 --> 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. 24:12.220 --> 24:14.200 So let's take a look at SpyFlash. 24:14.960 --> 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. 24:28.760 --> 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. 24:40.620 --> 24:44.220 There's a few different regions within the SpyFlash. 24:44.500 --> 24:50.400 If you have an Intel platform, you'll have a region for the manageability engine or the ME. 24:51.060 --> 24:53.360 It's also known as the CSME. 24:53.360 --> 24:57.820 AMD platforms will have a PSP region for the platform security controller. 24:57.960 --> 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. 25:10.220 --> 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. 25:20.500 --> 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. 25:34.600 --> 25:40.500 Because of this, the top of the BIOS region needs to correspond to the top of the SpyFlash. 25:40.500 --> 25:42.300 It can vary in size. 25:42.300 --> 25:50.180 So you can have a eight meg BIOS region or a four meg BIOS region. 25:50.180 --> 25:58.620 The size can vary, but the top of that region needs to correspond to the top of the spy chip itself. 25:59.940 --> 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. 26:12.820 --> 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. 26:24.200 --> 26:28.060 There can be some additional regions like the ME region. 26:28.220 --> 26:33.980 Some platforms will have a GigE region or an embedded controller region. 26:33.980 --> 26:41.000 There can be a platform data region which is for OEM specific additional components. 26:41.160 --> 26:48.120 The region mapping in the flash descriptor also doesn't need to include all of the contents of the spy region. 26:48.120 --> 26:56.180 So there can be some padding regions or padding areas that aren't actually included in the map as well. 26:57.660 --> 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. 27:15.320 --> 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, 27:32.660 --> 27:36.820 the GigE controller has access to read and write directly to that spy region. 27:36.820 --> 27:41.140 So those access controls are stored in the flash descriptor. 27:43.500 --> 27:49.620 So there are a lot of cases where the CPU can't directly read and write to the ME region. 27:50.120 --> 27:57.300 And most systems these days will have that BIOS region protected via hardware mechanisms in the chipset. 27:57.520 --> 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. 28:08.920 --> 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. 28:17.980 --> 28:21.100 Sometimes that doesn't provide signature verification. 28:21.100 --> 28:33.540 Sometimes it will do signature verification for part of the region but still copy data into that spy flash for you. 28:33.540 --> 28:41.500 However, the gigabit region itself is generally unprotected and you have full read and write access to that from the CPU. 28:42.000 --> 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. 29:01.600 --> 29:07.200 So if you have that issue, there's a lot of ways that you can take advantage of that. 29:07.520 --> 29:16.500 Another interesting storage location is the SPD or Serial Presence Detect chip in DRAM memory modules. 29:16.700 --> 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. 29:26.120 --> 29:29.060 There are a lot of different types of memory. 29:29.280 --> 29:33.040 There's a DRAM2, DRAM3, DRAM4. 29:33.520 --> 29:42.520 Each of these different memory modules have different parameters or configuration that needs to be done in order to be used. 29:42.700 --> 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. 29:58.240 --> 30:05.140 So the SPD is essentially a tiny EEPROM on those DRAM memory modules. 30:05.140 --> 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. 30:15.760 --> 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. 30:36.720 --> 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. 30:46.860 --> 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. 30:58.760 --> 31:06.720 In some systems, this SPD, the lower half of the SPD, which contains this critical data, is locked. 31:06.960 --> 31:15.240 Sometimes that's not protected though, and modifying that region can can brick the system or cause other unexpected behavior. 31:16.100 --> 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. 31:29.500 --> 31:34.240 So for accessing the SPD, we need to have it unlocked. 31:34.240 --> 31:42.120 It's essentially an SPD EEPROM that is connected over an SMBus interface. 31:42.120 --> 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. 31:51.360 --> 31:55.840 That includes a protection mechanism to prevent writes to it. 31:55.840 --> 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. 32:05.720 --> 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. 32:16.660 --> 32:23.380 And there are also attack scenarios where maybe bricking a device makes sense in the attack class. 32:23.380 --> 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. 32:34.600 --> 32:37.240 Next, we have USB controllers. 32:37.240 --> 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. 32:55.280 --> 33:08.940 Some of these have updatable firmware and it's depressingly common how many of these have unsigned firmware updates. 33:09.220 --> 33:14.680 And you as an attacker can store whatever payload you want on them. 33:14.680 --> 33:23.640 For example, we can have not just USB controllers that exist as USB bridges or on your motherboard. 33:23.640 --> 33:25.680 It doesn't have to be a USB controller. 33:25.680 --> 33:31.900 It will be actually a PCI device that exposes a USB 3.1 interface. 33:31.900 --> 33:43.400 If you have USB-C ports on your desktop, most likely you'll have one of these PCI to USB components. 33:43.400 --> 33:47.000 Not necessarily all of them are PCI to USB. 33:47.000 --> 33:50.940 Some of them are USB to SATA. 33:51.260 --> 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. 34:04.620 --> 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. 34:13.260 --> 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. 34:28.040 --> 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. 34:39.940 --> 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. 34:52.240 --> 34:54.340 It's not dumb, I promise you. 34:54.340 --> 34:55.940 I'll show you the code right after. 35:21.690 --> 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. 35:37.510 --> 35:43.390 What's circled in red is the actual Metasploit code that we have in the firmware. 35:43.390 --> 35:46.810 What's colored black is empty space. 35:47.430 --> 35:49.570 Everything else is actual code. 35:49.570 --> 35:54.450 So you'd see there is about a third of it, almost half of the image. 35:54.450 --> 35:56.490 It's 128 kilobytes. 35:56.490 --> 36:01.630 Out of that, so much space is is empty for us to use as attackers. 36:01.630 --> 36:08.250 The fact that I put a few hundred bytes as payload for a demo looks tiny. 36:09.930 --> 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. 36:24.270 --> 36:30.010 And once we find the leetleet, we fill up a buffer with the bytes from the firmware. 36:30.250 --> 36:41.090 After we have the payload, we're loading their payload from UEFI. 36:41.090 --> 36:47.030 But in this case, we use interoperability and marshalling, so there's no p invokes. 36:47.150 --> 36:49.690 Topher helped us speak this up. 36:49.950 --> 36:53.710 And we load them in memory and we execute them. 36:53.730 --> 36:54.450 Simple as that. 36:54.450 --> 36:56.590 All this code is going to be available on GitHub. 36:57.830 --> 37:04.230 Generally speaking, as an attacker, you'd break this attack into two distinct steps. 37:04.230 --> 37:06.750 One is hiding the payload. 37:06.890 --> 37:09.750 The second is retrieving and running it. 37:09.750 --> 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. 37:26.510 --> 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. 37:38.590 --> 37:43.090 Let's review a little bit of the attack surface from an internal asset perspective. 37:43.090 --> 37:49.130 You have USB controllers that are embedded in your devices that have their own firmware. 37:49.290 --> 37:54.770 You have PCI bridges that act as PCI to USB devices. 37:54.770 --> 37:58.990 You have trackpads and touch points and touchpads. 37:58.990 --> 38:01.610 If you have a ThinkPad Lenovo, it's a point. 38:01.610 --> 38:02.610 I don't know what it's called. 38:02.610 --> 38:04.250 You have one of those trackpads. 38:04.350 --> 38:08.090 It can have sometimes its own internal flash. 38:08.570 --> 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, 38:28.070 --> 38:29.290 and it has firmware. 38:29.290 --> 38:33.390 Most likely you can modify it from your computer. 38:33.470 --> 38:37.150 Webcams tend to have firmware related to them. 38:37.150 --> 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. 39:04.390 --> 39:06.090 You like to add something, Jesse? 39:06.090 --> 39:11.670 In addition to these controllers, there's also all of the endpoint devices themselves. 39:11.670 --> 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. 39:27.530 --> 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. 39:43.300 --> 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. 39:54.540 --> 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. 40:01.620 --> 40:10.640 Whatever ports you can use, Thunderbolt 3, USB-C 3.1, whatever USB format it is. 40:11.260 --> 40:13.460 Proprietary connectors for docking stations. 40:13.460 --> 40:17.000 Docking stations have a lot of parts in them that have their own firmware. 40:17.500 --> 40:23.440 So, ask yourself, how often do you check the firmware on the dock that you plug your laptop to at work? 40:23.760 --> 40:26.420 And then, obviously, the over-the-air updates. 40:26.580 --> 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. 40:39.400 --> 40:42.380 Sometimes those have firmware as well. 40:42.380 --> 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. 40:55.860 --> 41:02.740 Another example that we think is something that we should all pay attention to is the Gigabit Ethernet. 41:03.360 --> 41:10.840 If you have a LAN port on your laptop, congratulations, you have a code cave. 41:11.140 --> 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. 41:25.620 --> 41:31.460 I have yet to encounter one instance where it's, if it exists, it is read-only. 41:31.460 --> 41:37.180 This region in in SpyFlash usually contains the configuration data for the device. 41:37.800 --> 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. 41:49.980 --> 41:51.680 Usually, there are two images. 41:51.680 --> 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. 42:04.680 --> 42:10.480 Now, some systems are mandated to have such things like servers, for example. 42:10.480 --> 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. 42:24.240 --> 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. 42:39.880 --> 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. 42:53.360 --> 42:57.440 There's also other discrete PCI devices, but we'll not talk about them right now. 42:57.620 --> 43:02.220 Let's look at an example of the GigE region in a HEX editor. 43:04.740 --> 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. 43:19.860 --> 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. 43:34.060 --> 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. 43:50.060 --> 43:51.760 But how do we access it? 43:51.760 --> 43:53.260 I mean, it's great. 43:53.260 --> 43:56.940 It's in SPI Flash, but how do we read and write from it? 43:57.000 --> 44:01.760 The easiest way to do this on Intel platforms is using the Flash programming tool. 44:03.280 --> 44:09.080 It's an internal tool that it's not supposed to be public, but you can find it on the internet. 44:09.080 --> 44:15.500 I'm not going to say where, but you can use it to update your BIOS and update your ME. 44:15.500 --> 44:21.360 Some vendors might have it in their update packages, some don't. 44:21.360 --> 44:22.900 There are other utilities. 44:23.240 --> 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. 44:50.620 --> 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. 45:03.080 --> 45:10.320 One of them might include a pre-existing tool that you can abuse or use to your advantage. 45:11.440 --> 45:15.620 Now, the best part of this, in my eyes, it's the Confused Deputy. 45:15.620 --> 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. 45:30.380 --> 45:36.940 And a lot, a big number of those would have access to IO ports. 45:37.180 --> 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, 45:57.040 --> 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. 46:13.540 --> 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. 46:28.140 --> 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. 46:47.340 --> 46:53.340 Now we're going to flash a malicious version, well, so-called malicious, just for demo purposes. 46:58.520 --> 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. 47:09.240 --> 47:11.160 Now we flash it. 47:17.480 --> 47:21.720 Now it's flashed, that data is on the computer now. 47:26.780 --> 47:29.040 We dump the new content, 47:32.230 --> 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. 47:42.530 --> 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. 48:00.870 --> 48:05.090 A few tips and tricks of how you can hide your payload in firmware. 48:05.350 --> 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. 48:11.990 --> 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. 48:21.170 --> 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. 48:46.750 --> 48:51.610 But past that, there is empty space that is not included or not defined. 48:51.610 --> 48:56.510 But when you read and write the firmware from the controller, it would read and write the whole chip. 48:57.430 --> 49:07.480 Another way is if you have unverified firmware, you can put your payload inside segments of the that are empty. 49:07.580 --> 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. 49:18.240 --> 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. 49:27.980 --> 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. 49:43.060 --> 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. 49:56.780 --> 50:01.760 The practicality is that a lot of people are probably saying, well, what's the point? 50:01.760 --> 50:03.020 You got to be admin. 50:03.040 --> 50:05.920 This is all bullshit, but not necessarily. 50:05.920 --> 50:12.320 Like we said before, some drivers, if they exist on the system, they can be accessed from user space. 50:12.600 --> 50:16.920 So all you have to do is just see if the device exists and send it iOctals. 50:16.980 --> 50:25.300 Another point to mention is this scenario is relevant if you already have execution on the target. 50:25.320 --> 50:31.300 There's no point of gaining persistence or hiding your payload if you're just getting into the system. 50:31.300 --> 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. 50:45.580 --> 50:47.440 There is a lot to explore there. 50:47.440 --> 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. 50:57.080 --> 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. 51:17.860 --> 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. 51:33.440 --> 51:36.680 I guess it's easier to understand. 51:36.680 --> 51:38.800 It's managed code. 51:38.800 --> 51:40.040 Why the hell not? 51:40.040 --> 51:48.580 In our example, we're releasing code that uses the PMX driver, which is included in a lot of Intel utilities. 51:48.580 --> 51:51.920 It is dating back to 1998. 51:51.920 --> 51:54.400 It can read and write physical memory. 51:54.400 --> 52:02.980 It can read and write debug registers, control registers, model-specific registers, IOs, and so much more. 52:03.180 --> 52:04.220 You can load it. 52:04.220 --> 52:07.020 If you're admin, you can load it in Windows and play with it. 52:07.020 --> 52:15.660 Imagine read, write everything, but not read, write everything that was blocked by Windows. 52:16.600 --> 52:19.760 It's confusing, I know, but its name was read, write everything. 52:19.760 --> 52:24.940 We will also release code that's using AceMedia tools. 52:25.240 --> 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. 52:41.540 --> 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. 52:53.060 --> 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. 53:02.800 --> 53:09.160 We also used update tools from AceMedia to write the malicious firmware into the device. 53:09.160 --> 53:11.840 Funny story about AceMedia controllers. 53:11.840 --> 53:15.440 I bought, for the talk, I bought a couple of devices off Amazon. 53:15.520 --> 53:23.500 Both of them are AceMedia controllers, and I have an Intel NUC, it's called Hades Canyon, it's a NUC8. 53:23.500 --> 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. 53:38.140 --> 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. 53:48.980 --> 53:51.550 And then I realized I have two controllers. 53:52.940 --> 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. 54:03.760 --> 54:07.160 Talk about a scary moment right there. 54:07.620 --> 54:09.440 So yeah, it's a funny story. 54:10.380 --> 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. 54:20.140 --> 54:25.560 There is so much space in non-volatile memory. 54:25.560 --> 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. 54:38.070 --> 54:40.350 Is EDR catching up? 54:40.350 --> 54:42.650 Well, yes and no. 54:43.330 --> 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. 54:56.390 --> 55:00.270 But why just UEFI? 55:00.270 --> 55:03.470 There's so many other places on the platform that you can look into. 55:03.990 --> 55:05.370 I mean, great. 55:05.490 --> 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. 55:14.250 --> 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? 55:23.330 --> 55:25.750 We have solutions coming out. 55:25.750 --> 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, 55:46.870 --> 55:50.510 BootGuard, BIOSGuard, all kinds of solutions. 55:50.690 --> 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. 56:02.470 --> 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. 56:12.830 --> 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. 56:28.270 --> 56:35.370 And also like this, like Microsoft's, it is Defender ATP, so it's not rolled out everywhere. 56:35.370 --> 56:41.130 It's only that the premium version so that you need to pay more for. 56:41.130 --> 56:43.390 What can we do about it? 56:43.490 --> 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. 56:57.470 --> 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. 57:25.430 --> 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. 57:45.370 --> 57:48.410 And with that, we've reached the end of our presentation. 57:48.610 --> 57:53.290 Thank you for bearing with us and watching the slides while we talk. 57:53.410 --> 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. 58:06.590 --> 58:11.290 But feel free to ping us later on social media if you have any questions.