TELSAT marKoni FM Transmitter 1.9.5 - Insecure Access Control Change Password

TELSAT marKoni FM Transmitters — Insecure Access Control: Change Password (Firmware 1.3.9 → 1.9.5)

This article explains a reported insecure access control vulnerability in TELSAT (markoni) FM transmitters (firmware versions 1.3.9 through 1.9.5) that allows an unauthorized or low‑privilege user to change a password via the web interface/cgi endpoint. It covers technical details, impact, detection, mitigations, and secure coding recommendations for device vendors and administrators. All testing and remediation steps should be performed only on systems you own or are authorized to test.

Executive summary

• Product: TELSAT marKoni FM transmitters (Markoni‑D, Markoni‑DH, Markoni‑A families)
• Affected firmware: 1.3.9, 1.4.6, 1.5.9, 1.9.3, 1.9.5 (reported)
• Vulnerability type: Insecure access control / authorization bypass for password change functionality
• Author of discovery: Gjoko "LiquidWorm" Krstic (Zero Science Lab)
• Advisory: ZSL‑2024‑5811 (2023‑11‑10)

What the vulnerability is

The device exposes a CGI endpoint (ekafcgi.fcgi) that accepts requests with an OpCode parameter to perform user operations including password changes. An attacker with a standard user cookie or in some cases a crafted cookie can invoke the change password operation (OpCode=4) to change account passwords without the server verifying that the requestor has the necessary permissions (for example, only administrators should be able to edit other users). In short: missing/insufficient server‑side authorization checks on password change functionality.

Why it matters

• Unauthorized password changes can result in account takeover, loss of device control, and persistent unauthorized access.
• Attackers could lock out legitimate administrators or create backdoor accounts by changing credentials for privileged or service accounts.
• Broadcast infrastructure devices (FM transmitters) are safety‑critical and often reside in restricted physical environments — compromise may have operational, regulatory, or public safety impact.

High‑level technical behavior (observed)

Requests to the CGI handler with OpCode=4 and parameters username/password/newpassword return a success response (oc=4&resp=0) without performing any server‑side authorization check against the session cookie. The device sets a cookie such as name=user-1702119917 in responses, but requests carrying a valid cookie are not validated for sufficient privilege.

Example proof‑of‑concept (for authorized testing only)

curl -s -H "Cookie: name=user-1702119917" \
 "http://TARGET:88/cgi-bin/ekafcgi.fcgi?OpCode=4&username=user&password=user&newpassword=t00tw00t"

Explanation: This example sends an HTTP GET request to the device CGI endpoint with OpCode=4 (the change password operation), supplying an existing username, current password, and a new password. The Cookie header is included (as observed during testing). The vulnerable device responds with a short response like oc=4&resp=0, indicating success. Only run such commands in test environments or on devices you are authorized to assess.

Observed environment details

Item	Value
Tested on	GNU/Linux (armv7l), lighttpd/1.4.33
CGI handler	/cgi-bin/ekafcgi.fcgi
Indicator	OpCode=4 and response oc=4&resp=0

Potential impacts

• Account takeover and privilege escalation.
• Operational disruption: transmitters misconfiguration or denial of service if credentials are changed or admin accounts are locked.
• Regulatory/compliance exposure due to loss of control over broadcast equipment.

Detection and hunting

Focus on HTTP logs and management interface access. Look for requests to ekafcgi.fcgi where OpCode=4 is present, or patterns indicating password changes. Example detection rules and queries below can be used in SIEMs or IDS (for defenders — tune to avoid false positives).

# Simple webserver log grep (bash) - hunt for change-password attempts
grep -i "ekafcgi.fcgi" /var/log/lighttpd/access.log | grep "OpCode=4"

Explanation: This command searches access logs for requests to the CGI handler and filters those with OpCode=4, highlighting potential password change attempts.

# Example Splunk query to find suspect requests
index=web host="transmitter.example" "ekafcgi.fcgi" "OpCode=4"
| stats count by src_ip, user_agent, _time

Explanation: This Splunk query locates requests to ekafcgi.fcgi containing OpCode=4 and aggregates by source IP and user agent to aid investigation.

