Backstory

During a red teaming exercise conducted for one of our customers, we abused weak passwords to obtain an administrative access to some Zyxel ZyWALL Unified Security Gateway (USG) appliances that were used as both firewalls and VPN concentrators in their branch offices. These appliances are targeted at small and medium businesses and are somewhat popular, at least according to Shodan.

Thanks to our administrative access, we were able to dump the configurations and we noticed that a series of passwords stored on these devices were encrypted in some way. When we did a Google search we could not find any public information on the Internet about how these passwords were stored. Based on our observations, they had to be encrypted with a reversible algorithm because they were passwords that the device itself used, such as the PSKs of VPNs.

Since we had some spare budget, we decided to buy a similar device on eBay and spend some time auditing it on our own. Our next articles will cover the results of our analysis carried out on the physical device. In the meantime, let’s focus on the work we did while we were waiting for the device to arrive.

In this first article of our Zyxel audit series we will cover firmware extraction and password decryption against Zyxel ZyWALL Unified Security Gateway (USG) appliances.

Firmware extraction

First of all, we downloaded from the official website the same firmware images (version 4.10 and 4.70) for the USG310 device that were deployed by our customer.

We started working on version 4.10 of the firmware: the file 410AAPJ2C0.bin is the firmware image in ZIP format. Unfortunately, the ZIP archive was password protected. Searching online we were unable to find any information on the passwords used by Zyxel.

In the PDF documents distributed with the firmware, however, a recovery method is described in the event that the upgrade procedure is unsuccessful.

A lower level procedure is also available in case the previously described method does not work:
https://kb.zyxel.com/KB/searchArticle!gwsViewDetail.action?articleOid=006845&lang=EN

Based on the information in the low level recovery guide we can assume that the “.ri” file is directly executed by the system to install the fundamental components in order to then be able to flash the firmware from the “.bin” file.

We extracted “410AAPJ2C0.ri” with binwalk:

inode@stormbringer:w$ binwalk -e 410AAPJ2C0.ri

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
512           0x200           uImage header, header size: 64 bytes, header CRC: 0xF9EC0106, created: 2014-12-06 03:27:53, image size: 4948010 bytes, Data Address: 0x5000000, Entry Point: 0x80101400, data CRC: 0xD43F46E, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
576           0x240           LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 16814648 bytes

inode@stormbringer:w$

And the files inside it:

inode@stormbringer:w/_410AAPJ2C0.ri.extracted$ binwalk -e 240

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             ELF, 64-bit MSB MIPS32 rel2 executable, MIPS, version 1 (SYSV)
5095576       0x4DC098        Linux kernel version 2.6.32
11385704      0xADBB68        gzip compressed data, maximum compression, from Unix, last modified: 2014-12-06 01:57:21
11487616      0xAF4980        DES SP2, big endian
11488128      0xAF4B80        DES SP1, big endian
11511376      0xAFA650        CRC32 polynomial table, little endian
11910064      0xB5BBB0        Unix path: /usr/bin/magic-seed
11919441      0xB5E051        Unix path: /sys/module/perf_counters/parameters/counter{0,1}
11919495      0xB5E087        Unix path: /sys/module/perf_counters/parameters/l2counter{0-3}
11948723      0xB652B3        PARity archive data - file number 16717
12987688      0xC62D28        Unix path: /home/sdd1/source/410/formal/p2/usg310/src/kernel/arch/mips/include/asm/bugs.h
13224040      0xC9C868        Neighborly text, "NeighborSolicits"
13224064      0xC9C880        Neighborly text, "NeighborAdvertisementsorts"
13227391      0xC9D57F        Neighborly text, "neighbor %.2x%.2x.%.2x:%.2x:%.2x:%.2x:%.2x:%.2x lost on port %d(%s)(%s)"
13231704      0xC9E658        Flattened device tree, size: 10827 bytes, version: 17
13242536      0xCA10A8        Flattened device tree, size: 11728 bytes, version: 17
13622896      0xCFDE70        Unix path: /usr/local/zld_udev/sbin/uevent_helper.sh
14045184      0xD65000        gzip compressed data, maximum compression, from Unix, last modified: 2014-12-06
15042374      0xE58746        Zip archive data, at least v2.0 to extract, compressed size: 226984, uncompressed size: 229081, name: etc_writable/zyxel/secuextender/SecuExtender_x64.cab
15269496      0xE8FE78        Zip archive data, at least v2.0 to extract, compressed size: 610493, uncompressed size: 610989, name: etc_writable/zyxel/secuextender/ssltun.jar
15880177      0xF24FF1        Zip archive data, at least v2.0 to extract, compressed size: 493928, uncompressed size: 516542, name: etc_writable/zyxel/secuextender/sslapp.jar

