How "insecure" is Umbrel, really?

Hi all
I’m sure we’re all aware of the “experimental” warnings around Umbrel, Lightning, etc.

I’m wondering a couple of things:

  1. How “insecure” is Umbrel, really?
  2. How much would you store on Umbrel in channels, etc.
  3. Where do the insecurities come from? Local network? The fact that the app passwords can’t be changed? The “security by obscurity” approach of the apps behind Tor?

Thanks!
JL

I’m no security expert but I think the biggest security risk is this:

  1. Somebody you don’t trust may get access to your local network’s wifi password, or plug into it directly via ethernet. Could be a “friend” of a friend, or some worker at your home, etc.
  2. They try the access umbrel.local and then access any of the apps that run on default passwords like ThunderHub.
  3. Log-in with ‘moneyprintergobrrr’, and send out your funds.

To avoid this attack, uninstall all apps that allow sending out funds, and can only run with the default password. Mempool for example is safe, because it doesn’t allow sending out funds, and RTL is safe too because it lets you change the default password. But Thunderhub should be uninstalled.

The same attack can be performed if somebody gets hold of your onion address in some way. All the more reason to uninstall unnecessary apps.

–––

The second biggest issue in my view is the inability to restore funds in channels in case of a catastrophic hardware failure. Any electrical or mechanical failure may render your node inaccessible and unrecoverable.

Your on-chain funds are no problem. You can restore it with the seed as long as you kept is safe.

However, your channels need to be closed down nicely to access your SATS. If you have the channel backups you can issue a command to close those channels down, but you still need an operational Umbrel as far as I understand. You can’t issue that command from another device. (I’m unsure here, please correct me if wrong.)

If you can’t use your channel backup for any reason one of three things will happen:

  1. The other party will keep the channel open indefinitely or for a very long time even though it’s offline. Your sats will be stuck potentially for a long time until option 2 or 3 materialised.
  2. The other party will close your channel and everyone gets back their SATs fairly. Thus you will get them back on the restored on-chain wallet you created with the backup seed. Good outcome.
  3. The other party may try their luck and transmit a previous state of the channel where they had more SATs on the channel than you. And since you can’t issue a penalising transaction they will get away with it. You will get little or nothing, and they steal your funds. Worst outcome.

–––

How much to “risk” on channels? We must remember that we’re dealing with software that is all work in progress. It’s really good, but there are scenarios that nobody can foresee. A combination of hardware, network and user actions can create a situation that we can’t predict and defend against.

Generally, I believe you’re better off in terms of risks to go with Umbrel than building your own stack of software, because the Umbrel team and the community gives you an extra layer of testing. So if you’re running a business for example, it’s probably wise to run Umbrel instead of building your own node, unless of course you really know what you’re doing.

So, definitely don’t store your life savings on Umbrel and certainly not on channels. You should put only as much money on your Umbrel that you want to use for spending, for testing and learning. This amount could be as little as $100 worth of SATs or 0.1BTC depending on the person’s wealth and their appetite for risk.

2 Likes

Thanks for the very thorough and thoughtful answer! I wish I could !lntip you here :wink:

I do wish we could change the password for ThunderHub, I wonder if there’s a way to do that maybe in an upcoming release.

I hadn’t thought about the channel backups requiring you to have another Pi handy in case of failure. I suppose you could always boot up a Linux (or even Raspbian) virtual machine on your computer just to restore the channels and then close them with the last agreeable state, but that’s far from ideal, of course. Perhaps it’s a good idea to get another Pi just as a backup. Shame I just missed Prime day :wink:

0.1BTC is certainly not a lot if you want to do some serious routing, but I guess it depends on people’s risk appetite. I’ll certainly feel safer when I can get the password changed on ThunderHub, and, I’ll make a feature recommendation to @aarondewes and @mayank to add 2FA via Google Authenticator or something like that - that would be a HUGE improvement to security, I think.

1 Like

Just FYI, I took some time to look at the Security.md file, and here’s what they have to say:

    # Security Disclosure

**Umbrel is currently in beta and is not considered secure.**

