[00:01.620 --> 00:03.180]  Hello? Is this thing on?
[00:04.680 --> 00:10.140]  Hi, everyone. Welcome to our talk, Bites in Disguise. If you happen to watch this
[00:10.140 --> 00:14.940]  as it's being released by DEF CON, we want to thank you for tuning in on a Sunday morning.
[00:15.060 --> 00:19.640]  You brave souls. If you're watching this on YouTube at some point later on,
[00:19.640 --> 00:23.140]  well, thank you, you lazy f**ks. My name is Mickey.
[00:23.160 --> 00:24.240]  And I'm Jesse.
[00:24.420 --> 00:29.160]  I'm on the left. Jesse's on the right, just so you'd know to associate our faces with our voices
[00:29.160 --> 00:34.420]  now. We're both principal security researchers at Eclipseum, and we deal with hardware and firmware
[00:34.420 --> 00:38.140]  on a daily basis. Now that we have all the formalities out of the way, we can start with
[00:38.140 --> 00:44.280]  the actual talk. We'd like to start with a little bit of structure. What are we going to talk about?
[00:44.280 --> 00:53.040]  The agenda and high level. We want you to understand the background and the why,
[00:53.040 --> 00:56.800]  because it's very important for you to see things from a different viewpoint,
[00:56.800 --> 01:02.320]  our own viewpoint. We hope that by showing you what motivated us to look into this research,
[01:02.320 --> 01:07.560]  you'll be able to understand and maybe go out on your own and explore this yourselves.
[01:08.040 --> 01:13.880]  Once we've established that, we can show you what we did from an attack surface perspective,
[01:14.380 --> 01:18.040]  how we look at things from a hardware firmware perspective.
[01:18.920 --> 01:25.000]  After that, we can continue and walk you through some of the hiding places inside computers,
[01:25.000 --> 01:31.520]  servers, laptops, or any other computer platform. We thought about the best way to do this and we
[01:31.520 --> 01:38.100]  decided that it will be best if we start explaining each hiding spot and immediately after that,
[01:38.100 --> 01:46.120]  go through the attack surface scenarios and examples for that spot. Once that's all done,
[01:46.120 --> 01:52.620]  we'll discuss a little bit of what's in store for these types of threats in the future of the
[01:52.620 --> 01:58.520]  security industry and what can we do to protect against them. In the past, we've seen a lot of
[01:58.520 --> 02:06.940]  research talking about bad devices being abused like bad USB, rubber duckies, OMG cables, which
[02:06.940 --> 02:16.680]  are the best cables, all these malicious devices, dropping code, executing it from a separate device,
[02:16.680 --> 02:23.940]  hiding things off the platform. But the main issue is persistence. If your payload has to be
[02:23.940 --> 02:30.360]  plugged into the target to replay every time, even if it still stays undetectable, having a thumb drive
[02:30.360 --> 02:36.060]  stick out of your computer would be noticed by a user. You can't really hide that. So what if you
[02:36.060 --> 02:42.460]  could have your loader persistent and just have the payload itself, that's the malicious code,
[02:42.460 --> 02:47.820]  stored somewhere in your device. The easiest things to find about this type of
[02:47.820 --> 02:52.660]  research that was done in the past is fileless malware and fileless exploits and in-memory
[02:52.660 --> 03:00.040]  execution and anything that doesn't touch disk. And remember, don't touch disk. And one of those
[03:00.040 --> 03:07.880]  examples is a talk that was done last year at DEF CON by Topher and Mike that discussed about
[03:07.880 --> 03:13.960]  abusing this exact thing in UEFI variable. We usually describe this in the slide and say,
[03:13.960 --> 03:18.400]  look, past research done this and that. But since we know these guys, we thought we'd just
[03:18.400 --> 03:23.300]  ask them and record them and just replay it for you guys. So here's Topher and Mike.
[03:23.620 --> 03:27.360]  Topher is the left in the picture and Mike is on the right. So I hope you enjoy and help us
[03:27.360 --> 03:33.680]  embarrass them. Hey, I'm Topher Timson. Hey, I'm Michael Lebowitz. Last year at DEF CON,
[03:33.680 --> 03:38.660]  Mike and I gave a talk entitled EDR is coming, hide your shit. The reason that we did this
[03:38.660 --> 03:43.660]  research and gave this presentation is because we've been red teaming for a number of years now,
[03:43.660 --> 03:49.540]  and we were running into the problem that a lot of our malicious payloads and our malware were
[03:49.540 --> 03:56.020]  being eaten up by whether it be AV solutions or EDR solutions. And the blue team was discovering
[03:56.020 --> 04:01.140]  us and ruining our engagements. And, you know, when your lovingly crafted payload becomes some
[04:01.140 --> 04:07.740]  analyst sample, everyone's going to have a bad evening. So in looking at new areas in which we
[04:07.740 --> 04:15.060]  could hide our shit, we effectively wanted to get off of disk. The rationale for this was because
[04:15.060 --> 04:22.440]  having things on disk leaves it vulnerable to AV scanning it. It allows analysts to look at
[04:22.440 --> 04:29.840]  hashes of the binaries. The EDR solution sees that they're executing these binaries and all
[04:29.840 --> 04:35.460]  the activity that they're doing is shown to the analyst in whatever EDR platforms console they're
[04:35.460 --> 04:44.320]  using. In looking at ways to hide our shit, we looked into UEFI. So I used to do some UEFI
[04:44.320 --> 04:50.900]  security research. So I was already somewhat familiar with how UEFI worked as this firmware
[04:50.900 --> 04:58.420]  platform. And variables are something that were exposed after boot services. So they were available
[04:58.420 --> 05:06.500]  at runtime and actually booting the platform. Windows 10 re-added a UEFI API that allowed you
[05:06.500 --> 05:12.880]  to read and write UEFI firmware variables. And I had already known, or at least I had suspected,
[05:12.880 --> 05:20.220]  that EDR platforms were not at all scanning the UEFI firmware variable space in NVRAM. Everything
[05:20.220 --> 05:24.480]  that we had seen, it was all about what's on the hard drive, what's being executed from the hard
[05:24.480 --> 05:31.580]  drive, and we saw no notion of anything having to do with firmware. So we put our payload there,
[05:31.580 --> 05:37.240]  and lo and behold, analysts were completely blind and the EDR solution and AV solutions never saw
[05:37.240 --> 05:42.500]  our actual malicious payloads. They would see the binaries that we dropped on disk that would
[05:42.500 --> 05:48.060]  execute the payloads out of the UEFI variable, but those are seemingly benign and they're like
[05:48.060 --> 05:55.860]  four kilobyte binaries. In our talk, I handled the Windows platform piece, and my C-sharp binary
[05:55.860 --> 06:03.500]  to do reflective loading of a UEFI variable is like 15 lines of code, and nobody sees it at all
[06:03.500 --> 06:08.540]  in their UEFI platforms at the time. A couple of vendors have added some mitigations to this
[06:08.540 --> 06:14.560]  and are seemingly less blind, but it's still a problem facing a lot of these security solutions
[06:14.560 --> 06:21.980]  where if you hide stuff off of disk, they're not seen. As ever said, we want to muddy the
[06:21.980 --> 06:27.360]  water for analysis, and the analysis is highly correlated to the process image that you're
[06:27.360 --> 06:33.840]  running, and UEFI is an area that we're both familiar with, and UEFI access is available
[06:33.840 --> 06:40.740]  in Ring 3, and anytime you have delegated access in Ring 3 to something that is like a system
[06:40.740 --> 06:45.700]  firmware component, you're in for a good time. And I had previously done some research where I
[06:45.700 --> 06:52.800]  put malicious content into a RAM disk, and so now I had done this such that the malicious content was
[06:52.800 --> 07:00.120]  essentially benign and a very simple loader that could load the end payload from UEFI and then
[07:00.120 --> 07:08.000]  persist across the RAM disk boundary and then infect the EDR platform on the host system. So in
[07:08.000 --> 07:16.180]  total, a three-stage payload system with only one part, the tiniest loader on disk, but
[07:16.180 --> 07:22.660]  in a sort of awkward place in disk that's hard to find. And the whole rationale behind this was
[07:22.660 --> 07:28.540]  making it easier for offensive security practitioners and people on red teams to evade
[07:28.540 --> 07:35.800]  detection, because anytime you execute something to get that initial access, that will leave a lot
[07:35.800 --> 07:43.940]  of traces, particularly in EDR. But we were all about reducing that threat to detection for us
[07:43.940 --> 07:49.580]  after the fact, and by hiding your shit in places that these platforms are blind to, you can persist
[07:49.580 --> 07:54.980]  for longer. And in reality, what we're really trying to do is bring net happiness to the world,
[07:54.980 --> 07:59.340]  because we're now happy that we can persist for longer and run our engagements for longer,
[07:59.340 --> 08:04.040]  but the blue team's also happy because they don't have to work till midnight hunting us down.
[08:04.040 --> 08:10.900]  It's true as it is now, it was then, we need to flatten the curve, the curve of risk of you being
[08:10.900 --> 08:15.280]  detected over time. But no good thing lasts forever, and eventually your breach is going to
[08:15.280 --> 08:20.920]  get detected. But we just want that to go a little bit longer. Thank you Topher and Mike for that
[08:20.920 --> 08:26.520]  amazing summary. Just to recap some of the things that we want to emphasize here is, we want to
[08:26.520 --> 08:33.460]  avoid detection, we want to make it harder for forensic analysts to find our payload, we want to
[08:33.460 --> 08:39.300]  have code caves that we can abuse later on. Basically storing anything in non-conventional
[08:39.300 --> 08:46.980]  storage that the analysts are not looking at, hiding their blind spots. A little bit about
[08:46.980 --> 08:53.900]  UEFI variables. We've seen last year, we know EDR and AV have started looking into these and
[08:53.900 --> 08:59.960]  now we've seen Microsoft adding capabilities, we'll talk about them later. But using get and
[08:59.960 --> 09:08.080]  set variable is something that an attacker uses that is exposed by the Windows API, which is nice
[09:08.080 --> 09:14.910]  and handy if you get that coveted admin privilege, but it's not that handy when you are worried about
[09:15.440 --> 09:22.880]  AV and EDR hooking and monitoring your behavior. So think about it like this, these API calls are
[09:22.880 --> 09:29.740]  not commonly used and if you call them, you will raise so many red flags, you just want to hide
[09:29.740 --> 09:38.580]  under a rock. But under the hood, these API calls are basically a Windows wrapper to
[09:39.180 --> 09:45.320]  something called Runtime Services. UEFI-based BIOS has these function calls in memory,
[09:45.320 --> 09:50.840]  which are called Runtime Services that are obviously, well, as the name suggests,
[09:50.840 --> 09:56.880]  they're available during runtime, but they're only in ring zero, which means the Windows API calls
[09:56.880 --> 10:04.340]  those Runtime Services from a ring zero context. However, if you as an attacker can get code
[10:04.340 --> 10:11.700]  executing in ring zero, you can call those Runtime Services directly. The trick is they have
[10:12.700 --> 10:17.740]  a magic header in memory that you can search for and then you can find the Runtime Services table
[10:17.740 --> 10:23.580]  and then from there extrapolate the calls for setting a variable and getting a variable.
[10:23.760 --> 10:28.380]  All that's nice and dandy in theory, but to get that running in ring zero with
[10:28.380 --> 10:36.220]  modern protections that Windows is incorporating is going to be tricky. Okay, first step in
[10:36.220 --> 10:42.160]  understanding what we have at our disposal is do a proper attack surface enumeration or
[10:42.160 --> 10:47.560]  proper scoping. Let's talk about some of the ways that you can do that. First and most
[10:47.560 --> 10:52.420]  obvious way is to get your hands on your machine and pop open the box and look at what you're
[10:52.420 --> 11:00.480]  attacking. It can be a laptop, desktop, server, industrial controller, whatever you think
[11:00.480 --> 11:05.880]  falls under the definition of the word computer. But whatever you do, for the love of God,
[11:05.880 --> 11:10.060]  remember to unplug it from power before you take it apart.
[11:11.720 --> 11:17.160]  Some of the key things to remember when you take things apart. Remember where you put the screws
[11:17.560 --> 11:25.700]  you took out. Don't lose them. Remember which screw goes to which hole because some of them
[11:25.700 --> 11:33.940]  are longer than the others. And for some diabolical reason, vendors tend to not adhere to the same
[11:33.940 --> 11:41.400]  standard across devices. So while Dell laptops tend to have the same length of screws holding
[11:41.400 --> 11:48.500]  their chassis in, some other third-party vendors would have, and I shit you not, 14 different
[11:48.500 --> 11:57.300]  screws that have six different lengths in the bottom of the laptop. Also remember to group them
[11:57.300 --> 12:03.520]  and label them. And if you have any static electricity, remember to dispose of it. If you
[12:03.520 --> 12:09.440]  don't have any static electricity, you know, wristbands or anything, just YOLO and hope that
[12:09.440 --> 12:17.960]  you don't break your machine. Once you got it open, you need to get a magnifying glass or a
[12:17.960 --> 12:27.140]  jeweler's loop. You can pick these up at like a couple of bucks on Amazon or eBay.
[12:27.300 --> 12:33.760]  Many computers have a lot of chips that look similar and have some very similar markings.
[12:33.760 --> 12:40.620]  For example, spy chips made by Windbond will have very, very similar labels on them,
[12:40.620 --> 12:47.440]  but you'd find a couple of them on the same computer and when you won't be sure what's what,
[12:47.440 --> 12:52.480]  we recommend that you take a picture. Use your phone. You have this device that gives you
[12:52.480 --> 12:57.660]  access to all the cat images on the internet. Use it to take pictures. If you can label the
[12:57.660 --> 13:03.040]  pictures, label them, but just take a picture of it with your phone and save it for later.
[13:03.040 --> 13:09.920]  I know this sounds basic. Everything I say sounds super basic, but these are things that
[13:09.920 --> 13:16.560]  you'd wish you'd thought of at some point. I myself had written these down and it's
[13:16.560 --> 13:22.700]  lessons learned in blood. If you're afraid to open your $1,500 laptop,
[13:23.440 --> 13:27.280]  don't worry. Someone on the internet has probably done it for you.
[13:27.280 --> 13:34.440]  So you need to google the shit out of teardown images. Seriously, start googling the words
[13:34.440 --> 13:44.280]  teardown or memory upgrade or SSD upgrade or any of those and you'd find a lot of repair shops or
[13:44.800 --> 13:52.200]  repair tutorials or upgrade tutorials online that have HD videos and images of the computers you're
[13:52.200 --> 13:59.840]  looking at. You might not be able to go down to the very low resolution of what chip is what in
[13:59.840 --> 14:10.440]  what capacity, but you'll be able to get a sense of how many exist or how many you can risk opening
[14:10.440 --> 14:17.400]  your laptop for. If you open it and it's only like a BIOS chip and one more versus six others that
[14:17.400 --> 14:27.300]  you suspect might be holding firmware, then your risk assessment about opening it might change.
[14:27.320 --> 14:34.740]  One more option is look for schematics. Now, it's a bit of a weird adventure and you'll find
[14:34.740 --> 14:43.280]  yourself entering the world of repair shops and schematics websites in Vietnam, but you'd be able
[14:43.280 --> 14:51.020]  to find a lot of PDFs that describe how devices interconnect including non-volatile and firmware
[14:51.020 --> 14:57.960]  storage devices. You might be finding a lot of EEPROMs that are on the board and the schematics
[14:57.960 --> 15:03.160]  will tell you exactly what address you need to communicate with to read or write from,
[15:03.160 --> 15:10.440]  which SMBus line has what controller allows you. It will basically allow you to understand
[15:10.440 --> 15:17.320]  which device does what and how. I wouldn't put too much effort into this attack surface scoping
[15:17.320 --> 15:25.320]  method because schematics tend to be confidential and secret and if you happen to find one of a
[15:25.320 --> 15:33.160]  more recent platform, it's going to be really rare. But if you want to practice on an old one,
[15:33.540 --> 15:39.280]  buy a laptop from eBay and see if you can find its schematics. Go ahead, go for it. You could
[15:39.280 --> 15:51.150]  spend like 100, 200 bucks on this. My favorite part is looking for official documentation.
[15:51.150 --> 15:58.650]  And the biggest tip we could give you for looking for those is statement of volatilities or
[15:58.650 --> 16:04.330]  declarations of volatilities. The best way to do this is just google in quotes of volatility
[16:05.010 --> 16:12.550]  and just add the file type pdf and include the words flash or cmos or spy or whatever from
[16:12.550 --> 16:16.930]  keywords that you can find from other documents you will find in the process.
[16:17.110 --> 16:26.730]  These documents basically state what volatile and non-volatile components are in a platform. Now,
[16:26.730 --> 16:33.150]  not every computer has this type of document associated with it, but from finding these
[16:33.690 --> 16:41.410]  documents online, you can understand what is in most common platforms. Some of these documents
[16:42.970 --> 16:51.830]  contain hilarities like this one saying 128 bytes are protected by intel. The other 128 bytes are
[16:51.830 --> 16:59.730]  not right protected. So what the shit? Why would you put this in a document that tells me
[17:00.180 --> 17:07.830]  I have 256 bytes of non-volatile storage? Half of it's protected. The other half's not.
[17:07.830 --> 17:12.650]  Go have fun. Okay, we have a demo about that.
[17:14.210 --> 17:20.330]  Now, I wanted to put a picture of the pdf here, but I couldn't find a good enough resolution so
[17:20.330 --> 17:30.730]  I had to crop a snippet of the table. And the table that you see here is somewhat a representation
[17:30.730 --> 17:39.410]  of what you'll see in a statement of volatility document. You'll see a breaking down by type,
[17:39.410 --> 17:45.470]  size, if it's volatile, non-volatile, what's it used for, how to clear it. Sometimes it's not
[17:45.470 --> 17:50.570]  going to be documented on how to clear it or not. Sometimes it will be. There's sometimes in some
[17:50.570 --> 17:58.450]  platforms jumpers you need to remove and and put back. But the key point that I want to tell you
[17:58.450 --> 18:06.590]  here is even though you see documents saying is this user modifiable? Yes and no. You never know
[18:06.590 --> 18:15.130]  if it means is it user space modifiable or is it modifiable from a user at all. And whatever you do,
[18:15.470 --> 18:21.410]  as a rule to live by, always challenge the basic assumptions that you encounter
[18:21.410 --> 18:26.670]  in official documentation. Especially some that you can prove easily wrong. I can tell you
[18:26.670 --> 18:30.650]  that even though some of these are not saying it's not user modifiable,
[18:31.410 --> 18:35.890]  you will see in a few minutes a demo saying that it is.
[18:37.150 --> 18:41.810]  Yeah, to follow up on that a little, user modifiable in this case means that
[18:41.810 --> 18:47.950]  it's intended to be presented to the user to be demodifiable like the BIOS password.
[18:47.950 --> 18:55.250]  The user is intended to be able to modify this. But system software or other software running on
[18:55.250 --> 19:01.450]  this on the device could be modifying these components. It just is not making that directly
[19:01.450 --> 19:05.510]  accessible to the customer. It doesn't mean that it's not modifiable at all.
[19:05.530 --> 19:11.130]  Now that we showed you a way or multiple ways to find information and explore it by yourself,
[19:11.130 --> 19:15.590]  we can go ahead and start diving a little bit deeper into some individual components
[19:15.590 --> 19:20.590]  that we talked about before. We'll go through them one at a time and we'll describe them.
[19:20.590 --> 19:26.170]  And then we'll later proceed into explaining what the pros and cons are from an attacker's
[19:26.170 --> 19:34.640]  perspective. And hopefully we can have fun while doing it. First things first, remember that 128
[19:34.640 --> 19:42.840]  byte that we saw before? If we looked at the CMOS example in the previous slide, it said
[19:43.440 --> 19:49.900]  it's not user modifiable. And I know Jesse explained that it's what the user can modify
[19:49.900 --> 19:58.780]  sometimes by using a GUI like the BIOS password. But I wanted to emphasize that whatever the
[19:58.780 --> 20:03.460]  document says doesn't literally mean what you think it means. You need to go double check.
[20:05.240 --> 20:14.120]  So basically, back to the CMOS topic. If you are young and you have no idea what CMOS stands for,
[20:14.120 --> 20:20.720]  I am jealous. If you are somewhat old and you had to remove a battery from your computer
[20:20.720 --> 20:31.060]  motherboard, my heart's with you. It's really a relic that's used to have settings set for
[20:31.060 --> 20:38.280]  BIOS bring up, for the system bring up. It's a tiny bit of non-volatile RAM
[20:39.120 --> 20:44.960]  that is only non-volatile as long as their current and that current is supplied by the
[20:44.960 --> 20:51.600]  little lithium battery on the motherboard. The main thing I've seen this used is the
[20:51.600 --> 20:59.960]  real-time clock. So you know how you have a power surge and the microwave clock goes out,
[20:59.960 --> 21:05.420]  but your computer has the same clock afterwards? Probably because it keeps that real-time clock
[21:05.420 --> 21:12.700]  timer going internally. In modern platforms, the CMOS is located inside the chipset.
[21:12.700 --> 21:19.060]  So you really can't see it. It's it's itty-bitty. Not like other chips that we're going to talk
[21:19.060 --> 21:29.780]  about later. The pros of CMOS is that it has a few unused bytes. You can access it through
[21:30.540 --> 21:38.100]  IO ports. You can do in-and-out instructions to get to it. It exists almost everywhere.
[21:39.000 --> 21:47.780]  The cons are that it's super tiny. It only contains 256 bytes separated to two regions,
[21:47.780 --> 21:55.880]  lower CMOS and upper CMOS. If you mess up the wrong bytes, you might cause yourself some trouble
[21:55.880 --> 22:03.800]  and you might need to reset the CMOS or fuck up the platform. We don't know exactly what each
[22:04.700 --> 22:10.020]  modification of each bit might might do, but it's well documented. And then if you
[22:10.020 --> 22:14.440]  want to go to explore what you can do with it, it's all over Wikipedia.
[22:15.640 --> 22:23.700]  One other thing that we we think might happen is that if there are certain PCR measurements done
[22:23.700 --> 22:32.760]  by TPM, modifying CMOS might trigger an alert. For example, BitLocker has PCRs it's monitoring
[22:33.380 --> 22:37.880]  and if those PCR change, then it goes into BitLocker recovery mode.
[22:38.820 --> 22:44.840]  In short, we're pretty sure you can you can have fun with this, but don't mess up bytes that are
[22:44.840 --> 22:56.280]  not zero. So you don't think we're full of shit? Here's a short demo of how to abuse CMOS.
[22:56.320 --> 23:02.720]  In the demo you're about to see, we have the steps written on the right. Basically,
[23:02.720 --> 23:12.180]  we read the CMOS, we write a random payload to the lower part of CMOS, you read it, so we show
[23:12.180 --> 23:18.040]  you that there is a change there. We restore it back and then we read it again to show that we
[23:18.040 --> 24:03.280]  changed it back. Let's go and run the demo. We're going to have the code for this demo up on GitHub
[24:03.280 --> 24:08.000]  after the talk is published and keep an eye on that GitHub because we're going to keep adding
[24:08.380 --> 24:16.920]  more and more code to it as we go on. So let's take a look at SpyFlash. In order to know where
[24:16.920 --> 24:24.360]  to start executing code from in the first place, that code is stored in the SpyFlash and when the
[24:24.360 --> 24:30.820]  system turns on it starts executing instructions from there. Traditionally that was known as BIOS,
[24:30.820 --> 24:36.820]  but these days almost all systems have transitioned over to using a UEFI firmware instead
[24:37.640 --> 24:43.180]  and this firmware is stored in the SpyFlash. There's a few different regions within the
[24:43.180 --> 24:49.580]  SpyFlash. If you have an Intel platform, you'll have a region for the manageability engine or the
[24:49.580 --> 24:56.860]  ME. It's also known as the CSME. AMD platforms will have a PSP region for the platform security
[24:56.860 --> 25:02.580]  controller. There's also a flash descriptor which contains essentially a map for how the
[25:02.580 --> 25:07.920]  contents of the SpyFlash are organized as well as access permissions for these regions.
[25:10.220 --> 25:15.760]  So taking a look at the the contents of the SpyFlash itself, there's a couple constraints
[25:15.760 --> 25:23.080]  that determine the location of a couple of the regions in there. First, when the system boots up,
[25:23.080 --> 25:27.920]  the top of that SpyFlash is mapped to the top of the four gigabyte address space
[25:27.920 --> 25:35.840]  in order for the x86 reset vector to start executing code from there. Because of this,
[25:35.840 --> 25:42.480]  the top of the BIOS region needs to correspond to the top of the SpyFlash. It can vary in size. So
[25:43.000 --> 25:52.920]  you can have a eight meg BIOS region or a four meg BIOS region. The size can vary,
[25:52.920 --> 25:58.620]  but the top of that region needs to correspond to the top of the spy chip itself.
[25:59.940 --> 26:04.840]  Additionally, the flash descriptor region, which is essentially the map and permissions
[26:04.840 --> 26:11.160]  and what is actually stored throughout the spy chip, that starts at the beginning of of the
[26:11.160 --> 26:19.560]  SpyFlash. It contains some platform configuration for the device as well as the map determining
[26:19.560 --> 26:26.380]  where these regions are stored within the SpyFlash itself. There can be some additional regions like
[26:26.380 --> 26:34.340]  the ME region. Some platforms will have a GigE region or an embedded controller region. There
[26:34.340 --> 26:42.340]  can be a platform data region which is for OEM specific additional components. The region mapping
[26:42.340 --> 26:48.120]  in the flash descriptor also doesn't need to include all of the contents of the spy region.
[26:48.120 --> 26:54.380]  So there can be some padding regions or padding areas that aren't actually included in the map
[26:54.900 --> 27:03.120]  as well. To take a look at the flash descriptor itself, starting at the very beginning of the spy
[27:03.120 --> 27:12.720]  contents, there's a signature at 10 hex, offset 10 hex, that is used to determine if there is a
[27:12.720 --> 27:19.380]  flash descriptor in this area. And then there's a mapping, there's a variety of different components
[27:19.920 --> 27:25.740]  and access control lists to determine if the CPU has access to read and write of a particular spy
[27:25.740 --> 27:33.100]  region, or the ME has access to read and write to a particular spy region, or the NIC, the GigE
[27:33.100 --> 27:38.640]  controller has access to read and write directly to that spy region. So those access controls
[27:38.640 --> 27:47.380]  are stored in the flash descriptor. So there are a lot of cases where the CPU can't
[27:47.380 --> 27:53.580]  directly read and write to the ME region. And most systems these days will have that BIOS region
[27:53.580 --> 28:00.020]  protected via hardware mechanisms in the chipset. Occasionally we run into systems where
[28:00.020 --> 28:04.820]  that is still not protected properly and you can just directly write to the spy and BIOS region
[28:05.900 --> 28:12.290]  from code running on the CPU. But even in the case that that BIOS region is properly protected,
[28:14.000 --> 28:19.760]  there can be bugs in the BIOS update mechanism itself. Sometimes that doesn't provide signature
[28:19.760 --> 28:28.800]  verification. Sometimes it will do signature verification for part of the region but still copy
[28:28.800 --> 28:37.660]  data into that spy flash for you. However, the gigabit region itself is generally unprotected
[28:37.660 --> 28:44.680]  and you have full read and write access to that from the CPU. We also sometimes run into cases where
[28:45.080 --> 28:50.500]  the flash descriptor itself has incorrect permissions and that can be rewritten via
[28:50.500 --> 28:58.520]  software to modify the existing region definitions or even define new regions in the spy flash layout
[28:58.520 --> 29:05.500]  and change the permissions for those regions. So if you have that issue, there's a lot of ways
[29:05.500 --> 29:11.460]  that you can take advantage of that. Another interesting storage location is the SPD or
[29:11.460 --> 29:18.620]  Serial Presence Detect chip in DRAM memory modules. Although some recent devices like
[29:18.620 --> 29:22.880]  laptops and tablets only have soldered down memory which is not replaceable,
[29:22.880 --> 29:28.020]  the vast majority of systems include replaceable memory. There are a lot of different types of
[29:28.020 --> 29:37.580]  memory. There's a DRAM2, DRAM3, DRAM4. Each of these different memory modules have different
[29:37.580 --> 29:44.940]  parameters or configuration that needs to be done in order to be used. And the SPD has been
[29:44.940 --> 29:52.480]  created as a standard way for a replaceable memory module to provide this information to the system
[29:52.910 --> 29:57.060]  so that the system knows how to talk to the memory module and use it.
[29:58.240 --> 30:06.200]  So the SPD is essentially a tiny EEPROM on those DRAM memory modules. It includes
[30:06.200 --> 30:14.180]  both the memory module type, like if it's DDR2, DDR3, DDR4, as well as the size of the module
[30:14.180 --> 30:21.380]  itself. There's information about the layout of the memory module as well, including the number
[30:21.380 --> 30:30.200]  of banks, if it includes features like ECC, as well as timing and voltage requirements that are
[30:30.200 --> 30:36.180]  necessary for the system to understand, to know how to talk to and use this memory module.
[30:36.720 --> 30:42.620]  When the system is booting up, it reads this SPD EEPROM in order to determine this information
[30:43.240 --> 30:46.160]  so that it knows how to configure the memory controller.
[30:46.860 --> 30:51.120]  Modifying certain parts of this configuration data can cause the system to not boot up anymore
[30:52.600 --> 30:58.760]  and the system just will be bricked until this module is physically removed from the system.
[30:58.760 --> 31:05.680]  In some systems, this SPD, the lower half of the SPD, which contains this critical data,
[31:05.680 --> 31:12.660]  is locked. Sometimes that's not protected though, and modifying that region can can brick the system
[31:12.660 --> 31:20.940]  or cause other unexpected behavior. But generally, the upper half of that SPD is writable and we can
[31:20.940 --> 31:25.860]  use that to store small amounts of data for payloads, such as encryption keys or other
[31:25.860 --> 31:36.460]  interesting data. So for accessing the SPD, we need to have it unlocked. It's essentially an SPD
[31:36.460 --> 31:45.280]  EEPROM that is connected over an SMBus interface. So there's an SMBus controller in the chipset
[31:45.280 --> 31:53.380]  that is used to talk to this SMBus device in the memory module. That includes a protection
[31:53.380 --> 32:01.280]  mechanism to prevent writes to it. And if that bit is set, we can't write to the SPD itself,
[32:01.280 --> 32:07.800]  but we've run into systems where that bit is not set properly. It is a very small amount of data
[32:07.800 --> 32:14.980]  that you can store things in, but there are some usage scenarios where that actually makes sense
[32:14.980 --> 32:20.280]  and you don't need a lot of data. And there are also attack scenarios where maybe bricking a
[32:20.280 --> 32:25.820]  device makes sense in the attack class. And we want to make sure that people understand that that is
[32:25.820 --> 32:31.720]  also a concern, that if you can write to this SPD, there are bricking scenarios that can
[32:32.460 --> 32:40.840]  come into play here. Next, we have USB controllers. Now, these USB controllers that could be found on
[32:40.840 --> 32:46.900]  your motherboard or part of an external PCI card that is plugged into your motherboard or part of
[32:46.900 --> 32:55.070]  an external USB-C device that is connected to your computer or M.2 modules inside your laptop.
[32:55.280 --> 33:06.400]  Some of these have updatable firmware and it's depressingly common how many of these have
[33:06.400 --> 33:14.680]  unsigned firmware updates. 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:30.780]  It doesn't have to be a USB controller. It will be actually a PCI device that exposes a USB 3.1
[33:30.780 --> 33:41.760]  interface. If you have USB-C ports on your desktop, most likely you'll have one of these PCI to USB
[33:42.420 --> 33:50.940]  components. Not necessarily all of them are PCI to USB. Some of them are USB to SATA.
[33:51.260 --> 33:58.200]  For example, there is an external hard drive enclosure that has this exact, well I won't say
[33:58.200 --> 34:05.000]  issue, but exact design which has a controller that talks over USB 3.1 on one end. On the other
[34:05.000 --> 34:10.780]  end, it talks to a SATA hard disk drive and it has updatable firmware and you can update that
[34:10.780 --> 34:18.840]  firmware from from the computer. The next demo we have is one of these USB controllers
[34:19.580 --> 34:25.860]  embedded in your motherboard that we update the firmware to include a malicious payload, in this
[34:25.860 --> 34:32.280]  case a Metasploit shellcode. So what you're going to see is a program that we have adapted to read
[34:32.280 --> 34:41.700]  the firmware from this USB controller, load it into memory and execute it. And I know it's going
[34:41.700 --> 34:50.100]  to look dumb, but we're basically we're clicking on a file that's running as admin and then we get
[34:50.380 --> 34:55.940]  a connect back in Kali. It's not dumb, I promise you. I'll show you the code right after.
[35:21.690 --> 35:29.830]  Okay, breaking down the video you just saw, on the right side that the we have a binary
[35:29.830 --> 35:37.510]  visualization of the firmware image we're writing to the device to save our payload.
[35:37.510 --> 35:44.150]  What's circled in red is the actual Metasploit code that we have in the firmware. What's colored
[35:44.150 --> 35:52.690]  black is empty space. Everything else is actual code. So you'd see there is about a third of it,
[35:52.690 --> 36:00.390]  almost half of the image. It's 128 kilobytes. Out of that, so much space is is empty for us
[36:00.390 --> 36:08.250]  to use as attackers. The fact that I put a few hundred bytes as payload for a demo looks tiny.
[36:09.930 --> 36:17.270]  If we look at the the code that we have loading this exploit, the first part gets the hidden
[36:17.270 --> 36:25.950]  bytes looking for a magic header, which is leetleet, because obviously. And once we find the
[36:25.950 --> 36:38.230]  leetleet, we fill up a buffer with the bytes from the firmware. After we have the payload,
[36:38.230 --> 36:42.370]  we're loading their payload from UEFI. But in this case, we use
[36:43.630 --> 36:49.690]  interoperability and marshalling, so there's no p invokes. Topher helped us speak this up.
[36:49.950 --> 36:55.310]  And we load them in memory and we execute them. Simple as that. All this code is going to be
[36:55.310 --> 37:01.770]  available on GitHub. Generally speaking, as an attacker, you'd break this attack into
[37:01.770 --> 37:09.750]  two distinct steps. One is hiding the payload. The second is retrieving and running it.
[37:09.750 --> 37:15.250]  When you hide it, you have to get the firmware image, incorporate your payload in the firmware
[37:15.250 --> 37:23.030]  image in bytes that will not disrupt normal behavior or functionality, and upload that
[37:23.030 --> 37:29.330]  new image to your target device or firmware. When you retrieve it, you have to read the firmware
[37:29.330 --> 37:35.690]  like any other mechanism or use the built-in mechanisms or known tools, extract your hidden
[37:35.690 --> 37:41.630]  bytes, and then do the malicious. Let's review a little bit of the attack surface from an internal
[37:41.630 --> 37:48.130]  asset perspective. You have USB controllers that are embedded in your devices that have their own
[37:48.130 --> 37:58.090]  firmware. You have PCI bridges that act as PCI to USB devices. You have trackpads and touch points
[37:58.090 --> 38:02.610]  and touchpads. If you have a ThinkPad Lenovo, it's a point. I don't know what it's called.
[38:02.610 --> 38:08.090]  You have one of those trackpads. It can have sometimes its own internal flash.
[38:08.570 --> 38:15.890]  The monitors you're using, if you ever plugged in a USB cable from your laptop to your monitor,
[38:15.890 --> 38:21.710]  just so you can use the little USB hub on the side of the monitor, if you're one of those
[38:21.710 --> 38:28.070]  blessed few that do that, then you should know that that monitor has a USB hub in it,
[38:28.070 --> 38:34.670]  and it has firmware. Most likely you can modify it from your computer. Webcams tend to have
[38:34.670 --> 38:42.370]  firmware related to them. Fingerprint readers, accelerometers, integrated sensor hubs,
[38:42.370 --> 38:49.250]  power delivery systems, power management ICs, everything you can think of that's inside your
[38:49.250 --> 38:57.830]  computer not necessarily has a separate component to hold firmware, but it most likely has some
[38:57.830 --> 39:05.670]  internal firmware either on the integrated controller or off it. You like to add something,
[39:05.670 --> 39:11.670]  Jesse? In addition to these controllers, there's also all of the endpoint devices themselves.
[39:11.670 --> 39:21.330]  There can be a wireless network card or a cellular modem, and these are often
[39:21.330 --> 39:28.930]  PCI or USB devices themselves that also have updatable firmware. In addition to the controllers,
[39:28.930 --> 39:37.670]  there's generally USB devices or PCI devices in the system itself, and then all of the other
[39:37.670 --> 39:47.960]  fun stuff that Mickey just talked about. Speaking of wireless devices and external assets,
[39:47.960 --> 39:54.540]  there is also all the stuff that you have that you can possibly plug into your computer.
[39:54.540 --> 39:58.780]  Think of all the ports you have on your machine, if it's your laptop or if it's your desktop
[39:59.500 --> 40:08.540]  or whatever device you're looking at. Whatever ports you can use, Thunderbolt 3, USB-C 3.1,
[40:08.540 --> 40:14.680]  whatever USB format it is. Proprietary connectors for docking stations. Docking stations have a lot
[40:14.680 --> 40:20.580]  of parts in them that have their own firmware. So, ask yourself, how often do you check the
[40:20.580 --> 40:25.840]  firmware on the dock that you plug your laptop to at work? And then, obviously, the over-the-air
[40:25.840 --> 40:31.760]  updates. In addition to the Bluetooth controller in the motherboard itself, you might have Bluetooth
[40:31.760 --> 40:39.080]  devices that are commonly paired with your system, like keyboards and mice and wireless headsets.
[40:39.400 --> 40:46.700]  Sometimes those have firmware as well. That's probably less likely to be an attack scenario
[40:46.700 --> 40:52.500]  because they're less universal than some of these other things that we're talking about, but it is
[40:52.500 --> 40:59.560]  something to be aware of and keep in mind. Another example that we think is something that we should
[40:59.560 --> 41:08.420]  all pay attention to is the Gigabit Ethernet. If you have a LAN port on your laptop, congratulations,
[41:08.420 --> 41:18.020]  you have a code cave. In most, I think, the almost every instance that I've encountered
[41:18.760 --> 41:27.580]  of a Gigabit region in SpyFlash on a system, it was read-write capable. I have yet to encounter
[41:27.580 --> 41:33.980]  one instance where it's, if it exists, it is read-only. This region in in SpyFlash usually
[41:33.980 --> 41:42.380]  contains the configuration data for the device. Stuff like MAC address or any other setup
[41:42.380 --> 41:47.740]  configuration that was initially set up by the vendor manufacturing the computer or
[41:48.460 --> 41:54.680]  selling it. Usually, there are two images. One is the one being used, the other one is a backup,
[41:54.680 --> 42:01.580]  and there are so many unused bytes in that region that we'll show you in a second, but it's really
[42:01.580 --> 42:10.480]  open for abuse. Now, some systems are mandated to have such things like servers, for example.
[42:10.480 --> 42:17.740]  There's no server without a network adapter connected to it, and if it's an Intel platform,
[42:17.740 --> 42:25.660]  you will find a GigE region in Spy that you can read and write from. If you have a desktop
[42:25.660 --> 42:33.580]  computer and you bought a Gigabit Ethernet card that you plug in, sometimes these devices will
[42:33.580 --> 42:41.960]  expose their internal non-volatile memory to the user over memory access. So, you would query
[42:41.960 --> 42:48.940]  the PCI device, get the PCI config space, find the base address register where the flash is mapped
[42:48.940 --> 42:54.540]  to, and then you can read and write directly to the flash over memory. There's also other discrete
[42:54.540 --> 42:59.760]  PCI devices, but we'll not talk about them right now. Let's look at an example of the GigE region
[42:59.760 --> 43:08.800]  in a HEX editor. First region would have the main data, and then we scroll past all the unused
[43:08.800 --> 43:15.620]  bytes and empty bytes, and then we get to the backup region that has the backup data, and then we
[43:15.620 --> 43:22.240]  keep looking and there's a whole bunch of other empty bytes. If we take a closer look at this
[43:22.240 --> 43:31.700]  example, which we have eight kilobytes of data, 72 and a half percent of it is not used, which is
[43:31.700 --> 43:41.780]  quite a lot of space. And if I were an attacker and I had a known point to hide payload or data
[43:41.780 --> 43:49.580]  on every common platform on the market, this would be a very, very good piece of information to have.
[43:50.060 --> 43:54.880]  But how do we access it? I mean, it's great. It's in SPI Flash, but
[43:54.880 --> 44:00.220]  how do we read and write from it? The easiest way to do this on Intel platforms is using the
[44:00.220 --> 44:07.720]  Flash programming tool. It's an internal tool that it's not supposed to be public, but you can
[44:07.720 --> 44:13.360]  find it on the internet. I'm not going to say where, but you can use it to update your BIOS
[44:13.360 --> 44:21.580]  and update your ME. Some vendors might have it in their update packages, some don't. There are
[44:21.580 --> 44:28.800]  other utilities. If you have a card made by a different brand manufacturer and you look for
[44:28.800 --> 44:35.620]  firmware updates, for example, if you have like a Broadcom card or an Intel card or any device
[44:35.620 --> 44:45.500]  whatsoever, any card that you find the firmware updates for, always, always look for the same
[44:45.500 --> 44:55.860]  updates for the same hardware on a different OEM. If Lenovo has an update for a Broadcom-based card
[44:55.860 --> 45:01.400]  and Dell has an update for the same Broadcom-based card, you would see two different
[45:01.400 --> 45:09.180]  software implementations. One of them might include a pre-existing tool that you can abuse or use to
[45:09.180 --> 45:16.300]  your advantage. Now, the best part of this, in my eyes, it's the Confused Deputy. Now, last year,
[45:16.300 --> 45:24.860]  we gave a talk about how drivers in Windows are screwed, basically, and you can abuse a lot of
[45:24.860 --> 45:32.220]  these firmware updating drivers to gain access to lower levels of the platform. And a lot, a big
[45:32.220 --> 45:41.700]  number of those would have access to IO ports. And given access to IO ports, arbitrary IO might not
[45:41.700 --> 45:48.340]  seem like a big deal at first, but once you think that, once you remember that arbitrary IO can give
[45:48.340 --> 45:54.340]  you legacy PCI access, and with legacy PCI access, you can do a lot of things like hardware sequencing
[45:54.340 --> 46:00.900]  into the SPI controller on Intel platforms, and that some of these drivers, if they are loaded
[46:00.900 --> 46:08.720]  on the system, some of these don't require you to be an admin to send them IOctals, this becomes
[46:08.720 --> 46:15.440]  more and more realistic as an attacker, from an attacker's perspective. Let's see a demo of how
[46:15.440 --> 46:23.640]  we can read and write to the GIGI region on an actual computer with a custom payload, or
[46:24.160 --> 46:32.720]  just a demo payload that we have. Here we see PowerShell prompt where we
[46:34.960 --> 46:44.650]  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:06.360]  At the end of it, we put the ICAR test string and just explanation of this might be malicious
[47:06.360 --> 47:21.720]  code or shellcode. Now we flash it. Now it's flashed, that data is on the computer now.
[47:26.780 --> 47:35.590]  We dump the new content, we're checking what's in the new content,
[47:35.590 --> 47:41.150]  to be sure we're not checking the same one we wrote, and we find our malicious payload there.
[47:42.530 --> 47:51.490]  So just to recap, we dumped the GIGI region from Spy using existing tools, modified it,
[47:51.490 --> 47:58.670]  added our own malicious payload, flashed it back onto Spy, and read it back again to make sure that
[47:58.670 --> 48:05.090]  we have the changes persist. A few tips and tricks of how you can hide your payload in firmware.
[48:05.350 --> 48:10.590]  If you have empty regions like we showed you, you can just add your payload there,
[48:10.590 --> 48:16.130]  you won't touch the firmware. Usually what happens when firmware is signed or validated,
[48:16.130 --> 48:24.210]  it will only verify the block of code, it won't verify the whole image. So if you have,
[48:24.210 --> 48:30.070]  let's say you have 128 kilobytes of SpyFlash for your controller, and the firmware image is
[48:30.610 --> 48:35.470]  60 kilobytes, the image would have a header defining where it starts, where it ends, what
[48:35.470 --> 48:40.250]  parts it includes, what segments, and it would also include all the verification fields like
[48:40.250 --> 48:48.370]  signature or cryptographic signature or CRCs or whatever is included. But past that,
[48:48.370 --> 48:52.570]  there is empty space that is not included or not defined. But when you read and write
[48:52.570 --> 48:56.510]  the firmware from the controller, it would read and write the whole chip.
[48:57.430 --> 49:04.080]  Another way is if you have unverified firmware, you can put your payload inside segments of the
[49:04.080 --> 49:11.480]  that are empty. So if someone built a firmware with a lot of padding in it,
[49:11.480 --> 49:16.980]  or there's different segments that they kept a lot of padding in there, you can abuse that
[49:16.980 --> 49:24.800]  if it's big enough. If it's not big enough, and you need a lot of small segments, you can easily
[49:24.800 --> 49:29.840]  break it down to multiple parts with magic bytes. Like we've seen in the demo before,
[49:29.840 --> 49:36.580]  you can load your shellcode with a magic byte and magic sequence of bytes and then a length
[49:36.580 --> 49:42.920]  to read from, and then you can all concatenate it later into your own shellcode and execute.
[49:43.060 --> 49:50.200]  For this talk, we're going to release some code on GitHub, and it will give you the capability of
[49:50.200 --> 49:56.780]  doing a lot of things low-level again, but with specifically reading and writing firmware.
[49:56.780 --> 50:01.840]  The practicality is that a lot of people are probably saying, well, what's the point? You
[50:01.840 --> 50:07.200]  got to be admin. This is all bullshit, but not necessarily. Like we said before,
[50:07.200 --> 50:12.320]  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:24.500]  Another point to mention is this scenario is relevant if you already have execution on the
[50:24.500 --> 50:30.220]  target. There's no point of gaining persistence or hiding your payload if you're just getting
[50:30.220 --> 50:37.600]  into the system. A big focus on the confused deputy angle is where we have a lot of signed
[50:37.600 --> 50:43.820]  drivers and signed tools and existing tools that allow you to do a bunch of actions that you
[50:43.820 --> 50:49.800]  normally wouldn't be able to. There is a lot to explore there. There are a lot of, for example,
[50:49.800 --> 50:57.080]  Dell has .NET tools that are used to communicate with the monitor and update firmware on it.
[50:57.080 --> 51:05.980]  It's not necessarily admin privileged access, but you can literally go and see how your code
[51:05.980 --> 51:14.420]  can interact with some other vendor code to communicate over USB to a device and read
[51:14.420 --> 51:20.760]  the EEPROM content on it or write to it. We are going to release some code on GitHub to
[51:21.620 --> 51:29.740]  use some existing code that we found that might help everyone to play with this even further,
[51:29.740 --> 51:36.680]  specifically in C-sharp because C-sharp is the new Java. I guess it's easier to understand.
[51:36.680 --> 51:43.200]  It's managed code. Why the hell not? In our example, we're releasing code that uses
[51:43.200 --> 51:51.920]  the PMX driver, which is included in a lot of Intel utilities. It is dating back to 1998.
[51:51.920 --> 51:58.420]  It can read and write physical memory. It can read and write debug registers, control registers,
[51:58.420 --> 52:04.800]  model-specific registers, IOs, and so much more. You can load it. If you're admin,
[52:04.800 --> 52:13.180]  you can load it in Windows and play with it. Imagine read, write everything, but not read,
[52:13.180 --> 52:18.920]  write everything that was blocked by Windows. It's confusing, I know, but its name was read,
[52:18.920 --> 52:26.560]  write everything. We will also release code that's using AceMedia tools. There is a tool
[52:26.560 --> 52:32.860]  made by, and I hope I'm not butchering your name, Stefano Moioli, and it's a tool released on
[52:32.860 --> 52:39.640]  GitHub that reads the firmware off AceMedia chipsets, very common chipsets that are found
[52:39.640 --> 52:48.060]  in a lot of places. And that code can be used to adapt calls to the driver that you can load,
[52:48.600 --> 52:55.640]  or can be adapted to write the firmware to the device. In the demo we've shown earlier, we've used
[52:55.640 --> 53:02.800]  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:14.700]  Funny story about AceMedia controllers. I bought, for the talk, I bought a couple of devices off
[53:14.700 --> 53:22.160]  Amazon. Both of them are AceMedia controllers, and I have an Intel NUC, it's called Hades Canyon,
[53:22.160 --> 53:32.240]  it's a NUC8. Anyway, I decided to plug in the Thunderbolt controller to PCI adapter that I have,
[53:32.240 --> 53:40.080]  plug in the PCI cards, and connect it to the NUC and work on the demo. And I'm like working,
[53:40.080 --> 53:45.780]  having fun, writing malicious firmware images, reading them back, writing, flashing it,
[53:45.780 --> 53:51.550]  flashing new ones, flashing backups. And then I realized I have two controllers.
[53:52.940 --> 53:59.880]  Yours truly has not noticed that I have a built-in onboard AceMedia controller in the NUC,
[53:59.880 --> 54:08.160]  I've been flashing that the whole time. Talk about a scary moment right there. So yeah,
[54:08.160 --> 54:15.080]  it's a funny story. I don't want to be all doom and gloom, but I have to be all doom and gloom here,
[54:15.080 --> 54:25.920]  because nobody is looking in the firmware. There is so much space in non-volatile memory. I mean,
[54:25.920 --> 54:32.120]  if you look at it in bytes, it's not a lot of bytes, but it's a lot of bytes that are not
[54:32.120 --> 54:46.450]  supervised. Is EDR catching up? Well, yes and no. Microsoft Defender has released a couple months
[54:46.450 --> 54:53.150]  ago, a press release and notification that they are now looking into the UEFI file system,
[54:53.150 --> 55:02.370]  which is awesome. But why just UEFI? There's so many other places on the platform that you
[55:02.370 --> 55:08.690]  can look into. I mean, great. We have EDR is coming, hide your shit talk last year,
[55:08.690 --> 55:14.050]  where Topher and Mike showed that they can hide malicious payloads in UEFI variables.
[55:14.250 --> 55:19.310]  And then less than a year later, all of a sudden EDR is looking in UEFI variables,
[55:19.310 --> 55:26.250]  but that's just the tip of the iceberg, right? We have solutions coming out. Like we know
[55:26.250 --> 55:34.910]  Dell has a BIOS scanner, CrowdStrike scans firmware, HP has their own hardware, the SureStart
[55:34.910 --> 55:41.310]  solution that is literally a hardware root of trust on the platform that scans BIOS,
[55:41.310 --> 55:46.870]  verifies the BIOS image, verifies a lot of parts in it, including all the Intel parts as well,
[55:46.870 --> 55:55.190]  BootGuard, BIOSGuard, all kinds of solutions. We have open source firmware solutions that allow
[55:55.190 --> 56:02.470]  you to update to legitimate images to make sure that you're up to date and check by Richard Hughes.
[56:02.470 --> 56:11.230]  But beyond the BIOS, beyond the firmware on the SPI, big parts of the firmware on the SPI,
[56:11.230 --> 56:16.970]  no one's doing anything. There is external devices firmware and internal devices firmware,
[56:16.970 --> 56:21.370]  and a lot of stuff that you can see in the volatility reports that do not
[56:21.990 --> 56:27.390]  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:52.730]  What can we do about it? We can use OEM tools or vendor tools to read the storage, to access
[56:52.730 --> 56:59.810]  whatever non-volatile components we have on the platform. If they exist, some tools exist,
[56:59.810 --> 57:09.050]  we can hack some sort of interface to vendor tools or we can adapt existing tools like open
[57:09.050 --> 57:18.950]  source code from Stefano and the SASM tool on GitHub or Chipset that allows us to access the
[57:18.950 --> 57:27.670]  CMOS, GIGI, SPI, SPD, a lot of things that we can do there. And maybe we can add open source tools
[57:28.230 --> 57:34.770]  that check for everyone's safety and help notify vendors that not only do you have to verify the
[57:34.770 --> 57:40.710]  firmware image, but you also need to check all the unused space on firmware on your non-volatile
[57:40.710 --> 57:47.490]  device just to see that you're not being abused here. And with that, we've reached the end of our
[57:47.490 --> 57:54.170]  presentation. Thank you for bearing with us and watching the slides while we talk. If you have
[57:54.170 --> 57:59.950]  any further questions that you'd like to ask us, feel free to reach out on Twitter, Discord,
[57:59.950 --> 58:05.470]  Slack, whatever will be available to answer questions for this talk on the DEF CON Discord
[58:05.470 --> 58:11.290]  server. But feel free to ping us later on social media if you have any questions.