Cloud attack vectors and security controls

DEFCON Cloud Village
- Learn about how an attacker can perform reconnaissance, leverage network, IAM Misconfiguration, S3 misconfiguration, and implementation in weaknesses to steal credentials and data.
- Learn how misconfigurations and other leading cloud vulnerabilities put you at risk to exploitation with some real-world example
- Learn about what can be possible best practices, detective controls to avoid these misconfigurations

Transcript

1. Cloud attack vectors and security controls Kavisha sheth AWS
2. About me • Security Analyst at Appsecco • Breaks web application, API and Cloud security • Member of a number of security communities including null community, InfoSec Girls, Breaking Barriers - Lean In Circle and WiCys India • Active speaker
3. Agenda • Possible attack vectors for aws cloud • Reconnaissance that can help • Some of misconfigurations like IAM Misconfiguration, S3 Misconfiguration, EC2 Misconfiguration • Detection • AWS security Controls
4. Attack vectors • Leaked credentials • Instance misconfiguration • Using default settings • S3 misconfiguration • Access control misconfiguration • Exposure of resources via firewall • Network security misconfiguration • Insecure custom applications
6. Finding Credentials • Look for hardcoded credentials stored in js file or client side (IKIA keyword) • AWS Cognito credentials in response • Vulnerabilities in AWS hosted applications like SSRF (Server Side Request Forgery) and LFI (Local File Inclusion) • Code repositories such as Bitbucket and Github • AWS error messages such as access denied • Public EBS snapshots (EC2 -> Snapshots -> Public Snapshots) • Public AMIs (EC2 -> AMIs -> Public images) • S3 Bucket • RDS public snapshots (RDS -> Snapshots -> All Public Snapshots) • People looking for help online and end up copy-pasting complete info
8. Finding EC2 instance
11. Exposure of resources via misconfigured firewall
12. Finding leaked RDS endpoints
13. Finding s3 buckets • Google search • Google dork • Shodan • Censys • Use discovery (OSINT) tools – Sublist3r and Amass • Bruteforce name • In DNS records • Shodan, Certificate Transparency Logs, Censys, numerous bucket finder scripts, GrayHat Warfare bucket search
14. Google dork site:*.s3.amazonaws.com inurl:assessment
15. Misconfigured S3 Bucket
16. Allowing public access
17. Defining “Full control” access to Authenticated Aws Users group
18. Bucket with a “read access” policy
19. Forgetting to encrypt your AWS resources
20. Attack vectors 1. Allowing public access to bucket. 2.Defining “Full control” access to Authenticated Aws Users group. 3.Defining Bucket with a “read access” policy. 4.Enabling “Write” access to the “Everyone” group. 5.Forgetting to encrypt your AWS resources.
21. Investigation • GuardDuty finding for S3 will list an S3 bucket, the bucket's Amazon Resource number (ARN) and a bucket owner in the finding details. • Use AWS CloudTrail log • AWs Trusted Advisor ◦ To inspect your Amazon S3 implementation • Cloudwatch metric ◦ CloudWatch met for Amazon S3, particularly PutRequests, GetRequests, 4xxErrors, and DeleteRequests. • Enable AWS Config ◦ s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited managed AWS Config Rules.
22. Security controls that can help • Implement least privilege access • Use IAM roles for applications and AWS services that require Amazon S3 access • Enable multi-factor authentication (MFA) Delete • Consider encryption of data at rest • Enforcing SSL • Consider VPC endpoints for Amazon S3 access • Consider S3 Object Lock • PreSigned URL” through a generated URL, users can be granted temporary write or read access to a bucket or objects • Enable versioning
23. Found Credentials What’s next???
25. Stolen credentials !!!
26. Enumerate permissions Limited permissions !!
28. What policy attached to user
29. Get current policy version number
30. List all policies
31. Enumerate different policies
32. Make v5 as default policy and escalate privilege
33. Privilege escalation
34. Approach so far !
36. Investigation • Use Trusted Advisor, check IAM Credential Report. • Use IAM tools such as the IAM policy simulator or the IAM console can help you review. • Use config rules ◦ IAM_POLICY_IN_USE : Config rule that checks whether the IAM policy ARN is attached to an IAM user, • Access Advisor Use last accessed information. • Use CloudTrail for logging. • Monitor (CloudWatch alarms). - Root logins, IAM policy changes, unauthorized API calls,CloudTrail configuration changes, authentication failures
37. Detected that credentials being leaked !
40. Security controls • Use secret manager to store credentials securely • Grant least privilege access • Use access levels to review IAM permissions • Configure multi-factor authentication for your most sensitive operations • Rotate credentials regularly • Ensure a log metric filter and alarm exist for IAM policy changes
41. Found Public Ip of EC2 instance • Is default configuration being used? • Is there any port open? • Is web application running on that ip?
42. Web application running on port 80
43. Vulnerable to SSRF
45. Exploit SSRF to get IAM role credentials
46. • Enumerate permission using credentials • Found s3 related permissions
47. Attack surface analysis • Default configuration setting usage • Web Application hosted on EC2 was vulnerable to SSRF • Role having to work with S3 buckets • Data storage in AWS S3 was not encrypted • Sensitive information(Admin credentials) being stored in S3 bucket
48. Capital One breach • Misconfigured firewall • Gaining access to an EC2 instance • Getting IAM role access to S3 • S3 bucket discovery
49. Attack vectors
50. Detection Technique • Guard Duty • Config rules ◦ EC2_IMDSV2_CHECK : Checks whether EC2 instance metadata version is configured with Instance Metadata Service Version 2 • Security hub • Flow logs • System manager
51. EC2 instance is compromised !!!!
53. Security controls • Input validation • Update to AWS EC2 instance metadata service (IMDSv2) • Implement least privilege permissions • Consider encryption of data at rest • Constantly monitor for overly permissive Security Groups Use control tower for separate logging activity and normal account activity • Use security hub
54. Things to note • Reconnaissance and OSINT are the key to finding attack vectors • Post exploitation has no limits with the cloud. You can attack additional services, disrupt logging, make code changes to attack users. • The most common themes are mis-configuration of services, insecure programming and permissions that should not have been given • Logging and monitoring key for investigation. • Always keep in the mind least privilege access. • Follow AWS security best practices
55. Guidelines and Tools • CIS Amazon Web Services Foundations Benchmark • AWS Security Audit Guideline • AWS Whitepapers • Scoutesuite • Prowler • S3-inspector • Enumerate IAM • Pacu
56. Linkedin: https://www.linkedin.com/in/kavisha- sheth/ Twitter : https://twitter.com/sheth_kavisha
57. Resources • https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html • https://pages.awscloud.com/Best-Practices-for-Security-in-Amazon-S3_0713-STG_OD.html • https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.pillar.security.en.html • https://aws.amazon.com/blogs/security/aws-security-reference-architecture-a-guide-to-designing-with-aws-sec urity-services/ • https://d1.awsstatic.com/whitepapers/architecture/AWS-Security-Pillar.pdf?ref=wellarchitected-ws • https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf • https://aws.amazon.com/blogs/security/what-to-do-if-you-inadvertently-expose-an-aws-access-key/ • https://github.com/jassics/awesome-aws-security#Tools-of-Trade • https://github.com/appsecco/attacking-cloudgoat2 • https://github.com/RhinoSecurityLabs/cloudgoat • https://dzone.com/articles/pillars-of-aws-well-architected-framework