Full Disclosure mailing list archives
Re: Critical Vulnerability in Ubiquiti UniFi
From: kvnjs <kvnjs () riseup net>
Date: Tue, 11 Oct 2016 17:37:08 -0400
Tim conflates two products in his original report: Product: UniFi AP AC Lite Vendor: Ubiquiti Networks Inc. Internal reference: ? (Bug ID) Vulnerability type: Incorrect access control Vulnerable version: Unify 5.2.7 and possible other versions affected (not tested) [...] Both the UniFi appliance line and the AP management software are properly spelled 'UniFi'. https://www.ubnt.com/unifi/unifi-ap-ac-lite/ https://www.ubnt.com/download/unifi/ UniFi - the AP controller software - does not run on the UniFi AP AC Lite. It's intended as a low-cost replacement for a dedicated AP controller appliance, and it manages - does not run on - Ubiquiti's current AP product line. The current full release version of the UniFi AP controller is 5.2.9. It has a dedicated appliance in the form of the "Cloud Key" - https://www.ubnt.com/ unifi/unifi-cloud-key/ The Cloud Key is a cute little package with some integral flash, a micro SD slot, PoE or USB power, and a MediaTek MT7623 SoC - if the picture is accurate. Its sole purpose in life appears to be running the UniFi controller software. I don't have one to test; the Cloud Key may well configure MongoDB insecurely. I have access to a few other UniFi products, so I looked them over. The self- hosted UniFi controller appears to call MongoDB correctly, at least as of 5.2.9: john@malkovich ~ [0]# pgrep -a mongo 2850 bin/mongod --dbpath /usr/lib/unifi/data/db --port 27117 --logappend -- logpath logs/mongod.log --nohttpinterface --bind_ip 127.0.0.1 I also confirmed that this is the only port bound. However, installing the Debian package 'unifi' pulls in the default Debian MongoDB package, 'mongodb- server' john@malkovich ~ [0]# apt-cache depends unifi | grep mongo |Depends: mongodb-server |Depends: <mongodb-10gen> Depends: <mongodb-org-server> Unless it's disabled or configured, the mongodb-server package starts an insecure instance that binds the wildcard interface. UniFi doesn't communicate with this MongoDB instance. It may be that this packaging choice should be taken up with the distro maintainers... I don't have a UniFi AP AC Lite (UAP-AC-LITE) to test against. I was able to test UAP-AC-PROs. I can confirm that these do NOT expose MongoDB on the port number given, which is also the default MongoDB port. At time of writing, the latest firmware version is 3.7.17 - this is what the UAP-AC-PROs were running at time of testing. The UniFi-series APs do run sshd on 22/tcp, which is apparently the management interface used by the UniFi controller. It's possible for users with management credentials to get a remote shell here. john@malkovich ~ [0]$ ssh bruce@willis bruce@willis's password: BusyBox v1.11.2 (2016-07-15 14:51:44 PDT) built-in shell (ash) Enter 'help' for a list of built-in commands. BZ.v3.7.8# Port-scanning a UAP-AC-PRO takes a tediously long time, so I merely ran nmap against default TCP ports, plus 27117 and 1-1024. The only response was on 22/ tcp. I also didn't feel like expending the effort to downgrade the UAP-AC-PROs to a selection of earlier firmware releases to test whether they may have been vulnerable before Tim's report to Ubiquiti. I found no evidence that the UAP-AC-PRO runs or ever has run MongoDB. As a device with only 128MB RAM, I don't think that it was intended to. Tim's UAP model is older and was intended to be cheaper. It may well have even less RAM than the UAP-AC-PRO. The datasheet doesn't mention hardware except for radio types, Ethernet ports, power consumption etc. I hope this clears up the nature of the products being discussed, as well as the current state of some of Ubiquiti's AP products. Once again, I do not have access to the UAP-AC-LITE that Tim referred to originally, so I can only state that it's very unlikely that the AP itself was or ever has offered access to unauthenticated MongoDB sessions. It also seems possible that Tim mistook a default - OS - MongoDB instance running on a commodity server for the one started and used by the self-hosted UniFi controller app. Personally, I haven't been impressed with Ubiquiti support's response to security or other issues that I've raised via normal support channels. They do have a bug bounty program, although the amounts they offer seem to be very much on the low end of the range they quote. Still, you may get a faster, better response using that channel - https:// www.ubnt.com/support/security-rewards/about/ On Tuesday, October 4, 2016 10:10:02 PM EDT Rob Thomas wrote:
The impression I get from Tim Pham's emails is that the 'Unify Manager' is doing some behind-the-scenes tunnelling, and bringing the Mongo interface from the server to the client (Eg, Mac or Windows device) and you are then able to connect to localhost (on the client) which tunnels through to the server. However, after much searching, I am unable to locate this application. Googling insinuates that it is this (unreleased) software - https://www.ubnt.com/enterprise/software/ --Rob Thomas Information Security, Sangoma Corporation -----Original Message----- From: Fulldisclosure [mailto:fulldisclosure-bounces () seclists org] On Behalf Of Gregory Sloop Sent: Wednesday, 5 October 2016 1:54 AM To: Tim Schughart <t.schughart () prosec-networks com>; fulldisclosure () seclists org; bugtraq () securityfocus com; webappsec () securityfocus com Cc: Khanh Quoc. Pham <k.pham () prosec-networks com> Subject: Re: [FD] Critical Vulnerability in Ubiquiti UniFi I attempted private contact with Tim Pham and via email 12+ hours ago, but received no response since then. I've spent some time trying to reproduce the reported vulnerability and have had no success. It certainly doesn't help that the steps to reproduce it are so poorly described or documented. Without better documentation of the exploit, it seems impossible to determine if the report is just mis-informed, blatantly false, or if perhaps there's some step/process I don't understand or am missing. In every attempt I've made the binding of MongoBD to 127.0.0.1 is effective and non-local connection attempts are refused, as one would expect. A swift response from Prosec Networks [prosec-networks.com] would be most helpful. _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/ _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
_______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Current thread:
- Re: Critical Vulnerability in Ubiquiti UniFi Gregory Sloop (Oct 03)
- <Possible follow-ups>
- Re: Critical Vulnerability in Ubiquiti UniFi Carlos Silva (Oct 03)
- Re: Critical Vulnerability in Ubiquiti UniFi Tim Schughart (Oct 03)
- Re: Critical Vulnerability in Ubiquiti UniFi Gregory Sloop (Oct 04)
- Re: Critical Vulnerability in Ubiquiti UniFi Rob Thomas (Oct 11)
- Re: Critical Vulnerability in Ubiquiti UniFi Carlos Silva (Oct 19)
- Re: Critical Vulnerability in Ubiquiti UniFi kvnjs (Oct 19)
- Re: Critical Vulnerability in Ubiquiti UniFi Tim Schughart (Oct 03)