On The Hunt – 0-Day Vulnerability In Zyxel Router

Martin Wrona

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.

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.

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.

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:

1. Client generates a random AES key.
2. Client obtains a public key via the /getRSAPublickKey endpoint.
3. Client sends the generated AES key encrypted with the public key of the router during login.
4. 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.

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.

Martin Wrona

Senior Security Software Engineer

Martin.Wrona@digitecgalaxus.ch

These articles might also interest you