New Upnp exploit affecting most Asus routers - "UPNproxy: Blackhat Proxies via NAT Injections"

[ColinTaylor]

Then it seems like it should be in the LAN settings instead of WAN. Even the nvram setting tag name implies it affects WAN.

Of course it effects the WAN, that's whole point of it. Just like the other settings on that page.

"...the router's UPnP service can only be controlled from a device on the LAN..."

 

[RMerlin]

Then it seems like it should be in the LAN settings instead of WAN. Even the nvram setting tag name implies it affects WAN.

It's in the WAN settings just like the other port forward and port trigger settings because its goal is to open a port to the WAN interface.

 

[st1ngy]

It's in the WAN settings just like the other port forward and port trigger settings because its goal is to open a port to the WAN interface.

Thanks for the simple explanation. But I must be missing something because that seems contrary to what you said about Asus not exposing UPnP ports to WAN. Maybe it's just the terminology that's got me confused.

 

[CrystalLattice]

RT-AC3100 not listed. RT-AC68U is listed. What about TM-AC1900's? Doesn't not updating the f/w for that model leave TM and Asus vulnerable to legal action?

TM-AC1900 was updated for Krack attack in Dec. 2017. Asus may or may not have included all known security fixes. No announcement was made.

 

[KevTech]

They claim that the exploit requires WAN access of the service. Thing is, Asuswrt does NOT open UPnP to the WAN, so I have no idea how they can claim it's vulnerable to that exploit...

In case anyone wants to test this you can go here: https://www.grc.com/x/ne.dll?bh0bkyd2

Click on Proceed then when the next page loads click on GRC's Instant UPnP Exposure Test

I have UPnP enabled in the router and get this result.

 

[Ronald Schwerer]

In case anyone wants to test this you can go here: https://www.grc.com/x/ne.dll?bh0bkyd2

Click on Proceed then when the next page loads click on GRC's Instant UPnP Exposure Test

I have UPnP enabled in the router and get this result.

View attachment 12767

Watching the Security Now video from that link (which was from 2013), Steve Gibson mentioned ISPs should block UDP port 1900 and that would solve the problem. So without knowing whether it is blocked at a higher level, that test might not indicate that the router itself is safe. Of course, in practical terms it doesn't matter who blocked it.

 

[huygens_25]

They claim that the exploit requires WAN access of the service. Thing is, Asuswrt does NOT open UPnP to the WAN, so I have no idea how they can claim it's vulnerable to that exploit...

Hi RMerlin,

From reading their (Akamai) paper, I think they need that the Router (e.g. a vulnerable ASUS router) has already at least a UPnP service active (potentially several). So imagine, one has launched an application on your computer on the LAN (e.g. a video conferencing tool or game for which the exploit could work, it seems that not all UPnp opened port can be exploited), that application has opened a port on the router using UPnP.

Then the attacker just need to scan the router WAN interface, it will detect the opened port, and it seems it can then craft a SSDP probe toward this port or send a specially craft HTTP URL using the `Location: ` header. If the UPnP port is "vulnerable", it can then be exploited to open other UPnP port from the remote WAN interface.

For the attack to work, you need a vulnerable router where UPnP is activated. Then you also need to have an application on your LAN requiring UPnP and which is currently running (so has probably opened the port), and that port needs to be exploitable (it is not clear from the article which are vulnerable but potentially UDP opened port cannot be exploited using crafted HTTP, or TCP opened port cannot be used for SSDP probes, etc.) and they are I guess other factors which could prevent the exploitation. I agree that my description is still vague but the current document is not particularly clear on how this can be exploited (for good reasons in a way).

But anyway, while waiting for Asus to provide a patch, better disable UPnP (if you know how to configure Port Forwarding, and application can have a fixed port defined, then usually you can avoid UPnP all together).

 

[eddiez]

Hi RMerlin,

