The content of the article
This text is based on my report from the Oldschool Way of Hacking Microdigital IP-cameras, which I spoke at ZeroNights 2019. Many asked me to send slides, and I decided that an article with an analysis of all vulnerabilities would be even more useful.
So, my task was to choose a manufacturer that, on the one hand, has long been present on the Russian market, on the other hand, has not yet attracted the attention of security experts. My choice fell on the Korean company Microdigital, which produces IP-cameras.
The company’s website promises us a wide assortment: “over 30 models of recorders, over 150 models of video cameras”. Fine!
The company has existed on the market (including the Russian one) for more than twelve years, which means that its products are widespread. It even turned out that in 2011 an agreement was concluded to equip more than 30 thousand Russian buses with cameras of this company.
First of all, I was interested in devices of the N series, they are quite advanced, but at the same time have not yet become the object of testing for one of the researchers. It's time to fix it! I chose the model MDC-N4090W, which is designed for indoor use. Detailed device information can be glean on the manufacturer’s website.
It is best to start any research on iron with a study of the available documentation.
Open Pdfobtained on the Microdigital website and find out that the camera has a web interface with root users (root password) and anonymous.
Well, since we are on the company’s website, we’ll grab the latest firmware for the camera. I did not have to search long, it is available in the corresponding section.
It is not a fact, however, that the firmware contains all the information necessary for testing, so it will be worthwhile to study it only if there is no full admin access to the device’s console or when you need to study the update. Therefore, we will not waste time now and return to the firmware later.
Preparing the device for testing
Let's start the study of the hardware component. To do this, we disassemble the device (nothing complicated, four screws around the perimeter) and get a printed circuit board.
We also see the following:
- memory S34ML01G100TF100;
- DM368ZCE chip;
- Interfaces: four pins UART, USB, MicroSD, Ethernet.
I do not consider the pins marked as BLE, since these are most likely contacts for connecting the Bluetooth module. We are not interested in this at the moment.
The S34ML01G100TF100 module is a non-volatile NAND memory in the TSOP-48 package. Datasheet Googles easily. From it we learn more about the type of case (NAND08) and the storage size – 128 MB.
For further work, you will need to make a backup of the data, so that in the event of a “bricking” of the camera, you can return it to its original state. The ProMan TL86 or TL866 programmer with the NAND08 → DIP48 adapter is ideally suited for this.
The contents of the flash memory will be saved in our working directory. As with the firmware, you will need to return to it only if it doesn’t come out to get to the admin console.
For the DM368ZCE chip, it was also no problem to google the documentation (Pdf) It turns out that the chip architecture is ARM. In addition, you can get its pinout from the documentation, but we will not need it.
Let's go through the interfaces. From the documentation it is obvious that USB and MicroSD are needed mainly in order to connect external media to the device and use them as storage. For completeness, we can connect the USB fuzzer facedancer21 to the device and, using the umap2scan utility, get a list of supported devices.
Unfortunately, the camera does not support any of the devices we know.
What about UART? Here it is necessary to determine what each pin is responsible for and what is the data transfer rate. To do this, use the Saleae Logic logic analyzer. For convenience, I connected through the wiring, which connects the device board and infrared lights.
We number the pins for convenience.
Before turning on the logic analyzer, connect the ground to the GND pin of the interface for connecting the BLE.
Now we turn on the logic analyzer and the device itself and see what happens.
After turning on the device, pin 3 (in the program, the countdown starts from zero and the pin is numbered as 2), binary data is transmitted. This UART pin is responsible for transmitting data (TX). Having looked at the length of one bit, we get the current transmission speed – 115,200 bits per second. With the right settings, we can even make out part of the text.
Pin number 1 has a constant voltage of 3 V – therefore, it is intended for power supply. Pin number 4 is connected to the GND pin of the interface for connecting the BLE module. So this pin is also “earth”. And the last pin remains at number 2, it is responsible for receiving bytes (RX). Now we have all the information for communicating with the camera via UART. For connection I will use Arduino UNO in TTL adapter mode.
We start monitoring the UART port and get the following.
When the device starts up, the U-Boot bootloader is first loaded. Unfortunately, at the boot level, the TX pin is disabled in the camera settings, so we can only see the debug output. After some time, the main system is loaded, allowing you to enter a username and password for access to the administrator console. The root / root pair (similar to the one used for the web admin and indicated in the documentation) worked fine.
Having received the console, we can study all the working services. But do not forget that we have another unexplored interface – Ethernet. To study it, it will be necessary to prepare a traffic monitoring system. Moreover, it is important to monitor the first network connection.
We should begin to intercept traffic immediately, as some devices start downloading updates on the first connection. Not the fact that the next time it will turn out to intercept communications.
To intercept traffic, I will use the Lan Tap Pro device.
However, we do not find any activity related to updates. This is where the exploration is over, and we are fully prepared to search for vulnerabilities!
Scan the ports with the Nmap utility and get a list of open ports.
Let us briefly go over the services available to us.
When connecting, the service asks for a username and password. Anonymous login is disabled. But here the root / root option came up!
Now we can go into any directory and got a convenient way to upload files to a remote host.
When connecting via Telnet, again, the username and password of one of the real accounts are required and the root / root pair is not the first time. Please note that we no longer need the UART console, since the same thing can be done remotely via Telnet.
To connect to RTSP, again, you need to log in as root / root. Link for connection takes the form
Having studied the device of the web server of the camera, I made this diagram.
The server contains scripts for PHP and CGI applications that communicate with executable files from the directory
/usr/local/ipsca/ (mainly communication goes with
MainProc) To store all the settings, the SQLite 3 database is used.
With it, we will begin to search for vulnerabilities. The database is stored in
/usr/local/ipsca/mipsca.db. It contains everything from system logs to settings for automatically uploading camera recordings to a remote server. The database structure is visible in the screenshot below.
The User table caught my attention. She is responsible for working with user data: username, password, privileges.
The user password is stored in the Password column in notencrypted form, that is, by gaining access to the database, an attacker can obtain an administrator password and test it on other available services.
We pass to scripts on PHP. In the web directory
/root/httpd/htdocs/Web three scripts lie:
login.php not particularly interesting, since PHP is used here only to configure the ActiveX component needed for browser add-ons that stream video on the site.
download.php accepts the name of the file to download, checks its extension and, if such a file is found in the folder
updownloadsends back its contents.
The script does not check the file name, so if someone suddenly decides to put an executable PHP script in this directory, its contents will be downloaded upon request (pay attention to the variable
$file_type, which will be empty in case of unknown extension).
The last file is
upload.php It also turned out to be not without bugs: it has the ability to send not only files with an extension from the white list (.dat and .DAT), but also with an empty extension.
The extension whitelist is defined by the following line.
Now, if the extension value is not empty, it checks for the presence of the extension in the array, which is obtained from
$allowExt. A comma is used as a separator.
But if the extension is empty, execution will not reach this condition and verification will fail. However, this bug is useless for exploitation.
But the next accidentally found bug of this script should already be regarded as a vulnerability: there is no check on the length of the file name. It would seem that this is not a very serious problem, but at the beginning of the program, a Bash script is launched.
He cleans the directory
updownload from previously uploaded files, and in the Bash interpreter, which is included in BusyBox, there is a limit on the length of the file name of 256 characters. It turns out that the script will not be able to delete files whose names are longer than this value.
So how are u
upload.php there is no authorization, any user can upload any number of files with a name longer than 256 characters, and this will lead to the full memory of the device. In other words, Denial of Service.
Example file download.
And getting a list of files in a directory
/updownload/ through the Bash console.
With this, we can complete the study of scripts in PHP and move on to the largest part of the study – CGI applications.
CGI applications on the IP camera are responsible for almost all the actions in the admin web panel, from authorization to updating the device.
I will share the description of the work for testing with the naked eye (vulnerabilities for which you do not need to reverse the executable files) and the actual reverse of these very binaries.
When testing with the naked eye, two vulnerabilities were found. The first allows cross-site request forgery attacks (i.e. CSRF). Its essence lies in the fact that you can apply social engineering and force the administrator to follow a malicious link. This makes it possible to execute almost any command from the admin interface. For example, you can make such a link:
It will create a user tester with password password.
That is, the browser first makes a request to verify the login and password and, if the result is positive, saves the login, password and privileges in the appropriate cookie. And then these cookies are used when sending team requests, for example, when creating a new user.
This is where the second vulnerability appears: even if we do not send the password cookie, the server will still successfully process our request!
That is, it is enough to know the admin login (which by default is root) in order to bypass authorization and make any calls available to the administrator in the camera’s administrative web console! And we found this without even studying the application code. Let's see what will happen in the code itself.
Learning binary applications
Some preparations were required to study the executable files. Namely:
- installing a statically compiled GDB debugger from public repositories on GitHub;
- installing a MicroSD card with the VFAT file system (which allows you to get additional space).
The very process of researching compiled applications looks like this.
- Exploring the app in IDA Pro.
- If necessary, debug the application in GDB on the camera itself via Telnet. By the way, since the application is multi-threaded, I had to check the required process id each time to interact with a specific thread (the thread is created before the request is processed).
- Writing a proof-of-concept to demonstrate vulnerability.
Continuation is available only to participants
Materials from the latest issues become available separately only two months after publication. To continue reading, you must become a member of the Xakep.ru community.
Join the Xakep.ru Community!
Membership in the community during the specified period will open you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score!
I am already a member of Xakep.ru