Umbrel security is absolutely lacking, fixing this should be priority #1

[Unsettledroell]

The security that is offered by Umbrel is absolutely insufficient.

There is one, big, glaring security hole that is just sitting right there, allowing anyone that somehow makes it onto your network (a guest with the wifi password, an old laptop that is compromised) to simply steal all your onchain and offchain funds without any problem. And that is the default app passwords.

I just realized this. And a lot of people know it already. If you installed Lightning Labs or Thunderhub or anything like that, the only thing you need to do to access all funds is to

• Get onto the network of an umbrel user OR steal someones raspberry pi, plug it in at home
• figure out the IP of the Umbrel
• Go to ports 3000,3001,3002... etc. to find an app that is running
• Log in with MoneyPrinterGoBrrr
• Do a loop out, or pay some invoices, whatever.

It is so obvious that many Umbrel users have these apps installed, with default passwords, with funds at stake, and fixing this issue WILL eventually save some of the users from catastrophic loss of funds.

Assuming the home network is safe is really, really stupid. Because it never is.

So the fix is also obvious;

• change the default passwords to something you can set yourself (you can change it for some apps over ssh but not all of them)
• (or) force the users to login to Umbrel first before being able to open any apps
• (or) generate a random standard password shared by all apps that is based on the seed

Another very important addition that should be added in my opinion is an option to do 2FA for logging into Umbrel and all apps.

I have read the readme. And yes, I know that Umbrel is under development and you 'should no be reckless'. But THIS is reckless and should be fixed, priority number one, before adding any new apps or features. A lot of users are reckless with their money, and steps should be taken to protect them, too.

[lukechilds]

Hey thanks for taking the time to write up your thoughts. Have you read through SECURITY.md? We explain the current security tradeoffs in there and how we plan to resolve them (including the ones you raised).

I agree with your general points, I also agree 2FA would be a great addition to the login process, something we definitely plan to implement. However the solution is not quite as simple as you suggest.

Removing hardcoded passwords in favour of secure passwords does not provide much additional security if the assumption is that the network is untrusted. All local communication happens in plaintext, therefore if there is someone malicious on the network, they can simply sniff the secure passwords and then proceed to login to the services.

Encrypted communication over a local network that isn't vulnerable to an initial MITM attack is pretty much an unsolved problem in networking. We have some ideas on how we can solve this but it isn't trivial to implement and isn't something we're focused on while Umbrel is in beta. It is something we will resolve before a stable release.

Here's some issues/PRs with prior discussion on the topic:

• https://github.com/getumbrel/umbrel-os/pull/53
• https://github.com/getumbrel/umbrel/issues/190

In regards to your proposed solutions:

So the fix is also obvious;

• change the default passwords to something you can set yourself (you can change it for some apps over ssh but not all of them)
• (or) force the users to login to Umbrel first before being able to open any apps
• (or) generate a random standard password shared by all apps that is based on the seed

Your second proposal is exactly how we see this working. See the section titled "Hardcoded app passwords" in SECURITY.md for more details on that. Although it won't provide much security on local networks until we also have encrypted local communication working as discussed above.

[Unsettledroell]

Thank you for the writeup. As I understand form the material you added here, the issue is that local communications is unencrypted, because it is hard to avoid a MITM attack during the setup phase of the Umbrel?

I'm not really literate there, so I am not sure if I got that anyway. But I don't understand the reasoning.

The encryption helps against some type of attacks, but not against all of them, so we don't encrypt at all for the moment?

What is the chance of an IOT device acting as a MITM to attack your Umbrel, vs stealing the password because it is sent over cleartext over the network?

Also, you now only need the hidden tor address to access someones funds, if they have e.g. LightningLabs installed. This seems like another issue easily solved by being able to set a non-standard password.

[lukechilds]

The encryption helps against some type of attacks, but not against all of them, so we don't encrypt at all for the moment?

It's not just that, but also adding SSL on a local network itself isn't simple, the UX is really bad and borderline dangerous. There's no trusted certificate authority that can vouch for the local domain so there's no way to know which certs are valid. That not only allows MITM attacks but also means all browsers will reject the self signed certificates that Umbrel and all apps use with a scary error. Different browsers and OSs have different ways of whitelisting certificates, some aren't too complicated, some are very complicated.

It would be a UX nightmare to try and effectively communicate all the possible way to whitelist certificates to non-technical users. It would also be incredibly risky to tell them it's ok to ignore the SSL error and allow it when that's exactly the same error they'll be faced with in the future if an attacker was serving up a bad cert. Some platforms even require a root cert to be added to the OS to accept self signed certs in browsers, which is really dangerous to encourage non-technical people to go playing around with.

So to summarise, implementing SSL today would:

• Introduce a significant degradation in UX.
• Normalise dangerous behaviour to non-technical users.
• Still wouldn't allow for secure communication over an untrusted network.

