Gs1900-24 Firmware
Sherry Galeazzi
Please read the Release Note carefully before updating firmware or installing software. Also, please be aware Zyxel is not responsible for damages if firmware, software, or other files are not installed according to the Release Note instructions. You can click to download the Release Note.
ZyXEL GS1900-8HP The GS1900-8HP is an 8-port Gigabit L2 switch with a 70W of PoE power budget. [ZyXEL GS1900-8HP angled view] Supported Versions Experimental Versions None at this time. Hardware Highlights Installation -> Install...
All known/ supported gs1900 family members have been dual-firmware so far.
There is no automatic fail-over implemented by ZyXEL, it either needs to fully boot up to toggle it - or serial access to u-boot.
OpenWrt only supports running from the primary partition so far.
Earlier this year the NSA released Ghidra, a reverse engineering suite with support for a large number of CPU/MCU instruction sets. While I have some experience with Hopper and radare2 I wanted to play with Ghidra to poke around the firmware for my Zyxel GS1900-8 switch which runs on a 32-bit MIPS CPU. All in all this has turned out to be an interesting exploration of both Ghidra and the GS1900-8-2.40(AAHH.2)C0.bix firmware image.
Initially I wanted to write about poking around the firmware image and showing how one can use Ghidra to explore unknown binaries, but whilst looking around some libraries that are used by this switch I realised there is actually an interesting vulnerability to write about.
Secondly, there are two undocumented and password protected interfaces. One is a password recovery menu only reachable via serial console and the other is diagnostic menu which is available via SSH. The passwords for these hidden menus are hardcoded in the firmware.
Binwalk had a hard time figuring out what was in the bix file however it did get a number of binaries extracted that were of enough interest to pursue further exploration of this image. A quick search revealed the gs1900fw project which was used to extract the firmware:
What this function does is it checks if remote debugging is enabled (remote being not connected to serial, so basically via a network connection) by calling fds_sys_remoteDebugEnable_ret() from libfds.so.0.0. Disassembling that function I expected it to check a configuration flag or a switch or anything. But no, it simply returned 1 indicating that remote debugging is enabled. Odd.Also note that cmd_textline_enable_get() is simply returns 0, so this branch is always taken.
Next it prints Diagnostics: and waits for input which, judging by the code, is supposed to be a password of sorts. But there is nothing that indicates this, again, odd. Renaming a few variables (with hindsight) we get:
Furthermore this firmware contains a large number of calls to the libc system() function to perform a host of functions. However input is not always sanitised to prevent code injection through user controlled parameters:
Before documenting my findings I wanted to see if I could trigger the diagnostic menu via SSH as a regular user. The web interface allows for creating users with one of two types of privilege: admin or user. So I created a user, logged in and triggered the menu. Yikes.
Ha, I saw in the sys led that something is booting and a reset via the button has to be applied. Not the Zyxel GS1900-24E is back online with OEM firmware. Perhaps this helps somebody...so very easy to revert back...
January 2024 note: I received two reports saying that recent firmware versions support importing certificates via the web interface. The described workaround using telnet hasn't been working for years.
The caveats of this approach is that the key as well as any passwords have to be transmitted via an unencrypted network connection. As of this writing the author is not aware of any other method, though. It may be sensible to connect directly to the switch rather than via any intermediate devices.
The author used a variation of the command shown below to generate a new RSA key with a length of 4096 bits and a self-signed certificate with a validity of one year. The key and certificate should be generated on a separate machine as the version on the switch is very old. Naturally a certificate signed by a certificate authority (CA) may also be used.
On the switch the key and certificate are stored in /mnt/ssh/ssl_key.pem and /mnt/ssh/ssl_cert.pem respectively. There are only few programs available in the userland. There is no text editor at all. Instead files have to be written using cat. When the root shell is opened as described before ^D (Ctrl-D; end of file) does not work. Fortunately it can be enabled using stty.
Day to day, I deal with enterprise grade network equipment. Products made by companies like Cisco, HPE Aruba, and FortiNet. Equipment that is at home in a small factory's network closet and an enterprise data center.
I mean, they do everything they are supposed to do. Powerful pieces of equipment that measure throughput in millions of packets per second. Super computers compared to what I grew up around. The sorts of things that I dreamed about as a kid.
But there is something alluring about the little guys. The weird, inexpensive computers that do neat things. You know, the Raspberry Pis and their clones like the Banana Pis and Orange Pis. The ODROIDs by HardKernel. The LattePandas and Arduinos. The weird SOCs that can't possibly see much usage in the real world.
I recently came across a ZyXEL GS1900-24HPv2, which is a relatively inexpensive 24 port managed switch with PoE. This is interesting to me because if it is managed, it must have enough power to run some sort of operating system. Obviously, this made me wonder what makes it tick.
The firmware for this switch was pretty easy to find. A quick search on their site even showed that the newest version was only about 4 months old! That was unexpected! I just had a feeling that it most likely hadn't ever been updated.
I had a feeling that this firmware file was nothing more than an archive that gets written directly to the internal flash on the switch. Not exactly the same, but pretty similar to the image that you would write to a flash drive to install your favorite Linux distro. There is really only one way to find out, so let's get at it.
The easiest first step here is to simply walk through the binary file with binwalk. Binwalk is a super cool tool that searches for magic headers within another file to attempt to locate embedded data. It is also able to extract the data that it finds for further analysis.
I have never heard of a bix header, or even a bix file. It must be a thing if binwalk was able to pick this up. Some quick searching indicated that this file type was an experimental compression scheme invented by Igor Pavlov. It was apparently a predecessor of 7z and never had wide usage.
I spent quite some time trying to figure out how to decompress a bix archive. There were some ancient tools that were originally hosted on Angelfire but no other documentation to be found. This will become a theme of this entire series.
This extracts quite a bit, and honestly, most of it doesn't make sense yet. There are a few embedded png files that appear to show the front of a Zyxel switch, although not this model. There are also quite a few binary files with super helpful filenames.
I am not going to pretend to be an expert at using binwalk, so all of the intricacies are out of scope for this article. I would like to point out that while these filenames might appear random, they really aren't.