MITRE ATT&CK Framework: Initial Access

A cloud permission is never a dangerous thing by nature. In fact, their power is solely defined by the context in which they are used. Whether a permission falls into the wrong hands for malicious use, or an employee uses it and unintentionally introduces new risk, cloud permissions can be powerful tools.

Some permissions inherently hold more power than others and should be controlled accordingly. With over 40,000+ possible actions across the major cloud providers, prioritizing locking down the permissions with the greatest potential for damage is critical.

With this in mind, our teams have analyzed all cloud permissions and ranked them by their sensitivity and potential for damage. That is, if intentionally or unintentionally misused, how potentially destructive could this be?

Not only are these permissions ranked by sensitivity, but we’ve mapped them to the notable MITRE ATT&CK Framework. This means each permission is categorized into an attack stage – initial access, lateral movement, defensive evasion, and so on.

This blog kicks off a new series where we aim to educate on some of the most powerful cloud permissions you should protect, and how they could be used at each stage of the attack path.

First stop: Initial Access.

Note: How did we define ‘Initial Access’? Because holding any of these permissions already implies entry into the cloud, we categorize the permissions by their opportunity to create additional or future entryway into the cloud.

Powerful Permissions in AWS

Permission: CreateFunctionUrlConfig + UpdateFunctionUrlConfig

Service: Lambda

Context: This permission creates a Lambda function URL (or updates one) with whatever specified configuration parameters. A function URL is a dedicated HTTP(S) endpoint that you can use to invoke your function.

When your function URL auth type is NONE and you have a resource-based policy that grants public access, any unauthenticated user with your function URL can invoke your function.

So what?

With these permissions in hand, bad actors can create rogue lambda functions within your environment and update existing lambdas to require no authentication. This is their way in.

Along with the risk of exposing your private lambda function to the world, once public, a bad actor can then begin performing initial discovery and injection attacks.

In a less sinister light, internal employees with this permission can also introduce risk. A developer may accidentally leave these Lambda function URLs unauthenticated while testing. This means any unauthorized individual could invoke the function and cause some harm with it.

Permission: CreatePresignedNotebookUrl

Service: Athena

Context: This permission gets an authentication token and the URL at which the notebook can be accessed. During programmatic access, CreatePresignedNotebookUrl must be called every 10 minutes to refresh the authentication token. 

Each notebook is associated with a single Python kernel and runs Python code. A notebook can have one or more cells that contain commands. To run the cells in a notebook, you first create a session for the notebook. Sessions keep track of the variables and state of notebooks.

So what?

This permission allows an attacker to create or access an Athena notebook in an environment. This alone doesn’t sound harmful, but there are two elements to consider:

One, because the notebook is tied to a python kernel and can run python code, malicious code can be executed.

Two, Athena notebooks can also call other AWS services on your behalf. So, an attacker could query a data source within your organization and save that data within the Athena notebook.

The capability to create Athena notebooks also provides the opportunity for querying your unprotected datasets, SQL injection attacks, data manipulation, and more. 

By leaving the gate open to these notebook creations, bad actors can also upload shady zips, add python libraries, perform code executions, and generally wreak havoc once their initial access takes hold.

Powerful Permissions in Azure

Permission: Microsoft.ApiManagement/service/users/write

Service: Microsoft.ApiManagement 

Context: This permission allows both the creation AND updating of a user, including user password.

So what?

This is about as straightforward as it gets, permission to write to the user’s API provides an easy way for malicious folks to create new user entities which can access your portal(s). This is their initial foothold.

From there, the developer portal in Azure outlines APIs within your organization, providing a nice reconnaissance method for bad actors. Then, they can continue discovering unsecured API endpoints and aggregate information to use to pivot within your environment. Cue: further lateral movement.

Permission: Microsoft.Datadog/monitors/singleSignOnConfigurations/write

Service: Microsoft.Datadog

Context: This permission allows users to create or update an existing monitor for Datadog metrics, log collection, etc. and enables visibility into your organization and the potential architecture [/issues] within it. 

So what?

With this permission, and obtained access to Datadog, attackers can effectively discover loads of useful information like user and service-related details, locations of specific resources, and more. This is a great starting point for them to take their next move.

For example, let’s say an attacker got ahold of some credentials (with enterprise API/application key) they may gain expansive access to the organization’s monitors and mute, edit, disable, etc. one to wreak havoc.

Powerful Permissions in Google Cloud

Permission: compute.instances.osLogin

Service: Compute

Context: This permission allows a user to log into virtual machine instances using OS Login. That was easy!

So what?

The potential for harm with this permission in the wrong hands is pretty straightforward, but consider the following scenario: OS Login is enabled. User123’s google identity has permission to log into specific Linux Virtual Machines. 

User123 has a bad day and gets phished or falls for a social engineering scheme, suddenly the attacker has full blown access to these VMs – with no authorization needed. *Note: the identity additionally needs roles/iam.serviceAccountUser in this scenario.

Things could be even worse if it was a more senior employee than ‘User123’ who was phished, if an identity with `roles/compute.osAdminLogin`was compromised, the attacker has admin privilege over the associated VMs.

OS Login at surface value seems like a really convenient way to provision access to certain compute instances within your Google cloud, but when misconfigured or lacking additional measures like MFA, it may be considered a single point of failure for a successful social engineering attack.

How to Manage Sensitive Permissions

As we begin to better understand how cloud permissions can be weaponized by malicious attackers on their path to cause destruction, the next step is action towards securing these permissions. Some possible solutions to consider in the cloud access and permission management realm:

AWS IAM Access Analyzer: Access Analyzer identifies the resources like storage objects or roles that are shared externally. It works with logic-based reasoning to analyze resource-based policies and identify what external principals have unintended access and offers findings. Beyond that it can identify some unused access, enforce policy checks, and use CloudTrail logs for policy recommendations.

Least Privilege: Least Privilege is a well known security standard many enterprises work towards. Nearly impossible to do manually, a solution that offers least privilege can help by monitoring identity permission usage to gain an understanding of what they need to do their job. Excessive or unnecessary privilege can then be stripped away and a suggested better suited policy is recommended.

CIEM: Cloud Infrastructure Entitlement Management solutions are the best option for granularly managing permissions. They are able to ‘see’ all possible permissions tied to cloud identities – machine and human – even the ones accessible through inheritance. This visibility allows a CIEM to rightsize permissions by alerting to potential risks like lateral movement, privilege escalation, unintended access, and more – so your team can remediate within the platform.

Stay Tuned

Continue following the MITRE ATT&CK path as the next blog in this series comes out: Sensitive Permissions used for Persistence.

*** This is a Security Bloggers Network syndicated blog from Sonrai | Enterprise Cloud Security Platform authored by Tally Shea. Read the original post at: https://sonraisecurity.com/blog/powerful-cloud-permissions-you-should-know-part-1/