2 Cloud Catastrophes

2 Cloud Catastrophes

Resource Hijacking

bucket name is unique, if you delete it others can use the name

https://github.com/EdOverflow/can-i-take-over-xyz

Mitigating

• keep dns and cloud resources in sync to prevent djangling reources

Credentials SSRF

Server Side Request Frogery, attacker causes server to make an HTTP request.

• XML parsing
• pdf/page conversion functionality
• application proxying
• image uploads (may accept inline file or URL)
• web hooks

About Meta Data Service

• cloud services need a mechanisim to populate instance with configuration, e.g. ssh key

• they user an internal service where instacnes can request this data e.g. AWS 169.254.169.254/latest/meta-data

• • 2.1 Cloud Meta Data

By passing Anti SSRf

1. configuration

• backend url
• frontend url

Travis Example

to get meta data

Use and Attack Cases

Migating

• avoid api keys in user data scripts
• implement IAM policy where use of creds is IP restricted
• implement a proxy that whitelists by user agent

• trigger laerts when creds used from unknown

• ref [slide share detectiong-credential compromise in aws sec 389]

Auth and Trust Relationships

• using Assume Role to eonforce MFA

Pictures at S6 (including summary)

Summary

• Global pools of identification -> Hijacking of orphaned resources
• • monitor DNS for orphaned resources
• Cloud APIs are public -> cred disclosure can be catastrophic
• • proxy access to metadata service
• Gaps in knowledge of cloud auth models -> Gaps in Auth
• • MFA admin CLI users and leverage tools analyse policy

Step back

• use credential report access advisor
• VPC ACL Policies
• S3 buckets policies