Merge pull request #269 from righteousgambit/main

Added two new concepts to AWS exploitation associated with Amazon Cognito.

content/aws/exploitation/cognito_identity_pool_excessive_privileges.md

@@ -0,0 +1,48 @@
+---
+author_name: Wes Ladd
+title: Abusing Overpermissioned AWS Cognito Identity Pools
+description: How to take advantage of misconfigured Amazon Cognito Identity Pools.
+---
+# Overpermissioned AWS Cognito Identity Pools
+## Summary
+A significant security flaw in applications using AWS Cognito for identity management can occur when identity pools are given excessive privileges. Excessive privileges in an Identity Pool mean that the identities (users) associated with that pool can perform actions beyond what is necessary for their role in the application.
+
+If an attacker successfully authenticates with the AWS Cognito service (such as through the [unintended self-signup](./cognito_user_self_signup.md), and the corresponding identity pool has excessive privileges, the attacker can potentially perform actions that should be restricted. This might include accessing sensitive data, manipulating services, and, in some cases, privilege escalation.
+
+Sometimes, even unauthenticated (or anonymous users) can perform actions that should be restricted. This is because AWS Cognito allows unauthenticated users to be associated with an identity pool. If the identity pool has excessive privileges, unauthenticated users can perform actions that should be restricted.
+
+## How it works
+The process usually involves two key steps:
+
+### Identity Retrieval:
+This starts with an attacker successfully signing up or logging in to a vulnerable Cognito user pool. As we discussed in our previous post, this might be due to misconfigured access controls allowing unintended self-signup, or through credential stuffing, password spraying or other attack vectors against user accounts.
+
+When an attacker successfully authenticates, they get a set of identity tokens. The ID token, in particular, is a JWT (JSON Web Token) that contains claims about the identity of the authenticated user.  
+
+### Excessive Privileges Exploitation:
+The next step involves the attacker using this ID token to get temporary AWS credentials from an associated Cognito Identity Pool. The Identity Pool maps identities to IAM roles and provides them with temporary AWS credentials to access AWS services.
+
+However, if the IAM roles associated with the Identity Pool have excessive permissions, the temporary AWS credentials that the attacker receives will allow them to perform actions that they should not be allowed to. Depending on the assigned permissions, an attacker could potentially read sensitive data from an S3 bucket, manipulate a DynamoDB table, invoke Lambda functions, or even perform privilege escalation to gain administrative rights.
+
+## Exploitation
+The following commands can be used to get the AWS credentials, assuming you have the ID token for a valid user:
+
+```bash
+aws cognito-identity get-id --identity-pool-id {identity_pool_id} --account-id {account_id} --logins {login_provider}:{id_token}
+```
+and then:
+```bash
+aws cognito-identity get-credentials-for-identity --identity-id {identity_id} --logins {login_provider}:{id_token}
+```
+
+## Impact
+The severity of this vulnerability depends on the permissions associated with the Identity Pool. In the worst case, an attacker could perform actions that are equivalent to a full AWS account takeover. This could lead to data leakage, unauthorized modification of data, and potential compliance violations.
+
+However, if Identity Pools are configured in accordance with the principle of least privilege, the impact of this vulnerability is significantly reduced. In this case, the attacker would only be able to perform actions that are allowed by the associated IAM roles. This might include accessing data that they should not be able to access, but it would not allow them to perform privilege escalation and actions that are not allowed directly by the IAM roles.
+
+## References
+[Rhino Security Labs - CloudGoat](https://github.com/RhinoSecurityLabs/cloudgoat/tree/master/scenarios/vulnerable_cognito)  
+[TrustOnCloud - CloudGoat Cognito Walkthrough](https://trustoncloud.com/exploit-two-of-the-most-common-vulnerabilities-in-amazon-cognito-with-cloudgoat/)  
+[SecForce](https://www.secforce.com/blog/aws-cognito-pitfalls-default-settings-attackers-love-and-you-should-know-about/)  
+[SecForce AWS-Cognito-Finder](https://github.com/SECFORCE/AWS-Cognito-Finder)  
+[Padok.fr](https://www.padok.fr/en/blog/aws-cognito-pentest#Attack_3:_Identity_pool_escalation)

content/aws/exploitation/cognito_user_self_signup.md

@@ -0,0 +1,56 @@
+---
+author_name: Wes Ladd
+title: Abusing Unintended Self-Signup in AWS Cognito
+description: How to take advantage of misconfigured Amazon Cognito User Pools.
+---
+# Unintended Self-Signup in AWS Cognito
+## Summary
+A common security flaw in SaaS applications that use Amazon Cognito as the IAM authn/authz source is allowing unintended/unauthorized account creation. Many times, such applications are intended to only allow Administrators to sign up users. 
+
+However, applications using Cognito are frequently not explicitly configured to require Administrator only sign-up. Just because a sign-up page or button is not present in the application, doesn't mean that an attacker can't sign up for an account. __If "Admin Only" signup is not enabled__ in the Cognito User Pool and an attacker can identify the Cognito User Pool Client ID and required sign-up parameters, they can sign up for an account using the AWS CLI.
+
+## How it works
+Identifying a Cognito User Pool Client ID for web applications and mobile applications requires different approaches.
+
+### Web applications:
+An attacker may identify the User Pool Client ID in a web application by inspecting the source code. This typically involves the following steps:
+
+1. Opening the web application in a web browser. 
+2. Using the browser's 'Inspect Element' or 'View Page Source' feature (usually accessible by right-clicking on the webpage and selecting it from the menu, or from the browser's tools menu). This allows viewing the HTML, CSS, and JavaScript code of the webpage. 
+3. Looking for the initialization of the Amazon Cognito service in the JavaScript code. This often contains the User Pool Client ID. The code might look something like AWSCognito.config.update({UserPoolId:'...', ClientId:'...'});. The string after ClientId: would be the User Pool Client ID. 
+
+It's worth noting that best practices encourage storing sensitive data like Client IDs server-side or using secure methods of storage and transmission. However, misconfigurations can lead to these details being exposed in client-side code.
+
+### Mobile applications:
+Obtaining the User Pool Client ID from a mobile application is more complex and requires a bit more technical know-how. The steps typically involve:
+
+1. Downloading the application package (APK for Android, IPA for iOS) to a local device.
+2. Using a software tool to decompile the application package into its constituent files. There are several tools available for this purpose, such as apktool for Android applications or otool/class-dump for iOS applications. 
+3. Searching through the decompiled files for references to Amazon Cognito or the User Pool Client ID. This could be in the form of a configuration file or embedded within the application's code.
+
+## Exploitation
+Once an attacker has identified the User Pool Client ID, they can use the AWS CLI to sign up for an account. The attacker will need to know the required sign-up parameters, which may be obtained by inspecting the sign-up page or form in the web or mobile application. The attacker can then use the following command to sign up for an account:
+
+```bash
+$ aws cognito-idp sign-up --client-id {client_id} --username {desired_username} --password {desired_password}
+```
+
+If the sign-up request fails with InvalidParameterException, it means additional user attributes are needed. In many cases, an email address is required. The attacker can then try again with the email address.
+
+```bash
+$ aws cognito-idp sign-up --client-id {client_id} --username {desired_username} --password {desired_password} --user-attributes Name=email,Value={email_address}
+```
+
+## Impact
+The impact of this vulnerability depends on the application. In some cases, the application may not be affected at all. In other cases, the application may be affected in a variety of ways. 
+
+Authenticated users of an application may be allowed to perform actions that they should not be able to perform. Perhaps the application allows data to be shared between users, and the attacker can use the application to share data with other users. Perhaps the application allows users to perform actions that cost money, and the attacker can use the application to perform actions that cost money. Perhaps the application allows users to perform actions that are not allowed by the application's terms of service, and the attacker can use the application to perform actions that are not allowed by the application's terms of service.
+
+In addition, the attacker may be able to exchange authenticated user access for AWS credentials. This could allow the attacker to perform actions in AWS that they should not be able to perform. See [Cognito Identity Pool Excessive Privileges](./cognito_identity_pool_excessive_privileges.md) for more information.
+
+## References
+[Rhino Security Labs - CloudGoat](https://github.com/RhinoSecurityLabs/cloudgoat/tree/master/scenarios/vulnerable_cognito)  
+[TrustOnCloud - CloudGoat Cognito Walkthrough](https://trustoncloud.com/exploit-two-of-the-most-common-vulnerabilities-in-amazon-cognito-with-cloudgoat/)  
+[Padok.fr](https://www.padok.fr/en/blog/aws-cognito-pentest#Attack_1:_Unwanted_account_creation)
+[SecForce](https://www.secforce.com/blog/aws-cognito-pitfalls-default-settings-attackers-love-and-you-should-know-about/)
+[SecForce AWS-Cognito-Finder](https://github.com/SECFORCE/AWS-Cognito-Finder)