inode@stormbringer:w/_410AAPJ2C0.ri.extracted$

And again:

inode@stormbringer:w/_410AAPJ2C0.ri.extracted/_240.extracted$ binwalk -e D65000

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             ASCII cpio archive (SVR4 with no CRC), file name: ".", file name length: "0x00000002", file size: "0x00000000"
112           0x70            ASCII cpio archive (SVR4 with no CRC), file name: "zyinit", file name length: "0x00000007", file size: "0x00000000"
232           0xE8            ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/zyinit", file name length: "0x0000000E", file size: "0x00040DEC"
266064        0x40F50         ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/etc_inittab", file name length: "0x00000013", file size: "0x00000BB8"
269196        0x41B8C         ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/e2fsck", file name length: "0x0000000E", file size: "0x0006B64C"
709204        0xAD254         ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/zld_mrd.ko", file name length: "0x00000012", file size: "0x00001788"
715356        0xAEA5C         ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/rw.zip", file name length: "0x0000000E", file size: "0x002106C8"
2879904       0x2BF1A0        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/mke2fs", file name length: "0x0000000E", file size: "0x0004239C"
3151288       0x3015B8        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/switchdev.ko", file name length: "0x00000014", file size: "0x0000AF10"
3196236       0x30C54C        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/zld_fsextract", file name length: "0x00000015", file size: "0x00017098"
3290728       0x323668        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/sw_cn60xx.ko", file name length: "0x00000014", file size: "0x00005418"
3312388       0x328B04        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/zld_udev", file name length: "0x00000010", file size: "0x0001347C"
3391488       0x33C000        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/db.zip", file name length: "0x0000000E", file size: "0x00001428"
3396772       0x33D4A4        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/zyinit_gpl", file name length: "0x00000012", file size: "0x00055128"
3745356       0x39264C        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/fwversion", file name length: "0x00000011", file size: "0x0000014A"
3745816       0x392818        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/switchdev_char.ko", file name length: "0x00000019", file size: "0x00005800"
3768480       0x3980A0        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/unzip", file name length: "0x0000000D", file size: "0x0002B8B0"
3946956       0x3C39CC        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/lkm.lst", file name length: "0x0000000F", file size: "0x00000050"
3947164       0x3C3A9C        ASCII cpio archive (SVR4 with no CRC), file name: "zyinit/platform_support.ko", file name length: "0x0000001B", file size: "0x00004CC8"
3966960       0x3C87F0        ASCII cpio archive (SVR4 with no CRC), file name: "init", file name length: "0x00000005", file size: "0x0000000D"
3967092       0x3C8874        ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"

inode@stormbringer:w/_410AAPJ2C0.ri.extracted/_240.extracted$

Looking at the extracted files, it is possible to identify the “zyinit” binary, which contains some firmware related strings.

By analyzing it, it is possible to see that it launches other external commands, in particular the “zld_fsextract” command:

