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

For now, let's perform some static 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:

1. Device reboots

2. 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 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

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>

# eg.
gdb> target remote 8.8.8.8:8888

3. Initial enumeration

3.1 Webpage @port 80

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

3.2 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.2.1 Extract information

• We can extract the following information:

1. Identifier for this form (name=setup)

• likely referenced by:

  • document.setup

  • document.forms["setup"]

1. CGI action (action=apply.cgi)

• The /apply.cgi path will be called

3.2.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.2.3 Interesting code locations of document.setup

1. 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

1. Assigned to local variable in a function

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

• This can be found in the selpptppmode() function too

3.2.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:

1. selWan

2. selPPP

3. reboot

4. to_submit

5. 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:

1. selWan

2. reboot

3. selLang

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