Elevating Attack Path Mapping to the Clouds

Current State: Standard Cloud-based Application Testing

For clients with strict compliance requirements, we form a scoping discussion around what they need us to test so that they can meet their regulatory obligations. The target of testing may be an application which has been deployed within their cloud estate. The client, therefore, might require a web application test and also assurance for the underlying infrastructure which includes the configuration of the cloud resources the application relates to.

To perform the testing, we coordinate with the application and infrastructure team for the provisioning of access. This results in a test which considers the application and its infrastructure in isolation and therefore with a limited scope. If we find that the compute instance on which the application is deployed has a wide set of permissions, how should we rate the risk? We may have no idea of the business impact as we do not have visibility of the client’s wider cloud environment. The diagram below puts in perspective the arguably limited number of resources tested with such a approach, in the context of a multi-account environment.

Current State: Scale of Coverage

It is not uncommon to see hundreds of cloud accounts being managed under one organisation. Trying to test all of these accounts within any sensible timeframe or budget would be difficult. This is true especially given the rate at which cloud infrastructure can change within an organisation where DevOps (increased collaboration between Development and Operations teams) practices are used. In these organisations, risks raised against certain assets at the end of a test may no longer be relevant due to recently implemented changes, or even removal of the asset.

With an assessment which focuses only on one of the accounts or subscriptions, any overarching policies which are applied across the environment might not be seen. This means that they may evade being assessed at all, or that when smaller areas of the cloud environment are considered in isolation, context on the available security controls being applied is lost. This applies similarly for any centralised security services or products which are in use. For example, within AWS, Service Control Policies (SCPs) can be used within an AWS Organization to limit the ability of member accounts to perform actions. These may only be seen within the “Root” account, unless you receive an error message expressing that your access has been denied due to an explicit deny in an SCP during testing. As such, any assessment of a single “Member” account would not provide complete visibility of these SCPs and their total intended effect.

Current State: Existing Tooling

Many great tools exist to assist with cloud reviews, including

• IAMSpy - https://github.com/ReversecLabs/IAMSpy
• IAMGraph - https://github.com/ReversecLabs/IAMGraph
• ScoutSuite - https://github.com/nccgroup/ScoutSuite (though this has not received updates recently)
• Prowler - https://github.com/prowler-cloud/prowler

These provide a point-in-time overview of various configuration errors within a given cloud environment and pick up many of the major issues that an organisation might be concerned about. Additionally, Cloud Security Posture Management (CSPM) solutions exist which perform these, and additional, checks on a more continuous basis.

However, what these tools and products don’t account for is the context in which a resource is deployed. For example, if you decided to use a public S3 bucket to host a static website, tooling might flag this as an issue even though it was intended functionality. Exceptions can be created so that the next time the tool is run, this issue is not flagged, however this serves to demonstrate that tooling itself does not infer, or ask, the business reasoning behind a decision. This can introduce risk, if the exceptions are not carefully managed. For example, if an exception is made to account for public S3 buckets being allowed due to their use in a static website, care must be taken to ensure that this exception is not applied more widely. If the exception is not limited correctly, this could result in the tooling missing exposure of sensitive assets.

As such, especially when considering Identity and Access Management (IAM), a manual review of policies is preferred, with collaborative discussions with the client on permissions which are considered of higher risk. For example, without context, it is unlikely to be possible to say whether the below AWS IAM policy is over permissive or required functionality:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECSAccess",
            "Effect": "Allow",
            "Action": [
                "ecs:Poll",
                "ecs:StartTask",
                "ecs:StopTask",
                "ecs:DiscoverPollEndpoint",
                "ecs:StartTelemetrySession",
                "ecs:RegisterContainerInstance",
                "ecs:DeregisterContainerInstance",
                "ecs:DescribeContainerInstances",
                "ecs:Submit*",
                "ecs:DescribeTasks"
            ],
            "Resource": "*"
        }
    ]
}

This can also include discussions on federated access to the environment and an understanding how on-premise service accounts may interact with cloud resources, as these are not explicitly covered within tooling output.

The Future: Collaboration and Breadth

