Orion solarwinds api
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.Ĭounter-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. For example, say you have an S3 bucket policy within your account (ID 123456789012), as below:īecause 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 KMS, Secrets Manager, Lambda and many others. 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. Resource exposure, role chaining and network exposure Resource exposure If you decide to suspend your use of Orion, remove that identity altogether or, at the very least, revoke its privileges. While the primary risk is mass termination of instances, these permissions are overall rather reasonable and entail limited risk.Ĭounter-measures: Verify that Orion’s IAM identity has these permissions only. The risk: If you set up Orion to manage instances, the identity Orion uses has the permissions shown here: Assigning this IAM identity bears several risks: Identity permissions The identity that Orion uses within the monitored cloud environmentĪn 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.
Orion solarwinds api manual#
Requires a sisyphic, manual review of each identity and resource to determine the extent of exposure and take appropriate action. If you have not, you should treat anything the account had - or has - access to as compromised.Ĭounter-measures: Depends on your specific configuration. This is when least-privilege adoption can serve you well: if you have deployed Orion in a separate standalone account, your risk exposure will be limited.
Orion solarwinds api full#
This potentially gives an attacker full access to the accounts. 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. Root API Keys to the account Orion is running on Cloud security researcher Rob Fuller ( has released SolarFlare - an open source tool for generating an actual full list of the credentials in your Orion database. The interface does not actually display all stored credentials, making it difficult to track the extent of the exposure.Ĭounter-measures: Treat all stored credentials as compromised and rotate them. Attackers are able to extract and decrypt these credentials, potentially compromising anything stored in the databases. The risk: SolarWinds Orion databases have been known to store many credentials, including AWS and Azure API keys. API Keys stored in the SolarWinds Orion database Let’s take a look at the risks and counter measures to their mitigation. This potentially compromises - and calls for treating as compromised - the Orion IAM identity in your cloud environment. Orion requires access to an IAM (Identity and Access Management) identity.This enables an attacker to have full admin privileges to the account that Orion is deployed on. If deployed on AWS or Azure, Orion may have root API keys.This enables an attacker to take over and compromise these accounts. Orion databases may store AWS and Azure API keys.Specifically, the threat to cloud infrastructure is expressed in several ways: CONSIDER THESE CREDENTIALS COMPROMISED if you see other IOCs #SunBurst /jPMppewWMs 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. 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. However the cloud infrastructure of the impacted organizations is not necessarily immune. Until now much of the discussion around the SolarWinds breach that hacked FireEye and compromised US government networks has focused on the on-premise risks.