Symmetric encryption with a default key on Ubiquiti’s UniFi network devices combined with remotely-hosted UniFi Controllers leads to risk of undetectable observation of network configuration and usage data.

Overview of UniFi’s “inform” protocol

Ubiquiti’s UniFi product line consists of routers, switches, and WiFi access points.

These devices do not have any local management, instead relying on controller software¹ running locally or hosted remotely.

Devices discover their controller² through a combination of broadcast traffic on the local network, DHCP option 43, and trying to resolve the hostname unifi. In the case of option 43 or resolution of the unifi hostname, the device will attempt to communicate with the controller by sending a HTTP POST request to [ADDR]:8080/inform.

This POST request contains a JSON payload³ and is repeated every 30 seconds. Controllers respond with a JSON payload containing configuration data, commands, or instructions to check in at a later time.

Improper use of encryption

When sending JSON-encoded data to an API endpoint, one might expect to see a MIME type of application/json combined with HTTP over TLS. This is not the case.

Instead, the JSON payload is encrypted with AES in GCM or CBC mode depending on the combination of device and firmware version, wrapped with a bespoke binary protocol⁴ and transferred without benefit of TLS⁵.

The encryption key used prior to adoption by a controller is the md5sum of ubnt⁶.

During the adoption process, the controller generates a new key and sends it to the device as a inform response along with any other initial configuration data. Consequently, anyone observing network traffic during the adoption process can observe any future traffic between the device and controller.

Operators have been questioning⁷ Ubiquiti’s decision to not utilize TLS by default for several years. Eventually Ubiquiti removed⁸ the ability for operators to force usage of TLS for inform traffic.

Contents of inform traffic

Network configuration data by itself can be considered sensitive but does not directly impact user privacy. Unfortunately, inform traffic also contains data that can identify specific devices in place and time. With a UniFi router, it can associate browsing activity with a device’s mac and IP addresses.

Switches

Switch tables contain MAC addresses of user devices and can be used to associate a user with a location.

See: example inform from a USW-PRO-24 running firmware 4.0.64.10823.

WiFi Access Points

MAC addresses of users, data on neighboring WiFi AP signal strength provides sufficient information to geolocate the AP⁹ using commonly available services.

See: example inform from a UAP Flex HD running firmware 4.0.42.10433.

Routers (UniFi Security Gateway)

Router inform contains DPI, DHCP, and ARP tables that can be used to associate a device with usage of specific applications such as Facebook and Spotify.

Exerpt showing DPI update for a host (app and cat correspond to application and category identifiers used in the controller dashboard):

{
     "initialized": 1603949546,
     "ip": "10.0.2.9",
     "mac": "24:5e:be:XX:XX:XX",
     "stats": [
          {
          "app": 106,
          "cat": 18,
          "rxBytes": 48032,
          "rxPackets": 632,
          "txBytes": 48184,
          "txPackets": 634
          }
     ]
}

Why you should care

Reliance on symmetric encryption means that anyone that possesses the key can observe inform traffic. This traffic contains information that, if disclosed, could have an adverse effect on users of the network.

Surveillance and targeting

An aid worker installs a UniFi switch in a refugee camp. They use a UniFi controller hosted in a cloud VM for remote monitoring and management. It’s easy for an adversary to monitor¹⁰ these internet connection. The adversary gathers end-user device MAC addresses¹¹ from the switch table data contained in the inform message. How parties to a conflict could use such data is left as an exercise for the reader.

Location discovery via passive observation or DNS hijacking

Someone acquires a UniFi WiFi access point (AP) and installs it on their home network. They didn’t realize that a controller was required and order a UniFi cloud key controller, but did not unplug the AP while waiting for the controller to arrive.

Their internet provider uses wildcard DNS monetization¹² to show ads on domain names that do not exist. This leads to the unifi hostname resolving to the monetization provider’s server. Because of privacy regulations the ISP is prohibited from giving detailed information (such as physical location) to the ad provider, so the ad provider is incentivized to find ways to geolocate clients to deliver more targeted ads.

The neighboring networks / interference avoidance data included in the AP’s inform message contains sufficient information to utilize WiFi-based geolocation to associate the IP address with a physical address.

Proof of Concept

To demonstrate the feasibility of information extraction, I built a tool to automate information extraction from Unifi inform packets: pixiedust.

In key extraction mode, pixiedust follows inform traffic and learns keys as devices are provisioned or reconfigured.

$ ./pixiedust -in ../nanofi/sample_data/network-management-sequence.pcap 2>&1|grep discovered
I1120 02:13:39.632406  140512 extraction.go:59] discovered key: 0c1e5dd98abec05fa8b223792091bc90 for 192.168.1.54
I1120 02:13:39.633297  140512 extraction.go:59] discovered key: bcb39fa2baf992e6a989c6814a113ae1 for 192.168.1.69
I1120 02:13:39.635754  140512 extraction.go:59] discovered key: 165c32ce45ef3b9d16ed3d4762252040 for 192.168.1.61
I1120 02:13:39.652861  140512 extraction.go:59] discovered key: 39552006690888176a13de7787149960 for 192.168.1.96

In geolocation mode, pixiedust extracts site survey data from WiFi AP inform messages and uses Google’s WiFi Geolocation API¹³ to determine where APs are physically located:

$ ./pixiedust -in locinform.pcap -locate -message=false
Device E063DA85AAC5 at 37.533223,-121.998402 (32.000000)
Device E063DA85AAC5 at 37.533154,-121.998379 (122.000000)
Device E063DA85AAC5 at 37.532886,-121.997456 (164.000000)
Device E063DA85AAC5 at 37.532843,-121.997286 (175.000000)

Mitigation

Short-term

Operators should ensure that traffic between UniFi devices and controllers is protected by a site-to-site VPN when traversing untrusted networks.

Long-term

Use TLS. Even self-signed certificates are better than the current state because you can log certificate IDs to detect MITM.

Inform messages should contain the minimum information necessary for adoption until after the device has been paired with a controller to prevent inadvertent disclosure of network configuration and personally identifiable information.

Affected devices

All UniFi devices to date are affected, except for the UniFi Dream Machine (UDM) product line (including UDM Pro). The UDM series are not affected because they run a local instance of the controller software and cannot use a remotely hosted controller, so there is no opportunity for an attacker to eavesdrop on UDM🡘controller communication.

Timeline

• May 2020: start exploring feasability of creating my own UniFi controller (unixy, with configs in json on filesystem)
• June 15th, 2020: first working version of pixiedust.
• June 17th, 2020: Report via email to security@ui.com.
  1. Autoresponse that request was recieved
  2. Response from human asking me to use their HackerOne
  3. I respond that I can’t use their HackerOne because of the odious terms they’ve added their HackerOne program.
• I get busy with life
• November 9th, 2020: conversation with friend reminds me to finish this.
• November 18th, 2020: Request CVE from MITRE, recieved CVE-2020-28936.
• November 20th, 2020: Publish.