All Projects

Hello Alwaysdata Security Team
I would like to report a security vulnerability.

Severity level: Medium

Target: https://admin.alwaysdata.com

Category: Business Logic Flaw

Summary
A business logic flaw was discovered in the user registration system that allows a single individual to register an unlimited number of free trial accounts using a single primary email address. This is achieved by exploiting the additional addressing feature (the "+" sign) in email providers like Gmail.

Reproduction Steps
Example accounts:
laminasi0390@gmail.com (Primary Account)
laminasi0390+2@gmail.com (Detected as a new account)
laminasi0390+3@gmail.com (Detected as a new account)

1. Register and log in to the first account (primary account) using the email address: laminasi0390@gmail.com. Activate the free trial.
2. Register a second new account using the email address: laminasi0390+2@gmail.com. Check your inbox at laminasi0390@gmail.com. You will receive a verification email for the second account. Verify it and note that the free trial is valid for this "new" account again.
3. Register a third new account using the email address: laminasi0390+3@gmail.com. Check your inbox at laminasi0390@gmail.com. You will receive a verification email for the third account. Verify it and note that the free trial is valid for this "new" account again.
4. Repeat the process with +4, +5, and so on.

Business Impact
1. Financial Loss: Users can continue to enjoy premium features without paying.
2. Resource Abuse: Server load increases due to serving duplicate accounts.
3. Abuse of unlimited free trials

Recommended Fixes
1. Remove Aliases: Identify the + signs and delete all characters between them up to the @ sign.
2. Normalize email formats
3. Enforce uniqueness on canonical email values.
4. Optionally, block email aliases if they are not supported.

Regards,
Muchamad Alfian

Vulnerable Assets
- Activity Log Module
- /log/{log_id}/detail/

Menu menus whose logs are accessible to limited access accounts:
1. https://admin.alwaysdata.com/site/configuration/
2. https://admin.alwaysdata.com/domain/
3. https://admin.alwaysdata.com/environment/
4. https://admin.alwaysdata.com/advanced/log/

Vulnerability Type
Broken Access Control

Vulnerability Description
In the test scenario, there are two types of accounts:
- Account A: Full access (Admin/Owner)
- Account B: Limited access
By design, account B does not have permission to view the system audit logs. The log menu is not available in account B's UI. However, by manually adding the URL path, account B can still access certain log details. By accessing the endpoint: /log/{id}/detail/
Account B successfully views audit log information without any authorization validation on the backend. This indicates that access control is only implemented at the user interface (UI) level, not the backend API.

Sensitive data accessible to account B includes:
1. Actions (Create, Update, Delete)
2. Objects (modified resources)
3. Users (accounts performing the actions)
4. Resources
5. IP addresses
6. Date and time
7. Change details (Detail)

Reproduction Steps
1. Log in using account B (limited access).
2. Ensure the audit log menu is not available in the UI.
3. Access the URL directly, for example: /log/11032585/detail/
4. Audit log details are successfully displayed even though the account does not have permissions.

Security Impact
1. Leakage of Sensitive Information
2. Reconnaissance for Advanced Attacks
3. Violation of the Principle of Least Privilege

Recommended Improvements
1. Implement authorization validation in the backend for each audit log endpoint.
2. Ensure that only roles with appropriate permissions can:
View log lists and Access log details
3. Avoid relying on UI restrictions as the sole security control.

Vulnerable Assets
- Activity Log Module
- /log/{log_id}/detail/

Menu menus whose logs are accessible to limited access accounts:
1. https://admin.alwaysdata.com/site/configuration/ 2. https://admin.alwaysdata.com/domain/ 3. https://admin.alwaysdata.com/environment/ 4. https://admin.alwaysdata.com/advanced/log/

Vulnerability Type
Broken Access Control

Vulnerability Description
In the test scenario, there are two types of accounts:
- Account A: Full access (Admin/Owner)
- Account B: Limited access
By design, account B does not have permission to view the system audit logs. The log menu is not available in account B's UI. However, by manually adding the URL path, account B can still access certain log details. By accessing the endpoint: /log/{id}/detail/
Account B successfully views audit log information without any authorization validation on the backend. This indicates that access control is only implemented at the user interface (UI) level, not the backend API.

Sensitive data accessible to account B includes:
1. Actions (Create, Update, Delete)
2. Objects (modified resources)
3. Users (accounts performing the actions)
4. Resources
5. IP addresses
6. Date and time
7. Change details (Detail)

Reproduction Steps
1. Log in using account B (limited access).
2. Ensure the audit log menu is not available in the UI.
3. Access the URL directly, for example: /log/11032585/detail/
4. Audit log details are successfully displayed even though the account does not have permissions.

Security Impact
1. Leakage of Sensitive Information
2. Reconnaissance for Advanced Attacks
3. Violation of the Principle of Least Privilege

Recommended Improvements
1. Implement authorization validation in the backend for each audit log endpoint.
2. Ensure that only roles with appropriate permissions can:
View log lists and Access log details
3. Avoid relying on UI restrictions as the sole security control.