82% of companies unknowingly give 3rd parties access to all their cloud data

Cloud identity permissions are complex. So complex, that innocent looking permissions provided to 3rd party vendors can lead to unintended exposure of all of your data. The Wiz Research team conducted extensive research of permissions provided to 3rd party vendors in cloud environments and the results should be a wake-up call:

• 82% of companies provide 3rd party vendors highly privileged roles
• 76% of companies have 3d party roles that allow for full account takeover
• Over 90% of cloud security teams were not aware they gave high permissions to 3rd party vendors.

In the majority of cases these permissions are there for no reason: the vendor doesn’t actually need them, and the customer team isn’t even aware that they gave them to the vendor. The most common example is the AWS ReadOnlyAccess policy, which is extremely popular amongst 3rd party vendors (a default for 25% of vendors included in our research). Vendors and customers believe it’s a harmless policy, but instead it provides wide read access to many of your databases, DynamoDB, S3 buckets, SQS queues, and more. Wondering why any vendor would need permissions this broad? Well, they don’t.

In the aftermath of the SolarWinds attack and the Mimecast certificate breach, the status quo needs to change. Security teams need to focus on “Minimizing the risk of 3rd parties in your cloud environment”, because it provides room for a supply chain attack and can even lead to compliance risks. Reducing the permissions provided to 3rd parties is an immediate call to action for the industry and a shared responsibility between customers and vendors alike. Customers should be proactive and scrutinize every requested permission, while vendors should understand that “Less is More”. Less permissions means less liability, whereas too many permissions could mean they’re next in line to becoming a target for adversaries.

Lets dive into the numbers!

We did extensive research across more than 1,300 AWS accounts, analyzed the 40+ most popular 3rd party vendors, and looked for potential escalation paths and unused permissions. Although the data is AWS-focused, the risks we discuss are cross-cloud, because we are seeing similar issues in Azure and GCP. This research focuses on direct exposure via IAM roles.

Everyone uses 3rd party vendors

Our data shows that only 4% of organizations don’t have any 3rd party apps in their environment. This means that the risk of excessive exposure matters for almost all cloud-run organizations. The average number of 3rd party vendors with external IAM roles is 5.2.

Breakdown of the top vendors

We evaluated more than 40 vendors and took a close look at the default permissions they request once integrated. Below is an overview of the top categories and 20 key vendors across them:

Analysis of highly privileged roles

Each role was evaluated based on the default permissions we detected across multiple environments. This helped avoid false positives caused by misconfigurations of specific customers. We ran the roles through our identity analysis engine that computes effective permissions and takes the following into account:

• Privilege escalations paths
• Permission boundaries
• Deny statements and NotActions
• Advanced AWS constructs like conditions and SCPs

AWS has around 250 different services with ~9000 different permissions. Our analysis engine takes known privilege escalation paths into account to determine effective permissions. For example, ec2:createInstances with IAM:PassRole leads to a privilege escalation because the role owner can create an ec2 instance with a powerful IAM role.

Across the vendors we analyzed, we found that:

• 76% of organizations had at least one application that allows for complete account takeover. This type of access should be reserved for select and closely monitored roles and never be granted as part of a default setup of a 3rd party vendor.
• 15% of vendors receive extensive write-permissions that allow them to modify active cloud resources. In most cases, the access could have been restricted.
• 82% of all organizations give 3rd parties wide read access within their environment. This is a major risk to sensitive data leakage and may pose both a security risk, as well as serious privacy risk.

This is just a small subset of examples that highlights why closely monitoring your supply chain matters. The potential impact of a secondary attack if any of these vendors were to be compromised can range from leaked sensitive data, all the way to giving away the keys to your kingdom.

Deep dive: Common privileges that lead to unintended exposure

The AWS Identity system is so complex that most customers don’t understand what permissions they provide to their vendors. When we showed our own customers the results of the analysis, most security teams (over 90%!) told us they were not aware that a 3rd party in their environment had been given such critical permissions.

To better understand the risk, this section provides a detailed review of 3 common privilege escalation examples, their risks, and recommended mitigations. You’ll see that most escalations are subtle and require an experienced AWS cloud security engineer to spot them. Moreover, we found that based on vendor documentation, these permissions are not required in most cases and can be easily limited to reduce overall risk.

Escalation path #1 – iam:PutRolePolicy

Let’s start from a simple example, iam:PutRolePolicy. It’s one of the most powerful AWS privileges that exists, because it allows the user to add any policy to any role, effectively making the owner of the permission a super hero in two simple steps 🙂

It goes without saying that this permission should never be granted to a 3rd party vendor without the proper conditions and limitations.

Surprisingly, over 10% of vendors we analyzed use this policy, affecting a large percentage of environments and leading to a major account take over risk.

One of the most popular vendors in our research that requests iam:PutRolePolicy is Spot. As can be seen here, the default policy is quite extensive and asks for 100+ permissions, many of them highly privileged.

Why does the vendor request the iam:PutRolePolicy? Spot is an orchestration platform and may need extensive permissions to generate different resources in the environment.

How can I mitigate the risk? When working with an orchestration platform, there should always be a subset of policies and roles that the platform is allowed to use. These policies and roles should be tagged and the iam:PutRolePolicy should have proper conditions to reduce access only to these roles.

Spot provides a guide on how to restrict the policy (here):

“The role includes a restricted policy list, which you can further limit based on the AWS Resource and apply conditions to restrict it to a specific region or VPC or based on tags.”

Our research found that the majority of customers had not changed the default permissions requested by Spot.

