Product Security
The BastionZero product is maintained for existing BastionZero customers only.
Moving forward, we are natively rebuilding BastionZero’s technology as Cloudflare’s Access for Infrastructure 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 Google Authenticator App.
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.
In late 2020, the SolarWinds 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 Diginotar and Comodo. As a result of these attacks, the modern TLS ecosystem no longer relies on blindly trusting certificate authorities.
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.
MrZAP is an open-source cryptographic protocol, and its full specification is available here.
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:
The message is signed by a key in a valid BastionZero token.
The message is in response to the last message the target sent.
The message is intended for that target.
The corresponding BastionZero token is validly signed by the target's SSO provider AND by the BastionZero cloud service.
For a deeper look at MrZAP, take a look at the full protocol here.
Last updated
