The results are based on the open-source application DVSA, a deliberately vulnerable application aiming to aid security professionals to test their cloud security skills. You can deploy the application to one of your accounts and perform a CloudFormation stack scan to reproduce the results on CodeShield. As the application has vulnerabilities, we recommend using a sandbox account for deployment.
While this demo uses a scan of a CloudFormation stack, we generally suggest to scan the entire account or regions. Those scans include
identity resources (like users and roles), which apart from
compute resources also serve as entry points to the attack scenarios and are usually not defined in CloudFormation stacks. The amount of findings will be higher on those scans.
Privilege Escalations Matrix
CodeShield's privilege escalation algorithm detects two scenarios on the stack (see rows in matrix in screenshot below). Both scenarios' entry points are the Lambda function
OrderManagerJsFunction (first column in the screenshot). An attacker can use two critical IAM permissions (
lambda:UpdateFunctionConfiguration) to exploit the Lambda function to gain new privileges. Furthermore, the two scenarios lead to a total of three Attack Goals:
SPAWN_COSTLY_SERVICE. I.e., the attacker may exfiltrate or tamper with sensitive data, and is able to spawn new resources to conduct a denial-of-wallet attack.
Each cell within the matrix represents a scenario-goal combination and can be inspected further.
Clicking on the warning sign (), opens the attack scenario focus view that details all information about the scenario. The number below the warning sign () indicates the amount of impacted cloud resources by the scenario.
Attack Scenario Focus View
The scenario focus view provides all details for the concrete attack scenario. Below is an example attack scenario for one possible privilege escalation on DVSA. To the left, a summary of the scenario is provided, to the right the concrete steps of the exploitation walkthrough are displayed. In the center of the view, the steps an attacker takes are represented graphically.
In the scenarios, the attacker gained initial control over the Lambda function
OrdersManagerJsFunction. For instance, by abusing a known CVE in a library or by abusing a vulnerability in the Lambda's custom code. The Lambda function has a role attached, that defines an inline policy. The inline policy specifies the actions
lambda:UpdateFunctionCode. CodeShield's policy evaluation engine detects that the action is allowed to update the code of yet another Lambda function within the stack - the function
OrdersGetFunction. The Lambda function
OrdersGetFunctionhas higher privilege than the
OrdersManagerJsFunction- namely read access on DynamoDB tables.
Figure: Attack Scenario Focus View with graphical represantion of the attack in the center and exploitation walkthrough to the right.
Fine-granular fix recommendations are also provided in the Attack Scenario Focus View. The instruction are based on the actual resources and attack scenario and are automatically generated. However, over any of the resources and find the quick links to the AWS console for fixing the issue straight away.
The attack impact specifies the difference between the actions and resources the attacker initially has access to (in the example
OrdersManagerJsFunction), and the actions and resources the attacker gained access to after the privilege escalation happened. I.e., all actions and resources accessible by
OrdersGetFunction but not accessible by
In the attack scenario from above, the attack impact comprises the
dynamodb:GetItem and 9 more DynamoDB actions. Furthermore, one can view the actual DynamoDB tables that can be accessed with the stated actions. The link
6 cloud resource(s) navigates the user to the resource inventory view.
The Resource Inventory lists all cloud resources that are part of the given scope of the scan.
For the selected attack scenario, six resources are impacted. All six cloud resource impacted by the attack scenario (Dynamo DBs and S3 buckets) can be viewed in the Resource Inventory. Clicking on a resource provides more details on who can read/write from/to the specific DynamoDB tables. In the screenshot below, for instance, the impacted DynamoDB table
InventoryTable lists the
AdminUpdateOrder Lambda function to have an incoming relation to the table (The function can write to the table).
Within the Cloud Model view all resources of the scan are represented visually in an infrastructure diagram. The screenshot below shows the infrastructure of DVSA. The diagram also highlights the attacker and all cloud entry points. In the example infrastructure, the attacker enters the cloud environment via one of the three
AWS:ApiGateway:RestApi resources. The
ApiGateways are connected to Lambda Functions.
For an improved visualization, all resources are grouped by their resource types. By clicking on one of the grouped resources within the diagram, the right side pane changes and displays all grouped individual resources. As the resources are grouped by their types, so are the edges in the diagram. Selecting an individual resource in the left side pane, the user can further on understand relation to individual other resources within the diagram.
Example: In the screenshot below, the user first selected the
AWS:ApiGateway:RestApiresource node. Next, the user clicked on the individual
ApiGatewayApiresource on in the left pane. The
ApiGatewayApiresource has an
APIReferenceedge to the function
OrderManagerJsFunction. The reference indicates that the api gateway dispatches http request to the
/orderroute to a the
Note that the Cloud Model shows exactly how an attacker could enter the system to exploit a vulnerability in
OrdersManagerJsFunction and thereby conduct the shown attack scenario to gain privileges to read/tamper form/with the stated Dynamo DBs and S3 Buckets.