With the current state described previously, there are some changes in the style of testing that we believe would be of benefit to customers. Perhaps most importantly, we should consider the real world impact of our findings. Reversec do this in current engagements regardless, by making sure that we have contact with the clients and can talk to them about what the systems under test are doing and how they integrate with other systems. Additionally, we attempt to talk about business impact in a manner tailored specifically for the client, rather than giving generic statements about the issues. However, this level of involvement should be standard across the industry, forcing engagements to be more collaborative and invite a deeper understanding of the systems involved.

The second part to consider is estate-wide coverage of any cloud environments. Looking at the security of small elements in isolation is no longer enough, when so many integrations exist and microservices are tied to each other in complex webs. Difficulties, though not insurmountable, arise when we are asked to look at the underlying cloud infrastructure for a system and that infrastructure is in a shared account or tenant. One of the harder parts of such a job is discerning which resources and services are relevant to the system in scope. Access to the team’s Infrastructure as Code (IaC) repositories can help here. However, assessing this does not account for any drift or manually implemented changes within the environment.

The Future: A New Approach

With the entirety of an estate being within the scope of an engagement, there must be a way to narrow down testing so that a reasonable timeframe can be agreed. Reversec’s APM approach is to work with the client to agree of high-impact business objectives. Previous examples of these include:

• Lateral movement into air-gapped networks
• Adjusting transactions data to steal money or goods
• Accessing highly confidential product recipes before their release
• Deploying ransomware en masse across the estate

Choosing these objectives helps to determine which resources will be focused on within the APM and will ultimately demonstrate to the client the paths to their worst-case scenarios.

Having agreed these objectives, starting points will also be chosen together, such as: a newly onboarded employee, a cloud infrastructure developer, an opportunistic external attacker, a malicious or compromised contractor. The product of the number of starting points and number of objectives is a major contributor to estimating how much time an engagement will take, so these should be considered carefully.

The starting points will often also determine likely areas to be covered within the client environment. For example, if a cloud infrastructure developer is chosen as a starting point, the client’s cloud setup and Continuous Integration/Continuous Delivery (CI/CD) pipelines are likely to be investigated closely. However, while a new starter with an Active Directory account and associated permissions may eventually pivot to the cloud resources, AD-style privilege escalations might be needed to form the basis of such attacks.

A configuration review of elements within the environment is likely to take place to gain an understanding of the general security posture of the cloud environment in question. However, rather than giving specific recommendations on, for example, single policies within the Identity and Access Management plane, higher level guidance will be provided. This allows the client to understand the root causes of issues and address those.

Pros and Cons

With any approach, there are advantages and disadvantages. The main advantage of a cloud APM is that a client will be presented with impactful findings at the engagement’s conclusion, as the objectives have been specifically chosen with business impact in mind. Any routes that were found to achieve these objectives will be clearly stated and diagrams will be presented showing the paths through the environment. This gives a clear view of where the “critical” points in the environment are and, therefore, where immediate attention should be placed for fixes or mitigations.

Due to the open scope of an APM, any SaaS products which are integrated within the environment are under consideration too. Where a configuration review of the SaaS product might determine that the setup is suitable for the client, an APM may demonstrate how native functionality of the product can be used to achieve an objective or further an attacker on their path to this. With the number of integrations seen nowadays within client environments, this underappreciated additional attack surface must be considered.

Another notable advantage of an APM is that it doesn’t test everything. These engagements are carefully scoped and work is performed efficiently, meaning that results are maximised for the amount of effort required to perform testing.

However, as stated, an APM does not test everything. Due to this, an APM may not be the correct test for certain compliance frameworks which require testing on specific resources. They also require extensive collaboration with the client’s team, including senior stakeholder buy-in to allow for the extensive access required in various areas of the business. This can make the engagement costly in terms of people’s time.

Similarly, it is worth noting what an APM is not. Red Teams tend to involve a single starting point. They are mainly focused on reaching the objectives without being detected, so do not provide a holistic view over the client estate. The Red Team starting point is often an external attacker, meaning that a portion of the time of testing may be spent crafting phishing emails. Due to the need to stay stealthy on a Red Team, additional time is usually used in obfuscating malicious payloads. APMs instead tend to start from the “assumed breach” scenario and do not rely on stealth. APM actions can be “noisy” and we work with the client’s security team to deconflict our testing activities with other alerts. Should an analysis of a security team’s detection and prevention ability be required, an Attack Detection Capability Assessment (ADCA, or Purple Team) is more suitable, where consultants execute a range of payloads and work with the security team to establish where the detection and prevention controls could be improved.