openstack/security-analysis
Code Issues Proposed changes

Initial draft of Barbican review

Browse Source 
Change-Id: Id2a1be4baf4a2a62433572785359dd7c550ce8a5
This commit is contained in:
Douglas Mendizábal 2016-08-19 10:47:02 -05:00 committed by Doug Chivers
parent ee91b2dae1
commit f31be8a32d
3 changed files with 494 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

325
doc/source/artifacts/barbican/newton/architecture-page.rst Normal file
View File

@ -0,0 +1,325 @@
==========================
barbican architecture page
==========================
barbican - 3.0.0.0b2/newton
---------------------------
**Status**: Draft
**Release**: Newton
**Version**: 3.0.0.0b2
**Contacts**:
- PTL: Douglas Mendizábal - redrobot
- Architect: Douglas Mendizábal - redrobot
- Security Reviewer: Robert Clark - hyakuhei
- Security Reviewer: Doug Chivers - capnoday
Project description and purpose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Barbican is a RESTful API for the secure storage, provisioning and management
of secret material such as passphrases, encryption keys and X.509 certificates.
Primary users and use-cases
~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. End users will use the system to store sensitive data, such as passphrases
encryption keys, etc.
2. Cloud administrators will use the administrative APIs to manage resource
quotas.
3. Other cloud services will use the system to store/retrieve sensitive data on
behalf of end users.
External dependencies & associated security assumptions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Barbican depends on an external Authentication/Authorization service. In
a typical deployment this dependency will be fulfilled by the keystone service.
This review is of a barbican deployment with a certificate management system
(CMS) and PKCS#11.
Components
~~~~~~~~~~
- API Process (Python): Python web service listening for web requests.
- Worker Process (Python): Python process that executes tasks
retrieved from the worker queue.
- keystone Listener Process (Python): Python process that consumes keystone
events published by the keystone service.
- Database (MySQL): MySQL database to store barbican state data related to its
managed entities and their metadata.
- Worker Queue (RabbitMQ): This queue is used to process new order
requests.
- Configurable secure backend. One of the following:
- DogTag Service: An instance of the RedHat DogTag service.
- Hardware Security Module (HSM): Dedicated hardware security module with
either a PKCS#11 or KMIP interface
- Administrative CLI (Python): Command line interface tool that performs
administrative tasks.
Service architecture diagram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. image:: figures/barbican_architecture-diagram.png
Generated using draw.io, editable version:
https://www.draw.io/#G0Bz5iXPX51Qd9SW1IZXZ2UjljWEU
Data assets
~~~~~~~~~~~
- *Secret data* : Passphrases, Encryption Keys, RSA Keys - persisted in
Database [PKCS#11] or HSM [KMIP] or [KMIP, Dogtag]
- *Secret metadata* - persisted in database
- *RBAC rulesets* - persisted in policy.json
- *ACL rules* - persisted in database
- *DB Credentials* - persisted in barbican.conf
- *HSM Credentials* - persisted in barbican.conf, clients are also paired with
the HSM (for Safenet anyway) via PKI
- *RabbitMQ Credentials* - persisted in barbican.conf
- *keystone Event Queue Credentials* - persisted in barbican.conf
- *Middleware configuration* - persisted in paste.ini
- *[PKCS#11] HSM HMAC Key* - persisted in HSM
- *[PKCS#11] HSM Master Key Encryption Key (MKEK)* - persisted in HSM
- *Per-project KEKs wrapped by MKEK* - stored in DB
- *CA (dogtag) credentials* - persisted in worker process barbican.conf
- *keystone Credentials (barbican service account)* - should be configured to
only allow token validation but in some configurations may have higher
privileges
- *Client keystone token* - ephemeral token provided by client, validated
against keystone by barbican service account, could be any level of
permissions (e.g. service accounts for other services)
- *CADF Credentials* - write only access to rabbit server
Data asset impact analysis
~~~~~~~~~~~~~~~~~~~~~~~~~~
Data Assets:
- *Secret Data*:
- Integrity Failure Impact: Differs between plugins. In the case of the KMIP
plugin, secret data is stored directly in the HSM and direct compromise is
out of scope (See HSM credentials) however the PKCS#11 plugin encrypts
secret data in the HSM, using a key that is not retrievable from the HSM.
If secret data was tampered with in the database, subsequent retrieval via
the HSM would fail because of HMAC integrity checks.
- Confidentially Failure Impact: Secret data is persisted in the DB only in
its encrypted form. When the encryption keys are protected Exposure of this
data has little impact.
- Note: The simple-crypto plugin does not protect against these issues
- Availability: Service breaks if secret data is not available
- *Secret metadata*:
- Integrity Failure Impact: barbican ignores metadata, it is there as a
facility for users. User applications could be affected by changes to this
metadata. Future UI designers should ensure that metadata is sanitized
before being rendered to avoid things like XSS in metadata.
- Confidentiality Failure Impact: Metadata is not intended to be confidential
and barbican does not encrpyt it, but end-users could use metadata to
store confidential information.
does not encrypt it.
- Availability Failure: barbican unaffected
- *RBAC/ACL rulesets*:
- Integrity Failure Impact: Attacker with valid AuthN could be granted access
to any secret.
- Confidentiality Failure Impact: Mappings between users and secrets
- Availability Failure Impact: barbican will not start if the file is not
readable.
- *DB Credentials*:
- Integrity Failure Impact: barbican won't be able to access DB and fail to
start.
- Confidentiality Failure Impact: ACLs could be abused to grant access to all
secrets for any Authenticated user (AuthZ failure). All Secrets could be
deleted / mangled.
- Availability Failure Impact: barbican won't be able to access DB and fail
to start.
- *HSM Credentials*:
- Integrity Failure Impact: barbican can no longer authenticate to HSM,
there is potential here to cause the HSM to purge on multiple reconnects.
- Confidentiality Failure Impact:
- [PKCS#11] No keys are exposed, MKEK and HMAC keys could be deleted,
causing a denial of service (DoS). If these were not backed up, all
secrets would be lost.
- [KMIP] Attacker is able to retrieve all secrets from the HSM
- Availability: barbican won't be able to access HSM and will fail to CRUD
secrets in KMIP, unable to decrypt or encrypt secrets in PKCS#11.
- *RabbitMQ Credentials*:
- Integrity Failure Impact: barbican and Workers can no longer access the
queue. Denial of service.
- Confidentiality Failure Impact: An attacker could add new tasks to the
queue which would be executed by workers. User quotas could be exhausted by
an attacker. DoS. User would be unable to create genuine secrets.
- Availability Failure Impact: barbican could no longer create new secrets
without access to the queue.
- *Identity Service (keystone) Event Queue Credentials [Including endpoint
address]*:
- Integrity Failure Impact: An attacker could setup their own queue, point
barbican to this rogue queue and by publishing events, delete all
users/projects/secrets in barbican. Additionally, typical DoS scenario
using incorrect credentials for the legitimate queue.
- Confidentiality Failure Impact: barbican should only be able to subscribe
to the event queue. An attacker with the credentials could create their own
subscriber meaning that legitimate events don't get consumed by barbican.
Race condition?
- Availability Failure Impact: Projects might not get deleted when they
should be but the overall run state of barbican is unaffected.
- *Middleware Configuration*:
- Integrity Failure Impact: Can remove/replace keystone auth middleware -
allows you to capture tokens and also could cause barbican to fail open
(everything authorized). If keystone auth middleware is deleted from
paste.ini, an attacker could add their own keystone headers to REST
requests and barbican would interpret them as valid. If an attacker had
access to the filesystem they could inject their own middleware by dropping
a class on the FS (in the Python path) and directing paste.ini to use that.
- Confidentiality Failure Impact: Minimal - an attacker can enumerate the
middleware.
- Availability Failure Impact: barbican breaks
- *PKCS#11 MKEK/HMAC*: - Stored un-retrievable in HSM
- Integrity Failure Impact: PKCS#11 create, read, update, delete (CRUD)
operations will fail.
- Confidentiality Failure Impact: All secrets in DB could be decrypted.
However this failure mode is out of scope for this TA.
- Availability Failure Impact: PKCS#11 CRUD operations will fail.
- *PKCS#11 MKEK/HMAC*: - backed up *somewhere*
- Integrity Failure Impact: HSM Disaster Recovery will fail : PKCS#11 CRUD
operations will fail.
- Confidentiality Failure Impact: All secrets in DB could be decrypted by an
attacker with knowledge of the DB contents.
- Availability Failure Impact: HSM Disaster Recovery will fail : PKCS#11 CRUD
operations will fail.
- *Dogtag Credentials*:
- Integrity Failure Impact: Inability to submit or issue certificates (DoS)
- Confidentially Failure Impact: A malicious user can create valid
certificates for any service that trusts the Dogtag CA.
- Availability Failure Impact: Unable to submit or retrieve certificates.=
DoS.
- *Certificate Signing Request*:
- As a cryptographically "public" asset, we do not model CIA for Certificate
Signing Requests
- *keystone Credentials*:
- Integrity Failure Impact: barbican will not be able to validate user
credentials and fail. DoS.
- Confidentially Failure Impact: A malicious user might be able to abuse
other OpenStack services (depending on keystone role configurations) but
barbican is unaffected. If the service account for token validation also
has barbican admin privilages, then a malicious user could manipulate
barbican admin functions.
- Availability Failure Impact: barbican will not be able to validate user
credentials and fail. DoS.
- *Client keystone Token*:
- Integrity Failure Impact: barbican will not be able to validate user
credentials and fail. DoS.
- Confidentially Failure Impact: A malicious user might be able to abuse
OpenStack services including barbican. If the token had an admin scope then
an attacker may be able to subvert multiple cloud services. [Total fail].
- Availability Failure Impact: Not a persistent asset, provided and used at
the same time.
Interfaces
~~~~~~~~~~
Format:
From->To *[Transport]*
- Assets in flight
- Authentication?
- Description
1. Client->API Process *[TLS]*:
- Assets in flight: User keystone Credentials, Plaintext Secrets, HTTP Verb,
Secret ID, Path
- Access to keystone credentials or plaintext secrets is considered a total
security failure of the system - this interface must have robust
confidentiality and integrity controls, i.e. TLS.
2. Administrator->API Process *[TLS]*:
- Assets in flight: barbican admin keystone Credentials
- An attacker with access to the admin credentials can modify quotas,
expanding or reducing them for any user. This has potential availability
impact. DoS.
3. Administrator->API Process Host *[SSH]*:
- The actions of a malicious administrator are out of scope for the
OpenStack Threat Analysis Process. However the OSSP suggests hosts for
OpenStack services are configured following best practices such as
**<TODO>.**
4. Administrator->Administrative CLI *[SSH]*:
- The actions of a malicious administrator are out of scope for the
OpenStack Threat Analysis Process. However the OSSP suggests hosts for
OpenStack services are configured following best practices such as
**<TODO>.**
5. API Process->PKCS#11 HSM *[NTL]*: - work to understand NTL is required
- Assets in flight: HSM Credentials(Partition), HSM Commands, Plaintext
Secrets, MKEK wrapped PKEKs (MKEK is never transmitted over this
transport).
- Note: Access to individual secrets resulting in a compromise of system
integrity. Only secrets that were transmitted in view of an attacker are
compromised.
6. Worker Process to HSM *[NTL]*: - work to understand NTL is required, how
does it compare to TLS?
- Assets in flight: HSM Credentials(Partition), HSM Commands, Plaintext
Secrets, MKEK
- Credentials/Authentication: Each HSM connection has different credentials.
Credentials tied specifically to the FQDN of the worker process.
Certificate pairs generated on the HSM and installed into worker
processes. Site Crypto Officer / Crypto Officer creates certificates on
the HSM.
7. Worker Process->Certificate Authority (Dogtag)*[TLS]*:
- Assets in flight: CSR (uploaded by client or generated in Worker), Dogtag
credentials
- Note: All workers share the same set of credentials
8. API Process->keystone REST *[TLS]*: **TODO** - is this interface missing on
the diagram?
- Assets in flight: keystone credentials, Customer token
Resources
~~~~~~~~~
- https://wiki.openstack.org/wiki/barbican

BIN
doc/source/artifacts/barbican/newton/figures/barbican_architecture-diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 102 KiB

169
doc/source/artifacts/barbican/newton/review-findings.rst Normal file
View File

@ -0,0 +1,169 @@
=================================
barbican security review findings
=================================
barbican security review findings - 3.0.0.0b2/newton
----------------------------------------------------
**Status**: Draft
**Release**: Newton
**Version**: 3.0.0.0b2
**Review Date**: 08/18/2016
**Review Body**: OpenStack Security Project
**Contacts**:
- PTL: Douglas Mendizábal - redrobot
- Architect: Douglas Mendizábal - redrobot
- Security Reviewer: Robert Clark - hyakuhei
- Security Reviewer: Doug Chivers - capnoday
Findings:
---------
1. Modification of ACLs in barbian database could compromise all secrets
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: barbican has a feature that allows a tenant to grant another tenant
access to a secret. This is controlled via a tenant mapping table within the
barbican database. The implied security model of the barbican database (when
running with PCKS#11) is that all cryptographic operations are performed in
the HSM, a confidentiality or integrity breach of the database will not
directly result in secrets being compromised. However if an attacker was able
to modify the ACL mapping, they could grant a tenant access to any/all
secrets stored in the HSM. Once the mapping is manipulated the attacker could
retrieve secrets using the normal barbican API.
- Impact: All secrets stored in barbican are exposed.
- Likelihood: Medium
- Impact: High
- Overall Risk Rating: High
- Bug: <link to launchpad bug for this finding>
- Recommendation: Provide deployment guidance requiring strong controls
securing access to the barbican database.
2. Misconfigured HSM credential could cause DoS via HSM auto-purge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: A misconfigured or tampered barbican hardware security module (HSM)
credential could cause a denial-of-service of barbican (and potentially other
services using the HSM if it is shared), if the HSM is configured to purge
after a number of failed connection attempts.
- Impact: Denial of service to barbican, potential loss of all secrets if there
is inadequate backup, denial of service and potential loss of secrets for
other services sharing the HSM.
- Likelihood: Low
- Impact: High
- Overall Risk Rating: Medium
- Bug: <link to launchpad bug for this finding>
- Recommendation: Deployment guidance recommending that HSMs should not be
configured to auto-purge, unless this risk is actively managed via a security
event monitoring system. In this later case, consider adding a delay
period or auto backoff to barbican connection attempts to allow a SOC time
to respond.
3. Compromised HSM credential could cause DoS and all secrets (PKCS#11 only)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: When using PKCS#11 to connect barbican to a HSM, a compromised HSM
credential would allow an attacker to delete MKEK and HMAC keys, causing a
denial of service. If these keys were not backed up, all secrets would be
lost.
- Impact: Denial of service, loss of all secrets.
- Likelihood: Low
- Impact: High
- Overall Risk Rating: Medium
- Bug: <link to launchpad bug for this finding>
- Recommendation: Deployment guidance recommending that HSM credentials are
protected.
4. Compromised HSM credential lets attacker access all secrets (KMIP only)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: Although this review focusses on PKCS#11 barbican deployments, the
following KMIP finding was discovered during review and is included here for
completeness. When using KMIP to connect barbican to a HSM, a compromised HSM
credential allows an attacker to access all secrets stored in the HSM.
- Impact: Compromise of all secrets.
- Likelihood: Low
- Impact: High
- Overall Risk Rating: Medium
- Bug: <link to launchpad bug for this finding>
- Recommendation: Deployment guidance recommending that HSM credentials are
protected.
5. Metadata should be sanitized before rendering to avoid XSS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: Lack of sanitization of metadata could lead to cross site scripting
(XSS) vulnerabilities.
- Impact:
- Likelihood: Low
- Impact: Medium
- Overall Risk Rating: Medium
- Recommendation: Ensure future UI designers are aware of this risk and
sanitize all metadata before rendering.
6. Weak keystone credentials could result in loss of barbican users/secrets.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: An integrity failure of the keystone event queue credentials could
allow an attacker to point barbican at a keystone event queue controlled by
the attacker, the attacker could then publish events triggering deletion of
all users/projects/secrets in barbican.
- Impact: Soft deletion of all users/projects/secrets in the compromised
barbican deployment. Limited impact as there is time to restore deleted
data before the cleanup process runs.
- Likelihood: Low
- Impact: Medium
- Overall Risk Rating: Low
- Bug: <link to launchpad bug for this finding>
- Recommendation: Strong integrity controls for keystone credentials,
monitoring to detect mass deletion.
7. Compromised keystone credentials could lead to barbican admin compromise
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: If the keystone credentials for the barbican service account (for
token validation) have barbican admin privileges then a confidentiality
failure could allow an attacker to manipulate the barbican administration
functions.
- Impact: Compromise of secrets, DOS.
- Likelihood: Medium
- Impact: High
- Overall Risk Rating: Medium
- Bug: <link to launchpad bug for this finding>
- Recommendation: Do not grant barbican service account admin privileges
8. Compromise of PKCS#11 MKEK/HMAC backup could cause compromise of all secrets
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: Loss of confidentiality of the PKCS#11 MKEK/HMAC backup could allow an
attacker to decrypt all secrets in the barbican database.
- Impact: Compromise of all secrets
- Likelihood: Low
- Impact: High
- Overall Risk Rating: Medium
- Recommendation: Provide handling and encryption recommendations for MKEK/HMAC
backups.
Recommendations:
----------------
1. Provide best practice recommendations for HSM usage and operations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Recommendation: HSM security is outside the scope of this review (because it
is an external entity), but it is critical to the security of a barbican
deployment, so best practice recommendations should be provided for HSM usage
and security.
2. Document metadata useage
~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Recommendation: barbican metadata is not encrpyted, but users could store
confidential data there. barbican documentation should highlight this to
users.