Security vulnerabilities

Subject: Business Logic Flaw

Dear Security Team,

I trust this message finds you well in safeguarding our digital domain. I have successfully conducted a penetration test and am pleased to present the detailed findings in the attached report below.

Vulnerability Details:

Type: Business Logic Flaw
Severity: Medium
Vulnerable Endpoint: https://admin.alwaysdata.com/admin/account/add/ Description: The vulnerability enables attackers to bypass the restriction limiting the creation of only one Free Public Cloud (100MB). By exploiting this vulnerability, known as a race condition, an attacker can create more than 1 instances of the Free Public Cloud (100MB), potentially leading to resource abuse and unauthorized usage.

Reproduction Steps:
Log into the attacker’s account.
Remove all previous accounts from the attacker’s main account.
Attempt to add 2 Free Public Cloud (100MB), which will fail due to the existing function limitation.
To bypass this limitation, delete all Free Public Cloud (100MB) instances and capture the request to add a Free Public Cloud (100MB) using BurpSuite.
Duplicate the captured request in multiple tabs and modify the account names in each request.
Group all the requests and configure them to be sent in parallel (Single Packet Attack) in BurpSuite.
This will result in the addition of more than one Free Public Cloud (100MB).
Proof Of Concept:

Image & video-based POC is connected to the email.

Impact:

The impact of this vulnerability is significant as it allows attackers to bypass restrictions and manipulate the system to their advantage. By exploiting this flaw, attackers can create multiple instances of the Free Public Cloud (100MB), despite the intended limitation of only one. This can lead to several adverse consequences

Mitigations:
Increased resource usage and financial losses.
Risks of data breaches and damage to reputation.

NOTE: THESE ATTACKS HAVE BEEN DONE WHILE KEEPING SERVER’S SECURITY IN MIND, ENSURING THAT THE SERVER DOES NOT INCUR ANY DAMAGE. THIS ATTACK HAS BEEN PERFORMED WITH CAUTION.

Regards,
Zeeshan Beg

Google Drive POC Link : https://drive.google.com/file/d/1qz6s7g6l1dYsF1aq3PpAoIyzeodZTUBx/view?usp=sharing

Vulnerability Detail

PHPpgAdmin setup page is accessible over the internet in which it's possible for the user setup the servers with required details.

Vulnerable Endpoints

https://phppgadmin.alwaysdata.com/phppgadmin/redirect.php?subject=root You can add a server via this endpoint
https://phppgadmin.alwaysdata.com/phppgadmin/redirect.php?subject=server&server=&

Impact Its possible for an attacker to configure the servers without information of the application adminstrator.

Vulnerability Git Configuration Exposure

Severity Level Critical

Vulnerable Domain:
https://upload.alwaysdata.com/.git/config

1. Executive Summary: The Git Configuration Exposure vulnerability poses a significant threat to web applications, allowing unauthorized access to sensitive source code repositories. Through the discovery of exposed .git/ directories, attackers can leverage this information to extract the complete source code of a website. This breach can result in the unauthorized disclosure of sensitive information, including proprietary code, configuration files, and other critical assets. This executive summary outlines the discovery, impact, and recommended mitigation strategies for this vulnerability.

2. Overview The vulnerability arises when an attacker identifies the presence of a .git/config directory. This discovery provides a direct route to the Git repository of a web application. By employing specialized tools such as those available in Kali Linux, an attacker can download the entire source code of the website, gaining access to proprietary code, scripts, and configuration files. The consequences of this exposure extend beyond the compromise of intellectual property to potential security risks and the unauthorized retrieval of sensitive information.

3. Vulnerability Discovery The vulnerability is discovered through directory research, where the presence of a .git/config directory is identified. Attempts to access this directory reveal the underlying Git repository, providing a pathway for unauthorized individuals to exploit the exposed version control system.

4. Impact Unauthorized Access to Source Code: Attackers can download the complete source code of the website, enabling the extraction of proprietary code, scripts, and configuration files.
Intellectual Property Theft: The compromise of source code poses a significant risk of intellectual property theft, potentially leading to unauthorized use or distribution.
Sensitive Information Exposure: The extracted source code may contain sensitive information, such as API keys, database credentials, and other critical data, compromising the overall security of the web application.