Escalation path #2 – lambda:AddPermission

The next example is more difficult to detect. The permission lambda:AddPermission is used to add resource policies to Lambda functions, determining which services can access the function, trigger its code, or even update it. This permission is extremely powerful: In the wrong hands, it can allow an attacker to take over any existing lambda in the account and consume its privileges to become a super villain. Lets see how:

1. Find a highly privileged lambda function in the account
2. Using lambda:AddPermission add lambda:UpdateFunctionCode and lambda:InvokeFunction for the original IAM role
3. Inject the attacker code into the original lambda
4. Attacker can now escalate privileges and leverage the role provided to the lambda

3 of the vendors we analyzed require lambda:AddPermission and can execute code in the context of any lambda function across their clients’ account.

Why does the vendor need this permission? In most cases the permission is needed for a specific low-risk scenario. E.g. the vendor has a lambda function and wants to add triggers to that function dynamically (e.g. connect an S3 bucket event notifications to be sent to the lambda), but without adding any restrictions the customer is creating major escalation exposure.

How can I mitigate the risk? The mitigation is simple: When providing a high risk permission to a vendor, always limit the permission as much as possible. To do so, limit the names of the lambda functions in policy only to those that are used by the vendor (e.g. example-vendor-*) and limit the Principal to planned trigger type (e.g. S3 in the bucket event notifications scenario).

{
    "Sid": "LimitAddPermission",
    "Effect": "Allow",
    "Action": [
        "lambda:AddPermission"
    ],
    "Resource": "arn:aws:lambda:*:*:function:example-vendor-*",
    "Condition": {
        "StringEquals": {
            "lambda:Principal": "s3.amazonaws.com"
        }
    }
}

Limiting scope of permissions: The AWS identity engine has a rich set of conditions that are useful in reducing risk. When onboarding 3rd party vendors, the first step should always be to reduce the resource scope, limiting resources from access to everything, to specific resources. The second step is to use more advanced conditions to further limit the exposure, for example, here we use “lambda:Principal” to limit the permissions to the S3 service.

Escalation path #3 AWS ReadOnlyAccess managed policy

A personal favorite is the notorious AWS ReadOnlyAccess policy. The reason this policy is such a major risk is because it looks harmless. “There is nothing to worry about, we just need read only access”, giving the customer team a false sense of security. Since it’s a managed AWS policy, security teams assume it’s safe, but what they often don’t realize, is that AWS ReadOnlyAccess, is a highly dangerous policy that exposes the customer to a major data leakage threat. If access gets into the wrong hands, this policy may lead to extreme data leakage including PII, secrets, and any other data stored in the cloud.

25% of the vendors in our research requested ReadOnlyAccess and can therefore get wide access to the customer’s data.

The biggest concern? There is no real reason for any vendor to ask for permissions this broad. Lets take a closer look at one of the leading vendors asking for ReadOnlyAccess: NewRelic. While the vendor has extensive documentation on how customers can restrict access, we found that most simply use the default policy, despite the significant risk.

Why does the vendor request ReadOnlyAccess?

As explained here, the recommended policy is ReadOnlyAccess due to ease of deployment:

However, when examining the permissions required for each integration more closely, it seems that NewRelic only requires metadata from the different services, which begs the questions why ReadOnlyAccess is used as the default policy. One example are the requested DyanmoDB permissions that are outlined here:

So if there is no real need for data access, why does NewRelic request extensive permissions via the ReadOnlyAccess policy? It’s a question being actively discussed on NewRelic’s support forum without any specific guidance to-date. While we’ve used NewRelic as an example, we’re observing this to be an industry-wide problem across many of the top 3rd party vendors, showing the need for more diligence and accountability from vendors.

How can I mitigate the risk? Never give 3rd party vendors ReadOnlyAccess! It’s that simple because across all our research, we didn’t see any vendor that actually needed this managed policy. For security teams this means: Always reduce permissions, ideally use ViewOnlyAccess which is much less risky as it provides access to metadata only, and without any access to content. An additional step to reduce risk exposure overall is to leverage encryption where possible, because it requires the reader to have additional permissions for KMS keys, reducing the attack surface.

Changing the status quo – taking responsibility of 3rd party roles

To limit the risk of exposure through 3rd party vendors in your AWS environment, it’s important to not only understand the permissions they have today, but take the necessary steps to limit them. Most vendor policies allow for changes to the initial setup of permissions and you can enforce them to limit high permissions to only apply to the limited number of resources where they are actually needed.

Note: It’s important to be aware that enforcing permission changes can disrupt the activity of a vendor’s application. Therefore, if an application is critical to your environment, we recommend working closely with the vendor to ensure a smooth transition and prevent any disruption to the business. As described above, some vendors including NewRelic and Spot provide detailed documentation on how to restrict their roles.

In addition, we recommend maintaining a list of active vendors and applications used in your cloud environment and putting in place a process that ensures all permissions are removed once you stop working with them.

The gist:

• Understand the extent of a permission request before accepting it
• Identify external access to your environment
• Monitor 3rd party vendors with high privileges
• Remove unnecessary permissions and limit permissions to specific resources
• Remove roles of vendors and apps you no longer work with

Conclusion

This is a call for action! With an increasing number of security incidents related to supply chain attacks, cloud security teams have a great responsibility to verify and supervise the privileges they provide to third-parties. The status quo, where vendors receive wide access to data and services within customer accounts, without a real need, cannot continue as it allows . We must all make an effort to reduce requested permissions to the bare minimum.