Hacking Unifi Controller Passwords for Fun and WIFI

Kent Ickler //

Because, you know—that should be a thing. 


Don’t run the Unifi Controller on a laptop in the closet.   


Ubiquiti’s Unifi controller is a network device, or software service, that controls Ubiquiti’s Unifi line of devices.  Unifi is a brand of devices that, well, unify together to make a better user experience for network users and system admins in the SMB arena.  We’ll leave that up to your own opinion, but we’ve used the devices and they work alright.   


I’m not here to comment on the controller’s software design from a security perspective.  Ubiquiti pays security experts to do that.  That’s not me or BHIS.  And that’s OK. 

 What I will tell you is this: 

A compromised Unifi Controller host is a compromised Unifi network. 


Unifi cloud-enabled devices got popped awhile back.  Thought I should mention it.   


Enough of that. 


The local Unifi Cloud Controller can be installed on a Linux or Windows system if you didn’t want to buy their “Cloud Key” hardware controller (https://store.ui.com/products/unifi-cloudkey).  It’s awesome that they provide a downloadable controller to Unifi equipment owners.  This allows for a centralized install and administration of local Unifi devices without having to purchase an additional piece of software or hardware. 

Download link: https://www.ui.com/download/unifi/ 

In fact, it’s so awesome and versatile, it’s like they want us to install it on an old random laptop that we don’t actively use and will completely forget is running. 


The back-end database for the controller is running a MongoDB database.  While the database server only listens to the loopback address of the host it is installed on, it doesn’t require authentication.   

Again, I’m not commenting on that. 


Those in infosec know that loopback addresses are only as secure as the system that operates them.  In the grand scheme of things, if the host running the controller is compromised, it would be trivial to get remote access to the Unifi Controller using the loopback address without having remote desktop or console access.  For demonstration purposes, I’m jumping straight to the host via RDP to snag some easy screenshots.   


I’d normally use DBeaver (https://dbeaver.io/) for this type of thing.  A while back, DBeaver removed their No-SQL and MongoDB drivers from the Community Version.  Bummer.   

NOSQLBooster (https://nosqlbooster.com/) is a stand-in replacement that works great.   

After starting NOSQLBooster, you’ll need to connect to the local database.   


No MongoDB here. 

Even without Drake, this loopback obfuscated port wouldn’t have been hard to find with some cmd-fu.  

But… Ubiquiti was kind enough to fully document it too: https://help.ui.com/hc/en-us/articles/218506997-UniFi-Ports-Used 


In NOSQLBooster, click on “Connect” followed by “Create.”  Enter the details: 

Type: Single Server 

Server: localhost 

Port: 27117 

Name: Unifi     

Next, press “Save and Connect.” 

The database structure will open on the left side of the application. 


Let’s drill down to Unifi ace admin.   

Double click “admin” to open the associated records.   

Notice the x_shadow key?  It looks awfully like a hashed password.  

Spoiler: It is. 

Let’s snag that key and do some magic. 


Dance to this and you’re gonna get thinner. 


Let’s dissect that hash.  By analyzing the hash with the modular-crypt-format (https://passlib.readthedocs.io/en/stable/modular_crypt_format.html), we can identify its individual parts.  That syntax for this type of hash: $id$salt$encrypted 

  • First, the id, $6$, tells us we are looking at some sort of variation of SHA512-crypt. 
  • The text between the $6$ and the next $ is the hash salt (KPCNpIC/).  There are some amusing bits about that salt we’ll discuss later.   
  • After the salt and $ is the cryptographic hash of the password+salt (GzO92iNqVVQNN8cQonvDQumnwmYOnUzvC6WvGLLMcysBfporCeVt7UYgGKPnkxp8B/e0Ckp.57Q8UiWw32sM60). 


Notably, this is a common hash type in Linux shadow files.  Cleverly, we found the hash in a key named x_shadow.   

Those of you that know Linux already identified the hash as a salted sha512crypt hash. 

Hashcat nerds (like me) already know that this is mode 1800.  


Get on with it.  

First, we throw that hash into a file named “hash” and then start up Hashcat.  Hashcat will attempt to find a hash collision and, if it does, will output the collision in a file named “pot.”  We use the -m flag with Hashcat to specify the hash type and the -a flag to specify our attack mode—in this case, a direct dictionary attack. 

# echo $6$KPCNpIC/$GzO92iNqVVQNN8cQonvDQumnwmYOnUzvC6WvGLLMcysBfporCeVt7UYgGKPnkxp8B/e0Ckp.57Q8UiWw32sM60 > hash 

# hashcat -m 1800 -a 3 hash wordlist -o pot 

That’s a hit.  You sunk my controller-ship.  Let’s grab the collision from the potentials file. 

# cat pot 


The password is Fall2021!   


You can now login to the Unifi Controller at https://localhost:8443/ with the username specified in the ace admin key “name” with the cracked password.  In our case, Fall2021! It’s haxed. 

Mi Hash, Su Hash 

Let’s talk about salts and hash. 

To have a little fun with this (and to prove a point about non-filtered salts), let’s create our own hash.   

We will use openssl to generate a SHA512-crypt hash.  However, we will use our own custom salt—a salt that Unifi should know it never used to store an actual user account credential. 

# openssl passwd -6 -salt BHISWASHERE Fall2021!


To “reset” that Unifi Controller admin password, we need only overwrite the x_shadow key in the ace>admin table with our new hash:  


The login password will then be a very secure, Fall2021!   

The salt isn’t filtered, and it will work to login to the controller. 


So, the salt doesn’t matter.  It’s not filtered.  Big deal. 

Sorry, Padme.   

Imagine a runtime computed salt that is a derivative of an account attribute (like creation timestamp) plus device GUID that never gets stored, but rather, only re-computed at authentication.   

At authentication time, the user submits a password which is then added to the runtime-computed salt—that is, a derivative of the user’s account creation time plus the device GUID.  Since the salt would never be stored, a hacker would “never” be able to correctly produce and inject an external hash into the authentication database. 

But I’m an idealist. 


Well, aside from interesting things like the “payment” table where you find payment details for the Hot Spot Unifi service, there are other tidbits that might wet your whistle too. 

The “devices” table has all you wanted to know about how the controller talks to the devices, including authentication. 

The “alert” table will have network metadata alerts.  You could watch as users walk around a building. 

In the “users” table, you will find meta-data for every network device that the controller tracks data for (basically anything any controlled Unifi device sees in its network broadcast). 

In the “settings” table, you’ll find other juicy tidbits, including the authentication and API information to Unifi’s Cloud Controller service. 

Bottom line: Every setting in the controller can be enumerated.   

SMTP configurations, SYSLOG, SNMP, etc.  If it’s a stored credential in the controller, you now own it.   

Cough… IPSEC & VPNs… cough. 


If logging into the dashboard wasn’t your thing, you can always just pull the wireless pre-shared keys directly out of the database without logging into the controller interface. 

If you look in the “wlanconf” table, you’ll find treats like “name” and “x_passphrase” that are the plaintext SSID and pre-shared key respectively.  Remember, this is accessible even if the controller device itself cannot “see” the wireless network.  

Let’s be honest: if you’ve gotten this far, spaghetti and plaintext pre-shared keys are the least of your concerns. 


Frankly, this all started because I forgot my admin password on my local controller at home.   


Red Teamers: Check for a Unifi Controller on your target endpoints.  It may make an easy win. 


Is the Software Unifi Controller insecure 

No.  I mean, yes.  Maybe. 

If the host that runs the Unifi Controller becomes compromised, the network is compromised.  Any external service that was configured in the controller, and potentially a linked Unifi Cloud account, should be considered compromised, and keys changed. 

But then again, the host that runs this software should probably be better known as the “Unifi Controller” and protected as though it’s the “Unifi Controller.”  Don’t use a random laptop thrown in the back of a closet because you didn’t want to buy the Cloud Key hardware controller.   

By the way, “compromise” doesn’t mean SYSTEM context here.  Remember, MongoDB is running without authentication.  You only need local loopback privilege (even remotely) to modify the database.    

Could it be more secure?  

Yes, definitely.   

But remember how the pendulum swings both ways; another extreme: 

All the sensitive bits could be protected with PKI infrastructure controlled by Ubiquiti.  That would be better, right?   


Isn’t SHA512cyrpt broken anyway?   

Ehh, sure, here’s some math: https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/ 

Did I contact Ubiquity?   

No.  This is by their design.  I’m not even mad. 

As a systems administrator, I acknowledge this behavior would be consistent with other manufacturer network controllers not installed on Windows.  For example: a console cable can give you root privileges on a switch with nothing more than physical access—but you have that switch locked in a secure facility.  

This only appears bad because of the perception that it’s OK to install the software on any Windows host, including a personal-use laptop.  The network controller here leverages the security of the host itself.   

When you install this software, the device becomes a network controller, and you need to secure it like one. 

Don’t install network controller software on vulnerable devices.   

The only thing I’d say more is that the ease of install may have trivialized the security considerations of operating the controller—or at least the considerations used in the decision to install on a specific device. 

These products really do “just work” and consequently, it becomes easy to forget the security implications of how they “just work.” 

Can you automate Unifi stuff 

Yes, but this guy did it first:  https://github.com/MichaelMcCool/Unifi 


Did you know that after your Unifi devices are configured, they never need to talk to the controller?  Just turn off the service after your devices are configured.  The configuration on the devices will survive reboots and your mesh “shouldn’t” be impacted. 

If a few years later you turn on the controller and find you’ve forgotten the password, you’ll find this blog post and can just change it hacker-style. 


Real friends don’t let kids play Roblox on network controllers. 


Want to learn more mad skills from the person who wrote this blog?

Check out this class from Kent and Jordan:

Defending the Enterprise

Available live/virtual and on-demand!