Cloud attack vectors and security controls Kavisha sheth AWS

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

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

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

No content

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

No content

Finding EC2 instance

No content

No content

Exposure of resources via misconfigured firewall

Finding leaked RDS endpoints

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

Google dork site:*.s3.amazonaws.com inurl:assessment

Misconfigured S3 Bucket

Allowing public access

Defining “Full control” access to Authenticated Aws Users group

Bucket with a “read access” policy

Forgetting to encrypt your AWS resources

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.

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.

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

Found Credentials What’s next???

No content

Stolen credentials !!!

Enumerate permissions Limited permissions !!

No content

What policy attached to user

Get current policy version number

List all policies

Enumerate different policies

Make v5 as default policy and escalate privilege

Privilege escalation

Approach so far !

No content

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

Detected that credentials being leaked !

No content

No content

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

Found Public Ip of EC2 instance ● Is default configuration being used? ● Is there any port open? ● Is web application running on that ip?

Web application running on port 80

Vulnerable to SSRF

No content

Exploit SSRF to get IAM role credentials

● Enumerate permission using credentials ● Found s3 related permissions

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

Capital One breach ● Misconfigured firewall ● Gaining access to an EC2 instance ● Getting IAM role access to S3 ● S3 bucket discovery

Attack vectors

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

EC2 instance is compromised !!!!

No content

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

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

Guidelines and Tools ● CIS Amazon Web Services Foundations Benchmark ● AWS Security Audit Guideline ● AWS Whitepapers ● Scoutesuite ● Prowler ● S3-inspector ● Enumerate IAM ● Pacu

Linkedin: https://www.linkedin.com/in/kavisha- sheth/ Twitter : https://twitter.com/sheth_kavisha

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