All Projects

##Title: Improper Access Control in [admin.alwaysdata.com]

Summary:

A privilege escalation vulnerability was identified in the platform’s access control mechanism for managing specific paths related to site and SSL configurations. When a user is restricted from accessing a specific path within a site (sites path permission denied) but granted access to SSL management, they can still access a URL path intended for restricted site management at /site/xx/ssl. This bypasses intended access restrictions.

Description:

[Note that the path I mentioned to you does not appear to you when you are not given permissions to access the path (site)]

The platform enables administrators to set granular permissions, controlling what paths invited users can access or manage within a site. Two relevant permissions in this context are:

Path Management (sites): Grants access to manage certain paths related to a site.

SSL Management (ssl certificates): Grants access to manage SSL certificates.

There is a permissions inconsistency that allows users with SSL Management permissions, but without specific sites path permissions, to access the /site/xx/ssl path. This path resides within a restricted site-related path, yet contains SSL management functionalities. As a result, users can bypass restrictions on specific paths and potentially access or manipulate SSL settings.

##Link: [https://admin.alwaysdata.com/site/configuration/ssl/]
Steps to Reproduce:

1. Create a user account and assign SSL Management (ssl certificates) permissions, while explicitly denying access to the sites path.

2. Attempt to access the URL path: /site/xx/ssl.

3. Observe that access is granted to the SSL management path within the restricted sites path, despite restrictions on other paths under sites.

Expected Result:

The system should prevent access to paths under /site—including /site/xx/ssl—when specific path permissions are denied.

Actual Result:

The user can access /site/xx/ssl even though access to paths under /site is restricted, allowing them unintended access to certain SSL configurations tied to the site path.

##Proof of Concept: https://admin.alwaysdata.com/support/82440/384175-bandicam%202024-11-12%2004-13-20-975.mp4

Impact:

This vulnerability allows unauthorized users to bypass restrictions on certain paths and access SSL configurations. If exploited, this could lead to unauthorized manipulation of SSL settings, compromising the security integrity of site-related resources.

### Title:
Insecure Direct Object Reference (IDOR) Vulnerability: Unauthorized Commenting on Invisible Reports in [security.alwaysdata.com]

Note: I sent the vulnerability to [flyspray] They did not respond to the security report, and it has been a long time, So I had to send it to you.
—

#### Introduction
A security vulnerability has been identified in the site's report commenting feature, which allows unauthorized users to add comments to reports they should not have access to. This is due to an Insecure Direct Object Reference (IDOR) issue, compromising the integrity of sensitive data.

—

#### Steps to Reproduce
1. Create a New Report: Log in and create a new report.
2. Add a Comment: Use Burp Suite to intercept the HTTP request while adding a comment.
3. Modify the Report ID: Change the report ID in the request to one that is not visible to the public.
4. Submit the Modified Request: Forward the modified request through Burp Suite.
5. Check for Unauthorized Comment: Verify that the comment has been added to the invisible report.

##POC: To prove the concept, I commented on a report from my second account, and this report is not publicly available, Report number: 78
link: https://admin.alwaysdata.com/support/82086/382759-Screenshot_%D9%A2%D9%A0%D9%A2%D9%A4%D9%A1%D9%A0%D9%A2%D9%A4_%D9%A0%D9%A4%D9%A5%D9%A9%D9%A5%D9%A7_Kiwi%20Browser.jpg —

#### Impact
This IDOR vulnerability can lead to:
- Unauthorized Access: Users can manipulate and comment on reports they are not permitted to view.

Title: Two-Factor Authentication Bypass Issue in [admin.alwaysdata.com]

Summary: A vulnerability has been identified that allows an attacker to bypass Two-Factor Authentication (2FA) and manage applications on a user’s account. The attacker can create and delete applications on the account of the user who invited them.

