Siklu MultiHaul TG series < 2.0.0 - unauthenticated credential disclosure

Overview

This article examines a documented security issue affecting Siklu MultiHaul TG series devices prior to version 2.0.0: an unauthenticated credential disclosure condition reachable from the local IPv6 network. The vulnerability enables an attacker on the same Layer‑2/IPv6 link to obtain administrative credentials generated or stored on the device without prior authentication. The guidance below focuses on impact analysis, detection, containment, and practical mitigation steps for network operators and incident responders.

Affected products and scope

• Siklu MultiHaul TG series firmware versions earlier than 2.0.0 (per vendor notices and public reports).
• Attack surface: management interface reachable via IPv6 link-local or local network segments where the device participates in neighbor discovery and accepts local connections.
• Prerequisites for exploitation: network adjacency or ability to send IPv6 packets that reach the device (same VLAN/bridge domain or otherwise allowed by L2/L3 filtering).

Technical summary (high level)

According to reports, an unauthenticated service on affected devices responds to a specific request and returns credential material (username/password) over the local network. Because the service responds without authentication and uses link-local IPv6 connectivity, an attacker that can send traffic on the same link can extract credentials, then connect using those credentials to management services (for example, SSH). The core problem is an exposed management/data path that discloses secrets without authentication or sufficient access controls.

Impact and risk

• Privilege escalation / device takeover: Obtained credentials can enable full administrative access to the device, including configuration change, firmware flash, and persistent access.
• Network pivoting: With control of a backhaul or access radio, an attacker can eavesdrop, route traffic, or use the device to reach other internal segments.
• Operational disruption: Misconfiguration, denial-of-service, or injection of malicious routing can impact production network availability.
• Data exposure: Access to management interfaces often exposes monitoring data, logs, and secrets used elsewhere (keys, SNMP, monitoring credentials).

Detection and monitoring

Detection focuses on identifying attempts to contact the exposed management port or anomalous IPv6 activity on local links, and on detecting subsequent unauthorized logins. Below are defensive detection techniques that do not describe exploitation steps, only monitoring and logging.

Network-level detection

• Alert on TCP connections targeting management ports associated with the vendor/service if seen from link-local or unexpected subnets.
• Log and review IPv6 Neighbor Discovery (ND) events, unusual neighbor churn, and gratuitous announcements.
• Monitor for new SSH sessions to devices or for successful SSH authentication events from unusual source addresses.

# Example Suricata/IDS rule (defensive): alert on TCP connections to a nonstandard management port often observed on affected devices.
alert tcp any any -> any 12777 (msg:"Possible Siklu management access attempt to port 12777"; sid:1000001; rev:1;)

Explanation: This Suricata rule generates an alert for any TCP attempt to destination port 12777. It is purely defensive — intended to notify defenders of connection attempts that may correlate with reconnaissance or exploitation activity targeting management services known to be used by some devices. Tune source/destination IP context and suppression policies to reduce false positives in your environment.

# Example Zeek (Bro) script snippet to log connections to management port 12777
redef Ports::DefaultKnownPorts += {12777/tcp};
event connection_established(c: connection)
{
    if ( c$id$resp_p == 12777/tcp )
        Log::write(Conn::LOG, fmt("Conn to management port 12777: %s -> %s", c$id$orig_h, c$id$resp_h));
}

Explanation: This Zeek snippet flags connections observed to TCP port 12777 and writes a log entry. It helps correlate which hosts are initiating such access and when — useful for incident timelines and scope determination.

Host and device-level monitoring

• Review device logs for unexpected credential generation events or configuration changes (audit trails, syslog, local auth logs).
• Monitor for new or repeated failed/successful SSH authentications and for logins from link-local IPv6 addresses.
• Use Integrity Monitoring on critical device configuration files or stored credential files (if supported) to detect changes.

Mitigation and remediation

Immediate remediation should prioritize patching and reducing exposure. Use a layered approach: patching, access filtering, hardening, and monitoring.

Patch and vendor coordination

• Apply vendor firmware updates that mitigate the issue as soon as they are available (upgrade to 2.0.0 or later per vendor guidance).
• If a firmware upgrade cannot be performed immediately, engage Siklu support for recommended interim firmware or hotfixes.
• Maintain a record of affected serial numbers and firmware versions to prioritize patching across the fleet.

Network hardening and access control

• Block or restrict access to the management port on the device at the network edge and upstream firewalls. If the service is not needed, deny traffic to the port entirely.
• Segment management networks: place all management interfaces on dedicated VLANs and enforce strict ACLs so only authorized hosts and NMS systems can connect.
• Limit IPv6 link-local exposure: where IPv6 is not required, disable it on the management interface or apply ND/RA filtering (for example, RA Guard, IPv6 ND rate limiting) to reduce unsolicited neighbor interactions.
• Disable or restrict legacy/weak authentication: enforce key-based SSH, disable password authentication where possible, and remove unused accounts.

# Defensive example: block incoming TCP to port 12777 on the firewall using ip6tables (Linux)
ip6tables -I INPUT -p tcp --dport 12777 -j DROP

Explanation: This ip6tables command inserts a rule to drop incoming TCP connections destined for port 12777. Use management-plane IP addresses and interface-scoped rules (e.g., --in-interface) to avoid unintended impacts. Apply rules in coordination with change management and with backups of existing firewall rules.

Credential hygiene and recovery

• Assume exposed credentials may have been compromised. Rotate administrative credentials and SSH keys used by affected devices immediately after containment.
• Revoke any session tokens, management API keys, or third-party credentials stored on the device if applicable.
• Where possible, re-image the device or restore from a known-good configuration post-patch to remove persistent backdoors or misconfigurations.

Incident response checklist

• Identify affected hosts (inventory firmware versions and serials); isolate from production networks if compromise likely.
• Collect logs and telemetry: network captures, SSH logs, device audit trails, syslog; preserve evidence for forensic analysis.
• Rotate credentials and keys; force reauthentication for management systems.
• Apply firmware updates and configuration hardening across affected systems.
• Review lateral movement and pivoting indicators; scan adjacent networks for signs of access abuse.
• Document the incident, mitigation steps, and lessons learned for future prevention.

Responsible disclosure and coordination

If you are a vendor, integrator, or researcher discovering a similar issue, follow responsible disclosure best practices:

• Contact the vendor’s security response team with reproducible, non-exploitative technical details and sample logs (avoid publishing full exploit code publicly until fixes are available).
• Coordinate public disclosure timing with the vendor to allow customers to patch or apply mitigations.
• Share defensive indicators (e.g., port and behavior to alert on) rather than exploit payloads to help defenders respond quickly without enabling malicious actors.

Appendix: risk scoring and prioritization

Factor	Assessment
Authentication required	None — unauthenticated disclosure
Network reachability	Local link (IPv6 link-local) — high risk for adjacent hosts, medium for wider networks if misconfigured
Potential impact	High — full admin access, network pivoting
Exploit complexity	Low for an adjacent attacker

Prioritize remediation for devices that serve critical connectivity or have management exposed to user-facing networks. Use compensating controls (blocking management ports, VLAN isolation, SSH hardening, and strict ACLs) to reduce exposure until firmware updates can be deployed fleet-wide.