The Amazon Spheres in Seattle. Some Amazon AWS API keys are potentially threatened by the SolarWinds supply chain hack. (Joe Mabel, CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons)

The SolarWinds Orion supply chain hack endangers Amazon Web Services and Microsoft Azure API keys and their corresponding accounts, a security blog post from identity and access security company Ermetic has warned, reminding readers that this game-changing incident risks not just organizations’ on-premises systems but also their cloud-based infrastructure.

Additional experts similarly confirmed to SC Media that the SolarWinds threat poses a valid threat to cloud-based services, and recommended a series of counter responses, including rotating credential, instituting least privilege protocols, and deploying Orion on standalone accounts isolated from all other cloud-based resources.

“In the cloud, there is a shared responsibility for security. Just because someone else owns the hardware doesn’t mean you get a pass on securing and monitoring what you have up there,” said Travis Smith, director of malware threat research at Qualys.

If the SolarWinds attackers – presumed to be Russian intelligence agents – were able to extract and decrypt API keys from any compromised Orion databases, they could subsequently gain access to the related cloud-based services, wrote Noam Dahan, senior security researcher at Ermetic, on his company’s website. Moreover, Orion software that’s deployed in AWS or Azure environments may use root API keys that would give attackers comprehensive administrative privileges for any compromised accounts.

“The concerns raised in the post are absolutely valid issues that security teams should be looking into,” said Tim Bach, vice president of engineering at AppOmni. “As cloud and cloud-integrated systems are deployed, they frequently connect to each other via service accounts, API integrations, OAuth tokens, etc. And these connections are cloud-to-cloud, not mediated by an internal networks. This means that many of the tools security teams may be using to monitor their clouds (e.g. CASBs) will not have visibility into activity.”

Companies should take steps to make credential changes and identify all exposed credentials. But there’s a problem: the Orion interface “does not actually display all stored credentials,” which complicates efforts on the part of affected companies to “track the extent of the exposure,” said Dahan.

If Orion is deployed on an account that isn’t fully isolated from the rest of the cloud environment, then organizations must “consider everything the account touches as compromised,” Dahan wrote. “This is because many resources and identities, even though exposed, continue to be connected to the cloud.” Likewise, any part of a cloud environment that uses Orion IAM identity must also be considered a threat, because compromised IAM identities could allow attackers access to sensitive resources (e.g. S3 buckets, KMS, Secrets Manager, Lambda, etc.) or roles – even ones that are subjected to trust policies.

That why Ermetic recommends companies conduct place tighter controls on internal access policies and also conduct a “manual review of each identity and resource to determine the extent of exposure and take appropriate action.”

Meanwhile, Bach said it’s important for organizations to “understand the interconnectedness of their IaaS and SaaS cloud services and recognize that breaches like the SolarWinds one may not be limited to a single service or vendor by virtue of this interconnectedness. Security teams need to also understand what access to data and capabilities service accounts, tokens, and integrations have in other clouds. If a breach results in the compromise of integration accounts, those integration accounts may be used to exfiltrate data or create residency on other, totally unrelated services like a customer database or a version control system.”

In his post, Dahan’s contended that so far “much of the discussion around” the SolarWinds incident has been centered on on-premise risks. But Smith at Qualys, said he doesn’t believe the cloud-based implications have been overlooked. For starters, he noted, the Microsoft Threat Intelligence Center has “released detections to hunt for activity based on the SolarWinds breach within Azure.”

Such a move is prudent. After all, “an adversary as sophisticated as this would not only target organizations who leverage cloud-based services, but have the desire to pivot into their cloud assets to achieve their ultimate goals,” Smith added.

Ultimately, it comes down to understanding the adversary’s true impact to determine just how much of a danger this scenario represents.

“At this point the malware has been cut off from executing, due to the C2 domains being taken over, so the focus is on looking back for evidence of activity,” said Smith. “There are a lot of indicators of compromise already available to look for artifacts within your organization: files, services, network traffic, etc. If an organization is concerned about the impact of an attacker pivoting to their cloud environment, the first step would be to understand what, if any, credentials the Orion service stored. Beyond that, auditing all access to the cloud and rotating any impacted keys and/or passwords will become very high priority.”

Jim Reavis, CEO of the Cloud Security Alliance, said his organization recommends visualizing cloud “as a layered model” because it is “helpful in uncovering different vendors and technologies that are mashed up to create… business app[s] and examining whether the appropriate security measures are in place for each layer. Businesses absolutely need to know which cloud IaaS providers their vendors are using and how they are configured to identify the threats most relevant to that business. The CSA Security, Trust, Assurance & Risk program is an excellent way to examine how vendors secure their cloud systems and customers should demand this level of transparency from their technology partners.”