Behind the scenes

On The Hunt – 0-Day Vulnerability In Zyxel Router

14/4/2025

In the course of preparing for the launch of our Internet service offering, the Digitec Galaxus security team wished to take a closer look at the Zyxel router we were looking to supply to our customers. While analyzing the router, we discovered a previously unknown vulnerability (CVE-2024-12010). We would like to invite you on our journey as to how and why we did this.

As a security team, we are always keen to put our company's latest technologies and offerings through their paces. When we found out about our upcoming Internet offering, it was immediately clear to our team leader, Thomas Houiellebecq, that we should pay particular attention to this implementation in order to identify any potential security risks at an early stage. This is important for us as it allows us to directly influence the security posture of our customer devices.

It didn't take long before we received one of the Zyxel routers from the responsible project team and were able to start our assessment. Since we receive personalized firmware from Zyxel, we prioritized testing the part that was customized for us, and then further assessed the core part that is used by many Zyxel devices and customers.

Admin Interface

Our first step in the audit process was to get an overview of how the router is structured and which functionalities are offered. To do this, we utilized Burp Suite, a popular proxy tool for capturing and manipulating web traffic. We used it to collect all available paths within the management web application and then check them individually.

To our surprise, all POST request payloads and responses were encrypted, which made it incredibly difficult for us to get a quick initial overview. At first I assumed that this would make the reverse engineering process more complex, but more on that later. At this point, we decided to take a different approach.

Firmware Analysis

Fortunately, we had access to the unencrypted firmware running on the device and thus could look to subject it to reverse engineering. Since we don't analyze IoT / closed source projects every day, Thomas asked a colleague at ONEKEY to perform a proof of concept (PoC) on their platform.

ONEKEY is a security platform for IoT devices that specializes in the automated analysis of IoT firmware. A central component of the platform is the firmware binary analysis, which unpacks the firmware, classifies, identifies and optionally decompiles all assemblies and then checks the code for potential security vulnerabilities. The platform's automated processes enable potential security risks to be identified quickly.

After the firmware was analyzed by the platform, we had a list of points that we wanted to take a closer look at.

At first glance, we saw we had some potential vulnerabilities that were worth investigating in more detail. However, a deeper analysis shows that most of these reported vulnerabilities were either not directly accessible, or no user provided input is processed that would allow the vulnerability to be exploited. This means that the real threat/impact of these vulnerabilities was lower than it appeared at first glance.

The most exciting finding, which I will discuss in more detail here was recognized by the platform as a potential “command injection”.

To analyze and verify the detections in more detail, I loaded the corresponding library from the firmware into Ghidra, an open source reverse engineering tool from the NSA. In the view of the decompiled code, we saw a function that assembles a mailsend command with data from a JSON, and then executes it. The finding looked promising because data such as sender and recipient emails should most likely be always be user provided input.

Exploit

So we have a vulnerable action for which we need to find out whether it is accessible with user input, and how it can be called. After a short search, I found what I was looking for in the log settings. This functionality allowed syslogs to be sent to a specific e-mail address at regular intervals.

To utilize the function, our payload must execute a command within the actual command. Further information on command injection can be found on HackTricks

However, the admin panel did not let us enter any special characters that we needed for our attack. What if this was just a client-side validation?

To be able to manipulate requests to the backend, we first had to bypass the client-side encryption. To do this, I set a breakpoint in the corresponding JavaScript AES encryption function in the Chrome debugger, and was then able to adjust the value before encryption via the console. The program flow is then continued and the manipulated request was sent to the server.

The result of the manipulated request looked like this. As we can see, the special character validation was merely a client-side check that we were able to successfully bypass.

The configuration of the email settings was prepared and we need to trigger the function so that our payload was executed. For this we use the log function “E-mail Log Now”.

After we verified the functionality of the command injection, I built a simple PoC in Python that automated the entire process.

During this implementation, I had to rebuild the client-side encryption and recreated the following process:

Client generates a random AES key.
Client obtains a public key via the /getRSAPublickKey endpoint.
Client sends the generated AES key encrypted with the public key of the router during login.
Client encrypts or decrypts all subsequent requests/responses with the AES key.

This process is similar to a simplified implementation of TLS. The devices may be delivered without a self-signed certificate or, as in our case, with a self-signed certificate, which suggests that this method is intended as an additional protective measure against adversary-in-the-middle (AiTM) attacks.

PoC Exploit

We sent Zyxel the PoC script, and their security team was able to reproduce the problem in their standard firmware.

Timeline:

Nov 25, 2024 Report
Nov 29, 2024 Review / Reproduction
Dec 10, 2024 CVE Assigned
Dec 12, 2024 Fix Released
Mar 11, 2025 Zyxel Security Advisory Public Release

Affected Devices:

42 Devices, from DSL/Ethernet CPE, Fiber ONT to Wi-Fi extenders. See The Zyxel Security Advisory

Conclusion

The Zyxel security team treated the reported vulnerabilities with high priority and forwarded them to the responsible product group. The collaboration was professional, and thanks to the proof of concept I provided, a patch was quickly developed and distributed to customers. The ONEKEY platform enabled us to quickly get a comprehensive overview of the affected firmware, which significantly accelerated the entire review and assessment process. We wish to thank all parties for their timely and enjoyable collaborations.

Did you know that we have a Vulnerability Disclosure Program (VDP) at Digitec Galaxus? Ethical hackers & security researchers can also search for security vulnerabilities on our platform in a safe and responsible way, subject to the understanding and compliance with the VDP rules. Want to know more? Further information can be found at our security page.

94 people like this article

Martin Wrona

Senior Security Software Engineer

Martin.Wrona@digitecgalaxus.ch

Behind the scenes

News about features in our shop, information from marketing and logistics, and much more.

Show all

These articles might also interest you

Behind the scenes
From Lego to iPhones, here’s what our customers search for most
by Manuel Wenk
Behind the scenes
«Find my granny» – tracking devices are a summer hit at Galaxus
by Daniel Borchers
Behind the scenes
How to stay safe when online shopping
by Tobias Billeter