Summary
As part of my Masters’ research, I investigated the firmware of a popular smart home security device – the iSmartAlarm CubeOne. Two (2) vulnerabilities (CVE-2017-13663 and CVE-2017-13664) were found and disclosed responsibly to the vendor. This post details how the vulnerabilities were discovered, their implications and the disclosure process with iSmartAlarm. I would also like to highlight that iSmartAlarm has fixed/mitigated the vulnerabilities found and has released a firmware update to the iSmartAlarm CubeOne.
Obtaining the firmware
In this research, I used the iSmartAlarm Android mobile application to control the iSmartAlarm CubeOne. The iSmartAlarm CubeOne firmware was not publicly available on iSmartAlarm’s website and the lack of serial header pins in the CubeOne made it challenging to extract the firmware (Of course, it can be argued that header pins could have been soldered onto the CubeOne, but I had my limitations). However, when a firmware update was done for the CubeOne, a copy of the firmware was also stored on the Android phone (the device used was a Samsung Galaxy Note 4) in the /storage/emulated/0/iSmartAlarm/Firmware/ directory. This allowed me to retrieve the firmware for analysis.
CVE-2017-13663 – Encryption key exposure in firmware in iSmartAlarm CubeOne version 2.1.4.1 allows attackers to decrypt log files via an exposed key
Note: This also affects version 2.2.4.8 of the firmware and has been acknowledged by iSmartAlarm.
The firmware was analysed using the file command and binwalk with the flag -t.
After getting a rough idea of the type of firmware that was being examined and the firmware could be in a compressed form, the firmware was extracted using binwalk with the flag -e.
Two files with the name “40” and “40.7z” were observed and a closer look was taken at the file “40”. The commands file and binwalk -t were ran again. Over here, it was observed that the Linux kernel version is 2.6.21.
Binwalk with the flag -e was invoked again to extract the actual firmware file.
This revealed a CPIO archive with a file name of “440000” and another archive file with a .7z extension (“440000.7z”). The file “440000” was extracted into a folder to contain all the files and folders within the CPIO archive.
The extracted files and folders were examined and a binary named “iSmartAlarm” was discovered inside the /sbin directory.
I was curious what would be inside the binary, and thus ran a strings command on it and wrote the output to a file. Upon examining the output, an OpenSSL passphrase was observed.
CVE-2017-13664 – Password file exposure in firmware in iSmartAlarm CubeOne version 2.1.4.1 allows attackers to execute arbitrary commands with administrative privileges by retrieving credentials from this file
Note: This also affects version 2.2.4.8 of the firmware and has been acknowledged by iSmartAlarm.
I was intrigued by my first finding (CVE-2017-13663) and started wondering how the firmware would react if I interacted with it directly. Previous attempts of port scanning failed and it appeared that the iSmartAlarm CubeOne would refuse any unsolicited external connections to itself. Fortunately, a group of researchers from Carnegie Mellon University and Boston University (paper here) created a tool called FIRMADYNE which allowed dynamic analysis of Linux embedded firmware. Aditya Gupta went further and put together a Linux distribution (AttifyOS) which contained various tools and scripts that are useful for Internet of Things (IoT) penetration testing. In AttifyOS, there was a Python script called Firmware Analysis Toolkit (FAT) which helped to automate the process of the firmware emulation done by FIRMADYNE. Hence, the iSmartAlarm firmware was emulated using FAT.
In one of the working directories of FAT, it was observed that a raw file (image.raw) was created.
Again, it struck me as something that I should take a closer look, and thus I mounted the raw file and explored the file system itself. As the .raw file was an image, I had to use fdisk to calculate the block size and starting block number of the file partition to be mounted.
After mounting the raw file, the file system was explored again. Under the /etc directory, the Linux passwd file was observed and accessed successfully. It was also observed that the Linux shadow file was not present in the /etc directory.
Disclosure Timeline:
A 90 day time frame was given to iSmartAlarm to fix the vulnerabilities, and a further extension of 7 days was offered. Following that, the vulnerabilities would be released publicly.
Credits:
I would like to thank the respective creators of the tools used in this research.
2 thoughts