From reading their (Akamai) paper, I think they need that the Router (e.g. a vulnerable ASUS router) has already at least a UPnP service active (potentially several). So imagine, one has launched an application on your computer on the LAN (e.g. a video conferencing tool or game for which the exploit could work, it seems that not all UPnp opened port can be exploited), that application has opened a port on the router using UPnP.

Then the attacker just need to scan the router WAN interface, it will detect the opened port, and it seems it can then craft a SSDP probe toward this port or send a specially craft HTTP URL using the `Location: ` header. If the UPnP port is "vulnerable", it can then be exploited to open other UPnP port from the remote WAN interface.

For the attack to work, you need a vulnerable router where UPnP is activated. Then you also need to have an application on your LAN requiring UPnP and which is currently running (so has probably opened the port), and that port needs to be exploitable (it is not clear from the article which are vulnerable but potentially UDP opened port cannot be exploited using crafted HTTP, or TCP opened port cannot be used for SSDP probes, etc.) and they are I guess other factors which could prevent the exploitation. I agree that my description is still vague but the current document is not particularly clear on how this can be exploited (for good reasons in a way).

But anyway, while waiting for Asus to provide a patch, better disable UPnP (if you know how to configure Port Forwarding, and application can have a fixed port defined, then usually you can avoid UPnP all together).

So what 'patch' should Asus provide? There are so many 'ifs' in your statement...You are referring to potential firmware vulnerabilities that are pre 378.x ... I've read the article and can not find why the mentioned routers are vulnerable with the current firmware...

Verstuurd vanaf mijn SM-G965F met Tapatalk

 

[ColinTaylor]

@huygens_25 I thought you might be onto something there... but no.

To me the entire vulnerability is built on the ability to do an unsolicited SSDP probe from the WAN side (page 2, "The Basics"; page 14, "How to Fix It"). Akamai claim they built their list of vulnerable routers from the "leaky TCP daemons" on "devices that we could positively identify". Given the size and credibility of a company like Akamai their claim shouldn't be taken lightly.

The other thing that is suspicious (as @eddiez alluded to) is that all of the Asus routers listed are old models. There are no models listed that were released in the last few years.

