5 mins to read
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.
Instantly Secure the Most Sensitive Permissions
Sonrai’s Cloud Permissions Firewall knows the 3,000 most sensitive cloud permissions out there — and how your identities are using them. Unused sensitive permissions are instantly protected with a global default deny policy fit to your specific access needs — all you have to do is a click a button to deploy. Grant future access needs on the fly with a permissions-on-demand workflow integrated into your ChatOps tool.
While you’re at it, quarantine zombie identities and disable unused cloud services and regions for ultimate risk reduction.
How do organizations monitor and audit cloud permissions in real-time?
Organizations monitor and audit cloud permissions in real-time using various tools and practices, including Cloud Infrastructure Entitlement Management (CIEM) solutions, cloud provider-native tools (like AWS CloudTrail or Azure Monitor), and third-party security platforms that offer continuous monitoring and anomaly detection capabilities. These tools help in tracking permission changes, assessing risk levels, and identifying unusual access patterns or configurations that might indicate a security risk.
What are the common pitfalls or mistakes organizations make when managing cloud permissions?
Common pitfalls in managing cloud permissions include overprovisioning permissions (granting more permissions than necessary), neglecting to regularly review and adjust permissions, failing to implement the principle of least privilege, and overlooking the need for comprehensive audit trails. These mistakes can lead to risks, making it easier for unauthorized users to access sensitive resources.
Can you provide specific case studies or examples where mismanagement of these permissions led to security breaches?
Specific case studies highlighting the consequences of mismanagement include the Capital One breach in 2019, where a misconfigured AWS S3 bucket allowed unauthorized access to sensitive data. Another example is the Verkada camera breach in 2021, where attackers gained access to the internal systems of the company through a server with excessive permissions.
