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.
@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.
Cognito Misconfiguration. • S3 Misconfiguration that attackers love. • Misconfigured IAM Policy. • EC2 MIsconfigurations. • How HTML injections can help to get AWS credentials.
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.
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
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
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 ?
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
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
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
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
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
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
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
• 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