Taking off the blindfold:
Detecting persistent threats on Draytek
edge devices
About Us: Faraday research team
Octavio Gianatiempo Gaston Aznarez
Security Researcher Security Researcher
● Extensive experience working with firmware
● Strong foundation in computer science
● Active participants in CTF competitions
Talk Overview
Motivation for this research
Reverse Engineering Draytek Firmware
Vulnerabilities and Attack Vectors
Mitigation Strategies
Conclusions
Takeaways
Motivation for this
Research
Case study: Compromise of a client's infrastructure
● We had a call:
○ A client was compromised
○ Outdated Draytek equipment at the Edge
○ Mostly SOHO models (RTOS)
● Incident analysis:
○ Previous vulns with proven exploitation in high-end
models (Linux)
○ Are they exploitable in RTOS models?
○ Other unknown vulns?
○ Were these routers the attackers' entry point?
Increasing trend of • ZuoRAT: A sophisticated malware targeting SOHO
routers, allowing attackers to intercept traffic and
advanced attacks move laterally within networks.
targeting edge devices
• HiatusRAT: A recent malware targeting Draytek
business-grade routers, enabling attackers to
intercept network traffic and exfiltrate data while
maintaining stealth and persistence.
• BenignCertain: An NSA hacking tool targeting
Cisco routers, exploiting a vulnerability in the IKE
protocol to extract VPN credentials. It was leaked
by the Shadow Brokers.
Attack surface
● Over 500k exposed devices: Mainly in the UK
● Previous vulns affecting Draytek routers:
○ Information Disclosure (CVE-2024-23721)
○ Format string (CVE-2023-31447)
○ Cross-Site Scripting (CVE-2023-23313)
○ Unauthenticated RCE (CVE-2022-32548)
○ RCE (CVE-2020-19664)
○ Stack-based buffer overflow (CVE-2020-14473 /
CVE-2020-14993)
○ RCE (CVE-2020-14472 / CVE-2020-15415)
○ Stack-based buffer overflows (CVE-2020-10823 -
CVE-2020-10828)
○ ...
Understanding Draytek firmware for security research and assessment
● The problem: Analyzing closed-source firmware ● Target: Vigor2925 - MIPS32 -
is crucial for identifying vulnerabilities and RTOS
improving security measures.
● Our goal:
○ Reverse engineer the firmware format
○ Extract the firmware
○ Understand previous vulnerabilities
○ Look for new ones
○ Determine the attack vector
Reverse Engineering
Existing tools for extracting Draytek firmware
Draytools:
● Doesn’t work with new firmwares
● Last commit 12 yr ago: “The plan is to
update this to work with newer firmwares,
but that hasn't happened yet”
Previous work
Philippe Laulheret's at Hexacon 2022:
● Emulates Draytek’s bootloader to extract the RTOS
kernel
● This is a manual process that needs to be tweaked for
each firmware version
● Firmware images have other executable components
apart from the bootloader and the kernel
● Firmware images have filesystems
Our approach (1ro Argentina):
● Reverse engineer format and compression
● Write a tool that can be reused for different firmware
versions which:
○ Extracts filesystems
○ Extracts all executable components
Our tool: draytek-arsenal
A collection of tools to help Draytek firmware research
● Easy to install Python package
● Open-source: github.com/infobyte/draytek-arsenal
● Support for newer firmware versions
● We will show its features along this presentation
Firmware format:
● Bin Section
○ Header
○ Bootloader
○ Compressed RTOS image
○ FS with dynamic kernel modules (DLMs)
● Webfs Section:
○ Header
○ FS with web contents
Kaitai FTW
Compression algorithm
• Normal decompression: During boot, the RTOS is
decompressed to the same memory space as the
bootloader using bootloader defined functions.
• Decompression at runtime: By mapping the bootloader
and the RTOS together we saw that other files are
decompressed using the same bootloader functions.
• Error messages to the rescue: Is it LZ4? Why wasn’t
extracted by binwalk?.
Compression algorithm
● Custom LZ4: LZ4 standard block format wrapped in a
custom frame format.
● Frame magic: 0xaa1d7f50
● Frame format: [magic] + n x ([block_size][block_data])
● We wrote a compressor and decompressor
Dynamic kernel modules (DLMs)
● What is a DLM? ● During boot: Modules are loaded from the FW image:
○ Provides extra functionality to the RTOS ○ vr9geoip.dlm: Geolocation of IPs
○ Has firmware independent updates ○ vr9appe.dlm: Used to block traffic
○ Are dynamically loaded (boot or runtime) ○ vr9ssh.dlm: SSH server
Dynamic kernel modules (DLMs)
● Module upload/update:
○ APPE (and SSH) modules can be updated
○ Updates are saved to a persistent flash
FS
○ Modules form the FS are loaded first
○ Prevent loading of default DLM version
Dynamic kernel modules (DLMs)
● Module compression: Using the same algorithm as the
RTOS.
● Module encryption: We reverse engineered the module
decryption, which uses a modified version of XTEA/TEA
● We wrote a decrypter and encrypter
● DLM => Decryption => Decompression => Relocatable
ELF
How are DLMs loaded?
● ELF Loader: Loads relocatable ELFs
● Symbol table:
○ Used to resolve external dependencies present on
the RTOS image
○ Previously described by Philippe Laulheret only as
an aid for reversing
○ Now we know it is for linking modules with the
kernel.
● We can call many firmware functions from a module!
draytek-arsenal
● draytek-arsenal parse_firmware ● draytek-arsenal extract
❯ draytek_arsenal parse_firmware ❯ python3 -m draytek_arsenal extract --rtos
./v2925_394.all ./rtos.bin --fs ./fs --dlm ./dlms
./v2925_394.all
[+] Firmware information: [+] Extracting RTOS from firmware
bin: . . .
checksum: '0xb754a725' [*] All done..
header:
adjusted_size: '0xb6ca38' ❯ tree -L 3
bootloader_version: 5 .
next_section: '0x906c0b8' ├── dlms
product_number: 0 │ ├── vr9appe.dlm
size: '0xb6ca3c' │ ├── vr9geoip_data.dlm
version_info: '0x50' │ └── vr9ssh.dlm
rtos: ├── fs
size: '0x90173d' │ └── V2000
webfs: │ ├── act_sta.htm
checksum: '0xa3049ceb' │ ├── applet.htm
header: │ ...
adjusted_size: '0x5c7a94' │
next_section: '0x5c7a8c' │ └── WEBLOGIN.HTM
size: '0x5c7a98' ├── rtos.bin
└── v2925_394.all
Firmware is extracted, now what?
● To start reverse engineering we need the loading
address
● All Draytek bootloaders start by jumping to the
RTOS decompression function
● This function is located near the start
● Since the loading address is aligned, we look for
the decompression function and round down its
address.
● For example: 0x80028108 => 0x80028000
draytek-arsenal
● draytek-arsenal find_loading_addr
❯ python3 -m draytek_arsenal find_loading_addr ./rtos.bin
[*] First jump found
[*] Kernel decompression function at 0x80028108
[+] Loading address is 0x80028000
Vulnerabilities and
Attack Vectors
Some examples of vulnerabilities we found
● Insecure Password Storage: Passwords are
stored in plaintext.
● Non-Constant Time Comparison: Use of non-
constant time strcmp and memcmp for
password checking.
Some examples of vulnerabilities we found
• Predictable 2-Step Authentication Codes: The
codes used for two-step authentication derived
from the time elapsed since boot
deterministically.
• Null dereference in DHCP server: Can be
triggered from WAN
• Combined => 2FA Bypass
APP Enforcement signature update process
● Update process
○ Manual
○ Automatic
● Format? Json? Yaml?....
APP Enforcement signature update process
● No! APP Enforcement signatures are DLMs!!!
Module related vulnerabilities
● No Certificate Checking or SSL Enforcing
● Postauth Endpoints:
■ APPE signatures upload: Allows
uploading an APPE DLM
■ Configuration upload: Allows
uploading arbitrary DLMs (SSH
maybe? 🤔)
Three ways for an attacker to install a malicious module
● Post-auth endpoints: Attackers can exploit known credentials or other vulnerabilities to gain access to the
web UI.
● Module Update Process: Hijacking the process via configuration modification or DNS control.
● Supply Chain Attacks: Compromising device integrity through supply chain attacks.
How can we build a module?
● draytek-arsenal mips_compile
❯ python3 -m draytek_arsenal mips_compile ./mem_tools.dlm ./mem_tools.c
[+] Image 'draytek-arsenal' is present.
[*] Running mips_tools with: 'compile ./mem_tools.dlm ./mem_tools.c'
[+] Compiled with success. Bye.
● draytek-arsenal elf_to_dlm
❯ python3 -m draytek_arsenal elf_to_dlm --web-header ./mem_tools.dlm “key1” “key2”
./vr9appe.dlm
[*] Crating ./vr9appe.dlm from ./mem_tools.dlm
[*] Packing data
[*] Adding web header
[*] WH - Data len: 2472
[*] WH - Checksum: 0x94e6b7e1
[+] ./vr9appe.dlm creation success
SSH Backdoor
● Replace auth function with hook
Roadmap
SSH Backdoor:
● Reverse engineering the SSH module
○ Hook target: ssh_account_and_ldap_auth
● Writing and compiling a hook
● Merging the hook with the original module
● Modify target functions relocations
● Upload the DLM
Writing and compiling a hook
❯ python3 -m draytek_arsenal mips_compile
./hook.dlm ./hook.c
[+] Image 'draytek-arsenal' is present.
[*] Running mips_tools with: 'compile
./hook.dlm ./hook.c'
[+] Compiled with success. Bye.
Merging the hook with the original module
❯ python3 -m draytek_arsenal mips_merge ./vr9ssh.elf ./hook.elf ./backdoor.elf
[+] Image 'draytek-arsenal' is present.
[*] Running mips_tools with: 'merge ./vr9ssh.elf ./hook.elf ./backdoor.elf
[+] Compiled with success. Bye.
Modify relocations
● Find all relocations to the target symbol
● Replace all with our hook
SSH DEMO
Mitigation Strategies
Mitigation Strategies
● The problem: Persistent threats are facilitated by
dynamic module loading.
● First approach: Patched Firmware to remove the
feature
○ Avoid module loading at boot and APPE
update.
○ Disadvantage: Feature loss
Mitigation Strategies
● Designing a better solution
○ A mechanism for checking in-memory
integrity of other loaded modules
○ Should fetch updated signatures from a
trusted server (checking certificates this
time)
○ Check against other loaded module
signatures
○ Should be included with the firmware
○ Should notify users
Mitigation Strategies
● A PoC DLM Checker:
○ We will replace the APPE module with
our checker for ease of development.
○ Calculate signatures for valid DLMs
○ Check against other loaded modules
signatures when the DLM Checker is
loaded
○ Limitations:
■ Does not check signatures each
time a DLM is loaded.
■ Does not notify users
PoC DLM Checker:
MIPS J-Format
● Calculating DLM hashes:
○ One hash per section (MD5)
○ We only hash static sections
■ Static data
■ Code (only opcodes)
PoC DLM Checker:
● Dynamically finding DLMs:
○ When a module is loaded, an object is created and allocated by using linear_malloc.
○ This object holds the DLM name, a pointer to the text section, and a pointer to the main function
among other things.
○ The rest of the sections are copied after the text section
○ The order is usually defined by the compiler and should not change (text, rodata, data, bss).
DLM Checker: DEMO
Conclusions and takeaways
About these vulnerabilities
● We found these vulnerabilities analyzing Vigor2925 but they are present in several models:
○ Vigor165 and Vigor166 versions before 4.2.7
○ Vigor2620 and VigorLTE200 versions before 3.9.8.9
○ Vigor2860 and Vigor2925 versions before 3.9.8
○ Vigor2862 and Vigor2926 versions before 3.9.9.5
○ Vigor2133, Vigor2762 and Vigor2832 versions before 3.9.9
○ Vigor2135, Vigor2765 and Vigor2766 versions before 4.4.5.1
○ Vigor2865, Vigor2866 and Vigor2927 versions before 4.4.5.3
○ Vigor2962 and Vigor3910 versions before 4.3.2.8/4.4.3.1
○ Vigor3912 versions before 4.3.6.1
● The vulnerabilities are now patched but CVE assignment is still pending
Conclusions
On the offensive side:
● The RTOS is complex and has a lot of code: There are probably more vulns in these routers.
● Try our tools:
○ https://github.com/infobyte/draytek-arsenal
● And please let us know if you find new vulns!
Conclusions
On the defensive side:
● We showed that it’s possible to create a defensive module to verify the integrity of other modules
○ In an ideal situation the firmware should include this functionality
○ It should fetch valid module signatures from a trusted server
○ The device should implement a secure boot chain
Takeaways
● Closed source firmware is just another case of "security" by obscurity.
● Hides vulnerabilities that would otherwise be reported sooner by the community:
○ Plaintext password storage
○ Use of non time-constant comparison functions for sensitive data
○ Predictable 2FA code generation
○ Lack of SSL certificate validation
● Given the increase in edge device attacks, it would be important for the vendors to:
○ Facilitate observability and vulnerability research
○ Implement threat detection solutions
Thanks for your
time
Questions?
github.com/infobyte/draytek-arsenal
@faradaysec /company/faradaysec www.faradaysec.com