# Example Suricata/IDS signature (defensive)
alert http any any -> any 88 (msg:"TELSAT marKoni possible password-change CGI"; http_uri; content:"/cgi-bin/ekafcgi.fcgi"; http_client_body; content:"OpCode=4"; sid:1000001; rev:1;)

Explanation: The rule flags HTTP requests to port 88 with the ekafcgi.fcgi URI and OpCode=4 in the body/URI. Use only as a starting point and tune source/destination context to avoid noise.

Mitigations and immediate steps for administrators

• Restrict management interfaces: limit access to device web interfaces to trusted networks (management VLANs), jump hosts, or VPNs; block from general Internet.
• Apply vendor updates: check with TELSAT/markoni for firmware updates or advisories and apply patches when available.
• Change default credentials: ensure strong unique passwords for administrative accounts and remove unused accounts.
• Monitor logs: watch for unexpected password-change events and anomalous logins; enable logging/remote syslog where possible.
• Temporary controls: if patching is not immediately possible, consider disabling the web management interface, restricting access via firewall ACLs, or placing the device behind a reverse proxy that performs authentication/authorization.
• Incident response: if you find unauthorized changes, preserve logs, restore known-good credentials from secure sources, and follow your organization’s incident response processes.

Developer / vendor recommendations (secure fixes)

The root cause is lack of server‑side authorization checks. Enforce the following in firmware/CGI handlers:

• Validate session tokens and associate them with a logged‑in user on the server side.
• Implement role‑based access control (RBAC): only allow users with appropriate role (e.g., admin) to modify other users; require the target user to confirm their own current password for self password changes.
• Protect against CSRF by requiring an unguessable nonce for state‑changing requests.
• Use HTTPS for management traffic and mark session cookies as Secure and HttpOnly if TLS is used.
• Audit and sanitize all input parameters and avoid using GET for sensitive operations if possible; prefer POST with proper CSRF tokens and server side validation.

Sample server‑side authorization pseudocode

# Pseudocode for handling a change password request (server-side)
# This is illustrative. Implement proper session management and secure storage in real devices.

def handle_change_password(request):
    session = get_session_from_cookie(request.cookies.get("session_id"))
    if not session or not session.is_authenticated:
        return http_response(401, "Not authenticated")

    current_user = session.username
    target_user = request.params.get("username")

    # If user is changing their own password, require current password
    if target_user == current_user:
        if not verify_password(target_user, request.params.get("password")):
            return http_response(403, "Current password incorrect")

    # If changing someone else's password, require admin role
    else:
        if "admin" not in session.roles:
            return http_response(403, "Insufficient privileges")

    # Perform password strength checks, then update
    new_pw = request.params.get("newpassword")
    if not valid_password_policy(new_pw):
        return http_response(400, "Password policy violation")

    update_password(target_user, hash_password(new_pw))
    return http_response(200, "Password changed successfully")

Explanation: This pseudocode enforces server-side authentication and authorization checks. It requires a logged-in session, requires the current password when a user changes their own password, and requires an admin role to change other users' passwords. Password strength checks and hashing are demonstrated as required steps.

Responsible disclosure and coordination

Administrators should contact TELSAT/markoni for firmware updates and follow vendor guidance. If you discover exploitation in your environment, collect logs, isolate affected devices, and coordinate with internal responders and the vendor. Only perform active tests on equipment you own or have explicit permission to test.

Quick reference (metadata)

Field	Value
Vendor	TELSAT Srl (markoni)
Product	marKoni FM Transmitters (Markoni‑D / DH / A)
Affected firmware	1.3.9, 1.4.6, 1.5.9, 1.9.3, 1.9.5
Discovery	Gjoko 'LiquidWorm' Krstic, Zero Science Lab
Advisory	ZSL-2024-5811
Disclosure date	2023-11-10

Final notes

This vulnerability emphasizes the importance of server‑side access control enforcement for management interfaces, especially in embedded and industrial devices. Network segmentation, strict management access controls, and timely firmware updates are key to mitigating similar classes of flaws. If you operate affected devices, treat this as a high‑priority item — schedule updates or apply compensating network controls promptly.