[00:00.000 --> 00:05.580] This talk is about my search for a good UPnP hacking tool. [00:06.340 --> 00:11.340] So what we're going to go over today is just some introductions to tell you who I am. [00:12.020 --> 00:16.320] First I'll start talking about what is UPnP and why should you care about UPnP? [00:16.560 --> 00:20.120] Why was I looking for a tool to hack UPnP in the first place? [00:20.620 --> 00:25.740] I'll talk about some of the tools that are out there right now and what I found to be [00:25.740 --> 00:29.680] their shortcomings and why I thought that they weren't quite sufficient. [00:29.980 --> 00:37.900] I will show you a new, an updated tool that I put a lot of updates into and I'll talk [00:37.900 --> 00:39.360] about the features of that. [00:39.360 --> 00:44.000] And throughout we'll do some demos of that functionality and about UPnP in general. [00:44.580 --> 00:50.360] Q&A was going to be in the Discord chat, but I know Discord is down at the moment or there's [00:50.360 --> 00:51.600] some issues with it. [00:51.600 --> 00:58.760] So if that still happens, we'll probably just keep the Q&A here in the Twitch channel. [00:59.880 --> 01:01.360] All right, so who am I? [01:01.360 --> 01:03.620] Real name is Trevor Stavato. [01:03.620 --> 01:06.880] I've been in offensive security for over 10 years. [01:07.580 --> 01:13.160] Different positions, mostly in web app and network pen testing. [01:13.480 --> 01:17.880] A couple of years ago, I founded this cool little company called LabMath Security. [01:19.400 --> 01:24.380] Before I was in hacking, I was a software developer and I did that for a number of years [01:24.380 --> 01:28.340] and then realized all the mistakes I was making once I became a hacker. [01:29.220 --> 01:32.740] I try to be an active member of the security community. [01:32.780 --> 01:37.140] As Sam said, I help do some IoT village stuff in Canada. [01:37.140 --> 01:39.200] I help sometimes in the U.S. as well. [01:40.200 --> 01:42.680] I like to dabble a little bit in RFID. [01:42.680 --> 01:45.280] So we do an RFID village here in Canada. [01:45.280 --> 01:49.260] And I do some red teaming for the pros versus Joe CTF, [01:49.260 --> 01:53.320] which unfortunately didn't happen this year because of all this COVID stuff. [01:54.360 --> 02:01.400] Maybe one of my proudest achievements so far is the DEF CON 26 black badge win at the IoT CTF. [02:02.640 --> 02:06.220] All right, so let's talk about what UPnP is. [02:06.220 --> 02:09.320] So UPnP is Universal Plug and Play. [02:09.320 --> 02:16.800] And it's a protocol defined, I think back in 2008 was the original publication of this protocol, [02:18.000 --> 02:22.100] allowing for devices on network to discover and interact with each other. [02:22.100 --> 02:25.820] It's based around a principle called zero configuration networking. [02:26.260 --> 02:30.660] Really what they wanted to be able to do was to have a device that just plugged into a network, [02:30.660 --> 02:34.420] found other devices and was able to talk to and communicate with the other devices [02:34.420 --> 02:38.760] and have them configure themselves according to their needs [02:38.760 --> 02:44.140] without anybody having any actual input and hands-on keyboard configuration. [02:44.700 --> 02:47.140] Sounds like a great idea to me. [02:48.200 --> 02:55.740] So UPnP is a protocol that uses pretty standard services like HTTP, XML, and SOAP. [02:55.740 --> 03:01.760] And it defines a way for services to describe their functionality and interact with other devices. [03:02.220 --> 03:06.100] A lot of the common uses for this are for network services. [03:06.100 --> 03:12.840] So small office, home office routers will use this for configuring port forwarding. [03:13.480 --> 03:20.320] There's data sharing services for network storage, media streaming, for example, Chromecast, [03:20.320 --> 03:25.660] or some of the original versions of Chromecast use UPnP to initiate the streams. [03:25.680 --> 03:27.900] And it's also used commonly in smart home control, [03:27.900 --> 03:31.000] which will be one of the demos that we're doing later on today. [03:33.200 --> 03:40.720] So in the spec, UPnP talks about kind of six capabilities or six things that are required [03:40.720 --> 03:45.140] for proper UPnP functioning. The first one is addressing. [03:45.620 --> 03:50.700] It's not as important for the tool because we can't really talk to it unless it has a device, [03:50.700 --> 03:55.820] but the device needs a way to get an IP address. And this is typically done through DHCP. [03:57.160 --> 04:01.080] The second one, more interesting to us, is a discovery protocol. [04:01.080 --> 04:06.980] The devices need to be able to advertise their presence on the network, or other devices need [04:06.980 --> 04:12.860] to be able to search for other UPnP devices on the network. So there's a protocol called [04:12.860 --> 04:18.280] Simple Service Discovery Protocol, SSDP, that is used to do this advertisement. [04:18.280 --> 04:21.920] And I'll show one of those requests later and show how that works. [04:23.240 --> 04:28.820] Once you know what devices are on the networks, you need to know what those devices can do. [04:28.820 --> 04:36.240] And then there's a device description XML file that gives this detail. And when the devices [04:36.240 --> 04:42.000] broadcast their presence or another device searches for them, the URL to that XML file [04:42.000 --> 04:50.170] is part of the response that comes back. The next part is control. So once you know [04:50.170 --> 04:55.050] what it can do, you need to know how to control that device. You need to know what endpoint to [04:55.050 --> 05:02.290] send the request to, what parameters you need to include in the request. Once you have this [05:02.290 --> 05:06.630] information, now that's enough information to start interacting with that device. [05:07.270 --> 05:14.090] There are still a couple of other parts to UPnP. The fifth one is event notification. So [05:14.710 --> 05:20.490] you can subscribe to specific state variables on a device. And if that state variable changes, [05:20.490 --> 05:27.110] it'll send a notification to you. And then the last part of UPnP protocol is a presentation. [05:27.810 --> 05:33.250] For the topic of this talk, that's not as important, because that just gets into sort [05:33.250 --> 05:39.990] of regular web app hacking, less UPnP hacking. So we're going to focus on two to five with this [05:40.450 --> 05:52.970] talk. So I'm going to show you just a brief view of a device description and what that kind of [05:52.970 --> 06:00.210] looks like. So over here, I'm going to run a search. And you'll see the discovery message. [06:00.210 --> 06:03.370] And I'll make this bigger, because this might not be easy for people to see. [06:07.200 --> 06:16.180] So there's a discovery message that uses a custom HTTP verb called msearch. It posts to a [06:16.180 --> 06:23.560] broadcast address. And this is just a fixed... this is the same on every network. It's got a [06:23.560 --> 06:30.820] message saying, try SSDP discover, and the service type in this case is SSDP all, which basically [06:30.820 --> 06:36.680] says, all devices respond to me. And you can see the responses come back here from all the [06:36.680 --> 06:45.960] different devices, showing you here is the location of my device description. And it'll [06:45.960 --> 06:52.780] also give you some information about what kind of device it is. So you can see on my network, [06:52.780 --> 06:57.620] there are a couple devices that have a lot of different services. Because we said SSDP all, [06:57.620 --> 07:05.540] all the services are responding separately. So now I'm going to... we're going to take a look at [07:05.540 --> 07:17.130] one of these. And we'll show you what a device description looks like. And make this bigger. [07:19.070 --> 07:25.030] So this here, you can see my setup here on the other screen. I have an Asus router, [07:25.030 --> 07:30.050] I have a WeMo switch, and that is, there's a little lamp plugged into that WeMo switch. [07:30.450 --> 07:36.550] So the device description we're seeing here is for the Asus router. It shows you the model number, [07:36.550 --> 07:42.350] the version numbers, serial number, a lot of information about it. When we get down into [07:42.350 --> 07:47.910] this section, the service list, this is where we see the different services, the UPnP services [07:47.910 --> 07:53.950] that it supports. So it'll show you the URL that you need to send control requests to, [07:53.950 --> 08:03.170] the URL to send event requests to. And it'll also have, not in this one, but in some of them, [08:03.170 --> 08:09.690] it'll have the, oh yeah, no, here it is, the SCDP, so the service controlled [08:11.410 --> 08:17.330] description, so the service description. So if we copy this, and we put this on here, [08:17.330 --> 08:27.350] we'll now put a double X bar, there we go. Now we'll see all the actions that this service [08:27.350 --> 08:34.010] supports, action name, and all the arguments. So we can collapse all this, and you can see there's [08:34.010 --> 08:39.310] gonna be a bunch of actions for this service. And then we get into this server state table that [08:39.310 --> 08:45.210] talks about all the state variables. And some of these won't send events, so the send events is no, [08:45.210 --> 08:50.250] but some of these do. And those are the ones that we can subscribe to. So physical link status [08:50.250 --> 08:57.030] is a variable that we can subscribe to and get notifications when that status changes. [08:57.190 --> 09:04.630] So you can see how this can be used by devices to monitor what's happening in the network and be [09:04.630 --> 09:12.150] able to control it. So that's the overview of how the service descriptions and device [09:12.150 --> 09:20.340] descriptions work and what they look like. So one thing that's missing from this spec [09:21.080 --> 09:25.440] is that there's no authentication. Even on the control endpoints, when you're sending a control [09:25.440 --> 09:31.800] message, they are unauthenticated. It's a very old protocol, as I said, 2008, so they probably [09:31.800 --> 09:38.460] didn't think about that part of it. There have been some updates, some other optional pieces [09:38.460 --> 09:44.680] that you can tack on to add some authentication and some security to it. But those really, [09:44.680 --> 09:49.800] from my experience, I haven't seen any devices that use those. So most of this is just fully [09:49.800 --> 09:59.120] done unauthenticated. So why does this relate to IoT? Why is it in IoT Village? A lot of IoT devices [09:59.120 --> 10:06.980] are using UPnP. It makes them very simple for setup and control. A lot of consumer devices, [10:06.980 --> 10:11.200] they just want to make it simple. You take it home, you plug it in, and it works. So that's [10:11.200 --> 10:18.780] why UPnP is helpful for that. But as a hacker, we can look at what can we do with that. So we can [10:18.780 --> 10:24.520] do things like turning smart home devices on and off. And I'll do a demo later of the Wemo switch [10:24.520 --> 10:31.680] turning that on and off. One of the other things that UPnP has gotten the news a lot for is the [10:31.680 --> 10:40.220] ability to update the router's configuration and open ports on the router so that you can forward [10:40.220 --> 10:46.400] from the WAN side, the internet side, into the internal network. And then, as I said, you can [10:46.400 --> 10:53.340] also control media devices. So I thought IoT has already so many vulnerabilities. There's got to be [10:53.340 --> 11:01.020] some UPnP vulnerabilities, right? So that's why I wanted to look at UPnP as sort of an attack path. [11:02.220 --> 11:08.940] As I said, there's been a couple of notable exploits in the news. Back in 2017, Akamai [11:08.940 --> 11:19.000] released a paper talking about UPnProxy, UPnProxy. Basically, a lot of devices were configured to [11:19.000 --> 11:28.100] expose the UPnP interface on their WAN, on the WAN side. So you could send control events, [11:28.100 --> 11:35.020] things like port forwarding from the WAN side. So somebody on the internet could control your [11:35.020 --> 11:40.760] router and could set port forwarding to get internal access to your network. And even some [11:40.760 --> 11:46.060] of the rules, the way that they were doing the port forwarding, they're not validating the field. [11:46.060 --> 11:53.120] So you could port forward a port on the WAN side and forward it to a completely different URL [11:53.120 --> 11:58.900] somewhere else on the internet. So people were using this as a proxy, as their UPnProxy, [11:58.900 --> 12:03.600] to hide where they're coming from and sort of disguise their attacks. [12:04.260 --> 12:12.720] Back in 2019, there was a pretty famous attack from HackerGiraffe, where they used basically [12:12.720 --> 12:18.980] that same functionality, routers that were allowing configuration on their WAN side, [12:18.980 --> 12:24.940] to port forward to the Chromecast device. And then from there, they could control the [12:24.940 --> 12:31.040] Chromecast device, because it used UPnP as a way to stream a video to it. So they could control [12:31.040 --> 12:37.420] the Chromecast device and put a video of their choosing on. And they decided to put up an [12:37.420 --> 12:42.060] advertisement to subscribe to PewDiePie. So that got a lot of news headlines. [12:42.760 --> 12:48.480] One of the more recent ones that I've come across is this vulnerability called Call Stranger. [12:49.020 --> 12:53.360] And it's a 2020 vulnerability. It's really interesting when you look at this, because [12:53.360 --> 12:58.620] basically what he did is he looked at the UPnP spec and just noticed that there's some [12:59.240 --> 13:08.560] bad design in the spec. So I talked about the event subscription part of this. There's a callback [13:08.560 --> 13:12.800] of the event subscription. So you tell it where to call back when something changes. [13:12.800 --> 13:20.160] But there's no validation at this point done on that callback. So you can have that be some other [13:20.160 --> 13:26.060] address on the internet. You can use it to... you can add query strings on it. So you could use it [13:26.060 --> 13:31.240] for data exfiltration, if you wanted to get stuff out of a network kind of sneakily. There's also [13:31.240 --> 13:37.320] some amplifications type ramifications to this, because you send a very small request, [13:37.320 --> 13:42.740] and the request that comes back or gets forwarded to that notification server is much larger in [13:42.740 --> 13:48.120] size. So you can potentially do some sort of denial of service using that amplification. [13:48.740 --> 13:58.530] So we'll look at that and show you how that's done. So when I went looking for the UPnP tool, [13:58.530 --> 14:02.870] there's basic things that I would want a UPnP tool to do. First, I want it to discover all [14:02.870 --> 14:07.490] the devices on my network. I don't want to have to go out there and look for it. I want this tool [14:07.490 --> 14:12.070] to be able to find them. Once it finds them, it should be able to parse the description, find the [14:12.070 --> 14:17.130] services and actions and events. You know, XML is pretty straightforward and easy to parse. So that [14:17.130 --> 14:23.930] should be straightforward. And then to be able to build and manipulate the UPnP requests, that needs [14:23.930 --> 14:31.990] to be something simple that I can easily do, and potentially, ideally, fuzz that interface. [14:34.270 --> 14:39.370] So let's look at some of the tools that are out there and how I found that they worked. Now, [14:39.370 --> 14:44.310] this isn't an exhaustive presentation of what's out there. These are just the more common ones [14:44.310 --> 14:50.730] that I've come across. The first one is Miranda. And it's available in Kali out of the box. [14:50.950 --> 14:56.970] Has a nice command line syntax, if you like that kind of thing. But on the con side of things, [14:56.970 --> 15:03.610] I found it doesn't always work. In the case, I just ran it yesterday on my home network. [15:03.830 --> 15:08.810] It can find the devices by doing an msearch, but it seems to have trouble parsing some of the [15:08.810 --> 15:14.730] service description files. So it comes back with an empty list of services, and it can't do any [15:14.730 --> 15:21.230] sort of control of the actions. Also, command line syntax, in my opinion, isn't as nice for [15:21.230 --> 15:27.130] interacting with these requests. And I just don't find it as nice to use. [15:28.850 --> 15:32.530] The next tool that I looked at, and I was actually really excited about this tool, [15:32.530 --> 15:41.090] was the Burp UPnP B-Hunter. It's available in the Burp app store. Because UPnP is HTTP based, [15:41.090 --> 15:46.010] XML soap, all that kind of stuff works really well in Burp. And it works really well in Burp's [15:46.010 --> 15:50.410] other tools, like Intruder and Repeater. So I thought this was a great place to have that [15:50.410 --> 15:55.630] kind of functionality. But when I started using it, there were some major problems that I had [15:55.630 --> 15:59.170] where it wouldn't detect all the devices on the network. Some of the devices that I knew [15:59.170 --> 16:05.990] were there, it wasn't picking them up. And sometimes the parsing wasn't working. It wasn't [16:05.990 --> 16:14.030] able to parse the service descriptions and get access to all the different control points. [16:14.550 --> 16:20.010] Lastly, I found the interface just wasn't so easy. My home network, I do have a lot of IoT [16:20.010 --> 16:26.850] devices plugged in. And when I do a UPnP scan, I get back five or six devices. Each of them have [16:26.850 --> 16:35.430] many service descriptions and lots of control endpoints. And the version that's in the app store [16:35.430 --> 16:40.850] right now basically has very little fine-grained control over what requests you send to Intruder [16:40.850 --> 16:45.670] or Repeater. And sometimes even you don't have control over where you send it to. It's either [16:45.670 --> 16:51.490] one or the other. But I was ending up with, you know, a hundred Repeater tabs of requests and [16:51.490 --> 16:56.250] trying to dig through a hundred tabs to find the one request that I wanted to fuzz or test. [16:56.390 --> 17:03.890] It's just not very user-friendly, in my opinion. So, you know, what's a wannabe UPnP hacker guy [17:03.890 --> 17:09.910] like me going to do? As I said, there's other tools. There are things like uFuzz that's based [17:09.910 --> 17:14.130] on Miranda. So it's going to have the same sort of shortcomings that Miranda has. There's some [17:14.130 --> 17:20.430] .NET tools, but I don't really work on a Windows laptop very much. So .NET is not that conducive [17:20.430 --> 17:27.050] for me. So, you know, I was kind of looking at a few different options. I keep looking, [17:27.050 --> 17:32.650] see if there's other tools out there. I build a new tool from scratch or I modify an existing [17:32.650 --> 17:38.150] tool that's already out there. So being Canadian, I turned to my good friend and my neighbor, [17:38.150 --> 17:42.210] Drake, and I said, what should I do? He told me, don't build a new tool from scratch. [17:42.210 --> 17:45.190] You got to modify something that's already existing out there. [17:46.630 --> 17:53.550] So that brings me to my version of Burp's UPnP Hunter. I thought that it had the best sort of, [17:54.970 --> 18:01.230] you know, potential for a tool because of its integration into Burp and some of the other [18:01.230 --> 18:05.150] tools that you can use with Burp. But first we had to get through some of the bugs that [18:05.150 --> 18:11.110] it was facing right now. So the first one, the fact that it didn't detect all the UPnP devices [18:11.110 --> 18:17.190] on the network, I found that this comes down to some devices just don't follow the spec very well. [18:18.230 --> 18:24.310] It was sending the msearch using an ssdp-all, which I showed earlier, and all devices are [18:24.310 --> 18:30.450] supposed to respond to that. But some devices, they just don't. So I added a different msearch. [18:30.450 --> 18:36.550] So it does two msearches, one using ssdp-all and one using another tag called root device. [18:36.670 --> 18:40.530] And only the root device is supposed to respond to that, not all the different services. [18:41.170 --> 18:46.770] That seemed, pardon me, that seemed to work a little bit better for some of the devices that [18:46.770 --> 18:51.510] were on my network. So I was able to find all the devices on my network at that point. [18:52.210 --> 18:58.690] I still had some issues though with parsing in this tool. There was an interesting unsigned [18:58.690 --> 19:05.490] integer conversion error. So Burp is written in Java and Java byte arrays go from negative 127 [19:05.490 --> 19:14.430] to positive 127. But Python, which this tool is written in, has byte arrays go from 0 to 256. [19:14.770 --> 19:21.110] So in most characters, that doesn't really matter because you're still in the 0 to 127 range. [19:21.190 --> 19:26.890] But when you get into special characters and you get an assigned byte array from Java going [19:26.890 --> 19:33.850] into Python, things don't work so well. So I had to do some tricks to convert that back to [19:33.850 --> 19:42.790] an unsigned byte array. So that, you know, no matter what we got in the service description, [19:42.790 --> 19:49.770] special characters or not, it wasn't going to work on me. I also found that the control URLs, [19:49.770 --> 19:55.270] the way that it was parsing the control URLs from the device description, it didn't account for the [19:55.270 --> 20:02.070] fact that some devices add query strings to the control URLs. So they have a generic control URL, [20:02.070 --> 20:09.090] they have a query parameter that it uses to determine what service you're trying to talk to. [20:09.190 --> 20:14.310] Without that, it just gave me back a bad request. So I had to modify the tool to actually use the [20:14.790 --> 20:22.750] query string that was part of the control URL. Lastly, there were still other issues with the [20:23.270 --> 20:29.310] parsing. It wasn't actually doing XML parsing in the first version. It was using a regex to try to [20:29.970 --> 20:34.210] search through the XML document to pull out the pieces that it needed. [20:34.330 --> 20:38.070] And if you had an XML document that wasn't structured the way it's expected, [20:38.070 --> 20:45.670] then it wouldn't work. So I switched it to use actual XML parsing because that just makes sense. [20:47.330 --> 20:54.570] I also changed the UI for the tool. Because I didn't want to have to dig through 100 tabs in [20:54.570 --> 20:59.910] repeater, I added some combo boxes where you can now select the IP, the service, and the action. [20:59.910 --> 21:04.250] So you can drill in on the specific request that you want to look at and play with. [21:04.450 --> 21:10.650] I added a full request viewer and editor. So you can look at that and maybe change things [21:10.650 --> 21:15.310] before you send it to intruder or repeater. And you have the option to send it to either. [21:15.310 --> 21:18.770] You're not sort of tied into one or the other like you were in the first version. [21:20.270 --> 21:28.950] And lastly, I added a couple new features to the tool. So I added the ability to subscribe to event notification. [21:28.950 --> 21:35.630] So it parses that service description, looks for state variables that have events turned on, [21:35.630 --> 21:40.290] and then it will build a request for you that you can generate a subscribe request [21:40.850 --> 21:47.950] to subscribe to those state variables. I also added an option to specify the single device [21:47.950 --> 21:54.230] description. So instead of searching your network, you can specify a remote service description. [21:54.290 --> 21:58.750] Searching only works on your local network because you're broadcasting to an address [21:58.750 --> 22:03.070] within your local network. So only devices within that local network are going to work. [22:03.250 --> 22:08.850] But if you go on Shodan, there's a lot of UPnP devices on Shodan that are exposed to the internet. [22:08.850 --> 22:12.930] If you want to play with those, now you can because you can paste that service description [22:12.930 --> 22:19.930] into there directly and load that and get all the actions. I also added some little buttons [22:19.930 --> 22:25.330] so you can view, pull up the service description and SCDP files directly from the tool. [22:25.370 --> 22:29.690] That was kind of more of a convenience for me as I was debugging and trying to figure out [22:29.690 --> 22:34.170] why things weren't working. To easily get to the device description and those files [22:34.170 --> 22:41.950] made it a little bit easier to see what I'm looking at. And now it's demo time. So we'll go through [22:41.950 --> 22:51.410] that tool and show you what it actually does. So UPnP Hunter 2.0. Right now it is not available [22:51.410 --> 22:56.810] in the Burp App Store. I do plan to push it to the Burp App Store at some point later. [22:56.810 --> 23:02.270] I first wanted to wait and give the original author a chance to pull in some of the changes [23:02.270 --> 23:09.190] that I pushed and maybe update the tool from there. He doesn't seem to have the interest [23:09.190 --> 23:15.610] to do that. So I will push this as a separate standalone version. So this is the tool. This [23:15.610 --> 23:20.370] is what it looks like in the Burp tab. And I'm just going to go ahead and start a discovery [23:20.370 --> 23:25.350] on my network. And this will take a few minutes. Because as I said, it's running the [23:27.350 --> 23:32.170] mSearch, reading back all the responses and then parsing out. So on this network, [23:32.170 --> 23:38.050] I have two devices that are running UPnP. This is the ACES router as we saw before. [23:38.050 --> 23:45.390] This one is the Belkin WeMo device. And this is the list of all the service endpoints that [23:46.170 --> 23:52.150] it understands. And if you look at the different actions, these are all the actions within that [23:52.150 --> 23:57.490] service endpoint. So I'll just pull up the SCDP here for a second. And so you can see, [23:57.490 --> 24:01.630] you know, action, get device information. That should be in here somewhere. Yeah, [24:01.630 --> 24:06.690] get device information. And then once you select it, it pulls up the request, [24:06.690 --> 24:13.730] builds out the request in this field here. So you can view it, see what different parameters [24:13.730 --> 24:19.670] it takes. And then you can send that straight to Repeater or to Intruder. And you'll see that [24:19.670 --> 24:24.470] Repeater picked it up. And now it's here. And I can send this request and get device information [24:24.470 --> 24:33.450] from that device. So that's, you know, very basically, that's how it works. So let's show [24:33.450 --> 24:39.570] you why this is cool and, you know, what we can do with this. So one of the things that's very [24:39.570 --> 24:47.330] easy to do with the Belkin WeMo device is controlling its on and off state. So it's [24:47.330 --> 24:55.610] called binary state. So we are going to find the request set binary state. And we can see there's [24:55.870 --> 25:01.530] a few different parameters here. And the parameter values are just filled with fuzz here to tell you [25:01.530 --> 25:08.070] where you can actually put input. And we'll send that to Repeater. We'll take all this fuzz here [25:08.070 --> 25:19.000] stuff out. And the only one that really is needed for most basic operation is the binary state. So [25:19.000 --> 25:25.320] I'm going to set the binary state to one, which should be on. And as you see over here, the light [25:25.320 --> 25:32.600] flips on and I get a response that now the binary state is on and some other information. And now I [25:32.600 --> 25:38.600] can set the binary state back to zero and the light goes off. So very simple, easy control of [25:38.600 --> 25:52.860] the device state through UPnP. Let's talk a little bit about event subscription. So in here, you will [25:52.860 --> 26:02.100] see a subscribe request. And it again uses a custom HTTP verb, subscribe. This is the path [26:02.100 --> 26:06.980] pulled out of the device subscription. And then again, there's a bunch of places where you can [26:06.980 --> 26:14.500] fuzz. Here in this section is where you put the parameters that where you want the callback to [26:14.500 --> 26:21.180] come to. You can set a timeout for how long you want to get notified of those event changes. And [26:21.180 --> 26:27.960] then this is a comma separated list of all the different parameters that this device will give [26:27.960 --> 26:34.980] event notifications for. So I already have one of these queued up over here. Let's see. [26:35.460 --> 26:42.460] So if everything is still working the way it should, I will get a device subscription, [26:42.460 --> 26:55.340] or sorry, event notification here saying the... that is not what I expected. Hang on a sec. [26:56.420 --> 27:03.340] Property change. Property state is zero. Okay. Sorry. That is what I expected. [27:03.860 --> 27:11.300] Now if I go back to the basic event request and I change the state back to one, [27:12.060 --> 27:18.700] now I get another notification coming in on that callback with the binary state is one. So we see [27:18.700 --> 27:25.220] the notifications and how they come back. What's interesting about the notifications and what this [27:25.220 --> 27:31.320] call stranger vulnerability sort of talks about is you can specify multiple endpoints that this [27:31.320 --> 27:40.040] calls back to. One of the neat sort of features of this is that if the first request doesn't... if [27:40.040 --> 27:45.900] the first URL doesn't... it can't reach it, it doesn't get a response from it, then it will try [27:45.900 --> 27:52.780] the next request, the next IP. So you can actually make use of this to do some internal port scanning [27:52.780 --> 28:00.080] of things on the network. If you can access this on the WAN side, for example, you can use this [28:00.080 --> 28:05.380] feature, specify a host and a port, and then specify a host and a port that you know it can [28:05.380 --> 28:14.900] reach. And if you get the callback coming to your IP address, you know that it wasn't able to connect [28:14.900 --> 28:22.460] to the previous one. So that's kind of a fun little thing you can do with the subscribe feature. [28:22.780 --> 28:28.960] But really, that's, I guess, sort of the end of my demonstration of this tool. I think it [28:28.960 --> 28:34.140] can be really powerful, especially being able to send stuff to intruder and do some fuzzing [28:34.140 --> 28:41.620] with this. And I can also show you here that if we just take this device description, [28:42.160 --> 28:47.960] paste it in here, then we get just that device descriptions services. We don't get all the [28:47.960 --> 28:52.760] other. So you can use that as well to sort of narrow down or look at remote ones, like I said. [28:54.540 --> 29:00.780] And I think that is it. So the repository for this is in our GitLab. The link is here. [29:01.580 --> 29:04.800] As I said, I do plan on pushing this to the Verp app store [29:04.800 --> 29:09.000] at some point in the future, but it's just not there right now.