We are trying to iterate rapidly and build out our vision and only have so many hours in the day. Due to this, we've decided to make the following trade-offs to allow us to ship a working beta with critical features, such as over-the-air (OTA) updates and easy log access, as soon as possible.

**No signature verification on OTA updates or when pulling Docker images.**

The lack of signature verification means GitHub as a company could backdoor the OTA update process or Docker Hub could backdoor our Docker images. It's quite unlikely that they would do this but currently we just have to trust that they won't. If this were to occur, the current update system would not detect or prevent it.

**3rd-party Node.js dependencies.**

During the beta phase we are making use of Node.js and its rich ecosystem of npm packages to rapidly build out features. However the npm ecosystem tends to make use of a large number of small focused modules. This can make audibility difficult as you end up with a huge dependency tree for even relatively simple projects.

**Assuming the local network is secure**

Umbrel currently makes the assumption that the local network is secure. This means local network communication is unencrypted using plain text HTTP. (Remote access via Tor is encrypted)

This is pretty much the industry standard when it comes to locally networked devices. All routers and smart devices that expose a web interface work this way. Bootstrapping a secure connection over an insecure network and avoiding MITM attacks without being able to rely on certificate authorities is not an easy problem to solve.

However, we think we can do better and have some interesting ideas on how to make Umbrel safe to run even when the local network is untrusted.

**Hardcoded app passwords**

We use hardcoded passwords for apps that support password authentication. These hardcoded passwords aren't providing any actual security, they are there to prevent "annoying sibling" level attackers.

We plan to resolve this by implementing SSO authentication across all apps. We can implement this at the Umbrel level transparently without any modifications required from individual apps.

This means all Umbrel apps exposing a web interface will be protected by your Umbrel dashboard password.

**Relaxed Permissions**

Currently we are being quite liberal with filesystem permissions and root usage. Some background jobs on the host are currently being run as root that don't strictly need to. Also some scripts executed by root are writable by non-root users. The `umbrel` user itself is also currently added to the `docker` group which makes it essentially root.

**No Network Level Sandboxing**

Apps already have process level sandboxing and filesystem level sandboxing but not network level sandboxing. We plan to implement network level sandboxing so one app will not be able to interact with another app over the network. Apps will also not be able to interact with other physical devices on the local network without explicitly asking the user for permission.

Umbrel, in its current state, is intended to demonstrate what we have in mind, show the community what we are building, and to get early feedback. It's in a state that it can be used, but should not be considered secure. Thus, **you should not put more funds on your Umbrel than you're prepared to lose.**

The issues raised above will all be resolved before we do a stable release of Umbrel.
1 Like

It’s not much of a security risk if you don’t put Bitcoin on it.

I for one, only use my Umbrel Node to get blockchain data from my software and hardware wallets like Electrum, Sparrow, Wasabi, and Trezor. I also allow friends to access my Umbrel Node from remote locations using Tor and their software and/or hardware wallets. (They are working on running their own nodes, but they’re welcome to use mine until they are set up.)

Could someone break into my local network and gain access to my Umbrel?.. Yes. But they won’t get any of my Bitcoin.

1 Like

Really good points. Just want to add on a couple more things

  1. Having a watchtower setup can help mitigate the other party broadcasting a previous channel state.
  2. Using the channel backup to request channel close won’t work if the other node is gone. Make sure you prune zombie nodes.
1 Like

How do you define a ‘zombie’? Inactive for a long time?

Yeah, I think it’s 2 weeks for most zombie node/channel statistics. But it depends on you. You could have faith that they will come back and keep it open for a month or 2.

1 Like

So far some good points. I disagree though with the whole idea of not keeping Bitcoin on the node. Half the appeal for me of running my own node is routing on lightning, and I would like to increase my capacity more in order to do that… however, not if it’s risky.

I guess having a second pi around or even a virtual Linux machine ready to be able to restore and close channels would solve most of the concerns except for the local network situation… but also umbrel will hopefully allow single sign on soon.

2 Likes

In the context of the apps having standard passwords, this is concerning. Is there a timeline on Umbrel’s side that they want to update the node in a way that the standard passwords are protected?

I really want to learn and build up channels now. But I also don’t want to increase the risk too much.