Steps to Reproduce: 1. Create a new account.
2. Add a member to manage your account and activate Two-Factor Authentication (2FA) for that member.
3. Add an application to your account.
4. Log in to the account of the invited member.
5. Navigate to the following link: [https://admin.alwaysdata.com/site/application/script/].
6. Observe that you can create a new application and delete existing applications on the account of the original account holder.

POC: https://drive.google.com/file/d/1v5PbiZaZZK7l30XgdZx7025tsZnDOOf8/view?usp=drivesdk

Impact: Two-Factor Authentication Bypass

*Title: Unauthorized Email Sending Exploit in [alwaysdata.com] Summary: A vulnerability has been discovered in the site's email handling system. The site assigns each user a unique email address. However, it is possible to send an email from any email account, bypassing the intended email restrictions and validation mechanisms. Vulnerability Details: - Type: Email Spoofing
- Impact: Unauthorized email sending
- Affected Component: Email Handling System Description: The application generates a unique email address for each user. However, it is possible to exploit the system to send emails from any arbitrary email address. This issue arises due to insufficient validation of the email sender’s address. Proof of Concept: 1. Exploit Steps: - Use an email client or script to send an email through the application.
- Modify the "From" address to any arbitrary email address, not restricted to the user's assigned address. 2. Result: - The email is sent successfully. Follow the steps in the video: https://admin.alwaysdata.com/support/77431/376905-bandicam%202024-08-20%2003-19-32-375.mp4 Impact:**

This vulnerability allows an attacker to send emails appearing as if they are from any user.

*Title:*: Bypassing Email Address Restriction for Account Creation

*Description:*
The ban on an email can be bypassed

An example is the following e-mail address: "admin@alwaysdata.com"

*Steps to Reproduce:*
1. Attempt to create an account using a blocked email address. The system will display a message stating that the email address is blocked and prevent account creation.
2. Create an account using a different email address.
3. Once the account is successfully created, navigate to the account settings.
4. Change the email address of the account to the previously blocked email address.
5. Save the changes. The email address will be updated to the blocked one, bypassing the initial restriction.

*Impact:*
This issue allows users to circumvent email address restrictions.

*Recommendation:*
Implement server-side checks to ensure that email address restrictions are enforced consistently across all account management functionalities. Additionally, review the email update process to prevent such bypasses.

*POC:*

poc1: https://admin.alwaysdata.com/support/77431/375912-poc.22.png poc2: https://admin.alwaysdata.com/support/77431/375911-bandicam%202024-08-05%2009-36-57-769.mp4

*Title:* Account Creation and Impersonation Vulnerability in [admin.alwaysdata.com]

*Summary:*
It is possible to create a new account on the site using the domain name admin1@alwaysdata.com. After creating this account, the username can be changed to that of a legitimate site administrator. This vulnerability allows the account to generate support tickets and invite users, In this way he can defraud users.

*Steps to Reproduce:*
1. Register a new account on the site using the email admin1@alwaysdata.com , Or by any other name
2. Change the account username to that of a real site administrator.
3. Use the account to create a support ticket and invite users.

poc: https://admin.alwaysdata.com/support/77431/375910-poc.alwaysdata.png

*Impact:*
This vulnerability enables attackers to impersonate site administrators within the support system, Which enables the attacker to impersonate the administrators of the site and deceive users

*Recommendation:*
To mitigate this risk, implement restrictions to prevent the creation of accounts with administrative email domains.

*Title:* Insufficient Validation Allows Multiple Accounts Creation Under Single Subscription Plan

*Description:*
A vulnerability has been identified in the subscription management system which allows users to create multiple accounts under the same subscription plan. This issue can be exploited to bypass restrictions on the number of accounts per plan and gain unauthorized benefits.

*Steps to Reproduce:*

1. *Create an Account:*

1. Sign up for a new account with a specific subscription plan (e.g., "Free Plan").

2. *Create a Duplicate Account:*

1. Attempt to create another account using the same subscription plan as the first account.
2. Notice that the system does not prevent the creation of multiple accounts under the same subscription plan.

3. *Create a Similar Plan Account:*

1. From the newly created account, sign up for a subscription plan similar to the first account's plan.

4. *Send an Invitation:*

1. Send an invitation from the second account to the first account to become an admin of the plan created by the second account.

5. *Accept the Invitation:*

1. After accepting the invitation, the first account will now have two accounts under the same subscription plan.

I sent a proof of concept: https://admin.alwaysdata.com/support/77431/375639-poc.mp4

*Impact:*

This vulnerability allows users to circumvent subscription limitations by creating multiple accounts under the same plan

*Title: Critical Security Vulnerability: Unauthorized Account Deletion via Limited Permissions* in [admin.alwaysdata.com]

Summary:*
During my investigation, I discovered a significant security flaw in the system's account management feature.

*Description:*
The system allows users to invite others to manage their accounts with varying permissions, including the ability to enforce two-factor authentication (2FA) before accessing account management privileges.

*Vulnerability Details:*
I identified a vulnerability wherein an invited user, even without sufficient permissions or 2FA activation, can delete the inviting user's account from their own account. This deletion occurs regardless of whether 2FA was enabled during the invitation process.

*Steps to Reproduce the Bug:*
1. Create two accounts.
2. Invite a user to administer your account and enable 2FA.
3. From the invited user's account, delete the account of the inviting user.
4. Observe that the inviting user's account is permanently deleted, despite prior 2FA activation or the absence of sufficient permissions granted.

I sent proof of concept: https://admin.alwaysdata.com/support/77431/374527-bandicam%202024-07-17%2003-48-55-255.mp4

*Impact:*

This security vulnerability poses a significant risk to user accounts within the system. It allows an invited user, even with limited permissions and without activating two-factor authentication (2FA), to permanently delete the account of the inviting user. This action occurs despite security measures initially set up, such as 2FA activation during the invitation process or inadequate administrative permissions granted.

On-click Delete any invitation in [admin.alwaysdata.com]

*Summary:*
The [Create My Own Site] web application system is vulnerable to a click grabbing attack that allows an attacker to trick the user into deleting invitations that they have sent or received without their knowledge.

*Reproduction steps:*
1. Send an invitation to another user.
2. Receive an invitation and try it on the other account.
3. Get the direct link to the invitation and add the /cancel/ command to the URL.
4. Create an HTML proof-of-concept file with the following content:

Programming Language

<a href="https://admin.alwaysdata.com/transfer/Invitation_Number/cancel/----">Click</a>

5. Host this HTML page or send it via link to the victim.
6. Once the victim clicks on the masked link, the invitation is deleted without their explicit consent or knowledge.

An attacker could use their location and attach an HTML file instead of sending a file that the user clicks.

I have sent a proof of concept:
https://admin.alwaysdata.com/support/77431/374245-bandicam%202024-07-14%2007-00-17-624.mp4

*Impact:*
The exploit allows the deletion of any invitation that the user has sent or reached another user without his consent.

*Vulnerability Summary: Unauthorized Account Takeover via Invitation Exploitation in [admin.alwaysdata.com] Vulnerability Description: A critical security vulnerability was identified in the account invitation process of [Service that allows the user to create a site]. This vulnerability allowed an unauthorized user to gain administrative control over another user's account through the invitation feature. Below is a detailed timeline of events leading to the account takeover: 1. Account Creation: - A user (referred to as User A) created an account on [Service that allows the user to create a site]. 2. Incorrect Invitation: - User A intended to invite a member to become an administrator but mistakenly sent the invitation to another user (User B). 3. Invitation Deletion: - Realizing the mistake, User A promptly deleted the invitation intended for User B. 4. Correct Invitation: - User A subsequently invited their colleague (referred to as User C) to become an administrator of their account. 5. Acceptance by Colleague: - User C accepted the invitation, assuming administrative rights as intended by User A. 6. Unauthorized Acceptance: - Meanwhile, User B, who received the initial invitation in error, noticed the invitation and, potentially unaware of the implications, accepted it. 7. Account Takeover:**

1. By accepting the invitation, User B gained administrative access to User A's account, effectively taking ownership of the account.

I've sent a proof of concept: [REDACTED]

Impact:
Account Takeover

*Title:* Two-Factor Authentication Bypass via Support Ticket Creation in [admin.alwaysdata.com]

*Summary:*
A critical security vulnerability has been identified in the [admin.alwaysdata.com]'s account management system where a user with administrative privileges but mandated to use two-factor authentication (2FA) can bypass this requirement by initiating a support ticket under the name of the primary account holder without triggering 2FA.

*Description:*
This vulnerability allows an added user, who is supposed to be restricted by 2FA, to perform actions appearing as the primary account holder by submitting support tickets. This circumvents the security protocol intended to protect sensitive account operations via 2FA, potentially leading to unauthorized actions without the account holder's consent or knowledge.

*Steps to Reproduce:*
1. Create two user accounts, Account A (primary) and Account B.
2. From Account A, add Account B as another user with full administrative privileges but enforce 2FA on actions.
3. Log into Account B.
4. Navigate to the support section and initiate a support ticket, selecting Account A as the affected account.
5. Submit the ticket without being prompted for 2FA verification.

I sent a proof of concept : https://admin.alwaysdata.com/support/77431/367474-VID-20240423-WA0000.mp4

*Impact:*
The primary account holder's security is compromised as the added user can perform sensitive operations under their guise without completing the necessary 2FA checks. This vulnerability may lead to unauthorized access and control over the primary account's sensitive functions and data.

*Title:* Clickjacking (On-click) Vulnerability in Support Ticket Attachment Deletion in [admin.alwaysdata.com]

*Summary:*
The support ticket system of the web application is vulnerable to a clickjacking attack that allows an attacker to trick a user into deleting attachments from their support tickets unknowingly.

On-click Delete any attachment for users in support tickets Delete any attachment for users in technical support tickets

*Steps to Reproduce:*
1. Create a support ticket in the application.
2. Attach a file to the support ticket.
3. Obtain the direct link of the attachment and append the /delete/ command to the URL.
4. Create an HTML proof-of-concept file with the following content:

html

  <a href="https://admin.alwaysdata.com/support/----/delete/----">click</a>

5. Host this HTML page or send it via link to the victim.
6. Once the victim clicks on the disguised link, the attachment is deleted without their explicit consent or knowledge.

An attacker can use his location and attach an html file instead of sending a file that the user clicks on.

*Impact:*
The exploit enables unauthorized deletion of any attachment from user-created support tickets. This can result in loss of critical data and potential breach of information security, affecting data integrity and user trust.

This is in addition to this report as I explained in another way but I remembered now that the attacker had to delete any technical support ticket in the way I explained in this report
link: https://security.alwaysdata.com/task/24

No Rate Limit On Reset Password in admin.alwaysdata.com

welcome all :
i found that no rate limit in reset password in ::: https://admin.alwaysdata.com/password/lost/ Summary:
No rate limit check on forgot password which can lead to mass mailing and spamming of users and possible employees
A little bit about Rate Limit:
A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache.
Steps To Reproduce The Issue
1- create account and go to reset password
2- intercept burp and send request to intruder
3- make payload and start attack

Impact
1- Attacker could use this vulnerability to bomb out the email inbox of the victim.
2- Attacker could send Spear-Phishing to the selected mail address.
3-Causing financial losses to the company

unverified password change in [admin.alwaysdata.com]

Hello team!

I have found an interesting flaw where an attacker can change the account password without knowing the old password

When the user requests a password reset link, it accesses the activity log inside the account and this bug can be exploited by an attacker

Steps to reproduce the bug :

1-Create a new account on [admin.alwaysdata.com]
2-log in to your account
3-request the password reset link from another browser
4-you will notice that the password reset link you requested has arrived in the activity log

Impact :
If the attacker hijacks the session or gains access to the user account, he can request a password reset link and the link will reach him in the Account Activity Log, from which he can reset the account password without knowing the old password

Title: Security Report: Public Exposure of Sensitive Information

Introduction:
The purpose of this report is to highlight a critical security issue involving the public exposure of sensitive information on the website security.alwaysdata.com. The exposed data includes details about supervisors, the number of reports they have sorted, and some reports that remain unprocessed and may contain sensitive information and unpatched vulnerabilities.

Exposure of Supervisor Information:
The website security.alwaysdata.com hosts a page that displays information about all users, including supervisors. The URL format for accessing supervisor information is https://security.alwaysdata.com/user/1. By manipulating the numeric value in the URL, it is evident that any user can access information about all users and supervisors on the site. This unrestricted access poses a significant security risk as it allows unauthorized individuals to view sensitive user data, potentially compromising the privacy and security of the users and the platform as a whole.

Unsecured Reports:
Furthermore, the website contains reports that are in an unprocessed state and have not been closed. These reports are accessible to the public through the URL format https://security.alwaysdata.com/task/23?dev=1. The presence of such reports in an open state poses a severe security threat as they may contain sensitive information that should not be shared with regular users. Additionally, these reports may reveal unpatched vulnerabilities in the platform, further increasing the risk of exploitation by malicious actors.

Recommendations:
1. Immediate Restriction of Access: It is imperative to implement access controls to restrict public access to supervisor information and unprocessed reports. Access should be limited to authorized personnel with appropriate privileges.

2. Review and Remediation: All unprocessed reports should be reviewed to identify and address any sensitive information or vulnerabilities they may contain. Once remediated, these reports should be appropriately secured and closed.

3. Security Awareness Training: Conduct security awareness training for all personnel involved in managing and maintaining the website. Emphasize the importance of safeguarding sensitive data and the potential consequences of data exposure.

4. Regular Security Audits: Implement regular security audits to identify and address any potential security loopholes, including unauthorized access to sensitive information and unsecured reports.

Conclusion:
The public exposure of supervisor information and unsecured reports on security.alwaysdata.com poses a significant security risk, potentially compromising user privacy and platform integrity. Immediate action is necessary to address these vulnerabilities and ensure the confidentiality and security of user data. Failure to mitigate these risks could lead to severe repercussions for the organization and its users.

Security Report:Broken Access Control (BAC) refers to a security vulnerability where users are able to access or manipulate resources that they are not authorized to

Introduction:
Broken Access Control (BAC) refers to a security vulnerability where users are able to access or manipulate resources that they are not authorized to. In this report, we will discuss an instance of BAC where a user is able to delete a technical support ticket to which they have been invited, even though they do not have the necessary permissions to do so.

The user who is added to the ticket does not have the permission to delete the ticket, he is not the one who created it.

Command used to delete:https://admin.alwaysdata.com/support/"Ticket_Number"/delete/

Steps to reproduce the bug:

1- Open a technical support ticket
2- Add a user with you in the ticket
3- Try the delete order I sent you
4- You will notice that the invited user can delete the ticket completely and this is not his prerogative

Impact:
The impact of this vulnerability is significant as it compromises the integrity and confidentiality of the technical support system. Unauthorized deletion of tickets can lead to loss of important information, disruption of support services, and potential security breaches if sensitive information is contained within the tickets.