Project: Zyxel GS1200–5, Part 1

5 min readJun 19, 2022

Edited June 25, 2022 to include a link to my config export script github repo.

Introduction

A year ago I bought a Zyxel GS1200–5 managed switch. My goal was to experiment with the network security monitoring software, Zeek. I needed a way to mirror my network traffic to a Raspberry Pi for analysis and the GS1200–5’s port mirroring capability was the answer.

Raspberry Pi 4 running Zeek mounted on top of a Zyxel GS1200–5 switch

As with all newly acquired gear, my first step was to patch the GS1200–5. I downloaded the latest (at the time) firmware from Zyxel to upgrade the switch from version 1.00 to version 2.00(ABKM.0)C0.

This proved to be a challenge. The web interface for managing the switch had a firmware update bug. When you browse to your firmware and click upload, the web interface starts a 30 second countdown waiting for the firmware to finish uploading. But at the 30 second mark, with the link light still flickering away (showing an active upload), the web interface throws an error saying the firmware failed. The web interface is now locked on that error message and will not respond, even with a new private-browsing session, until factory reset.

To successfully apply new firmware, I had to open my browser’s developer tools and go to the javascript debugger. I paused the script and stepped through until it got to the function timedCount() and the line c = wait_time. In the the console I set “wait_time=60” and resumed the debugger. That gave the web interface enough time to finish uploading and complete the upgrade.

This left me with an uneasy feeling. At the time I was also seeing headlines about security vulnerabilities in other Zyxel products. That combined with the sloppy coding convinced me there was more to be found if I looked deeper.

View Source

Checking out the management web interface source code led to an easy discovery. The switch exposes some juicy internal data via an unauthenticated URL. Browsing to http://ip/system_data.js (yep, http) dumps out the model name, hostname, build date, MAC address, IP address, net mask, gateway, uptime, and some interface data. Not good. I sent this data along to HD Moore at Rumble to help their product with identifying this switch. I’m a huge Rumble fan and found some interesting things with it.

I also discovered a mild issue with client-side input validation. The device hostname can only be numbers, letters, dashes, and underscores. The validation is done client-side and server-side but the character sets are not consistent. I was able to insert a period into a hostname by skipping the client-side validation. I was not able to insert other special characters nor exceed maximum length without making system_name_set.cgi fail. So far, period appears to be the only character discrepancy between client and server-side validation and I can’t do much with it.

UART Rabbit Hole

I decided to dive deeper than the web interface. A few years ago I saw an old Black Hat talk about accessing devices using the UART pins and was dying to try it. I had a USB to UART adapter, found some pins that looked suspiciously like UART pins, tried everything I could, and failed to make it work. Apparently, other manufacturers may purposely unsolder or break connections to UART pins before shipping. To test that, I may try soldering access wires directly to the switch’s RTL8367N chip (pins 54 and 55).

NARRATOR VOICE: “He’s awful at soldering and will brick the switch soon”.

Dumping Flash via SPI

Despite the UART setback, I didn’t give up! I read several books on IoT hacking, hardware pentesting, and using STM32 boards and finally stumbled upon an interesting technique that got me somewhere.

I found the flash chip on the GS1200–5. It is a Winbond 25Q32JVS1Q. While the switch was powered off and unplugged, I was able to clip onto it with a Pomona 5250 SOIC8 Test Clip. I hooked the clip up to a Bus Pirate and was able to dump the flash chip to my computer. The image below shows my setup at the time.

SOIC8 Test Clip and Bus Pirate dumping the Winbond flash chip on the SG1200–5

Later I simplified it by removing unnecessary wires, removing the resistor, the breadboard, and wiring it up directly to the SPI pins on a Raspberry Pi Zero instead of the Bus Pirate.

SOIC8 Test Clip and Raspberry Pi Zero dumping the Winbond flash chip on the SG1200–5

The first thing worth reporting is that neither the flash dump nor the firmware downloaded from Zyxel’s site are easily digested by binwalk. The second gotcha is that Zyxel use their own magic number, 0x12345678. I had no experience with embedded device analysis at the time so this roadblocked me for a while.

Password6 = p5ssWor8b

I wasn’t getting anywhere with trying to get binwalk to dissect the firmware download or flash dump so I turned my attention to something easier; changing the admin password and checking to see what changed between two dumps. The admin password appears at 0x001ff040 in the flash dump for version 2.00(ABKM.0)C0. It’s encoding is pretty weak. They don’t say it but passwords are case insensitive. Next, the password characters a-e and 5–9 overlap and encode to the same value. So Password6 and p5ssWor8b evaluate as equal.

In the flash dump, a little before the password, is the switch’s hostname, IP address, subnet mask, and gateway. No special encoding here. The hostname will be regular ASCII encoding and the IP addresses are decoded with socket.inet_ntoa.

My github repo has a script to export the config from either a flash dump or a config backup. Currently (June 2022) it can export the admin password, hostname, IP, netmask, and gateway.

Next Steps

This is as far as I could go in 2021. I took some time to do some study on reverse engineering and Ghidra. See Part 2 for the next adventure.

My intention is to responsibly disclose any exploitable vulnerabilities. Thus far my findings have been superficial or trivial for anyone with physical access to the device. Other than some minor information disclosure, I’ve found nothing that can be compromised remotely.