Skip to content

Article by Wes Ladd.

Unintended Self-Signup in AWS Cognito

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:

$ 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.

$ 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 for more information.

References

Rhino Security Labs - CloudGoat
TrustOnCloud - CloudGoat Cognito Walkthrough
Padok.fr SecForce SecForce AWS-Cognito-Finder