Security - shared JWT secret

[benv666]

Describe the bug

Currently the JWT token used is hardcoded into the Docker image used for nethermind on DAppNode. This means that all dappnode installations running nethermind are using the same "secret", which is just as good a plan as having admin/admin as user/pass as defaults. If an attacker would be able to reach the engine API they can do whatever they want, since it's public knowledge. Worse, it's currently nearly impossible to change without hackery.

To Reproduce

1. Install Dappnode-Nethermind
2. Your jwt secret is fixed:

   $ docker exec -it DAppNodePackage-nethermind.nethermind.public.dappnode.eth cat /jwtsecret && echo
   7ad9cfdec75eceb662f5e48f5765701c17f51a5233a60fbcfa5f9e495fa99d18

Expected behavior

Either a configuration option to enter your own jwtsecret (please validate the length!) when installing nethermind, and/OR, automatically generate the jwtsecret when the docker container starts and the file does not exist (could be done through the entrypoint). (maybe put it on a shared volume?)

Screenshots

DAppNode version:

• Package version: v1.0.23, upstream: v1.14.0
• OS: debian

Additional context

I would like to hook up my own beacon node (running on a different machine) to Nethermind, which made me look into how the JWT secret was handled. Not happy.

[alexpeterson91]

We've been looking into various solutions to this situation, it's not a security concern currently but it does limit the ability to securely connect to external devices. We have had several internal discussions and some of it has been documented here https://github.com/dappnode/DNP_DAPPMANAGER/issues/1119. As it stands right now it would be a pretty major change every client and the core packages to implement true docker secrets, and would not be possible to refactor in short order, so we've been looking into other more creative options so we can securely expose the EngineAPI over HTTPS etc to use EL and CLs on separate machines. The fact that were still dealing with daily updates from each of the EL and CL clients (8 currently) that directly affect the interoperability of the various clients that each dev team is pushing out as fast as they can before the Merge is complete in a few days, makes this issue a lower priority for us right now. It is still actively being looked into by our devs and contributors brainstorming and sketching out possible solutions that dont require fully rewriting our codebase; but it's on the back burner for our core Devs since top priority is making sure we have all the latest clients working bug free, but once the Merge is complete in a few days it will become a P0 issue.

[benv666]

Hi Alex, thanks for the elaborate response, good to see you guys are investing in this issue. While I'm not sure I agree with it's not a security concern currently, I can see it why isn't a high priority one for now. I'll watch the linked issue with great interest and hopefully there will be a nice solution somewhere soon after the merge.

[alexpeterson91]

While it's certainly far from ideal from a security standpoint in theory, in effect right now at least, It's not much of a security concern because to be able to exploit it you would need to break all the layers of of protection already built into Dappnode to access the API anyways. So the threat level is quite low in that respect, if you trust Dappnode with your private keys, then you should have the same confidence in the security of the EngineAPI since its inaccessible by default and is not easily exposed by users let alone malicious actors, on purpose, until we have implemented a secure way of generating and passing the JWT via docker secrets. Then we hope to make it as secure and easy as using our HTTPS portal, which will likely also be getting and update with docker secrets securing the process even further.