Elber Wayber Analog/Digital Audio STL 4.00 - Authentication Bypass

Elber Wayber Analog/Digital Audio STL 4.00 — Authentication Bypass (ZSL-2024-5822)

Executive summary

The Elber Wayber (Wayber II) family of analog/digital audio microwave links contains an authentication bypass vulnerability in its web management interface. A management endpoint that changes passwords can be invoked without proper authorization, allowing an unauthenticated actor to overwrite credentials and escalate to administrative access. This vulnerability affects multiple firmware and device revisions and can lead to full device compromise, persistent configuration changes, and disruption of broadcast audio services.

Affected products and advisory

Vendor	Product	Affected revisions (examples)
Elber S.r.l.	Wayber II / Analog-Digital Audio STL	Version 3.0.0 (various revisions, Firmware 4.00/3.00), Version 1.0.0 (Firmware 2.00) (See vendor advisory and ZSL-2024-5822 for full list)

Advisory: ZSL-2024-5822 — https://www.zeroscience.mk/en/vulnerabilities/ZSL-2024-5822.php

What the vulnerability is (technical description)

The device exposes a password-management endpoint in its web UI that accepts parameters to set passwords for various accounts and services. The endpoint does not enforce proper authentication and/or authorization checks, which permits unauthenticated requests to replace passwords for system users and service credentials (including administrative accounts and SNMP community credentials). As a consequence, an attacker can gain administrative privileges or change network management credentials without valid login.

At a high level this is an authentication and authorization failure: the password-change operation is treated as an allowed action for unauthenticated or insufficiently authorized principals.

Why this is dangerous (impact)

• Unauthorized administrative access: A malicious actor can gain control of the web UI and device configuration.
• Service disruption: Configuration changes can interrupt audio transport, degrade availability or misconfigure RF/microwave settings.
• Persistence and lockout: Attackers can overwrite legitimate administrator credentials and lock out operators.
• Network exposure: SNMP community strings and other management credentials can be changed, enabling further reconnaissance or lateral movement.
• Supply-chain and broadcast integrity: For broadcast infrastructure, unauthorized changes could alter transmitted audio or metadata.

Root causes and common coding mistakes

• Missing authentication check on sensitive HTTP endpoints.
• Incorrectly trusting client-side UI code for access control (client-side checks alone are insufficient).
• Exposing sensitive operations over GET or unauthenticated endpoints instead of using protected POST endpoints with CSRF and session validation.
• Insufficient input validation and lack of audit/logging around critical operations.

Safe, secure example: how to implement a protected "set password" endpoint

# Flask-style pseudocode (Python) — server-side handler
from flask import request, session, jsonify
from werkzeug.security import generate_password_hash
import logging

# Mapping of allowed levels to internal names
ALLOWED_LEVELS = {"admin": "admin_pwd", "user": "user_pwd", "snmp_rw": "snmp_write_pwd"}

@app.route('/api/set_password', methods=['POST'])
def set_password():
    # 1) Authentication: require a valid session token and user identity
    if 'user_id' not in session:
        return jsonify({'error': 'authentication required'}), 401

    # 2) Authorization: only allow admins (or a specific role) to change passwords
    if not session.get('is_admin'):
        return jsonify({'error': 'forbidden'}), 403

    # 3) Input validation: expect JSON body, required fields and allowed values
    data = request.get_json()
    level = data.get('level')
    new_password = data.get('password')
    if level not in ALLOWED_LEVELS or not new_password:
        return jsonify({'error': 'invalid input'}), 400

    # 4) Password strength policy (example)
    if len(new_password) < 10:
        return jsonify({'error': 'password too weak'}), 400

    # 5) Hash the password before storing (use bcrypt / Argon2 in production)
    hashed = generate_password_hash(new_password)

    # 6) Store securely using parameterized queries / API to device config
    save_password_to_config(ALLOWED_LEVELS[level], hashed)

    # 7) Audit log the operation (do not log the plaintext password)
    logging.info("User %s changed password for %s", session['user_id'], ALLOWED_LEVELS[level])

    return jsonify({'status': 'ok'}), 200

Explanation: This pseudocode demonstrates a secure pattern for handling password changes. It enforces authentication and role-based authorization, uses POST with a JSON body (instead of an unauthenticated GET), validates input and password strength, hashes passwords before storing, and logs the operation while avoiding logging secrets. In production, use a strong, memory-hard hashing algorithm (bcrypt/Argon2) and ensure secure storage.

Detection and indicators

• Unexpected or unexplained changes to administrative account behavior (logins failing for legitimate admins).
• Configuration drift: SNMP community strings, display passwords or other management credentials modified without authorized change events.
• Web server logs showing unauthenticated requests to password-management endpoints or unusual HTTP requests to management URIs.
• Service anomalies after a remote password change (reboots, configuration reloads, or access lockouts).

Recommended mitigations and mitigations when patching is unavailable

• Apply vendor-supplied firmware updates as soon as they are available.
• If updates are unavailable, reduce exposure: restrict device management interfaces to a management VLAN or trusted hosts only (ACLs/ firewall rules).
• Disable web management from untrusted networks; require management via an authenticated VPN or jump host.
• Enable and monitor audit logging on the device and centralize logs for alerting on suspicious password-change events.
• Change default credentials and rotate management passwords and SNMP communities after confirming device integrity.
• Implement network-level protections: limit inbound access to HTTP/HTTPS management ports (e.g., only from known IP ranges), employ intrusion detection/prevention systems that alert on suspicious management payloads.
• On the device side: enforce HTTPS/TLS, session timeout, CSRF protection, and role-based authorization for sensitive operations.

Longer-term secure-development recommendations for vendors

• Perform authorization checks server-side for all sensitive endpoints; never rely on client-side controls alone.
• Use POST for state-changing operations, require CSRF tokens, and validate the origin/referer when appropriate.
• Adopt secure password storage (bcrypt/Argon2) and do not store plaintext credentials.
• Implement fine-grained logging and tamper-evident audit trails for administrative operations.
• Conduct regular security-focused code reviews and automated API scanning to detect endpoints that accept sensitive parameters without auth.
• Harden default configurations: management interfaces should be disabled by default on WAN-facing interfaces.

Risk assessment and prioritization

This is a high-severity issue for devices used in broadcast and critical audio infrastructure because it enables direct administrative takeover. Prioritize patching and compensating controls (network restrictions and centralized logging) immediately. Even short windows of unauthenticated administrative access can create persistent compromises, loss of service, and reputational or regulatory consequences for operators.

Responsible disclosure, timeline and next steps for operators

• Follow vendor advisory and apply patches or firmware updates when published.
• Review access logs and change history for affected devices; if unauthorized changes are found, assume compromise and follow incident response procedures (isolate device, preserve logs, reset to known-good configuration, rotate credentials).
• Contact the vendor or your supplier for verification of fixed firmware and for guidance on secure configuration.
• Maintain a patch management schedule and inventory of exposed management interfaces across operational networks.

References

• ZSL-2024-5822 advisory: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2024-5822.php
• Vendor: Elber S.r.l. — https://www.elber.it