 Thank you for being here. As you probably suspect by now, I'm gonna be talking about UPNP and UPNP mapping. This is a turbo talk, so obviously this is gonna be a little fast. I'm gonna try to go into as much details as I can, but any other questions or whatever, you can just go to the Q&A and I'll answer any questions. So let's do a brief introduction. Who am I? Not very important, but I'm a security researcher. I started working with security at the tender age of 14. I used to hang out and under it and work with ISPs back in the Dominican Republic, which is where I'm from, cable companies and all that. So that's that. What is UPNP? UPNP is Universal Plug and Play. Universal Plug and Play is a technology made by the UPNP forum, which is code name for Microsoft. They made it back in 1999 and the name probably gave it away. That was something made by Microsoft. The point of UPNP is to make devices work seamlessly. Be it connectivity devices or networking devices or media devices. There are also other devices that can be used, but mostly that's what UPNP is used for. So as you probably suspect, making devices work seamlessly is not a very good idea or it's a good idea, but it's not very plausible. We're gonna talk about specifically IGDs or the part of UPNP that works with networking devices. As you probably suspect, to make the network devices work seamlessly, you need NAT traversal. How many of you were, raise your hands if you were in the Dan Kaminski talk? All right, so you probably get the idea or the basic idea. Basically, a device on the LAN uses UPNP to automatically add port mappings on the device so that extra one devices can access the LAN, which is a great idea. But as you will see, it's not that great if you make it like UPNP does. So IGDs are basically found mostly on DSLs and some other devices. Cable models, not that much because cable models usually are bridged, but if something is routing and doing PPP, it's probably doing IGD. So big question and I've been working with Dan Kaminski on this one on how many IGD devices are online and a shed load. I mean, it's amazing. We thought we would have a minority of the devices on the net, but I have personally seen half a million devices across different countries open and accepting UPNP requests. So let me, first of all, explain a little bit of how UPNP works briefly. Basically, you start with a discovery process, which is relies on multicast UDP. It sends a multicast UDP and any device listening replies back with a unicast UDP. This unicast UDP, I probably you can't read it very well, but it's in the white paper. It describes or points out a location, which is just an XML file describing the different services and devices available. To execute on that UPNP device. After you get that unicast, which is the blue part, the yellow part, you get to the green part with this, which is unicast TCP. Basically, it's SOAP requests and after that, after you get the SOAP request, the description of the device to XML, you get send a SOAP request which maps a port. You probably can see it either, but over here you have different arguments that you can use like least duration of the port mapping, internal client, external port, and remote host. Basically your basic port mapping arguments. So let's do a bit of the UPNP hacking timeline. It started in 2001 and came from FDU security. He found a couple of denial service attacks for the Windows XP stack. Obviously, UPNP was implemented in Windows XP first. Microsoft wanted to promote the technology. Then in 2001, again, EI published buffer flows for the same stack. You probably remember that one. It was pretty popular. Then in 2003, Bjorn Stikler talked about UPNP information disclosure. Now, there's not a lot of information that's being thrown out by UPNP, but it's enough. It's not that good. You'll see with the demo how much information we can get. Then in 2006, Armin Hermel, that's a typo where Armin is in, he started publishing UPNP facts on the site, UPNPhacks.org, and he's basically, let's say, like one of the fathers of UPNP hacking. He has examined all the UPNP stacks and described which stacks allow some actions and whatnot. Then in 2008, we had an attack by New Citizen, which was pretty smart. They basically relied on the clients, internal clients of a network sending soap through JavaScript. Basically, the purpose of that was opening the web administration port of clients that access sites and such. So what are the main problems of UPNP? Well, first of all, this is the word plug-and-play. I don't know if you guys remember Windows Night Again and plug-and-play and the whole idea, it didn't work. I mean, it's not rocket science, and every time I see plug-and-play anywhere, I just have to look it up because I don't want to go through the same nightmares that we went through in the early or late 90s. So the other thing with plug-and-play, it's a pretty nice idea. We would love to have things plug-and-play, but it doesn't work good with security. I mean, you can't have security devices plug-and-play, being plug-and-play. I mean, you need to authenticate something, you need to ask questions and all that. Well, that's one of the main problems of UPNP, too. UPNP has no authentication whatsoever at all. In fact, the only way they consider an entity that could actually execute commands is just if they have an IP assigned for it, which is ridiculous. I mean, it's like DefCon sitting down and saying, oh, how are we going to let people in? How would we know who would let in? And then someone said, if they exist, they can't come in, which is ridiculous. I mean, don't even go through it. After that, the other problems are that most stacks do not validate data. And what we mean by this is that, first of all, UPNP was made or designed for land use only. And that's not true, unfortunately. But not only that, port mappings were designed to work for internal hosts that wanted to traverse an app and add port mappings. So in this case, most stacks, or a lot of stacks, do not check if the internal IP is actually on the land or internal. So what that actually allows us is that UPNP is to stick any IP that we want in that port mapping. So if I want to say, add a port mapping at the device pointing to Amazon IP port 80, it's doable in most devices, which is also a little bit weird. The other problem is, as I was saying, UPNP was designed for land use and most, or a lot of devices, use or allow indiscriminate one request. I mean, requests of UPNP actions coming from the one, which is, doesn't make any sense. In fact, the UPNP protocol says not to do that. But to be, it's that the IGD version one protocol says specifically, it's not recommended to do that. To get them credit, though, on the IGD version two paper, they made that sentence on caps. So I guess they're making a better point now. And on the other hand, we have devices that don't even log UPNP requests. I mean, we can play with it, do whatever we want with it, and no one will ever see it because the device doesn't have the capacity of logging in, which is also a bit weird. There's also a ton of other problems. We have command execution on some stacks. And as you saw, the denial service and buffer rule flows. In fact, the denial service is so bad that when I was programming UMAP or the tool I'm going to showcase, I accidentally crashed my modem like a thousand times. And I didn't even do anything. I'm just sending bad requests and the device will go dead. So the devices affected so far, we don't know yet how many devices are affected. But obviously some vendors have taken into account what's been going on. And we have Linksys, edimax, sidecom, Broadcom, which is not listed here. But the most common stack on the net, which is vulnerable, is the speed touch or thumbs on, or now, technical stack. We have devices roaming around the net on big amounts. So UMAP, the tool, what is it? First of all, it's a SOX proxy server that forwards or pipes the request through UPNP devices. I'm going to explain it a little bit better and a little bit further down the road. It's also a TCP UDP scanner for hosts behind the IGD net. Basically, we can scan the services of the hosts inside the net from outside. And also a manual port mapper for UPNP devices. So how does it work? As I explained in the first part of the presentation, UPNP relies on multicast. So that is not a very good scenario for a one request or search. Obviously we can't use multicast on the one. So basically what we do is we skip that part completely and we just go on to fetching the XML description files to the locations. It's pretty simple. It's like fetching HTTP files, not that big of a deal. And then it also uses a control part of the UPNP protocol, which is actually what executes the actions or the commands that UPNP allows on devices. So here's a flow diagram of more or less how UMAP works. It basically takes a list of IPs and starts scanning for open control points or UPNP devices. Once it receives a SOX request, if it has a positive UPNP device, it attempts to add the port mapping, then it opens the connection and pipes the connection through to the SOX request or the client that's making the SOX request. And after that, it attempts to delete the port mapping. And this is very needed on UPNP because UPNP does not allow an infinite amount of port mappings. Actually, some devices allow as little as 10 port mappings at a time. So if we actually did a port mapping for every connection, we wouldn't have a very accurate or a very good connection. So we also have the part of scanning the internal host. And basically it also checks for open control points. Then it tries to guess the IP or the internal LAN block that's being used. It adds a port mapping for each IP, internal IP. Let's say if I want to scan port 21 of all the hosts on the inside of the LAN, it starts adding port mappings for 10.001 and 21 and then tries to map it to an external port. And then the program tries to check if that port is opening the external port on the one IP. If it's open, obviously you can establish the connection for the internal host and the internal services. And also it does the deletion of the port mapping. So what are the cons with UPNP mapping? A lot. First of all, the UPNP stacks are buggy and unstable. It was kind of hard, or not that hard, programming U-Map. The one being distributed on the CDs are very buggy. So I would suggest just telling you the new version when I release it tonight on the site. But basically UPNP stacks, even though they're supposed to be in a standard, they don't behave on the standard and they have minor differences. The other thing is that obviously we have limited bandwidth because we're relying on the upload bandwidth of the devices. And also we have problems with protocols that have a heavy amount of connections. I mean we can use UPNP mapping for maybe mapping ports for SSH, maybe some web request. But if you get something like torrent or whatever, obviously it won't work that well. I mean if we have only a limit of 150 or 200 mappings at a time, it's just not going to work. And the other thing is that some devices, even though they report that they opened the port, they don't. They say everything's okay, 200 okay and everything in the reply. But when you go and try to connect to the port, you have nothing. So that's obviously not very good. So let's do a little demo on U-Map and let's go for the proxy mode. Let's see if I can get this to work. I had to modify U-Map so that the real IPs don't show because I don't want my Astrone in jail and raped. So when you get the real version though, you can have all the fun you want. It shouldn't matter. In fact, there's also an issue on if this is, it's obviously maybe it could be illegal but not that much because it's the same idea of an open proxy. It's just someone that has a badly configured device on the net that's allowing people to forward traffic. Obviously you're not authorized for doing port mappings but it's not actually breaking into the device. So maybe I won't get my Astrone in jail. So here we go. I'm just going to scan a standard IP block and it should start running right away. I don't know if you can see it back there. Can you? All right. So on the right hand here we have the positive IPs and as you can see here, we have a lot of details that come out from the device. First of all, we can get the serial number from the device, the model number, who makes it and the MAC address of the device. This obviously would help also for those devices that come with WEP keys tied to the serial number and all that. So that's not good either. So not only that, we also have a group of commands that we can execute on any device. And let me remind you that we are scanning a random block somewhere and it's not, I mean, we're not doing any tricks. So here are the commands that we can execute. There are not a lot of interesting commands. Well, maybe or maybe not. So we have the first part that's not on bold and those are the commands that are actually advertised by the device. Now the ones that are on the bottom are the ones that are not advertised by the device. Obviously, we wanted to try just in case a certain hacker would do and it works. I mean, even if the device doesn't advertise this command, you can still execute the command. So, for example, if I want to check out what's the upload and download bandwidth for this device, I can just execute and here we go. We get that this device is running an upstream of a 350-something and a downstream of two max, which is pretty convenient if you want to use for a SOX proxy and you want to know what kind of bandwidth or latency you've been using. And we also have other commands like force termination. I assure you force termination is not for a contract or anything. It will actually close down the device and close out the connection. So I don't think the denial service is even a big deal because if you have a command that actually turns off the device, what's the point? I mean, we don't need the denial service. We just have to turn it off. So we also have other commands like ad port mapping, which is basically what UMAP uses for connections. And we also have these other commands like get username and get password and they actually work. Now, on the bright side, the username and the password they're talking about is not the administration interface but the PPP authentication username and password. Now, this is maybe not that bad for some guys because, I mean, there's not much you can do with it. But unfortunately, some providers use a customer number as a username for the PPP device. So that would also do something that you don't want to and get you some information that you shouldn't have. Let me hit another command. Let's see if the username works. There you go. That's a username for the PPP of that device, which is also very weird. So, onto the more important stuff, let's go for what I set up is this UMAP is actually scanning and it opens up SOX port and you can send a request and it will map it through to that IP that I have selected. We can test it right here. I've set up a page to show this mapping. Let's see if it works. Remember that UPNP usually is very buggy and unreliable. Then there it goes. It works. Now we have a very disturbing image of Bill Gates over there. But as you can see, we have the IP over there. You can test that URL out if you want to and you can see that it will point out the IP you're working at. If you can see an UMAP, this is the IP we have selected. Now, if I want to just use another device, like the one below 244.6, then it should work too. Let's see. There we go. Let's see. In fact, we can go on Google and show you should go to the Google for the Dominican Republic as this is a device for the Dominican Republic. Now, as you probably suspect, this is pretty bad. I mean, we have devices like this going on in the Dominican Republic, Colombia, Thailand, a lot of countries, and a lot of devices are going on like that. We also have another functionality of the UMAP, which is scanning for internal hosts. Now, I don't want to do live scanning of the hosts because most hosts nowadays are using other gateway devices like Lynx's wireless routers and all that, which block all the one request. But if there are devices that have direct connections to other devices or PCs, then we could actually map. Let me show you a couple of mappings I did earlier on. Now, don't laugh at my lead smudging skills from GEMP. So basically what I want to show you here is UMAP and this number up here on the total positives. This scan was running for a couple of days and we got 88,000 devices with open UPNP ports, which is ridiculous. And this is actually a port mapping. As you can see, the smart part is the external IP address and the external port, and we have the internal IP address, which the mapping has been made for. We also have another example of, in this case, for example, I just set it to run for that IP and we got a Windows IP 10.005.139.445. Now, this is maybe a bigger problem because obviously you can traverse an ad from the one, which is something you don't want. And we have all the possibilities. Now, we can't use this sometimes on some protocols, let's say, because we have to map these ports on some of the higher ports. We can't use the same 139 or the 445. So that could make things a little bit more difficult, but it still works. And obviously if you have an SSH port or an HTTP port, it won't matter that much. Let's keep on working here. So as the internal LAN scanning tool, and how do we fix this? I don't know. There's no real solution or the best solution. First of all, we need to get everyone to be aware of this and start configuring their devices for UPNP only accepting action from the LAN side. Now, unfortunately, some devices, even if after you configure them to accept the action from the LAN side, they just don't work. I mean, you can configure them and they will keep on working on the one side, which is pretty bad, too. We also could work with ISPs, which could do some base configuration to disable by default the UPNP 1 request. And then we can do this. Now, this is a big problem because most ISPs just say that's not my problem. That's a customer's problem. I don't want to, you know, it's an industry problem, which is, yeah, deplorable. And on some cases, if you don't have any other choice, you could just disable UPNP all the way, which is not good. I don't know if you guys have used UPNP that much, but I'm a gamer and you can't play with PlayStation and Xbox without UPNP, unless you have some kind of DMC or an external IP address pointing directly at your device. So mitigation is going to be a little difficult, but most people can just configure their devices so that they can block the request from the one. As Stan Kaminski was saying at the previous talk, it's like having a firewall, asking people if they want to block or unblock, which is kind of weird because, I mean, why should you ask? If obviously if you configured, you shouldn't be asking. And that's about it. I have any questions or, I'm sorry?