5. Mitigation Strategies

Git Configuration Hardening: Implement strict access controls and configure Git repositories to restrict access to authorized personnel only.
Directory Listing Prevention: Disable directory listing to prevent the exposure of .git directories during web server configuration.
Git Repository Hosting Security: If using third-party Git repository hosting services, ensure proper access controls are in place, and sensitive information is not exposed.

6. Steps To Reproduce:

1- Visit this URL = https://upload.alwaysdata.com/.git/config 2- You can see the Config file.
3- Using the gitdumper tool, in which I was able to dump the whole .git directory.
4- Boom!! I have access to the whole source code of the application.
4- Command
–> ./git_dumper.py https://upload.alwaysdata.com/.git/ your/any/directory/of/kali

Important Note: Another thing I'd like to share with you is that I haven't extensively exploited this vulnerability. Otherwise, I could have easily downloaded the entire website's source code, which often contains many and many sensitive information.

Proof of concept As you can see that I am able to access the entire source code. Now, if I put the output command to my command, I can download the whole source code.

[-] Testing https://upload.alwaysdata.com/.git/HEAD [200]
[-] Testing https://upload.alwaysdata.com/.git/ [403]
[-] Fetching common files
[-] Fetching https://upload.alwaysdata.com/.git/hooks/commit-msg.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-commit.sample [200]
[-] Fetching https://upload.alwaysdata.com/.gitignore [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/applypatch-msg.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/COMMIT_EDITMSG [404]
[-] https://upload.alwaysdata.com/.git/COMMIT_EDITMSG responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/hooks/post-commit.sample [404]
[-] https://upload.alwaysdata.com/.git/hooks/post-commit.sample responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-push.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-rebase.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-receive.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/index [200]
[-] Fetching https://upload.alwaysdata.com/.git/info/exclude [200]
[-] Fetching https://upload.alwaysdata.com/.git/objects/info/packs [404]
[-] https://upload.alwaysdata.com/.git/objects/info/packs responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/hooks/update.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/prepare-commit-msg.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/post-receive.sample [404]
[-] https://upload.alwaysdata.com/.git/hooks/post-receive.sample responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/hooks/post-update.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-applypatch.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/description [200]
[-] Finding refs/
[-] Fetching https://upload.alwaysdata.com/.git/info/refs [404]
[-] https://upload.alwaysdata.com/.git/info/refs responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/ORIG_HEAD [404]
[-] Fetching https://upload.alwaysdata.com/.git/config [200]
[-] https://upload.alwaysdata.com/.git/ORIG_HEAD responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/FETCH_HEAD [404]
[-] https://upload.alwaysdata.com/.git/FETCH_HEAD responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/logs/HEAD [200]
[-] Fetching https://upload.alwaysdata.com/.git/packed-refs [200]
[-] Fetching https://upload.alwaysdata.com/.git/refs/heads/master [200]
[-] Fetching https://upload.alwaysdata.com/.git/refs/remotes/origin/master [404]
[-] https://upload.alwaysdata.com/.git/refs/remotes/origin/master responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/refs/stash [404]
[-] https://upload.alwaysdata.com/.git/refs/stash responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/refs/remotes/origin/HEAD [200]
Many More File will be Fatched…..!

Vulnerable URL's: https://files.alwaysdata.com/ https://files.alwaysdata.com/migrations/ https://files.alwaysdata.com/migrations/software-2017/ https://files.alwaysdata.com/migrations/software-2020/

Summary:

The vulnerability was discovered during security testing when the directory listing feature of a web server listed the xapian-7.3.so file among its contents. Given that xapian-7.3.so is a shared object file for Xapian, a highly versatile search engine library, its exposure poses significant security risks. This file contains compiled code that is executed within the server context, making it a critical component of the search functionality offered by the hosting server.

Impact:

The inadvertent exposure of xapian-7.3.so could have several potential impacts:

