Upon logging in via SSH, I immediately noticed the limited set of available commands and options. It became evident that I was indeed confined to a restricted shell environment.
After exploring several known vulnerabilities, I decided to delve into the search for new ones. To begin, I logged into the administrative portal and began testing various functionalities that could potentially result in OS command injection. Within the Diagnostic menu, I came across a particular feature that allowed me to test connectivity using the ping and traceroute commands.
So, I decided to try something sneaky by adding a ";" character to my command. I executed "cat /etc/passwd" and guess what? The command ran successfully.
Since I had complete admin privileges, I couldn't resist delving deeper to uncover the vulnerable component. While inspecting the browser requests, I noticed something interesting. There were two CGI files, "ping.cgi" and "DiagGeneral.cgi", being targeted by the requests.
After grabbing the files, I had some fun with reverse engineering using Ghidra. Here's the interesting part: in the "ping.cgi" file, I noticed that the **PingIPAddr** parameter was being directly taken from user input without any proper sanitization. The **PingIPAddr** parameter grabbed from user input was stored for future use utilizing the **tcapi_set** function.
Lastly, in the DiagGeneral.cgi file the PingIPAddr parameter was retrieved using the **tcapi_get** function and then directly used in the **system** function without any sanitization. This flaw creates a command injection vulnerability, enabling unauthorized execution of arbitrary commands on the system.
