All Projects

*Title: Critical Security Vulnerability: Unauthorized Account Deletion via Limited Permissions* in [admin.alwaysdata.com]

Summary:*
During my investigation, I discovered a significant security flaw in the system's account management feature.

*Description:*
The system allows users to invite others to manage their accounts with varying permissions, including the ability to enforce two-factor authentication (2FA) before accessing account management privileges.

*Vulnerability Details:*
I identified a vulnerability wherein an invited user, even without sufficient permissions or 2FA activation, can delete the inviting user's account from their own account. This deletion occurs regardless of whether 2FA was enabled during the invitation process.

*Steps to Reproduce the Bug:*
1. Create two accounts.
2. Invite a user to administer your account and enable 2FA.
3. From the invited user's account, delete the account of the inviting user.
4. Observe that the inviting user's account is permanently deleted, despite prior 2FA activation or the absence of sufficient permissions granted.

I sent proof of concept: https://admin.alwaysdata.com/support/77431/374527-bandicam%202024-07-17%2003-48-55-255.mp4

*Impact:*

This security vulnerability poses a significant risk to user accounts within the system. It allows an invited user, even with limited permissions and without activating two-factor authentication (2FA), to permanently delete the account of the inviting user. This action occurs despite security measures initially set up, such as 2FA activation during the invitation process or inadequate administrative permissions granted.

*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

Subject: Business Logic Flaw

Dear Security Team,

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

Vulnerability Details:

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

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

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

Impact:

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

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

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

Regards,
Zeeshan Beg

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

unverified password change in [admin.alwaysdata.com]

Hello team!

I have found an interesting flaw where an attacker can change the account password without knowing the old password

When the user requests a password reset link, it accesses the activity log inside the account and this bug can be exploited by an attacker

Steps to reproduce the bug :

1-Create a new account on [admin.alwaysdata.com]
2-log in to your account
3-request the password reset link from another browser
4-you will notice that the password reset link you requested has arrived in the activity log

Impact :
If the attacker hijacks the session or gains access to the user account, he can request a password reset link and the link will reach him in the Account Activity Log, from which he can reset the account password without knowing the old password

Description

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

Impact

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

Proof-of-Concept

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

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

3) This is the vulnerable endpoint:

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

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

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

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

Mitigation

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

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