LogoLogo
Main SiteStart Now
  • Home
    • What Is BastionZero?
      • Server Access
      • Database Access
      • Kubernetes Access
      • Web Server Access
    • Product Security
    • Architecture
    • Taxonomy
  • Deployment
    • Getting Started
    • Installing the ZLI
    • Installing the Agent
    • Installing the Desktop App
  • Automation & Integrations
    • CircleCI
    • GitHub Actions
    • Go SDK
    • Google Cloud Run
    • Slack
      • Using the BastionZero app for Slack
    • Terraform
    • Third-Party Clients
  • Admin Guide
    • Authentication
      • SSO Management
      • User Management
      • MFA Management
      • Service Accounts Management
    • Authorization
    • Auditing
    • Target and Connection Management
  • How To Guides
    • Passwordless Database Access
      • Passwordless Access to MySQL and Postgres on GCP Cloud SQL
      • Passwordless Access to AWS RDS PostgreSQL
      • Passwordless Access to AWS RDS MySQL
      • Passwordless Access to Self-Hosted Postgres
    • How to use BastionZero to connect to a Linux Host using the ZLI
    • How to use BastionZero to manage SSH Keys
  • User Guide
    • Installing the ZLI
    • ZLI Cheat Sheet
    • Connecting to Your Targets
    • Troubleshooting Guide
  • ZLI Reference Manual
  • API Specification
  • Getting Help
  • Security Policy
  • Open Source Software Credits
    • Backend Services
    • Bzero Agent
    • Client Daemon
    • Desktop App
    • Go SDK
    • Helm Provider
    • Terraform Provider
    • Web App
    • ZLI
  • Product Changes
  • Service Status
  • GitHub
Powered by GitBook

Copyright © 2024

On this page
  • The Basics of Zero Trust Security
  • BastionZero’s Unique Model of Zero Trust
  • The Problem with Traditional Zero Trust
  • BastionZero’s Security Model
  • How MFA Works with BastionZero
  • BastionZero’s MrZAP Protocol
  1. Home

Product Security

PreviousWeb Server AccessNextArchitecture

Last updated 6 months ago

The BastionZero product is maintained for existing BastionZero customers only.

Moving forward, we are natively rebuilding BastionZero’s technology as Cloudflare’s service.

BastionZero is a cloud service that provides zero trust remote access to infrastructure. Our unique security model means that any compromise of our cloud service does not lead to a compromise of your infrastructure targets. Simply put, our security model eliminates single points of compromise in your infrastructure.

In the next sections, we will explain the basics of zero trust security. We then discuss BastionZero’s security model and why it allows us to offer zero trust access as a cloud service without creating single points of compromise.

The Basics of Zero Trust Security

Zero trust access simply means that clients that access infrastructure targets do not have any standing credentials. That is, clients don’t hold any long-lived keys, credentials, or tokens.

In a zero trust model, each time a client wants to access a target, the client must first prove its identity via SSO authentication and MFA. The client is then issued a short-lived token that allows for access until the token expires.

The use of short-lived tokens improves security because it reduces the risk that a compromise of the client leads to a compromise of infrastructure targets. For example, in 2001, the Fluffy Bunny hacking group replaced SSH clients with a malware that exfiltrated long-lived SSH credentials and then later used those credentials to log into targets, execute a local privilege escalation attack, and repeat. A zero trust approach would have limited this attack surface because even if the attacker could exfiltrate short-lived tokens, these tokens would expire before the attacker could use them to compromise any targets.

The use of short-lived tokens also reduces the risk that users will walk away with long-lived credentials (like SSH keys) when they leave the organization or mistakenly leak those credentials to attackers.

MFA plays an important role in any zero trust approach. MFA ensures that if the user’s SSO username and password are compromised, their authentication remains secure as long as their MFA is not also compromised. BastionZero uses the Time-based One-time Password (TOTP) protocol for MFA, which can be set up using a variety of authenticator applications, such as the .

When TOTP is used for MFA, it validates that the user really is in possession of the device (e.g., a phone) where the authenticator app is installed. MFA would have prevented the Fluffy Bunny attack because even if the attacker had stolen a victim’s username and password, the attacker would also need to physically steal the MFA device (phone) in order to impersonate the victim.

BastionZero’s Unique Model of Zero Trust

BastionZero offers zero trust remote access as a cloud service. We’ve gone to great lengths to ensure that our cloud service does not become a point of compromise for your infrastructure targets.

In this section, we explain why traditional approaches to zero trust remote access can create grave risks by becoming a single point of compromise. We then explain why and how BastionZero’s security model avoids these pitfalls.

The Problem with Traditional Zero Trust

