Towards the end of the year I read a top-10 list of cloud security threats for 2019 and it had me thinking about the Cloud Security risks that people are not talking about. I can’t find that original list, and I’ve been sitting on this post for the last two months.
So with out further ado, here is my take on cloud security risks you’re not reading about in the press. These aren’t presented in any order.
1. Accounts not owned by your company
Do you know what email addresses have created all your cloud accounts? AWS will only talk to the root user on the account. If that account isn’t in your domain, you could lose control of that AWS account and have to engage a lengthy process with AWS’s legal department. In fact, if you are using organizations, you cannot even detach an AWS account if you cannot login to it (to set billing, contacts and accept some agreements). Basically, if that account was registered with an employee’s personal address and that employee is no longer with the company, you cannot even detach it from your bill.
In Azure, Subscriptions are part of an Account and that account can be either an Azure AD or Microsoft Live user. Do you know which one your subscriptions use? And if you terminate the employee who owns the subscriptions, what happens? I’m not brave enough to test that.
With GCP, someone can name an organization they control similar to your organization, then invite your users to that rogue organization. Your users can get confused and create confidential resources in that rogue organization. This was submitted to the Google Vulnerability Program, resolved and a bounty paid.
2. Cloud Identities not owned by your company
There are also issues with Cloud Identities - the accounts your employees use to login to your Azure Subscriptions and Google Projects (IAM Users in AWS don’t have this issue). With Azure, it is easy to invite any Microsoft (Live) account to join the AzureAD domain. From there these users can be granted access to Subscriptions.
If your Google domain is not set correctly, your Google identities could be consumer identities which are not owned or controlled by your organization. Go ask Google for a list of Google Consumer Identities that use your company’s domain. Since those identities aren’t part of your enterprise, Google won’t tell you.
3. Cloud Accounts trusted by your company
Do you know who you trust? We mentioned that AzureAD can add other Microsoft Live or AzureAD users to your domain. Based on the GCP Organization trick above, you can easily invite entire domains to your organization. AWS allows you to trust other accounts. This trust can be via IAM Assume Roles, S3 Bucket Polices and AMIs you launch. If you see a strange 12 digit account trusted by your organization, what do you think the chances are that AWS will tell you who owns it?
Scott Piper did an excellent write up of this.
4. Cloud-to-ground compromise
In AWS, there are three common permissions that are granted to most developers that can grant that user full root access to any EC2 Instance. An attacker can add a simple reverse netcat shell to the instance’s user data with the ec2:ModifyInstanceAttribute API call. They then just need to stop and start the instance for that reverse shell to be executed as root.
5. Azure AD
Azure has two “features” that cloud security folks should know about. First, anyone with an AzureAD account (ie any O365 User) can access https://portal.azure.com. From there, even if they have no access to any Azure Subscriptions, they can still view all the attributes of your AD. Combined with an AD account compromise, and an attacker doesn’t need to be on your network to enumerate your full AD.
6. Azure Storage Keys
The other “feature” is Azure Storage Keys. Unlike AWS keys they are created by default and cannot be deleted (only rotated). They are also visible by most users in the subscription. You can leverage them to access any date in the storage account, and since most subscription users would have had access to view the keys at any point, attribution will be hard at best.
7. Endpoint Security
With Google and Azure, novice users of the API are encouraged to use cloud-shells which are authenticated via the normal web-based login process (which has MFA right?). With AWS, API authentication uses an Access Key and Secret Key that are kept unencrypted in .aws/credentials on the user’s laptop. Any malware that can encrypt a file could just as easily send these keys to an attacker.
8. De-segmentation
One of key security controls you can have is to segment your networks & application environments. Until recently AWS enforced segmentation via strict boundaries of the AWS account and the inability to share VPCs. In response to both Google and Azure supporting cross Project/Subscription VPCs, AWS has started to blur that line. VPCs can be shared between accounts, and Transit Gateway is a service from AWS allowing you to link all your VPCs. Transit Gateway doesn’t offer a method to inspect of filter the traffic.
9. Hijacked or Hijackable Cloudfront & Route 53 Aliases
S3 has a global Name space. I can go and create the S3 bucket “downloads.your-company.com” and put whatever malware I want in there. There is no risk to you in me creating that bucket. Unless of course you had once configured your Route53 Zone or CloudFront Distribution to point to that bucket then deleted the bucket (without deleting the Route53 Alias or Cloudfront origin). If I’m crawling your site and find a de-referenced origin, I can recreate the origin under my control. You will then happily point your customers or users to my content.
10. Creds in UserData & Lambda & VPN
The default ReadOnlyAccess policy can grant an attacker a great deal of knowledge of an AWS account. Three places they can get access to secrets are EC2 UserData, Lambda Code packages and VPN configurations defined as CustomerGateways.
Teri Radichel described this trick in her re:Invent session. With minimal permissions to an AWS account, an attacker can download the Lambda deployment package and look for baked-in credentials or code vulnerabilities.
aws lambda get-function --function-name YOUR-FUNCTION_NAME --query Code.Location
The output of that command is a pre-signed S3 URL you can curl from anywhere and run through dumpster diver or trufflehog.
Prior to the introduction of Secrets Manager and Parameter Store before it, developers would often bake credentials into the UserData file that is passed into the instance from the EC2 service at launch. ReadOnlyAccess gives you access to the DescribeInstanceAttribute API which can be used to download the Userdata for the instance.
Finally, the DescribeVpnConnections call will return an XML document in CustomerGatewayConfiguration that contains the on-prem VPN IP address and shared secrets.
Conclusion
Some of these threats are limited in scope and somewhat theoretical. After all, if we’re not hearing about them in the news, they must not be commonly exploited. But then again, it didn’t take long from the disclosure of the first open AWS ElasticSearch cluster to reading about regular discoveries of open ES and MongoDB databases in cloud and on-prem.