Router configuration backups are essential for disaster recovery but can become a critical vulnerability if encryption is flawed. In this technical deep dive, we dissect a router’s backup/restore mechanism, exposing how hardcoded AES-256-CBC keys and a multi-layered encryption process can be exploited to extract sensitive data like Wi-Fi passwords and DDNS credentials.
Target:
Device: Archer AX10 AX1500
Firmware Version: 1.3.10 Build 20240130
Intro:
I downloaded a TP-Link router config. When inspecting the config file with strings I just got junk data. When inspecting the file with binwalk it reports that the file has high entropy which means the file is most likely compressed or encrypted.
Wanting to decipher this config i went ahead and downloaded the firmware from the TP-Link. The file was “Archer AX10_240130.zip”
When extracting the archive it contained a file named “ax10v2-up-ver1-3-10-P1[20240130-rel77367]_2024-01-31_09.13.04.bin”
I ran then ran binwalk to extract the firmware
Binwalk successfully identified the Squashfs filesystem and extracted it to a folder.
The Backup Process: A Multi-Step Compression & Encryption Journey
I then ran “find . -name *backup*” and “find . -name *restore*”
The following files were found
- /usr/bin/tr069/mybackup
- /usr/bin/tr069/myrestore
Upon inspecting the backup file I found the following.
It has multiple step which including decompressing and decryption however there is no encryption key in this file
The script uses cry which comes from local cry = require “luci.model.crypto” for encryption and decryption
Upon inspecting this file ”/usr/lib/lua/luci/model/crypto.lua” I found the AES Key and IV and the encryption method AES-256-CBC
I used a decompiler from https://github.com/CPunch/LuaPytecode to output the screenshot above. The same result can be found using tools such as strings or xxd. I have removed part of the key and iv for legal reasons.
After analysing the backup and restore scripts, I came up with the following steps and developed a script to reveal the plain-text xml file.
Steps:
- Decrypt the config
- Decompress the config
- Save first 16 bytes (MD5 hash) from config this is needed if you want to repackage it
- Strip the first 16 bytes from config write to a new config file
- Decompress the config
- Decrypt the config
- Decompress the config
After completing these step’s I was able to obtain the config in a plain-text xml file.
XML File Contents:
Source Code:
#!/bin/bash
zlib-flate -compress < ori-backup-user-config.xml > output/tmp/archive-ori-backup-user-config.bin
echo “Compressed ori-backup-user-config.xml”
# Encrypt the compressed configuration file
openssl enc -aes-256-cbc -in output/tmp/archive-ori-backup-user-config.bin -out output/tmp/ori-backup-user-config.bin -K “PUT YOUR ENCRYPTION KEY HERE” -iv “PUT YOUR IV HERE” -nosalt
echo “Encrypted archive-ori-backup-user-config.bin”
# Create a tar archive of the encrypted configuration file
tar -cf output/read-backup-userconf.bin -C output/tmp ori-backup-user-config.bin
echo “Created read-backup-userconf.bin”
# Add the first 16 bytes (Product MD5) to the beginning of the tar archive
cat output/product_md5 output/read-backup-userconf.bin > output/tmp/backup-userconf.bin
echo “Added product_md5 to tmp/backup-userconf.bin”
# Compress the tar archive
zlib-flate -compress < output/tmp/backup-userconf.bin > output/read-backup-userconf.bin
echo “Compressed read-backup-userconf.bin”
# Encrypt the compressed tar archive
echo “Encrypting read-backup-userconf.bin”
openssl enc -aes-256-cbc -in output/read-backup-userconf.bin -out “$1” -K “PUT YOUR ENCRYPTION KEY HERE” -iv “PUT YOUR IV HERE” -nosalt
echo “Output written to $1”
Critical Risks
- Hardcoded Keys: The same key/IV pair is used across all devices of this model, making every backup vulnerable.
- Double Encryption : Inner/outer encryption layers provide no security if the key is known.
Conclusion
By reverse-engineering the backup/restore process, I’ve shown how hardcoded keys can be exposed and used against the backup config. Vendors must adopt modern key management practices, while users should demand transparency about encryption methodologies.
Final Note: Always treat router backups as highly sensitive.