In a traditional zero trust approach, the focus is on eliminating long-lived credentials held by users or clients. Usually, this is done by introducing a single, centralized root-of-trust that is given the power to determine which user has properly authenticated into the system. In other words, instead of giving long-lived credentials to each individual user or client, all the long-lived credentials are stored in one place — the centralized root-of-trust.

If we put all credentials in a single centralized root-of-trust, that root-of-trust becomes a single point of compromise. Attackers are incentivized to attack this centralized root-of-trust because all the credentials are stored there. If the attack is successful, the attackers own all of the infrastructure targets that rely on this centralized root-of-trust.

Architectures that rely on a centralized certificate authority (CA) are present in a variety of commercial solutions including:

  • Solutions that use certificate authorities to issue short-lived zero trust credentials.

  • Solutions that rely solely on SSO systems to determine who has access to targets.

  • Solutions that use a self-hosted bastion host or proxy to determine who has access to targets.

It is important to note that MFA alone does not prevent these attacks. In most commercial products that use MFA, the MFA is checked by the centralized root-of-trust (for instance, the SSO or the CA). But if the centralized root-of-trust is compromised, it does not matter if it is checking MFA because the attacker can still issue tokens to access whatever target it wants.

BastionZero’s Security Model

BastionZero uses multiple independent roots-of-trust to control access to your targets. This eliminates single points of compromise because if one root-of-trust is compromised but the other root-of-trust is not, then your targets remain secure.

With BastionZero, one of the roots-of-trust is our cloud service. The other root-of-trust is your SSO provider.

Accessing a target in your infrastructure requires authorization from both the BastionZero cloud server AND your SSO provider. Notice that this reduces your attack surface because it is very unlikely that both our cloud service AND your SSO provider could be compromised simultaneously.

To access a given target, the client must present the target with a short-lived BastionZero token that is cryptographically signed both by the SSO provider and the BastionZero cloud service. The two cryptographic signatures on this token are validated directly by the BastionZero agent, using the public key of the user's SSO and the public key of the BastionZero cloud service.

Because two independent cryptographic signatures are required to access any target, this security model eliminates the single point of compromise created by traditional zero-trust solutions.

How MFA Works with BastionZero

BastionZero uses MFA to separately authenticate each user to each of the two roots-of-trust. That is, the user performs an MFA to the BastionZero cloud service that independently authenticates her to BastionZero. Meanwhile, the user performs an SSO to authenticate to her SSO provider, which independently authenticates her.

This prevents the SolarWinds attack we described earlier. As we discussed, a compromise of the SSO provider would not compromise infrastructure targets because the user must authenticate using MFA to an independent, second root-of-trust: BastionZero, before she is granted access to any targets.

BastionZero’s MrZAP Protocol

BastionZero uses MrZAP, a multi-root, zero-trust protocol to control access to infrastructure targets.

Messages transmitted between clients and targets flows through the BastionZero cloud service so that the BastionZero cloud service may log these messages. The MrZAP protocol ensures that the BastionZero cloud service cannot tamper with these messages.

With MrZAP, each time a user Alice logs into BastionZero by completing an SSO and MFA, she chooses a fresh cryptographic key that she stores locally on her machine. This is a short-lived key that is deleted once her login expires. As part of the login, Alice’s key is signed (in the BastionZero token) by the two roots of trust: the BastionZero cloud service and the SSO provider. Alice then uses her key to sign all her messages. Because messages are signed, this ensures that BastionZero’s cloud service cannot tamper with Alice’s messages or inject its own commands to her targets. These messages are also arranged in cryptographic hash chain, to prevent the BastionZero cloud service from reordering the messages.

For each message the target receives via MrZAP, the target validates that:

  1. The message is signed by a key in a valid BastionZero token.

  2. The message is in response to the last message the target sent.

  3. The message is intended for that target.

  4. The corresponding BastionZero token is validly signed by the target's SSO provider AND by the BastionZero cloud service.

In late 2020, the attackers exploited this type of architecture to compromise the SSO in their victim’s networks and then used the compromised SSO to issue tokens to themselves that allowed them to access any target in the victim’s infrastructure.

There is also a long history of attacks on certificate authorities, including the 2011 compromises of and . As a result of these attacks, the modern TLS ecosystem on blindly trusting certificate authorities.

MrZAP is an open-source cryptographic protocol, and its full specification is available .

For a deeper look at MrZAP, take a look at the full protocol .

Access for Infrastructure
Google Authenticator App
SolarWinds
Diginotar
Comodo
no longer
relies
here
here
Diagram of the traditional security model with a single root-of-trust
Diagram showing BastionZero's multi-root security model
Diagram of the flow among client, BastionZero, targets, and SSO provider