|
26 | #1 Crititical Vulnerability Name: No Rate Limit in addi ... | Closed | 06.02.2024 |
Task Description
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
|
|
31 | Broken Access Vulnerability via 'Impossible deletion' E ... | Closed | 16.02.2024 |
Task Description
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.
|
|
80 | Bug bounty - MTA-STS Record Not Found for Domain | Closed | 23.09.2024 |
Task Description
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
|
|
21 | Bug Bounty Report | Closed | 04.02.2024 |
Task Description
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
|
|
85 | Bug Report: XSS Vulnerability via File Upload | Closed | 24.10.2024 |
Task Description
### 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.
|
|
45 | Bug Title: Missing access control at password change. | Closed | 09.04.2024 |
Task Description
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
|
|
38 | Bug Title: Prototype Pollution Vulnerability Report | Closed | 19.03.2024 |
Task Description
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
|
|
74 | Bypassing Two-Factor Authentication via Account Deactiv ... | Closed | 02.09.2024 |
Task Description
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
|
|
70 | ClickJacking Leads to deletion of user profile | Closed | 17.08.2024 |
Task Description
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.
|
|
48 | Clickjacking (On-click) Vulnerability in Support Ticket ... | Closed | 24.04.2024 |
Task Description
*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
|
|
52 | Direct IP Access of the Domain on HTTP | Closed | 05.06.2024 |
Task Description
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
|
|
41 | Directory Listing of Unauthorized Xapian Files | Closed | 27.03.2024 |
Task Description
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.
|
|
69 | EXIF metadata not stripped | Closed | 17.08.2024 |
Task Description
Summary: When uploading images in ticket option, the EXIF metadata is not removed or changed in any way. Description: When answering in the ticket, you can upload a file, and if you upload an image with EXIF metadata on it, it isn't stripped. This can lead to disclosure of location where photo was taken or other personal information by the photo uploader if their group is public, as anyone can download the logo and check the metadata. Steps To Reproduce: 1) Create a ticket. 2) Upload an image with exif metadata. 3) Now, download the same image and check the metadata.
Link to POC: https://drive.google.com/file/d/1KflN8xTcF6Gq-0x1wo-n65KkT9ScNHMl/view?usp=sharing
|
|
42 | Git Configuration Exposure | Closed | 27.03.2024 |
Task Description
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…..!
|
|
18 | .git file exposed | Closed | 18.01.2024 |
Task Description
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
|
|
35 | Git Folder Forbidden Bypass | Closed | 22.02.2024 |
Task Description
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
|
|
47 | information disclosure | Closed | 13.04.2024 |
Task Description
i found this detial in one of the git file on https://security.alwaysdata.com/.git/config
and this file contains 0000000000000000000000000000000000000000 58bea729f4359a45f69aaba274bb2a931155b427 Cyril Baÿ cbay@alwaysdata.com 1704809861 +0100 clone: from https://github.com/flyspray/flyspray.git
this information in the master named file which i think is sensitive as it disclosing the email address and other stuff also other files like config and packed-refs contain sensitive information , but its all on you to decide weather the information is sensitive or not contact me on my email bhavishthakral123@gmail.com
|
|
30 | Information Disclosure on cAdvisor software via Origin ... | Closed | 16.02.2024 |
Task Description
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.
|
|
43 | Information Disclosure PHPpgAdmin | Closed | 03.04.2024 |
Task Description
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.
|
|
64 | Insecure Account Deletion | Closed | 22.07.2024 |
Task Description
Summary: The removal of account is one of the sensitive part of a web application that needs to protect, therefore removing an account should validate the authenticity of the user, however i have found that when removing an account, the system did not require the user to input the account password. Steps To Reproduce: 1.Create an account on https://alwaysdata.com 2.Go to My account section DELETE ACCOUNT. 3.Click on delete and you will see it will delete the account without any kind of verification or password confirmation.
Impact Exploit Scenario: The user logins to a shared computer (office, library, cafe) Left the account open. Intruder came and try to delete the users account Intruder can easily delete the account because the system did not protect it by asking the password to validate that the person deleting the account is the real user.
Regards Raghav Sharma
POC Link -: https://drive.google.com/file/d/1iu1gb0l44_sTqG2Ol-ZTbLc0ZKHYkO-f/view?usp=drive_link
|
|
83 | Issue: Application Allowing Old Password to be Set as N ... | Closed | 26.10.2024 |
Task Description
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.
|
|
53 | Lack of Email Confirmation During Account Creation | Closed | 05.06.2024 |
Task Description
Severity: High
Vulnerability Description: The website allows users to create accounts without verifying their email addresses. This practice poses significant security and usability risks.
Impact:
Spam and Fake Accounts:
Malicious users can create multiple fake accounts, leading to spam and abuse of the platform. Automated scripts (bots) can exploit this vulnerability to flood the system with fake accounts, overwhelming resources and degrading performance. Account Security:
Unauthorized users can create accounts using someone else's email address, potentially leading to privacy breaches and unauthorized access to personal information. Genuine users might be unable to access their accounts if their email addresses are misused by others.
Communication Failures:
Users may not receive important notifications, updates, or password reset instructions, leading to poor user experience and support issues.
Reputation and Trust:
The lack of basic security measures can lead to loss of trust among users and damage the website's reputation. Users might perceive the platform as insecure and unreliable, leading to reduced user retention and engagement. Steps to Reproduce: Navigate to the account creation page. Enter any email address (including ones that do not belong to the user) and complete the registration process. Observe that the account is created and accessible without any email verification step.
Recommended Mitigation:
Implement Email Verification:
During registration, send a confirmation email to the provided email address containing a unique verification link. Require users to click on the verification link to activate their accounts. Use CAPTCHA:
Incorporate CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) during the registration process to prevent automated bots from creating accounts.
Rate Limiting:
Implement rate limiting on the account creation endpoint to prevent mass account creation from the same IP address within a short period.
Audit Existing Accounts:
Review existing accounts for potential fake or unauthorized accounts and take appropriate actions, such as sending verification requests or disabling suspect accounts.
References: OWASP Authentication Cheat Sheet: OWASP Authentication Cheat Sheet NIST Digital Identity Guidelines: NIST SP 800-63B
|
|
17 | Lack of password confirmation on account deletion | Closed | 19.01.2024 |
Task Description
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://
|
|
86 | Lack of Password Confirmation on Delete Account | Closed | 24.10.2024 |
Task Description
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
|
|
57 | Lack of Password Confirmation on Delete Account and GET ... | Closed | 15.07.2024 |
Task Description
Summary:
A vulnerability was discovered where the delete account functionality lacks password confirmation and is vulnerable to GET-based CSRF, potentially allowing attackers to delete accounts without authorization.
Impact:
- Unauthorized account deletion - Potential data loss - Increased risk of account takeover
Expected Result:
- Password confirmation should be required to delete an account - CSRF protection should prevent unauthorized requests
Actual Result:
- No password confirmation is required to delete an account - GET-based CSRF vulnerability allows unauthorized account deletion
Steps to Reproduce:
1. Login to the application 2. Trick the user into clicking a malicious link to delete their account: https://admin.alwaysdata.com/admin/details/1/delete 3. User click submit 4. Observe the account being deleted without password confirmation
Recommended Fix:
1. Implement password confirmation requirement for delete account functionality 2. Implement CSRF protection for delete account functionality 3. Validate requests to prevent unauthorized account deletion
Conclusion:
This vulnerability poses a critical risk to user accounts and data. Implementing password confirmation and CSRF protection for delete account functionality will prevent unauthorized account deletion and ensure the security and integrity of user accounts.
|
|
54 | Lack of Verification Email | Closed | 06.06.2024 | |
|
13 | Lack of Verification Email | Closed | 16.01.2024 | |
|
58 | Missing Invitation Link for Existing Users | Closed | 12.07.2024 | |
|
51 | Multiple Free Public Cloud accounts obtained by a singl ... | Closed | 25.04.2024 | |
|
79 | Nginx version leaking Information Disclosure | Closed | 23.09.2024 | |
|
91 | No Rate Limit on account deletion request | Closed | 31.10.2024 | |
|
40 | No Rate Limit On Reset Password in admin.alwaysdata.co ... | Closed | 27.03.2024 | |
|
12 | No rate limit on Submit tickets | Closed | 15.01.2024 | |
|
60 | On-click Delete any invitation in [admin.alwaysdata.com ... | Closed | 30.07.2024 | |
|
46 | Open Redirection Vulnerability | Closed | 13.04.2024 | |
|
14 | Potential SSRF Vulnerability via Self-XSS | Closed | 18.01.2024 | |
|
33 | Privilege Escalation in admin.alwaysdata.com - Academic ... | Closed | 16.02.2024 | |
|
24 | Security Report:Broken Access Control (BAC) in [admin.a ... | Closed | 01.02.2024 | |
|
44 | Security Vulnerability | Business Logic Flaw | Closed | 28.03.2024 | |
|
32 | Server Path Traversal + Information Disclosure on admin ... | Closed | 15.02.2024 | |
|
55 | Session Not Invalidated on Permission Change | Closed | 12.07.2024 | |
|
62 | Stored XSS Via Upload Document | Closed | 17.07.2024 | |
|
63 | Stored XSS Via Upload Document | Closed | 17.07.2024 | |
|
23 | Subject: Vulnerability Report: Transmission of Credenti ... | Closed | 02.02.2024 | |
|
28 | Summary: A username disclosure vulnerability has been i ... | Closed | 13.02.2024 | |
|
67 | *Title:* Account Creation and Impersonation Vulnerabili ... | Closed | 05.08.2024 | |
|
68 | *Title:*: Bypassing Email Address Restriction for Accou ... | Closed | 05.08.2024 | |
|
61 | *Title: Critical Security Vulnerability: Unauthorized A ... | Closed | 18.07.2024 | |
|
84 | Title: Exposed .git Directory on https://security.alway ... | Closed | 24.10.2024 | |
|
87 | ### Title:**Insecure Direct Object Reference (IDOR) Vul ... | Closed | 24.10.2024 | |