Cloud infrastructure is not immune from the SolarWinds Orion breach

Organizations exposed to the SolarWinds breach must identify exposed credentials and rotate them asap.

Until now, much of the discussion around the SolarWinds breach that hacked FireEye and compromised US government networks has focused on on-prem risks; however, the cloud infrastructure of the impacted organizations is not necessarily immune. That's because the SolarWinds Orion platform can also be deployed in cloud environments, where it has privileged access to certain management functions and may hold AWS and/or Microsoft Azure root API keys.

To all looking into the SolarWinds Orion breach: Orion holds credentials, such as Domain Admin, Cisco/Router/SW root/enable creds, ESXi/vCenter Credentials, AWS/Azure/Cloud root API keys. and so much more. CONSIDER THESE CREDENTIALS COMPROMISED if you see other IOCs  pic.twitter.com/jPMppewWMs

— Rob Fuller (@mubix) 

Specifically, the threat to cloud infrastructure is expressed in several ways:

• Orion databases may store AWS and Azure API keys. This enables an attacker to take over and compromise these accounts.
• If deployed on AWS or Azure, Orion may have root API keys. This enables an attacker to have full admin privileges to the account that Orion is deployed on.
• Orion requires access to an identity and access management (IAM) identity. This potentially compromises -- and calls for treating as compromised -- the Orion IAM identity in your cloud environment.

Let’s take a look at the risks and counter measures to their mitigation.

API keys stored in the SolarWinds Orion database

The risk: SolarWinds Orion databases have been known to store many credentials, including AWS and Azure API keys. Attackers are able to extract and decrypt these credentials, potentially compromising anything stored in the databases. The interface does not actually display all stored credentials, making it difficult to track the extent of the exposure.

Counter-measures: Treat all stored credentials as compromised and rotate them. Cloud security researcher Rob Fuller (@mubix) released SolarFlare -- an open source tool for generating an actual full list of the credentials in your Orion database.

Root API keys to the account on which Orion is running

The risk: When deployed in a cloud environment, Orion may ask for root API Keys to the AWS/Azure accounts to which it is deployed. This potentially gives an attacker full access to the accounts. This is when least-privilege adoption can serve you well: if you deployed Orion in a separate standalone account, your risk exposure will be limited. If you have not, you should treat anything the account had -- or has -- access to as compromised.

Counter-measures: Depends on your specific configuration. Requires a sisyphic, manual review of each identity and resource to determine the extent of exposure and take appropriate action.

The identity that Orion uses within the monitored cloud environment

An Orion cloud deployment requires -- even in a least-privilege setup -- that you give Orion access to an IAM identity with limited privileges in the environment that it will be monitoring or managing. Assigning this IAM identity bears several risks:

Identity permissions

The risk: If you set up Orion to manage instances, the identity Orion uses has the permissions shown here:

While the primary risk is mass termination of instances, these permissions are overall rather reasonable and entail limited risk.

Counter-measures: Verify that Orion’s IAM identity has these permissions only. If you decide to suspend your use of Orion, remove that identity altogether or, at the very least, revoke its privileges.

Resource exposure, role chaining and network exposure

Resource exposure

The risk: Within a given AWS account, if a resource gives permission to be accessed in a resource-based policy, any principal in the same account as the resource can access the resource — even without an identity-based policy that allows access. For example, say you have an S3 bucket policy within your account (ID 123456789012), as below:

[Note: While the above example is widely recognized as inadvisable, we frequently see this type of policy in customer environments before Tenable Cloud Security deployment.]

Because of how AWS IAM policies work, the Orion IAM identity is able to access this bucket! This risk applies not only to S3 buckets, but to every resource that supports resource-based policies, such as key management service (KMS), secrets manager, Lambda and many others. This kind of resource risk is much more dangerous than typical public exposure risks because an identity within an account or organization is often more trusted so inadvertently given access to more resources.

Counter-measures: The only solution to this kind of risk is to enforce least privilege and control resource policies such that they don’t allow unintentional access for cross-account roles or identities that a third party vendor has the credentials for. Treat any such identified resource as compromised.

Role chaining

The risk: As in the case of resource-based policies, if a role’s trust policy allows certain identities to assume a role, any trusted identity within the account can assume that role — even without an identity-based policy allowing sts:AssumeRole for that role. If you’ve left any role open for AssumeRole while protecting it with only those conditions that the Orion IAM identity can meet, the attacker can escalate privileges to take those of the role. The second role’s privileges often open even greater avenues for privilege escalation.

Counter-measures: Take steps to enforce least privilege and control the trust policies of all roles such that they don’t allow unintentional access for third party roles or identities. Identify any potential role chain and treat it as compromised.

Network exposure

The risk: The ability to list EC2 instances and start instances that were stopped can allow an attacker to breach the organization’s virtual private cloud(s). The permissions assigned to the Orion IAM identity make it easier for an attacker to find and exploit EC2 instances exposed to the internet, causing potential risks:

• The attacker can escalate privilege to that given to the EC2 instance by the IAM instance profile
• The attacker can gain entry to one or more VPCs

Additionally, the attacker’s ability to start instances that were stopped could expose new risks. Did someone in the organization create a public EC2 instance with EC2FullAccess permissions to check something -- and later stop it without terminating it? The stopped instance can be restarted and used to enter the network and escalate privilege.

Counter-measures: Take steps to identify publicly exposed EC2 instances and the privileges they hold, and to protect them by ensuring least privilege and that only instances that absolutely need internet exposure are exposed.

Note that the above risks are fodder for compounded risk. To give just a few examples:

• An attacker can use a publicly exposed EC2 instance to assume a role protected by an IP condition to gain admin privileges in the environment
• An attacker can access a KMS key with a misconfigured resource-based policy to gain access to an open EC2 instance

In short, attackers can combine vulnerabilities in countless ways to gain privileged access to an account and the organization.

Tenable identifies and remediates vulnerable access entitlements

To sum up: First, identifying all exposed credentials and rotating them should be the top priority of any organization exposed to the SolarWinds breach. Second, if your Orion deployment was not on an account completely separate from your environment, consider everything the account touches as compromised. This is because many resources and identities, even though exposed, continue to be connected to the cloud.

Your cloud environment is, in fact, vulnerable to many additional risks stemming from the use of the reasonable yet vulnerable Orion IAM identity. Unfortunately, when it comes to visibility of third party role permissions, AWS IAM tends to be less than transparent. It is hard to identify which resources and roles a principal has access to, and to monitor access to resources, detect publicly exposed EC2 instances and control the privileges they hold and, in general, maintain total visibility of cloud privilege.

Tenable Cloud Security can help identify exactly which resources a compromised third party role or identity has access to across the cloud infrastructure and provide automatic remediation to ensure that all third-party roles or identities in the account have only the access they need. This enables an organization to both manage any risks from the current breach and, critically, mitigate the risks of breaches yet to come.