Information Disclosure: Malicious actors could download and analyze the shared object file to uncover proprietary algorithms or specific implementations of the search engine, leading to a competitive disadvantage or privacy violations.
Security Vulnerability Exploitation: If any vulnerabilities exist within the specific version of the file, attackers could develop exploits to compromise the server or manipulate search engine results.
Service Disruption: In scenarios where the file is not merely exposed but also manipulable or deletable, attackers could disrupt the search functionality, leading to denial of service.

Mitigation

Immediate steps should be taken to mitigate the vulnerability:

Disable Directory Listing: Configure the web server to disable directory listing globally or specifically within directories not intended for public access.
Access Controls: Implement proper access controls to ensure that sensitive files, such as xapian-7.3.so, are not accessible via the web server to unauthorized users.
Security Patches: Ensure that all components, especially exposed ones like xapian-7.3.so, are regularly updated to the latest versions to mitigate known vulnerabilities.

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

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

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

Bug Title: Prototype Pollution Vulnerability Report
Weakness: Prototype Pollution
Hello Web Security Team,

I am reporting a security vulnerability on the website https://www.alwaysdata.com/en/ The website is affected by prototype pollution due to the usage of an outdated jQuery version.

Description:
The website uses jQuery version 1.12.4, which is susceptible to prototype pollution. This vulnerability allows an attacker to inject properties into Object.prototype, affecting all objects across the application. Notably, the "deep" version of jQuery $.extend is impacted.

Steps To Reproduce:
1. To check if the application is vulnerable to prototype pollution attack we can use the below command:

command: $.extend(true, {}, JSON.parse('{"__proto__":{"polluted":"hacked"}}'));

2. Now let's open the application URL: https://www.alwaysdata.com/en/ and enter into the developer options Console tab and paste the command and hit enter.
Notice that the result contains an option with polluted: hacked

Image:
https://ibb.co/VxyNw4z

Impact:
Prototype pollution introduces a severe risk to the application. An attacker, upon exploiting this vulnerability, can manipulate default values for options passed to functions with an "options" argument—a common pattern in JavaScript applications. The impact escalates based on the application's use of such options, potentially leading to unauthorized modifications and alterations in the application's behavior.

Supporting Material/References:
https://hackerone.com/reports/380873 https://hackerone.com/reports/454365 The vulnerability has been verified on jQuery version 1.12.4, and it is likely to affect older versions.
The issue is present when using Chrome latest version.

Fix:
Update latest version of jquery 3.7.1 is the best remediation as it has no known vulnerabilities at the time of this writing

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

Hi,
During google search I have found an Open sensitive git directory.
Git metadata directory (.git) was found in this folder. An attacker can extract sensitive information by requesting the hidden metadata directory that version control tool Git creates. The metadata directories are used for development purposes to keep track of development changes to a set of source code before it is committed back to a central repository (and vice-versa). When code is rolled to a live server from a repository, it is supposed to be done as an export rather than as a local working copy, and hence this problem.
Vulnerable URL:-
https://upload.alwaysdata.com/.git/ (403 forbidden)
bypass
https://upload.alwaysdata.com/.git/config https://upload.alwaysdata.com/.git/logs/HEAD

https://security.alwaysdata.com/.git/ (403 forbidden)
bypass
https://security.alwaysdata.com/.git/config https://security.alwaysdata.com/.git/logs/HEAD

These files may expose sensitive information that may help a malicious user to prepare more advanced attacks.
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)
Thanks

Description

A vulnerability has been discovered in the student management system, which allows a normal user account to bypass access controls. ANY registered low-level user, with no knowledge or involvement in a class, can globally detach any student involved just by manipulating the UID. Even without tutorship/academic privileges and regardless of tutor access control.

Impact

A malicious attacker could fuzz predictable UID values and remove multiple students, abusing the privesc as a nuisance.

Proof-of-Concept

1) First, we logged in to an actual tutor account where I've added a few students. Next, I take note of the IDs of each student involved.

2) Then, I logged out and just to validate this exploit, I would create a NEW account.

3) This is the vulnerable endpoint:

https://admin.alwaysdata.com/academic/release/<USER_ID>

I replaced the <USER_ID> param with the various IDs I recorded from the tutor account.

4) Visit these URLs on the new account and observe the results.

5) Then, log out and re-login to the tutor account. Visit https://admin.alwaysdata.com/academic/ and confirm poc validity.

