Move away from default password

[Stewart Smith]

Joseph Reynolds <jrey at linux.ibm.com> writes:
> There is some interest in moving OpenBMC away from a default password.
> - email: 
> https://lists.ozlabs.org/pipermail/openbmc/2019-June/016515.html  (which 
> references a RestrictionMode design: 
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/21195)
>
> Having a default password is a security risk.  Note that changing to a 
> different default password is not a good solution.  For example, if a 
> bad actor learns the default password from one device, that actor will 
> likely know the password for many of them.

and it makes it pretty easy to use something like Shodan to find all the
possible OpenBMCs connected to the Internet (hopefully by accident) and
pop a root shell on them.

Mind you, in a lab environment, it's *really* useful.

> I am exploring two options for OpenBMC, and want your feedback.
>
> 1. Unique password per BMC.
> In this approach, there is a way to change the factory default password. 
>   Example flow: assemble the BMC, test it, factory reset, generate unique 
> password (such as `pwgen`), then use a new function “save factory 
> default settings” which would save the current setting into a new 
> “factory settings” flash partition.  After that, a factory reset 
> would reset to the factory installed password, not to the setting in the 
> source code.
> Presumably the new factory default would be printed on a sticker, or 
> something.
> Are there any other factory settings (settings unique to each device) 
> that would benefit from being set like this?
> One downside to this approach is someone who orders 100 systems has to 
> enter 100 unique passwords.

There's also a downside for those of us who often work remotely from
machines, we may have to wait for someone to be awake and be able to
physically go and check what the default password is.

> 2. Create new account on first access.
> Specifically, default OpenBMC to use a new RestrictionMode=SetupAccess 
> which:
>   - (A) requires users to set up their credentials (at least: remove the 
> default password) before they can leave that mode, and
>   - (B) does not let the user do anything else, including other 
> provisioning or operating the host, while in this mode.
> So we could manufacture the BMC with a default password, but require it 
> to be changed as the first step to provision the BMC.
> We might want to make network services react to this new mode, for 
> example, the phosphor-webui GUI would likely want to handle this 
> specially, and most REST APIs would be restricted.
> Note this approach gives an attacker a window of time before the 
> credentials are set up.

In a lab environment though, we'd have to ensure we had a *very*
reliably way to reset the BMC when we switched who was using the machine.

>
> I believe both of these approaches represent reasonable security 
> practices which may satisfy laws regarding consumer products.  For 
> example, CA Law SB-327 
> https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327
>
> Are there guidelines we can follow?  Can you find additional 
> vulnerabilities with these approaches?  Can we do better than this 
> without requiring additional infrastructure?
>
> I plan to discuss this at the 2019-06-26 Security working group meeting: 
> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/
> and would be happy to see ideas here.

I had an idea that provides less security, but still may be valuable:
make the default password at manufacturing be linked to the MAC address
of the BMC. This prevents people not on a local network to the machine
from gaining access (e.g. I have no idea what the MAC address of 8.8.8.8
is), but if I'm on the same ethernet network, then I can still work it
out. It would also allow someone buying 100 machines to programatically
work out what the password should be.

-- 
Stewart Smith
OPAL Architect, IBM.