Exploit research

1. Initial findings

1.1 file

$ file httpd
httpd: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

1.2 checksec

$ pwn checksec httpd
    Arch:     mips-32-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX disabled
    PIE:      No PIE (0x400000)
    RWX:      Has RWX segments

We can see that the httpd binary does not have any form of protection
We are not directly able to identify the presence of ASLR
- Given that PIE is disabled, it is likely that ASLR will be enabled (or at least partially)
- We can use the following command to find out:

$ cat /proc/sys/kernel/randomize_va_space

The file contains an integer value with different meanings:

0 -> no ASLR
1 -> partial ASLR
2 -> full ASLR
In our case, the file contains the value 1

In the later sections (CVE-2025-60690), we will able to see that the value of the stack pointer (SP) and stack addresses changes for each execution

1.3 Runtime analysis

For now, let's perform some runtime analysis to identify if ASLR is enabled on the libc (/lib/libc.so.0) library

The commands listed below (to identify the address of the libc library) should be ran across the following conditions:

Device reboots
Re-executions of the vulnerable binary (httpd)

In all cases, the address is shown to be constant at 0x2ad38000:

cat /proc/<PID>/maps | grep /libc
2ad38000-2ad71000 r-xp 00000000 1f:02 1180       /lib/libc.so.0
2adb0000-2adb2000 rw-p 00038000 1f:02 1180       /lib/libc.so.0

The dynamic loader (/lib/ld-uClibc.so.0) appears to be constant too:

2aaa8000-2aaad000 r-xp 00000000 1f:02 1176       /lib/ld-uClibc.so.0
2aaec000-2aaed000 r--p 00004000 1f:02 1176       /lib/ld-uClibc.so.0
2aaed000-2aaee000 rw-p 00005000 1f:02 1176       /lib/ld-uClibc.so.0

1.3 objdump

Note that the objdump binary used is from the binutils-mipsel-linux-gnu library

$ sudo apt install binutils-mipsel-linux-gnu
$ ls /usr/mipsel-linux-gnu/bin
ar  as  gold  ld  ld.bfd  ld.gold  nm  objcopy  objdump  ranlib  readelf  strip

$ /usr/mipsel-linux-gnu/bin/objdump -d --disassemble=get_merge_ipaddr gn-httpd

2. GDB, gdbserver

Debugging with gdbserver | Hex-Rays Docsdocs.hex-rays.com

Remote Debugging using gdbserver - GNAT User's Guidegcc.gnu.org

2.1 Retrieve `gdbserver` for the target's architecture

GitHub - guyush1/gdb-static: A statically compiled gdb/gdbserver-17.x repositoryGitHub

To start off, we have to retrieve the gdbserver binary for our target architecture mipsel (mips little-endian):

$ wget https://github.com/guyush1/gdb-static/releases/download/v17.1-static/gdb-static-full-mipsel.tar.gz

$ tar -xzvf gdb-static-full-mipsel.tar.gz
$ ls 
addr2line gdb        objdump    strings
ar        gdbserver  objcopy    ...
as        ld          readelf    ...

Remember to always check the available memory space available on the device, before transferring files

2.2 `gdbserver` on target router

Next, we can run gdbserver on the target router:

We can use the steps outlined in the previous sections to transfer the gdbserver binary from host to the device

UART console

# gdbserver <iface_addr>:<port> <program>

#! eg. 
# gdbserver 192.168.1.1:8888 /path/to/httpd

Alternatively, launch from PID of a running program:

UART console

# gdbserver <iface_addr>:<port> --attach <PID_of_program>

#! eg.
# pidof httpd
# gdbserver 192.168.1.1:8888 --attach <PID>
Attached; pid = <PID>
Listening on port 8888

2.3 Connect to remote target from host machine

To debug (using gdb-multiarch) from the host machine

NOTE: the normal gdb will not work since it does not support the mips architecture

$ sudo apt install gdb-multiarch

Since we know that our router uses the mipsel architecture (simply mips with little-endian), we have to set it up appropriately

$ gdb-multiarch
gdb> set architecture mips
gdb> set endian little
gdb> target remote <host>:<port>
...
gdb> continue

# eg.
gdb> target remote 8.8.8.8:8888

2.4 Memory address enumeration (`httpd`)

gdb> info proc mappings

3. Enumeration

3.1 Ghidra

Window -> Function call graph
Window -> Function call tree
Window -> Defined strings
1. Right-click -> Data -> ... eg. TerminatedCString
2. Right-click -> References -> show TerminatedCstring
Right-click -> References -> show references to ...
...

3.2 Fuzzing

