Whistleblower: Ubiquiti Breach “Catastrophic”

It may sound strange, but for Mikrotik, I find it more productive to concentrate on setting them up via CLI. It's certainly more trainable.

CLI for Port Forward: /ip firewall nat add chain=dstnat dst-port=1234 in-interface=ether1-gateway action=dst-nat protocol=tcp to-address=192.168.1.1 to-port=1234

VS having to document the same task in the GUI:

IP->Firewall->Nat-> Add New

General Tab Chain: dstnat Protocol: TPC Dst. Port: Port In. Interface: ether1-gateway

Action Tab Action: dst-nat To Address: IP address of Server To Port: Port # of Service

We should be clear here that there are multiple types of "self-hosted". Ubiquiti makes essentially little (weaker) Raspberry Pi devices with PoE that are dedicated to just the controller, and a few years back they also forced their (garbage) "Protect" onto their hardware only. They (confusingly) call these "Cloud Keys", though they have nothing to do with the cloud. However, you can also get 100% standalone versions of the Controller that will run on any server or VM you've got, Linux, Windows, or Mac. This is just the Java 8-based controller software and that's it, and you can lock those down arbitrarily hard for any WAN access same as any other LAN network software, no general internet access is needed at all and no firmware is involved.

A lot of people quite reasonably got CKs seeing them as very easy ways to have a low power always on local controller since they didn't have some other server running 24/7 already. If the firmware on those was updated to require tie-in to Ubiquiti's SSO that's a horrible betrayal. But I'm confident in saying the full standalone Controller doesn't since I have mine locked down from any general net access, remote L3 management was done to IP only at the firewall and I've been switching to just putting it all through WireGuard.

You are required to have internet access to setup something like the UDM-Pro. After it is setup you can create a local admin account and disable remote access.

Here is how:

1. Login with your online account credentials and password 2. Choose system settings 3. Choose advanced 4. Disable Remote Access 5. Confirm that "Transfer owner" won't be available if you disable remote access.

The issue in general is that the UniFi stuff can be crappy and buggy, but it SUCKS LESS then any other complete solution for a home / small enterprise there at the price point.

I personally used to given them a strong recommendation and even now that is a recommendation with some footnotes. They have been growing to fast and the SW quality has gone down. Being on the latest release is not always the best idea.

To be fair in my I have had many conversation with Cisco that started with "no, not the latest GA, but what is the latest proven STABLE GA."

It is interesting to do a search of HN for past references to "Ubiquiti". Whenever the topic of routers came up, many comments followed that recommended them above any alternatives. Commenters seemed proud to tell the world they were using Ubiquiti, as if the "HN concensus" for home routers was to choose Ubiquiti.

It seemed to me Ubiquiti would never allow customers the option to install their own OS (e.g., BSD) or boot from external media containing a non-Ubiquiti OS, without sacrificing the benefits of hardware specs that were likely deciding factors in selecting the Ubiquiti hardware above existing alternatives. The intent was clearly to have Ubiquiti retain control over the hardware after purchase. The customer effectively remained tied to Ubiquiti forever, so if the company started serving ads, using AWS unnecessarily, etc., there's no way to opt out. Customer is compelled to accept all updates.

Specs are important, but maybe not as important as control.

Reliance on third parties necessarily increases potential risk. Unnecessary use of third parties is, IMO, poor decision-making. This is of course rampant in "tech" and, IMO, marks a triumph of the salesforce for those third parties over common sense, possibly assisted by network effects. Further, I dislike products where there is a heavy focus on opaque "updates". Again, many customers have been trained to believe that not updating is always the wrong decision. (Meanwhile they have no idea what is in each update.)

As stated in one of the blog post comments:

"It is even worse: Ubiquiti forced all users to use cloud-based authentification even for accessing your controller software on a local network with a local client. This was not even properly communicated but deployed by one of the regular maintenance updates."

They seem to have gained access through getting secrets from developers as far as I understood it.

So with 2FA they would have had a much harder time to gain access to the database.

The part of changing the seed only matters for customers of the hacked company but is (as far as I can tell) unrelated to them gaining access.