TELSAT marKoni FM Transmitter 1.9.5 - Backdoor Account Information Disclosure

TELSAT marKoni FM Transmitter 1.9.5 — Backdoor Account Information Disclosure

This article examines a critical information disclosure vulnerability discovered in multiple firmware versions of TELSAT (marKoni) FM transmitters. A hidden, hardcoded super‑administrator account named factory with the fixed password inokram25 is present in the device web interface code. The backdoor is embedded in an unprotected JavaScript file and allows full administrative access to affected devices if exposed to an attacker.

Summary

Researchers discovered a hardcoded backdoor account inside /js_files/LogIn_local.js on several marKoni transmitters. The account is not listed in the normal user management UI and its password cannot be changed through the device interfaces. Exploitation of this weakness can result in full web‑management control, configuration changes, and potentially persistent device compromise.

Affected products and firmware

Vendor	Product	Affected firmware
TELSAT Srl	marKoni FM Transmitters (Markoni‑D, Markoni‑DH, Markoni‑A)	1.3.9, 1.4.6, 1.5.9, 1.9.3, 1.9.5

Vulnerability type

CWE‑912: Hidden Functionality. The product contains an undocumented administrative account with a hardcoded password embedded in static JavaScript served by the device.

Where the backdoor is located

The credentials are present in the auto_login() function inside the unprotected JavaScript file /js_files/LogIn_local.js. A minimal example (redacted for context) looks like this:

function auto_login() { // @mod1
 var username = "factory";
 var password = "inokram25";
}

Explanation: This JavaScript function contains the hardcoded username and password values in plain text. Because the script is served by the device without authentication, anyone who can fetch the file can read the credentials.

Impact and risk

• Unauthorized full administrative access to the web management interface.
• Ability to change configuration parameters, upload firmware or settings, and alter persistent storage (EEPROM) where supported.
• Potential service disruption (misconfiguration, denial of service) or persistent compromise if an attacker modifies device firmware or configuration to maintain access.
• Large blast radius for devices exposed directly to untrusted networks (e.g., public‑facing management ports or insufficiently segmented internal networks).

Discovery and sources

The vulnerability was discovered by Gjoko "LiquidWorm" Krstic of Zero Science Lab. Official advisory: ZSL‑2024‑5809. CWE reference: CWE‑912. Vendor: markoni.it.

Detection (defensive guidance)

To determine whether a device is exposing the vulnerable script, an administrator can request the JavaScript file from the device and inspect it. Example (replace host and port appropriately):

curl -s http://10.0.8.3:88/js_files/LogIn_local.js | grep -A2 "auto_login()"

Explanation: The command performs an HTTP GET for /js_files/LogIn_local.js, suppresses progress output, and searches for the auto_login() function. If the file contains the backdoor, the credentials will be visible in the output.

Indicators of compromise or exposure include:

• Presence of the factory account string or the literal password inside served JavaScript.
• Unexpected administrative logins or configuration changes recorded in device logs.
• Unwanted open management ports (HTTP/HTTPS) reachable from untrusted networks.

Mitigation and remediation

• Firmware update: Apply vendor firmware updates that remove the hardcoded backdoor if available. Check the vendor advisory or contact TELSAT/markoni support for fixed releases.
• Network controls: Restrict access to device management interfaces to trusted management networks only. Use firewall rules, ACLs, and VPNs for remote management.
• Remove or restrict static JS files: If firmware update is not immediately available, block access to /js_files/LogIn_local.js at the network perimeter or via a reverse proxy. Alternatively, if you have safe console access, inspect and remove or sanitize the file (apply vendor guidance before modifying device files to avoid breaking functionality).
• Change default accounts: Ensure no other accounts use factory defaults and that administrative credentials are unique and rotated regularly. Note: in this case the hardcoded account cannot be changed via the normal UI, so network restrictions or firmware updates are required.
• Segmentation and isolation: Place broadcast and critical infrastructure equipment on isolated management VLANs with strict access controls.
• Monitoring and logging: Enable and centralize device logs and monitor for unexpected configuration changes or failed/successful logins from unknown sources.
• Physical security & inventory: Maintain an up‑to‑date asset inventory and ensure devices are only connected to trusted networks.

Responsible disclosure and timeline

The issue was publicly documented by Zero Science Lab (Advisory ZSL‑2024‑5809). If you are a device operator, contact the vendor for coordinated remediation. When disclosing vulnerabilities, follow responsible disclosure practices: provide vendor time to patch, document affected versions, and publish remediation guidance for administrators.

Best practices for embedded device vendors

• Avoid hardcoded credentials or hidden backdoor accounts. If special factory modes are required, protect them with hardware tokens, one‑time tokens, or require physical presence and authentication.
• Ensure all served static files are reviewed for sensitive data during firmware build processes and security audits.
• Support secure firmware update mechanisms (signed images, rollback protection) and publish timely security advisories.
• Implement role‑based administration, account audit trails, and the ability to disable factory/debug modes in production units.

References and further reading

• Zero Science Lab Advisory ZSL‑2024‑5809
• CWE‑912: Hidden Functionality
• markoni.it — Vendor site

Final notes for operators

If your organization uses marKoni transmitters, treat this vulnerability as high priority. If you cannot immediately update firmware, apply network controls to prevent remote access to the affected management interface and inspect the device for unauthorized changes. Prioritize inventory, segmentation, and monitoring to reduce exposure of critical broadcast infrastructure.