This repository contains the results of my August 2020 research of Tiandy's IPC/NVR firmware. I found two vulnerabilities that could be used to remotely recover the administrator password and gain root access to the device.
This repository contains the results of my August 2020 research of Tiandy's IPC/NVR firmware (these devices are also sold as OMNY). This "research" was not exhaustive, but I did find multiple methods to recover the administrator password remotely, enable telnet and change the root password.
It's hard to say exactly which versions are affected, since we can only download the recent ones. All these downloadable versions are affected:
DVRS_V9.12.7.20200422
DVRS_V11.7.4.20200721
NVSS_V13.6.1.20200723
NVSS_V22.1.0.20200722
Not only are there different branches for different devices, but some components are versioned and upgraded separately, like the web API, where I found an authentication bypass that only works for versions released since mid 2019 regardless of the firmware version number. If you happen to know more about versions affected, I'd appreciate your help.
I'm doing full disclosure here, but it's reasonable. A vendor patch (unlikely since they are unresponsive) 'd not make the problem vanish, especially when no devices online have the latest firmware (not even close). The actual vulnerability is that those devices are exposed to the internet. And this is something that end users need to fix, not Tiandy.
As a bonus, I'm also including the firmware unpacker and some info about how to access the streams via RTSP/RTMP (good luck finding that in the manual).
Firstly I present the scripts:
Then I try to briefly explain what these scripts do and why. I don't repeat the code though, but I try to explain enough context so you can understand the code:
Finally, this get relatively technical:
You'll need Python 3 with PyCrypto.
First, try recover.py. This requires port 3001 to be accessible:
python3 recover.py [HOST]
if everything goes well, the administrator credentials should be printed.
If that port is not accessible, the web one might work. This requires the url:
python3 cgi_recover.py http://123.45.67.89
python3 cgi_recover.py https://123.45.67.89
If none of the above work, check if telnet is enabled. If it is, you can root the device directly, just crack this hash:
support:$1$$AErA9BQgLjrxTJB1748k71:501:501:Linux User,,,:/home/support:/bin/sh
(make sure to open a PR in case you actually crack it :D)
In older V7 NVR firmware, you can run commands directly:
python3 ftpupdate.py [host] [adminpass] '[cmd]'
but it gives no output. To make this easier, I've included this shorthand:
python3 ftpupdate.py [host] [adminpass] adduser [username] [password]
This will add another user with uid 0.
First, enable telnet using:
python3 telnet.py [host] [adminpw]
or for recent devices:
python3 cgi_recover.py [host] telnet
Then you can overwrite /etc/passwd (I assume you know how this works). Try filetransport.py first (for NVRs):
python3 filetransport.py [host] [adminpass] put /etc/passwd <[source_file]
this gives no feedback, you need to test it by trying to login...
For IPC models where filetransport.py doesn't work, try upgrade_rw.py:
python3 upgrade_rw.py [url] [adminpass] /etc/passwd <[source_file]
(this gives no feedback either)
Finally, for even newer devices, this can also be done through the web API:
python3 cgi_recover.py [url] write /etc/passwd <[source_file]
If none of the above worked (check whether you can login), retry all those methods but overwrite /config/etc/passwd instead. In some firmware versions, /etc/passwd is a symlink to that. Finally, you can also try overwriting /tdfs/etc/passwd, but after that, a device reboot might be needed, so to reboot, use:
python3 reboot.py [host] [adminpass]
The old V7 (IPC and NVR) firmware doesn't appear to be affected, but if you have the administrator password, for NVRs there's an authenticated RCE (ftpupdate.py), and for IPCs, the upgrade-rw.py script might be used to overwrite /etc/passwd.
Later versions of the NVR firmware (V9 and V11) feature a default account, which combined with "passive" privilege escalation makes it possible to recover the administrator password. We can then overwrite /etc/passwd using filetransport.py.
While the default account isn't present in the IPC firmware, another recovery method appears - the PSW method. This is a password recovery mechanism with no security at all. It's present in all downloadable firmware versions since V9. While filetransport.py only works on NVRs, upgrade_rw.py achieves the same purpose on IPCs by using the upgrade mechanism so we can still gain the root access.
2019 firmware introduces another attack vector - an authentication bypass using the web API. By exporting the configuration file without authentication, we can recover the password and prepare an upgrade package to overwrite arbitrary files.
Speaking of vulnerabilities, there are 4 of them:
Note that I didn't investigate the "cloud" features i.e. whether it's possible to enumerate devices and therefore connect to devices not exposed to the internet (as it is with Xiongmai devices).
In old versions, telnet is enabled by default and this is what we can find in the /etc/passwd file:
support:$1$$AErA9BQgLjrxTJB1748k71:501:501:Linux User,,,:/home/support:/bin/sh
(root password is updated dynamically, also I didn't crack this hash, so pull requests more than welcome :D)
The support user (actually present in all firmware versions) might seem unprivileged, but of course, this user has enough privileges to read the Admin password and overwrite world-writable init scripts in /etc/init.d or even create new ones :)
Conceptually, the method is really simple. We just send a login packet and read the response. That's all, because the "login successful" response contains credentials of all users, regardless of our privileges. While it was like this in V7 too, practically this method became useful only when the default account was introduced in the NVR firmware. The irremovable "Default" has no remote privileges, so you can't do anything with it. Well, maybe except reading the administrator password...
While this sounds trivial, it wasn't that trivial to implement. A custom protocol is used for communication, and passwords are encryptred using DES but with bits reversed (the hardest part was figuring that out), with a key transmitted by the server. Since there's no key derivation, an eavesdropper could easily decrypt everything. Nevertheless, one still needs to figure out that the bits are reversed, or reimplement the whole thing from scratch...
See the recover_with_default function in the recover.py file for the implementation.
When analysing the binary, it's hard not to notice this mechanism. Its whole purpose is to... make password recovery possible, and it actually does this thing well. Too well I'd say...