CyberWire Daily - UPnProxy infiltrates home routers. [Research Saturday]

Episode Date: May 26, 2018

Researchers at Akamai recently published a white paper titled UPnProxy: Blackhat proxies via NAT Injections. In it, they describe vulnerabilities with Universal Plug and Play capabilities in home routers, and how malicious actors could take advantage of them.  Chad Seaman is a senior CERT engineer at Akamai, and he's our guide.  Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. JoinDeleteMe.com slash N2K and use promo code N2K at checkout. The only way to get 20% off is to go to JoinDeleteMe.com slash N2K and enter code N2K at checkout. That's JoinDeleteMe.com slash N2K, code N2K. Hello, everyone, and welcome to the CyberWire's Research Saturday.

I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs

that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context. Simplifying security management with AI-powered automation. And detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI.

Learn more at zscaler.com slash security. Universal Plug and Play was rolled out by Microsoft and it was intended to make networking in a consumer environment user-friendly and automatic. That's Chad Seaman. He's a senior cert engineer at Akamai. Our conversation centers on their recently published white paper, UPN Proxy, Black Hat Proxies via NAT Injections. If your Xbox, if you're loading up a game and it needs ports 60 through 61,000 with UDP, it may send traffic to you on requests that you did not necessarily initiate. Your NAT will block that. So if something is attempting to come into your network, but the NAT has not seen you communicate out on those ports,

it will not know that that traffic is destined for you and won't really know what to do with it. So it'll just throw it away. So what NAT was made for was a machine behind your router could interact with UPnP and pop holes to destine that traffic to you at all times. Think of it like automatic port forwarding configurations. And what does NAT stand for? Network address translation. All right, so that's the intention, but how did it actually work out? I mean, it works really well. It's for gaming and consumer networks. It meets its intended goal. The problem is there were several flawed implementations that were introduced into the wild by various vendors and software stacks. So take us through, what's the history of the vulnerabilities there?

2006, a researcher came out and basically said, hey, there's a bunch of these UPnP-enabled devices, whereas it's a land-scoped technology. It's not meant to ever be on the internet. It's meant to run on your local network. Some of these daemons that are running this technology on these devices is basically listening on both interfaces. It's not just listening on the LAN side of the network, it's listening on the WAN side, and it's responding. And that is the fundamental problem. There have been other vulnerabilities

discovered in the UPnP stack, remote code execution and command injection, and stuff like that. But all of this primarily centers around the one flaw that is parts of the technology that should never be on the internet are listening on the interface that faces the internet and responding. I see. So walk us through that. How does this NAT injection exactly work? The first step is called SSTP, which is Simple Service Discovery Protocol. It's the UDP portion. So if you have ever been on a network, a local network, and you've opened up Wireshark and started listening, you would start seeing all of these connections and things coming through that are broadcast UDP traffic. And they're basically doing what's an ssdp service discovery request so anything running

on the network that's running ssdp will see these requests come in and respond back and say hey i speak this language and here are the services i offer because once again we're assuming we're on a land network and the devices there are trusted. And this is how these devices expose media streaming capabilities and how a device can find the router that it needs to poke holes in for NAT purposes. So the first step is that UDP broadcast, which people are already using for DDoS purposes, but the response that comes back actually has some more information inside of it. And some of that information is the location as to where you can find the UPnP TCP components, the daemons that control NAT and other service offerings for that device. So for the routers, you can hit them with an SSDP request. If they

respond to that, it means that's already one flaw, right? It should be responding to that, to the outside world. Correct. And when it responds back, it tells you where to find the UPnP daemon, but the UPnP daemon is scoped with the IP address, assuming that you're on the LAN. So it might say, go to 192.168.1.1, port 56,538, slash, and then give you a whole path, potentially sometimes even with the UIDs of the device to make it so you can't just guess it. So it was designed to be not really able to be found super easily or guessable,

and you take that and change that IP from the internal to the external IP that you just communicated with to get the SSDP response, and there is a chance that you will be talking to the TCP daemon that is the UPnP functionality. From there, it leaks all kinds of information. You can find manufacturer, model names, serial numbers, firmware versions, capabilities, service offerings, and then from each of the service offerings, you can drill down and find even more capabilities.

You can, in some cases, remotely reboot stuff. You can see transfer statistics. You can see all kinds of stuff. You can even subscribe to events. If you would like to know when this device does things, you can potentially subscribe to those events remotely and have it ping you when something happens. In this case, the UPnP daemon is exposing the internet gateway daemon, I believe it is, but it's called the IGD in the services lookups. And this is what allows you to see what UPnP forwards are in place and allows you to also inject them. Take us through that injection.

