CVE-2025-60690

6.1 Ghidra

get_merge_ipaddr

undefined4 get_merge_ipaddr(undefined4 param_1,char *param_2)

{
  char *__src;
  size_t sVar1;
  int iVar2;
  char acStack_48 [32];
  
  *param_2 = '\0';
  iVar2 = 0;
  while( true ) {
    snprintf(acStack_48,0x1e,"%s_%d",param_1,iVar2);
    __src = (char *)get_cgi((ACTION)acStack_48);
    if (__src == (char *)0x0) {
      __src = "0";
    }
    strcat(param_2,__src);
    if (iVar2 == 3) break;
    iVar2 = iVar2 + 1;
    sVar1 = strlen(param_2);
    param_2[sVar1] = '.';
    (param_2 + sVar1)[1] = '\0';
    if (iVar2 == 4) {
      return 1;
    }
  }
  return 1;
}

Refined get_merge_ipaddr

undefined4 get_merge_ipaddr(undefined4 a1, char *a2)

{
  char *__src;
  size_t sVar1;
  int iVar2;
  char acStack_48 [32];
  
  *a2 = '\0';
  // iVar2 = 0;
  
  // while(true) {
  for (int i=0; i<4; ++i) {
    snprintf(acStack_48,0x1e,"%s_%d",a1,i); //snprintf(acStack_48,0x1e,"%s_%d",param_1,iVar2);
    __src = (char *)get_cgi((ACTION)acStack_48);
    if (__src == (char *)0x0) {
      __src = "0";
    }
    strcat(a2,__src);
    
    //if (iVar2 == 3) break;
    if (i == 3) break;
    //iVar2 = iVar2 + 1;
    
    sVar1 = strlen(a2);
    a2[sVar1] = '.';
    (a2 + sVar1)[1] = '\0';

    //if (iVar2 == 4) {
    //  return 1;
    //}
  }
  return 1;
}

...

Analysis

Keep in mind that we are working with the MIPS assembly for this binary. The insrtuctions and concepts are different from common x86, x64 or ARM assembly

We can see that the param_1 and param_2 variables corresponds to the 1st and 2nd arguments passed to the get_merge_ipaddr function. As what we can understand from MIPS assembly, this relates to the a0 and a1 registers in the current function (get_merge_ipaddr)

However, this does not necessarily mean the same for the nested function calls within the current get_merge_ipaddr function (eg. strcat, get_cgi)

Hence, there may be a situation where the disassembly listing view shows a particular param_x variable (corresponding to ax register) passed in as an argument to a nested function call, but that does not actually correspond to the x-positioned argument to that function call

Example 1

Lets take the following disassembly + decompiled code snippet:

