Analysis Environment Build Report
1. Overview
This document is a report written by Team.ENVY (Chan-in Kim, Myung-hoon Park, Myeong-jin Shin, Kang-min Yang, Yu-kyung Lee), who carried out the KITRI BoB 12th NVR Vulnerability Analysis project, on the construction of the Dahua analysis environment.
1.1. Necessity
In order to analyze Dahua's vulnerabilities, debugging the binary that activates the service is essential. Therefore, this document describes how to debug by bypassing watchdog and Dahua's shell access restrictions.
2. Analysis
In the case of Dahua, after Challenge, the binary responsible for the service, is executed, the shell cannot be used, and a prompt where only a few commands can be executed is executed.
You can perform functions such as checking device status and changing settings at this prompt, but escaping was essential because gdb must be run through a shell to build an analysis environment.
Administrators can activate ssh using the web interface and GUI, but Dahua's self-produced dsh is executed, and the shell is very limited to 4 usable commands.
Therefore, it was necessary to make some modifications to the booting process through UART communication.
First, the commands that Dahua's U-Boot can use are limited compared to regular U-Boot.
There were no common commands like printenv.
MStar # printenv
Unknown command 'printenv' - try 'help'However, this could be bypassed as follows.
Additionally, the contents of all environment variables were dumped through nand read and the environment variables were output.
Afterwards, I changed the init variable in bootargs to /bin/sh, but I didn't get a shell.
Also, “Starting Kernel…” After confirming that the kernel boot log was not output, it was determined that the problem was related to standard output.
We confirmed that the dh_keyboard environment variable is a variable that changes the kernel output mode, and changed the variable's value as follows.
Afterwards, I was able to check the kernel output.
Before executing the init script, I tried to run ash by modifying the contents of /etc/passwd, but modification was not possible because all directories except /var, /root, and /dev were read-only.
Therefore, an attempt was made to modify /etc/passwd through bind mount, but the integrity of the read-only file system was verified during initialization of the challenge binary, and if the verification failed, it was rebooted.
Through the script written in /etc/init.d, all services up to just before the challenge binary was executed were activated to enable all functions in the shell, and then the nfs was mounted to enable the analysis binary.
I ran the challenge in the background and redirected the output so that the shell is still available after the challenge runs.
After executing the challenge, the bind mount command could not be executed as if it were prohibited.
Therefore, all of the above restrictions were bypassed through the following steps.
Clone /etc/passwd to a writable location using the cp command.
Perform bind mount immediately before running the challenge (however, the file contents must not be changed)
After the initialization process has been completed in the Challenge binary and the service is running normally, change /etc/passwd contents (dsh → ash)
Perform nfs server mount
3. Analysis environment construction boot script
Modify the contents of rcS and run all init scripts except S99Dahua.
Modify the contents of S99Dahua to background the Challenge binary and redirect output.
To mount a writable directory, run part of the contents of S99Dahua first.
Copy the contents of the read-only directory to a writable location and perform bind mount.
Run the modified S99Dahua.
Afterwards, change the nfs server mount and /etc/passwd.
The full boot script is as follows.
Last updated