How does that work and then what would people use that for? People would use it for in a regular functional safe network. They would use it for just like we described with the Xbox popping holes in the net for certain UDP ports or something. In this case, you basically just have to craft a SOAP request. You can do it in a single curl command. In the white paper, we actually give some examples as to how easy it is to do and the commands to potentially do it, or at least the ones we used in our research. Well, people right now are using it for bad stuff. They're, they're using it for proxying traffic out of devices they don't own. And we can only assume for what they're doing

that for. Hmm. Let's walk through some of the things that people are using this vulnerability for. What are the bad guys doing? Well, we don't know. That's the problem. We don't have any honeypots or anything like that currently running to intercept this traffic to see exactly how they're using it. The only thing that we were able to do is kind of passively look at what they've have injected into these devices and then try and draw some kind of conclusion from that. You know, our assumption is that we're seeing it used for, you know, account takeover, Our assumption is that we're seeing it used for account takeover, potentially credit card fraud, ad click and affiliate fraud campaigns. And all of these things have potential to make a lot of money.

So there is incentive there for them to do that. The only real case that we know that somebody was using it was actually discovered by Symantec as part of an APT group that were running the Inception framework is what they were calling it. And the bad guys were basically storing malware on a WebDAV web service for distribution purposes. So this is just where they store their malicious files. So to hide their own tracks, they had chained together multiple UPnP proxies. So when they were interacting with the web service, it would appear to be some person's home router, some other IP. And the reality is that before they even jumped through that IP, they jumped through multiple other UPnP proxy compromised devices to get there. So it's kind of like that meme you see on the internet, good luck, I'm behind seven proxies. That was literally what they were going for. Now, if I'm the person whose router has been compromised,

would I know that anything was going on? No, you would have no clue. There's no signs on the device. So for UPnP in general, like I said, it's an automagic device that's meant to be used in an automated fashion from one device communicating to another device. It's not supposed to be a hands-on human experience. And because of that, there's no way for humans to easily inspect, audit, or manage it straight out of the box. If you log into your router and you start digging around and looking at your NAT table, first of all, the only thing that's going to show up for you in your port forwards

are the port forwards that you have put there. Anything that was injected into your NAT table as a port forward by the NAT daemon or the UPnP daemon will not show up there. There's not really a good interface for dealing with that. I think there are some tools on Windows that will let you kind of audit a UPnP device. But what we basically opted for was some shell scripts and writing SOAP requests because that was pretty straightforward. Yeah. But so again, I'm imagining if you're someone that this has happened to, I guess part of the vulnerability is that someone could be using your router to proxy data through.

They could be up to no good, and someone investigating that could end up on your doorstep. Yeah, and that's exactly the reason that we wanted to publish this research. When we initially found it, it seemed like it was being used by parties to sidestep censorship efforts to get access to uncensored information. At first, I was really hesitant to kind of throw cold water on that effort. When we started digging deeper into it, it was like, no, no, this is much bigger and much worse. of digging deeper into it, it was like, no, no, this is much bigger and much worse. And the potential for abuse, you know, I think what we're seeing now pales in comparison for the potential that this has to introduce to forensic investigations and law enforcement efforts. So I mean, think about it like this. I could set up a malware distribution server and I could go around to when we did our basic head count,

there were 750,000 of these things that responded to our TCP probes. So that's 750,000 potential exit points I can find now. All I have to do is inject one port pointing back to my server into, what, 15,000, 20,000 of these machines, compile that list of what the IP was

and what the port was, and then write that into my loader distribution software. So now an investigator that's being infected by this is going to think that we have 20,000 C2s. When they look up at these devices or these IPs that this stuff is coming from, They'll basically have clean reputations. They're all sitting on residential networks, consumer grade stuff where you would not expect malware to be coming from. And then you start to draw conclusions. Is it a machine behind that thing that's infected? Is it the router itself that's infected? And at the end of the day, none of those answers would be true. If you were investigating a potential infection

and you were to go knock on a door and ask to see a potentially compromised device, that potentially compromised device would not exist on the network and it would not be on the router itself. Because it is, it is the router and yet the router itself doesn't, doesn't reveal, you can't just get in an interface and have it reveal what's going on under the hood by design. Unless you were to explicitly go out of your way to inspect the UPnP NAT table, you would never find the reason. Nothing weird would seem out of place until you looked at the UPnP table. And so it seems like this would be a good avenue for DDoS and botnets as well.

Yeah, yeah, it could. I mean, that's the thing. If we talk about the distribution of malware, the same conversation could be had about botnets and C2 communications. If I needed to hide my C2, why not stick it behind seven proxies, right? If you're jumping through multiple residential gateways to communicate with my endpoint, you're going to be thinking it's some kind of P2P network. You're going to be thinking some kind of crazy transient C2. And the reality would be that, no, it's just one C2. It's just tucked behind multiple residential gateways that you don't even know to inspect. Now, if I wanted to, I don't know, to fix this, if I was afraid that I might be falling