disassembly

 0041f994 21 20 20 02     _move      param_1,s1
                             LAB_0041f998                                    XREF[1]:     0041fa1c(j)  
 0041f998 09 f8 20 03     jalr       t9=><EXTERNAL>::strcat                           char * strcat(char * __dest, cha
 0041f99c 21 28 40 00     _move      param_2=>DAT_0049ea84,v0                         = 0030h

decompiled code

strcat(param_2,__src);

From the instruction:

0041f99c 21 28 40 00     _move      param_2=>DAT_0049ea84,v0                         = 0030h

We can see that the value in register v0 is moved to the variable param_2, and this variable is then passed as the 1st argument to the strcat function (as seen from the decompiled code)

We might think that the value in register v0 is used as the 1st argument to the strcat function. However, in reality, this register is actually moved to the a1 register instead, which relates to the 2nd argument passed to the strcat function

Other findings

We can discover that the 2nd argument to the get_merge_ipaddr function is passed in as the 1st argument to the nested strcat function. Take a look at the following disassembly code (objdump):

41f934:       00a08821        move    s1,a1 #1
...
41f994:       02202021        move    a0,s1 #2
41f998:       0320f809        jalr    t9 #3

1. (#1) Move a1 to s1

• Moves the value of the 2nd argument to the get_merge_ipaddr function to the s1 register

1. (#2) Move s1 to a0

• a0 (value from s1) indicates the 1st argument to the following function call (strcat)

1. (#3) Calls the strcat function (address stored in temporary register t9)

Important notes from each section

1. Disassembly

• The a0 to an registers indicates the exact values passed to each of the nested function calls

1. Decompiled code

• The param_1 and param_2 variables indicates the 1st and 2nd argument to the get_merge_ipaddr functions

• However, even though the 2nd argument (param_2) to the get_merge_ipaddr function is shown to be passed as the 1st argument to the strcat function, this is not actually the case

  • param_2 refers to a1, which instead relates to the 2nd argument passed to the nested strcat function call instead

Hence, the source of truth of argument passing should come from the a0, a1, an, etc. registers in the disassembly, rather than the decompiled code

6.2 gdb, gdbserver

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

https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gnat_ugn_unw/Remote-Debugging-using-gdbserver.htmlgcc.gnu.org

6.2.1 Compile 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    ...

Due to limited space on the device, we can only store a few selected binaries at once. In this case, this will be gdbserver.

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

6.2.2 gdbserver on target router

Next, we can run gdbserver on the target router:

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

UART console

# gdbserver localhost:<port> <program>

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

Alternatively, launch from PID of a running program:

UART console

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

#! eg.
# pidof httpd
# gdbserver localhost:8888 --attach <PID>

6.2.3 Connect to remote target from host machine

• To debug (using gdb) from the host machine

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

$ gdb
gdb> set architecture mips
gdb> set endian little
gdb> target remote <host>:<port>

# eg.
gdb> target remote 8.8.8.8:8888

6.2.4 Attempting to overwrite return address

Refer to the following disassembly snippet:

41f900:       afbf0060        sw      ra,96(sp)
...
41f994:       02202021        move    a0,s1
41f998:       0320f809        jalr    t9

In an attempt to overwrite the return address to invoke an RCE, we first have to identify the address stored in the s1 (location we write) register, and the location where ra (return address to overwrite) is saved

To achieve this, we can can print the values of each register at specific instructions:

1. ra can be found at address $sp+96 as seen from instruction 41f900

2. s1 @ right before 41f994

• The value stored in s1 is written to the a0 register (1st argument to strcat)

Calculate the distance between address stored in s1 and location where ra is saved:

# get the start of the buffer (the destination for strcat)
gdb> info register s1

# calculate the address where the return address is physically stored
gdb> p/x $sp + 96
$x = ...

# calculate distance
gdb> p/x $x - $s1

6.3 Further enumeration

6.3.1 Ghidra

1. Window -> Function call graph

2. Window -> Function call tree

3. Window -> Defined strings

   1. Right-click -> Data -> ... eg. TerminatedCString

   2. Right-click -> References -> show TerminatedCstring

4. Right-click -> References -> show references to ...

5. ...

HTTP POST /apply_cgi
   ↓
apply_cgi()
   ↓
get_cgi("skip_amd_check")   ← optional bypass
get_cgi("<action_var>") == "Apply"
   ↓
for each entry in variables[]:
    if get_cgi(variable_name):
        variable_handler()
            ↓
            get_merge_ipaddr()

POST /apply_cgi HTTP/1.1
Content-Type: application/x-www-form-urlencoded

action=Apply&lan_ipaddr=AAAA...

6.3.2 Fuzzing

$ curl -X POST http://192.168.1.1:80/apply -v
NOT FOUND

$ 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="
# long HTML response

$ 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="
# NOTE the action=Appl or any other invalid options: actio=Apply, etc.
# 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"

Breakpoint does not work

• There appears to be some form of protection from the device kernel or other feature that prevents breakpoints:

(remote) gef➤  break apply_cgi
Note: breakpoint 1 also set at pc 0x421a50.
Breakpoint 2 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

...