IoT Village - In Search of the Perfect UPnP Tool
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.
t1v0
While researching UPnP vulnerabilities I became frustrated with the currently available UPnP tools. Some devices that I knew had UPnP just weren't found with any of the tools I tried. Out of this frustration, came a new and improved BHunter extension for Burp Suite. In this lightning talk I'll go over some of the issues I found and the improvements made to it, and I'll give a demo of the tool in action.
 This talk is about my search for a good UPnP hacking tool. So what we're going to go over today is just some introductions to tell you who I am. First, I'll start talking about what is UPnP and why should you care about UPnP. Why was I looking for a tool to hack UPnP in the first place? I'll talk about some of the tools that are out there right now and what I found to be their shortcomings and why I thought that they weren't quite sufficient. I will show you a new, an updated tool that I put a lot of updates into, and I'll talk about the features of that. And throughout, we'll do some demos of that functionality and about UPnP in general. Q&A was going to be in the Discord chat, but I know Discord is down at the moment, or there's some issues with it. So if that still happens, we'll probably just keep the Q&A here in the Twitch channel. All right, so who am I? Real name is Trevor Stavato. I've been in offensive security for over 10 years, different positions, mostly in web app and network pen testing. Couple of years ago, I founded this cool little company called LabMath Security. Before I was in hacking, I was a software developer and I did that for a number of years and then realized all the mistakes I was making once I became a hacker. I tried to be an active member of the security community. As Sam said, I help do some IoT village stuff in Canada. I help sometimes in the US as well. I like to dabble a little bit in RFID, so we do an RFID village here in Canada, and I do some red teaming for the pros versus joe CTF, which unfortunately didn't happen this year because of all this COVID stuff. Maybe one of my proudest achievements so far is the DefCon 26 Black Badge win at the IoT CTF. All right, so let's talk about what UPnP is. UPnP is universal plug and play. And it's a protocol defined, I think back in 2008 was the original publication of this protocol, allowing for devices on network to discover and interact with each other, based around a principle called zero configuration networking. Really what they wanted to be able to do was to have a device that just plugged into a network, found other devices and was able to talk to and communicate with the other devices and have them configure themselves according to their needs without anybody having any actual input and hands-on keyboard configuration. Sounds like a great idea to me. So UPnP is a protocol that uses pretty standard services like HTTP, XML and so. And it defines a way for services to describe their functionality and as they interact with other devices. A lot of the common uses for this are for network services. So small office, home office, routers, we'll use this for configuring port forwarding. There's data sharing services for network storage. Media streaming, for example, Chromecast or some of the original versions of Chromecast use UPnP to initiate the streams. And it's also used commonly in smart home control, which will be one of the demos that we're doing later on today. So in the spec, UPnP talks about kind of six capabilities or six things that are required for proper UPnP functioning. The first one is addressing. It's not as important for the tool because we can't really talk to it unless it has a device, but the device needs a way to get an IP address. And this is typically done through DHCP. The second one, more interesting to us is discovery protocol. So the devices need to be able to advertise their presence on the network or other devices need to be able to search for other UPnP devices on the network. So there's a protocol called simple service, discovery protocol, SSDP that is used to do this advertisement. And I'll show one of those requests later and show how that works. Once you know what devices are on the networks, you need to know what those devices can do. And then there's a device description XML file that gives this detail. And when the devices broadcast their presence or another device searches for them, the URL to that XML file is used. The URL to that XML file is part of the response that comes back. The next part is control. So once you know what it can do, you need to know how to control that device. You need to know what endpoint to send the request to, what parameters you need to include in the request. Once you have this information, now that's enough information to start interacting with that device. There are still a couple of other parts to UPnP. The fifth one is event notifications. So you can subscribe to specific state variables on a device. And if that state variable changes, it'll send a notification to you. And then the last part of UPnP protocol is a presentation. For the topic of this talk, that's not as important because that just gets into sort of regular web app hacking less UPnP hacking. So we're gonna focus on two to five with this talk. So I'm gonna show you just a brief view of a device description and what that kind of looks like. So over here, I'm gonna run a search and you'll see the discovery message. And I'll make this bigger because this might not be easy for people to see. So there's a discovery message that uses a custom HTTP verb called Msearch. It posts to a broadcast address. And this is just a fixed, this is the same on every network. It's got a message saying, trying SSDP discover and a service type. In this case is SSDP all, which basically says all devices respond to me. And you can see the responses come back here from all the different devices, showing you here is the location of my service or my device description. And it'll also give you some information about what kind of device it is. So you can see on my network, there are a couple of devices that have a lot of different services because we said SSDP all, all the services are responding separately. So now I'm gonna, we're gonna take a look at one of these and we'll show you what a device description looks like. And let's make this bigger. So this here, you can see my setup here on the other screen. I have an ASUS router, I have a WiIMO switch and that is, there's a little lamp plugged into that WiIMO switch. So the device description we're seeing here is for the ASUS router. It shows you the model number, the version numbers, serial numbers, a lot of information about it. When you get down into this section, the service list, this is where we see the different services, the UPNP services that it supports. So it'll show you the URL that you need to send control requests to, the URL to send event requests to. And it'll also have, not in this one, but in some of them, it'll have the, oh yeah, no, here it is, the SSDP. So the service controlled descriptions, the service description. So if we copy this and we put this on here, we'll now put a double fax bar, there we go. Now we'll see all the actions that this service supports, action name and all the arguments. So we can collapse all this and you can see there's gonna be a bunch of actions for this service. And then we get into this service state table that talks about all the state variables. And some of these won't send events. So the send events is no, but some of these do. And those are the ones that we can subscribe to. So physical link status is a variable that we can subscribe to and get notifications when that status changes. So you can see how this can be used by devices to monitor what's happening in the network and be able to control it. So that's the overview of how these, the sort of service descriptions and device descriptions work and what they look like. So one thing that's missing from this spec is that there's no authentication. Even on the control endpoints when you're sending a control message, they are unauthenticated. It's a very old protocol. This is a 2008, so they probably didn't think about that part of it. There have been some updates, some other optional pieces that you can tack on to add some authentication and some security to it. But those really, from my experience, I haven't seen any devices that use those. So most of this is just fully done unauthenticated. So why does this relate to IoT? Why is it an IoT village? A lot of IoT devices are using UPMP. It makes them very simple for setup and control. A lot of consumer devices, they just wanna make it simple. You take it home, you plug it in and it works. So that's why UPMP is helpful for that. But as a hacker, we can look at what can we do with that so we can do things like turning smart home devices on and off and we'll do a demo later of the WiIMO switch turning that on and off. One of the other things that UPMP has gotten the news a lot for is the ability to update the router's configuration and open ports on the router so that you can forward from the WAN side, the internet side into the internal network. And then, as I said, you can also control media devices. So I thought, IoT has already so many vulnerabilities. There's gotta be some UPMP vulnerabilities, right? So that's why I wanted to look at UPMP as sort of an attack path. As I said, there's been a couple of notable exploits in the news back in 2017, Akamai, who used the paper talking about UPN proxy. UPN proxy. Basically, a lot of devices were configured to expose the UPMP interface on the WAN side. So you could send control events, things like port forwarding from the WAN side. So somebody on the internet could control your router and could set port forwarding to get internal access to your network. And even some of the rules, the way that they were doing the port forwarding, they're not validating the fields. So you could port forward a port on the WAN side and forward it to a completely different URL somewhere else on the internet. So people were using this as a proxy, as they're from UPN proxy, to hide where they're coming from and sort of disguise their attacks. Back in 2019, there was a pretty famous attack from HackerDraft, where they used basically that same functionality, routers that were allowing configuration on their WAN side to port forward to the Chromecast device. And then from there, they could control the Chromecast device because it used UPNP as a way to stream a video to it. So they could control the Chromecast device and put a video of their choosing on. And they decided to put up an advertisement to subscribe to PewDiePie. So that got a lot of news headlines. One of the more recent ones that I've come across is this vulnerability called Call Stranger. And it's a 2020 vulnerability. It's really interesting when you look at this because basically what he did is he looked at the UPNP spec and just noticed that there's some bad design in the spec. So I talked about the event subscription part of this. There's a callback of the events that's sufficient. So you tell it where to call back when something changes. But there's no validation at this point done on that callback. So you can have that be some other address on the internet. You can add query strings on it. So you could use it for data exfiltration if you wanted to get stuff out of a network kind of sneakily. There's also some amplifications type ramifications to this because you send a very small request and the request that comes back or gets forwarded to that notification server is much larger in size. So you could potentially do some sort of denial of service using that amplification. So we'll look at that and show you how that's done. So when I went looking for the UPNP tool, there's basic things that I would want a UPNP tool to do. First, I wanted to discover all the devices on my network. I don't want to have to go out there and look for it. I want this tool to be able to find them. Once it finds them, it should be able to parse the description, find the services and actions and events. It smells pretty straightforward and easy to parse. So that should be straightforward. And then to be able to build and manipulate the UPNP requests, that needs to be something simple that I can easily do and potentially ideally fuzz that interface. So let's look at some of the tools that are out there and how I found that they worked. Now, this isn't an exhaustive presentation of what's out there. These are just the more common ones that I've come across. The first one is Miranda and it's available in Cali out of the box. It has a nice command line syntax if you like that kind of thing. But on the con side of things, I found it doesn't always work. In the case, I just ran it yesterday on my home network. It can find the devices by doing an M search, but it seems to have trouble parsing some of the service description files. So it comes back with an empty list of services and you can't do any sort of control of the actions. Also, command line syntax in my opinion is as nice for interacting with these requests and I just don't find it as nice to use. The next tool that I looked at and I was actually really excited about this tool was the Burp UPNP B Hunter. It's available in the Burp app store because UPNP is HTTP based XML soap. All that kind of stuff works really well in Burp and it works really well in Burp's other tools like intruder and repeater. So I thought this was a great place to have that kind of functionality. But when I started using it, there were some major problems that I had where it wouldn't detect all the devices on the network. Some of the devices that I knew were there, it wasn't picking them up. And sometimes the parsing wasn't working. It wasn't able to parse the service descriptions and get access to all the different control points. Lastly, I found the interface just wasn't so easy. When my home network, I do have a lot of IoT devices plugged in and when I do a UPNP scan, I get back five or six devices. Each of them have many service descriptions and lots of control endpoints. And the version that's in the app store right now basically has very little fine green control over what requests you send to intruder or repeater. And sometimes even you don't have control over where you send it to. It's either one or the other. But I was ending up with 100 repeater tabs of requests and trying to dig through 100 tabs to find the one request that I wanted to fuzz or test. It's just not very user friendly in my opinion. So what's a wannabe UPNP hacker guy like me going to do? As I said, there's other tools. There are things like UFuzz. That's based on Miranda. So it's going to have the same sort of shortcomings that Miranda has. There's some.NET tools, but I don't really work on a Windows laptop very much. So.NET is not that conducive for me. So I was kind of looking at a few different options. I keep looking to see if there's other tools out there. I build a new tool from scratch or I modify an existing tool that's already out there. So being Canadian, I turned to my good friend and my neighbor Drake and I said, what should I do? He told me, don't build a new tool from scratch. You got to modify something that's already existing out there. So that brings me to my version of Burp UPNP Hunter. I thought that it had the best sort of potential for a tool because of its integration into Burp and some of the other tools that you can use with Burp. But first we had to get through some of the bugs that it was facing right now. So the first one, the fact that it didn't detect all the UPNP devices on the network, I found that this comes down to some devices just don't follow the spec very well. It was sending the M search using an SSDP all, which I showed earlier. And all devices are supposed to respond to that, but some devices they just don't. So I added a different M search. So it does two M searches, one using SSDP all and one using another tag called root device. And that only the root device is supposed to respond to that, not all the different services. That seemed to work a little bit better for some of the devices that were on my network. So I was able to find all the devices on my network at that point. I still had some issues though with parsing in this tool. There was an interesting unsigned integer conversion error. So BIRP is written in Java and Java byte arrays go from negative 127 to positive 127. But Python, which this tool is written in has byte arrays go from 0 to 256. So in most characters, that doesn't really matter because you're still in the 0 to 127 range. But when you get into special characters and you get an assigned byte array from Java going into Python, things don't work so well. So I had to do some tricks to convert that back to an unsigned byte array. So that no matter what we got in the service description, special characters or not, it wasn't going to work on me. I also found that the control URLs, the way that it was parsing the control URLs from the service, from the device description, it didn't account for the fact that some devices add query strings to the control URLs. So they have a generic control URL, but they have a query parameter that it uses to determine what service you're trying to talk to. And without that, it just gave me back bad requests. So I had to modify the tool to actually use the query string that was part of the control URL. Lastly, there were still other issues with the XML with the parsing. It wasn't actually doing XML parsing in the first version. It was using a regex to try to search through the XML document to pull out the pieces that it needed. And if you had an XML document that wasn't structured the way it was expected, then it wouldn't work. So I switched it to use actual XML parsing because that just makes sense. I also changed the UI for the tool because I didn't want to have to dig through 100 tabs in repeater. I added some combo boxes where you can now select the IP, the service, and the action. So you can drill in on the specific request that you want to look at and play with. I added a full request viewer and editor. So you can look at that and maybe change things before you send it to Intruder or repeater. And you have the option to send it to either. You're not sort of tied into one or the other like you were in the first version. And lastly, I added a couple new features to the tool. So I added the ability to subscribe to event notifications. So it parses that service description, looks for state variables that have events turned on, and then it will build a request for you that you can generate a subscribe request to subscribe to those state variables. I also added an option to specify the single device description. So instead of searching your network, you can specify a remote service description. Searching only works on your local network because you're broadcasting to an address within your local network. So only devices within that local network are going to work. But if you go on Shodan, there's a lot of UPNP devices on Shodan that are exposed to the Internet. If you want to play with those, now you can because you can paste that service description into there directly and load that and get all the actions. I also added some little buttons so you can view, pull up the service description and SEDP files directly from the tool. That was kind of a more of a convenience for me as I was debugging and trying to figure out why things weren't working. To easily get to the device description and those files made it a little bit easier to see what I'm looking at. And now it's demo time. So we'll go through that tool and show you what it actually does. So UPNP Hunter 2.0. Right now it is not available in the verb app store. I do plan to push it to the verb app store at some point later. I first wanted to wait and give the original author a chance to pull in some of the changes that I pushed and maybe update the tool from there. He doesn't seem to have the interest to do that. So I will push this as a separate standalone version. So this is the tool. This is what it looks like in the verb tab. And I'm just going to go ahead and start a discovery on my network. And this will take a few minutes because as I said, it's running the M search, reading back all the responses and then parsing out. So on this network, I have two devices that are running UPNP. This is the ASUS router as we saw before. This one is the Belkin WiIMO device. And this is the list of all the service endpoints that it understands. And if you look at the different actions, these are all the actions within that service endpoint. So I'll just pull up the SCDP here for a second. And so you can see, you know, action to get device information. That should be in here somewhere. Yeah, get device information. And then once you select it, it pulls up the request. It builds out the request in this field here. So you can view it, see what different parameters it takes. And then you can send that straight to repeater or to intruder. And we'll see that repeater picked it up. Now it's here and I can send this request and get device information from that request, from that device. So that's, you know, very, very basically that's how it works. So let's show you why this is cool and, you know, what we can do with this. So one of the things that's very easy to do with the Belkin Wiimmo device is controlling its on and off state. So it's called binary state. So we are going to find the request set binary state. And we can see there's a few different parameters here and the parameter values are just filled with fuzz here. Could tell you where you can actually put input. And we'll send that to repeater. We'll take all this fuzz here stuff out. And the only one that really is needed for most basic operation is the binary state. So I'm going to set the binary state to one, which should be on. And as you see over here, it at the light flips on and I get a response that now the binary state is on and some other some other information. Now I can set the binary state back to zero and the light goes off. So very simple, easy control of the device state through UPNP. Let's talk a little bit about event subscription. So in here, you will see a subscribe request and it again uses a custom HTTP verb subscribe. This is the path pulled out of the device description. And then again, there's a bunch of places where you can fuzz here in this section is where you put the parameters that where you want the callback to come to. You can set a timeout for how long you want to get notified of those event changes. And then this is a comma separated list of all the different parameters that this device will give event notifications for. So I already have one of these queued up over here. Let's see. So if everything is still working the way it should, I will get a device description or sorry event notification here saying the. That is not what I expected. Hang on a sec. Property change. Property state is zero. Okay. Sorry. That is what I expected. Now, if I go back to the basic event requests and I change the state back to one. Now I get another notification coming in on that callback with the binary status one. So we see the notifications and how they come back. What's interesting about the notifications and what this call stranger vulnerability sort of talks about. Is you can specify multiple endpoints that this calls back to one of the neat sort of features of this is that. If the first request doesn't if the first. URL doesn't it can't reach it doesn't get a response from it. Then it will try the next request. The next IP. So. You can actually make use of this to do some internal port scanning. Of things on the network if you can access this on the way inside for example, you can you can use this feature. Special I host in a port and then specify a host and port that you know it can reach. And if you get the callback coming to. To your. IP address, you know that it wasn't able to connect to the previous one. So that's kind of a fun little, little thing you can do with the subscribe feature. Really that's I guess sort of the end of my demonstration of this tool. I think it can be really powerful, especially being able to send stuff to retreat intruder and do some fuzzing with this. And I can also show you here that if we just take this device description. Paste it in here. Then we get just that that device descriptions services we don't get all the other so you can use that as well to sort of narrow down or or look at remote ones like I said. And I think that is it. So the repository for this is in our Git lab link is here. As I said, I do plan on pushing this to the verb app store at some point in the future. But it's just not there right now.
 This talk is about my search for a good UPnP hacking tool.  So what we're going to go over today  is just some introductions to tell you who I am.  First, I'll start talking about what is UPnP  and why should you care about UPnP.  Why was I looking for a tool to hack UPnP in the first place?  I'll talk about some of the tools that are out there right now  and what I found to be their shortcomings  and why I thought that they weren't quite sufficient.  I will show you a new, an updated tool  that I put a lot of updates into,  and I'll talk about the features of that.  And throughout, we'll do some demos of that functionality  and about UPnP in general.  Q&A was going to be in the Discord chat,  but I know Discord is down at the moment,  or there's some issues with it.  So if that still happens,  we'll probably just keep the Q&A here in the Twitch channel.  All right, so who am I?  Real name is Trevor Stavato.  I've been in offensive security for over 10 years,  different positions, mostly in web app  and network pen testing.  Couple of years ago, I founded this cool little company  called LabMath Security.  Before I was in hacking, I was a software developer  and I did that for a number of years  and then realized all the mistakes I was making  once I became a hacker.  I tried to be an active member of the security community.  As Sam said, I help do some IoT village stuff in Canada.  I help sometimes in the US as well.  I like to dabble a little bit in RFID,  so we do an RFID village here in Canada,  and I do some red teaming for the pros versus joe CTF,  which unfortunately didn't happen this year  because of all this COVID stuff. Maybe one of my proudest  achievements so far is the DefCon 26 Black Badge win  at the IoT CTF.  All right, so let's talk about what UPnP is.  UPnP is universal plug and play.  And it's a protocol defined, I think back in 2008  was the original publication of this protocol,  allowing for devices on network to discover  and interact with each other,  based around a principle called zero configuration  networking.  Really what they wanted to be able to do  was to have a device that just plugged into a network,  found other devices and was able to talk to  and communicate with the other devices  and have them configure themselves according to their needs  without anybody having any actual input  and hands-on keyboard configuration.  Sounds like a great idea to me.  So UPnP is a protocol that uses pretty standard services  like HTTP, XML and so.  And it defines a way for services to describe their  functionality and as they interact with other devices.  A lot of the common uses for this are for network services.  So small office, home office, routers,  we'll use this for configuring port forwarding.  There's data sharing services for network storage.  Media streaming, for example, Chromecast  or some of the original versions of Chromecast  use UPnP to initiate the streams.  And it's also used commonly in smart home control,  which will be one of the demos that we're doing later on today.  So in the spec, UPnP talks about kind of six capabilities  or six things that are required for proper UPnP functioning.  The first one is addressing.  It's not as important for the tool because we can't really  talk to it unless it has a device,  but the device needs a way to get an IP address.  And this is typically done through DHCP.  The second one, more interesting to us is discovery protocol.  So the devices need to be able to advertise their presence  on the network or other devices need to be able to search  for other UPnP devices on the network.  So there's a protocol called simple service,  discovery protocol, SSDP that is used to do this advertisement.  And I'll show one of those requests later  and show how that works.  Once you know what devices are on the networks,  you need to know what those devices can do.  And then there's a device description XML file  that gives this detail.  And when the devices broadcast their presence  or another device searches for them,  the URL to that XML file is used.  The URL to that XML file is part of the response that comes back.  The next part is control.  So once you know what it can do,  you need to know how to control that device.  You need to know what endpoint to send the request to,  what parameters you need to include in the request.  Once you have this information,  now that's enough information to start interacting  with that device.  There are still a couple of other parts to UPnP.  The fifth one is event notifications.  So you can subscribe to specific state variables on a device.  And if that state variable changes,  it'll send a notification to you.  And then the last part of UPnP protocol is a presentation.  For the topic of this talk, that's not as important  because that just gets into sort of regular web app hacking  less UPnP hacking.  So we're gonna focus on two to five with this talk.  So I'm gonna show you just a brief view  of a device description and what that kind of looks like.  So over here, I'm gonna run a search  and you'll see the discovery message.  And I'll make this bigger  because this might not be easy for people to see.  So there's a discovery message  that uses a custom HTTP verb called Msearch.  It posts to a broadcast address.  And this is just a fixed, this is the same on every network.  It's got a message saying,  trying SSDP discover and a service type.  In this case is SSDP all,  which basically says all devices respond to me.  And you can see the responses come back here  from all the different devices,  showing you here is the location of my service  or my device description.  And it'll also give you some information  about what kind of device it is.  So you can see on my network,  there are a couple of devices  that have a lot of different services  because we said SSDP all,  all the services are responding separately.  So now I'm gonna,  we're gonna take a look at one of these  and we'll show you what a device description looks like.  And let's make this bigger.  So this here, you can see my setup here on the other screen.  I have an ASUS router, I have a WiIMO switch  and that is, there's a little lamp  plugged into that WiIMO switch.  So the device description we're seeing here  is for the ASUS router.  It shows you the model number, the version numbers,  serial numbers, a lot of information about it.  When you get down into this section, the service list,  this is where we see the different services,  the UPNP services that it supports.  So it'll show you the URL  that you need to send control requests to,  the URL to send event requests to.  And it'll also have, not in this one, but in some of them,  it'll have the, oh yeah, no, here it is, the SSDP.  So the service controlled descriptions,  the service description.  So if we copy this and we put this on here,  we'll now put a double fax bar, there we go.  Now we'll see all the actions that this service supports,  action name and all the arguments.  So we can collapse all this and you can see  there's gonna be a bunch of actions for this service.  And then we get into this service state table  that talks about all the state variables.  And some of these won't send events.  So the send events is no, but some of these do.  And those are the ones that we can subscribe to.  So physical link status is a variable  that we can subscribe to and get notifications  when that status changes.  So you can see how this can be used by devices  to monitor what's happening in the network  and be able to control it.  So that's the overview of how these,  the sort of service descriptions  and device descriptions work and what they look like.  So one thing that's missing from this spec  is that there's no authentication.  Even on the control endpoints  when you're sending a control message,  they are unauthenticated.  It's a very old protocol.  This is a 2008, so they probably didn't think  about that part of it.  There have been some updates,  some other optional pieces that you can tack on  to add some authentication and some security to it.  But those really, from my experience,  I haven't seen any devices that use those.  So most of this is just fully done unauthenticated.  So why does this relate to IoT?  Why is it an IoT village?  A lot of IoT devices are using UPMP.  It makes them very simple for setup and control.  A lot of consumer devices, they just wanna make it simple.  You take it home, you plug it in and it works.  So that's why UPMP is helpful for that.  But as a hacker, we can look at what can we do with that  so we can do things like turning smart home devices  on and off and we'll do a demo later  of the WiIMO switch turning that on and off.  One of the other things that UPMP has gotten the news  a lot for is the ability to update  the router's configuration and open ports on the router  so that you can forward from the WAN side,  the internet side into the internal network.  And then, as I said, you can also control media devices.  So I thought, IoT has already so many vulnerabilities.  There's gotta be some UPMP vulnerabilities, right?  So that's why I wanted to look at UPMP  as sort of an attack path.  As I said, there's been a couple of notable exploits  in the news back in 2017, Akamai,  who used the paper talking about UPN proxy.  UPN proxy.  Basically, a lot of devices were configured  to expose the UPMP interface on the WAN side.  So you could send control events,  things like port forwarding from the WAN side.  So somebody on the internet could control your router  and could set port forwarding  to get internal access to your network.  And even some of the rules,  the way that they were doing the port forwarding,  they're not validating the fields.  So you could port forward a port on the WAN side  and forward it to a completely different URL  somewhere else on the internet.  So people were using this as a proxy,  as they're from UPN proxy,  to hide where they're coming from  and sort of disguise their attacks.  Back in 2019, there was a pretty famous attack  from HackerDraft, where they used  basically that same functionality,  routers that were allowing configuration on their WAN side  to port forward to the Chromecast device.  And then from there,  they could control the Chromecast device  because it used UPNP as a way to stream a video to it.  So they could control the Chromecast device  and put a video of their choosing on.  And they decided to put up an advertisement  to subscribe to PewDiePie.  So that got a lot of news headlines.  One of the more recent ones that I've come across  is this vulnerability called Call Stranger.  And it's a 2020 vulnerability.  It's really interesting when you look at this  because basically what he did is he looked at the UPNP spec  and just noticed that there's some bad design in the spec.  So I talked about the event subscription part of this.  There's a callback of the events that's sufficient.  So you tell it where to call back when something changes.  But there's no validation at this point done on that callback.  So you can have that be some other address on the internet.  You can add query strings on it.  So you could use it for data exfiltration  if you wanted to get stuff out of a network kind of sneakily.  There's also some amplifications type ramifications to this  because you send a very small request  and the request that comes back or gets forwarded  to that notification server is much larger in size.  So you could potentially do some sort of denial of service  using that amplification.  So we'll look at that and show you how that's done.  So when I went looking for the UPNP tool,  there's basic things that I would want a UPNP tool to do.  First, I wanted to discover all the devices on my network.  I don't want to have to go out there and look for it.  I want this tool to be able to find them.  Once it finds them, it should be able to parse the description,  find the services and actions and events.  It smells pretty straightforward and easy to parse.  So that should be straightforward.  And then to be able to build and manipulate the UPNP requests,  that needs to be something simple that I can easily do  and potentially ideally fuzz that interface.  So let's look at some of the tools that are out there  and how I found that they worked.  Now, this isn't an exhaustive presentation of what's out there.  These are just the more common ones that I've come across.  The first one is Miranda and it's available in Cali out of the box.  It has a nice command line syntax if you like that kind of thing.  But on the con side of things, I found it doesn't always work.  In the case, I just ran it yesterday on my home network.  It can find the devices by doing an M search,  but it seems to have trouble parsing some of the service description files.  So it comes back with an empty list of services  and you can't do any sort of control of the actions.  Also, command line syntax in my opinion is as nice for interacting with these requests  and I just don't find it as nice to use.  The next tool that I looked at and I was actually really excited about this tool  was the Burp UPNP B Hunter.  It's available in the Burp app store because UPNP is HTTP based XML soap.  All that kind of stuff works really well in Burp  and it works really well in Burp's other tools like intruder and repeater.  So I thought this was a great place to have that kind of functionality.  But when I started using it, there were some major problems that I had  where it wouldn't detect all the devices on the network.  Some of the devices that I knew were there, it wasn't picking them up.  And sometimes the parsing wasn't working.  It wasn't able to parse the service descriptions and get access to all the different control points.  Lastly, I found the interface just wasn't so easy.  When my home network, I do have a lot of IoT devices plugged in  and when I do a UPNP scan, I get back five or six devices.  Each of them have many service descriptions and lots of control endpoints.  And the version that's in the app store right now basically has very little fine green control  over what requests you send to intruder or repeater.  And sometimes even you don't have control over where you send it to.  It's either one or the other.  But I was ending up with 100 repeater tabs of requests and trying to dig through 100 tabs  to find the one request that I wanted to fuzz or test.  It's just not very user friendly in my opinion.  So what's a wannabe UPNP hacker guy like me going to do?  As I said, there's other tools.  There are things like UFuzz.  That's based on Miranda.  So it's going to have the same sort of shortcomings that Miranda has.  There's some.NET tools, but I don't really work on a Windows laptop very much.  So.NET is not that conducive for me.  So I was kind of looking at a few different options.  I keep looking to see if there's other tools out there.  I build a new tool from scratch or I modify an existing tool that's already out there.  So being Canadian, I turned to my good friend and my neighbor Drake and I said,  what should I do? He told me, don't build a new tool from scratch.  You got to modify something that's already existing out there.  So that brings me to my version of Burp UPNP Hunter.  I thought that it had the best sort of potential for a tool  because of its integration into Burp and some of the other tools that you can use with Burp.  But first we had to get through some of the bugs that it was facing right now.  So the first one, the fact that it didn't detect all the UPNP devices on the network,  I found that this comes down to some devices just don't follow the spec very well.  It was sending the M search using an SSDP all, which I showed earlier.  And all devices are supposed to respond to that, but some devices they just don't.  So I added a different M search.  So it does two M searches, one using SSDP all and one using another tag called root device.  And that only the root device is supposed to respond to that, not all the different services.  That seemed to work a little bit better for some of the devices that were on my network.  So I was able to find all the devices on my network at that point.  I still had some issues though with parsing in this tool.  There was an interesting unsigned integer conversion error.  So BIRP is written in Java and Java byte arrays go from negative 127 to positive 127.  But Python, which this tool is written in has byte arrays go from 0 to 256.  So in most characters, that doesn't really matter because you're still in the 0 to 127 range.  But when you get into special characters and you get an assigned byte array from Java going into Python,  things don't work so well.  So I had to do some tricks to convert that back to an unsigned byte array.  So that no matter what we got in the service description, special characters or not,  it wasn't going to work on me.  I also found that the control URLs, the way that it was parsing the control URLs from the service,  from the device description, it didn't account for the fact that some devices add query strings  to the control URLs.  So they have a generic control URL, but they have a query parameter that it uses to determine  what service you're trying to talk to.  And without that, it just gave me back bad requests.  So I had to modify the tool to actually use the query string that was part of the control URL.  Lastly, there were still other issues with the XML with the parsing.  It wasn't actually doing XML parsing in the first version.  It was using a regex to try to search through the XML document to pull out the pieces that it needed.  And if you had an XML document that wasn't structured the way it was expected, then it wouldn't work.  So I switched it to use actual XML parsing because that just makes sense.  I also changed the UI for the tool because I didn't want to have to dig through 100 tabs in repeater.  I added some combo boxes where you can now select the IP, the service, and the action.  So you can drill in on the specific request that you want to look at and play with.  I added a full request viewer and editor.  So you can look at that and maybe change things before you send it to Intruder or repeater.  And you have the option to send it to either.  You're not sort of tied into one or the other like you were in the first version.  And lastly, I added a couple new features to the tool.  So I added the ability to subscribe to event notifications.  So it parses that service description, looks for state variables that have events turned on,  and then it will build a request for you that you can generate a subscribe request to subscribe to those state variables.  I also added an option to specify the single device description.  So instead of searching your network, you can specify a remote service description.  Searching only works on your local network because you're broadcasting to an address within your local network.  So only devices within that local network are going to work.  But if you go on Shodan, there's a lot of UPNP devices on Shodan that are exposed to the Internet.  If you want to play with those, now you can because you can paste that service description into there directly and load that and get all the actions.  I also added some little buttons so you can view, pull up the service description and SEDP files directly from the tool.  That was kind of a more of a convenience for me as I was debugging and trying to figure out why things weren't working.  To easily get to the device description and those files made it a little bit easier to see what I'm looking at.  And now it's demo time. So we'll go through that tool and show you what it actually does.  So UPNP Hunter 2.0. Right now it is not available in the verb app store.  I do plan to push it to the verb app store at some point later.  I first wanted to wait and give the original author a chance to pull in some of the changes that I pushed and maybe update the tool from there.  He doesn't seem to have the interest to do that. So I will push this as a separate standalone version.  So this is the tool. This is what it looks like in the verb tab.  And I'm just going to go ahead and start a discovery on my network.  And this will take a few minutes because as I said, it's running the M search, reading back all the responses and then parsing out.  So on this network, I have two devices that are running UPNP.  This is the ASUS router as we saw before.  This one is the Belkin WiIMO device.  And this is the list of all the service endpoints that it understands.  And if you look at the different actions, these are all the actions within that service endpoint.  So I'll just pull up the SCDP here for a second.  And so you can see, you know, action to get device information.  That should be in here somewhere. Yeah, get device information.  And then once you select it, it pulls up the request. It builds out the request in this field here.  So you can view it, see what different parameters it takes.  And then you can send that straight to repeater or to intruder.  And we'll see that repeater picked it up.  Now it's here and I can send this request and get device information from that request, from that device.  So that's, you know, very, very basically that's how it works.  So let's show you why this is cool and, you know, what we can do with this.  So one of the things that's very easy to do with the Belkin Wiimmo device is controlling its on and off state.  So it's called binary state.  So we are going to find the request set binary state.  And we can see there's a few different parameters here and the parameter values are just filled with fuzz here.  Could tell you where you can actually put input.  And we'll send that to repeater. We'll take all this fuzz here stuff out.  And the only one that really is needed for most basic operation is the binary state.  So I'm going to set the binary state to one, which should be on.  And as you see over here, it at the light flips on and I get a response that now the binary state is on and some other some other information.  Now I can set the binary state back to zero and the light goes off.  So very simple, easy control of the device state through UPNP.  Let's talk a little bit about event subscription.  So in here, you will see a subscribe request and it again uses a custom HTTP verb subscribe.  This is the path pulled out of the device description.  And then again, there's a bunch of places where you can fuzz here in this section is where you put the parameters that where you want the callback to come to.  You can set a timeout for how long you want to get notified of those event changes.  And then this is a comma separated list of all the different parameters that this device will give event notifications for.  So I already have one of these queued up over here.  Let's see.  So if everything is still working the way it should, I will get a device description or sorry event notification here saying the.  That is not what I expected.  Hang on a sec.  Property change.  Property state is zero.  Okay.  Sorry.  That is what I expected.  Now, if I go back to the basic event requests and I change the state back to one.  Now I get another notification coming in on that callback with the binary status one.  So we see the notifications and how they come back.  What's interesting about the notifications and what this call stranger vulnerability sort of talks about.  Is you can specify multiple endpoints that this calls back to one of the neat sort of features of this is that.  If the first request doesn't if the first.  URL doesn't it can't reach it doesn't get a response from it.  Then it will try the next request.  The next IP.  So.  You can actually make use of this to do some internal port scanning.  Of things on the network if you can access this on the way inside for example, you can you can use this feature.  Special I host in a port and then specify a host and port that you know it can reach.  And if you get the callback coming to.  To your.  IP address, you know that it wasn't able to connect to the previous one.  So that's kind of a fun little, little thing you can do with the subscribe feature.  Really that's I guess sort of the end of my demonstration of this tool.  I think it can be really powerful, especially being able to send stuff to retreat intruder and do some fuzzing with this.  And I can also show you here that if we just take this device description.  Paste it in here.  Then we get just that that device descriptions services we don't get all the other so you can use that as well to sort of narrow down or or look at remote ones like I said.  And I think that is it. So the repository for this is in our Git lab link is here.  As I said, I do plan on pushing this to the verb app store at some point in the future.  But it's just not there right now.
DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__0_155.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__156_1499.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__1500_3059.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__3060_3155.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__3156_4187.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__4188_5327.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__5328_6563.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__6564_7151.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__7152_7703.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__7704_8531.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__8532_8747.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__8748_9035.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__9036_9107.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__9108_9155.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__9156_10283.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__10284_10331.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__10332_10499.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__10500_10547.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__10548_10751.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__10752_10799.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__10800_10871.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__10872_11255.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__11256_12431.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__12432_13895.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__13896_14831.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__14832_16535.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__16536_20831.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__20832_21839.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__21840_22139.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__22140_23231.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__23232_25523.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__25524_26087.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__26088_26471.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__26472_26651.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__26652_28295.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__28296_30467.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__30468_31175.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__31176_32015.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__32016_33959.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__33960_34079.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__34080_34139.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__34140_35867.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__35868_36911.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__36912_38075.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__38076_40787.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__40788_42971.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__42972_43403.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__43404_43739.png DEFCONSafeModeIoTVillage-t1v0_-_nSearchofthePerfectUPnPTool_720p_30fps_H264-192kbit_AAC__43740_43741.png