Mitigation

Implement proper access controls and role-based permissions to restrict normal users from utilizing global admin/tutor privileges. Conduct a thorough review of the authentication and authorization processes to ensure that no other similar vulnerabilities exist.

POC video: https://file.io/DRmuH2Qk7wZk

Description

I identified a vulnerability in the SSH function of admin.alwaysdata.com, where the home directory setting is vulnerable to server path traversal.

Proof-of-Concept

1. Login to your account and visit https://admin.alwaysdata.com/ssh

2. Edit the home directory from '/' to '/../../../../../../'

3. Next, save the settings and login to your SSH shell. Type ls. You'll discover your path has been traversed.

4. Access the /alwaysdata/etc/passwd folder to view the admin superusers. More information of other users are also available throughout the server.

For example;

/var/lib/extrausers/passwd shows all the other registered users on the server.

/usr/lib/python3/dist-packages/fail2ban/tests/files/logs/postfix display failban logs.

Other interesting files;

/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/.htpasswd

/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/.htpasswd

Mitigation

Restrict access to any parent directory, other than the container being run.

Description

A vulnerability exists on the https://admin.alwaysdata.com/ permissions_delete endpoint which is intended for deleting sub-accounts' generated data or permissions. However due to unsecure design, it can also be used to remove critical permissions or access controls of the owner account, rendering the account useless.

Proof-of-Concept

1. Visit this URL: https://admin.alwaysdata.com/permissions/<owner-id>/delete/ (Replace owner-id with the the id of main account, that is, the one with 'impossible deletion')

2. This renders the account useless. But permissions can still be reinstated using the following request

POST /permissions/<account-id>/ HTTP/2
Host: admin.alwaysdata.com
Cookie: csrftoken=nHI6Qy3zJu9uxxxqNvXRuZlTuvgLJwbBI5jg4XRa; django_language=en; sessionid=tdcg6j9im2g31ga9tk7
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.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, br
Referer: https://admin.alwaysdata.com/permissions/
Content-Type: application/x-www-form-urlencoded
Content-Length: 314
Origin: https://admin.alwaysdata.com


csrfmiddlewaretoken=U0CcqjIPBxxxxxxxxxxxx2zGI69d7GFBI5AKORMPsTJlk1SfgDJZ5t&csrfmiddlewaretoken=U0CcqjIPBxxxxxxxxxxxxxxxx7GFBI5AKORMPsTJlk1SfgDJZ5t&email=<EMAIL>&customer_account=on&customer_contact_billing=on&customer_full_accounts=on&customer_full_servers=on&account=<USERID>

Mitigation

Ensure that only authorized admin can access and modify owner permissions through the delete endpoint. This can be achieved by implementing authentication and authorization mechanisms.

Description

I discovered that cAdvisor, a container monitoring and management tool, is exposed to the public internet. Using OSINT techniques, this endpoint was discovered on one of the company servers. This information disclosure could potentially be used by attackers for various malicious purposes, such as mapping vulnerable targets or launching further attacks.

Proof-of-Concept

To demonstrate this issue, we can access the cAdvisor web interface via the URLs;
http://185.31.41.177:8000/containers/ http://185.31.41.177:8000/metrics/ http://185.31.41.177:8000/api/v1.0/machine http://185.31.41.177:8000/containers/user.slice http://185.31.41.177:8000/containers/system.slice

Browse through the URIs for more information on processes running, users involved, resource usage, container names e.t.c.

Mitigation

Restrict access to cAdvisor. Limit access to the cAdvisor interface to trusted users or networks only.

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

Details: Upon accessing the URL endpoint https://blog.alwaysdata.com/wp-json/wp/v2/users/, the website returns a JSON response containing information about registered users, including usernames. This exposes user account details to anyone who accesses the endpoint, without requiring authentication.

Impact: The username disclosure vulnerability poses a significant risk to the security and privacy of users on the https://blog.alwaysdata.com website. Attackers can use the exposed usernames to attempt unauthorized access to user accounts, conduct targeted phishing attacks, or perform further reconnaissance to exploit additional vulnerabilities.