Searching online for these executable binaries, only an interesting URL was identified (https://www.dslreports.com/forum/remark,26961186), which gave us some information about the ZIP password:

Searching in the “zld_fsextract” binary for the password, it is possible to identify some good starting points for the analysis, like this one:

These options are used by the “unzip” binary to unzip a file with a specific password which is defined in the parameter “-P”. Based on information found online and on a quick analysis, it seems that the binary calculates the unzip password in some way based on the binary name or the binary content.

The fastest way to extract the files is to emulate the MIPS processor and execute the binary.

Launching a Linux/MIPS virtual machine:

> wget https://people.debian.org/~aurel32/qemu/mips/vmlinux-3.2.0-4-5kc-malta
> wget https://people.debian.org/~aurel32/qemu/mips/debian_wheezy_mips_standard.qcow2
> qemu-system-mips64.exe -M malta -kernel vmlinux-3.2.0-4-5kc-malta -hda debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0" -net nic -net user,hostfwd=tcp:127.0.0.1:2222-:22

Getting firmware image information using the “zld_fsextract” binary:

root@debian-mips:~# ./zld_fsextract 410AAPJ2C0.bin -s list
name                :kernel
scope               :-f kernelusg310.bin -f kernelchecksum -D /
nc_scope            :-f kernelusg310.bin
version             :2.6.32
build_date          :2014-12-06 11:27:35
checksum            :6e4e1ad212be0a8a3ce89484f3c5dc1e
core_checksum       :a028057f7c742ea52bd3d0408f38a673

name                :code
scope               :-f bmusg310.bin -f bmchecksum -f kernelusg310.bin -f kernelchecksum -d wtp_image -d db -i -D /rw
scope               :-d db/etc/zyxel/ftp/conf -D /
nc_scope            :-f fwversion -f filechecksum -f wtpinfo
version             :4.10(AAPJ.2)
build_date          :2014-12-09 08:51:18
checksum            :899be95dac4a5bdcfd2f694035f16746
core_checksum       :e25ab639d4ff432bb7ffdc8c1bd39be3

name                :WTP_wtp_image/400AAS4C0.bin
scope               :-f wtp_image/400AAS4C0.bin -D /db
nc_scope            :
version             :4.00(###.4)
build_date          :2013-08-31 20:36:43
checksum            :07773b3deb39a1dd9c2036201097529c
core_checksum       :07773b3deb39a1dd9c2036201097529c

name                :WTP_wtp_image/400AADG4C0.bin
scope               :-f wtp_image/400AADG4C0.bin -D /db
nc_scope            :
version             :V4.00(###.4)
build_date          :2013-08-31 20:35:40
checksum            :aabb0606887cec28a07b8598e699f027
core_checksum       :aabb0606887cec28a07b8598e699f027

root@debian-mips:~#

And using the zld_fsextract binary to extract the firmware without the need to specify a password:

root@debian-mips:~# ./zld_fsextract 410AAPJ2C0.bin ./unzip -s extract -e code
...
root@debian-mips:~#

root@debian-mips:~# ls -al /rw/
total 57192
drwxr-xr-x  3 root root     4096 Nov 23 12:56 .
drwxr-xr-x 24 root root     4096 Nov 23 12:56 ..
-r--r--r--  1 root root 58511360 Dec  6  2014 compress.img
drwxr-xr-x  5 root root     4096 Dec  9  2014 etc_writable
-rw-r--r--  1 root root      139 Dec  9  2014 filechecksum
-rw-r--r--  1 root root    21415 Dec  9  2014 filelist
-rw-r--r--  1 root root      326 Dec  9  2014 fwversion
-rw-r--r--  1 root root     1671 Dec  9  2014 wtpinfo
root@debian-mips:~#

Then uncompressing the new image:

inode@stormbringer:w$ binwalk -e compress.img

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

0             0x0             Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 58509745 bytes, 4958 inodes, blocksize: 131072 bytes, created: 2014-12-06 03:26:20

inode@stormbringer:w$

After seeing that the process worked correctly with a fully emulated environment, we decided to try the single binary emulation provided by qemu. By using “strace” we can quickly see how the “unzip” binary was launched to find the ZIP password.

strace -f -s 199 qemu-mipsn32-static ./zld_fsextract 410AAPJ2C0.bin ./unzip -s extract -e code

Here is the output.

The binary that calculates the ZIP password is statically compiled, therefore it is not so easy to understand how that password is generated, and above all we are lazy…

Password encryption algorithm

Now that we have access to the filesystem, let’s start looking for information on the algorithm used to store passwords in the configuration files. In the configurations available to us, all passwords used the $4$ format and were preceded by the following keywords:

• encrypted-key
• encrypted-keystring
• encrypted-password
• encrypted-presharekey
• password-encrypted
• wpa-psk-encrypted

First step, identify which executables deal with these types of keywords:

inode@stormbringer:w$ grep "encrypted-" _compress.img.extracted/squashfs-root/bin/*
Binary file _compress.img.extracted/squashfs-root/bin/zysh matches
Binary file _compress.img.extracted/squashfs-root/bin/zyshd matches
inode@stormbringer:w$

Looking in the code of “zyshd” for the string “$4$” which identifies the encrypted password:

Looking inside the schrodinger routine. This part generates the salt:

Encryption is performed by the following code:

And then the BASE64 encoding at the end:

Looking inside the “RIJ_cbc_encrypt” function, it is possible to identify the routine “RIJ_decrypt” which leads us to the AES algorithm. This is also confirmed by the name of the function (RIJ = Rijndael) and by the 0xC0 used on the set key, which is 192. AES is one of the few encryption algorithms that support 192-bit keys.

Looking inside the encryption routine, it is possible to identify AES parameters like Td0 memory; it is also possible to use the FindCrypt Ghidra plugin that helps identify the encryption routines in use.

We can assume that the encryption/decryption function works as follows:

RIJ_cbc_encrypt(destination, source, len, unknown, IV, encryption/decryption byte)

At this point we only need to identify the parameters passed to the function.

The IV is:

The encryption key is:

So:

aes_key = "001200054A1F23FB1F060A14CD0D018F5AC0001306F0121C"
aes_iv = "0006001C01F01FC0FFFFFFFFFFFFFFFF"

The same process can be followed on the firmware version 4.70 to identify the $5$ encryption scheme.

To summarize, in the case of a password hash starting with $4$ the algorithm is as follows:

iv = static_iv
key = static_key
salt = generate_8_bytes_from_random()
to_encrypt = salt + password (the password is repeated to reach the 80 bytes)
AES_SET_KEY(aes,key,192)
AES_DECRYPT(aes,cyphertext,to_encrypt,key,iv)
final_encrypted = base64(cyphertext)
final_string = "$4$" + salt + "$" + final_encrypted "$"

In the case of a password hash starting with $5$ the algorithm is as follows:

iv = static_iv
key = static_key

salt = generate_8_bytes_from_random()
to_encrypt = salt + password (the password is repeated to reach the 80 bytes)
AES_SET_KEY(aes,key,192)
AES_DECRYPT(aes,cyphertext,to_encrypt,key,iv)

salt = generate_8_bytes_from_random()
to_encrypt = salt + password (the password is repeated to reach the 80 bytes)
AES_SET_KEY(aes,key,192)
AES_DECRYPT(aes,cyphertext,to_encrypt,key,iv)
step1 = base64(cyphertext)

salt1 = generate_8_bytes_from_random()
to_encrypt = salt1 + step1
AES_SET_KEY(aes,key,192)
AES_DECRYPT(aes,cyphertext,to_encrypt,key,iv)
final_encrypted = base64(cyphertext)

final_string = "$5$" + salt1 + "$" + salt2 + "$" + final_encrypted "$"

We developed a decryption tool that can be downloaded from: https://github.com/inode-/zyxel_password_decrypter

Another possible way to reverse these algorithms is to use dynamic analysis, but it seems QEMU does not fully support the SoC used by Zyxel and generates some illegal instruction fault on most executables. There is a potentially working QEMU patch at https://github.com/amir-mehmood/QEMU-Octeon-MIPS64, but we did not test it.

Finally, when we received the physical device we found out that the /usr/sbin/zencrypt binary present in the filesystem can be used to decrypt these passwords as well:

root@USG20-VPN:~# zencrypt -k 'E8AzAwOyYBwVHJJjtUTDqdAxLDPIr/ncDNV5HCfZFRJlqhYkSqbGvX9BP06YyBg5fGp2HQrwtHsp9mQLNAtBeEIPejrUv5jw/ZRmUx20nuwCNK0UZdeklaFWc945oR3zWVupR2i/KakLhb9d46q72geNfFnXggbJdsl7ObjGKUNLfRF6tMnvxGtPO54PJKpL8E9Af4LAqStAAEPu3S70og8h9PzUER9/Qq246kyTfjONyyVF49EX1l+vg6rD0y+5UnHamBedqvzr/e7az469oViXUIxfMnr/CpMgR5hgzKn3efqldNVSEqmS07UN6CkjHiWaQgnDTxhc4tjbZQjaT3CGVpghF7W3GzmYtMqQlYQ$'
pluto

Stay tuned for our upcoming articles in this series, along with some juicy vulnerability disclosures!