SolarWinds: Between The Clouds

The SolarWinds breach is THE hot talk these days around the security industry. First disclosures by FireEye and US government networks were all about on-premises risks, and the Microsoft blog also took a deep dive into the “guts” of the attack, its malicious DLL, the C2 communication and its DGA. 

But the cloud security aspect needs to have its focus, too. 

An attacker located in a compromised server, hosting the Orion platform, will try to harvest any piece of information they can, to allow themselves to get as close as possible to the attack objective. 

Whether the SolarWinds Orion platform is deployed on an on-premises machine or in a cloud environment, it might hold more than just the vulnerable instance and some passwords. Both deployment options require permissions to the cloud environment to manage its resources, as described in the SolarWinds documentation for Azure Cloud, or AWS Cloud. 

This blog post will take you to the attacker’s point of view, between two clouds – Azure and AWS. 

Exploiting SolarWinds’ Access Permissions 

Let’s have a closer look at the access permissions the Orion platform has and how an attacker can leverage these permissions to their advantage. 

The Azure IAM permissions setup instructions clearly state: 

If you select Contributor, well, you do have these abilities… 

Looking more closely at the AWS permissions granted to the Orion platform, which can manage instances in your AWS account, we can see here it has the following AWS Policy: 

The obvious API and more “scary looking” one might be “ec2:TerminateInstances,” which might wreak havoc in the environment when it’s… well…terminating important instances. That alone can cause considerable damage, such as with Cisco’s case published last month. 

Others might assume, “what do I care about existing machines? All systems are working and configured well, let’s move on with the installation.”  

Wrong assumption. Granting third parties access permissions to your account needs to be taken with very special care. 

