© 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.

November 13, 2014 | Las Vegas

SEC403

Building AWS Partner Applications Using

IAM RolesBob Van Zant, Bracket Computing

Resources

• Code samples:

– https://github.com/bobveznat/sec403

• IAM policy helper:

– https://github.com/cloudtools/awacs

Use cases• Cloud management platform

• Log analysis

• Cloud spend analysis

• Operating across more than one AWS account

• Generalized: AWS applications that access other

AWS accounts

Anti-patterns• Ask for access key ID and secret access key

• Asking users to trust you more than they should

– “Create an admin user and send us the creds”

• Eager IAM policies

– action: *

Requirements• Act within another AWS account

• Take on subset of permissions to act within AWS

• Cannot be required to persist a secret(s)

AssumeRole API call“Returns a set of temporary security credentials that

you can use to access AWS resources that you might

not normally have access to. Typically, you use

AssumeRole for cross-account access or federation.”

http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

DescribeInstances example• Given account ID and region

• Print instance names and status

• Setup required:

– IAM role in customer account

– Role trust in customer account

To the console

AssumeRole Parameters

Easy ones• Duration: validity period for creds, 900-3600sec

– Go shorter with IAM policy variables

• RoleArn: The ARN of the role you’re assuming

• SerialNumber: For an MFA device

– Hardware serial number for gemalto

– ARN for virtual• arn:aws:iam::<account id>:mfa/<iam user>

• TokenCode: Code from MFA device

Policy• JSON string with valid IAM policy up to 2048 bytes

• Use this to further restrict permissions by scoping

down the policy

• Imagine a logical and of the role’s policies with this

new policy.

– i.e. May only be used to restrict access of the role

being assumed

To the console

RoleSessionName• Between 2 and 32 characters long

• Fairly restrictive character set:

– ^[\w+=,.@-]{2,32}$

• Useful for auditing

• Shows up in AWS CloudTrail logs (i.e. name wisely)…

session_name = “Hi-Mom”

sts_conn.assume_role(role_arn, session_name)

CloudTrail in your account

'requestParameters': {

‘durationSeconds': 2011,

'roleArn': ‘arn:…role/role-name’,

'roleSessionName': ‘Hi-Mom’},

CloudTrail in customer account

'userIdentity': {

'accessKeyId': 'ASIA…',

‘accountId': '111122223333',

'arn':

‘arn:…:assumed-role/ROLE-NAME/Hi-Mom’

Auditing Results

Time: 10/31/2014 13:05:19.000

RoleArn: arn:aws:iam::111111111111:role/brkt-readonly

RoleSessionName: adm-hub-mani

Who: arn:aws:sts::999999999999:assumed-role/prod-brkt-net-

hub-web/i-30e01eda

Time: 10/31/2014 15:07:59.000

RoleArn: arn:aws:iam::111111111112:role/brkt-readonly

RoleSessionName: adm-hub-krishnan

Who: arn:aws:sts::999999999999:assumed-role/prod-brkt-net-

hub-web/i-56e7e0b8

Auditing

_sourceCategory=AWS_EAGLE

| json “eventName",

“requestParameters.durationSeconds",

“requestParameters.roleArn",

“requestParameters.roleSessionName",

"userIdentity.arn"

| where eventName = "AssumeRole"

| where %"requestParameters.roleSessionName" matches "adm-*"

• Example Sumo Logic query

ExternalId• A pre-shared secret between you and your customer

• String from 2-1224 bytes long

• Used to prevent “confused deputy” problem

“A confused deputy is a computer program that is innocently

fooled by some other party into misusing its authority.”

http://en.wikipedia.org/wiki/Confused_deputy_problem

Let’s confuse the deputy• Assume a cloud management platform

• Customers bring their own AWS account

Getting confused

Confusion is imminent

Deputy confused

Image is in public domain. Obtained from http://commons.wikimedia.org/wiki/File:Don_Knotts_Jim_Nabors_Andy_Griffith_Show_1964.JPG

We’ve been owned

• Attacker has obtained a login to our platform

• Attacker has given a legitimate customer’s AWS ID

(the victim’s) instead of his own

• Attacker can now use our platform to view and act

within the victim’s AWS account.

• Oops.

What went wrong?

• We never verified that our user owned the AWS

account in question

• AWS provides the External ID parameters, which

lets us do that

Deputy not confused

Prevent that attack

• Customer brings 12-digit ID on signup

• You generate an external ID and hand to customer

• Customer sets up roles and trust, including the

external ID you specified

• Attack mitigated

– Attacker can only leverage your platform to take

over customer account if they have already

compromised the customer account and can

modify the trust policy

Are you vulnerable?

• Do you allow customers to bring their own account?

• Are you using external ID as described here?

• If not, your customers are at risk.

• It’s your fault.

Complete example

Notch it up

• Let’s build our cloud management platform on AWS

• Use Amazon EC2 instance profiles to seed access

• Instance profile should reference an access policy

that is again least privilege

• The more privileged an instance, the further from

users/attackers it should be

Sample architecture

Harder to attack; allow increasing privilege

To the console

http://bit.ly/awsevals