start	end	text
1620	3180	Hello? Is this thing on?
4680	10140	Hi, everyone. Welcome to our talk, Bites in Disguise. If you happen to watch this
10140	14940	as it's being released by DEF CON, we want to thank you for tuning in on a Sunday morning.
15060	19640	You brave souls. If you're watching this on YouTube at some point later on,
19640	23140	well, thank you, you lazy f**ks. My name is Mickey.
23160	24240	And I'm Jesse.
24420	29160	I'm on the left. Jesse's on the right, just so you'd know to associate our faces with our voices
29160	34420	now. We're both principal security researchers at Eclipseum, and we deal with hardware and firmware
34420	38140	on a daily basis. Now that we have all the formalities out of the way, we can start with
38140	44280	the actual talk. We'd like to start with a little bit of structure. What are we going to talk about?
44280	53040	The agenda and high level. We want you to understand the background and the why,
53040	56800	because it's very important for you to see things from a different viewpoint,
56800	62320	our own viewpoint. We hope that by showing you what motivated us to look into this research,
62320	67560	you'll be able to understand and maybe go out on your own and explore this yourselves.
68040	73880	Once we've established that, we can show you what we did from an attack surface perspective,
74380	78040	how we look at things from a hardware firmware perspective.
78920	85000	After that, we can continue and walk you through some of the hiding places inside computers,
85000	91520	servers, laptops, or any other computer platform. We thought about the best way to do this and we
91520	98100	decided that it will be best if we start explaining each hiding spot and immediately after that,
98100	106120	go through the attack surface scenarios and examples for that spot. Once that's all done,
106120	112620	we'll discuss a little bit of what's in store for these types of threats in the future of the
112620	118520	security industry and what can we do to protect against them. In the past, we've seen a lot of
118520	126940	research talking about bad devices being abused like bad USB, rubber duckies, OMG cables, which
126940	136680	are the best cables, all these malicious devices, dropping code, executing it from a separate device,
136680	143940	hiding things off the platform. But the main issue is persistence. If your payload has to be
143940	150360	plugged into the target to replay every time, even if it still stays undetectable, having a thumb drive
150360	156060	stick out of your computer would be noticed by a user. You can't really hide that. So what if you
156060	162460	could have your loader persistent and just have the payload itself, that's the malicious code,
162460	167820	stored somewhere in your device. The easiest things to find about this type of
167820	172660	research that was done in the past is fileless malware and fileless exploits and in-memory
172660	180040	execution and anything that doesn't touch disk. And remember, don't touch disk. And one of those
180040	187880	examples is a talk that was done last year at DEF CON by Topher and Mike that discussed about
187880	193960	abusing this exact thing in UEFI variable. We usually describe this in the slide and say,
193960	198400	look, past research done this and that. But since we know these guys, we thought we'd just
198400	203300	ask them and record them and just replay it for you guys. So here's Topher and Mike.
203620	207360	Topher is the left in the picture and Mike is on the right. So I hope you enjoy and help us
207360	213680	embarrass them. Hey, I'm Topher Timson. Hey, I'm Michael Lebowitz. Last year at DEF CON,
213680	218660	Mike and I gave a talk entitled EDR is coming, hide your shit. The reason that we did this
218660	223660	research and gave this presentation is because we've been red teaming for a number of years now,
223660	229540	and we were running into the problem that a lot of our malicious payloads and our malware were
229540	236020	being eaten up by whether it be AV solutions or EDR solutions. And the blue team was discovering
236020	241140	us and ruining our engagements. And, you know, when your lovingly crafted payload becomes some
241140	247740	analyst sample, everyone's going to have a bad evening. So in looking at new areas in which we
247740	255060	could hide our shit, we effectively wanted to get off of disk. The rationale for this was because
255060	262440	having things on disk leaves it vulnerable to AV scanning it. It allows analysts to look at
262440	269840	hashes of the binaries. The EDR solution sees that they're executing these binaries and all
269840	275460	the activity that they're doing is shown to the analyst in whatever EDR platforms console they're
275460	284320	using. In looking at ways to hide our shit, we looked into UEFI. So I used to do some UEFI
284320	290900	security research. So I was already somewhat familiar with how UEFI worked as this firmware
290900	298420	platform. And variables are something that were exposed after boot services. So they were available
298420	306500	at runtime and actually booting the platform. Windows 10 re-added a UEFI API that allowed you
306500	312880	to read and write UEFI firmware variables. And I had already known, or at least I had suspected,
312880	320220	that EDR platforms were not at all scanning the UEFI firmware variable space in NVRAM. Everything
320220	324480	that we had seen, it was all about what's on the hard drive, what's being executed from the hard
324480	331580	drive, and we saw no notion of anything having to do with firmware. So we put our payload there,
331580	337240	and lo and behold, analysts were completely blind and the EDR solution and AV solutions never saw
337240	342500	our actual malicious payloads. They would see the binaries that we dropped on disk that would
342500	348060	execute the payloads out of the UEFI variable, but those are seemingly benign and they're like
348060	355860	four kilobyte binaries. In our talk, I handled the Windows platform piece, and my C-sharp binary
355860	363500	to do reflective loading of a UEFI variable is like 15 lines of code, and nobody sees it at all
363500	368540	in their UEFI platforms at the time. A couple of vendors have added some mitigations to this
368540	374560	and are seemingly less blind, but it's still a problem facing a lot of these security solutions
374560	381980	where if you hide stuff off of disk, they're not seen. As ever said, we want to muddy the
381980	387360	water for analysis, and the analysis is highly correlated to the process image that you're
387360	393840	running, and UEFI is an area that we're both familiar with, and UEFI access is available
393840	400740	in Ring 3, and anytime you have delegated access in Ring 3 to something that is like a system
400740	405700	firmware component, you're in for a good time. And I had previously done some research where I
405700	412800	put malicious content into a RAM disk, and so now I had done this such that the malicious content was
412800	420120	essentially benign and a very simple loader that could load the end payload from UEFI and then
420120	428000	persist across the RAM disk boundary and then infect the EDR platform on the host system. So in
428000	436180	total, a three-stage payload system with only one part, the tiniest loader on disk, but
436180	442660	in a sort of awkward place in disk that's hard to find. And the whole rationale behind this was
442660	448540	making it easier for offensive security practitioners and people on red teams to evade
448540	455800	detection, because anytime you execute something to get that initial access, that will leave a lot
455800	463940	of traces, particularly in EDR. But we were all about reducing that threat to detection for us
463940	469580	after the fact, and by hiding your shit in places that these platforms are blind to, you can persist
469580	474980	for longer. And in reality, what we're really trying to do is bring net happiness to the world,
474980	479340	because we're now happy that we can persist for longer and run our engagements for longer,
479340	484040	but the blue team's also happy because they don't have to work till midnight hunting us down.
484040	490900	It's true as it is now, it was then, we need to flatten the curve, the curve of risk of you being
490900	495280	detected over time. But no good thing lasts forever, and eventually your breach is going to
495280	500920	get detected. But we just want that to go a little bit longer. Thank you Topher and Mike for that
500920	506520	amazing summary. Just to recap some of the things that we want to emphasize here is, we want to
506520	513460	avoid detection, we want to make it harder for forensic analysts to find our payload, we want to
513460	519300	have code caves that we can abuse later on. Basically storing anything in non-conventional
519300	526980	storage that the analysts are not looking at, hiding their blind spots. A little bit about
526980	533900	UEFI variables. We've seen last year, we know EDR and AV have started looking into these and
533900	539960	now we've seen Microsoft adding capabilities, we'll talk about them later. But using get and
539960	548080	set variable is something that an attacker uses that is exposed by the Windows API, which is nice
548080	554910	and handy if you get that coveted admin privilege, but it's not that handy when you are worried about
555440	562880	AV and EDR hooking and monitoring your behavior. So think about it like this, these API calls are
562880	569740	not commonly used and if you call them, you will raise so many red flags, you just want to hide
569740	578580	under a rock. But under the hood, these API calls are basically a Windows wrapper to
579180	585320	something called Runtime Services. UEFI-based BIOS has these function calls in memory,
585320	590840	which are called Runtime Services that are obviously, well, as the name suggests,
590840	596880	they're available during runtime, but they're only in ring zero, which means the Windows API calls
596880	604340	those Runtime Services from a ring zero context. However, if you as an attacker can get code
604340	611700	executing in ring zero, you can call those Runtime Services directly. The trick is they have
612700	617740	a magic header in memory that you can search for and then you can find the Runtime Services table
617740	623580	and then from there extrapolate the calls for setting a variable and getting a variable.
623760	628380	All that's nice and dandy in theory, but to get that running in ring zero with
628380	636220	modern protections that Windows is incorporating is going to be tricky. Okay, first step in
636220	642160	understanding what we have at our disposal is do a proper attack surface enumeration or
642160	647560	proper scoping. Let's talk about some of the ways that you can do that. First and most
647560	652420	obvious way is to get your hands on your machine and pop open the box and look at what you're
652420	660480	attacking. It can be a laptop, desktop, server, industrial controller, whatever you think
660480	665880	falls under the definition of the word computer. But whatever you do, for the love of God,
665880	670060	remember to unplug it from power before you take it apart.
671720	677160	Some of the key things to remember when you take things apart. Remember where you put the screws
677560	685700	you took out. Don't lose them. Remember which screw goes to which hole because some of them
685700	693940	are longer than the others. And for some diabolical reason, vendors tend to not adhere to the same
693940	701400	standard across devices. So while Dell laptops tend to have the same length of screws holding
701400	708500	their chassis in, some other third-party vendors would have, and I shit you not, 14 different
708500	717300	screws that have six different lengths in the bottom of the laptop. Also remember to group them
717300	723520	and label them. And if you have any static electricity, remember to dispose of it. If you
723520	729440	don't have any static electricity, you know, wristbands or anything, just YOLO and hope that
729440	737960	you don't break your machine. Once you got it open, you need to get a magnifying glass or a
737960	747140	jeweler's loop. You can pick these up at like a couple of bucks on Amazon or eBay.
747300	753760	Many computers have a lot of chips that look similar and have some very similar markings.
753760	760620	For example, spy chips made by Windbond will have very, very similar labels on them,
760620	767440	but you'd find a couple of them on the same computer and when you won't be sure what's what,
767440	772480	we recommend that you take a picture. Use your phone. You have this device that gives you
772480	777660	access to all the cat images on the internet. Use it to take pictures. If you can label the
777660	783040	pictures, label them, but just take a picture of it with your phone and save it for later.
783040	789920	I know this sounds basic. Everything I say sounds super basic, but these are things that
789920	796560	you'd wish you'd thought of at some point. I myself had written these down and it's
796560	802700	lessons learned in blood. If you're afraid to open your $1,500 laptop,
803440	807280	don't worry. Someone on the internet has probably done it for you.
807280	814440	So you need to google the shit out of teardown images. Seriously, start googling the words
814440	824280	teardown or memory upgrade or SSD upgrade or any of those and you'd find a lot of repair shops or
824800	832200	repair tutorials or upgrade tutorials online that have HD videos and images of the computers you're
832200	839840	looking at. You might not be able to go down to the very low resolution of what chip is what in
839840	850440	what capacity, but you'll be able to get a sense of how many exist or how many you can risk opening
850440	857400	your laptop for. If you open it and it's only like a BIOS chip and one more versus six others that
857400	867300	you suspect might be holding firmware, then your risk assessment about opening it might change.
867320	874740	One more option is look for schematics. Now, it's a bit of a weird adventure and you'll find
874740	883280	yourself entering the world of repair shops and schematics websites in Vietnam, but you'd be able
883280	891020	to find a lot of PDFs that describe how devices interconnect including non-volatile and firmware
891020	897960	storage devices. You might be finding a lot of EEPROMs that are on the board and the schematics
897960	903160	will tell you exactly what address you need to communicate with to read or write from,
903160	910440	which SMBus line has what controller allows you. It will basically allow you to understand
910440	917320	which device does what and how. I wouldn't put too much effort into this attack surface scoping
917320	925320	method because schematics tend to be confidential and secret and if you happen to find one of a
925320	933160	more recent platform, it's going to be really rare. But if you want to practice on an old one,
933540	939280	buy a laptop from eBay and see if you can find its schematics. Go ahead, go for it. You could
939280	951150	spend like 100, 200 bucks on this. My favorite part is looking for official documentation.
951150	958650	And the biggest tip we could give you for looking for those is statement of volatilities or
958650	964330	declarations of volatilities. The best way to do this is just google in quotes of volatility
965010	972550	and just add the file type pdf and include the words flash or cmos or spy or whatever from
972550	976930	keywords that you can find from other documents you will find in the process.
977110	986730	These documents basically state what volatile and non-volatile components are in a platform. Now,
986730	993150	not every computer has this type of document associated with it, but from finding these
993690	1001410	documents online, you can understand what is in most common platforms. Some of these documents
1002970	1011830	contain hilarities like this one saying 128 bytes are protected by intel. The other 128 bytes are
1011830	1019730	not right protected. So what the shit? Why would you put this in a document that tells me
1020180	1027830	I have 256 bytes of non-volatile storage? Half of it's protected. The other half's not.
1027830	1032650	Go have fun. Okay, we have a demo about that.
1034210	1040330	Now, I wanted to put a picture of the pdf here, but I couldn't find a good enough resolution so
1040330	1050730	I had to crop a snippet of the table. And the table that you see here is somewhat a representation
1050730	1059410	of what you'll see in a statement of volatility document. You'll see a breaking down by type,
1059410	1065470	size, if it's volatile, non-volatile, what's it used for, how to clear it. Sometimes it's not
1065470	1070570	going to be documented on how to clear it or not. Sometimes it will be. There's sometimes in some
1070570	1078450	platforms jumpers you need to remove and and put back. But the key point that I want to tell you
1078450	1086590	here is even though you see documents saying is this user modifiable? Yes and no. You never know
1086590	1095130	if it means is it user space modifiable or is it modifiable from a user at all. And whatever you do,
1095470	1101410	as a rule to live by, always challenge the basic assumptions that you encounter
1101410	1106670	in official documentation. Especially some that you can prove easily wrong. I can tell you
1106670	1110650	that even though some of these are not saying it's not user modifiable,
1111410	1115890	you will see in a few minutes a demo saying that it is.
1117150	1121810	Yeah, to follow up on that a little, user modifiable in this case means that
1121810	1127950	it's intended to be presented to the user to be demodifiable like the BIOS password.
1127950	1135250	The user is intended to be able to modify this. But system software or other software running on
1135250	1141450	this on the device could be modifying these components. It just is not making that directly
1141450	1145510	accessible to the customer. It doesn't mean that it's not modifiable at all.
1145530	1151130	Now that we showed you a way or multiple ways to find information and explore it by yourself,
1151130	1155590	we can go ahead and start diving a little bit deeper into some individual components
1155590	1160590	that we talked about before. We'll go through them one at a time and we'll describe them.
1160590	1166170	And then we'll later proceed into explaining what the pros and cons are from an attacker's
1166170	1174640	perspective. And hopefully we can have fun while doing it. First things first, remember that 128
1174640	1182840	byte that we saw before? If we looked at the CMOS example in the previous slide, it said
1183440	1189900	it's not user modifiable. And I know Jesse explained that it's what the user can modify
1189900	1198780	sometimes by using a GUI like the BIOS password. But I wanted to emphasize that whatever the
1198780	1203460	document says doesn't literally mean what you think it means. You need to go double check.
1205240	1214120	So basically, back to the CMOS topic. If you are young and you have no idea what CMOS stands for,
1214120	1220720	I am jealous. If you are somewhat old and you had to remove a battery from your computer
1220720	1231060	motherboard, my heart's with you. It's really a relic that's used to have settings set for
1231060	1238280	BIOS bring up, for the system bring up. It's a tiny bit of non-volatile RAM
1239120	1244960	that is only non-volatile as long as their current and that current is supplied by the
1244960	1251600	little lithium battery on the motherboard. The main thing I've seen this used is the
1251600	1259960	real-time clock. So you know how you have a power surge and the microwave clock goes out,
1259960	1265420	but your computer has the same clock afterwards? Probably because it keeps that real-time clock
1265420	1272700	timer going internally. In modern platforms, the CMOS is located inside the chipset.
1272700	1279060	So you really can't see it. It's it's itty-bitty. Not like other chips that we're going to talk
1279060	1289780	about later. The pros of CMOS is that it has a few unused bytes. You can access it through
1290540	1298100	IO ports. You can do in-and-out instructions to get to it. It exists almost everywhere.
1299000	1307780	The cons are that it's super tiny. It only contains 256 bytes separated to two regions,
1307780	1315880	lower CMOS and upper CMOS. If you mess up the wrong bytes, you might cause yourself some trouble
1315880	1323800	and you might need to reset the CMOS or fuck up the platform. We don't know exactly what each
1324700	1330020	modification of each bit might might do, but it's well documented. And then if you
1330020	1334440	want to go to explore what you can do with it, it's all over Wikipedia.
1335640	1343700	One other thing that we we think might happen is that if there are certain PCR measurements done
1343700	1352760	by TPM, modifying CMOS might trigger an alert. For example, BitLocker has PCRs it's monitoring
1353380	1357880	and if those PCR change, then it goes into BitLocker recovery mode.
1358820	1364840	In short, we're pretty sure you can you can have fun with this, but don't mess up bytes that are
1364840	1376280	not zero. So you don't think we're full of shit? Here's a short demo of how to abuse CMOS.
1376320	1382720	In the demo you're about to see, we have the steps written on the right. Basically,
1382720	1392180	we read the CMOS, we write a random payload to the lower part of CMOS, you read it, so we show
1392180	1398040	you that there is a change there. We restore it back and then we read it again to show that we
1398040	1443280	changed it back. Let's go and run the demo. We're going to have the code for this demo up on GitHub
1443280	1448000	after the talk is published and keep an eye on that GitHub because we're going to keep adding
1448380	1456920	more and more code to it as we go on. So let's take a look at SpyFlash. In order to know where
1456920	1464360	to start executing code from in the first place, that code is stored in the SpyFlash and when the
1464360	1470820	system turns on it starts executing instructions from there. Traditionally that was known as BIOS,
1470820	1476820	but these days almost all systems have transitioned over to using a UEFI firmware instead
1477640	1483180	and this firmware is stored in the SpyFlash. There's a few different regions within the
1483180	1489580	SpyFlash. If you have an Intel platform, you'll have a region for the manageability engine or the
1489580	1496860	ME. It's also known as the CSME. AMD platforms will have a PSP region for the platform security
1496860	1502580	controller. There's also a flash descriptor which contains essentially a map for how the
1502580	1507920	contents of the SpyFlash are organized as well as access permissions for these regions.
1510220	1515760	So taking a look at the the contents of the SpyFlash itself, there's a couple constraints
1515760	1523080	that determine the location of a couple of the regions in there. First, when the system boots up,
1523080	1527920	the top of that SpyFlash is mapped to the top of the four gigabyte address space
1527920	1535840	in order for the x86 reset vector to start executing code from there. Because of this,
1535840	1542480	the top of the BIOS region needs to correspond to the top of the SpyFlash. It can vary in size. So
1543000	1552920	you can have a eight meg BIOS region or a four meg BIOS region. The size can vary,
1552920	1558620	but the top of that region needs to correspond to the top of the spy chip itself.
1559940	1564840	Additionally, the flash descriptor region, which is essentially the map and permissions
1564840	1571160	and what is actually stored throughout the spy chip, that starts at the beginning of of the
1571160	1579560	SpyFlash. It contains some platform configuration for the device as well as the map determining
1579560	1586380	where these regions are stored within the SpyFlash itself. There can be some additional regions like
1586380	1594340	the ME region. Some platforms will have a GigE region or an embedded controller region. There
1594340	1602340	can be a platform data region which is for OEM specific additional components. The region mapping
1602340	1608120	in the flash descriptor also doesn't need to include all of the contents of the spy region.
1608120	1614380	So there can be some padding regions or padding areas that aren't actually included in the map
1614900	1623120	as well. To take a look at the flash descriptor itself, starting at the very beginning of the spy
1623120	1632720	contents, there's a signature at 10 hex, offset 10 hex, that is used to determine if there is a
1632720	1639380	flash descriptor in this area. And then there's a mapping, there's a variety of different components
1639920	1645740	and access control lists to determine if the CPU has access to read and write of a particular spy
1645740	1653100	region, or the ME has access to read and write to a particular spy region, or the NIC, the GigE
1653100	1658640	controller has access to read and write directly to that spy region. So those access controls
1658640	1667380	are stored in the flash descriptor. So there are a lot of cases where the CPU can't
1667380	1673580	directly read and write to the ME region. And most systems these days will have that BIOS region
1673580	1680020	protected via hardware mechanisms in the chipset. Occasionally we run into systems where
1680020	1684820	that is still not protected properly and you can just directly write to the spy and BIOS region
1685900	1692290	from code running on the CPU. But even in the case that that BIOS region is properly protected,
1694000	1699760	there can be bugs in the BIOS update mechanism itself. Sometimes that doesn't provide signature
1699760	1708800	verification. Sometimes it will do signature verification for part of the region but still copy
1708800	1717660	data into that spy flash for you. However, the gigabit region itself is generally unprotected
1717660	1724680	and you have full read and write access to that from the CPU. We also sometimes run into cases where
1725080	1730500	the flash descriptor itself has incorrect permissions and that can be rewritten via
1730500	1738520	software to modify the existing region definitions or even define new regions in the spy flash layout
1738520	1745500	and change the permissions for those regions. So if you have that issue, there's a lot of ways
1745500	1751460	that you can take advantage of that. Another interesting storage location is the SPD or
1751460	1758620	Serial Presence Detect chip in DRAM memory modules. Although some recent devices like
1758620	1762880	laptops and tablets only have soldered down memory which is not replaceable,
1762880	1768020	the vast majority of systems include replaceable memory. There are a lot of different types of
1768020	1777580	memory. There's a DRAM2, DRAM3, DRAM4. Each of these different memory modules have different
1777580	1784940	parameters or configuration that needs to be done in order to be used. And the SPD has been
1784940	1792480	created as a standard way for a replaceable memory module to provide this information to the system
1792910	1797060	so that the system knows how to talk to the memory module and use it.
1798240	1806200	So the SPD is essentially a tiny EEPROM on those DRAM memory modules. It includes
1806200	1814180	both the memory module type, like if it's DDR2, DDR3, DDR4, as well as the size of the module
1814180	1821380	itself. There's information about the layout of the memory module as well, including the number
1821380	1830200	of banks, if it includes features like ECC, as well as timing and voltage requirements that are
1830200	1836180	necessary for the system to understand, to know how to talk to and use this memory module.
1836720	1842620	When the system is booting up, it reads this SPD EEPROM in order to determine this information
1843240	1846160	so that it knows how to configure the memory controller.
1846860	1851120	Modifying certain parts of this configuration data can cause the system to not boot up anymore
1852600	1858760	and the system just will be bricked until this module is physically removed from the system.
1858760	1865680	In some systems, this SPD, the lower half of the SPD, which contains this critical data,
1865680	1872660	is locked. Sometimes that's not protected though, and modifying that region can can brick the system
1872660	1880940	or cause other unexpected behavior. But generally, the upper half of that SPD is writable and we can
1880940	1885860	use that to store small amounts of data for payloads, such as encryption keys or other
1885860	1896460	interesting data. So for accessing the SPD, we need to have it unlocked. It's essentially an SPD
1896460	1905280	EEPROM that is connected over an SMBus interface. So there's an SMBus controller in the chipset
1905280	1913380	that is used to talk to this SMBus device in the memory module. That includes a protection
1913380	1921280	mechanism to prevent writes to it. And if that bit is set, we can't write to the SPD itself,
1921280	1927800	but we've run into systems where that bit is not set properly. It is a very small amount of data
1927800	1934980	that you can store things in, but there are some usage scenarios where that actually makes sense
1934980	1940280	and you don't need a lot of data. And there are also attack scenarios where maybe bricking a
1940280	1945820	device makes sense in the attack class. And we want to make sure that people understand that that is
1945820	1951720	also a concern, that if you can write to this SPD, there are bricking scenarios that can
1952460	1960840	come into play here. Next, we have USB controllers. Now, these USB controllers that could be found on
1960840	1966900	your motherboard or part of an external PCI card that is plugged into your motherboard or part of
1966900	1975070	an external USB-C device that is connected to your computer or M.2 modules inside your laptop.
1975280	1986400	Some of these have updatable firmware and it's depressingly common how many of these have
1986400	1994680	unsigned firmware updates. And you as an attacker can store whatever payload you want on them.
1994680	2003640	For example, we can have not just USB controllers that exist as USB bridges or on your motherboard.
2003640	2010780	It doesn't have to be a USB controller. It will be actually a PCI device that exposes a USB 3.1
2010780	2021760	interface. If you have USB-C ports on your desktop, most likely you'll have one of these PCI to USB
2022420	2030940	components. Not necessarily all of them are PCI to USB. Some of them are USB to SATA.
2031260	2038200	For example, there is an external hard drive enclosure that has this exact, well I won't say
2038200	2045000	issue, but exact design which has a controller that talks over USB 3.1 on one end. On the other
2045000	2050780	end, it talks to a SATA hard disk drive and it has updatable firmware and you can update that
2050780	2058840	firmware from from the computer. The next demo we have is one of these USB controllers
2059580	2065860	embedded in your motherboard that we update the firmware to include a malicious payload, in this
2065860	2072280	case a Metasploit shellcode. So what you're going to see is a program that we have adapted to read
2072280	2081700	the firmware from this USB controller, load it into memory and execute it. And I know it's going
2081700	2090100	to look dumb, but we're basically we're clicking on a file that's running as admin and then we get
2090380	2095940	a connect back in Kali. It's not dumb, I promise you. I'll show you the code right after.
2121690	2129830	Okay, breaking down the video you just saw, on the right side that the we have a binary
2129830	2137510	visualization of the firmware image we're writing to the device to save our payload.
2137510	2144150	What's circled in red is the actual Metasploit code that we have in the firmware. What's colored
2144150	2152690	black is empty space. Everything else is actual code. So you'd see there is about a third of it,
2152690	2160390	almost half of the image. It's 128 kilobytes. Out of that, so much space is is empty for us
2160390	2168250	to use as attackers. The fact that I put a few hundred bytes as payload for a demo looks tiny.
2169930	2177270	If we look at the the code that we have loading this exploit, the first part gets the hidden
2177270	2185950	bytes looking for a magic header, which is leetleet, because obviously. And once we find the
2185950	2198230	leetleet, we fill up a buffer with the bytes from the firmware. After we have the payload,
2198230	2202370	we're loading their payload from UEFI. But in this case, we use
2203630	2209690	interoperability and marshalling, so there's no p invokes. Topher helped us speak this up.
2209950	2215310	And we load them in memory and we execute them. Simple as that. All this code is going to be
2215310	2221770	available on GitHub. Generally speaking, as an attacker, you'd break this attack into
2221770	2229750	two distinct steps. One is hiding the payload. The second is retrieving and running it.
2229750	2235250	When you hide it, you have to get the firmware image, incorporate your payload in the firmware
2235250	2243030	image in bytes that will not disrupt normal behavior or functionality, and upload that
2243030	2249330	new image to your target device or firmware. When you retrieve it, you have to read the firmware
2249330	2255690	like any other mechanism or use the built-in mechanisms or known tools, extract your hidden
2255690	2261630	bytes, and then do the malicious. Let's review a little bit of the attack surface from an internal
2261630	2268130	asset perspective. You have USB controllers that are embedded in your devices that have their own
2268130	2278090	firmware. You have PCI bridges that act as PCI to USB devices. You have trackpads and touch points
2278090	2282610	and touchpads. If you have a ThinkPad Lenovo, it's a point. I don't know what it's called.
2282610	2288090	You have one of those trackpads. It can have sometimes its own internal flash.
2288570	2295890	The monitors you're using, if you ever plugged in a USB cable from your laptop to your monitor,
2295890	2301710	just so you can use the little USB hub on the side of the monitor, if you're one of those
2301710	2308070	blessed few that do that, then you should know that that monitor has a USB hub in it,
2308070	2314670	and it has firmware. Most likely you can modify it from your computer. Webcams tend to have
2314670	2322370	firmware related to them. Fingerprint readers, accelerometers, integrated sensor hubs,
2322370	2329250	power delivery systems, power management ICs, everything you can think of that's inside your
2329250	2337830	computer not necessarily has a separate component to hold firmware, but it most likely has some
2337830	2345670	internal firmware either on the integrated controller or off it. You like to add something,
2345670	2351670	Jesse? In addition to these controllers, there's also all of the endpoint devices themselves.
2351670	2361330	There can be a wireless network card or a cellular modem, and these are often
2361330	2368930	PCI or USB devices themselves that also have updatable firmware. In addition to the controllers,
2368930	2377670	there's generally USB devices or PCI devices in the system itself, and then all of the other
2377670	2387960	fun stuff that Mickey just talked about. Speaking of wireless devices and external assets,
2387960	2394540	there is also all the stuff that you have that you can possibly plug into your computer.
2394540	2398780	Think of all the ports you have on your machine, if it's your laptop or if it's your desktop
2399500	2408540	or whatever device you're looking at. Whatever ports you can use, Thunderbolt 3, USB-C 3.1,
2408540	2414680	whatever USB format it is. Proprietary connectors for docking stations. Docking stations have a lot
2414680	2420580	of parts in them that have their own firmware. So, ask yourself, how often do you check the
2420580	2425840	firmware on the dock that you plug your laptop to at work? And then, obviously, the over-the-air
2425840	2431760	updates. In addition to the Bluetooth controller in the motherboard itself, you might have Bluetooth
2431760	2439080	devices that are commonly paired with your system, like keyboards and mice and wireless headsets.
2439400	2446700	Sometimes those have firmware as well. That's probably less likely to be an attack scenario
2446700	2452500	because they're less universal than some of these other things that we're talking about, but it is
2452500	2459560	something to be aware of and keep in mind. Another example that we think is something that we should
2459560	2468420	all pay attention to is the Gigabit Ethernet. If you have a LAN port on your laptop, congratulations,
2468420	2478020	you have a code cave. In most, I think, the almost every instance that I've encountered
2478760	2487580	of a Gigabit region in SpyFlash on a system, it was read-write capable. I have yet to encounter
2487580	2493980	one instance where it's, if it exists, it is read-only. This region in in SpyFlash usually
2493980	2502380	contains the configuration data for the device. Stuff like MAC address or any other setup
2502380	2507740	configuration that was initially set up by the vendor manufacturing the computer or
2508460	2514680	selling it. Usually, there are two images. One is the one being used, the other one is a backup,
2514680	2521580	and there are so many unused bytes in that region that we'll show you in a second, but it's really
2521580	2530480	open for abuse. Now, some systems are mandated to have such things like servers, for example.
2530480	2537740	There's no server without a network adapter connected to it, and if it's an Intel platform,
2537740	2545660	you will find a GigE region in Spy that you can read and write from. If you have a desktop
2545660	2553580	computer and you bought a Gigabit Ethernet card that you plug in, sometimes these devices will
2553580	2561960	expose their internal non-volatile memory to the user over memory access. So, you would query
2561960	2568940	the PCI device, get the PCI config space, find the base address register where the flash is mapped
2568940	2574540	to, and then you can read and write directly to the flash over memory. There's also other discrete
2574540	2579760	PCI devices, but we'll not talk about them right now. Let's look at an example of the GigE region
2579760	2588800	in a HEX editor. First region would have the main data, and then we scroll past all the unused
2588800	2595620	bytes and empty bytes, and then we get to the backup region that has the backup data, and then we
2595620	2602240	keep looking and there's a whole bunch of other empty bytes. If we take a closer look at this
2602240	2611700	example, which we have eight kilobytes of data, 72 and a half percent of it is not used, which is
2611700	2621780	quite a lot of space. And if I were an attacker and I had a known point to hide payload or data
2621780	2629580	on every common platform on the market, this would be a very, very good piece of information to have.
2630060	2634880	But how do we access it? I mean, it's great. It's in SPI Flash, but
2634880	2640220	how do we read and write from it? The easiest way to do this on Intel platforms is using the
2640220	2647720	Flash programming tool. It's an internal tool that it's not supposed to be public, but you can
2647720	2653360	find it on the internet. I'm not going to say where, but you can use it to update your BIOS
2653360	2661580	and update your ME. Some vendors might have it in their update packages, some don't. There are
2661580	2668800	other utilities. If you have a card made by a different brand manufacturer and you look for
2668800	2675620	firmware updates, for example, if you have like a Broadcom card or an Intel card or any device
2675620	2685500	whatsoever, any card that you find the firmware updates for, always, always look for the same
2685500	2695860	updates for the same hardware on a different OEM. If Lenovo has an update for a Broadcom-based card
2695860	2701400	and Dell has an update for the same Broadcom-based card, you would see two different
2701400	2709180	software implementations. One of them might include a pre-existing tool that you can abuse or use to
2709180	2716300	your advantage. Now, the best part of this, in my eyes, it's the Confused Deputy. Now, last year,
2716300	2724860	we gave a talk about how drivers in Windows are screwed, basically, and you can abuse a lot of
2724860	2732220	these firmware updating drivers to gain access to lower levels of the platform. And a lot, a big
2732220	2741700	number of those would have access to IO ports. And given access to IO ports, arbitrary IO might not
2741700	2748340	seem like a big deal at first, but once you think that, once you remember that arbitrary IO can give
2748340	2754340	you legacy PCI access, and with legacy PCI access, you can do a lot of things like hardware sequencing
2754340	2760900	into the SPI controller on Intel platforms, and that some of these drivers, if they are loaded
2760900	2768720	on the system, some of these don't require you to be an admin to send them IOctals, this becomes
2768720	2775440	more and more realistic as an attacker, from an attacker's perspective. Let's see a demo of how
2775440	2783640	we can read and write to the GIGI region on an actual computer with a custom payload, or
2784160	2792720	just a demo payload that we have. Here we see PowerShell prompt where we
2794960	2804650	dump the GIGI region, and then we clear the screen, we show that the end of it has nothing but Fs.
2807340	2813340	Now we're going to flash a malicious version, well, so-called malicious, just for demo purposes.
2818520	2826360	At the end of it, we put the ICAR test string and just explanation of this might be malicious
2826360	2841720	code or shellcode. Now we flash it. Now it's flashed, that data is on the computer now.
2846780	2855590	We dump the new content, we're checking what's in the new content,
2855590	2861150	to be sure we're not checking the same one we wrote, and we find our malicious payload there.
2862530	2871490	So just to recap, we dumped the GIGI region from Spy using existing tools, modified it,
2871490	2878670	added our own malicious payload, flashed it back onto Spy, and read it back again to make sure that
2878670	2885090	we have the changes persist. A few tips and tricks of how you can hide your payload in firmware.
2885350	2890590	If you have empty regions like we showed you, you can just add your payload there,
2890590	2896130	you won't touch the firmware. Usually what happens when firmware is signed or validated,
2896130	2904210	it will only verify the block of code, it won't verify the whole image. So if you have,
2904210	2910070	let's say you have 128 kilobytes of SpyFlash for your controller, and the firmware image is
2910610	2915470	60 kilobytes, the image would have a header defining where it starts, where it ends, what
2915470	2920250	parts it includes, what segments, and it would also include all the verification fields like
2920250	2928370	signature or cryptographic signature or CRCs or whatever is included. But past that,
2928370	2932570	there is empty space that is not included or not defined. But when you read and write
2932570	2936510	the firmware from the controller, it would read and write the whole chip.
2937430	2944080	Another way is if you have unverified firmware, you can put your payload inside segments of the
2944080	2951480	that are empty. So if someone built a firmware with a lot of padding in it,
2951480	2956980	or there's different segments that they kept a lot of padding in there, you can abuse that
2956980	2964800	if it's big enough. If it's not big enough, and you need a lot of small segments, you can easily
2964800	2969840	break it down to multiple parts with magic bytes. Like we've seen in the demo before,
2969840	2976580	you can load your shellcode with a magic byte and magic sequence of bytes and then a length
2976580	2982920	to read from, and then you can all concatenate it later into your own shellcode and execute.
2983060	2990200	For this talk, we're going to release some code on GitHub, and it will give you the capability of
2990200	2996780	doing a lot of things low-level again, but with specifically reading and writing firmware.
2996780	3001840	The practicality is that a lot of people are probably saying, well, what's the point? You
3001840	3007200	got to be admin. This is all bullshit, but not necessarily. Like we said before,
3007200	3012320	some drivers, if they exist on the system, they can be accessed from user space.
3012600	3016920	So all you have to do is just see if the device exists and send it iOctals.
3016980	3024500	Another point to mention is this scenario is relevant if you already have execution on the
3024500	3030220	target. There's no point of gaining persistence or hiding your payload if you're just getting
3030220	3037600	into the system. A big focus on the confused deputy angle is where we have a lot of signed
3037600	3043820	drivers and signed tools and existing tools that allow you to do a bunch of actions that you
3043820	3049800	normally wouldn't be able to. There is a lot to explore there. There are a lot of, for example,
3049800	3057080	Dell has .NET tools that are used to communicate with the monitor and update firmware on it.
3057080	3065980	It's not necessarily admin privileged access, but you can literally go and see how your code
3065980	3074420	can interact with some other vendor code to communicate over USB to a device and read
3074420	3080760	the EEPROM content on it or write to it. We are going to release some code on GitHub to
3081620	3089740	use some existing code that we found that might help everyone to play with this even further,
3089740	3096680	specifically in C-sharp because C-sharp is the new Java. I guess it's easier to understand.
3096680	3103200	It's managed code. Why the hell not? In our example, we're releasing code that uses
3103200	3111920	the PMX driver, which is included in a lot of Intel utilities. It is dating back to 1998.
3111920	3118420	It can read and write physical memory. It can read and write debug registers, control registers,
3118420	3124800	model-specific registers, IOs, and so much more. You can load it. If you're admin,
3124800	3133180	you can load it in Windows and play with it. Imagine read, write everything, but not read,
3133180	3138920	write everything that was blocked by Windows. It's confusing, I know, but its name was read,
3138920	3146560	write everything. We will also release code that's using AceMedia tools. There is a tool
3146560	3152860	made by, and I hope I'm not butchering your name, Stefano Moioli, and it's a tool released on
3152860	3159640	GitHub that reads the firmware off AceMedia chipsets, very common chipsets that are found
3159640	3168060	in a lot of places. And that code can be used to adapt calls to the driver that you can load,
3168600	3175640	or can be adapted to write the firmware to the device. In the demo we've shown earlier, we've used
3175640	3182800	Stefano's code to read the payload from the firmware and execute it in our own custom program.
3182800	3189160	We also used update tools from AceMedia to write the malicious firmware into the device.
3189160	3194700	Funny story about AceMedia controllers. I bought, for the talk, I bought a couple of devices off
3194700	3202160	Amazon. Both of them are AceMedia controllers, and I have an Intel NUC, it's called Hades Canyon,
3202160	3212240	it's a NUC8. Anyway, I decided to plug in the Thunderbolt controller to PCI adapter that I have,
3212240	3220080	plug in the PCI cards, and connect it to the NUC and work on the demo. And I'm like working,
3220080	3225780	having fun, writing malicious firmware images, reading them back, writing, flashing it,
3225780	3231550	flashing new ones, flashing backups. And then I realized I have two controllers.
3232940	3239880	Yours truly has not noticed that I have a built-in onboard AceMedia controller in the NUC,
3239880	3248160	I've been flashing that the whole time. Talk about a scary moment right there. So yeah,
3248160	3255080	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,
3255080	3265920	because nobody is looking in the firmware. There is so much space in non-volatile memory. I mean,
3265920	3272120	if you look at it in bytes, it's not a lot of bytes, but it's a lot of bytes that are not
3272120	3286450	supervised. Is EDR catching up? Well, yes and no. Microsoft Defender has released a couple months
3286450	3293150	ago, a press release and notification that they are now looking into the UEFI file system,
3293150	3302370	which is awesome. But why just UEFI? There's so many other places on the platform that you
3302370	3308690	can look into. I mean, great. We have EDR is coming, hide your shit talk last year,
3308690	3314050	where Topher and Mike showed that they can hide malicious payloads in UEFI variables.
3314250	3319310	And then less than a year later, all of a sudden EDR is looking in UEFI variables,
3319310	3326250	but that's just the tip of the iceberg, right? We have solutions coming out. Like we know
3326250	3334910	Dell has a BIOS scanner, CrowdStrike scans firmware, HP has their own hardware, the SureStart
3334910	3341310	solution that is literally a hardware root of trust on the platform that scans BIOS,
3341310	3346870	verifies the BIOS image, verifies a lot of parts in it, including all the Intel parts as well,
3346870	3355190	BootGuard, BIOSGuard, all kinds of solutions. We have open source firmware solutions that allow
3355190	3362470	you to update to legitimate images to make sure that you're up to date and check by Richard Hughes.
3362470	3371230	But beyond the BIOS, beyond the firmware on the SPI, big parts of the firmware on the SPI,
3371230	3376970	no one's doing anything. There is external devices firmware and internal devices firmware,
3376970	3381370	and a lot of stuff that you can see in the volatility reports that do not
3381990	3387390	fall into the SPI BIOS regions that are not verified.
3388270	3395370	And also like this, like Microsoft's, it is Defender ATP, so it's not rolled out everywhere.
3395370	3401130	It's only that the premium version so that you need to pay more for.
3401130	3412730	What can we do about it? We can use OEM tools or vendor tools to read the storage, to access
3412730	3419810	whatever non-volatile components we have on the platform. If they exist, some tools exist,
3419810	3429050	we can hack some sort of interface to vendor tools or we can adapt existing tools like open
3429050	3438950	source code from Stefano and the SASM tool on GitHub or Chipset that allows us to access the
3438950	3447670	CMOS, GIGI, SPI, SPD, a lot of things that we can do there. And maybe we can add open source tools
3448230	3454770	that check for everyone's safety and help notify vendors that not only do you have to verify the
3454770	3460710	firmware image, but you also need to check all the unused space on firmware on your non-volatile
3460710	3467490	device just to see that you're not being abused here. And with that, we've reached the end of our
3467490	3474170	presentation. Thank you for bearing with us and watching the slides while we talk. If you have
3474170	3479950	any further questions that you'd like to ask us, feel free to reach out on Twitter, Discord,
3479950	3485470	Slack, whatever will be available to answer questions for this talk on the DEF CON Discord
3485470	3491290	server. But feel free to ping us later on social media if you have any questions.