Umbrel: Serious security concern: warning from README is NOT on the website

[Kixunil]

The warning about security is not present on getumbrel website. As a result multiple people installed Umbrel without knowing about the security issues. Especially open SSH with default password which I consider a grave issue.

It is good that you have the warning in README but it must be on the website because most people install from the website directly, not from github.

Also perhaps you should remind the users of the issues in your marketing campaigns as they make Umbrel look like finished product.

[mayankchhabra]

Thanks for raising your concern, @Kixunil. I don't know if you've tried running Umbrel for yourself, but we make it very clear during the onboarding that Umbrel is in beta, it should not be considered secure, and you shouldn't put more funds on it than you can afford to lose.

Our target audience isn't technical, and most of them don't even know what "SSH" means. We don't want to turn them off with things they don't understand and make them feel like they need a certain level of technical literacy to understand and use the product, as that would end up defeating our entire purpose.

It's also unnecessary for them to understand every single security tradeoff that we've currently made during the beta, as long as they are generally aware of the fact that it is not secure and they shouldn't put anything on it that they can't afford to lose — which we think the final screen of our onboarding has done a good job at.

[Kixunil]

Hmm, yet, those people still install it, so I'm not convinced it's sufficient. It also wastes their time if they only learn about it at the last step and may feel pressure of sunken cost fallacy to continue using it despite the warning.

If they shouldn't know what SSH means, perhaps disable it by default instead of using default password? That'd help a lot.

[AaronDewes]

Hmm, yet, those people still install it, so I'm not convinced it's sufficient. It also wastes their time if they only learn about it at the last step and may feel pressure of sunken cost fallacy to continue using it despite the warning.

If they shouldn't know what SSH means, perhaps disable it by default instead of using default password? That'd help a lot.

We need SSH for debuggin, and we'd have to implement an option to enable it first.

[Kixunil]

My understanding is that you use a modified RPI image. If that's the case you just need to touch /boot/ssh after flashing the SD card.

Alternatively, you can create two builds. That's how I do it - never release debug/testing versions to general public.

[AaronDewes]

Yes, we use a modified RPi Image. The issue is not that we need to use that for our debugging (we have umbrel-dev for that) but to help users debug Umbrel. Currently there is no way to debug issues by adding that file because if Umbrel gets stuck on the loading screen, it's impossible to shut it down safely to add that file, so we need SSH.

[Kixunil]

Ah, that makes sense. Given the seriousness of the issue I believe changing the password should be the highest priority if you refuse to copy the warning to your website. The remaining known security issues are nowhere near that serious. This is nearly free sats for attackers.

[karozagorus]

I feel cheated.

[AaronDewes]

I feel cheated.

Why? There clearly is a warning, and you can always run myNode or RaspiBlitz on the same hardware and wait with Umbrel until it's more secure.

[crownbtc]

Why is changing default password controversial? This seems like common sense...

Still unacceptable compromise imo...but at least a hacker would have to use a tiny bit of effort

[karozagorus]

Let us change the default SSH password.

[AaronDewes]

It will be added soon

[Kixunil]

There clearly is a warning, and you can always run myNode or RaspiBlitz on the same hardware and wait with Umbrel until it's more secure.

It's not on your website and it's not in your marketing materials. Most people don't read it.
Also the hardware argument really doesn't apply. Let's say that someone likes various projects in this order:

1. Umbrel - not knowing about vulnerability
2. Cryptoanarchy Debian Repository - only supported on x86_64
3. everything else goes here

Perhaps such user would pick 2. if he had known about the vulnerability and would need a different hardware.
Putting it at the end of install process is the worst kind of marketing.

[karozagorus]

Putting there the BIG DISCLAIMER about I have to SSH in, knowing that EVERYTHING is the DEFAULT SSH password, I would have immediately change it after setting it up and not sit on it for 5 days. How would you feel if your router came with default SSH password exposed to the wild open internet and you never changed it? I would personally be terrified of the consequences, this must be put onto the knowledge of users in clear readable format during installation.

[AaronDewes]

SSH is NOT exposed to the internet, only to the local network

[CommanderPoe]

You guys should stop being this defensive and let the users change that default password even if ssh is not by default open to the internet. Furthermore i strongly agree with @Kixunil that a disclaimer other than 'our audience is not technical' and 'we dont want to turn them off' should exist. Just saying...

[Kixunil]

SSH is NOT exposed to the internet, only to the local network

Repeating for visibility: NAT is easy to bypass e.g. https://samy.pl/slipstream/

[jodobear]

100% agree with @Kixunil @karozagorus & @CommanderPoe we can't let security be a second thought, this is a given building on bitcoin. This is lazy and just not acceptable.

Maybe create two versions, a production version without the default password and a test version with the default password, with the information EXPLICITLY stated at the beginning. That way maybe Umbrel get closer to moving out of beta.

[AaronDewes]

100% agree with @Kixunil @karozagorus & @CommanderPoe we can't let security be a second thought, this is a given building on bitcoin. This is lazy and just not acceptable.

