Closed Circuit Television (CCTV) frameworks have multiplied in organizations and are also heavily used for private use. Despite their increased usage lately, they carry along critical points of failure. Hacking of IP surveillance cameras first appeared in the public eye in 2016 when a huge DDoS attack influenced one-third of all US Internet services. An immense number of IP cameras had been hacked on the grounds that their default usernames and passwords had not been changed.
Vulnerabilities in internet-connected camera enable an attacker to seize control of the camera for manipulation. They can remotely control the camera for use as a surveillance device with the capacity to snoop on any recorded sound or video. Pictures and videos recorded by the camera can be transferred to a mobile application. Exploitation of bandwidth resource, end-user deception, anti-forensic data planting and zombie exploitation are a few highlights that fall under possible manipulation.
It is quite easy to scan for the cameras connected to the internet and to get a reverse root shell to forge credentials. Moreover, by messing with DNS settings, the attacker can capture the alerts that the camera sends to its proprietor and also see the videos that would be sent to cloud storage.
The known CCTV vulnerabilities have been listed in a database (CCTV Calculator). They list vulnerabilities existing in renowned products including FOSCAM, Yi Home Camera, Axis, ZoneMinder, Panasonic, Canon, Zhuhai RaySharp, Samsung, Dahua, Grandstream, WESPMonitor, FlexWATCH, WebGate, D-connect, Mobotix, Cisco, Hikvision, Sony, TRENDnet, CIPCAMPTIWL, TVT, AVTECH, Brickcom, TP-LINK, AirLive, QNAP, Arecont Vision, GeoVision, March Networks, and Linksys.
Axis Network Camera
A total of seven vulnerabilities were found in the cameras by researchers at VDOO. Researchers have also reported that three of these vulnerabilities, when bound together, could give remote access to the cameras which will allow an attacker to execute remote shell commands. What is most disturbing is that a potential attacker who has access to the camera login page through the network can take complete control of the device and take over functions such as access the camera’s video stream, alter the camera’s software, and even render the camera completely useless. There's likewise the potential for cameras misused along these lines to be utilized as an entry point in the network for a more extensive attack, as well as the likelihood of the camera being roped into a botnet.
Yi Home Camera
Yi Technology, a renowned Chinese organization closely connected with and supported by Xiaomi, entered the US market bursting with a newer, affordable IoT camera. The Yi Home Camera i27US is an entry-level device, which gives owners a chance to see the camera's feed from anyplace and highlights offline capacity and membership-based cloud storage.
There are numerous consequences to the security vulnerabilities within the firmware of this surveillance camera, such as viewing video feeds, disabling camera to prevent recording, deleting stored videos, launching potential attacks against owner’s phone app, and other devices on the home network.
Hanwha Cameras
Researchers stated that the figure could be a few times higher because it didn't take into account extra gadgets which may be put behind routers and firewalls. These security gaps could enable attackers to get access to live video and sound, and remotely get root access to the camera - possibly accessing whatever is left of the network.
While the attack was conceivable only if the attacker knew the serial number of the target camera, scientists stated that with the manner in which these numbers were created, it could have been relatively easy to crack the serial number via brute-force attacks as the camera-registering system didn't have protection against such attacks.
A large number of security holes in the Hanwha SmartCam came from its cloud-based framework. The camera's cloud server architecture highlighted extra vulnerabilities that were appealing to attackers. As a result of a fault in the design, an interloper could obtain entrance through the cloud to all cameras and control them. Experts state one of the primary issues, for this case, was that the cloud architecture depended on the XMPP communications protocol.
Attackers would also have been able to compromise the cameras by spoofing the DNS server addresses indicated in the camera's settings. Kaspersky Lab likewise discovered that a bargained camera could possibly be utilized to steal accreditations from camera clients, as the alerts from the gadget could be sent to the client by means of email and social media.
Foscam camera
According to the researchers at VDOO, the vulnerability trifecta included - an arbitrary file-deletion bug, a shell command-injection flaw, and a stack-based buffer overflow vulnerability.
Here’s how an attacker gained access to the Foscam security camera: to begin with, the malicious client utilizes arbitrary file deletion vulnerability to erase certain critical files that result in an authentication bypass. Then, the attacker utilizes stack-based buffer overflow vulnerability to crash the webService procedure, enabling him to sidestep the webService and gain administrative access. At last, a shell command injection vulnerability is used to escalate the attacker's privileges to root level.
The Foscam and VDOO team worked diligently towards securing the camera as soon as possible. Soon after, the Foscam team released patches to these vulnerabilities and users were encouraged and guided to update their devices.
Bosch IP Camera
An attacker could remotely execute code on the device (RCE) using this vulnerability. This would enable an attacker to reactivate disabled features (e.g. telnet) or bypass access credentials (username/password). An attacker, however, needs to have access to the network access to the webserver (HTTP?HTTPS) of the device in order to carry out the attack.
There is presently no sign of the exploitation code being openly known or used. Bosch rates this vulnerability as critical and prescribes clients to update gadgets with upgraded versions of firmware. A decrease in the gadgets' system exposure is recommended in the event that the firmware upgrade is not possible in a timely manner. In order to achieve this, the Bosch cameras ought to be firewalled alongside additional steps like the gadget's IP filtering features and network isolation by VLAN.
The above-mentioned cases demonstrate that despite being hugely popular, surveillance cameras are inclined to vulnerabilities and that there is urgency for taking cautions and applying best practice guidelines. Countermeasures are required to shield these IP cameras from hacking and exploitation of the communication assets.
It is highly recommended to change default credentials and to keep updating them from time to time. Layers of protection and detection of surveillance activity are required on a minute-by-minute basis to maintain system integrity. Likewise, critical data requires encryption, cryptographic complexity and protection by tunnelling to confuse analysis.
Clients should update their firmware version and IP Camera anti-virus software on a regular basis. In case of disclosure of a vulnerability, clients should always keep an eye out for a vulnerability patch. With a fix available there's no good reason for winding up in grave circumstances. Being a responsible user is after all in your own hands. So, take the next step towards securing your device’s security.
Addendum: Reproducing CVE-2018-6830 in Foscam
It’s an important part in the learning process to be able to reproduce already discovered vulnerabilities. Here we will be showing you the steps to replicate CVE-2018-6830 - Arbitrary File Deletion in Foscam which was discovered by VDOO. Since purchasing an IP camera just for the sake of testing a vulnerability might not be feasible to all, in keeping the same view, we will be doing the test entirely in software using emulation techniques.
Obtaining the firmware
The first step is to get hold of a vulnerable firmware version. In many cases, after a vulnerability is discovered, reported and patched, the vendor no longer offers the vulnerable firmware version for download. The same is the case with Foscam. The official download site (https://www.foscam.com/downloads/index.html) no longer offers a vulnerable firmware. In such cases, we have to look at other sources. If we are lucky we can obtain an old version on The Wayback Machine else it’s a matter of Google Search.
Decrypting the firmware
We will use binwalk for inspecting the firmware package. It’s a tool for analyzing, reverse engineering and extracting firmware images. Binwalk is generally used for firmware analysis but can also be used on any unknown files. Running binwalk reveals that the firmware package is encrypted. To proceed we need to decrypt it.
Searching for “foscam firmware decrypter” leads us to this script (https://github.com/mcw0/PoC/blob/master/decrypt-foscam.py). Running the script on our encrypted firmware we get back the decrypted one.
From the output of the script we can infer that the firmware binary is encrypted using the AES cipher with a block size of 128 in CBC mode. The key for decryption is WWeift*v2. We will again see this password a bit later.
Analysis
The decrypted firmware is just a blob of gzip compressed data.
Gunzipping it reveals it’s a tar archive. So essentially firmware-de.bin is a tar.gz archive.
Hence, firmware-de.bin can be extracted using just a single command.
Several files were extracted. Among them the .md5 files simply contain the MD5 checksum of the correspondingly named file.
WriteFlash is 32-bit ARM ELF. It’s purpose is to update the firmware on the IP camera after being uploaded. Analyzing in Binary Ninja we can find few occurrences of decryption related strings.
If we look at the string passed to sprintf we can notice there are several %s placeholders. The final command which is passed to system is generated at runtime. This is done just to hide the actual command from appearing with a simple strings scan.
To find out the final command, we can simply construct the string ourselves. We obtained the offsets from the MOV instructions.
offsets = [14,15,4,13,18,18,11,93,4,13,2,93,77,3,93,77,0,4,
18,77,53,54,60,77,2,1,2,93,77,10,93,48,48,4,8,5,19,70,21,54]
charmap = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+|`-={}[]:;'<>?,./\" "
print ''.join(map(lambda x:charmap[x], offsets))
Running our script, we get the final command.
This is the same password which had obtained from the firmware decryption script. mtd.sqfs is a SquashFS file system. However, on trying to extract using unsquashfs it fails.
The error message indicates that the file was probably truncated. There is another sqfs file but the file command doesn’t recognize it.
Interestingly, if we append mtd_ext.sqfs at the end of mtd.sqfs and pass the resultant to unsquashfs it succeeds.
The extracted files looks something like below (shown upto three folders deep). Within squashfs-root, there are two directories - mtd and mtd_ext.
Emulating the firmware
The extracted firmware does not contain a full linux file system. For instance there’s no /etc directory. As a result we cannot use Firmadyne for emulation. However that does not stop us from using qemu user-mode emulation to run the individual binaries.
As per the blog post from VDOO, the lighttpd binary is vulnerable to Arbitrary File Deletion. So let’s try running it using qemu.
The ld-uClibc.so.0 shared library is missing. We can get a copy of that library and ld-uClibc-0.9.28.so from https://github.com/joninvski/arm-uclibc-3.4.6/tree/master/lib
In a similar way, we also need the following files in /lib
- libdl.so.0, libdl-0.9.28.so : From GitHub
- libssl.so.1.0.0 : From /basic_lib directory
- libcrypto.so.1.0.0 : : From /basic_lib directory
- libc.so.0, libuClibc-0.9.28.so : From GitHub
At this point, the binary does run but it quits immediately after. We need to provide a configuration file.
Within the mtd/app directory there’s a lighttpd-1.4.35-hi.tar.xz file which contains the configuration file for lighttpd. We can extract that to usr/local within the chroot directory.
And run again by specifying the path to the config file.
This time we hit a different error. Qemu crashes with a segfault. Debugging the binary we found out the reason for the crash was due to the custom signal handlers installed by the app. For brevity we have not included the debugging steps here. We need to patch out the code which deals with the signal handling. In addition we need to run the binary with the -D flag which stands for non-daemon mode to prevent it from forking which can create further problems down the line.
We have to patch all the instructions from 0xf6c4 to 0xf78c with NOP. Originally the code looks like.
We can run the following script in the Binary Ninja Python console to patch the required instructions.
After patching, it looks like
We can save the patched file with a new name. Let’s try running the patched file.
Qemu no longer segfaults but lighttpd still exits as it was not able to spawn CGIProxy.fcgi. As a workaround, we can try disabling fcgi altogether. We can edit the configuration file modules.conf and comment out the line include "conf.d/fastcgi.conf" as shown.
With the updated configuration in place, lighttpd runs without errors.
Reproducing the vulnerability
To create the same environment as that of the IP camera we need to create a /tmp/www/snapPic. As per the disclosure from VDOO, if the request URL contains the string /config/export or /snapPic/ it proceeds to delete that file.
First, let us create a file under /bin which we wish to delete by abusing the path traversal bug.
We spawn a Python shell and issue a GET request to http://127.0.0.1:9000/snapPic/../../../bin/importantfile.png. The web server runs on port 9000 and we can know this from the lighttpd config file.
On the other terminal where lighttpd is running, it prints several messages indicating it is going to delete the aforementioned file.
Indeed, if we do a directory listing of /bin, we can notice that importantfile.png is missing.
Thus we are able to reproduce the same results as VDOO obtained. In addition, we did the entire testing on pure software using qemu without access to the physical camera.
Final Words
Qemu offers a nice way to be able to test firmware without access to the physical hardware. However this has its downsides too. The task was not so straightforward and we had to make a lot of changes just to get it running. However during the process we learnt a lot about firmware emulation and how to overcome the obstacles one by one. Had we used a real device, the exploitation would have been a lot easier but on the flip side it would have little educational value as there is nothing new to discover.