Recommendations:

  Immediate Mitigation: Disable public access to the /wp-json/wp/v2/users/ endpoint to prevent unauthorized users from obtaining a list of user accounts.

  Patch Deployment: Implement a security patch or update provided by the website’s developers to address the username disclosure vulnerability.

  User Notification: Inform registered users of the vulnerability and advise them to change their passwords as a precautionary measure.

  Security Audit: Conduct a comprehensive security audit of the website to identify and remediate any additional vulnerabilities that may exist.

Additional Information: This report aims to assist in promptly addressing the username disclosure vulnerability on the https://blog.alwaysdata.com website to safeguard user data and mitigate potential security risks. Urgent action is recommended to prevent exploitation and protect the website’s users from unauthorized access to their accounts.

Please feel free to reach out if further assistance or clarification is needed.

Sincerely, Nilesh
nilesh56466@gmail.com

Vulnerability Name: No Rate Limit in adding Sites

Impact:
- This may consume a large amount of bandwidth and, sometimes, require large amounts of storage space.

How to reproduce this issue:

1. Use Burp Suite and capture the Sites request.

2. Send the captured request to Intruder and select name position as shown in POC.

3. Set payloads to numbers and numbers will be from 1 to 40 (depending on your usage).

4. Observe that the status code is 302 means we can add an unlimited Sites.

Recommendation:
1. There should be some rate limit for Add Sites (Example: should not exceed more than 10 Sites)

2. Implement Captcha, the captcha should not be based on IP.

POC:
- Video file in below link.
- Link: https://www.mediafire.com/file/q9ir608diysdnhj/Always+Data+Poc-1.mp4/file https://mediafire.com/file/q9ir608diysdnhj/Always+Data+Poc-1.mp4/file

Title: Security Report: Public Exposure of Sensitive Information

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

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

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

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

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

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

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

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

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

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

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

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

Steps to reproduce the bug:

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

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

Subject: Vulnerability Report: Transmission of Credentials in Plain Text on Alwaysdata.com

Dear Security Team,

I hope this email finds you well. I am writing to report a security vulnerability that I discovered on the Alwaysdata.com platform regarding the transmission of credentials in plain text during the login process. This vulnerability poses a significant risk to the security and privacy of users' accounts and sensitive information.

Vulnerability Details:

Vulnerability Type: Transmission of Credentials in Plain Text
Website: https://www.alwaysdata.com/ Description:
During testing of the login process on the Alwaysdata.com platform, I observed that user credentials (email and password) are transmitted in plain text or with minimal obfuscation. While the CSRF token appears to be encrypted, the email and password fields are transmitted without proper encryption, making them susceptible to interception and potential exploitation by malicious actors.

Steps to Reproduce:

Navigate to the Alwaysdata.com login page.
Enter valid login credentials (email and password).
Intercept the login request using a tool such as Burp Suite.
Analyze the intercepted request to observe that the email and password are transmitted in plain text or with minimal obfuscation, while the CSRF token is encrypted.

Impact:

Unauthorized Access: Attackers can intercept and extract user credentials, potentially leading to unauthorized access to user accounts and sensitive information.
Account Takeover: Malicious actors can exploit the vulnerability to gain unauthorized control over user accounts, posing a risk to the security and privacy of affected users.
Data Breach: The transmission of credentials in plain text exposes users' sensitive information to interception, increasing the risk of data breaches and privacy violations.

Severity:

The severity of this vulnerability is considered critical due to the potential for unauthorized access, account takeover, and data breaches. It undermines the security and trustworthiness of the Alwaysdata.com platform and poses significant risks to its users.
Recommendation for Mitigation:
To mitigate this vulnerability, I recommend the following actions:

Implement HTTPS encryption for all pages, especially those involving sensitive operations like login.
Ensure that all user credentials, including email and password, are transmitted securely using encryption techniques such as TLS.
Implement strong authentication mechanisms, such as multi-factor authentication (MFA), to enhance the security of user accounts.
Conduct regular security assessments and audits to identify and address vulnerabilities in the platform's security controls.
I believe that addressing this vulnerability promptly is crucial to ensuring the security and privacy of users' accounts and sensitive information on the Alwaysdata.com platform. I am available to provide further assistance or clarification on this matter if needed.