To check whether my router (see my sig.) was vulnerable I did a little test. We know SSDP takes place over UDP port 1900. I did an SSDP query to my UPnP server and it responded saying that it was listening on port 60568 (Akamai's example was listening on port 52869). Doing a netstat on my router confirmed this to be the case, but also it appeared to be listening on all interfaces .

# netstat -an | grep -E "1900|60568"
tcp        0      0 0.0.0.0:60568           0.0.0.0:*               LISTEN
udp        0      0 0.0.0.0:1900            0.0.0.0:*

However, doing a port scan on my router from the internet shows that those ports are not open and do not respond .

So it would appear that although miniupnpd binds to all network interfaces it doesn't necessarily respond to all of them (listening_ip=br0 in the config file). Which is a good thing. So given that newer routers, and by implication firmware's, don't appear to be vulnerable I'm wondering whether this was actually an old bug in miniupnpd rather than an implementation error by Asus. Looking in the changelog for miniupnpd we see things like this:

2017/05/24:
get SSDP packet receiving interface index and use it to check if the
  packet is from a LAN

Anyway, that's my thoughts on it at the moment.

 

[huygens_25]

@huygens_25 I thought you might be onto something there... but no.

(...)

I wanted to do also some real test on my ASUS RT-AC68U which is part of the marked vulnerable routers. And before I finally found where the UPnP option was (I know I had deactivated it, so I needed to reactivate it to test it) I found out that:

1. Asus activated DDNS without me configuring it in the first place!! I'm quite pissed, it is like being tracked without consent, btw Asus the GRDP is coming here in EU, so please ask consent before doing such a thing because by storing and matching ma IP address to simething, you are using my personal data! I never agreed to that!
2. Even more grave, they "**##**" (censured by myself) activated the remote web access without my consent!!! That's a no go. I was looking to replace my router by a new model, that the drop that will make sure I don't buy Asus. I was happy with that model and I'd been recommending Asus for router around, I no longer will do so!!! Remote web access is an absolute NO GO Asus!

Anyway, back to the main subject, my UPnP server is running on yet another port but also listening on all interfaces. This is not such a problem because the firewall is blocking access to it. I have currently nmap running it should finish in 30min but I need to take care of the family now. I will report further results later today.

 

[OzarkEdge]

I wanted to do also some real test on my ASUS RT-AC68U which is part of the marked vulnerable routers. And before I finally found where the UPnP option was (I know I had deactivated it, so I needed to reactivate it to test it) I found out that:

1. Asus activated DDNS without me configuring it in the first place!! I'm quite pissed, it is like being tracked without consent, btw Asus the GRDP is coming here in EU, so please ask consent before doing such a thing because by storing and matching ma IP address to simething, you are using my personal data! I never agreed to that!
2. Even more grave, they "**##**" (censured by myself) activated the remote web access without my consent!!! That's a no go. I was looking to replace my router by a new model, that the drop that will make sure I don't buy Asus. I was happy with that model and I'd been recommending Asus for router around, I no longer will do so!!! Remote web access is an absolute NO GO Asus!

Anyway, back to the main subject, my UPnP server is running on yet another port but also listening on all interfaces. This is not such a problem because the firewall is blocking access to it. I have currently nmap running it should finish in 30min but I need to take care of the family now. I will report further results later today.

1,2. Agreed. You probably used the ASUS Router app, so you will likely want to uninstall that app from your Android/IOS device. I certainly did.

OE

 

[ColinTaylor]

Anyway, back to the main subject, my UPnP server is running on yet another port but also listening on all interfaces. This is not such a problem because the firewall is blocking access to it. I have currently nmap running it should finish in 30min but I need to take care of the family now. I will report further results later today.

It'll be interesting to see what you discover. I just tried turning off the firewall on my router (note that this restarts miniupnpd so the port number changes) and the UPnP ports were still not accessible from the internet.

 

[huygens_25]

It'll be interesting to see what you discover. I just tried turning off the firewall on my router (note that this restarts miniupnpd so the port number changes) and the UPnP ports were still not accessible from the internet.

I'm wondering if - as you suggested/implied - non-patch older Asus router (so running a default older firmware) would be the only one affected. Asuswrt in its latest release seems to have a recent version of miniupnp, at least it should have the fix you mentioned.

Nmap is reporting for the WAN interface no other ports on TCP or UDP than those which I explicitely allowed. So the TCP and UDP port for miniupnp are not exposed on the WAN even if UPnP is activated and miniupnp is listening on both interface. On the LAN side I can certainly send probe to the UDP port 1900 and get the information on the TCP port and many information about the router, etc. But not really newsworthy anyway, on the LAN side if you have UPnP you can do many things already by design, and by scanning port you can learn a lot about the router information even without UPnP.

I have tried to launch some applications on my LAN which make use of UPnP. As I had explicitely activated UPnP on the router, I could see new ports being opened on the WAN interface, all expected behaviour. Then I've been trying to send SSDP probes to these port on the WAN interface (and trying to trick any listener by using the "Host" multicast address), none of my attempts worked. It does not mean the problem isn't there. There is not enough details in the current report from Akamai so that I can understand exactly what is required in order to have a successful SSDP probe over the WAN.

At least on Asuswrt it is possible to control which UPnP port are being forwarded. Under "System Log" -> "Port Forwarding" are listed all "static" port forwarding rules as well as "dynamic" (set via UPnP) ones. They are not distinguished from one another, but one can see the list and check if one seems odd.

tl;dr;
it is too early to understand exactly how the Asus router are vulnerable and which firmware release or particular configuration are vulnerable. We need to wait for more detailed information.