1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

UPnP flaw draws concern

Discussion in 'Tomato Firmware' started by i1135t, Jan 29, 2013.

  1. i1135t

    i1135t Network Guru Member

  2. koitsu

    koitsu Network Guru Member

    The actual white paper (which contains all the technical details, source code, etc.) in PDF format is available here:


    This document covers a *lot* of problems, and that makes it very hard for any end-user to follow. I finished reading the document -- yes, in full -- and I'm aware of what the complaints are. I'll summarise them:

    1. A couple of the complaints relate to routers or devices which have their UPnP daemons listening on the WAN IP and a firewall stack which is permitting inbound traffic on the WAN to UDP port 1900, as well as an arbitrary TCP port number (pertains to HTTP POST SOAP requests via UPnP).

    This issue is purely the fault of bad firewall rules. Present-day TomatoUSB does not suffer from this problem. I've verified myself using a combination of iptables, lsof, and some general knowledge/familiarity with UPnP.

    2. The other complaints relate to software design flaws/bugs in many UPnP implementations (and they are indeed real/true bugs). The only one that concerns TomatoUSB is MiniUPnP, which is the software used for the UPnP service/capability on present-day TomatoUSB.

    These security issues were fixed in MiniUPnP 1.4(released in December 2009), and some fixed in 1.1 (released April 2008).

    Present-day TomatoUSB uses MiniUPnP 1.6, which as of this writing is not known to have any issues.

    3. The article also complains that the MiniUPnP version string is returned in the SSDP response -- this is true/correct, and still applies today. That response string (using tomato-K26USB-1.28.0501.2MIPSR2Toastman-RT-N-Ext.trx):

    Server: UPnP/Tomato 1.28.0501 MIPSR2Toastman-RT-N K26 USB Ext UPnP/1.0 MiniUPnPd/1.6
    However, there's really no problem with disclosing this string/version. In fact, the article author implies the version string has some implications, but it doesn't. It does, however, provide an easy way for an attacker who can circumvent issue #1 listed above (which TomatoUSB, as I said, is not susceptible to) to determine what version of the software you're using.

    So, with regards to present-day TomatoUSB, I do not think there is any part of this disclosure we need to worry about.

    Those who released the white paper also compiled a list of devices which were found vulnerable. Here's that list:


    Folks using original Tomato (as in the true original, not a fork) may be affected however -- I don't remember what MiniUPnP version is used in stock/vanilla Tomato. However, regardless of what version is used in original Tomato, UPnP SSDP is still not accessible via the WAN due to proper firewall rule configuration. :)
    Azuse, charlitis, occamsrazor and 3 others like this.
  3. free2share

    free2share Networkin' Nut Member

    Koitsu, thanks for taking time to investigate and share your findings with the community. Its reassuring to have people in this community like yourself.
  4. Mangix

    Mangix Networkin' Nut Member

    The UPnP issue may be more of an issue with older equipment honestly. I used the ScanNow utility that Rapid7 provided to scan four different routers running tomato, dd-wrt, netgear stock firmware(wndr3400v2), and an att u-verse gateway. All showed negative for exploitability. Then again, dd-wrt does not use miniupnpd and the alternate implementation may have other 0day bugs.

    I'm curious to know which pieces of SOHO equipment this actually affects.

    edit: ironically, the ScanNow utility requires Java, the current version of which has known unfixed vulnerabilities.
  5. PGalati

    PGalati Network Guru Member

    The report claims that 81 million devices are listening to UDP port 1900 on the WAN port.

    Steve Gibson's grc.com now has a upnp test added to his shields up test and does not require java.
  6. Toastman

    Toastman Super Moderator Staff Member Member

    steve gibson again !

    StarClout likes this.
  7. heirloom

    heirloom Serious Server Member

    Hi. If you have a moment can you please look at this thread?


    I think I've discovered a vulnerability in shibby-tomato-k26usb-1-28-rt-mipsr2-105-1-aio-trx that exposes MiniUPnP to the internet. It certainly has exposed SSH and Telnet. I know because my log shows script kiddies trying to log into my VPN gateway from the internet. My confidence in making a definitive statement is low because this is only the fourth day I've been playing with tomato and iptables. It may be that I have chosen configuration options that put my set-up at risk but I'm too ignorant to know what that might be. Any help appreciated.
  8. koitsu

    koitsu Network Guru Member

    1. You've changed settings/messed about with things in a fairly unique way. This is not an out-of-the-box configuration; you introduced this problem yourself,
    2. The problem you're talking about is not specific to UPnP as you've admitted, thus has no relevancy to this thread.

    Other people interested in helping you with iptables (not ipchains -- you said ipchains repeatedly in your other post) and the difference between the nat table and the filter table, and how to configure a VPN, etc., should comment / assist in that thread, not this one. I do not assist with complex networking configurations like what you've posted in that thread, sorry.
  9. heirloom

    heirloom Serious Server Member

    I know you probably get a pile of queries from newbies like myself so thank you for taking the time to look at my post. It was a very kind gesture. Given that you think this is not an out of the box configuration leads me to believe that there is a real problem with 105.1-AIO. There is a very small thread of programming logic from the user interface configuration of /bin/nvram get pptp_client_dfltroute to setting /usr/sbin/iptables --insert INPUT --source $REMOTESUB/$REMOTENET --destination --jump ACCEPT --in-interface $1. It is out of the box behavior for the 105.1-AIO image. Maybe you are referring to the Toastman code on which parts of this release were built when you said "out of the box"? I can compare this version to something you consider a good reference.
    I spent a few minutes today adding a custom PPTP configuration to specifically remove that INPUT filter rule. No nat rules were harmed in the making of the changes. Before the change everything was exposed to the internet through the VPN including Telnet, SSH, ICMP echo, and UPnP: hence the reason for posting in this thread. Given your reaction I assume that exposing UPnP to the internet is a big deal and anything that does is messed about.
  10. koitsu

    koitsu Network Guru Member

    By "not out of the box" I'm referring to this:

    1. You have multiple networks involved specifically two reserved networks ( and
    2. Multiple layers of NAT (your WAN interface uses, your LAN interfaces use; LAN gets NAT'd across the WAN, which then gets NAT'd again by use of another router or device provided by your ISP),
    3. You also involve a VPN (PPTP) into the mix of the above mess.

    I should have used the term "uncommon/complex configuration", not "out of the box".

    The main stuff I help with are simple setups, as in "I use my router to provide network access to a couple devices in my home" (i.e. no VPNs, no multiple networks) -- this is what I consider an "out of the box" configuration.

    There are folks here that linger that are much more familiar with complex networking environments when used by these routers, but I am not one of them. While I understand IP and VPNs (especially PPTP) without any issue, the Tomato/TomatoUSB routers are significantly different than medium and enterprise business equipment that I'm used to dealing with (Juniper M320 routers, Cisco or HP switches, Juniper NetScreens for VPNs, etc.) -- the interface complexities (br0 vs. ethX vs. vlanX), as you've discovered in the other thread, make things quite annoying to deal with compared to a more elegant/clean environment. Anyway, my point is that it's not a common configuration so I don't assist with those situations -- I let others help. Sorry.

    The few Tomato-based routers which did show up in the spreadsheet mentioned in my above post are definitely people involved with "complex configurations" similar to yours. You're responsible for your own security in that case, because the default security out of the box with Tomato is correct/functional. When you start adding VPNs and multiple networks and other whatnots into the picture, that security model can be lost, as you found. As I said over at DSLR/BBR: "The more people screw around and make a mess (in effect avoid KISS principle), the more likely they're exposed." Bottom line: Tomato/TomatoUSB, out-of-the-box running with simple setups and nothing complex, is not vulnerable.

Share This Page