 How's everybody doing? Good? So all the opening acts are finished. It's now time for the headliner. Before we get started with the last talk, which is going to be awesome, I need to remind you guys that when we finish this, we are going to need to dump the room so that we can prep for closing ceremonies. They got to move air walls, do all that kind of stuff. So when we get done, I know you'll probably have some questions or something like that. Try to catch them in the hall and remember to exit out the back. Just as quickly and orderly as you can. That will help us get everything set up and get everything squared away for closing ceremonies. Make sense? All right. Now, since this is also the last time I'm going to get to talk to you guys, probably until next year, I want to thank you guys. I take vacation for this. How many people take vacation for this? Hell yeah, you're not going to get that out of a lot of other security cons, I don't think. That's why this thing is the best in the world. Yeah? There we go. All right. Let's get this thing started. Zeke is going to pop a couple boxes and that's going to be awesome. So let's give Zeke a hand. The last talk of the day. Thank you. All right. Thank you everyone for sticking around for my little talk. As the man said, I'm headless and this is my talk. I swear, I swear I'm going to try not to sing salt and pepper. That's a lie. I'm totally going to sing. So yeah. Let's talk about salt and pepper. Let's talk about UPMP. Okay. Introductories. I'm a security researcher at the awesome HP tipping point. I'm on the DV Labs team. HP tipping point. Before that, I was at rapid seven. Rapid seven. Before that, breaking point. Hey, somebody. So yeah, I've spoken at a few conferences before. This is actually my second time speaking at DEF CON. So unfortunately no shot for me. Even though I think the last time didn't even count because it was like the little time slot and it was many years ago. So I think I should get another shot. But yeah. So I've been around a little bit. Recon, Insomniac and Ruxcon. I did both of those which was really awesome. But anyways, I'm more excited to be here. So in my spare time, I do the same thing that I do professionally because I really enjoy it. Which is just tearing devices out of my house and seeing if I can break them, which tends to take off my wife and kids or whatever. I read some comic books. The jewel of my collection is a first printing of Alan Moore's Batman The Killing Joke. Really awesome. Which I actually bought for 75 cents. That's neither here nor there. So anyways, little fun fact about me to give you an idea of the kind of person that I am, I guess. I once got a job at a police department when I had four active warrants out for my arrest. It was kind of a hiding in plain sight, I guess. Nonviolent crimes. I did not. Okay, so let's get into it. So yeah, Internet of Things is a thing, whether we want it to be or not. Putting a network interface on a random device is very in fashion right now for some reason. Even if it has no reason to have an Internet connection. Even if it's not a good idea at all. But yeah, basically all of our devices are smart devices now. But they're not actually that smart. They need a very simple way to communicate with each other. They all need to speak the same language and be able to understand each other without us getting involved. And that's what makes them smart. So that is basically handled with soap services, which we will talk at length about. But anyways, very broadly they're very super talkative services. You can jump on an unknown network, send out a few packets, and all of a sudden you'll find these devices and they will tell you everything about who they are, what they can do, what you can do to them. Really awesome. And you too will be able to do that by the end of this talk. But yeah, and also a really important part of these is the whole working together without getting us involved means things like authentication doesn't come into play because you don't want to bother your users with entering passwords and things like that. That would get in the way of the seamless experience. So I do have to talk about a couple of definitions real quick. These terms are sometimes muddied up and used interchangeably at times. I'm probably going to do the same thing in my talk just because there is so much overlap in this protocol. But basically it breaks down like U-P-M-P is what I consider the UDP side of things, the discovery side of things. SSDP is kind of hand in hand with U-P-M-P. And then SCPD is more on the definition side when we move over to TCP which will become clear in a moment. And then SOAP is going to be like the control where you're actually sending actions to the device. All right. Let's talk about all the good things. I'm warning you now this next part is going to be a little bit dry. But I'm a nice guy so I put a TLDR slide at the end. So until then if you all just want to put your heads down and relax, I'll be sure to wake you back up when we get to that point. Okay, so U-P-M-P operates on UDP port 1900. Response to multicast packets which comes in very handy as you will see. U-P-M-P.org defines the stack thusly. So they consider U-P-M-P as kind of like an umbrella term encompassing everything else. So it's actually six layers to the stack. There's a layer zero but I didn't want to go through having to explain how to get an IP address because I think that's kind of superfluous. If you don't understand how to get an IP address you're probably not to this point yet. Anyways, so discovery, description, control, eventing and presentation. I am not going to talk about it's kind of out of scope for this presentation. That's going to be like eventing is like listening for events sent back from the device. Presentation is presenting the SOAP actions in like a UI to the user which I guess means the web management portal because that's the only thing I've seen that even comes close to doing something like that. So anyways. Alright, U-P-M-P discovery. This is everything you need to perform U-P-M-P discovery. There are actually two types of discovery. The left side of the screen is passive discovery and the right side of the screen is active discovery. So with passive discovery you can just sit there and listen for packets coming in on UDP port 1900 and if you see these notify things you can just pull out the location URL or the URL in the location header and just make a note of it or if you want to take a more active approach you can send out what's called an M-search request and you'll get an HTTP reply. You'll notice all of these are basically the HTTP protocol over UDP. That's intentional. It's very, very similar. And then again in the response that you got to the M-search pull out the URL from the location header. Basically this guy is your new best friend. Any network that you connect to you should send out an M-search probe on and you will be amazed at the devices that just happily tell you like, yeah, here I am, talk to me, talk to me. So yeah, any network you're on, you know, your home network, your business network, a hotel in Las Vegas, I don't know. So if you pull out the URL from the location header and you do a GET request what you will get is the description layer. So this is going to be a huge wall of XML that basically defines everything about what the device is. So you're going to see the version info which is always UPMP1.0. It's just whatever version of the spec they're using from UPMP.org. I've only ever seen 1.0. And then a bunch of device definitions which when we go to the next slide you'll see what this looks like. It really tells you like exactly what the device is. It's really great. I mean it can be spooked or whatever. But anyways, the important things to pull out is you'll see the services list. It's going to list all of the SOAP services that are listening on the device. And that's going to contain the service type, SCPD URL which we're going to need later on, control URL which we are also going to need later on, and event URL which we don't care about. All right. I don't think there's any way anybody could possibly read that. But I'll just do my best to be descriptive. So at the top there's the version block like I was saying. And then you'll see that it's, I wish y'all could read that. But anyways, can anybody read it? Hey, there you go. So yeah, you could see like this was a mystery device. We had no idea. We just sent out an M search and followed the URL that we got back. And all of a sudden we know that it's a Netgear 3400 router because it told us so. Which is great. And then these three fields are the service type which we're going to need when we're composing our SOAP control. And then the SCPD URL and the control URL. All right. So if we follow that SCPD URL what we get back is another wall of XML. And this one again contains the version info. This one is where it starts to get really interesting because this is where the device tells you what it can do and what you can do to it. So you're going to see a list of actions. And these will contain the arguments that the action takes. Whether it's an input or an output. So me sending to you or you sending to me. And then variable definitions where it gives you the name of the variable and then ties it to the data type at the end. So literally tells you everything you need to know. Makes it really, really easy. And again this is what that looks like. These slides are on the CD. So. But yeah, so we're going to see this as set default connection service and then takes an argument of new default connection service. And down at the bottom the new default connection service is a string type. So if you want to set a new default connection service you give it a string argument in the new default connection service action argument. Okay. So finally we get to talk about SOAP. This is where things get really exciting because after all of that information gathering we take all that put it together and actually get to send commands to the device and have it do what we say. So with SOAP the front end is very well defined. Always going to be basically the same idea. The back end you never know what you're going to see. It could be an RPC service or a CGI script or a shell script. You really have no idea what's running on the back end. The way SOAP works is again XML sound familiar. You form a post request that you send to the control URL that we got in one of the previous steps. And the body of the post request is going to be what's called the SOAP envelope which is basically just an XML formatted API call. That's going to have the action, the argument, and the type and all that. Easy peasy. All right. What about this one? Can people read this one? Kind of? Sort of? No. Okay. So the things that are highlighted in red are from the description first off. The things that are in blue are from the SCPD, the action definition. So we're putting them all together. The things in black are fairly standard. Going to be the same over and over and over again. So yeah, this is how to SOAP. Okay. Everybody can start paying attention again now. This is the TLDR UPMP to SOAP flow chart. You start out by sending out your M search request. You get back a 200 okay that has the description URL. You get the description URL. You get a 200 okay that has the service type SCPD URL and control URL. Send a GET request to the SCPD URL and then you get back another XML that has the action name and the arguments. Put all that together in a POST request to the control URL and hopefully you get back an HTTP 200 okay and the device executes whatever you sent to it. More often than not, you're going to get a 500 error because you did something wrong. Okay. Even better screenshot on this one. So this one I actually had no intention of you guys being able to read. I just wanted to put this on there to show you. It's a screen capture from the official SOAP specs on UPMP.org. This just gives you an idea of the breadth and depth of things that are already officially defined in the UPMP.org specs. It runs the gamut from the obvious things like you can automate control of your audio video systems. That's when you've got like a wifi remote to control your TV. Home automation we're seeing more and more of that with motion sensors and air conditioner controls working together to turn off your AC when nobody's home. It starts to get a little bit questionable when you start talking about things like physical security systems. I could kind of see a purpose for that maybe. Like being able to unlock your door from your cell phone might be kind of cool but might be kind of dangerous also. And then we start talking about how they're defining SOAP controls for like SCADA and ICS because why wouldn't you want to be able to control your nuclear power plant from your iPhone? Seems like a perfectly good idea. And this is just what's officially defined. It's a whole can of worms when we start talking about vendors who decide to roll their own. You never know what's going to be out there but the handy thing about SOAP is that it tells you what it does. Okay, so great. You know this is all awesome. We live in the Jetsons basically. All of our devices happily talk to each other and work together and everything's great. Have your toaster turn on the lights, set the TV to the news channel and send you a text message when your breakfast is ready. That's not even a joke. We can totally do that and it's awesome. Right? Everything is sunshine and rainbows. The end. And the bad things. Okay, so now we have to talk about security obviously. So these things really have the deck stacked against them from the get go. First off they're embedded devices. So you know we're talking about limited memory and space. So you're not going to see exploit mitigation, memory corruption mitigations. Lots of times the board development and the software development are two completely separate companies. Like the board is just cranked out by some hardware company and then different software vendors put their software on top of it and it's not always designed to go on top of it. You start seeing a lot of the same code especially when you consider SDKs released by the board manufacturer. The software manufacturer will be like that's great. That's exactly what I need. Just use that every time. But yeah, all in an effort to keep costs low. And then when you start talking about deployment, the attack surface is growing bigger and bigger and bigger as the Internet of Things is growing bigger and bigger and bigger. So we've got millions of these devices on the Internet from every vendor you can imagine. Like, I don't know. I think even Nike is doing things on the Internet of Things now. But yeah, so I mean it becomes really impossible to keep on top of firmware patches especially if you're not able to actively push out updates to your customers. You have to rely on them to search you out and pull down the firmware update. It's never going to happen. So this slide has some statistics on it that I pulled out of my ass. I don't know. This slide just felt like it needed some statistics. So I put some on there. But yeah, so I mean, you know, XML parsing is really hard. It takes a lot of resources. And there's a lot of bugs that come with that. You need to parse it properly. But yeah, in 2013, 2.5 of all CVEs were XML related. And of those, almost 36% had CVSS severity of 7 or above. Yeah, I know, right? Okay. So with all that in mind, it's no surprise at all that there's a huge attack surface here spanning like every step of the UPMP stack. So yeah, we start seeing all of the standard old school volums coming back again in a brand new protocol like HTTP header parsing, command injection, XML parsing, and then you start seeing new things like SSDP header parsing, XXE volums, XML external entity expansion. So what I would like to do now before I get into the really cool, awesome, fun stuff, I want to give you guys an idea of the attack complexity that we're talking about here, which is a pretty low bar, as you will see. So I'm going to go through and talk about some examples that have already been disclosed. So first off, can't talk about UPMP without mentioning the work of H.D. Moore from a couple years back. I'm sure you all heard about it. He released a slew of vulnerabilities. CVE 2012, 59, 58 was one of those. Basically, in many UPMP, I think, they were taking the ST header from those notify packets, or from the in search packets, sorry, and calling stir-in copy, which is good in theory. Stir-in copy is better than stir copy. But the argument that they were using for the length to copy was based on the input that you were sending to it. It was based on the number of characters between colons and the thing. And what you end up with is this, which is the exact same kind of vulnerability that we've been seeing since the 90s. You know, the kind of lessons that we've learned countless times, and now they're coming up in a brand new attack surface. The one thing to note about this is that this is a multicast packet. So you can just jump on a network and send this out, even without a working exploit as the payload, and it's just going to bring down devices all across the network, anything that's vulnerable to it. Another example of UPMP vulnerability, this one was discovered by Zach Cutlip, who I'm actually going to mention again later on. This is an example of a command injection vulnerability in a D-Link, D-I-R 815. D-Link has had a terrible couple of years. I don't know if you guys keep up on these kinds of volums, but they've gotten really, really good at response. They are one of the quickest vendors to respond to vulnerability disclosures now because they have had a lot of practice. But yeah, so here's a command injection vulnerability. Again, the ST header, this time they feed whatever you give it to a shell script called M search with no validation or sanitization. I'm sorry, I always say sanitation, so I have to enunciate. So yeah, and what you end up with is this, again, multicast packet, so you can send this out on a network, have no idea that these devices are even on the network, and you're just popping boxes right and left. But yeah, so the ST header, UUID, colon, whatever command you want to execute on the device. All right, this one was a pretty recent one from this year in the Airtese RT series devices. Again, disclosed by owner Allen Bell. There's the link to the volume. This one was even more old school because we're looking at a MIM copy buffer overflow. MIM copying the action that we're sending in a soap request into a statically sized buffer, which looks like this. So you'll see the soap action with the service type, and then the pound sign, and then more than 2048 bytes of data, and then it will overflow the buffer. Typical 90s wounds over and over and over again. Broadcom also has had a few wounds disclosed recently. This one was in the set connection type action of the new connection type, or sorry, the new connection type argument of the set connection type action. Again, format string vulnerabilities are back, apparently. Same old, same old. Sorry, I'm starting to get bored with this myself. So this is kind of the example of this vulnerability is a little bit arbitrary. But because this was in Python's soap libs, it was a pretty big deal, at least I thought so. This is a good example of an exit Z-vulm. So he wrote basically an echo service, so it would just echo whatever you sent to it. But you'll see the external entity defined at the top was a path to Etsy past WD, and so the service would be like, I'll expand that for you and send you back the contents of that file, just fine. Shout out to my homie in Austin, Brandon Perry. This was a pretty cool one. It was a simple command injection in the host name argument on F5 I control devices. So shellcommand.whatever.com. It's my host name. Okay, is that cut lip again? This is a great series of blog posts I definitely recommend anybody go out there and read them. He basically takes some, I don't know if it was intentionally broken, but it was definitely broken code that was shipped with the device. And basically like goes through and fixes the code to be able to upload firmware images that whatever firmware images he wants. It's a wild ride and a great series of blog posts. But anyways, that was a soap bone also. Okay, now demo time. Sorry, that caption says the things you own will end up owning you. Okay. So how about that? Can people read that? Because I can zoom that. Good? Okay. So when I first started this project, I wanted to write command injection fuzzer. Which I did after having to fix up the Ruby soap parsing libs which are woefully out of date. I don't think they're even supported anymore. The project seems like it hasn't had an update in years. And this is soap for R by the way. So I basically kind of forked it and then made a bunch of changes that I can't remember what all I did. So I haven't been able to release these libraries. But anyways, I wrote this fuzzer to the point where I could run it against something. And the very first thing that I ran it against found a vulnerability. A command injection vulnerability. It's just that easy. So the device that I ran it against happened to be this trend net. What is it? A TW731BR Wi-Fi router. Which I just happened to have laying in a pile at my house. I found the vulnerability in that. And then after researching it with enormous amounts of help from my buddy Josh Smith of the ZDI team, we found out that it actually was not just in this device. It was in a binary that was part of the SDK released by real tech. So all of these real tech chipsets that used this SDK were vulnerable. Ended up being thousands and thousands and thousands of devices across multiple manufacturers. Largely still unpatched. I think D-Link actually released a patch. Trend net is actually not vulnerable to it because in their latest firmware they don't use mini-IGD anymore which is where the vulnerability is. They use mini-UPMPD which used to have the vulnerability but it had been patched. So anyways, the details of the vulnerability, again it's pretty, okay, so hold on. First before I start the demo I have to mention one more thing. This was my ugly version of this exploit. M1K3 Mike released a much, much cleaner, much nicer version of this exploit and put it in the Metasploit framework. But I tried his in my hotel room this morning and even though I've tried it before and it worked beautifully before, it did not work in the hotel room and that's what accounted for me and this one did so I'm using the ugly version. So this, oh, hang on. Dude, I'm sorry. We're looking at the wrong thing. Sorry. This is what we should be looking at. Sorry about that everyone. Okay, so this is a vulnerability in the ad port mapping action. This device can be used in as an internet gateway device where say somebody comes over and puts their computer on your network and they need port forwarding for gaming or whatever. Their computer can automatically forward ports through your firewall on your router which is awesome, great idea. But one of the one of the actions in here is this ad port mapping and then you will see right here in the new internal client, it will just execute whatever command I want. So without further delay, let's go ahead and try this. Okay, so this is going to send a bunch of ad port mapping commands over and over and over again because I have to build up my payload little by little into a temp file and then mark it executable and then I can run it. So it takes a little while and it's blind exploitation so I can't tell if it even works and tell it works. So let's see if it's ready. Almost. Fingers crossed everyone. Any day now. It's connected. Hey, there we go. Okay. Thank you. Okay, so I can't run like ID or who am I? But I can show you that every single process is running as root including my BNSH down at the bottom. So yeah, root command injection on thousands and thousands and thousands of routers largely still unpatched. Some of them allegedly are even affected over the WAM port although that is not confirmed not true in this device and not substantiated in others. So yeah, there's that. Next demo. I wanted a really visual way to demonstrate the danger involved in giving this amount of unauthenticated control over these devices to just any random person on your network. So when I was looking through the official specs I came across this set AV transport URI action. Basically what this does is it takes a URL and media share. Just like a media file, it could be a gif, a song, a movie, whatever you want and sets that as the transport URI on the device. And then there's a play action where you then play it. So that's pretty great. So I had an idea to make a script that would, this was the one that I was showing you earlier, that would basically scan a network, find all of the TV's and Blu-ray players, anything that implements this set AV transport URI and brick roll them. So this is the sound. So yeah, this works on like Samsung, Sony, Panasonic. You name it. I am going to show you a little video now. This working. Sorry, my wife wouldn't let me bring our TV with me. I don't know. Is the sound, hopefully the sound is working on this? It's really not going to be funny if the sound isn't turned up on my laptop. Okay, so anyways, I give it a media share URL. It scans the network. It starts listing out all of the UPNP hosts that it finds. And then you'll see pretty close to the bottom, it'll say found one, ready to roll. And then all of a sudden the TV picture changes, even though I was just watching TV. So, you know, I don't condone this kind of behavior, but one could imagine going into like a, you know, a large electronics consumer store. That kind of thing. You could even, from a more malicious standpoint, if you found a bug in like a video codec or something like that, this would be a great avenue to force the device to render it without any user interaction. So, yeah, it's dangerous and it's stupid to give this kind of control to just anybody. And that's kind of the conclusion I drew in the immortal words of Tyler Durden with enough soap, one could blow up just about anything. But yeah, you have to really think about what your device is going to be used for and where it's going to be deployed before you just throw a network's interface on it, throw a random service on it and let everybody talk to it. It makes perfect sense in some situations, but not in all. So you really, really have to keep that in mind. Same situation as with other things. So what you can take home from this on your own network, I give this advice regardless of what service you're talking about, but know your network. You should be, as I said earlier, you should be sending out in search requests on every network you connect to because you would be amazed what you find. And if you don't want to be loud about it, you can just sit on the network and listen to Port 1900 and whenever a device powers up. I mean, if you've ever watched the traffic from Windows laptops, by default, they have UPMP enabled and just constantly bombard the network with notify messages. Just ridiculous amounts of traffic. But yeah, more important than that, if you don't need UPMP for anything, disable it. If you can't disable it on the device, you might be able to do something with black-colling it at the router, but just find some way to prevent UPMP if you don't need it. And then, yeah, as always, keep on top of updates if possible. On the other hand, the darker side of the hat, if you want to find volans of your own, if you've never found any volans before in your life, I guarantee you'll be able to find some volans in SOAP services. So there are lots of options for fuzzing it. Burp is always great, especially for HTTP style requests like SOAP is. WS Fuzzer is by the OWAS project. I've actually never used it, but it is targeted specifically to HTTP and SOAP. So that's pretty handy. Miranda is fantastic. It's written by Craig Hefner. I think it's Craig, it might be Chris, the binwalk guy. Craig, I think. Really, really great, but it's in Python and I'm not a Python guy, sorry. So UFuz actually just came out fairly recently is actually supposedly a Ruby port of Miranda. Or at least that's what the guy is billing it as. Unfortunately, I tried it and I couldn't even get the thing to send traffic. It might be me, it might be him. He says on the GitHub that it's very, very much still in beta. So I might look into that further and submit some pull requests. But also, if I ever decide to release my stuff, which I might, I might not. I don't know depending on how the mood strikes me. We'll see. But yeah, I've got some, my injector libs that seem to work pretty well. And yeah, that's basically it. I'm headless on pretty much every communication medium. Feel free to hit me up. If you find any cool phones, I'd love to hear about them. You know, post disclosure, I guess. But yeah, feel free to hit me up and that's it. Are there any questions? Make them quick because we have to clear the room. No, I don't, I beat my head over it. So as an example, so okay, I do have an idea. See if it's a spec, like an officially defined spec and read it really carefully. Because I was beating my head over that set AV transport URI for forever. And then I read the spec line by line and found out that it took a ditto light meta tag, just an empty tag. It didn't even have to have anything in it, but it needed that empty tag. And then it worked fine. Anyone else? All right, thank you.