So for those reasons combined we deemed it not a good solution.

Also, you now only need the hidden tor address to access someones funds, if they have e.g. LightningLabs installed. This seems like another issue easily solved by being able to set a non-standard password.

Yep, you're absolutely right here. While secure passwords won't significantly increase the security of local access, they would be a great second line of defense for services accessed over Tor. Our SSO auth server is higher priority to implement than secure local access for that reason.

It's worth noting that the Tor hidden service address provides 256 bits of entropy, so essentially knowledge of the hidden service itself acts as a cryptographically secure access token. If you don't share your hidden service address with someone, no one can access it. Of course it's not ideal to rely on that, hidden service addresses can be accidentally leaked by users in screenshots or other ways so adding the Umbrel authentication in front of apps would be a great second line of defense here.

I can't promise exactly when that will be implemented, it's not an immediate priority, but it is reasonably high on our list.

[AaronDewes]

Just for an implementation proposal for the future:

The best (for users) way to do this would probably be a custom SD flashing util which creates a trusted SSL certificate and also puts that onto the SD.

[silverfisk]

TLS might be solveable with a wild card certificate, like *.my.getumbrel.com that is hard coded on the os image but not considered secret.

Then take each ip address of the private address spaces and register its base64 encoded string as [base64 of IP].my.getumbrel.com and resolve as the private ip.

During installation you change hostname from umbrel to the base64 string and let port 80 redirect permanently to the https://b64.my.getumbrel.com and instruct the user to bookmark this.

The umbrel.loclal should resolve until the DHCP lease is out I think, so there should be enough time to redirect the user.

[lukechilds]

@silverfisk it's a cool idea!

However if I understand your proposal correctly there are three problems:

• The bookmark will break if the devices local IP changes.
• The SSL private key is publicly known so an attacker can MITM and decrypt connections that will deceptively show up with a green padlock in the users browser as if everything is ok.
• Even without a MITM attack, just eavesdropping on the network would allow an attacker to decrypt the encrypted traffic since they have knowledge of the Umbrel SSL private key and so can passively participate in the Diffie–Hellman key exchange protocol to derive the decryption key.

[BenGWeeks]

Proposal 1: A warning at the top of the screen if the user is accessing over HTTP rather than HTTPS, and instructions on how to access the site over HTTPS (How to enable SSL Certificate Error Overrides and How to create your own self-signed certificate). It should give instructions to resolve "ERR_CONNECTION_REFUSED" when trying to access via HTTPS (ref: #726).

Proposal 2: Prompt users to change default passwords at the first opportunity (if not during the installation process so that default passwords are not used at all).

And continue working on SSO :-) What good is SSO without communicating with the device over SSL as outlined above though for the reasons of bad actors potentially sniffing traffic on the local network?!

[plebos]

Well, if you want to avoid the SSL warning, you can still generate a certificate in the installation phase and make your client side code communicate the password encrypted to the server side (without the help of the browser).

[BenGWeeks]

@talshmuely Do you have the instructions for that so no CONNECTION_REFUSED error?

[waps11]

I'm a little late to the party but here's my 2 cents on the TLS subject:

In all cases mitigating MITM attacks implies enabling somehow prior trust between devices and this translate to additional configurations steps before connection to any network.

Users that want TLS on an isolated local subnet (behind a NAT or even air-gapped) need to be minimally technical and able to do some work in a DIY fashion. For them a couple of solutions should be on the table.

1. As users are already requires to write the umbrel image to a SD card prior to booting the rpi4, there could be additional steps done by the users on the sd-card before the server is ready to boot. There could be a directory on the sd-card where user could drop needed files (CA, cert+key and chain bundle) to enable TLS. Upon boot, a script could pick them up, validate them and enable TLS if everything checks out.
2. A self-sign certificate could be generated upon initial boot and the fingerprint displayed on the local RPI console with a warning to the user. By retrieving the fingerprint from the console and comparing it to the certificate offered on initial connection, a user could add a security exception in their browser with a certain level of trust. This scenario should not be acceptable nor propose to non-technical folks as it implies that a security decision be made by them to analyze the content of a certificate and adding it to a whitelist on their browser of choice. It is a serious security risk to let people make this kind of security decision without understanding the technical implications. It creates a bad habit of accepting security risks popups as a path to less resistance...
3. This one is a long-shoot but definitely my favorite: Add small-step to umbrel so it can be its own local Lets-encrypt server. Here's a recipe of a working solution that could be adapted: https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/. The idea would be to have everything automated on first boot to create a new CA and a certificate for umbrel.local. But, before being able to connect to umbrel, the user has to securely retrieve the root CA file and add it to his devices certificate store so it is now trusted. I think that this solution best fit with the umbrel way of doing things so far.

[ulfklose]

I'd love to see an Tailscale integration regarding the certificate matter. Tailscale is already on your app store and they can provide SSL certificates.