start	end	text
0	4520	I have pushed the button. Now we're waiting on it to kick over.
6900	12620	And see, I learned I have to actually refresh this thing, because for some reason sometimes
12620	20940	the stream will just continue playing whatever source it was playing. And now it's music.
24520	26260	It's still music.
34010	40170	Let's do it. Oh, oh, oh, oh, that's looking good. Hey, there's a bunch of faces.
40670	47950	All right. Hello, DEF CON. Welcome to your early morning Sunday content.
48250	55310	My name is Fallible. We have got Jethro here. Joining us from the speaker side is
55310	62530	Mickey and Jesse with the Q&A portion for their talk of Bytes in Disguise.
65390	70050	Oh, hold on. Before I do this, I have one more button I have to push on my side.
70110	77150	Okay. So before we get going here, I guess I'd like for the two of you to tell us a little bit
77150	83230	about yourselves and your DEF CON history, because I know that neither of you are strangers to
84690	87790	the hanging out in the desert with a bunch of geeks for a weekend. So
88350	90830	tell us a little about yourselves.
93050	94370	Go ahead, Jesse.
94810	102310	Okay, I can start that. So I first started coming to DEF CON in 2003 when I was still back at the
102310	108930	Alexis Park and was playing CTF back then and ended up winning a couple black badges. So I've
108930	115450	been coming to DEF CON every year since 2003 and enjoying myself a lot and having a lot of fun
115450	122710	and ended up starting giving talks a few years ago. So I think this is number five, maybe. I
122710	125990	need to go count how many talks we've actually given, but I've had a lot of fun here.
126270	128990	Casual drop in there, a couple black badges.
131150	138270	Yeah, I'm not as acquainted with DEF CON as Jesse is. I started coming to DEF CON
138270	146350	since DEF CON 19 and been speaking since 20, except 21, I think.
147530	150430	I didn't get a black badge. I had to make my own.
152530	154630	Give a talk about that, too.
155570	164450	Yeah, I love the vibe, love the community. Great experiences, horrible stories.
165310	173030	Yeah, it sounds about right. Well, excellent. I know that Jethro over here has a lot of
173030	178630	interesting things to say about your talk. I have some interesting things to say about your talk,
178630	187050	but I'm not into the niche that you occupy. So I will be watching for some of the questions
187050	193930	that come in and maybe we'll have my fellow goon ask our initial question while I watch
193930	200390	channels. Sure. Yeah. So for me, I watched the talk and I thought it was kind of cool,
200390	205930	just the number of different places that you could actually hide information. And the joke I was
205930	209150	saying is like, you've literally covered everything from like, hey, you need to wear a wrist strap
209150	213090	when you go into this to, you know, Google hacking, like just run these searches and get this
213090	218510	information to, you know, here's how to write random chips and, you know, code release. I guess
218510	222750	like so quick 30 seconds, like what I guess what's the someone hadn't seen the talk yet? How would
222750	231310	you recap everything for them? What are the high points? Not wearing a wrist strap. Let's, let's,
231310	237730	let's do a 30 second recap for an hour talk. What's the best part they should look out for?
237730	246370	Why should they go and watch it? The demo music. Yeah, the bossanova thing. Well done.
247750	252270	No, no. Yeah. So, so really, I mean, like guys, what inspires you to take like such a complete
252270	255730	look at the attack surface, right? Like, how did you think to start to look at all these different
255730	267640	ways that you could go after devices? We both have similar perspectives, but they're slightly different.
269120	274340	What got us into this? Well, I'd say we got tired of getting caught.
276380	281780	So when we do the red team exercises or whatnot, and we want to hide our payloads and
282500	288800	we always get caught and, you know, adding in a memory and on disk and all kinds of locations.
289080	292680	And we've had a lot of experience dealing with hardware and firmware. And we thought,
292680	297160	why the hell not? I mean, there's so many places that everyone thinks that once you go,
297160	302840	the lower you go in the stack, the more complicated things get. They don't actually,
302840	308560	they're way simpler, but they're just a little bit low level than most people are comfortable
308560	314280	with. But they're not too complex. And once you get over that hurdle, you go,
314280	319480	oh, I can just do that. That's awesome. I'll just write firmware to this thing.
320660	326840	As simple as that. Yeah. I mean, there are a lot of mitigations in the operating system
326840	332600	and application level that there's been a lot of attention there. So there's all kinds of
333160	338740	OS level application security stuff, looking at the file system, doing scans of the file system
338740	345860	are really common. And there's been a move towards like fileless malware and doing stuff only in
345860	355040	memory. But a lot of that is just, you get code execution on the box and run fileless in,
355040	360140	or just in memory. But being able to store stuff in places that people aren't looking
360800	365960	gives you that additional persistence where the loader that you actually have on disk
366780	372220	looks completely benign because people don't understand how these access mechanisms work
372220	378360	in most cases. So being able to have something that looks benign on disk and it'll pass all the,
378360	383700	like you can throw it up on VirusTotal and everything is 100% clean, but it still can go
384580	391400	read the actual malicious payload out of the GIGI region or from some random USB controller
391400	398640	firmware that's unsigned. And maybe it has some encryption key or something like that, where
398640	404920	the only thing that happens in memory is malicious, but the thing that actually happens on disk is
404920	411540	completely benign. And it's an interesting mechanism for persistence. And we wanted to
411540	417600	provide more visibility into that and let people know that this type of capability exists in the
417600	425380	system. Were you inspired? Go ahead. I was going to say, yeah, if you were inspired by any particular
425380	433240	researcher attackers using similar techniques. I mean, there's generally been, like I said,
433240	439780	there's been all this research and attackers in the operating system space and attackers have
439780	445160	started moving down in the stack. Like we've seen UEFI implants. There was like a Lojax implant.
445280	450700	There were some other ones were found in the wild. There was something in the Vault 7 leak that was
450700	456360	talking about an EFI implant that they were using there. So I think there's a trend towards people
456360	462160	moving further down into the stack. And a lot of these firmware components at those lower levels
462160	468580	in the stack don't have all those same hardening protections that the application and operating
468580	474320	system has. So you don't have things like code signing protecting your firmware in the stack
474320	480120	or firmware in some of these devices. A lot of these are lower cost, lower power devices that
480120	488020	maybe they don't have like a nice crypto engine built into this chipset. So a lot of that is
488020	491840	lagging behind just because there isn't this additional visibility and people going after these
491840	499360	components. And it's an area that's ripe for exploration and exploitation. And like we
499360	504420	talked about in our talk, some friends of ours gave a talk about doing this type of thing using
504420	509980	UEFI variables. And we were like, but wait, there's more. So let's go out after some of these
509980	516440	other areas. So that was kind of the inspiration for this talk. So a lot of what you're saying
516440	523340	is really interesting. I work way higher. I'm kind of in the website usually, and there's a lot
523340	530460	of things that have happened over the years in the website that make it harder-ish to do the web
530460	538280	hacking world. It sounds like there's maybe less... because there's less people working in the space
538280	544940	of attacking low level, are there less mitigations that I would run across if I got into it?
547100	553760	That depends. I mean, it is lagging behind to some degree. There are some... so people,
554740	560420	depending on what people's understanding, like you said, you work in the web space. So you
560420	566320	may be familiar with web stuff. People can talk about a full stack. And there's the full
566320	573520	stack of the web stuff that's externally facing, going down to a lot of these
573520	577720	underlying levels of the operating system. And you can get down to the point where you end up
577720	586040	looking at bugs in CPU microcode that have side channel implications. And there's a lot of
586040	591200	different vulnerabilities all throughout that stack. And there's been a lot of effort to do
591200	595920	the easier stuff that's more directly exposed to the user. But there are some of these underlying
596640	601200	things, some of these foundational technologies that everything is built on top of,
601200	608000	that are kind of lagging behind those exploit mitigations. Where like when the system
608000	613760	powers on and boots up, the processor starts executing code at the reset vector.
613840	618780	It used to be the case this was BIOS, where there was no protections whatsoever there.
618780	623820	Then people have standardized on UEFI, where there's the UEFI firmware that executes.
623880	629240	And a lot of that is they're adding protections there. But a lot of the times when the UEFI
629240	634660	firmware is running, there aren't things like address randomization. Sometimes the stack and
634660	639240	heap are fully executable. A lot of those mitigations that you're totally used to in the
639240	645880	operating system and application space aren't there. And there is some effort to put some of
645880	654040	these mitigations into the reference code. So there's a... UEFI has a reference specification
654040	662220	EDK, EFI development kit, development environment. And people take that specification. There's a
662220	666780	reference implementation called TianoCore. Some of these exploit mitigations are going
666780	674160	into TianoCore, but there's this whole big supply chain for getting those out to
674160	679260	actual customer systems. So there's reference code in TianoCore that then independent
679860	686860	vendors like AMI Phoenix inside take that code, add their own special sauce. Then the OEMs like
686860	691960	HP Lenovo Dell take the code from the independent virus vendor and do their own
692940	698540	value add. And then quite a bit later, that actually ends up shipping in production firmware.
698540	704340	So there's kind of this... there's a lot of components that are going into it. And it's
704340	708620	just lagging behind a little bit. So something going into the reference code in TianoCore
709640	714100	it might not be enabled by default. And even if it is enabled by default, it's going to take a
714100	719500	little while before it actually gets out into the systems that are shipping to customers. So
719500	725000	the other problem is that updating firmware is a lot harder than just pushing out a patch
725000	731580	through some Windows update in general. So there's... they've tried to standardize on
731580	737500	firmware updates for system firmware to some degree, but a lot of different vendors are doing
737500	744540	things differently. And that isn't fully easy to do yet. And so there's the system firmware
744540	748780	for your device, the UEFI firmware, but there's also all the firmware for all these
748780	754960	embedded controllers like the S-Media controller that Mickey talked about. And there's a
754960	760520	GigE controller that's as part of the Intel PCH chipset that we can write to that region.
760520	765060	We're not reading and writing to the firmware directly for that GigE region, but there's other
765060	772080	controllers on the system like there's a lot of servers have a Broadcom 5917 chip
772080	776540	that we talked about in some research a while back that also has unsigned firmware that
776540	784700	that's a common server chipset where maybe an HP DL380 will have that chipset and you can
784700	788780	write firmware there as well. Sorry, I kind of rambled a lot. Did you want to say anything?
788780	791600	I need to change my background after that.
794080	800440	Yep, that's pretty much it summarizes everything Jesse talked about.
800440	805160	Yeah, so you have like a operating system security which maybe is updated through
805160	814420	Windows Update or maybe Debian or Canonical or Red Hat SUSE repositories where
815040	820180	they're providing updates there, but there is a little bit of an effort to update firmware,
820180	824380	all of these different components are out there and some of them just don't have the capability
824380	830720	to have signed firmware. So there's a lot that you can do there and there's not a really good
830720	835140	easy way to fix it other than just waiting for the next generation to come out and hopefully
835140	840020	it has the capability to have signed firmware as well. Sometimes they'll have checksums and
840020	844360	stuff like that, but that's not a security mechanism and it's pretty easy to bypass
844360	850120	and recalculate a checksum. Excellent, there's a lot there and I'm sure that
850120	855600	I'll be watching through this talk later to make sure I get more of what you just said.
855680	859360	We do have some questions coming in from the audience, so I'm going to get to one of those.
861380	867820	So RPTK2015 says, question, do you know of a way to write some code into one of the various
868860	874400	EEPROMs that will be capable of executing code by itself without code in the disk?
875580	881300	Yeah, I mean that depends on the capabilities of the specific device, but as an example,
881300	888640	there's all the rubber ducky bad USB devices where a lot of flash controllers or flash devices
888640	895480	use an 8051 processor as part of the controller and you can write firmware to that and have that
895480	901280	essentially act as a keyboard and inject keystrokes, mass storage, stuff like that. So
901280	907440	if you have the ability to update firmware depending on the capabilities of the device,
907440	913360	if it's an internal USB device, it might have the ability to essentially act as a rubber ducky and
913920	920860	execute code and basically restage back from the device. We had given a talk a number of years ago
920860	928360	also at DEF CON about an internal Huawei LTE modem that we were able to update the firmware for that
928360	935040	and this was an internal device. Basically it was an M.2 card that was connected to the rest
935040	942100	of the system over a USB interface and it essentially was running a version of Android
942100	947560	with the Android gadget interface inside of this little M.2 card. So it was a complete Linux
947560	953960	distribution inside of the USB device inside of your laptop or tablet. So you could essentially
953960	958380	update the firmware there and have your payload there. The cool thing about that one is that
958380	964640	you can have that inject keystrokes back to your tablet or laptop and it also had a cellular
964640	972620	connection so you could do a CNC out to AWS. So that was a fun talk also that was a few years
972620	976940	ago at DEF CON. So yes, you definitely have the capability where if you can update the firmware
976940	981500	for the device, depending on the capabilities of the device, you might have the ability to
982000	988300	directly attack it again without needing that loader within the operating system
988300	993580	that's on disk in the file system. Additionally, if you have like a PCI device, you could potentially
993580	999980	do DMA attacks against the system and do that same type of capability. Sometimes the
999980	1004380	operating system has DMA protections but the boot process doesn't and you can do an injection into
1004380	1010420	the boot process while the system is booting up. There was a quick follow-up question on
1010420	1015960	that from the same user. Did you use this in an assessment?
1017700	1026440	Well, we don't work as consultants or red teamers.
1026560	1033940	Not currently. So we were on a red team and we've since moved to different positions doing more
1033940	1038040	hardware and low-level security. And it was like this is the type of thing that we would have
1038040	1043780	wanted while we were still actively red teaming. But we haven't specifically used this on an
1043780	1049120	engagement, just proof of concepts and playing around with our own systems. We've heard others
1049120	1055840	use the high trick in an engagement. But not the rest of it. The rest of it's just so
1055840	1062160	many options we haven't had a chance to try them all. That's kind of the problem across this
1062160	1065620	space, isn't it? There's a target-rich environment.
1068460	1072640	While I read this next question in my head...
1074760	1083520	We'll just go right into it. It was like this when I found it. So the demo jumps right into
1083520	1091460	and here's this stuff and we can write and read to it. Isn't this cool? And the natural is it is.
1091460	1097680	It totally is. Plus one for elevator music. Any more pointers on enumerating access methods for
1097680	1103980	these things? White papers? I presume you're not using physical methods, JTAG or in-circuit
1103980	1110680	programming. So, point three, what APIs functions are you using for this kind of thing in general?
1110680	1116460	It seems like you could drop stuff into legit update image and flash it, but it looks like this
1116460	1125360	is on the fly. So a couple of... I can go through the TLDR of that. We can answer that. Well, it's
1125360	1132260	going to take 15 minutes, but I'm going to jump right at it. So there are certain tools you can
1132260	1139220	use to flash a pre-infected image. Like you can modify the legitimate image and then use the
1139220	1145540	provided tool by the vendor to send it to the device and have the device flash it to its image.
1147240	1153760	There was another way where we use one of the code releases was actual
1154560	1162060	talking directly to the spy controller in the computer. So, Jesse, you're itching to
1162060	1166640	say something, so go ahead. I just wanted to point out that if you haven't taken a look at it, we do
1166640	1173800	have a sample code up on GitHub now. Basically, GitHub hacking things slash bytes in disguise
1173800	1179680	that shows how some of this code works where... I will beg you after this thing to post that
1179680	1185360	GitHub to the TrackOne channel, but go ahead. Okay. So, yeah, basically we have some examples
1185360	1192000	to show off doing things like reading and writing to CMOS. Essentially, the low-level hardware
1192000	1198700	interfaces that the processor uses to talk to some of these resources are things like IOPorts,
1198700	1203540	where there's an x86 command called in and another called out that are literally for doing
1203540	1209120	reads and writes to these IOPorts, and that's an architectural feature of the system. There's also
1209360	1218600	a PCI access where you can do IOPort read and write to IOPorts CF8 and CFC in order to do
1218600	1224940	what's called legacy PCI access. And then there's also what's called memory mapped IO, where if you
1224940	1230020	can read and write to specific physical memory addresses in the system, you can basically talk
1230020	1236810	to these PCI devices through the PCI controller. And generally, in order to talk to these interfaces,
1239040	1246150	IOPort, you can basically do a privilege access like IOPL in Linux in order to
1247740	1251880	set your IO privilege level, so then you can do IO reads and writes from ring three
1251880	1258280	and talk to these ports. But in order to do reads and writes to the memory mapped IO,
1258280	1266880	you generally need a ring zero access, kernel access, or a privileged proxy that can do that
1266880	1273880	for you. So we gave a talk last year about a lot of drivers that provide this access for you. Basically,
1274520	1280380	you can do IO controls to talk to the driver, and then the driver will go do reads and writes to
1280380	1287080	these IOPorts, or PCI access, or reads and writes to physical memory. And we found a number of
1287080	1293620	these drivers that can provide this type of access. And we took one of the specific examples that's
1294640	1299820	pretty commonly found, the PMX driver from Intel. And it has a lot of capabilities, like
1300360	1305280	you can do an IO control to talk to the driver, and it'll do an arbitrary read write to a port,
1305280	1310640	or arbitrary PCI access. So we have some code that shows how to do that, including things like
1311880	1315380	talk to the CMOS, read and write CMOS, read and write
1317080	1325800	different areas of memory, talk to PCI devices. So one complication is that
1326400	1333540	if you use the direct PCI access mechanism in that driver, it goes through the IO,
1333960	1341900	or it goes through the Windows API functions to do that IO, which is how get bus by offset,
1341900	1349380	bus by offset. The interesting thing is that the spy driver, or the spy device,
1349380	1356060	when the Windows system is booted up, is actually hidden. It's a hidden device. So
1356060	1361120	if you try and go through the API in Windows, you won't be able to talk to that spy device
1361120	1369540	at bus 0, device 31, function 5. But if you do legacy PCI access by going through that IO
1369540	1374900	read write of CF8CFC, you can directly talk to the spy controller in that device with no problem.
1374900	1379780	So we have some code to demonstrate that. And using what's called hardware sequencing,
1379780	1384780	where you basically say, here's the address within the spy chip that I want to talk to.
1384980	1389800	Go read the 64 bytes from that and give me that data back. So we have an example of doing that.
1389800	1395520	We have an example of basically mapping the physical address, the last page of the four
1395520	1401880	gig region, and printing the bytes from the reset vector in the physical memory region. So all of
1401880	1410740	that is using this driver and DLL that was included in a number of software packages for update
1410740	1416480	mechanisms. And if that answer went way over your head, you can just go to the GitHub. No, that's
1416480	1424760	fine. That's fine. Go to the GitHub and look at the code. It mostly is in C sharp, which is easier
1424760	1431520	to understand than most things. It goes a little bit low level at some places. But if you
1432000	1436800	go there and you look at the code, it's not big. It's not scary. Just take your time.
1436860	1442280	If you have any questions, you can ask us later on. But whatever, everything that Jesse just said,
1442280	1446640	and if you completely went over your head, it's not that complicated once you spend an hour
1446640	1451200	reading on the internet. It's not that big of a deal. I promise you. It should be fairly
1451200	1457540	straightforward. There are some defines and register offsets that are specified for certain
1457540	1464820	things like the spy controller. If you look for the Intel PCH chipset data sheet, you'll be able
1464820	1472880	to find the definitions for those registers and offsets. This was specifically put together on a
1472880	1479720	Kaby Lake system, at least from my side. So some of the registers, like the fields, are a little
1479720	1485140	bit different sizes between a couple different generations. But this code should work on
1485140	1492200	everything from Sandy Bridge onward, I believe. All right. So I love where you're heading with
1492200	1501120	this. And this is particularly the way that you're explaining how to... for some of us who don't have
1501120	1508360	the depth of experience in the low level stuff, you're giving us some entry points so we can go
1508360	1514840	look at your code. We can try and replicate some of this on our own. Are there other thoughts for
1514840	1520440	those of us who might want to do this on our own? Do you have other places you would like us to
1520440	1529080	maybe go point and get some base experience to start playing with you? Yeah, I mean...
1529640	1534320	Before you do anything, before you start playing with anything, you got to remember too, if you're
1534320	1540980	going to do something with something, back shit up. If you're going to experiment with
1540980	1545860	non-volatile memory, first learn how to physically back it up and flash it back on.
1547440	1554620	That said, go for whatever you see has a chip on it that contains data. Go wild.
1555380	1559920	Yeah, to follow up on that, there are some things you can do, like writing to some locations
1560490	1565900	in your system, where the system won't boot anymore. So you'll need to physically open the
1565900	1575180	case. In the case of writes to just bare SPI chips that are easily accessible,
1575180	1581040	like the BIOS or UEFI firmware or BMC firmware in a server, you could use something like a
1581040	1587460	Dediprog with a chip clip and physically clip onto the SPI chip and read that, make a backup copy
1587460	1593300	using physical access before you start messing with it. There's also, you can use a bus pirate
1593300	1597820	to do SPI read and write if you don't have a Dediprog. But you can often find a Dediprog
1597820	1603460	on eBay for like 50 bucks or so. What I recommend is if you don't want to do that, I have an
1603460	1610000	alternate method, which is you have a Thunderbolt capable device, you just plug in a PCI Thunderbolt
1610000	1615980	adapter you can pick up for 100-150 bucks off Amazon. And then you just plug in one of these
1616900	1621560	PCI cards. This is one of the cards we worked on for the demo. This is a USB controller PCI
1621560	1628880	device. It has its own EEPROM. And if you mess it up, it's 15 bucks. Isn't that the thing too,
1628880	1633760	but was not the controller you actually writing to? This is the same controller that I thought
1633760	1638480	I was writing to, but apparently I had one in my motherboard that I've been reading and writing to.
1638480	1642820	So yeah, be careful about doing that. It's nice if you can just pull out the PCI card
1642820	1648480	and your system boots again, but sometimes it's more difficult. Remember to check you
1648480	1651380	don't have your target already in your computer before you start flashing.
1653040	1660020	This is all great advice. All right, gentlemen, we are right at the end of our allotted time.
1660380	1666860	You two are incredibly easy to talk to about this stuff, so we appreciate that. I like to
1666860	1673100	provide everybody an opportunity to distill a takeaway. What is the call to action you
1673100	1680240	would like to provide for the community who is watching this? I would just start out by saying
1681020	1686420	this might seem intimidating and difficult to get into, but it's really a lot easier than you think.
1686420	1692560	And if you just start experimenting with this case and do some of this yourself,
1692560	1695800	it's actually a lot of fun and it's not as hard as it might initially seem. So
1695800	1702120	we have some code examples you can get to. Like I mentioned, the Intel PCH chipset data sheet.
1702500	1708020	It's a pretty big document, but if you just look at certain things like the SPI controller
1708840	1715100	registers, it can help guide you and get you started. So I totally recommend people to go.
1715160	1720560	Don't be intimidated by this and just try it out and see what you can do. I'm just going to add that
1722240	1728300	feel free to ask other people for advice. And I'm just going to caveat this with if you ask
1728300	1734220	me for advice, I will gladly help you under the condition that you help others if they ask you.
1735980	1740860	So don't be an asshole. Help others. This is the point of community.
1740960	1749180	Yeah, that is one of the best takeaways that I've heard so far. So you have a whole series
1749180	1756340	of people in chat wanting to buy you drinks next time they see you in person. Well, thank you two
1756340	1765460	very much for coming and providing another deep load of content for DefCon and all that you do
1765460	1771600	for us. So if anybody has additional questions, I'm going to see if I can get these two to post
1772160	1780600	more of their contact information in the TrackOne channel so that people can find you later.
1780600	1787820	Other than that, I hope you have a wonderful rest of your Con and that's pretty much it.
1788000	1790080	Cool. Thank you. Thank you both. Thank you.