Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Exploiting IAM in the google cloud platform - dani_goland_mohsan_farid

702 views

Published on

"Cloud infrastructure design is complex and makes even the most straight-forward topics, such as Identity and Access Management (IAM), non-trivial and confusing and therefore, full of security risk. While AWS IAM provides for access via console and API/CLI using access keys, there is also a temporary security tokens feature, designed for secure temporary access. However, temporary tokens have multiple security pot-holes that can lead to exploits.

I'll explore the limitations of temporary tokens including:
- the lack of visibility/management
- minimal logging
- limited remediation options
and how this can be taken advantage of, especially in combination with other techniques such as assuming of roles, pre-signed URLs, log attacks, and serverless functions to achieve persistence, lateral movement, and obfuscation.

In addition, I’ll look at common defensive techniques and best practices around lockdown, provisioning, logging and alerting to see whether these are practical and can shift the field."

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Exploiting IAM in the google cloud platform - dani_goland_mohsan_farid

  1. 1. Exploiting IAM in GCP
  2. 2. Who am I? ● Formerly Security @ Apple, Netflix ● Startup experience: built cloud security software ● Currently Research @ Netskope ● Focused on AWS, GCP
  3. 3. My Organization colin-demo-project What’s the Story... nsk-colin-child-bucket colin_perimeter colin-child-project Service account instance-1 Compute Engine nsk-colin-child-bucket Cloud Storage Stolen credential Shell Access
  4. 4. My Organization End Condition colin-child-project nsk-colin-child-bucket Cloud Storage colin-demo-project instance-1 Compute Engine
  5. 5. Agenda ● IAM in GCP ● VPC Service Controls ● Service Account Deep Dive ● GCP Demo ● Q&A
  6. 6. IAM in GCP
  7. 7. Types of Roles ● Primitive Roles - created by Google (not recommended) ○ Owner ○ Editor ○ Viewer ● Predefined Roles - created by Google ○ Compute Instance Admin ○ Storage Object Viewer ○ etc. ● Custom Roles - defined by users
  8. 8. VPC Service Controls
  9. 9. What are VPC Service Controls? ● Designed to mitigate Data Exfiltration risks ○ Create perimeters around your resources, such as Storage buckets ○ Control the movement of data past the boundaries of your perimeter ○ Set conditions to allow data flow outside of the perimeter ● Independent of IAM policies ○ IAM allow access would still be blocked based on the service control perimeter
  10. 10. Access Context Manager ● Another service that works in tandem with VPC service controls ● Allows admins to define the rules for access using certain criteria ○ Device type and operating system ○ IP address ○ User identity
  11. 11. An Example Protecting: nsk-colin-child-bucket
  12. 12. Combining the Controls ● Google says: IAM + VPC Service Controls = Defense in Depth ● IAM can be misconfigured, but the Service Controls protect you ● Everyone should be monitoring changes to these controls ○ What if someone changes the access level rule to allow all traffic from multiple countries? ○ What if somebody removes a service control perimeter?
  13. 13. Service Account Deep Dive
  14. 14. What is a Service Account? ● Identity for applications to authenticate ● Designed for non-human use ● Uses RSA keys instead of passwords ● Can’t access the web console ● Also considered resources – can apply bindings to them
  15. 15. More about Service Accounts ● A service account must be created in a Project ● IAM bindings can be granted at any level ● Elevated Bindings = bindings at the Folder, Organization ● Google creates some service accounts automatically ● Default account for Compute Engine, App Engine, etc. ● Accounts they will use for internal processing
  16. 16. Default Service Account - Compute Engine Google advises against it:
  17. 17. Compute Engine Service Account Role Contains a primitive role: ● Project Editor
  18. 18. Service Account Impersonation Project Editor Permissions (1894 in total) VPC Service Controls
  19. 19. Binding at the Project level colin-demo-project Service Account User Cloud IAM Service Account 1 Cloud IAM Service Account 2 Cloud IAM Service Account 3 Cloud IAM Service Account 4 Cloud IAM
  20. 20. Binding at the Service Account Level colin-demo-project Service Account User Cloud IAM Service Account 1 Cloud IAM Service Account 2 Cloud IAM Service Account 3 Cloud IAM Service Account 4 Cloud IAM
  21. 21. Permissions for Impersonating a Service Account ● Generating Service Account Keys ○ iam.serviceAccountKeys.create ○ iam.serviceAccountKeys.get ● Impersonation only ○ iam.serviceAccounts.actAs
  22. 22. Why Service Account Impersonation? ● Privilege Escalation ● It’s easy to lose track: a. VMs could have service accounts b. SSH keys could be applied project-wide c. User can now operate as the service account from a VM ● Obfuscates your activity in GCP
  23. 23. Access Scopes for Virtual Machines ● Legacy Method for applying permissions ● Must be set when using a service account ● Restricts API access for the service account ● Set on a per-instance basis
  24. 24. GCP Demo
  25. 25. My Organization colin-demo-project Our Scenario again... nsk-colin-child-bucket colin_perimeter colin-child-project Service account instance-1 Compute Engine nsk-colin-child-bucket Cloud Storage Stolen credential Shell Access
  26. 26. My Organization IAM Flow colin-demo-project Stolen credential instance-1 Compute Engine Default SA Cloud IAM Org Admin Cloud IAM Org Admin Cloud IAM Shell Access SA Impersonation colin_perimeter IAM Binding colin-child-project nsk-colin-child-bucket Cloud Storage
  27. 27. My Organization End Condition colin-child-project nsk-colin-child-bucket Cloud Storage colin-demo-project instance-1 Compute Engine
  28. 28. Demo
  29. 29. Key Takeaways ● Keep Service Accounts with elevated bindings in their own Project(s) ○ Keep public workloads out of the Project ○ Keep the Project under lock and key ○ Service accounts in the same Project may be able to see each other ● Bind permissions to specific Service Accounts whenever possible ● Don’t use Default Service Accounts ● Avoid using Primitive Roles
  30. 30. 2019 © Netskope Confidential. All rights reserved. Thank you! Colin Estep Netskope Threat Research https://www.netskope.com/blog

×