In cloud-based deployments, users and services are associated with roles. These roles become the way of governing identity and access. A common tendency in many organizations is to overlook these permissions — providing an opportunity for attackers to exploit them once discovered.

 

One solution: audit the roles, regularly.

 

What are over-permissioned roles and how do they happen in the AWS cloud?

An over permissioned role has more access authorization than it needs, leaving more room for compromise should an unauthorized user (“attacker”) obtain access to that role. For example, think about this from the systems administrators (Windows, Linux, macOS) perspective. Imagine if every user in your environment was an Administrator or root. Now, if any account is compromised, the unauthorized user can access, and cause severe damage to, existing systems and data.

 

To complicate things, cloud providers such as AWS offer pre-built managed roles that make it easier to configure roles, services, and the like. The convenience of these pre-built AWS Managed Roles is helpful for individuals who are inexperienced in setting up roles within the cloud or have to deploy cloud environments at a fast pace to maintain demanding business objectives.

 

The problem with using these roles appears in how they are set up. For example, notice that “Resource” is set to “*” (all resources) in the configuration screenshot below. There are no conditions to meet. These are the default policies and may be quite vague to the new user, or one that is in a hurry. Unfortunately, this ambiguity provides a rich condition for (potentially) enabling overly permissive actions.

 

 

Using baseline pre-built roles is often the default and includes more permissions than is needed for the specific task or service that role is administering. Further, it is time-consuming and difficult to learn the rules of each permission in order to tailor each role to its strict and appropriate level of permissions once the pre-built roles are implemented.

 

To compound this issue, once permissions and roles are built it is hard to keep track of who (users, systems, and services) has permissions assigned to them unless they were tracked from their creation. This creates a perfect storm for system administrators and security professionals alike.

 

How do we meet the needs of the business, learn the nuances of these new cloud environments, and maintain a safe and secure environment?

 

What is the cyber risk inherent to over-permissioned users?

Understanding how over permissioned roles happen is one thing, but knowing what happens when these over permissioned roles are used against the organization is the real issue. Attackers can exploit these misconfigurations to escalate privileges, move laterally, or gain access to sensitive information. If an attacker gains access to an account with high-level permissions, or they pivot to another account, they can potentially accomplish any of objectives, to include:

 

• Accessing sensitive information (Potentially leading to exfiltration if other factors line up)
• Escalating permissions
• Deleting entire accounts
• Defacing external sites
• Creating new AWS resources (e.g., servers, S3 buckets)
• Pivoting to internal infrastructure (i.e. “moving laterally”)
• Executing code on computer infrastructure
• Moving to another account

While misconfigurations in permissions can provide the conditions for any of the above, other misconfigurations within the environment, or weak security policies overall, can further exacerbate the amount of harm or damage that an attack will be able to achieve.

 

How does this look in the real world?

We have observed over permissioned roles in both organizations new to cloud migrations and organizations with long-term use of cloud-based hosting. In one example, while performing a cloud assessment, the Neuvik team was provided with an organization’s typical “Developer” role. During a common review of the provided role, the team discovered the account had (unintended) unrestricted administrator access; essentially allowing the Neuvik security team to access resources and create new ones.

 

With this functionality, the team was able to create a new resource with a public IP address, allowing the security team to SSH into the instance and gain access to the internal network. Through this same Developer role the team was able to access the production configuration of an application which then disclosed credentials to connect to databases with sensitive information.

 

The consequence of excessive permissions on this role had significant effects on how far we were able to penetrate the security of the cloud environment. And we see this over-permissioning quite frequently.

 

How do you address the issue of over-permissioned users in the cloud?

The answer is twofold:

First, and as a general practice, we recommend understanding and mapping out the actual permissions desired when creating well-defined, custom user roles. This means moving away from the habit of using prebuilt roles. While prebuilt roles are easy to setup in the near-term, they introduce an immediate risk over the long-term. To an attacker, the use of prebuilt roles also signify the possibility of other default, non-customized configurations in the cloud environment, for example:

 

• Outbound network connections allowed (meaning anything can call back over the internet to external systems, rather than using proper filtration)
• Default security proofs
• Third party service providers that hook up into an AWS account and ask to grant permissions (those permissions are excessive)

When cyber hygiene is discovered to be weak, we expect to see much weaker overall management of the environment. (It’s also worthwhile to map out the permissions that your internet-facing services have.)

 

Second, consider performing a cloud security assessment. In almost every AWS Security Assessment that Neuvik has completed, we notice the existing risk of over-permissioned users in the cloud. To move away from pre-built roles and reduce the risk of these types of attacks from occurring, perform an assessment of permissions assigned to the roles in the cloud environment. This assessment should consider why the role is needed, who will need access to the role, and which services should be assigned. Once the baseline is established, build pre-defined custom roles meeting the needs of the business while reducing the risk of default permissions (or configurations) being used in an attack.

 

Do you need a Cloud Security Assessment Review?

Take a moment to look at the user roles in your cloud environment and check to see if you have any vulnerabilities from excess user permissions. If you need help with an AWS Security Assessment Review, we at Neuvik Solutions are here to help.

 

Contact us here and let us know what we can do for you.