pin2pwn: How to Root an Embedded Linux Box with a Sewing Needle
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 93 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/36222 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 2483 / 93
4
6
7
11
15
20
26
33
34
35
36
39
40
46
49
53
58
62
63
66
68
72
79
90
92
93
00:00
Information securitySoftware testingPhysical systemPresentation of a groupMultiplication signMoment (mathematics)File CarvingComputer animation
01:00
BootingDemo (music)Level (video gaming)BootingBefehlsprozessorComputer animation
01:22
BootingEscape characterInformationDDR SDRAMParameter (computer programming)Bit rateInformation securityAutomatic differentiationDemo (music)BootingPhysical systemComputer animation
01:36
Bit rateMusical ensembleParameter (computer programming)DDR SDRAMComputer-generated imageryFlash memoryVideo game consolePhysical systemMatching (graph theory)Medical imagingPartition (number theory)Personal identification numberMoment (mathematics)
02:12
Bit rateParameter (computer programming)DDR SDRAMComputer-generated imageryBootingMusical ensembleKernel (computing)Partition (number theory)outputRow (database)BootingComputer animation
02:28
Kernel (computing)Computer-generated imageryDDR SDRAMParameter (computer programming)BootingStructural loadFlash memoryLine (geometry)Configuration spaceDemo (music)Right angleParallel portComputer animation
03:12
Flash memorySystem administratorRouter (computing)Data recoveryHacker (term)BlogSoftware testingBridging (networking)Multiplication signForm (programming)Software testingNumberBlogLink (knot theory)Key (cryptography)Asynchronous Transfer ModeComputer animation
03:40
Computer hardwareLarge eddy simulationNP-hardOcean currentTime travelAbsolute valueArithmetic meanComputer hardwareMaxima and minimaCondition numberMultiplication signKreisprozessOperator (mathematics)Personal identification numberJSON
05:06
Order (biology)Computer networkGeneric programmingProduct (business)Interface (computing)BefehlsprozessorSerial portDiagramBefehlsprozessorFlash memoryComputer architectureTelecommunicationBootingParallel portCoprocessorBitComputer animationProgram flowchart
05:35
ChainBootingSpacetimeProcess (computing)2 (number)Kernel (computing)Level (video gaming)BootingBus (computing)Multiplication signFigurate numberFlash memoryProgram flowchart
06:22
Computer hardwarePoint (geometry)Process (computing)Computer configurationComputer animation
06:34
Game controllerMereologyZoom lensCore dumpBridging (networking)Kernel (computing)Computer configurationEinheitswurzelMetropolitan area networkUniformer RaumUser interfaceMenu (computing)Block (periodic table)Computer-generated imageryThresholding (image processing)Total S.A.Principal ideal domainThread (computing)Ubiquitous computingWeb pageEmailVolumeInheritance (object-oriented programming)Mathematical optimizationDevice driverImage registrationRead-only memoryEinheitswurzelProcess (computing)Serial portFlash memoryGastropod shellComputer animation
06:47
File systemVideo game consoleLine (geometry)Ubiquitous computingWeb pageEmailVolumeThresholding (image processing)Computer-generated imageryFreewareTotal S.A.Principal ideal domainThread (computing)Error messageBlock (periodic table)Cache (computing)EinheitswurzelRead-only memoryKernel (computing)Image registrationDevice driverRevision controlCore dumpOpen setStructural loadMach's principleConfiguration spaceExecution unitPhysical systemAsynchronous Transfer ModeAuthenticationSerial portCuboidProcess (computing)Cartesian coordinate systemCharacteristic polynomialBinary codeWeb pageBootingGastropod shellMultiplicationStructural loadSource codeJSON
08:00
Video game consoleStructural loadCartesian coordinate systemWeb pageFlash memoryPersonal identification numberFunction (mathematics)CuboidMultiplication signSemiconductor memorySerial portStructural loadJSON
08:41
Router (computing)Line (geometry)CuboidParallel portFlash memoryTape driveAddress spacePersonal identification numberLogicBefehlsprozessorMetreRouter (computing)Demo (music)Fraction (mathematics)Computer animation
09:45
BootingSerial portPartition (number theory)Musical ensembleRouter (computing)Point (geometry)ArmComputer-generated imageryKernel (computing)Digital rights managementDemo (music)Personal identification number
09:57
Level (video gaming)Multiplication signSerial portSoftware developerLogikanalysatorError messageSoftware crackingFlash memoryVideo game consoleComputer hardwareBootingArchaeological field surveyOpen setFigurate number
10:58
Archaeological field surveyBootingPOKEParallel portSerial portEinheitswurzelGastropod shellData typeFlash memoryDifferent (Kate Ryan album)Asynchronous Transfer ModeSoftwareFirmwareMultiplication signRight angleBitPower (physics)State of matterProjective planeSoftware testingDemo (music)BootingPersonal identification numberEinheitswurzelOnline helpKreisprozess
12:22
BootingSoftware testingComputer hardwareService (economics)Asynchronous Transfer ModeFactory (trading post)Interior (topology)SurfacePlane (geometry)NP-hardKernel (computing)Serial portFunction (mathematics)Physical systemProcess (computing)SpacetimeInformation securityMaxima and minimaBootingAsynchronous Transfer ModeTracing (software)Auditory maskingDifferent (Kate Ryan album)Flash memoryPerspective (visual)outputPersonal identification numberRouting1 (number)BitInterrupt <Informatik>Level (video gaming)Degree (graph theory)Decision theoryVideo game consoleReading (process)Coefficient of determination2 (number)Exploit (computer security)Computer animation
Transcript: English(auto-generated)
00:00
give it up for Brad Dixon. Thank you. So I'm Brad Dixon uh I work with Carve Systems we have a a lot of fun uh working with systems that involve um embedded or IOT devices uh you know trying to do security assessments and penetration testing uh on the whole system. And uh
00:23
this is gonna be a presentation a quick one about uh uh uh an attack technique that we found repeating itself uh as useful uh more times than we thought it would. And I'm gonna describe this as as being useful because it works, it's easy, it's uh it's pretty dramatic, and it provides a teachable moment about designing more secure systems. But it is a
00:44
novelty and it's a novelty because it is uh it's it's risky, it's crude, and it's perhaps redundant to a lot of other great techniques that are out there. But it sure is fun and when you do this uh you do this device like you can you can demo this attack to your mom and she'll just be like oh I get it. So let's just quick get to the
01:02
demo. So to set the stage here uh we've used this on a lot of devices but this one in particular is an embedded Linux device with uh U-boot as the boot loader. There's no JTAG that's actually been turned off with microfuses inside the CPU. So that's gone, can't find it, JTAGulator was great but couldn't find JTAG at all. And because this device
01:23
had had some challenges before let's say um it was uh it had they had a homegrown secure boot loader added. So getting to the demo here this is the system booting up. And you'll see why we call this pin to pwn in a moment. Uh this is my trusty like 1995 uh
01:43
multimeter just jamming into the flash chips and I'll show you where in just a moment. But as the system is booting it's doing a cryptographic checksum across the flash image. And when that checksum doesn't match what it's expecting it does a fallback to a secondary partition. And it's gonna start that in just a moment. And as you can see using a serial
02:05
console on these devices you can track what's going on. Um I didn't put the clip in there but I'm again poking the flash device to get the second uh partition to fail as well. And they designed this device to do not respond to any serial input. But what happens
02:21
is they've misconfigured it so that if it fails twice in a row the primary and the secondary partition I get a U-Boot prompt. Excellent. That gets me in. So the primary misconfiguration was not checking their failure paths. That happens as I found out more
02:45
often than you would think. And there's also gonna be two kinds of flash devices you'll see in these demos. Uh this is a parallel flash device. It comes in a standardized package typically a TSOP48 package. You can actually attack it from the left or the right side. Uh I'm attacking the right side between two of the data lines that feed data out of the
03:04
flash device uh when it's uh called by the CPU. Um and and as you saw it it's pretty low tech. You just poke it. Um but there's been a lot of prior work on this. Uh glitching as a form of attack has been done numerous times uh and just some really amazing stuff
03:21
about like extracting cryptographic keys with transient glitches induced by a number of manors. Um there's also been other blog posts about this precise thing using you know a transient electrical fault to get a failure mode that's advantageous to doing a penetration test. Um and so there's some of the links you can check out. But what I
03:41
want to do today is just provide more details so that when you sit down, pull out some devices from the closet, try this, you might be surprised as I was how often this works. Um I have to warn you uh well first of all this is Grogg, Grogg's our mascot. Uh sometimes you know you you try elegant techniques and they work. Sometimes you
04:00
just beat stuff with rocks. Um and and you get what you want that way. Um but you can definitely break your hardware doing this. I haven't yet destroyed anything. But you can. And and the way you'll do that is by exceeding um there's an absolute maximum current that can go out of each IC device. And if you exceed that for too long um then
04:23
that device might just be you know kaput. The black smoke comes out. You can also temporarily uh cause a device to fail. They have sometimes protection circuitry so that if you exceed the operating conditions, that pin just shuts off. Usually power cycling will fix that. And I've had that happen a few times. Um and and of course
04:42
depending on what access you have to the device. Like if you have JTAG you don't need to do this. Um if you have other means to get what you need, use the safer means certainly. It it will you know prevent you from breaking something. Uh if there are any time travelers in the audience, go back and listen to uh Joe Grans and Joe Fitzpatrick's um
05:01
101 ways to brick your hardware. I I think I'm adding a new manner to do so. So let's get to the details about how can you mount this attack yourself. This is a general architecture diagram for the kinds of devices that we work with. CPU devices, 32 or 64 bit processors, running Linux, using typically a boot looter boot loader like U-boot. Um and
05:26
you're trying to interrupt the communications between the external flash device and that CPU. Uh these can either be serial or parallel flash devices. The reason that this works is that systems boot in stages. And what's being shown right here is the
05:43
activity on the flash bus. You don't need to you know looking at trying to decrypt the details of this by zooming in is not helpful for this but you want to get an idea of like the wall clock timing on this. And figure out well when is the boot loader being loaded like is shown on the left. When is the kernel being loaded? What's the duration where the
06:01
device is booting? And then where does the user space and knit process kick off? And you can actually attack in two different places. The most successful for me has been interrupting um the loading of the kernel so that you fail to a U-boot prompt. But I'll show you an example in a second of something that was it's actually much more surprising to me.
06:23
So in this example this device had actually been pretty well secured. Um this this was a device where where JTAG wasn't gonna be an option uh you know based on how they designed the hardware. Um but we I found a point later during the init process where poking the serial flash device caused the init process to fail and give me exactly what I
06:45
wanted out of this. A root shell on the device. Yeah! So this kind of misconfiguration is much more rare. The the forgetting to have a a useful failure mode for load for U-boot
07:06
that's pretty common. I've seen that a lot. Um but this one was more rare and the reason for it is uh this this uh embedded Linux system had been really cleanly set up. It was great work. Um and they had but they had left something in there to help the
07:21
developers out that when the primary application started up it would grab all the serial ports, throw up an authentication prompt. It wasn't Getty, it was something that was built into their application. Um and then um but then if their application for whatever reason failed the next step in the init process would be just run a shell. Now another
07:42
thing that happened uh another characteristic of the system was important to this. Uh this system was using BusyBox. BusyBox is like uh uh what's called a multi-call binary. It's like a Swiss Army knife that does all the things that a typical Linux system needs but does it with just one binary. And so since most of the pages for that had already loaded before the application we caused to fail had started when that application failed
08:05
even though I was screwing up flash for it, BusyBox was already resonant memory. I think it might have been different if it had to go load other pages because I wouldn't have been able to time that attack very elegantly. This is also uh an example of a
08:21
serial flash device. These typically have an 8 pin uh pin out very standardized much bigger device you know so uh you can use a multi-meter probe to you know to poke at this. And I was uh poking between the chip select which says hey flash device read me out some of that data uh and the actual data output on that. So here's another
08:45
example. This was an LTE router. Um on this device um as you can see up in the your top left uh there's a little DIMM looking uh CPU module. The flash device was on the underside of that DIMM device so that's outlined in in the red box below. So to get
09:02
set up for this I had to pop that device out, flip it over, put my pin where I wanted, throw a little blue tape on it and then pull that pin out just a fraction you know a I'm working on the left side of a parallel flash device. Another Tsopp 48 pin out. It's a
09:21
standardized pin out so you can find this pretty frequently. And I'm probing uh the chip select uh sorry the uh command latch and address latch lines. Shorting those 2 out. And what those do is when that when that command latch line is toggled it says here's a command make sure you read this in do what I'm asking. And then here comes an address. And just by screwing with the logic on that you got this flash chip confused enough to do
09:44
what I wanted. So this is a quicker demo. On this device just a little boop on the pin and uh we're gonna end up back at our U-boot prompt which is where we wanted to get on this. So doing your own pin to pwn attacks uh pretty straight forward. You need to
10:03
survey the hardware. Pop that thing open. You don't need to take anything apart at the PCB level but just the key things you want to do is find all the flash storage devices, figure out how you can access them. You need some way to monitor the boot process. A serial console's great because that's probably the access that you're gonna get. The developers will turn the serial port on when something goes wrong. Um but you
10:25
know there's other ways that you could do that perhaps. You know monitoring with a logic analyzer and just getting a wall clock time on it. Um you need some data sheets to figure out on the flash storage devices that you have um where can you probe successfully. There's some trial and error on this. Not everywhere I tried worked on
10:41
each device. So you're gonna have to take a few cracks at it. And you need a way to be able to understand when the device fails. Maybe it's LED's. Maybe it's something on the serial console. There'll be something. Because the last thing a developer wants is for something to go wrong in the lab and for their device to be bricked. They left a door.
11:01
Find it. Um you got after you selected your pins you're gonna gonna start poking at that. This took me a try. Usually about six or eight attempts per device just to get the timing right on it. Um but you know it's something you can work through pretty quick. Um make sure you power off between each test. If some of that uh protection circuitry in
11:22
the IC gets engaged, power cycling it's gonna help you out. And then monitor for a different operational state. One that's not the normal one. Um getting U-boot prompts uh pretty common. But some devices have different failure modes like uh enabling networking ports or failing to like a USB uh device firmware upgrade. You'll need to find
11:43
those. And you need a little bit of luck on this too. So we pulled out all the devices in our closet and we said hey let's go for this. Let's see what other devices can do this. And you know about that little bit over 50% of the time we were able to get some failure mode that was helpful to what we're doing. You know getting
12:02
root on one of these devices is really just the start that's kind of like day one of a project. It just helps us do the rest of the rest of the work. Um but it's really cool to be able to demo to people to say watch this. Boop. And you end up with what you want. Um it's it's a great demo. I highly recommend it. But let's talk about some of the places where I was unable to get uh to get root. The devices that have
12:24
thoughtful consideration of how to fail. Those are pretty resistant. The best ones uh were ones that would reset if it if they were unable to read flash on it. From a consumer perspective that device is bricked. That's probably maybe a bad thing for business. Um but from a security perspective that's a proper reaction to it. Ways that you can improve
12:48
your design or uh you know give recommendations to others. You know if you can't all turn on uh watch dog timers early in the init process at the boot loader level and then start servicing them in user space so that something interrupts in between you're
13:01
gonna confound an attacker to a degree. Um you know who's trying to get at this device. Um and just be very cautious you know about shipping failed debug mode systems. Uh those are exploitable. You just gotta find the way to get in. The other one is really a design um uh decision. Uh hide your pins, hide your traces. Um BGA or ball grid array
13:26
devices uh they have an IC with little balls underneath that mounts directly on the PCB and uh the PCB designer can actually take signals and route them immediately through via to an inner layer of the printed circuit board. When you're at an inner layer it's it's
13:40
hard to get at them. Um you know traces that are on the uh outer layers of the PCB you can actually scrape off the solder mask and get at those. Um but you're gonna have less options. And so it just makes it harder for an attacker. So BGA devices uh some security conscious PCB design and PCB routing uh can make a big difference. And and the last
14:05
which I I think you know everybody should be doing when they lay out these devices to help improve security is just be very terse about what you're doing. If you have a serial console certainly don't accept input on it unless you really want that for some reason. Um and boot that thing fast. Um you can get like embedded Linux systems to boot you
14:23
know well under a second. And it just makes it hard for a hand timed attack like this. You could do something more elegant and crafty of course. Um but you know that's that's that's more work an attacker. Maybe they'll move elsewhere. So that's the last bit of this. Um Max is here. Somewhere. Max is right there. We're gonna be uh outside to take
14:46
some questions and if you have some good questions we're gonna have something for you. But uh I'm Brad Dixon. Uh thanks so much for your attention. Appreciate it.