victim to this, is this a situation where I could do some kind of hard reset on the router and start from ground zero? Yeah, you could. You could do a hard reset on the router. And as soon as you did that, you would want to go and disable UPnP. The problem is that UPnP is a pretty handy functionality for the LAN side of the device. Before you do that, you should inspect or maybe start Googling around and seeing if your model or manufacturer could be impacted by this, if there's known vulnerabilities in the UPnP stack. We also included in the white paper, there's a small script with a payload where you can point it at your own home gateway, and it will attempt to dump the NAT table into a terminal for you so you can actually inspect and see what's in there. And the presence of something being in there isn't scary. It's only scary if you're seeing other people's stuff in there. So you'll see your 192, 168s, like your torrent clients, Skype inject stuff, WhatsApp inject stuff, like different apps are injecting stuff into this table for their own

personal usage. So it's not scary. It's just when you start to see internet routable addresses showing up in there, that's when something is wrong. Now, in terms of the manufacturers, how have they addressed this? Is there acknowledgement that there's an issue? Have there been any updates? Do new models that are for sale right now, are they still vulnerable to this? Well, it's kind of a crapshoot. You can't really tell. The disclosure happened in 2006, which gives us plenty of time to actually fix the problem. problem and in just our our quick and dirty head count of device models manufacturers based on the information leakage from the upm proxy the upmp payloads that came back we identified like 72

manufacturers and 400 models some of those manufacturers came back in dispute and we were like okay well let's dig deeper into this and and make sure you're wrong or we're right or vice versa and we actually started digging up more models for some of those manufacturers that we didn't even notice in the first pass. So there's actually far more devices that are vulnerable than what is listed in the actual device section of the paper because of time constraints and needing to get this paper out. I wish I could say that there was a lot being done about it. Some of the manufacturers have come back and said that those devices are not vulnerable. They've tested them. But the fact that we were even able to identify them from internet-based

scans would suggest otherwise. I haven't heard a whole lot about them rolling out patches or notifying users or anything like that. From what you've been able to examine, from what you've been able to gather with the research that you've done, how widely spread is this problem? Should I assume that my home router has been compromised or is it something that's, you know, there's so many routers out there that it's few and far between the ones that have actually been infected? I mean, there's millions upon millions of home routers out there that don't have this problem, right? I believe in the paper we said that when we started the scans, it was about 4.8 million that were identified via the SSDP leaks. Of that 4.8 million, 750,000 responded to TCP probes.

And of that 750,000, 65,000 were found with injections that pointed to internet routable devices or IPs. So that's not to say that only 65,000 of them were vulnerable. 750,000 of them are potentially vulnerable. 65,000 were actively being exploited. There were others where we were able to communicate with the daemon, but there was nothing in the NAT table that suggested anything suspicious was going on. It looked like just regular 192.168 injections from devices living on the land. So you're talking a small percentage of the overall footprint, but it's still a significant number if you're trying to defend against it. And it's

still significant if it's happening to you. If the FBI comes knocking on your door, you're not going to care how many other people it's happened to. Right. You should keep a copy of this white paper printed out and sitting next to your router, right? Just in case. Exactly. Yeah. All right. Well, I mean, it's an interesting story. It's one of those ones that I guess is to be continued because it's happening. It's hard to defend against. So I guess it's one of those ones that I guess is to be continued because it's happening. It's hard to defend against. So I guess it's one of those ones we'll have to see how it plays out.

It's, I guess for you, frustratingly unresolved. It's frustratingly unresolved. And it's one of those topics where I feel like we need people looking at it. We need people to know it exists, but we also risk stoking the fire of adoption by even mentioning it. You know, I think it's important for forensic investigators and law enforcement and stuff to know that this capability exists and to know to look for it when they're dealing with their investigations. But from the DDoS perspective and from the Black Hat proxy perspective, from the carding perspective and the account takeover perspective, it also presents a serious threat that I don't know if we've actually seen it really leveraged yet. Our thanks to Chad Seaman from Akamai for joining us.

The white paper is titled UPN Proxy, Black Hat Proxies via NAT Injections, and you can find it on the Akamai website. Cyber threats are evolving every second, and staying ahead is more than just a challenge. It's a necessity. That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely.

Visit ThreatLocker.com today to see how a default-deny approach can keep your company safe and compliant. The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing Cyber Wire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar,

Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Vilecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick,

Jennifer Iben, Rick Howard, John Petrick, Jennifer Iben, Rick Howard, Peter Kilby, and I'm Dave Bittner. Thanks for listening.