kbroughton / aws_integration_external_id Goto Github PK

Currently, the block below is hardcoded static.
The uuid value fc2a0258-aee3-41f9-a37a-7db9c9e16cee should be a variable
that will change depending on the scenario.
external_id_value_per_difficulty = {'trivial': 'SSC_external_id', 'easy': 'SSC-role-id', 'hard': 'f2ca uuid value, 'secure': 'f2ca uuid value'}

Fill in the body so that the user-selected mode in ['trivial', 'easy', 'hard', 'secure'] returns the correct value and templatizes the policy correctly.

function set_external_id_value {

}

Template:

var jsonVar = {
  "Version": "2012-10-17",
  "Statement": [{
      "Effect": "Allow",
      "Principal": {
        "AWS": "999999999999"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "sts:ExternalId": [
            "fc2a0258-aee3-41f9-a37a-7db9c9e16cee"
          ]
        }
      }
    }
  ]
}

Currently, the game on the tamper setting will succeed just by hitting "test connection".
The player should first have to brute force the accountid, and role name.
If the player doesn't do this, the connection should show "failed"

We can't illustrate this with the screenshot since it has fixed values, so only show the intercepted traffic once the accountid and role are entered. All three values should match what is in the ssc_role trust policy in the grey block at the bottm.

This is an advanced feature that most sites do not have. Hide it unless we are on the "Secure" setting of the game.

The current Tamper flow isn't quite right.
It should start with the burp intercepts not showing.
Press "Test Connection" and the first one appears.
Press "Tamper" popup and it switches to match the externalId value in the Trust policy below instead of in the greyed input box above.
Connection should succeed. Then reset.

Design to support the following DefCon CTF

Minimal
Need two AWS empty AWS accounts.
Vendor Account has a server running
EC2 VS Serverless VS LightSail / ElasticBeanstalk. EC2 allows ssrf attack. More common.
ASG behind ELB behind WAF

Maximal
Base the Vendor portal off of Panther Labs. Will it allow user isolation and quick customizations?
https://github.com/panther-labs/panther/issues

Challenge 1: Standard Attack - Trivial
Description: Web portal. Instructions on how to use Pacu to solve.
Recon: You are given an account ID. Brute force the role with Pacu.
Attack: Access the vendor portal. Supply the accountID and role.

Challenge 2: Direct Access to Resource - Easy
Description: Website url with some suggested pages to visit. Observe the web traffic. Hint that the Account ID can be extracted from a signed URL.
Recon: A website has a signed URL. Use it to get the AWS Account ID. Brute force role names to find vendors.
Website uses signed URL Use pacu to brute force role names.

Challenge 3: Tamper POST request - Medium
Recon: Foothold container instance. Call metadata service to get credentials. Read cloudtrail logs/CloudWatch events to get externalId.
Attack: Vendor portal does not allow UI tampering of externalID. Use burp to intercept and modify to the discovered value.

Challenge 4: Attack the vendor - Hard
Recon: Hint - you are attacking the vendor's AWS cloud, but you will still need to use the Client portal to discover something about the vendor.
Attack: Up to you. This is the nuclear variation. no hints.

Infrastructure supplied by dungeonmaster
2 AWS accounts for Vendor and Customer.
Hackers will receive unique credentials to a single unique role which they have permissions to modify the trust policy for.
The permission policy of the role will allow them to read the unique CTF secret from and S3 bucket to prove their success.
Hackers will also be able to self register at the vendor portal.

Requirements for hackers
Hackers are encouraged to use docker to run Pacu, but it can be installed with pip.
For Challenges 3 and 4, hackers will need an intercepting proxy like Burp.

Challenge 1: Standard Attack - Trivial
Description: Web portal. Instructions on how to use Pacu to solve.
Recon: You are given an account ID. Brute force the role with Pacu.
Attack: Access the vendor portal. Supply the accountID and role.

I'd like some stats on how many people visit the page, how long the stay, maybe even which buttons get pushed.

even though there is no server to attack, the code should look clean and follow basic best practices like sanitizing input to alphanumeric plus "-" and "_".

currently this is commented out.
It seems like the code just runs immediately. It should brute force a list of 6 names before hitting the correct SSC_role. there should be a split second delay so the user can see the values updating in the Role input field.

This is currently done in brython, but could be switched to javascript.

Do we want a multi-tenant server?
https://books.agiliq.com/projects/django-multi-tenant/en/latest/

We want each student to be able to create their own AWS integration without interfering with another user.
This could be separate ECS containers for each web app, or many tenants on a single server.
Simplest would be single tenant and each user sees a view populated with their own values for role_arn, external_id.

No preference for now.

Currently playing with this
https://www.notion.so/How-to-deploy-django-app-to-ECS-Fargate-Part1-a1e99c19b2a3423585e67f0b1ad81cbd

The top of the page should have a user select dropdown mode = [ ] which determines whether the example aws integration is trivial, easy, hard, or secure (not possible) to hijack.

The mode determines the AWS policy that gets templatized (see issue 1) with the external ID.
The logic of "Test Connection" changes with the mode.

The current page only has a single mode - secure. In this mode, "Test Connection" should actually fail because the UUID in the custom AWS policy block (representing a victim account signed up in a different vendor session) would be different from the UUID.

The other scenarios are:

1. trivial. The externalId is suggested by the vendor (initial text in input box) as SSC_external_id
   This can be achieved on first try. The externalID is an editable field like the AWS account and Role fields.
2. easy. The externalId is not suggested, but the user can choose any value.
   In this case, the user should have to press "Test Connection" four times, each time the suggested external_id should change to a new "guessed" value simulating a brute force list.
3. hard. The externalId is a UUID of a different value but the field is editable. We explain with a text box that this case requires an insider attack ( someone who can read the externalID from CloudTrail or from a leaked screenshot etc). In this case, the player wins by copying the UUID from the AWS policy (which we assume was leaked) into the externalID input box and pressing "Test Connection".