[You may also like: Excessive Permissions are Your #1 Cloud Threat]

A skilled attacker can achieve a lot with a bit of luck, cloud API knowledge, and some excessive permissions granted to company resources. 

Each compromised server might hold its own unique set of permissions, available for the attacker to meet its needs: Files, Passwords, Backdoors, Databases, and more. Whatever the attacker finds, will be used one way or the other to advance the attack. 

So, let’s assume we deployed a compromised version of the Orion platform on an AWS instance, allowing it to access our AWS cloud and manage its cloud resources for us with the permissions seen above. 

[You may also like: When It Comes to Cloud Security, Least Privilege Takes Precedent]

In the examples below, we assume the attacker is skilled enough to have exploited a vulnerability existing on the virtual machine and can log in or perform RCE. 

What are the actions an attacker could perform using these “innocent looking” permissions to our account? 

I’m an attacker and I have found a stopped EC2 instance with the “AmazonEC2FullAccess” policy attached. What happens if I start it? 

AmazonEC2FullAccess – EC2:* 

Amazon’s managed policy of AmazonEC2FullAccess allows full access to all EC2 APIs, which makes the game quite easy for an attacker. It’s one of the holy grails of permissions, which can lead to pretty much any action an attacker might want to take. Here are few examples: 

• Show me the money! – Crypto mining 

Well, the most obvious choice here, when dealing with other people’s compute power to pay the bill, will be to make some money. Using the ec2:RunInstances API to spin up as many machines as needed, as powerful as needed, to whatever cryptocurrency chosen, will yield a nice profit, especially lately when BTC price breaks new records.  

• Sharing is caring – Resource sharing 

After dealing with making direct profit, our attacker might also want to browse around, and look for some “hidden gems.” 

Using the API ec2:ModifyImageAttribute, an attacker can pick an existing Amazon Machine Images (AMI) on the compromised account, make it publicly available, get to their own account, and spin up a new instance from this “stolen” image. 

[You may also like: Eliminating Excessive Permissions]

This image might hold more sensitive content, in the form of other AWS account credentials, passwords, and important or confidential files left on the image. 

The same approach can be achieved when looking at EC2 EBS Snapshots. Using CreateSnapshot or ModifySnapshotAttribute EC2 API calls, an existing snapshot can be made public, or created from a running machine, and used from the attacker’s own account, to browse around for more information. 

I’m an attacker and I have found a stopped EC2 instance with the “AmazonS3FullAccess” policy attached. What happens if I start it? 

AmazonS3FullAccess – S3:* with Resource: * 

Amazon’s managed policy of AmazonS3FullAccess allows full access to all S3 APIs, including access to all data stored in S3 buckets! 

This AWS managed policy does not have any “obstacles” on its way – you can get anything, everywhere! Not specific buckets or paths, all of them! 

No Bucket is safe, and as an attacker, you can gain any data you want, from any bucket you want. 

[You may also like: Protecting AWS Assets: A Case Study]

This is one of the most important places to look if you are seeking some PII. 

But not just existing information is important. The attacker also can store files, or even modify existing files (download, modify, upload) hosted on these buckets. These files can cause considerable damage, such as changing the content of a webpages hosted on S3, or similar case to this example of modifying a malicious DLL such as the case of the SUNBURST backdoor in Orion software. 

I’m an attacker and I have found a stopped EC2 instance with the “AmazonRDSFullAccess” policy attached. What happens if I start it? 

AmazonRDSFullAccess – RDS: * 

Amazon’s managed policy of AmazonRDSFullAccess allows the attacker full access to all RDS APIs and can hold some serious implications to data stored in databases. Here are few examples: 

• Sharing is caring – Snapshot sharing 

Existing RDS snapshots can be modified to be publicly accessible, using the API rds:ModifyDBSnapshotAttribute, will allow an attacker access from their own AWS account to this snapshot. An attacker will then create a new database from the snapshot, to see the data in their account, without performing any suspicious actions in the original compromised account. 

• What is your PaS$W0rd? – Master password change 

Gaining access to existing RDS instance or cluster needs a password to login. 

Instead of endlessly trying different well-known passwords, the attacker can simply modify the existing password. Using the API ModifyDBInstance or ModifyDBCluster with the argument of MasterUserPassword allows the attacker to change the password as needed, and allow a connection and queries to be made to the DB. 

[You may also like: Malicious Bots Have Realized Your APIs Are the Weak Link]

Exploiting Access Permissions Stored in Orion 

After dealing with exploiting the access permissions granted to the Orion platform itself, let’s also discuss what an attacker can find in the Orion database and how this information can be further leveraged. 

The Orion database may store credentials to additional systems and environments, including AWS and Azure API keys. These can include some very powerful keys, allowing privileged access to databases, storage repositories or even to Identity and Access Management (IAM) services.  

For example, imagine an AWS user with the AdministratorAccess AWS policy whose access key is stored in the Orion database. 

Looking at the AWS policy of “AdministratorAccess,” we see it has only a single “Action”: “*”, which translates to “Use any API, on every service and on any resource.” 

One can only imagine what can be done with such permissions, as opposed to the stricter permissions of Orion’s deployment, or the service-specific examples given above. An attacker with these powerful permissions will have access to all the account’s data and services. ALL! Full account control! Pretty intimidating, don’t you think? 

Recommendations/What You Can Do Now 

We could go on and describe additional attack scenarios enabled by the Orion breach, but let’s talk about what can be done about them. 

There are several ways in which organizations can get better protected against the risks introduced by the SolarWinds supply chain attack:  

Visibility – Understanding what assets exist across your cloud environments is crucial. 

• Make sure your security monitoring tools and logging mechanisms cover all your cloud accounts, across all locations and cloud vendors. 
• Beware of the virtual machines, storage repositories, snapshots and other resources that are publicly accessible from the internet. Make sure this is authorized and by design. 
• Identify and decommission stale or unused resources that might run unpatched software.  

Excessive access permissions – Make sure you follow the Least Required Privilege Principle by revoking excessive permissions granted to IAM (Identity and Access Management) entities operating in your accounts. 

• This includes human and non-human users, compute roles that can be attached to virtual machines and serverless functions, cross-account roles that allow access to your accounts from third parties, as well as federated roles used for user authentication by external Identity Providers. 
• Revoke permissions from IAM entities with IAM policies that allow full *:* administrative privileges on all resources. 
• Immediately revoke access for any terminated users. In addition, revoke access for users who have been completely inactive for a long time.  

[You may also like: FireEye Hack Turns into a Global Supply Chain Attack]

Threat detection – Monitor logs and security events happening in your cloud accounts to identify unusual and potentially unauthorized activity in a timely manner. 

• Analyze the behavior of both human and non-human users, as well as the activity done by all types of roles – from compute roles to cross-account and federated roles. 
• Ensure alerts upon detection of suspicious activity are delivered to the relevant responsible personnel. 

Authentication – Ensure proper user identification.  

• Enable multi-factor authentication for users with Console access and for the root user. 
• Remove access keys associated with the root user account. 
• Rotate access keys periodically to ensure data cannot be accessed with an old key which might have been lost or compromised. 

Logs – Critical for security analysis, resource change tracking and incident investigation. Make sure your AWS and Azure logs are properly configured and enabled in all locations.

• This starts from cloud activity logs like AWS CloudTrail or Azure Activity Logs which record API calls to the cloud platform, as well as network traffic logs like AWS VPC Flow logs and Azure NSG Flow logs.  
• Secure the logs so they cannot be altered.  
• Put an alarm on attempts to turn the logs off. 

Securing your cloud workloads and data is critical in these exceptional times. With Radware’s Cloud Native Protector service you can get better protected against the risks introduced by the SolarWinds attack, and:  

• Ensure your IAM (Identity and Access management) follows security best practices  
• Reduce attack surface by detecting and remediating users and roles with excessive IAM permissions  
• Improve your visibility into the cloud activity and resources across all your cloud environments 
• Ensure your logging configuration is correct to get a better visibility of your public cloud 
• Detect network and cloud native attacks  

Leo Reznik, Product Manager for Radware’s Cloud Native Protector service, contributed to this article.