SSH Dahua
- Thread starter OnePunch
- Start date
i can accessed with this password on this models but there is no access to "shell" with this qr code and domain account that requests password and get verify code....what's the matter?
access to ssh is not efficient when there is no way to shell
Last edited:
It seems Dahua NVR uses DSH.
Have anyone been able to bypass it?
Code:
$ ssh admin@192.168.7.200 "set shell=/bin/sh"
admin@192.168.7.200's password:
warning: setsid failed.
: Operation not permitted
Date&Time: Dec 1 2020 15:45:02
Revision: 64981
Enter 'help' for a list of commands (dsh)
tcgetattr failed!
#Have anyone been able to bypass it?
Malvineous
Getting the hang of it
So I pulled the dsh binary off a firmware image and disassembled it with Ghidra to take a look at this whole Domain Account thing.
Long story short, it uses public key encryption so unless Dahua's private certificate leaks, there's no way to calculate valid check codes.
What happens is that when you run the "shell" command, it collects a bunch of data, mostly random numbers and the current time, as well as the device's MAC address and serial number. This gets encrypted with Dahua's public key, and is passed as the "t" parameter in that URL you get from the QR code.
Dahua decrypt the value, use the third byte in the MAC address (mod 0x18) as an offset, then read four bytes at that offset. They convert those bytes into an 8-digit ASCII hex string and return that, which is what you type in to the "check codes" prompt.
If those eight characters/four bytes match the value originally calculated, and not too much time has passed since the QR code was generated, then it will launch /bin/busybox. It also appears to do some other stuff around alerting as well - maybe just recording the login attempt in the logs or something.
Unfortunately since it is using public key cryptography, it's impractical to decode the values needed from the QR code URL. If we had Dahua's private key then it could be done, but no doubt they guard that very closely.
EDIT: Also, it confirmed that the "diagnose 7" command does nothing. They just have an off-by-one error when they check whether the parameter is valid. The diagnose commands also don't pass any user input into the actual system() call, so there are no injection vulnerabilities available there.
Long story short, it uses public key encryption so unless Dahua's private certificate leaks, there's no way to calculate valid check codes.
What happens is that when you run the "shell" command, it collects a bunch of data, mostly random numbers and the current time, as well as the device's MAC address and serial number. This gets encrypted with Dahua's public key, and is passed as the "t" parameter in that URL you get from the QR code.
Dahua decrypt the value, use the third byte in the MAC address (mod 0x18) as an offset, then read four bytes at that offset. They convert those bytes into an 8-digit ASCII hex string and return that, which is what you type in to the "check codes" prompt.
If those eight characters/four bytes match the value originally calculated, and not too much time has passed since the QR code was generated, then it will launch /bin/busybox. It also appears to do some other stuff around alerting as well - maybe just recording the login attempt in the logs or something.
Unfortunately since it is using public key cryptography, it's impractical to decode the values needed from the QR code URL. If we had Dahua's private key then it could be done, but no doubt they guard that very closely.
EDIT: Also, it confirmed that the "diagnose 7" command does nothing. They just have an off-by-one error when they check whether the parameter is valid. The diagnose commands also don't pass any user input into the actual system() call, so there are no injection vulnerabilities available there.
Last edited:
how did you get the dsh, I use GitHub - BotoX/Dahua-Firmware-Mod-Kit: Unpack and repack Dahua IP camera firmware upgrade images. but the unzipped firmware only get romfs-x.squashfs file (encrypted or encoded ) not full file system
Malvineous
Getting the hang of it
I had a look at that repo but it was very involved. In the end it turned out they're all zip files with the PK signature changed to DH, but the "unzip" utility allowed me to extract them even with the obfuscated signature. Once I had the squashfs files, it turns out 7zip is able to decompress and extract them so that's all I had to do to extract the files. Under Linux "7z x romfs-x.squashfs" extracted the file into the current directory.
I couldn't find a valid firmware for a device with the new web interface so I just picked a random firmware and examined that. It doesn't look like any devices with the new web UI have had firmware updates yet.
dsh is a pretty restrictive "shell". I didn't notice anything in there undocumented, except for something to do with a "return" command. I couldn't work out what it does but it seems to involve changing permissions on running PIDs. Also it's interesting the way it implements security - it first checks whether the command is part of an allowed list, and aborts if not. Then it runs the command if it's valid, and if it's invalid it passes it through system() as a normal command. So it seems dsh is set up to allow you to run Linux commands like /bin/busybox just by typing the command, except that at some point they added a check in to abort early if the command you enter isn't part of a predefined list of valid commands (which only includes the four documented commands). I haven't found a way to disable that check, which would've been another way to launch a proper shell on the device.
I couldn't find a valid firmware for a device with the new web interface so I just picked a random firmware and examined that. It doesn't look like any devices with the new web UI have had firmware updates yet.
dsh is a pretty restrictive "shell". I didn't notice anything in there undocumented, except for something to do with a "return" command. I couldn't work out what it does but it seems to involve changing permissions on running PIDs. Also it's interesting the way it implements security - it first checks whether the command is part of an allowed list, and aborts if not. Then it runs the command if it's valid, and if it's invalid it passes it through system() as a normal command. So it seems dsh is set up to allow you to run Linux commands like /bin/busybox just by typing the command, except that at some point they added a check in to abort early if the command you enter isn't part of a predefined list of valid commands (which only includes the four documented commands). I haven't found a way to disable that check, which would've been another way to launch a proper shell on the device.