Thank you for your attention to this report, and I look forward to your prompt response and actions to address this vulnerability.

Sincerely,
Neel Shukla
Shuklaneel525@gmail.com

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.

Summary:
A potential security vulnerability has been identified in the user invitation token generation process when integrated with a third-party service. This vulnerability could lead to the leakage of user invitation tokens, potentially exposing sensitive information and compromising the security of user accounts.

Details:
Vulnerability Type: Information Disclosure
Affected Component: User invitation token generation integrated with third-party service
Severity: High
Description:
During our security assessment, it was discovered that the user invitation token, which is generated as part of the user invitation process, is not adequately protected when interacting with a third-party service. This oversight allows unauthorized access to the token, leading to potential exposure of sensitive information.

Steps to Reproduce:
1.Login into the account.
2.Go to the invite user function and add the email which you want to invite.
3.A token is received to that email for joining the team.
4.Keep your proxy on and click on the invitation link.
5.Set the password and you have successfully joined the team.
6.Now go back to your burp suite and search for the invitation token which is received on the step3.
7.You will notice that the token got leaked into third parties also.

Impact:
If exploited, this vulnerability could allow an attacker to gain unauthorized access to user accounts, potentially leading to data theft, unauthorized access to sensitive information, and other malicious activities.

Recommendations for Mitigation:

Token Encryption: Implement encryption mechanisms to protect user invitation tokens during transmission to and from the third-party service.
Secure Transmission: Ensure that communication channels between your system and the third-party service are secure, using protocols such as HTTPS.
Token Expiry: Implement token expiration mechanisms to limit the window of opportunity for exploitation.
Audit Access Logs: Regularly audit access logs for any suspicious activities or unauthorized access.

Proof of Concept (PoC):
Include relevant information or details demonstrating the vulnerability, ensuring that no sensitive information is disclosed in the report.

I appreciate your prompt attention to this matter and look forward to working collaboratively to address and resolve this security vulnerability.

Thank you.

Aditya

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.

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

Hello support teams,

I hope this email finds you well. I am Devansh.I am a security researcher and I am writing to bring to your attention a security vulnerability that I have discovered on your website.

Report of bug is as follows:

Vulnerability name: .git file exposed

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

Overview of the Vulnerability

The danger occurs when the application leaves the “. git” directory, which is in the system root, exposed. By carelessness, an application that uses Git for versioning can expose the “. git” directory.

Steps to Reproduce

1. open this website in the browser https://cdn.anscommerce.com/.git/config

2. you can see the git file is open

3 .by the dotgit extension you can download the git file

It can be exploited more but may cause harm to your website

Impact of the vulnerability

git folder is required to log every commit history and every other information required for your remote repository, version control, commits etc. These things are saved in different folders which have different meanings. Once the folder is created, open it and see the

References :

https://medium.com/stolabs/git-exposed-how-to-identify-and-exploit-62df3c165c37

https://www.acunetix.com/vulnerabilities/web/git-detected/

Please consider this as an urgent matter and prioritize the resolution of this vulnerability . if you require any additional information or assistance. Do let me know

Thank you for your attention to this matter, and I look forward to hearing from you soon.

Regards
Devansh

Hello support teams,
I hope this email finds you well. I am Devansh . I am a security researcher and I found a vulnerability in your website.

bug name : Lack of password confirmation on account deletion

Description: the user account can be deleted without confirming user password or re authentication.
The removal of an account is one of the sensitive parts of any application that needs to be protected, therefore removing an account should validate the authenticity of the legitimate user.

steps to reproduce:

1. Go to account settings and click on delete account.

2. There will be a next page where I click on delete my account now option.

3. You will see the message of account has been deleted and get logged out

Remediation:
System must confirm authentic user before performing such task. A link can be sent to the user email id that can be used for delete operation. Otherwise user password should be provided to the application to confirm the entity identity.

It seems to be of very low impact,but consider a situation when a user forgets to logout from his account or someone gets access to his phone and deletes the account. This situation is more severe than account takeover as there is no way to get an account again. All the save information and data including previous record, card information etc can be deleted.

video poc is attached

Thanks and regards
Devansh

https://