Date: Tue, 11 Oct 2016 17:37:08 -0400
From: kvnjs <kvnjs@...eup.net>
To: fulldisclosure@...lists.org
Subject: Re: [FD] Critical Vulnerability in Ubiquiti UniFi

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@...kovich ~ [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@...kovich ~ [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@...kovich ~ [0]$ ssh bruce@...lis
bruce@...lis'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@...lists.org] On Behalf
> Of Gregory Sloop Sent: Wednesday, 5 October 2016 1:54 AM
> To: Tim Schughart <t.schughart@...sec-networks.com>;
> fulldisclosure@...lists.org; bugtraq@...urityfocus.com;
> webappsec@...urityfocus.com Cc: Khanh Quoc. Pham
> <k.pham@...sec-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/

Powered by blists - more mailing lists