$ curl -X POST http://192.168.1.1:80/apply.cgi -v
UNAUTHORIZED # path exists

$ curl http://192.168.1.1:80/apply.cgi -v -H "Content-Type: application/x-www-form-urlencoded" --data "action=Apply" -H "Authorization: Basic xxxx="
# RESPONSE: long HTML response

$ curl http://192.168.1.1:80/apply.cgi -v -H "Content-Type: application/x-www-form-urlencoded" --data "action=Appl" -H "Authorization: Basic xxxx="
# NOTE the action=Appl or any other invalid options: actio=Apply, etc.
# RESPONSE: shorter HTML response

From UART console

Listen with gdbserver

# /tmp/gdbserver 192.168.1.1:9999 --attach 539
Attached; pid = 539
Listening on port 9999
Remote debugging from host 192.168.1.100, port 52784

It appears that sending a VALID POST request to /apply.cgi triggers a certain system reset (as seen from the UART console), with the following logs:

# 539 nvram_commit(): start
539 nvram_commit(): end
cmd=[killall radvd ]
killall: radvd: no process killed
waitpid: No child processes
cmd=[killall igmpxmld ]
killall: igmpxmld: no process killed

# stop_dhcp6c
cmd=[/usr/sbin/ip -6 addr flush dev vlan2 scope global ]

Only a VALID POST request parameter will trigger this behavior, while an invalid one (such as --data "action=Apple") will not:

# valid
$ curl http://192.168.1.1:80/apply.cgi -v -H "Content-Type: application/x-www-form-urlencoded" --data "action=Apply" -H "Authorization: Basic YWRtaW46YWRtaW4="

# invalid
$ curl http://192.168.1.1:80/apply.cgi -v -H "Content-Type: application/x-www-form-urlencoded" --data "action=Apple" -H "Authorization: Basic YWRtaW46YWRtaW4="

Interesting observation

For the POST request with an invalid action parameter passed to the --data "action=xxxx" option, we get a response string:

<!--Invalid Value!<br>-->

Searching for the value "invalid" in the apply_cgi function (Ghidra), we find the following code snippet:

wfputs("<!--",param_1);
wfprintf(param_1,"Invalid Value!<br>",uVar4,param_4);
wfputs("-->",param_1);

A more comprehensive code snippet:

apply_cgi

    iVar2 = strcmp(pcVar1,"Apply");
    if (((iVar2 == 0) || (iVar2 = strcmp(pcVar1,"tmUnblock"), iVar2 == 0)) ||
         (iVar2 = strcmp(pcVar1,"hndUnblock"), iVar2 == 0)) {
     ... 
     }
    else {
      iVar2 = strncmp(pcVar1,"Restore",7);
      if (iVar2 == 0) {
        nvram_set("restore_defaults",&DAT_004a22b4);
        puVar6 = &DAT_00000001;
        __seconds = 0;
      }
      else {
        uVar4 = 7;
        iVar2 = strncmp(pcVar1,"Reboot",7);
        if (iVar2 == 0) {
          puVar6 = &DAT_00000001;
          __seconds = 0;
        }
         else {
          error_value = 1;
          wfputs("<!--",param_1);
          wfprintf(param_1,"Invalid Value!<br>",uVar4,param_4);
          wfputs("-->",param_1);
          puVar6 = (undefined1 *)0x0;
          wfflush(param_1);
          __seconds = 0;
        }

Other valid values appears to be "Restore" and "Reboot"

3.3 `index.asp`

59KB

index.asp

Open

Note that this web page automatically loads the index.asp file. This information will be useful for further analysis in the later steps

The index.asp file can be found in the /www directory (/www/index.asp)

From the initial research (in the Initial research page), we can understand that most of the CVEs found are relating to the httpd binary. Looking further into the description of each, we can see that quite a few of them involves CGI functions (CVE-2025-60689, CVE-2025-60690, CVE-2025-60691, CVE-2025-60693, CVE-2025-60694)

Let's start off by searching for the term ".cgi" in the index.asp file. Right off the bat, we find the following code snippet:

<FORM name=setup method=<% get_http_method(); %> action=apply.cgi>

3.4.1 Extract information

We can extract the following information:

Identifier for this form (name=setup)

likely referenced by:
- document.setup
- document.forms["setup"]

CGI action (action=apply.cgi)

The /apply.cgi path will be called

3.4.2 Identifying form identifier locations

We can attempt to identify the functions that handles the form action by searching for the following values:

document.setup
- multiple results
document.forms["setup"] (or document.forms['setup'])
- none

3.4.3 Interesting code locations of `document.setup`

Passed as arguments to functions

The following shows a code snippet where document.setup was passed as argument to the reboot() function:

<TD colspan=2 class=FUNNAME1>
        <script>document.write("<input type=button name=btn_reboot value='" + sbutton.reboot + "' onclick=reboot(document.setup)>");</script>
</TD>

From the reboot() function, we can observe that it accepts the argument value of document.setup as the variable F

function reboot(F)
{
// ...

We can also observe similar patterns for other functions:
- ppp_enable_disable
- dhcp_enable_disable
- dslite_enable_disable
- mtu_enable_disable

Assigned to local variable in a function

function init()
{
	var F = document.setup;
	// ...

This can be found in the selpptppmode() function too

3.4.4 Identifying form action handler(s)

In JavaScript, the submit method can be called on the document.name instance to trigger a form action

Thus, we can perform a search for the value .submit (or more specifically .submit()), in order to identify the functions that handles the form action

NOTE: we can also search directly for the term: F.submit()

The code snippet can be found in the following functions:

selWan
selPPP
reboot
to_submit
selLang

From the results, we should observe that most of the functions will have the following code:

F.submit() // "F" variable either from argument or local assignment

This supports our observation from the previous analysis, where the variable name F is commonly used to reference the document.setup instance

The following functions are invoked by a certain HTML form present on the web page:

selWan
reboot
selLang

Refer to the subsequent CVE sections to understand how we can trigger the found functions

3.4 Web page (port 80) traffic analysis

Upon navigating to the web page on port 80, we are prompted for a username and password. A simple search in a search engine for "linksys e1200 default credentials" yields the following results:

https://netstorage.ringcentral.com/datasheets/routers/linksys/e1200_v06.1.pdf

Accessing the Linksys Smart Wi-Fi Router's user interface using the local access linkLinksys

The username and password combination is admin, admin

It is likely that the index.asp file is loaded whenever a request is sent to the root URL of the webpage on port 80. We know from previous analysis that there exist a form element that calls the apply.cgi route, which triggers the apply_cgi function

3.4.1 Manually send form request from the webpage

We can manually send a form request, and use the web browser to analyze the HTTP traffic to understand the parameters and values involved

Refer to the notes under the Exploit research page to understand more about each function discussed below

Payload analysis

The following outlines the payload for each of the specific forms:

SelWAN() function

At the top of the web page, we can see the following outlined form field:

From anaylsis of the HTML source code, we can identify the following FUNNAME1 class:

<TD colspan=2 class=FUNNAME1><SELECT name="wan_proto" onChange=SelWAN(this.form.wan_proto.selectedIndex,this.form)>
...

Next, we can experiment with a few values from the selection options, and record the Payload parameters (form-data) that are automatically generated by the code, and sent with the request

NOTE: we require proper authentication with the Authorization: Basic xxxx request headers, and the response should have a 200 OK status code
The basic token value YWRtaW46YWRtaW4= is the base64-encoded string of the value admin:admin

a. Automatic Configuration - Static IP

submit_button        index
change_action        gozila_cgi
submit_type
action
now_proto            dhcp
daylight_time        0
switch_mode_dhcp     1
switch_mode          0
switch_ipaddr        4
hnap_devicename      Cisco58059
need_reboot          0
user_language
wait_time            0
dhcp_start           100
dhcp_start_conflict  0
lan_ipaddr           4
ppp_demand_pppoe     9
ppp_demand_pptp      9
ppp_demand_l2tp      9
ppp_demand_hb        9
wan_ipv6_proto
detect_lang          EN
wan_proto            static
wan_hostname
wan_domain
mtu_enable           0
lan_ipaddr_0         192
lan_ipaddr_1         168
lan_ipaddr_2         1
lan_ipaddr_3         1
lan_netmask          255.255.255.0
machine_name         Cisco58059
lan_proto            dhcp
dhcp_check
dhcp_start_tmp       100
dhcp_num             50
dhcp_lease           0
wan_dns              4
wan_dns0_0           0
wan_dns0_1           0
wan_dns0_2           0
wan_dns0_3           0
wan_dns1_0           0
wan_dns1_1           0
wan_dns1_2           0
wan_dns1_3           0
wan_dns2_0           0
wan_dns2_1           0
wan_dns2_2           0
wan_dns2_3           0
wan_wins             4
wan_wins_0           0
wan_wins_1           0
wan_wins_2           0
wan_wins_3           0
time_zone            -08 1 1
_daylight_time       1

b. Automatic Configuration - DHCP

submit_button        index
change_action        gozila_cgi
submit_type
action
now_proto            static
daylight_time        0
switch_mode_dhcp     1
switch_mode          0
switch_ipaddr        4
hnap_devicename      Cisco58059
need_reboot          0
user_language
wait_time            0
dhcp_start           100
dhcp_start_conflict  0
lan_ipaddr           4
ppp_demand_pppoe     9
ppp_demand_pptp      9
ppp_demand_l2tp      9
ppp_demand_hb        9
wan_ipv6_proto
detect_lang          EN
wan_proto            dhcp
wan_ipaddr           4
wan_ipaddr_0         0
wan_ipaddr_1         0
wan_ipaddr_2         0
wan_ipaddr_3         0
wan_netmask          4
wan_netmask_0        0
wan_netmask_1        0
wan_netmask_2        0
wan_netmask_3        0
wan_gateway          4
wan_gateway_0        0
wan_gateway_1        0
wan_gateway_2        0
wan_gateway_3        0
wan_dns              3
wan_dns0_0           0
wan_dns0_1           0
wan_dns0_2           0
wan_dns0_3           0
wan_dns1_0           0
wan_dns1_1           0
wan_dns1_2           0
wan_dns1_3           0
wan_dns2_0           0
wan_dns2_1           0
wan_dns2_2           0
wan_dns2_3           0
wan_hostname
wan_domain
mtu_enable           0
lan_ipaddr_0         192
lan_ipaddr_1         168
lan_ipaddr_2         1
lan_ipaddr_3         1
lan_netmask          255.255.255.0
machine_name         Cisco58059
lan_proto            dhcp
dhcp_check
dhcp_start_tmp       100
dhcp_num             50
dhcp_lease           0
wan_dns              4
wan_wins             4
wan_wins_0           0
wan_wins_1           0
wan_wins_2           0
wan_wins_3           0
time_zone            -08
_daylight_time       1

Note a few important parameter names such as action , lan_ipaddr_0 , lan_ipaddr_1 , etc.

4. Setting custom breakpoints on a binary (workaround)

4.1 Binary patching

In the subsequent sections, we will discover that we are unable to use the built-in GDB commands to set a custom breakpoint, as there appears to be some form of protection from the device kernel or other feature:

(remote) gef➤  break apply_cgi
Breakpoint 1 at 0x421a50

(remote) gef➤  continue
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x421a50
Cannot insert breakpoint -11.
Temporarily disabling shared library breakpoints:
breakpoint #-11

Command aborted.

Using hardware breakpoint fails too:

(remote) gef➤  hbreak apply_cgi
(remote) gef➤ continue # fails too

Fortunately, we can use a creative workaround to set a custom breakpoint, by manually patching the binary:

$ printf '\x0d\x00\x00\x00' | dd of=/tmp/httpd bs=1 seek=$((0xXXXXXXXX)) conv=notrunc

Points to note:

\x0d\x00\x00\x00 represents the value 0x0000000d in little-endian, which is a break instruction
We will overwrite the address at 0xXXXXXXXX

Indicated by the seek option

It is important to include the conv=notrunc option to prevent truncation of the data following the "seek" address

Refer to the next few specific CVE research sections to understand how we can apply this method (eg. CVE-2025-60690)

4.2 Manual SIGSTOP signal to halt the running process (`gdb`)

Right after the breakpoint is hit, we need to manually send a SIGSTOP signal to halt the running instance on gdb, and allow us to view the relevant values: stack, registers, threads, etc.

Note that this command must be ran from a separate console from the one running the gdbserver instance

Device console

# ps w | grep httpd
<PID> root     xxx T /tmp/httpd

# kill -STOP <PID>

PreviousMiscellaneous NextCVEs research

Last updated 8 days ago

hashtag1. Initial findings

hashtag1.1 file

hashtag1.2 checksec

hashtag1.3 Runtime analysis

hashtag1.3 objdump

hashtag2. GDB, gdbserver

hashtag2.1 Retrieve gdbserver for the target's architecture

hashtag2.2 gdbserver on target router

hashtag2.3 Connect to remote target from host machine

hashtag2.4 Memory address enumeration (httpd)

hashtag3. Enumeration

hashtag3.1 Ghidra

hashtag3.2 Fuzzing

hashtag3.3 index.asp

hashtag3.4.1 Extract information

hashtag3.4.2 Identifying form identifier locations

hashtag3.4.3 Interesting code locations of document.setup

hashtag3.4.4 Identifying form action handler(s)

hashtag3.4 Web page (port 80) traffic analysis

hashtag3.4.1 Manually send form request from the webpage

hashtag4. Setting custom breakpoints on a binary (workaround)

hashtag4.1 Binary patching

hashtag4.2 Manual SIGSTOP signal to halt the running process (gdb)