Maybe create two versions, a production version without the default password and a test version with the default password, with the information EXPLICITLY stated at the beginning. That way maybe Umbrel get closer to moving out of beta.

Repeating for visibility: We'll change it in the future, it's already planned!

Repeating for visibility: NAT is easy to bypass e.g. https://samy.pl/slipstream/

This only allows to access ports on the comßputer the website is opened on.

You guys should stop being this defensive and let the users change that default password

I said multiple times that we're planning to do that, i just stated that the issue is not as severe as you're saying.

[lukechilds]

SSH is NOT exposed to the internet, only to the local network

Repeating for visibility: NAT is easy to bypass e.g. https://samy.pl/slipstream/

@Kixunil just want to clarify that Umbrel is not vulnerable to this attack.

From: https://samy.pl/slipstream/

NAT Slipstreaming allows an attacker to remotely access any TCP/UDP service bound to a victim machine, bypassing the victim's NAT/firewall (arbitrary firewall pinhole control), just by the victim visiting a website.

I'm not sure how familiar you are with Umbrel but it's run on a dedicated server, not the users machine, so the Umbrel SSH port is not "bound to the victim machine" (which accesses the malicious website via browser) and therefore is not vulnerable to this attack as I understand it. Umbrel runs on a dedicated server and the browser would not be used from the same machine.

I'm always open to hearing valid criticism but I agree 100% with Mayank's response here: https://github.com/getumbrel/umbrel/issues/381#issuecomment-753273274

We have clearly documented every security trade off we currently make in high detail for technical users on GitHub. For non-technical users we have a very clear disclaimer that "Umbrel is in beta, it should not be considered secure, and you should not put more funds on it than you're prepared to lose." I don't think it makes any sense to go into technical detail on the specifics for non-technical users. We've clearly stated it's beta/insecure, that's enough for them to make a decision on if Umbrel is right for them.

I feel confident we've done what is expected of us.

Also I just want to say here that I feel a little disappointed with the way you went about this. I really respect you a lot, I'm a huge fan of your work on electrs, btc-rpc-proxy and on your cryptoanarchy repo. I look up to you as a developer, it doesn't make me feel good to hear you criticise something that I'm working on. But as stated above, I personally feel confident that we've done a good job at educating our users.

I appreciate you taking the time to open an issue and raise your concerns, and I'm sorry if you aren't happy with our response. But seeing you write articles stating that running an Umbrel means an attacker could "Store child porn on the disk of your node and report you" seems needlessly sensational and I feel is in poor taste. If an attacker already has access to your network, they can already download illegal material from your network and report you. Umbrel plays no role in that. I know you already understand this, but non-technical users don't.

We have already clarified in our security document that Umbrel currently makes the assumption that the local network is secure. I don't think replicating our security document with sensationalist wording is particularly helpful to educate users. If you want to help educate users you can link to our existing security document which we will continue to update.

[Kixunil]

Sorry about that mistake with slipstream, I've corrected my wordings in places where it'd confuse people. The bigger point of it was that NAT vulnerabilities do exist and relying on NAT is not a good security practice.

@lukechilds to be completely honest, I was holding off disclosing it this publicly mainly because of your involvement - you seem like an honest person to me and I was hoping this would be fixed soon. Perhaps I could have done it in a way that is somehow better. Please let me know if you see something I missed.

I was mainly triggered by learning that even Karo, who is interested in security and asks me questions about what is secure and what is not, got confused by this. That led me to believe the matter is urgent.

You believe that you did everything right and I believe you did your best. I just have a good reason to think you missed one thing. That's why I opened the issue first. I was myself surprised that people don't read GitHub so there's a chance I would do a similar mistake. The mistake is that it is possible for a person to start installing it before being aware of the risks. That's why I asked to put it on your website.

"Store child porn on the disk of your node and report you" seems needlessly sensational and I feel is in poor taste. If an attacker already has access to your network, they can already download illegal material from your network and report you.

I went into creative mindset and tired to think of "the worst that can happen", which is a common thing to do when thinking about security. I was mainly thinking of storing but you have a good point. I updated the text.

replicating our security document

There are some differences which I find important:

• It's written in a way anyone can understand - no "technical gibberish" about SSH, which most people don't even know what it is.
• It was shared on Twitter instead of hidden on GitHub
• It talks about the biggest issue mainly

That all being said, maybe I am too paranoid. Heck I don't dare to clearly document how to use an experimental version of my project which is more secure and probably more stable than Umbrel. Making a website and suggesting random people to try it seems insane to me. (I only sent the instructions to people who I knew were aware of the details and had the capability to resolve the issues.)

So if wider Bitcoin community, including technically knowledgeable people, agrees that not putting a disclaimer on a website is fine, I will think about it and perhaps admit my mistake and finally make a proper website for my stuff so that more people would try it. :)

If you agree that putting a good disclaimer on your website is reasonable, I offer you my help in coming up with wording that'd be both understandable for general public and sufficiently detailed to not be hand-wavy.