This document is a report described by Team.ENVY (Kim Chan-in, Park Myung-hoon, Shin Myung-jin, Yang Gang-min, Lee Yu-kyeong) who carried out the BoB 12th NVR Vulnability Analysis project.
1.1. Necessity
File system analysis is essential to perform embedded vulnerability analysis. It is an essential step to identify and deactivate a watchdog for debugging, which activates a service for performing vulnerability analysis. Therefore, this document describes the contents of file system analysis to perform vulnerability analysis.
1.2. /etc/inittab
The contents of "/etc/initab" are as follows. First of all, when the NVR is booted, the "/etc/init.d/rcS" file will be executed first. In addition, it can be seen that the "/etc/scripts/SsShutdown.sh " file is executed when the NVR is terminated.
::sysinit:/etc/init.d/rcS
# Example of how to put a getty on a serial line (for a terminal)
::respawn:/sbin/getty -L ttyS0 115200 vt100
# Stuff to do when restarting the init process
::restart:/sbin/init
# Stuff to do before rebooting
::ctrlaltdel:/sbin/reboot
::shutdown:/etc/scripts/SsShutdown.sh
2. Analyzing Boot Scripts
2.1. init script
2.1.1. /etc/init.d/rcS
With the "/bin/mount -a" command, mount the device based on the content in "/etc/mtab", set the environment variable and run all scripts in the "/etc/init.d" directory.
2.1.2. /etc/init.d/S00hostname
Use the hostname command to set the hostname.
2.1.3. /etc/init.d/S01devs
If there is no directory used for the NVR service, create and mount it.
2.1.4. /etc/init.d/S02udevd
Run the udevd command to activate the udev service.
2.1.5. /etc/init.d/S03syslogd
Run the /sbin/syslogd command to activate the syslog service.
2.1.6. /etc/init.d/S04klogd
Run the /sbin/klogd command to record the kernel log.
2.1.7. /etc/init.d/S05sysctl
Run the sysctl command based on the contents of the /etc/sysctl.conf configuration file.
2.1.8. /etc/init.d/S06network
Configure the local network interface using the ifconfig, route command.
2.1.9. /etc/init.d/S82mount
The mount command is used to mount the flash memory, which is an mtdblock device, and the flash memory that is mounted in the app directory is only read-only.
2.1.10. /etc/init.d/S83dvr_main
Run the startup.sh script.
2.1.11. /root/startup.sh
After going through processes such as loading the driver module, initializing storage, and initializing the network related to the NVR service, /bin/scheduler, /root/daemon binary is executed.
2.2. Activation service analysis
2.2.1. daemon
This binary is the last binary to run in init script. When the binary is reversed, the dvr_main binary is executed through the fork function, and when the child process ends, the state is imported using a waitpid system call and different tasks are performed based on the state.
Additionally, as a result of executing the lsof command on the operating cgi, it may be confirmed that the cgi binary also refers to the socket file.
2.3. Check mount
After the boot is complete, the following results can be obtained by executing the mount command.
sh-4.3# mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime,size=74752k)
tmpfs on /tmp type tmpfs (rw,relatime)
tmpfs on /pam type tmpfs (rw,relatime,size=163840k)
tmpfs on /media type tmpfs (rw,relatime,size=32768k)
tmpfs on /debug type tmpfs (rw,relatime,size=5120k)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
none on /dev/shm type tmpfs (rw,relatime,size=10240k)
/dev/mtdblock9 on /system type jffs2 (rw,relatime)
/dev/mtdblock12 on /app type jffs2 (ro,relatime)
/dev/sda1 on /mnt/sda1 type xfs (rw,relatime,attr2,inode64,noquota)
/dev/sda2 on /mnt/sda2 type xfs (rw,relatime,attr2,inode64,noquota)
/dev/sda3 on /mnt/sda3 type xfs (rw,relatime,attr2,inode64,noquota)
/dev/sda4 on /mnt/sda4 type xfs (rw,relatime,attr2,inode64,noquota)
As confirmed in the init script, the /app directory was counted as read-only, and web service-related files existed in the folder. In addition, it was confirmed that the sda device loaded with xfs was a hard disk.
It was confirmed that log-related data were present in the /mnt/sda1 directory as follows.
However, if an error occurs in the dvr_main binary, the daemon binary catches it and reboots the device, so I will explain that part. Reversing daemon is as follows.
do {
if (*(uint *)((int)&status_arr+ ptr1) == uVar3) {
memset(log1,0,0x200);
uVar3 = (&error_code)[result * 3];
snprintf(log1,0x200,"[DAEMON] %s:%d %s\n","handle_dvrmain_exitcode",0x2d0,uVar3);
log_write(log1);
local_15d0 = (&DAT_00013460)[result * 3];
goto LAB_00012108;
}
result = result + 1;
ptr1 = ptr1 + 0xc;
} while (result != 0xf);
local_15d0 = 1;
memset(log1,0,0x200);
snprintf(log1,0x200,"[DAEMON] %s:%d exit reason is [%d]\n","handle_dvrmain_exitcode",0x2d9,uVar 3);
...
snprintf(log1,0x200,"[DAEMON] %s:%d System Restart Count (%d), ExitCode (%d)\n",
"dvr_main_thread_body",0x370,addr,local_15d0);
log_write(log1);
switch(local_15d0) {
case 0:
file system unmount
reboot
case 1:
continue
case 2:
reboot
case 3:
Format after unmount if file system type is xfs or ext type
reboot
case 4:
running swupgrader process background
default:
Forced reboot after unmounting the file system
Since the daemon binary creates a child process through the fork function and executes the dvr_main binary through the execl function, it has a structure that reboots the system through the case statement after checking the error code of dvr_main.