Move away from default password

[Joseph Reynolds]

On 2019-06-17 17:56, Stewart Smith wrote:
> 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 imagine for the forseeable future, OpenBMC would continue to have a 
default userid and password (and I hope each development lab is using a 
different default password than the well-known password).  But I think 
development labs are subject to attack, so we need to eventually move 
away from default passwords even in the development labs.

At this time, I am looking for options to move away from this model, but 
do not anticipate changing the default.


>> 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.

Agreed.  Gaining initial access and recovering access the BMC is one of 
the issues.


>> 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.

Thanks, I understand this idea.  It may satisfy the letter of the law, 
and perhaps also its intent (disclaimer: not a legal opinion), so it has 
some merit.  But this scheme not as secure as random passwords 
(specifically, if the attacker learns the MAC addresses).

- Joseph