RVASec AWS Survival Guide 2.0
Download as PPTX, PDF0 likes551 views
This document provides a summary of best practices for securing AWS environments. It discusses common issues like exposed credentials, misconfigured services, and vulnerable systems that can lead to account exploitation. The document recommends implementing monitoring with AWS services like CloudWatch, CloudTrail and Config to detect threats. It also advises hardening AWS security by not using the root account, auditing IAM policies, enabling multi-factor authentication, using IAM roles instead of long-term access keys, and monitoring for unauthorized API access or root account usage. Specific techniques are demonstrated like creating a CloudWatch event rule to send unauthorized IAM events to Lambda for analysis.
RVASec AWS Survival Guide 2.0
- 2. HELLO! Before we get started, let’s chat about recent events… 2
- 3. AWS Key “Our review has shown that a threat actor obtained access to a set of AWS keys and used them to access the AWS API from an intermediate host with another, smaller service provider in the US.” 3
- 4. S3 Bucket Permissions “On May 24, Chris Vickery, a cyber risk analyst with the security firm UpGuard, discovered a publicly accessible data cache on Amazon Web Services' S3 storage service that contained highly classified intelligence data.” 4
- 5. Quora & 50k bill “After just one week of the account being compromised, the monthly bill was $285,000!” 5
- 6. Gettin’ Robbed “I hired a remote developer to help me with my startup. After asking him to sign a Non Disclosure Agreement (NDA), I added him to my private Github repository. He then forked my repository and publicly exposed a copy of it on his own repository” 6
- 7. Background
- 8. Me 8 CTO – nVisium Breaker & Builder Utilize AWS Heavily @cktricky
- 9. This talk 9 Preventing the preventable
- 10. “Account exploitation, in my experience, occurs due to hosting vulnerable systems, misconfigured services, or compromised credentials.
- 12. Exposed Credentials ▸Keys are often stored on developer or ops machines ▸Typically can be found under ▹~/.aws/config ▹~/.bashrc ▹ ~/.zshrc ▹~/.elasticbeanstalk/aws_credential_file 12
- 13. “Thankfully, developers never embed secret keys in source code or post their sensitive dot files to public repos ~ Nobody, the F%@k Ever
- 18. Misconfigured Services ▸S3 bucket with “any authenticated user” permissions (credit: Chris Gates) 18
- 19. Misconfigured Services ▸Listing buckets contents 19
- 20. Misconfigured Services 20 ASK SHODAN Don’t believe me? Just ask Shodan.io…
- 21. Misconfigured Services ▸I have many more examples including ▹RDS default creds ▹“Internal” assets on a VPC ▹Security groups ▹Unencrypted storage of PII ▹List goes on…
- 23. Vulnerable Systems ▸Machine is compromised ▸Attacker grabs metadata info ▸Uses these credentials to pivot
- 24. Vulnerable Systems ▸For compromised instances, just turn to Google...
- 25. Vulnerable Systems ▸Browse to this address from compromised machine ▸http://169.254.169.254/latest/meta- data/iam/security-credentials/ ▸Obtain credentials here and pivot
- 26. Vulnerable Systems ▸Even a talk/tool to help with this ▹https://www.blackhat.com/docs/us-14/materials/us- 14-Riancho-Pivoting-In-Amazon-Clouds-WP.pdf ▹https://andresriancho.github.io/nimbostratus/
- 27. Vulnerable Systems ▸Summary ▹Plenty of ways to get in ▹Plenty of ways to secure your infrastructure ▹Let’s get started shall we
- 28. Prevention
- 30. Monitoring
- 31. Monitoring ▸AWS Solutions - Monitoring ▹3 Services: CloudWatch, CloudTrail, and Config
- 32. Monitoring
- 33. Monitoring ▸Step 1 – Turn it on
- 34. Monitoring ▸Step – 2 Configure Log Group
- 35. Monitoring ▸Step 3 - Create IAM Role
- 36. Monitoring ▸CloudWatch Alarms – Helpful but not detailed
- 37. Monitoring ▸This is more along the lines of what we want
- 38. Monitoring ▸I learned the hard way so you don’t have to ▹Alarms filter for metric data and, when sent to Lambda, SNS, etc. they only contain info on the metric ▹Events on the other hand, they send the entire event data to Lambda (much more detailed) ▸Both are functions of CloudWatch
- 39. Monitoring ▸First we will setup an alarm for IAM Unauthorized Activity ▸Second, setup a similar alarm but for events and with better, more granular details ▸Discuss other types of events to monitor for
- 40. “One last thing - you want both an alarm and events… we have good reason
- 41. Monitoring ▸Choose log group, create metric
- 42. Monitoring ▸Define Pattern (what to grok for)
- 43. Monitoring ▸Assign a metric (naming conventions)
- 45. Monitoring ▸Give it a name, desc, etc.
- 46. Monitoring ▸It works really really well ▸No matter what event source the data comes from, its parsed and recognized correctly ▸This means its safe ▸But… those “details”…
- 47. Monitoring
- 48. Monitoring ▸But then I learned about CloudWatch Events (Rules)! ▸If something (Event) happens, you can send that something to Lambda for processing based on a rule (Rules)
- 49. CloudWatch Events!If something (Event) happens, you can send that something to Lambda for processing based on a rule (Rules) 49
- 50. Monitoring
- 51. Monitoring ▸This what an event typically looks like
- 52. Monitoring ▸At first, I tried “How to Detect and Automatically Revoke Unintended IAM Access with Amazon CloudWatch Events” https://aws.amazon.com/blogs/security/how- to-detect-and-automatically-revoke- unintended-iam-access-with-amazon- cloudwatch-events/
- 53. Monitoring ▸Filters requests when event source = IAM ▸Sends IAM event to Lambda ▸Check user permissions ▸Lacking administrative permissions? =>Revoke access
- 54. Monitoring ▸Not exactly what I want although, cool stuff ▸We are looking to alert on any Unauthorized Activity error triggered by AWS calls
- 55. Monitoring ▸Now for a brief interruption
- 56. Monitoring ▸Prior to Event Rule Creation 1. Configure Slack Webhook 2. KMS encrypt Slack Webhook URL 3. Create Lambda Function
- 57. Monitoring ▸Start configuring incoming webhook
- 58. Monitoring ▸Add configuration inside of slack
- 59. Monitoring ▸Choose the channel (and other details)
- 60. Monitoring ▸Retrieve the webhook URL
- 61. Monitoring ▸Create KMS key, later used to decrypt
- 62. Monitoring ▸Name the key, follow steps 1 - 4
- 63. Monitoring ▸Use the AWS KMS encrypt function to encrypt the webhook URL
- 64. Monitoring ▸Next we will create the Lambda function ▸We need the Base 64 encoded + KMS encrypted URL from the previous slide ▸This will be needed for our code to securely retrieve the Slack Webhook URL
- 65. Monitoring ▸Select a blank function template
- 66. Monitoring ▸Configure Trigger (just click “Next”)
- 67. Monitoring ▸Place the following code into the function https://gist.github.com/cktricky/8f4e9912f75 7d1ccdcd00ad8e8630620
- 68. Monitoring ▸Use Base64+ KMS encrypted URL
- 69. Monitoring ▸Lastly, choose the slack service role
- 70. Monitoring ▸Directly edit the JSON
- 71. Monitoring ▸Paste in JSON and select Lambda Function as Target
- 75. Monitoring ▸You can now unleash the power of Event Rules for other alerts ▸Simple as editing the JSON and parsing the data via Lambda ▸Use BOTH CloudWatch Alarms AND Events
- 76. Monitoring ▸Previous versions of this talk show how to configure Alerts for: ▹Root account usage ▹Billing Alerts (Exceed normal spend) ▹Failed Login Attempts https://www.youtube.com/watch?v=g- wy9NdATtA&feature=youtu.be
- 77. Hardening
- 78. Hardening ▸The AWS Security Fundamentals Course provides the framework for your plan: ▹You are responsible for leveraging the tools AWS provides (financially) ▹Your configuration… that is on you https://aws.amazon.com/training/course- descriptions/security-fundamentals/
- 79. Hardening 1. Don’t Use The Root Account! 2. Audit IAM user policies 3. Multi-Factor Authentication 4. API + MFA 5. IAM Roles 6. Misc
- 81. Hardening – AWS Root Account ▸Every AWS environment has a root account ▹Root account is the king/god/all-powerful ▹Use only when you absolutely must ▹When those circumstances arise, notify your team first
- 82. Hardening – AWS Root Account Simple steps: ▹Disable or delete access keys if they exist: ▹Implement verbal/written policy that states “we don’t create access keys for the root account ▹Use the CloudWatch Alarm I mention to alert on its use
- 84. Hardening – Auditing IAM Permissions ▸A single IAM user can have… ▹Multiple Managed Policies ▹Multiple Inline Policies ▹Belong to multiple IAM Groups which… ▹Have multiple managed policies ▹Have multiple inline policies
- 85. Hardening – Auditing IAM Permissions ▸Explanation ▹Managed Policies: Policies that can be attached to multiple users, groups, or roles ▹Inline Policies: Directly attached to a single user, group, or role
- 86. Hardening – Auditing IAM Permissions ▸Tool to inspect each user’s permissions: ▹https://gist.github.com/cktricky/257990df2f36aa3a01 a8809777d49f5d ▹Will create a CSV file ▹Provides you with ▹Usernames ▹Inline Policies ▹Managed Policies ▹Groups
- 87. Hardening – Auditing IAM Permissions ▸Tool Output
- 88. Hardening – Auditing IAM Permissions ▸Closer look
- 89. Hardening – Auditing IAM Permissions ▸https://aws.amazon.com/blogs/security/move-over- json-policy-summaries-make-understanding-iam- policies-easier/
- 90. Hardening – Auditing IAM Permissions ▸Why this is important ▹If you house sensitive data, you need to know who has access ▹Permissions should be a need-to-have/know situation in order to limit damage should creds get stolen ▹AWS is a flexible environment that changes – your permission model might need to change with it (inventory it)
- 92. Hardening – MFA ▸MFA == 2-Factor Authentication ▸If credentials are stolen or guessed, we want a second layer of protection ▸You can use apps or hardware to do this ▹Google Authenticator (Apps) ▹Gemalto (Hardware) ▸Find the full list of MFA devices here: https://aws.amazon.com/iam/details/mfa/
- 93. Hardening – MFA Let’s demonstrate enabling MFA using a virtual device (app) on an IAM account
- 94. Hardening – MFA ▸Navigate to Identity & Access Management
- 95. Hardening – MFA
- 96. Hardening – MFA
- 97. Hardening – MFA
- 98. Hardening – MFA ▸At this point, its worth mentioning that non- administrators or those without IAM privileges cannot enable MFA on their own account ▸Why is this a problem? Well, they need to be able to enable MFA on their own device… not the administrator’s ▸Fortunately, we have a solution!
- 99. Hardening – MFA
- 100. Hardening – MFA ▸Okay so that wasn’t the easiest to read, so here is the link: http://docs.aws.amazon.com/IAM/latest/UserGuide/id_ credentials_delegate- permissions_examples.html#creds-policies-mfa- console ▸Basically this IAM policy allows a user to manage their *OWN* MFA device
- 101. Hardening – MFA ▸Need a shared MFA for root? TOTP! ▸Recommend using something like 1password for teams, can share the TOTP code: https://support.1password.com/guides/mac/totp.htm l https://www.youtube.com/watch?v=eZyb-ArMK9g
- 102. API & MFA 102
- 103. Hardening – API & MFA ▸This is the alternative to interacting with the AWS environment via the web console ▸Typically used for automated tasks ▸Automated tasks means “code”.
- 104. Hardening – API & MFA ▸At a minimum apply to those with IAM permissions
- 105. Hardening – API & MFA ▸This entry requires MFA for Web/API
- 106. Hardening – API & MFA ▸Truth be told, doing this can be painful at first ▸Things that used to work, might not (via the API) ▸Fortunately, we have some answers for you ▸Firstly, let’s discuss STS or SecurityToken Service
- 107. Hardening – API & MFA ▸Leverage STS in order to interact with the AWS API should this MFA restriction be placed on resources (and it should ) ▸Example of using STS: https://gist.github.com/cktricky/127be4e431563a986f0f
- 108. Hardening – API & MFA ▸Example of retrieving creds (in the gist)
- 109. Hardening – API & MFA ▸Output of script
- 110. Hardening – API & MFA ▸Use the creds to leverage tools like ec2-api- tools ▸(-O <access key id>–W <secret> and –T <session token>)
- 111. Hardening – API & MFA ▸https://github.com/jimbrowne/aws-sts- helpers
- 112. Hardening – API & MFA ▸ElasticBeanstalk does not work with STS. Le Terrible. ▸However, there is a workaround, use CodePipeline. ▸Very simple process to setup but only works with: ▹GitHub ▹AWS CodeCommit ▹Amazon S3
- 113. Hardening – API & MFA Remember MFA only protects against the web and NOT the API… unless you change your policies and use STS
- 114. IAM Roles 114
- 115. Hardening – IAM Roles ▸Roles ▸Is *like* a user but is not an IAM user ▸Replaces the need for hardcoded Access Key ID & Secret ▸The extent of what a role can do is heavily controlled by you, the administrator
- 116. Hardening – IAM Roles ▸Credentials automatically rotate via STS ▸Available here on an EC2 instance: http://169.254.169.254/latest/meta-data/iam/security- credentials/ ▸If you’re using the AWS-SDK gem/egg/etc – credential handling is built-in ▸If you’re using something like Paperclip + Rails, try Fog to leverage Roles ▸https://github.com/thoughtbot/paperclip/issues/1591
- 117. Hardening – IAM Roles ▸Example of a Role policy (shown within IAM)
- 118. Hardening – IAM Roles ▸Example attaching Role to ElasticBeanstalk instance
- 119. Misc 119
- 120. Hardening – Misc ▸Review AWS environment for Unencrypted and Encrypted EBS Volumes https://gist.github.com/cktricky/0fa3b13ca4306bcd1ec 384e88eac3f55
- 121. Hardening – Misc ▸Review S3 buckets to determine security policy https://gist.github.com/cktricky/faf0f40116e535a055b7 412458136917
- 122. Splunk + AWS
- 123. Splunk + AWS ▸Splunk is a pretty great resource for monitoring activity ▸I’m fairly new to Splunk myself ▸Two separate plugins: Splunk App for AWS https://splunkbase.splunk.com/app/1274/ Splunk Add-On https://splunkbase.splunk.com/app/1876/
- 124. Splunk + AWS ▸Examples of things you can view: ▹Billing ▹Topology ▹Usage ▹IAM Activity ▹SSH Key Pair Activity ▹User Activity ▹Network ACL(s) ▹VPC Activity and a lot more…
- 125. Splunk + AWS
- 126. Splunk + AWS
- 127. Splunk + AWS
- 128. Splunk + AWS ▸Splunk will need an AWS account in order to retrieve data ▸Create account(s) for Splunk, grab the necessary permission policy from here: http://docs.splunk.com/Documentation/AddOns/rele ased/AWS/ConfigureAWSpermissions
- 129. Summary
- 130. Hardening – API & MFA ▸Hopefully, I’ve given you some ideas ▸We talked about Monitoring & Hardening ▸But we did NOT discuss recovery (prepare for the worst) ▸http://www.irongeek.com/i.php?page=videos/derbyc on6/120-hardening-aws-environments-and- automating-incident-response-for-aws-compromises- andrew-krug-alex-mccormack
- 131. 131 THANKS! Any questions? You can find me at @cktricky & cktricky@gmail.com