All Projects

Description

A Cross-Site Request Forgery (CSRF) vulnerability exists in the Display Zone File functionality.

The application does not properly validate whether the Display Zone File request is initiated by the authenticated user. By creating a malicious CSRF proof-of-concept (PoC) and replacing the domain_id with the victim's domain ID, an attacker can force the victim's authenticated browser to execute the Display Zone File request without the victim's knowledge or interaction.

This allows unauthorized actions to be performed on behalf of authenticated users.

## CVSS v3.1

Base Score: 4.5 (MEDIUM)

Steps to Reproduce

Log in with an attacker account.
Navigate to the Domain section.
Ensure at least one domain is present.
Go to Domain Settings → DNS Records.
Open another browser/private window and log in as a victim.
Ensure at least one domain is present in the victim account.
Return to the attacker account.
Trigger the Display Zone File functionality.
Capture the Display Zone File request using Burp Suite.
Use Burp Suite Engagement Tools to generate a CSRF PoC.
Save the generated HTML file.
Replace the attacker's domain_id with the victim's domain_id.
Open the modified PoC in the victim's authenticated browser.
Click Submit.
Observe that the victim's Display Zone File is opened successfully without the victim intentionally initiating the action.

Expected Behavior

The application should validate that the Display Zone File request was intentionally initiated by the authenticated user and should reject cross-origin forged requests without proper CSRF validation.

Actual Behavior

The application accepts the forged CSRF request and executes the Display Zone File action using the victim's active session without requiring any additional verification.

Impact

An attacker can force authenticated users to execute the Display Zone File action without their knowledge.

This may allow unauthorized exposure of domain DNS zone information and sensitive configuration details through the victim's active session.

Description

The application does not properly validate whether a Logs Refresh request is initiated by the authenticated user. By creating a malicious CSRF PoC and replacing the service_id with the victim's service ID, an attacker can force a victim's authenticated browser to execute the Logs Refresh action without the victim's knowledge or interaction.

This allows unauthorized actions to be performed on behalf of authenticated users.

Steps to Reproduce

Log in with an attacker account.
Navigate to the Services section.
Create a new service.
Open another browser/private window and log in as a victim.
Create a service in the victim account.
Return to the attacker account.
Trigger the Logs Refresh functionality.
Capture the Logs Refresh request using Burp Suite.
Use Burp Suite Engagement Tools to generate a CSRF PoC.
Save the generated HTML file.
Replace the attacker's service_id with the victim's service_id.
Open the modified PoC in the victim's authenticated browser.
Click Submit.
Observe that the victim's Logs Refresh action is executed successfully without the victim intentionally performing the action.

Expected Behavior

The application should validate that Logs Refresh requests are intentionally initiated by the authenticated user and should reject cross-origin requests without proper CSRF protection.

Actual Behavior

The application accepts the forged request and performs the Logs Refresh action using the victim's active session without requiring any additional validation.

Impact

An attacker can force authenticated users to execute Logs Refresh actions without their knowledge through a CSRF attack.
The attacker can repeatedly trigger Logs Refresh requests on behalf of the victim, potentially consuming the victim's available Logs Refresh quota/limit.
This may result in abuse of limited resources and prevent the victim from using the Logs Refresh functionality when needed.

Description

During testing, I discovered that when an owner creates a new user and assigns permissions, the user is immediately added to the organization without any invitation acceptance or verification step.

As a result, if an owner accidentally enters an attacker's email address and assigns a privileged role, the attacker gains direct access to the organization and its resources immediately after logging in.

This allows the newly created user to perform all actions associated with the assigned role without requiring approval or invitation acceptance.

Steps to Reproduce

Log in to the Owner account.
Navigate to Permissions.
Click Add User.
Enter a user's email address.
Assign all available permissions.
Click Create User.
Log in to the newly created user account.
Observe that the user is automatically added to the owner's organization with all assigned permissions.

Impact

If an owner mistakenly enters an attacker's email address while creating a user, the attacker immediately gains access to the organization with the assigned permissions.

When high-privilege permissions are assigned, the attacker may be able to access sensitive data, manage users, modify organization settings, and potentially delete or take full control of the organization.

Expected Behavior

Newly created users should be required to verify ownership of the invited email address and explicitly accept the invitation before gaining access to the organization.

Actual Behavior

The user is automatically added to the organization with the assigned permissions immediately after account creation, without any invitation acceptance step.

Description

During testing, I discovered that the application accepts an expired 2FA verification code.

After capturing the 2FA verification request, I waited until the code expired (after three code rotations). Even after expiration, replaying the same request was accepted by the server and resulted in successful authentication.

This indicates that the application does not properly validate the expiration time of 2FA verification codes.

Steps to Reproduce
Log in using a valid email address and password.
Enter the 2FA verification code.
Capture the 2FA verification request using Burp Suite.
Send the captured request to Burp Repeater.
Wait until the 2FA code has completed three rotations and is expired.
Send the request from Burp Repeater and observe a 302 Found response.
Forward the original intercepted request containing the same expired 2FA code.
Observe that the server again returns 302 Found and successfully authenticates the account.

Impact

An expired 2FA code can still be used to complete authentication, allowing an attacker who obtains an old 2FA code to bypass the intended expiration protection and gain unauthorized access to the account.

Expected Behavior

The server should reject any 2FA verification attempt using an expired code and require the user to enter a new valid code.

Actual Behavior

The server accepts a 2FA code even after it has expired and successfully authenticates the user.