Share
Embed
OWASP 20th Anniversary - AWS (Mis)configuration from attacker’s eye-view
What you can expect from this ?
- AWS Cognito Misconfiguration.
- S3 Misconfiguration that attackers love.
- Misconfigured IAM Policy.
- EC2 MIsconfigurations.
- How HTML injections can help to get AWS credentials.
Kavisha Sheth
September 25, 2021
Transcript
38 slides
-
AWS (Mis)configuration from attacker’s eye-view About me • Security Analyst
@Appsecco. • Listed as among top security researcher of the nation by NCIIPC. • Curious person • International speaker who talks around Cloud security , API security and Modern web-application. -
AWS (Mis)configuration from attacker’s eye-view What’s all about? • AWS
Cognito Misconfiguration. • S3 Misconfiguration that attackers love. • Misconfigured IAM Policy. • EC2 MIsconfigurations. • How HTML injections can help to get AWS credentials. -
AWS (Mis)configuration from attacker’s eye-view User Pools & Federated Identity
Pools https://serverless-stack.com/chapters/cognito-user-pool-vs-identity-pool.html 1. User authenticates against a user pool. 2. The user pool assigns 3 JWT tokens (Id, Access, and Refresh) to the user. 3. The ID JWT is passed to the identity pool in order to receive temporary AWS credentials with roles assigned to the identity provider. 4. The user can then make calls to AWS services based on their privileges. Amazon Cognito has authenticated and unauthenticated mode to generate AWS temporary credentials for users. -
What are the possible attack vectors? • Misconfigured AWS Cognito
Attributes. • Hardcoded Identity Pool ID. • AWS cognito misconfigured to allow sign up of new user. • Identity Pool ID present in HTTP response. • Liberal AWS permissions has been assigned. AWS (Mis)configuration from attacker’s eye-view -
AWS (Mis)configuration from attacker’s eye-view Hardcoded Identity Pool ID Identity
Pool Id getting disclosed in HTTP Response -
How the disclosure of App Client ID, User Pool ID,
Identity Pool ID, and Region information can help? How can I try to exploit? AWS (Mis)configuration from attacker’s eye-view -
Try to fetch Temporary credential Using Python script Generate the
temporary credentials through Boto3 script API call to look into HTTP request for to get IdentityID from IdentityPoolID API call: AWSCognitoIdentityService .GetCredentialsIdentity API call to look for in HTTP request to fetch temporary credentials after knowing IdentityID API call: AWSCognitoIdentityService.GetCred entialsIdentity Using Burpsuite A B AWS (Mis)configuration from attacker’s eye-view 1 2 -
AWS (Mis)configuration from attacker’s eye-view • Check if application exposed
some functionalities unintentionally via AWS Cognito misconfiguration. for example, AppClientId disclosed. • Check if the confirmation email was sent to the attacker specified email along with the confirmation code. • Check if the user account can be confirmed from the token received on the registered email. • Check if Application validated a newly created user and returned access tokens. • Authenticated access and ID token. These values could be used to generate temporary AWS credentials for authenticated identities. What if access to unauthenticated identities was disabled ? -
• Sensitive details present in server responses, including Cognito Identity
Pool Id. • AWS cognito misconfigured to allow sign up of new user. • Providing the liberal AWS permissions and that allows an unauthenticated user to access sensitive AWS services. • Improper validation for Identity ID and allow to fetch temporary credentials What can go wrong ? AWS (Mis)configuration from attacker’s eye-view -
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 resource. AWS (Mis)configuration from attacker’s eye-view -
Finding S3 Bucket • Google search • Google dork •
Shodan • Censys • Use discovery (OSINT) tools – Sublist3r and Amass • Bruteforce name • Shodan, Certificate Transparency Logs, Censys, numerous bucket finder scripts, GrayHat Warfare bucket search AWS (Mis)configuration from attacker’s eye-view -
How (Mis)configured IAM Policy allows least privilege user to get
admin level access? AWS (Mis)configuration from attacker’s eye-view -
1. Multiple policy versions with overly permissive configuration for older
version. 2. Overly permissive policy present. 3. Able to use overly permissive older version policy by making it as a default policy. What went wrong? AWS (Mis)configuration from attacker’s eye-view -
• Is EC2 instance accessible to public user? • Is
there any port open? • Is web application running on that EC2 instance ip address? • Is default configuration being used? What to look for? AWS (Mis)configuration from attacker’s eye-view -
1. Misconfigured firewall that allows EC2 instance publicly accessible. 2.
Web Application hosted on EC2 instance doesn’t have input validation and trust on user supplied data to make requests from the server and that make web-application vulnerable to SSRF. 3. EC2 role with overly permissive policy. 4. Data storage in AWS S3 was not encrypted. 5. Storing credentials such as admin credentials in S3 bucket. What went wrong? AWS (Mis)configuration from attacker’s eye-view -
AWS (Mis)configuration from attacker’s eye-view What are other attack vectors
worth to look for • Public Snapshots • Non-public EC2 AMI • Encrypted AMI • Not using default VPC • EC2 Instance Not In Public Subnet • Unrestricted Outbound Access • EC2 Reserved Instance Payment Pending • Allowing meaningful ports to open without putting restrictions -
How an attacker make use of HTML Injection to get
AWS credentials ? AWS (Mis)configuration from attacker’s eye-view -
1. The user provided data was being consumed were not
output encoded and input is not being sanitized and that make application to vulnerable to HTML Injection attack and also confirm that vulnerable to SSRF attack. 3. AWS hosted web application, so try to access to a set of AWS access keys by accessing the AWS EC2 metadata service via a SSRF vulnerability. 4. Able to access EC2 metadata as usage of IMDVS1. What went wrong? AWS (Mis)configuration from attacker’s eye-view -
• Improper credentials handling • Instance misconfiguration • S3 misconfiguration
• Access control misconfiguration • Exposure of resources via firewall • Network security misconfiguration • Insecure custom applications • RDS Misconfigurations Misconfigurations that worth to look for AWS (Mis)configuration from attacker’s eye-view -
Tools that can help to speedup procedure • Scoutesuite •
Prowler • S3-inspector • Enumerate IAM • Bucket finder • Pacu • aws_escalate AWS (Mis)configuration from attacker’s eye-view -
References • https://aws.amazon.com/premiumsupport/knowledge-center/cognito-user-pools-identity-pools/ • https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html • https://dev.to/cloudanix/top-13-aws-ec2-misconfigurations-to-avoid-in-2021-29 • https://notsosecure.com/hacking-aws-cognito-misconfigurations/ •
https://andresriancho.com/wp-content/uploads/2019/06/whitepaper-internet-scale-analysis-of-a ws-cognito-security.pdf • https://blog.appsecco.com/finding-ssrf-via-html-injection-inside-a-pdf-file-on-aws-ec2-214cc5 ec5d90 • https://github.com/appsecco/attacking-cloudgoat2 AWS (Mis)configuration from attacker’s eye-view