Stepping P3wns: Adventures in full spectrum embedded exploitation (and defense!)
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
Titel |
| |
Serientitel | ||
Anzahl der Teile | 112 | |
Autor | ||
Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
Identifikatoren | 10.5446/38899 (DOI) | |
Herausgeber | ||
Erscheinungsjahr | ||
Sprache |
Inhaltliche Metadaten
Fachgebiet | ||
Genre | ||
Abstract |
|
DEF CON 21104 / 112
3
6
8
9
13
14
15
16
17
22
23
24
25
29
32
33
36
37
39
42
45
47
49
53
60
61
64
65
66
71
76
79
80
82
89
103
106
108
00:00
Rechter WinkelMathematikBenutzerschnittstellenverwaltungssystemMetropolitan area networkBitMultiplikationsoperatorBetrag <Mathematik>t-Test
02:56
Rechenschiebert-TestWeb SiteRechenschieberPunktspektrumAbenteuerspielMereologieExploit
03:34
MagnetbandlaufwerkSoftwareQuick-SortRechenschieberBildgebendes VerfahrenMultiplikationsoperatorSoftwareschwachstelleCoxeter-GruppeSoftwarepiraterieComputerunterstützte ÜbersetzungGoogolRechter WinkelRouterComputeranimation
05:01
BitDifferenteGoogolPropagatorMalwareKonfigurationsraumMultiplikationsoperatorBildgebendes VerfahrenTypentheorieProdukt <Mathematik>PolygonnetzSoftwareComputersicherheitMAPRouterOffice-PaketComputeranimation
05:51
ComputersicherheitMAPMetropolitan area networkComputersicherheitSchlüsselverwaltungTropfenTabelleAuswahlverfahrenComputeranimation
06:25
RouterAuswahlverfahrenVirtuelle MaschineOffice-PaketKonfigurationsraumComputeranimation
07:15
SoftwareschwachstelleInternetworkingHochdruckFirewallPunktSelbst organisierendes SystemProzess <Informatik>Bildgebendes VerfahrenRechter WinkelFirmwareElektronische PublikationPhysikalische TheorieIntranetTabelleSchlüsselverwaltungTropfenComputeranimation
08:21
Patch <Software>Fisher-InformationTabelleSoftwareschwachstelleComputersicherheitPatch <Software>BildschirmfensterInternetworkingFirmwareCASE <Informatik>Einfache GenauigkeitDatenverarbeitungssystemEndliche ModelltheorieSelbst organisierendes SystemUnordnungRechter WinkelGraphische BenutzeroberflächeComputeranimation
09:19
SoftwareschwachstelleGamecontrollerPhysikalisches SystemInternetworkingExploitComputerReverse EngineeringSoftwarePeripheres GerätRouterMultiplikationsoperatorWeb-SeiteComputeranimation
10:14
MalwarePropagatorRouterTypentheorieDifferenteOrdnung <Mathematik>Web-SeiteArithmetische FolgeSoftwarePhysikalische TheorieRechter WinkelART-NetzPolygonMalwareComputeranimation
10:54
DifferenteDifferenzenrechnungVollständigkeitHardwareAuswahlverfahrenQuick-SortQuellcodePhysikalisches SystemCASE <Informatik>Ein-AusgabeComputerarchitekturKernel <Informatik>Gewicht <Ausgleichsrechnung>Tragbarer PersonalcomputerVirtuelle MaschineNetzbetriebssystemComputeranimation
11:37
Demo <Programm>TypentheorieRechter WinkelSoftwareNetzbetriebssystemRouterBinärcodeFirmwarePhysikalisches SystemHardwareReverse EngineeringProgrammierumgebungEin-AusgabeKernel <Informatik>SpielkonsoleMereologieWurm <Informatik>AnalysisÄquivalenzklasseHook <Programmierung>CodeQuick-SortLineare OptimierungARM <Computerarchitektur>DifferenteSystemaufrufComputeranimation
13:34
Wurm <Informatik>Lesen <Datenverarbeitung>CodeSpeicherverwaltungStrahlensätzeServerPunktNichtlinearer OperatorBlackboxZeichenketteNetzbetriebssystemBenutzerbeteiligungHalbleiterspeicherRelationentheorieBereichsschätzungSchedulingProgrammbibliothekGebäude <Mathematik>AggregatzustandComputerFrequenzProgrammierungMultiplikationsoperatorAusnahmebehandlungDynamisches SystemProzess <Informatik>Ein-AusgabeRechter WinkelBinärcodeFunktionalMaximum-Entropie-MethodeDämpfungFlächeninhaltRouterHook <Programmierung>GamecontrollerFirmwareQuick-SortBefehlsprozessorPhysikalisches System
15:29
Disk-ArrayNetzbetriebssystemProgrammierumgebungCodeEin-AusgabeMereologieFunktion <Mathematik>BitHalbleiterspeicherInhalt <Mathematik>Message-PassingMusterspracheHardwareHook <Programmierung>SystemaufrufGamecontrollerCoprozessorProgrammierungKernel <Informatik>Spannweite <Stochastik>MultiplikationsoperatorPunktProzess <Informatik>SoftwareBildschirmfensterCASE <Informatik>NummernsystemQuick-SortRechter WinkelLineare OptimierungTragbarer PersonalcomputerComputerarchitekturVerschlingungComputeranimation
17:36
Rich Media ContentElementargeometrieEinhüllendeBitMusterspracheGamecontrollerDemo <Programm>HalbleiterspeicherWurm <Informatik>CASE <Informatik>MetadatenParametersystemVollständigkeitRechter WinkelComputeranimation
18:12
ARM <Computerarchitektur>GamecontrollerLineare OptimierungRouterFunktionalEin-AusgabeCoxeter-GruppeMomentenproblem
18:46
HalbleiterspeicherPhysikalismusRechter WinkelPrimidealFunktionalGamecontrollerBootenBitDemo <Programm>SchlüsselverwaltungComputeranimation
19:20
GamecontrollerSoftwareSurjektivitätReverse EngineeringRouterTabelleRechter WinkelTropfenComputeranimation
19:54
WhiteboardHardwareDemo <Programm>Rechter WinkelUnrundheit
20:42
TabelleServerFirewallReverse EngineeringSchlüsselverwaltungMAPRechter WinkelEinfach zusammenhängender RaumTropfenBitWurm <Informatik>Computeranimation
21:30
Lokales MinimumSpielkonsoleHP LaserJetExploitHochdruckServerProxy ServerNetzadresseSoftwareZahlenbereichElektronische PublikationSchlüsselverwaltungPortscannerMultiplikationsoperatorDateiformatGamecontrollerDatenfeldInformationTouchscreenElektronischer FingerabdruckHalbleiterspeicherMAPRootkitBitAuthentifikationAdressraumPasswortMapping <Computergraphik>Exogene VariableDatenbankGüte der AnpassungFirmwareMereologieMusterspracheDemo <Programm>FiletransferprotokollAdditionCoxeter-GruppeHidden-Markov-ModellComputeranimation
25:27
RootkitProxy ServerEinflussgrößeDefaultWurzel <Mathematik>InformationComputerRechter WinkelPatch <Software>GamecontrollerSystemprogrammLoginFlash-SpeicherElektronische PublikationSoftwareschwachstelleZahlenbereichNabel <Mathematik>PasswortSchlüsselverwaltungInternetworkingDateiverwaltungKernel <Informatik>MathematikStellenringProgrammierungDemo <Programm>TypentheoriePunktProgrammierumgebungComputersicherheitBootenp-BlockSoftwareFehlermeldungPhysikalische TheorieAuthentifikationGruppenoperationBildschirmmaskeArithmetisches MittelRoutingGüte der AnpassungComputeranimation
29:54
Metropolitan area networkLokales MinimumGamecontrollerNichtlinearer OperatorPhysikalisches SystemFreewareRechter WinkelFeldrechnerZahlenbereichHalbleiterspeicherFunktionalRouterInformationEinflussgrößeElektronischer FingerabdruckAdressraumQuick-SortInstantiierungCASE <Informatik>RootkitDifferenteSchreiben <Datenverarbeitung>DatenbankProgramm/QuellcodeComputeranimation
31:32
Metropolitan area networkRouterCASE <Informatik>TypentheoriePasswortVersionsverwaltungMultiplikationsoperatorZahlenbereichRechter WinkelFunktionalHalbleiterspeicherComputeranimationProgramm/Quellcode
32:17
URLHalbleiterspeicherSchreiben <Datenverarbeitung>Ein-AusgabeZeichenketteUmwandlungsenthalpiePhysikalisches SystemRouterElektronischer FingerabdruckVersionsverwaltungDifferenteGamecontrollerDifferenzenrechnungDisassemblerComputerarchitekturZentrische StreckungProgramm/QuellcodeComputeranimation
32:53
Bildgebendes VerfahrenDemo <Programm>BitMultiplikationsoperatorComputerspielSystemprogrammBefehlsprozessorRouterZweiRechter WinkelProgramm/QuellcodeComputeranimation
33:39
SoftwareentwicklerHydrostatikQuellcodeCodeBinärcodeHardwareIntegralSoftwareDynamisches SystemFirmwareDemo <Programm>Kategorie <Mathematik>BeweistheorieRouterMultiplikationsoperator
34:33
Rechter WinkelHalbleiterspeicherSpielkonsoleKernel <Informatik>HydrostatikCodeDialektSystemprogrammRouterBefehlsprozessorMinimumKonforme FeldtheorieExploitDateiformatProgramm/QuellcodeComputeranimation
36:06
Demo <Programm>VideokonferenzYouTubeElektronische PublikationHackerWurzel <Mathematik>Computeranimation
36:51
AggregatzustandVideokonferenzWurzel <Mathematik>FirmwareMathematikTouchscreenDoS-AttackeComputeranimationProgramm/Quellcode
37:25
BitrateBitTouchscreenCisco IOSDateiformatMereologieAdditionFunktionalHalbleiterspeicherEin-AusgabeMathematikRouterAggregatzustandComputeranimationProgramm/Quellcode
38:06
Hill-DifferentialgleichungTouchscreenRouterHardwareNetzbetriebssystemEndliche ModelltheorieGamecontrollerGrundraumRechter WinkelAggregatzustandBildgebendes VerfahrenEchtzeitsystemQuellcodeEinsRootkitExistenzsatzComputeranimation
39:34
Demo <Programm>HalbleiterspeicherMathematikExploitPhysikalisches SystemMereologieMultiplikationsoperatorEchtzeitsystemDoS-AttackeTypentheoriePropagatorServerRechter WinkelOffice-PaketSoftwareRouterMAPDienst <Informatik>ART-NetzMinkowski-MetrikPolygonComputeranimation
40:48
Hill-DifferentialgleichungDoS-AttackeAdressraumRechter WinkelRouterBefehlsprozessorComputeranimationProgramm/Quellcode
41:32
ComputersicherheitRouterInverser LimesDemo <Programm>NebenbedingungSystemprogrammMultiplikationsoperatorCoxeter-GruppeFlächeninhaltVideokonferenzSoftwareRechenschieberRechter WinkelBefehlsprozessorComputeranimationProgramm/Quellcode
Transkript: Englisch(automatisch erzeugt)
00:00
This is what happens when the math on speaking doesn't really all add up.
00:28
Yeah, I'm ready to do this. Let's do it. Do you want me to stand up? Oh, absolutely. You know what? You're the boss.
00:59
It's up to a vote. No, fuck you guys.
02:08
It's starting to really suck. I thought I liked it. I liked it for a little bit.
02:22
You fucking suck. No, no, you got to get the rest of it, man. Oh, he's my nice friend. Science time. Enough spanking.
02:43
You're not fucking around. We're going to do science now, all right? Yeah, yeah? Oh, okay. Thank you. Anyone else? Oh, lord. Okay, science. So I'm a Ph.D. student from Columbia University.
03:01
And this is my research. Why is your voice shaking? My butt hurts. And this is terrible. Okay, so the name of my talk is Stepping Pones, Adventurous and Full Spectrum Embedded Exploitation and Defense. So the defense part is really important. This is what I want to talk to you guys about.
03:22
And here's why. Oh, and by the way, the slides are not on the DVD. It's on our website and it's like 100 megs because unicorns are magical creatures which cannot be compressed at all. So sorry about that. And this is our typical talk. This is what I usually do. First we say, hey, look, we find this bright shiny thing that we want to play with.
03:43
And be it a router, a car or a phone or a printer, whatever it is, we talk about our motivation for wanting to do this sort of thing. And then we spend a lot of time in fail shack, you know, figuring out all the different ways of not owning these devices. We fail and we fail. And after a while we finally succeed.
04:03
We find that one vulnerability. We build that one exploit that works. We're really excited and we spend some time during the presentation talking about it. And then comes the bad news. The bad news is this thing is everywhere. The fix is really hard. You know, this thing runs our lives and it could potentially have a very big impact that's terrible for the world.
04:21
And then we feel bad for saying that. So we say, well, it's okay. Actually, we have this thing called duct tape. So we're going to duct tape this thing up by unplugging it from the network or let's just not use it in the way that it's intended to and hopefully your house won't fall down tomorrow. And then, you know, me, I usually have pictures of cats and things I find on Google image search like 4 o'clock in the morning for harmless copyright infringement.
04:41
And during like the last two minutes of the talk, right, we always have this slide that says, wouldn't it be great if we had a real solution, you know, a solution that's not just duct tape, that actually fixes the fundamental insecurities, the problems, the reasons why we have the problem that we presented on. And then we say, okay, goodbye, have a nice day, and we do it all over again. But the real solution is never really presented, usually.
05:02
So I'm happy to say today we worked really hard to make this talk a little bit different. I'm going to spend about 47% of this talk on the offensive side of our work. You're going to see PolySUSE's malware propagation. And by that I mean malware on embedded devices that propagate from one type of device to another, like a printer to a phone, from a phone to a router,
05:21
and vice versa in full mesh configuration. And then we're going to spend a lot of this time, as much time as I can, on the defensive technology that we've built at Columbia University that we're commercializing through a little company that is called Red Balloon Security. The defense is called Software Symbio, and it's essentially the product of the five years of my Ph.D. work.
05:40
You're about to see it live on stage, in what amounts to basically your typical modern office. And then we're going to spend some time showing you pictures of unicorns and other things that I find on Google Image Search. So Human Cast, this is my Ph.D. advisor and co-founder of Red Balloon Security, Sal Stoffel. We haven't seen him since Black Hat. We don't know where he is.
06:02
Michael Costello is a fantastically beautiful man, a designer by day and a scientist by night. This is Jonathan Cauteria, who is also a research scientist at Red Balloon Security, and here's me getting spanked on stage and such. And special guest appearance by Mikey Droptables, who is the mayor of Ponetown,
06:21
which is located between Quarth and New Jersey, so halfway between. And that's not all. So we have a lot of gear in front of you. We have the cast of machines, and this is stuff that you probably use every single day. You may or may not see them on your desk, but we all use it in our modern offices. So we have the 2821 Cisco router. This is probably something you'll find in the closet somewhere.
06:42
And you'll have one of my favorite printers, the HP 2055 LaserJet, and the Cisco phone, the Cisco 7961. And today we're going to show you a zero day that we drop at Black Hat, but we're going to show you here today. It's called the Cisco 8961. So this is the bright, new, shiny, sexy new Cisco phone
07:01
that's almost twice as expensive, but it's really nice. It also has a zero day that's fun to talk about. And we're going to show you something on the 1841 Cisco router, and we're going to talk very briefly about the work that we've been doing recently on the Avaya IP phone as well. Now, this is an image that we all know. You have your big, bad Internet, you have this firewall,
07:21
and inside you have the Internet where you're super safe. And Ponetown is on the right side of Internet, where Mikey DropTable lives. So he doesn't really know anything about your Internet. To him this is a mystery because he can't really send any packets to do recon through the firewall from outside in. This is how we always set things up. But he can make an educated guess that you probably have a printer
07:41
somewhere in your organization. So this is what he does. He's very clever. He's going to make a fantastically impressive resume, and someone in your organization is going to be so compelled by this resume that they're going to print this out. And this is a vulnerability that we talked about a year and a half ago, which has been patched by the vendor, where a print job can change the entire firmware on the printer itself.
08:02
And that's because you can pack firmware-updated files inside print jobs and the printer will just interpret the firmware update and flash its firmware. So that's been talked about. That vulnerability has been patched in theory. But once he gets onto the printer, now he has a physical stepping point into your Internet from the outside. And what he does is he will then...
08:22
Oh, so why am I talking about this vulnerability? It's been fixed. We talked about this at Chaos two years ago. But it turns out we scanned IPv4, looking for publicly accessible, vulnerable laser jet printers on the Internet. And after 14 months, 14 months after the initial security patch was released by the vendor,
08:40
and I think they released something like three dozen patches for every single laser jet model they made, we found that only 7.5% of all the printers on the Internet has been patched against this vulnerability. So if you find a zero day on something like Firefox or Chrome, you have maybe a weak window where that vulnerability is actually useful. But on the embedded side, this is absolutely not the case. And it's because we don't have the same update infrastructure that we do on general purpose computers.
09:05
So the vulnerability that I found on this laser jet printer a year ago, a year and a half ago, will still be something that your organization will probably be vulnerable to today. And that's just because people don't patch the firmware on their printers. It's difficult, it's cumbersome, and nobody likes to do it. So with this vulnerability,
09:22
what he's going to do is he's going to create a reverse IP tunnel out the firewall so that he can get command and control through this tunnel from outside, from PwnTown, into the Internet. And from there, he's going to send the printer a couple of commands to do reconnaissance on the network to figure out what other embedded devices there are. And using what he knows about the vulnerabilities and exploits he has about those embedded devices,
09:42
we're going to show how you can actually propagate through the network, compromising all of these embedded systems without ever touching a general purpose computer where you have host based defense of any kind. Right? So we've done a few of these. We looked at the printer, we looked at the router, and we looked at the various phones. And it turns out if you just sit down with an embedded device, if you focus on that one thing, finding vulnerabilities isn't really all that difficult.
10:05
And I have to put that in air quotes to me, it's not easy. But you have the physical device, you have all the time in the world, you can take it apart, you can figure out how it works. So the idea was that, and this is the page I put in, the first page of my candidacy document for Columbia, my theory is that polyspecies malware propagation is certainly coming.
10:23
We have the offensive capability to exploit all these different types of devices. The logical next progression would be to take one device and own another one. But it turns out, you know, polyspecies malware propagation isn't just trivial. There are some challenges that have to be solved in order for this to really work in the real world.
10:41
So my goal is, again, to own, let's say, the router and from there, put malicious implants in every single one of these devices, embedded devices in the network. And there are certainly some challenges, and we're going to talk about the three that we really had to solve in order to get this to work. And here's the reason why. So if you look at the cast of machines, we have Cisco's, we have HP's,
11:00
and we have Viya's, you know, devices from different vendors, these are all proprietary devices, you're not going to get the source codes for any of this stuff. The hardware is obviously all specialized. And on top of that, the architecture, we have MIPS, PowerPC, AVR, x86, ARM, all sorts of different ISAs. And after that, we have different operating systems. We have modified Linux, we have mystery operating systems that nobody really knows very much about.
11:23
We have things like iOS, which is proprietary and full of mystery. We have CNU that's kind of like Unix, but not really. And we have other things that are just complete mysteries, right? You know, look at the thing and say, does this thing even have a kernel? Completely unknown in some cases. So what I want to say is take a step back.
11:40
We're going to show you solutions to these problems, these challenges that we found for the offensive side. But we're really, when you solve the offensive problem, you're solving the dual of the defensive problem. So we are actually taking the insights we've gotten from building the embedded defensive technology software, Symbiote, to apply this to build an offensive demo. So we're using the same type of technology for offense and defense, right?
12:03
So the very first challenge here is a generalized way of modifying binaries. So I mean, once you have a device, how do I get the code that I want to run onto the thing in the first place? It's not like I can install that EXE on a printer or a router. That's just not going to happen. And it turns out we built this automation infrastructure called FRAC,
12:23
firmware reverse analysis console that we presented here last year. I definitely recommend you check that out. We've been building on top of it, and it seems to have worked quite well. So that challenge is more or less solved for us. The next part gets a little tricky. And here is the generalized execution problem. So once you have modification, you can put whatever binary you want in these devices.
12:43
Now, the question is, what do you want to execute? And by execute, I don't mean just single instructions, but I want to run semantically equivalent payload on environments that are vastly different, things like Linux kernel on MIPS or VX works on ARM, and have it all more or less do exactly the same thing without really a full understanding of the operating system at all.
13:02
Right? And I'm going to show you ways of doing that. Once you solve that, there is an even trickier problem of getting input and output to these targets. So you have OS and hardware agnostic payload of some sort. How do you communicate to it? How do I send traffic and receive traffic from this device without understanding how the network subsystem works?
13:21
Typically you figure out, let's say the indestriver works this way, I'm going to hook this specific call, and that's the way that I can see all the traffic that are coming in. But in operating systems that you really don't understand, this is very difficult. So let's talk about generalized execution first. Forget about everything you've ever learned about any operating system.
13:41
That's why we have this black box down here. This is like XYZ computer. You know that the memory is roughly organized in this way. You have some code and you have some data, dynamic data region. Somewhere in that dynamic data region you have what's generally referred to as IOMEM. And inside this code, it shouldn't surprise you, but embedded device firmware is really bloated.
14:01
It's got a whole bunch of code that really isn't necessary for the operation of that device. And by that I mean debug strings, IGMP if you don't use that sort of thing, multicast IPv6 if you're not using it, syslog, and a lot of dead code, redundant libraries that are linked in through the build process and whatnot. In fact, Mike and I looked at Cisco IOS, and it turns out if we wanted to rip out BGP and the HTTP server,
14:24
it looked like we were able to take out 40% of the IOS binary and still have that router come up and be fully functional if you just didn't want to use the web server or BGP. So there's a lot of room to play with. On the other hand, there are points inside the code that we know will be executed at a high frequency with high confidence,
14:42
regardless of the operating system. And here's a really good example. The e‑read instruction. Every time an exception comes up, the e‑read instruction is called. So if you just mapped out all of the e‑read instructions and hooked that, we'll be guaranteed perpetual control of the CPU. And there are a bunch of other places where we can look. Popular functions that are called all the time, mem copy, et cetera.
15:03
So put these two things together. We replace the dead code that's not necessary for the operation of the device, whatever it is. We replace it with our own payload. This payload is capable of restoring state between itself and the host program. So think about this as a binary scheduler. We use some other dead code for dynamic memory region, stack, heap, scratch area.
15:22
And the last thing we do is we hook a whole bunch of intercept points to guarantee that our payload is periodically invoked. And then that's really the solution to the generalized execution problem. You can compile the code for a specific architecture and inject it into the environment regardless of the operating system that you're working inside.
15:41
Now, how do we solve the input and output problem? I'm going to say that we can actually take the solution from the generalized execution part of this and at least solve the generalized input problem. The output is still a bit more difficult. And this is what we do. The payload, in this case, we choose to run is called the packet scrubber. We're doing an Easter hunt, essentially.
16:01
We're going to put this piece of code that will do a linear scan through the IO memory region of the device regardless of what the operating system is. We're going to hook a whole bunch of points that's going to guarantee that the packet scrubber will be hit periodically all the time. And as the device receives network traffic, packets are going to be copied into IO memory.
16:20
And in that IO memory region, we're going to detect well-known patterns that we define ahead of time that we're just going to call command and control patterns. And as the device operates, we pick out these patterns in memory and then we service them accordingly to our command and control scheme. And how do we get these patterns inside the IO memory range?
16:40
It turns out it's really easy. Even if you send a malformed packet of some sort, as long as the device doesn't have a lot of hardware acceleration, the entire packet is usually copied into memory range of that device and then the processor will analyze and decide whether it needs to discard it, quote, unquote, or process it. And as long as the thing is copied into IO mem, our packet scrubber will find it.
17:01
So we can send this command and control through, let's say, an ICMP message or we can send it through the content of a JPEG picture. As long as that is copied into IO mem, our packet scrubber will identify it. So take a step back and think, is this something that's specific to ARM? It's not. It'll work for MIPS, it'll work for AVR, x86, PowerPC, whatever architecture.
17:22
Now, is this something that will only work for VxWorks? No. It will work for Lynx OS, the Windows CE kernel, iOS, big iOS, the Linux kernel inside a DSP program. Right? This is really hardware and software agnostic. So for completeness, this is the command and control acknowledgement packet
17:42
that we defined for this demo. You have an envelope that starts with a predefined pattern, and in this case, I use ACAC, my initials, followed by some metadata, and then at the end, we have magic pattern prefaced by a checksum so we can validate that the packet hasn't been corrupted by something that we don't understand about how IO memory is manipulated.
18:00
And inside that, we have the command arguments, various payloads, and this is how both offensive and defensive demo will work. You'll see in a little bit. So put that together. You have the packet scrubber running, you have CNC packets coming in and out of IO mem, and as these packets are hit, we identify it, we service the command and control, and that's how it all works,
18:20
and we have it working on MIPS, ARM printers, routers, phones, and you're going to see that today. And I want to take a moment. We found out about Barnaby Jack a few days before making this presentation, and we were all super shocked, so we wanted to do something for him as a tribute in this presentation. So we've actually implemented the Barnaby function,
18:42
and what the Barnaby function does is it takes arbitrary embedded devices as input, and it puts his face into the working memory of those devices. Thank you. We're not done. We're not done. We've actually made a modified Barnaby function prime, which does exactly the same thing, but in a permanent way.
19:01
So to show that not only can we do this through our command and control, we can actually affect real permanent physical destruction of all these devices through our command and control. So here is a Cisco phone with Barnaby Jack's face right past the Linux loader. Here it is. Physical destruction of prime. So now I want to talk a little bit about how our demo will go.
19:21
So Mikey dropped tables on the outside, eyeing the printer, owns the printer through this reverse IP tunnel, through this resume, establishes the reverse IP tunnel, sends command and control down to the printer to do recon. Recon will bring back active devices on the network. We're going to do a whole bunch of fingerprinting to figure out the devices you're actually looking at, and once we have, we figure out
19:40
whether this is a Cisco router or an HP printer or a Cisco phone, et cetera. And using what we find there, we're going to start dropping exploits onto these things and putting our malicious implants that will give us the same command and control capability on all of these devices. Okay? And before we jump into the demo, I really have to say, I'm not allowed to say a lot about what we have done with Evaya.
20:00
That's coming soon. But the JTAGulator, I don't know if you guys saw the talk about it, is the super awesome sauce. Like, this is the coolest piece of hardware I've seen in a while. If you see Joe, get him, like, a latte or something, but buy, like, ten of his boards. This is really cool. And his board made our work really possible, so big thanks for Joe Grant.
20:20
So now, without further ado, Michael is going to start writing the demo, the offensive demo. All right. I just want to say, I really love this community. It's 1 o'clock, 1.30 now, on a Sunday afternoon, the last day of the conference, and the room is packed. I mean, this is great. Like, you should all give yourself a round of applause, please.
20:45
And there's going to be a little bit, a very tiny bit of audience participation here, so, you know, when that happens, please, everybody just shout out the obvious answer. All right, so we're going to Pometown.
21:01
Okay, so we're going to, so everything that we're doing here on stage right is Pometown. So this is where we're going to put our offensive payloads, and then after that's done, then we're going to come to stage left over here and do defense. So I'm going to bring up my server. We've already sent our resume to the printer. It has been, it's rebooted,
21:23
and it's going to build its reverse tunnel connection out through the firewall, out to where Mikey Drop Tables is living. So we've got our tunnel connected, so we can now bring up our offensive console,
21:40
and already we see that we have the printer in here. And so everything that we're going to be doing here, and all you see is at the beginning, but every command that we're doing, or almost every command that we're doing, is we're sending commands through the command and control tunnel to the printer to have the printer instructed to do different things. And so what might be the first thing that we want to do?
22:02
So we've got our printer. We know about this on the network, but we want to find, we want to do reconnaissance on the rest of the network. So we're going to do a SYN scan on the printer on port 23, and we're instructing the printer through the tunnel to do a SYN scan. We've spoofed the IP address so all the SYN acts
22:22
and all the reset packets are coming back to us, and we can find out a number of devices on the network. And right now we see we have a number of IP devices, and I apologize for the formatting for the screen size, but another thing that you're going to notice is that the printer now has a fingerprint, and this is a memory fingerprint.
22:40
So when our rootkit is on there, we can do a checksum over memory and then use this fingerprint as a key into a database that we have precomputed offline a number, a bunch of information on these devices. And here we know that it's an HP LaserJet 2055 DN running firmware from March of 2010. And this might be another good time to,
23:02
or this might be a good time to note that this work that we're doing on the printer is nothing new. This is not a new exploit. This was presented at 28C3, print me if you dare, and there was an NDSS 2013 when firmware modifications attacked paper. Please read that and watch that. We just were making the printer do a lot more things during this presentation.
23:22
So now the next thing that we want to do now that we have an idea of some devices on the network is that we want to find out a little bit more information. We want to get some, we have some layer 3 information, we want to get some layer 2 information because that's going to help us in the next stage of our attack. So we're going to ask the printer to give us a IP to MAC address mapping of these various devices.
23:43
And then looking at the first six bytes of the MAC address, the OUI, we can find out what vendor these are. And we see that we have an HP, we have a couple Cisco's on here. And we also have one target on here, Recon 4, which is the Cisco. We, for the purpose of the demo,
24:00
we know that this is an IP phone. So we're going to rename Recon 4 to Phone 2. And what we're going to do is we're going to try to SSH into this phone. And we're going to try to, because we know that the phone is going to be running SSH. And we're not going to try to log into the phone
24:22
by guessing a user name and a password. We're going to take advantage of a feature on these phones is that every single time you attempt to SSH into them, they ask their preconfigured TFTP server for an authorized keys file. So we can do key-based authentication on this. What we're going to do, though, is instruct the printer to ARP spoof the phone,
24:42
making it think that a device that we control on the network is in fact the TFTP server. And that's going to be the printer. So one of the things that the printer does, in addition, as part of the packet scrubber, looking for these magic patterns of command and control packets, is it looks for TFTP authorized keys request files. And it already has, in memory, a nicely formed one packet TFTP response file
25:03
of an authorized keys file. It just has to populate a couple of fields. But which key are we going to use, Mike? We're going to just use a key that we built ourselves. Oh, so we would be able to authenticate without it. That's nice. So we're going to poison phone two
25:20
with the IP address of the TFTP server that we learned through reconnaissance. But first, before that, I need to bring up a proxy. I'm going to wait for the... Oh, the proxy already connected. Very good. And we're going to... So we're going to ARP poison it
25:40
and do it again for good measure. So now Mike is going to SSH through the local host in Ponetown, through the proxy, through the printer, to the phone and spoof the authorized keys file as it's being requested and then get console access to the phone from the Internet through the printer. Okay, and if this works, we should get a shell login prompt and not an SSH password prompt.
26:03
Yes. Ta-da! Wait, he's typing a super secret password. How do you know what the username and password is? Cisco documentation informs. But can you not just change that password? No, because if you change it, then the checksum changes and the phone resets itself.
26:22
And the password comes back to the way it was before. Oh, that sucks. Okay, so this we find out is a Cisco 8961. It's running 921 software. This is recent, not the latest software on it.
26:40
There has been a release or there will be forthcoming release that kind of puts epoxy in some of the holes on this but doesn't actually address the problem that we're going to show you all today. But here we notice that this is a phone. This is a general purpose computer. This guy still looks like a phone that's running a Linux kernel on here. We're not going to go over everything that we tried and failed to do to get rid of this thing.
27:03
We're going to cut right to the point. We found after looking at how the phone boots up that it uses NAND devices. And one of the things that we noticed and this is just one of the devices.
27:22
Does anybody see a problem with the permissions? Just shout it out. There you go. We did this before seeing Monks talk about NAND. Flash vulnerabilities. We could have done this in a lot more elegant way. But he didn't send the slides before and we didn't know about it. So we did this in the most monkey way possible.
27:41
So if anybody didn't hear it MTD4 has world right permissions on it. And what we can do is if it has world right permissions as an ordinary authenticated default nonprivileged user we could write to this device. In theory, but Mike, we don't have any tools to do that. We're going to have to compile it or download it.
28:01
How are we going to do this? Actually it's really convenient that Cisco had already packed for us a number of Flash utilities so we could erase the device and find out information. No way. So they give us permission to do it. And the tools that allow us to do it. There's not only Flash erase and info but we also have a number of NAND tools.
28:22
Wow, that's really useful. This file system is going to be megs and megs large. How are we going to ship it to the phone? How are we going to pack it? It sounds all very complicated. It really isn't. You can do all of this stuff offline and you can pack one file in a very small file system fit into one 4K block and transfer it over the phone using TFTP.
28:42
Which is also on the phone. So you don't have to compile any of this stuff. All the tools are there. So there's the old day. When I found it, this was a little disappointing almost. We've gone from the CNU kernel which is a proprietary thing that very few people have looked at to a much more secure environment the Linux 2.6 kernel with all the security patches backdated to the thing
29:03
and yet, only this phone has become somehow easier. So something is wrong here. And it's just human error, really. So what would somebody want to pack into one of these files? Maybe a little root popping, set UID root program. So if we look at who I am now,
29:23
I'm default. But I really don't type this slow. Everything is going over this proxy. We're root. Okay, so that's all it took.
29:43
You didn't actually have to compile anything. You just log into the phone, you look around and build this 4K file system and there you go. And now we're going to switch over to our command and control demo. For good looks, we promised that this is going to be a command and control infrastructure. Oh, by the way, I have to say, now that we're on a Linux operating system,
30:01
we're home free. We can start doing all this stuff that we know how to do. So now going from a Linux phone to compromising the printer using the initial attack vector becomes all of a sudden very simple. Now we're going to load up all of the devices we have our command and control implant on and for good measures, we're going to add two other devices, the Cisco 2821 router and the Cisco 1841 router
30:21
just to show that our command and control will work on phones, printers, and all sorts of different routers as well. Okay, so through the tunnel, the first thing that we want to do is heartbeat all the devices, see if our rootkit is listening. And of course we're also doing this again through the tunnel that the printer has established. Okay. So a number of data gets back from it,
30:40
everything responds and says that we're here. Again, with the memory fingerprints that we were able to take, we can look up a bunch of info on these things precomputed offline. So for instance, let's instead look at the 2821. And we see that we know that it's running
31:02
MIPS 4 Big Endian, we could find the addresses of various functions. Here we've decided to redact it. Oh yeah, so we got lawyer pwned and we couldn't show you any of the actual offsets, but they're there in our database. Sorry. Okay, so now we can do read and write, right?
31:20
So let's rock out the Barnaby function. Okay, so let's just go directly to reading and writing. So before running the Barnaby function, just so in case anybody doesn't know, typical Cisco router behavior, if you type in enable and you type in the password wrong three times, this is bad secrets
31:40
and you're just a regular privileged user and if you do a show version, you just get to see what the router is running. But if we run the Barnaby function, this is doing a number of writes to memory. Let's do it on the 1841 as well.
32:02
So now if we do enable bad secrets, but notice that the prompt has changed and if we do a show version. That's not supposed to happen. Things are weird and terribly bad in the routers. Wait, wait, that's not all, so we're going to do show version, right? Yeah, and if we do show version. Oh, look at that.
32:21
We've got Barnaby's face in there. And it's in the 1841 as well. Right, so we can do this on, and this is because the command and control works the same way on different architectures, different operating systems. And we're just given an arbitrary memory write command and we're writing it to the specific location.
32:41
And the reason why we know the specific location of the string is because we actually have precomputed this assembly of the specific iOS version that we found that we know this router is running through the fingerprint that we've exfiltrated through the heartbeat. And we can do this at scale on all of the images from all the devices that we have under CNC. Okay, let's move on to defense. Yeah, so let's do the defense demo.
33:01
We're running a little bit short on time, and as promised, I'm going to spend as much time as I can on the defensive side. So I want to say, well, okay, population PwnTown without Defense 6, right? Terrible. Oh, another fun fact. It turns out the Cisco, the HP printer is really quite a capable piece of device. This thing can send about 15,000 packets per second, right?
33:21
And you can send terrible things and you can just yak yak yak all day long. And it turns out if you want to DOS a 2821 router using a single printer, you can. You can peg it to 100% or 98% CPU utilization. And that's one printer. Imagine what I can do with two printers. And we'll show you that if we have some time. Right? Wins all day.
33:40
Okay, so now I want to show you the defense demo. And this is the thing that I've been spending the last five years of my Ph.D. career developing. This thing is called software symbiote, and it uses a lot of the same insight that you saw on the offensive side to develop dynamic firmware integrity attestation in arbitrary legacy embedded devices. We're showing you demos that run on ARM, on MIPS, on Cisco phones,
34:01
on Cisco routers, and then on HP printers. This is really not something that, oh, and we require absolutely no vendor intellectual property. We take the binary that comes from the vendor. We require no source code. We require no hardware modification. This is not a timing-based attestation method. This is not a static attestation method. This is not proof-carrying code in any way or inline monitoring.
34:22
This is something very new that is very flexible, and you're going to see a demo of this thing working right now on exactly the same hardware that you saw the offensive demo on. So we're going to get out of Pone Town and go somewhere else. And then as Mike is setting up,
34:40
we're going to run through the first phone exploit that does kernel memory modification, and we're going to bring up the symbiote alerting console that's going to show us dynamic updates to the checksums of the static regions of code inside all of these devices. So any piece of code that is modified within static code regions of these devices will be detected in approximately about 100 milliseconds
35:02
of detection latency, depending on the speed of the CPU. So the routers will have 100 milliseconds or so. The phone actually has a much faster CPU, so we can actually detect it much, much faster. Okay, so we got in here. We added our routers, and again, I apologize for the formatting.
35:22
So right now we have the phone, the router. There's a printer at the bottom. We'll try to add that in individually at the end. But for right now, we'll show you the phone and the routers. And so these are routers that are running our symbiote code. This is all work that's been funded by DARPA, IARPA, the DHS. All of these things are packed together with a utility that we built called FRAC, funded by CFT.
35:43
So thank you very much, Mudge, if you're in the audience or wherever you are. All right. So what we're going to do is we're going to go through exploits that we've demonstrated before, shown before. There's not much new here. So the first one, but what is new here,
36:00
is the symbiote, depending on all this stuff. So the first thing that we're going to try it on is the Cisco IP phone. We're going to SSH into this thing. And so the exploit that we're going to be showing here
36:21
is the same one that we showed at 29C3, hacking Cisco phones. So if you want the details on that, please watch that video. You can find it on YouTube.
36:43
And then the way that this demo works is that we have a file called pwnbin. What we do is we change the way that setuid responds so that we get root access. If you look over here, the Cisco phone, we have one checksum and the secure state is secure. But after we go to the phone and we run pwnbin,
37:00
we can then log into the phone and we have root access. Again, please watch the video to see the details. But now we see that the secure state has changed the pwn because the symbiote detected the change that we made in firmware. And the checksum has changed. And you can see the alarms coming periodically. We actually had to slow down the alarms coming from the phone,
37:21
otherwise it would just flood the screen. So the alarms can actually come much faster, but for the sake of the demonstration, we had to slow down the refresh rate a little bit. Okay, and here we're just going to show the 2821 router because of the screen formatting. But we're not going to be demonstrating a Cisco iOS exploit today. Along with the symbiote, we made a small change
37:41
to the show CDP neighbor command, which in addition to showing us our CDP neighbors, it also makes the memory modification change that was part of the barnaby function to bypass enable authentication. So if we run show CDP neighbor here, we could see that the router 2821 checksum has changed and it's changed state to pound as well.
38:03
Let me see if I can bring up the printer quickly. Let's do the 2821. It's off the screen. It'd be hard to see. Well, so what you're looking at here are functionally equivalent devices, but these are very unique devices in the sense that the phone and the printer and the routers you've seen
38:21
are literally the only ones of their kind in the universe that actually has host-based defense in real time as the device is running that will allow you to have alerts that tell you whether the phone and the printer and the router has been exploited with approximately 100 millisecond latency. This is something that's never happened before, and you folks are the very first people to actually see something like this.
38:44
And this is not something that we developed specifically for a specific model of a Cisco or a phone or a printer. This is generic technology that can be injected into legacy embedded devices without requiring any source code, any hardware modification. So this is something that you can see in a car. You can see in something that controls the Predator drone
39:03
or the Mars Rover, which also runs the Xbox, by the way. The same operating system as the printer. So that exists. And with the printer that has a very small proof-of-concept symbiote running into it, we can use our command and control rootkit that we had demonstrated earlier. And if we write an image of Hello Kitty into it, the state should change.
39:36
Sorry. Oh, there. So we made a change in memory.
39:40
The symbiote picked up on it. Ta-da! So that's it. That's our defensive demo. I just want to say, you know, we've accepted host-based defense on desktop servers for a very long time now. And we haven't really started thinking about ways of seriously defending embedded systems against this type of attack. So you've seen in the last few years that exploitation of these devices
40:03
is no longer a myth. It's no longer that hard that people aren't looking at it. Now hopefully you saw here that the polyspecies malware propagation part of this thing is also not a myth. You saw it live on stage. You saw a printer on a phone and malicious implants on routers, et cetera. So I think this is the real time that we need to start thinking about
40:22
real ways of getting this technology out, host-based defense on the defenses that we use every single day in our offices, in our defensive networks, et cetera. So we have a few more minutes. I'm going to take Q&A in the pool. So we're going to have some time for that. But before, can we run the DDoS, the denial of service demo?
40:43
Who wants to see a printer peg a 2821 router? All right, let's do it. This is a lot of fun. So right now Mike is going to send the denial of service attack command to the printer. And what the printer is going to do is send as quickly as it can
41:03
malformed TCP packets to the OSPF hello address in multicast. And when the router sees that it doesn't know what to do and it gets all scared and the CPU goes all very high and bad things happen.
41:40
Ta-da!
41:41
So that's not good. You shouldn't have your router running at 98% CPU utilization. And this is all happening from a single printer. So imagine a printer and a phone. We'll show that next year. Okay, so that's our presentation. If you want to know more about Software Symbiote or our presentation, check out Red Balloon Security.
42:02
We have all of the academic papers that discuss exactly how this works, the performance constraints, the security promises and limitations of our technology. And some demo videos. And of course, this slide. I don't know if I have time to take questions, but Q&A area in the pool. And it will probably be about 30 minutes.
42:21
Yeah, about 30 minutes. We'll pack up. We'll go to the pool. Thank you very much.