Move away from default password

Move away from default password

[Joseph Reynolds]

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.

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.

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.

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.

- Joseph

Re: Move away from default password

[Thomaiyar, Richard Marian]

Joseph,

#1 is not yet covered in any docs yet, but 
https://github.com/openbmc/docs/blob/master/user_management.md#deployment---out-of-factory 
this covers the out of factory deployment.

Regards,

Richard


On 6/17/2019 10:16 PM, Joseph Reynolds wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> - Joseph
>

Re: Move away from default password

[Adriana Kobylak]

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

How would this new "factory settings" flash partition be protected 
against being modified by an unauthorized or malicious user?

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

Re: Move away from default password

[Stewart Smith]

Adriana Kobylak <anoo@linux.ibm.com> writes:
>>> 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.
>
> How would this new "factory settings" flash partition be protected 
> against being modified by an unauthorized or malicious user?

My guess would be it'd be protected the same way that the default
password is today: not at all. If an attacker can write to flash, the
only way to reset the box is to dediprog the BMC flash chip.

-- 
Stewart Smith
OPAL Architect, IBM.

Re: Move away from default password

[Joseph Reynolds]

On 2019-06-17 17:58, Stewart Smith wrote:
> Adriana Kobylak <anoo@linux.ibm.com> writes:
>>>> 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.
>> 
>> How would this new "factory settings" flash partition be protected
>> against being modified by an unauthorized or malicious user?
> 
> My guess would be it'd be protected the same way that the default
> password is today: not at all. If an attacker can write to flash, the
> only way to reset the box is to dediprog the BMC flash chip.

Access to the flash would be protected from attack by network agents via 
password access to the BMC at two critical points.

In this scenario:
1. The factory assembles and tests the BMC, then changes its password to 
a new value.  The password hash is stored on the flash "factory 
settings" partition.  The BMC is then shipped to its new owner with the 
new password.
At this point, only the owner has password access to the BMC (unless the 
factory keeps a record of the new password).
2. The owner installs the BMC and configures it, including its network.  
For example, change the password, creates new accounts, and set up IP.
At this point, only the owner and owner's agents have password access to 
the BMC.

At this point, one of the owner's agents could use ssh to access the 
flash partition.  (But why would they need to?)

Re: Move away from default password

[Stewart Smith]

Joseph Reynolds <jrey@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.

Re: Move away from default password

[Joseph Reynolds]

On 2019-06-17 17:56, Stewart Smith wrote:
> Joseph Reynolds <jrey@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

Re: Move away from default password

[Stewart Smith]

Joseph Reynolds <jrey@linux.ibm.com> writes:
> On 2019-06-17 17:56, Stewart Smith wrote:
>> Joseph Reynolds <jrey@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 admire your optimism :)

I could probably ruin everybody's day with a simple nmap invocation and
for loop in shell across the IBM class A :)

Having something that wasn't the same everywhere would probably be an
improvement in the lab, and make it harder for someone to accidentally
do something to a machine they didn't intend to.

-- 
Stewart Smith
OPAL Architect, IBM.

Re: Move away from default password

[Carter Su(苏孝)]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]


Having a default password is a security risk, but if per BMC has an unique password, it may not very convenient for customer to use.
Customers will change the default password when they install new machinery, or they may creat new account and password for BMC to use.


Carter Su


---------- Forwarded message ---------
From: Stewart Smith <stewart@linux.ibm.com>
Date: Tue, Jun 18, 2019 at 6:59 AM
Subject: Re: Move away from default password
To: Adriana Kobylak <anoo@linux.ibm.com>, Joseph Reynolds <jrey@linux.ibm.com>
Cc: openbmc <openbmc-bounces+anoo=linux.ibm.com@lists.ozlabs.org>,
Openbmc <openbmc@lists.ozlabs.org>, Thomaiyar, Richard Marian <richard.marian.thomaiyar@linux.intel.com>


Adriana Kobylak <anoo@linux.ibm.com> writes:
>>> 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.
>
> How would this new "factory settings" flash partition be protected 
> against being modified by an unauthorized or malicious user?

My guess would be it'd be protected the same way that the default password is today: not at all. If an attacker can write to flash, the only way to reset the box is to dediprog the BMC flash chip.

--
Stewart Smith
OPAL Architect, IBM.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4084 bytes --]

Re: Move away from default password

[Joseph Reynolds]

On 2019-06-20 02:55, Carter Su wrote:
> Having a default password is a security risk, but if per BMC has an
> unique password, it may not very convenient for customer to use.
> Customers will change the default password when they install new
> machinery, or they may creat new account and password for BMC to use.

Thank you.  I understand that concern.  How do we balance ease of use 
-versus- security?
Having a well-known default password is easy to use, but too many 
installations fail to change the password, which gives attackers an easy 
way to take over the system.  Because of that, new laws are going into 
effect, for example [CA Law SB-327][], which require the system to not 
have a default password.

[CA Law SB-327]: 
https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327

I am looking at three options:

1. Leave the default OpenBMC configuration with the default password.  
That is, if you build an OpenBMC image from source, it will have the 
default password.
I wouldn't change that unless until there is a better alternative.  (See 
2 and 3 below.)

2. Same as option 1, but have a way to set an unique password for each 
system.  Specifically, the firmware image would be identical for 
multiple systems, but the password would be different for each.  You 
could use randomly generated passwords, or a scheme that generates 
password based on the system serial number or some other unique 
identifier (such as a MAC address), with weaker or stronger security 
considerations for each.  Whoever build the BMC image and loads it onto 
the BMC could change the password before giving the BMC to its end user. 
  As you point out, this may be very inconvenient.

3. Create a new feature: a new security mode to restrict the BMC's 
operation to setting up a new account.  Specifically, when this feature 
is engaged, the BMC requires you to create a userid and password before 
its full function can be accessed.

- Joseph

> 
> 
> Carter Su
> 
> 
> ---------- Forwarded message ---------
> From: Stewart Smith <stewart@linux.ibm.com>
> Date: Tue, Jun 18, 2019 at 6:59 AM
> Subject: Re: Move away from default password
> To: Adriana Kobylak <anoo@linux.ibm.com>, Joseph Reynolds 
> <jrey@linux.ibm.com>
> Cc: openbmc <openbmc-bounces+anoo=linux.ibm.com@lists.ozlabs.org>,
> Openbmc <openbmc@lists.ozlabs.org>, Thomaiyar, Richard Marian
> <richard.marian.thomaiyar@linux.intel.com>
> 
> 
> Adriana Kobylak <anoo@linux.ibm.com> writes:
>>>> 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.
>> 
>> How would this new "factory settings" flash partition be protected
>> against being modified by an unauthorized or malicious user?
> 
> My guess would be it'd be protected the same way that the default
> password is today: not at all. If an attacker can write to flash, the
> only way to reset the box is to dediprog the BMC flash chip.
> 
> --
> Stewart Smith
> OPAL Architect, IBM.

Re: Move away from default password

[Stewart Smith]

Carter Su(苏孝) <suxiao@inspur.com> writes:
> Having a default password is a security risk, but if per BMC has an unique password, it may not very convenient for customer to use.
> Customers will change the default password when they install new
> machinery, or they may creat new account and password for BMC to use.

I think there's a gap between what customers *should* do and what they
*actually* do.

Defaulting to as secure as possible is nice as it somewhat saves people
from themselves.

-- 
Stewart Smith
OPAL Architect, IBM.