Hacker News Reader

Comment by myrandomcomment | Hacker News Reader

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."

View on HN

I just did this for a controller that is hosted on a VM (via the new controller UI), I went through a couple of additional steps.

1. Disable "Enable Remote Access"

2. Setup SMTP (since disabling remote access stops routing emails through Ubiquiti's backend)

3. Create a new admin not tied to a cloud Ubiquiti account (via "Administrators")

4. Disable "Sync Local Admin with Ubiquiti SSO" (the older UI says "Enable Local Login with UBNT Account")

5. Delete the old admin account

Steps 3 and 5 may not really be necessary, but I did to be safe.

Just verifying my understanding: this will make it impossible to reach the device from ui.com or otherwise off-network, but an attacker could:

1. use leaked SSO keys to forge an SSO token

2. craft a malicious webpage

3. get an unsuspecting UDMP user (e.g., me) to navigate to that page

4. run scripts on that page that would access & interact with the UDMP from the browser within the network, using the forged SSO

Is this still a possible vector? Presumably UI would have rotated their SSO keys by now, but since there's no way to disable SSO-based login to the UDMP....

So SSO is disabled here. You just use a local account. IE, I go to https://192.168.27.1 to get to my UDMP and the account to auth is locally stored.

Hmm, I followed your steps and my ui.com account can still log into the device.

I have also created a local account, that I can use to log in alongside my ui.com one, but I cannot disable my ui.com SSO from being able to sign into the device.

Let's make sure we are talking about the same thing.

You have local and SSO account.

You disable remote access in your local cloud key.

You open the local IP for the CK and are able to sign in using the SSO account is what you are saying, so auth token is coming from remote.

Question if I got this correct, can you go to the ui.com portal, the UI cloud based one in a web browser do you see the controller still? Can you login and still manage it through the remote web portal? This is what turning off remote access does. You should not be able to manage the system remotely.

Disabling remote access is for the remote web base ui site portal and that should not work after you disable remote access (my understanding). It is possible that you can connect to the local controller and use SSO to authorize vs web and be passed a valid token to login however that would be local only and not remote. Ie the hacker would have to have your SSO AND be on your local network.

Have you tired / are you able to delete the SSO account in the local CK? I have not tried but will later.

Hope that makes sense.

The difference is that the attack you suggest has to be targeted

Reply on news.ycombinator.com