[2.0.0] Make default root password the BMC MAC address

[CFSworks]

Problem summary

As a concerned Internet-security-conscious party (not "as a user"), I mirror @ruslashev's concerns about using an easily-cracked default password. Something found in an English dictionary is bad enough, but honestly I wouldn't be surprised if something out there is scraping GitHub for BR2_TARGET_GENERIC_ROOT_PASSWD= and building password lists out of the results.

Proposed solution

When the work in #126 lands, the BMC will finally have a unique+stable Ethernet MAC address. I would like to suggest that the default root password be this address, lowercase hex, no separators (e.g. 0200339bb454). This has several benefits:

• It is unique, with theoretically 32 bits of entropy (in practice, probably more like 20) and not in any wordlists
• It is easy for the authorized user to find: the authorized user is probably on the same Ethernet LAN as their BMC during first-time setup, and can easily learn the MAC address of the BMC (indeed any host on the same LAN) with ip neigh (Linux), arp /a (Windows), arp -a (Linux/BSDs/macOS). If not, the authorized user can most likely check the router's DHCP leases to learn the MAC address that way.
• It is relatively hard for an unauthorized user to find: unauthorized users are unlikely to be on the same LAN and can't learn the MAC address remotely.
• It is inconvenient to type/memorize thereby giving an incentive to the user to change it. Normally I am not a fan of inconveniencing users, but we really should not make continuing to use the default password the path of least resistance. :)

Why in 2.0.0?

With 2.0.0 already being a monumental upcoming release, it is hard to justify adding "just one more thing" into it, but this may be appropriate, because:

• The implementation should be pretty easy. All we need is a script in /etc/init.d to check if the root password is unset and set it to the (properly-formatted) MAC address.
• There are some security consequences. The safemode introduced in 2.0.0 can activate accidentally (if the overlay is somehow corrupted) and users (+ botnet-hating Internet folks) will appreciate the barn door not swinging quite so wide open to unauthorized access.
• This is a good opportunity to let the user know. The upgrade to 2.0.0 will (hopefully) be the last in which the system settings reset to their defaults, so it would be good to take that opportunity to run the user through the exercise of finding the BMC MAC address and making them aware that this is the new default. This way, if they ever have to use safemode, they already know what to expect.

Thoughts, on either the approach or the timing?

[fentonfentonfenton]

It's super common for things (helm charts, devices, Linux distros, applications) to use a default admin password and more common for the user to have to set a variable or flag to not use the default, which I think is a fine pattern to follow (not going to expose the BMC to the outside world and by default on 99.99% of users home networks aren't either) so I would probably find this more annoying than useful?🙂 I get the idea though

[walkjivefly]

Sounds like a good idea to me. So long as the MAC address really does stay fixed (or always initialises to the same value on the same hardware).

It's a minor inconvenience for the owner to find their unique default password, slap it into their password manager and never have to worry about it again. Or with better understanding of opsec find it, change it, slap it into their password manager.

[ruslashev]

I really like the idea, and the timing seems good to me (it's the 2.0.0 after all), but I am a little concerned about the connectivity over LAN requirement: what if the user wants to connect to the board via a MPCIe-3G card -- does that mean we would force them to procure an Ethernet cable for the first time setup? It wouldn't be the first additional cable we require, like USB-A↔USB-A/C, but still, could it be avoided?

[soxrok2212]

I think a better solution would be to require a mandatory password change on first login. That way, there's no guessing with arp or whatever else, and a reset guarantees it back to a known default.

[svenrademakers]

Choosing the right solution is a balancing act between user-friendliness and security hardening. Setting the default password to MAC is perhaps at the cost of the user experience. (unless we would make tooling to show/ retrieve the password).

The solution proposed by @soxrok2212 ticks the boxes of better security with minimal user experience degradation. We would still have an easy-to-guess default password but have a wider adoption rate of unique passwords. Which is the goal of this ticket.

[hoinzy]

I think there are more positions to consider here: Once an attacker has gained access, at any point in time even during setup, the correspondence with the device afterwards has to be considered compromised since everything from that moment on can be faked.

If MAC Addresses are at some point registered, they will have a prefix. Then some evil people will just scan larger corporate networks for these prefixes, and brute-force the remainder for these.

I would again like to promote the idea of the fuses: some signed hash is burned into the efuses. The initial password is derived from this. The user get's a user friendly representation of the specific burned fuse (like some derived smileys), and can rest assured that no matter which firmware is flashed: As long as the algorithm remains, the board will always display the same seed by those smileys.

[soxrok2212]

I think there are more positions to consider here: Once an attacker has gained access, at any point in time even during setup, the correspondence with the device afterwards has to be considered compromised since everything from that moment on can be faked.

If MAC Addresses are at some point registered, they will have a prefix. Then some evil people will just scan larger corporate networks for these prefixes, and brute-force the remainder for these.

I would again like to promote the idea of the fuses: some signed hash is burned into the efuses. The initial password is derived from this. The user get's a user friendly representation of the specific burned fuse (like some derived smileys), and can rest assured that no matter which firmware is flashed: As long as the algorithm remains, the board will always display the same seed by those smileys.

Burning to efuses imo is horriblly over complex for this. The typical use case of efuses is for a public key to validate a signature, e.g. securebooting signed firmware images/bootloaders or enabling/disabling features like UART at the hardware level.

it makes no sense to store a seed for the default password in efuses. Anyways, efuses are typically burned at the factory, and given many people already have their TPI2, this means the seeds would have to be generated on the fly by people’s devices which kind of blows up your point of “the device afterwards has to be considered compromised”.

Further, having password algorithms fed by seeds has been proven time and time again to be insecure .