Special guest at the Black Hat USA event SeungJin Lee, aka beist, from the Korea University highlights the main vectors for exploiting Smart TV technology.
I’m going to talk about Smart TV hacking. Let me introduce myself: SeungJin Lee; my handle is ‘beist’ and I’m from Korea University – the name is Korea University. I’m named to advisory council for Cyber Command in Korea. I’m highly interested in offensive security; I like finding vulnerabilities and reverse engineering, something like that.
We can start with what is the research motivation and what is Smart TV and what’s the attack point on the Smart TV, and then how I made rootkits for Smart TV.
You may have heard of some communities who do a research on some specific brands of Smart TV, but they are doing it mostly from hacker’s point. But this talk is not a talk about hacking, it’s more like a security research on authorizing system, platform layer.
We have some vulnerabilities on Smart TV, but I want to emphasize more about the rootkits. Like, for example, I made a rootkit program, which I can do surveillance via Smart TV camera or mic, this is exploitation of vulnerabilities in Smart TV. It’s very traditional, that’s why I focused more on how to build rootkits on Smart TV. Actually I was only doing it for one specific Smart TV, but I want to say that this issue goes to all the Smart TV vendors, so this is something like a general issue.
So, the motivation: last year over 80 million Smart TVs were sold around the world (see leftmost image below), and the industry says it’s going to be more popular. But we hardly see any security research on Smart TV, so that’s why we did start on Smart TV.
Smart TV is used everywhere, home and office; big companies use Smart TV in their work environment (see middle image above). I want to say that Smart TV is just like a regular PC (see rightmost image above), because it is actually using modern operating system; that one is using Linux inside.
You can see mine here (see image set below). It’s kind of a fancy one; I bought it for like $300. It has a camera and a mic inside. The back has 3 USB ports, so you can connect USB into the Smart TV. There’s a LAN cable and EXlink.
Inside there are some hardware modules like Bluetooth and wireless device. As I said, the operating system is Linux, but the CPU is not Intel, but they are using ARM architecture. The thing is that the vendors make a lot of code for the platform. And it is using Linux, so it is working like a regular PC.
Why they have camera and mic is so that you could control Smart TV using your arm or voice, for example say “Turn it on” so that the TV will turn on. There’s an app store – you can download games, for example, Angry Birds, so you can play Angry Birds with your arms. And you can use Skype as well.
What were the big hurdles (see left-hand image) when I was doing the Smart TV security research? The thing is that there is not much documentation about Smart TV security, and the TV is totally the blackbox, which means you have to do full reverse engineering to understand how it works.
And the thing is that I thought the Smart TV software was not that big, but I realized it is really big. The platform, I mean the vendor, has made over 300 MB of programs inside, which means it will be hard to find some interesting spots for attackers who want to find some 0days inside.
One of the hardest hurdles was that when I was doing the research on Smart TV I broke my TV, so I had to send my TV to A/S center to fix it. It was a really big hurdle, because you couldn’t do everything on software level. It is very possible to make the TV malfunction, and it takes a lot of time to fix it.
I’m going to talk about the Smart TV attack vectors (see right-hand image). I want to say that Smart TV has almost the same attack vectors as smartphone has. I categorized 4 attack vectors. One of them is a hacker who uploads malicious apps to the app market. Smart TV has a market like Android has Google Play and iOS has App store, things like that. It has its own market. There are other vectors as well, I will talk about this in more detail later.
How do I start research (see right-hand image) on Smart TV? It’s pretty much the same when you do it on mobile devices. For example, when you do research on Android or iOS, you’ve got to root it first so that you could understand the internals, so that you could test stuff you want. This is the same, even though the Smart TV uses Linux, but the vendors don’t give us any shell, so you can’t access the box. So we’ve got to find a way to get a shell from Smart TV.
First I tried to download the firmware for my Smart TV model, but the problem was that at the time my Smart TV was very new, so the Samygo site didn’t have any information for my TV. So I decided to get it another way (see left-hand image). As I told you, the Smart TV binaries are very huge, which means that even though there are older versions of firmware, there must be a lot of same code between the older version and the later version. I just downloaded the older firmware and started to analyze the binaries.
You have IDA, which supports ARM architecture as well, which means you could do static analysis using IDA. But I wanted to go an easier way, so I decided to use UART. Actually UART is pretty basic hardware. Why I tried to use UART is that normally embedded developers make a lot of debug messages in the code. It usually goes to UART port, because many embedded systems don’t have monitors, so if you put UART port and if you redirect messages to your box, you can see all the messages which developers made. Of course, we need to do reverse engineering. If you find some strings, that means it’s a lot easier to do reverse engineering, because these binaries are very huge. And you see some exception messages when you do some memory correction down the box, like buffer overflow, things like that.
By default the UART mode is disabled, so you’ve got to make it enabled before using UART (see left-hand image). There are two ways to get into Service Mode. I had to take the second one, because the first one doesn’t have Advanced Mode; only Advanced Mode has the option of enabling UART. Usually normal remote controller doesn’t have info or factory key, so you’ve got to generate the key yourself (see leftmost image below). You see 0x1f and 0x3b that match the info and factory. I got this from Samygo, by the way, so you program this and you send it via, like – yeah, I made this one – this (see middle image below) is for sending IR signals. I used Arduino. You see that Advanced Mode and UART are enabled. So, some configuration (rightmost image below).
I think we are ready for reverse engineering on Smart TV. So you have binaries and you can do static analysis. You can get some useful messages from Smart TV via UART port. My strategy is to find vulnerabilities in Smart TV, I mean, to get the shell. The first one is I do static analysis, I mean reverse engineering. Next, if I think I got something interesting, I mean to try to trigger that vulnerability, I do test. The third one is that after test I read messages from the Smart TV so that I can know if my payload is working or not. If it didn’t work, I would repeat this process until I find 0days in Smart TV.
After this work I’ve gotten, like, 10 vulnerabilities in Smart TV in almost every attack vector. The first one is – I told you that Smart TV has its own app store, but developers can only use HTML, JavaScript and Flash. You cannot use native languages like C or C++. There are two reasons, I think. The first one is because of portability, and the second one is because of the security policy.
Why am I mentioning the security policy here? What is to write in only JavaScript and Flash? For security researches it means that basically JavaScript and Flash are virtual machines, which means you cannot do systems calls directly and you cannot access files directly. Nothing really much you can do in VM. That’s why I told you this is because of security policy.
In app store we have two big attack points (see left-hand image). Smart TV app is running on the web browser, which means the Smart TV web browser has web libraries that desktops have, like WebKit, so they use Adobe Flash. Attacking WebKit or Flash is very traditional, so I passed this one, but I was focusing more on the second part, which is SDK.
You cannot make many useful programs only using JavaScript or Flash, so the vendor gives you SDK so that it’s easier for developers to make applications (see right-hand image). For example, you could use the file I/O API or you could control networks or you could control the screen.
But the thing is that JavaScript and Flash are the virtual machine, but you could have used this API in JavaScript, but this API is implemented in native label, which means you could find some vulnerabilities inside, you would get access to debugs.
Most of APIs do sanity checks (see left-hand image). You see this function, so when you try to do a directory traversal, “../”, it is very simple, by the way.
The problem is that they don’t have sandbox, so if there is any vulnerable API, it’s all gone, because you see that every application is running as root privilege, so if there is any single API bug, you would get root privilege on the box.
I’m going to show three vulnerabilities in the app store. When your Smart TV installs a program from app store, it first downloads an XML file (see leftmost image below). The XML file has application name, title, compression type, descriptions, things like that. This is ARM code, I have like 100 slides. You see that function BL is ZN13CNNaviAppBase9execShell.
This (see rightmost image above) is basically a referral for system function. It does actually vfork, waitpid, execl, almost the same as system function. The problem is that the download URL is a ZIP file. After downloading it they’ve got to unzip the file, but they use internal binary /bin/unzip. They do very basic sanity checks. Like, if there is a pipe or semicolon in the URL, pipe and semicolon are special characters in Linux and you could execute multiple commands at the same time. But they don’t check the tilt characters, so tilt you can also use in multiple executions. So I was bypassing it.
The only hurdle is that you cannot use the slash character directly (see right-hand image). But the installer is a background process, which means it has OLDPWD environment; it basically indicates slash. I could have used the slash character using that environment in Linux.
After that is simple stack buffer overflow (see left-hand image). You see String7ConcateEPcPKc. There is a field in the XML file with that ID. This is for the app directory.
Strcat is known to be vulnerable if they don’t check the boundary (see right-hand image). This is from the UART menu, UART port. You see the PC is the IP in Intel. I gave them a very long string, so this is a very “1999” simple buffer overflow.
There are more (see left-hand image). Mostly there are unzip API, move API, copy API, delete API, but they all use system functions (see leftmost and middle images below), which means you could use a tilt character for multiple executions. This is because all applications are running as root, so if you find any vulnerable API you could get a root.
The other attack vector – you can do web surfing on Smart TV (see leftmost image below), but I told you before that their libraries, like Flash or JavaScript, are really old, you can see their version here – 10.1.105.7 (see middle image below), which is very old. All vulnerabilities that could trigger on desktop are working on Smart TV as well. We made some exploits for that. There are around 10 tcp/udp daemons on Smart TV (see rightmost image below).
For example, you see this port (see right-hand image). We’ll take a look at the 55000 port. Actually it has many commands. I mean you could give it some commands, you get responses from that. You see that, for example, 100 – that is for authentication and providing rich features. You can make an application on smartphone and you could control your Smart TV using your phone. To provide those features, these daemons are for that. Take a look at 121, that RSA decryption.
This (see left-hand image) is a bit weird, but they didn’t use open SSL and things like that, they made some code themselves. I found some memory corruptions while handling that data, I mean, while decrypting the package. You see the exception messages here. I have to say this is exploitable, but it’s very hard to make it reliable, because the PC always points to unmapped memory address, so it’s very hard to make it reliable.
We failed at 7676 to find some vulnerabilities, but it was good to take a look to understand Smart TV. The man-in-the-middle issue is everywhere (see right-hand image). As soon as you have root vulnerability, you could sniff all the network traffic on Smart TV. And you see unencrypted, I mean, plain text, which it’s sending to the other site. You could see ID or password in plain.
There are also physical attack vectors (see left-hand image). As it has a USB port inside, you remember that in Linux 3.6.35 there was a Linux USB kernel driver, simple stack overflow, so it can be triggered as well. I’m going to skip this one, because the rootkit part has more slides.
From those vulnerabilities I’m now having a shell on the box. After that I decided to make some rootkits, because it has a camera and a mic inside, so I thought I could make something fun. Basically, you can do whatever you want on Smart TV (see right-hand image), because it’s exactly like a regular PC running Linux. So you could do hijacking of TV programs or key-logging when the users do web surfing. Of course, sniffing network traffic is possible.
We now have our shell, but I want to make it persistent, so I’ve got to find ways to make it persistent (see left-hand image). So, basically, you have three ideas. First one is rewriting firmware, but again, it could make your TV break, so I don’t want to try that one. The second one is remounting partitions to make it writable, and you put your binaries in that writable partition, but it didn’t work for some unknown reason. The third one is more reliable and more clean.
Let me explain in more detail (see right-hand image). To make our shell persistent – persistence means you get a shell even though the user reboots his/her TV – we tried to find some shelled libraries which are loaded by program. We found some interesting shelled libraries that actually don’t exist. There is a web browser launcher which is executed with every booting. So there is no shelled library, but the web launcher is trying to load it, which means you make your own evil shelled library and just put your library into that directory so that the browser launcher will load your library.
You put just reverse_shell in init function, because by default the program will execute your init function, so it is very simple. The problem was that there was some security program on Smart TV by the vendor (see left-hand image). I called that UEP, because the process name is UEP; it stands for User Executable Preventer. That code, that function takes all the files in Smart TV and checks if these binaries are signed or not, signed by the vendor. If it’s not, it just deletes the file.
You see a problem from this code (see leftmost image below). There is something like the timing issue, because the UEP process has to scan all the binaries in Smart TV. That means usually you have time to do it before UEP program. My solution was very simple: just kill UEP process (see middle image below). It is really simple.
I could make many kinds of rootkits. Before making a rootkit I was asking my friends, which one was the worst case for you if their Smart TV got hacked (see rightmost image above). The result is that most of them voted for watching and listening, I mean surveillance – 85% voted for this.
Before we move on to how I implemented surveillance programs, I want to mention the comparison of surveillance between smartphone and Smart TV. I did a quick test on a smartphone. I made a simple program on Android which takes a picture every minute (see middle image below). I went out with the phone and I used it as my real phone.
I got two problems from the test. The first one (see rightmost image above) is most of the time your phone is on your desk or in your pocket, so that most of pictures you take are black or white or very noisy. Only 1% of photos were ok, but the other 99% of the photos were useless, I mean, for attackers.
The second problem (see right-hand image) is that if you take a lot of photos on smartphone, the battery life is really going down so fast. People would say that surveillance on smartphones is really critical and really bad, and I realized these problems.
Unlike smartphone, Smart TV is almost always connected to the power and you could record via the camera and the mic 24 hours (see left-hand image). Of course, TV cannot move, but on the other hand, a TV is a really good photographer, so they can watch you very well. Of course, the photos from Smart TV are very nice. Basically, surveillance is not about me or you, but it is about your family. I mean, if you get hacked, if your desktop gets hacked, mostly it’s your problem. But if a Smart TV gets hacked, it is about your family or your girlfriend, so do not make the TV see your bed.
Also, I know some big companies like Google or Microsoft use Smart TV at their offices, so it’s not only about personal stuff or home private stuff, but it’s also about the companies, infiltrating some sensitive data (see right-hand image).
We’ll go to technical stuff now (see left-hand image). We have a shell, which means you could do dynamic analysis, I mean, reverse engineering. But the problem is that most of the code is written in C and C++. If you do C++ reverse engineering, it’s really hard to know which function is called. You’ve got to do dynamic analysis to figure out how the Smart TV is working. I was going to make my own DBI program. But I found a really nice one – Collin Mulliner made a DBI program for Android. I slightly modified its code and tried to use it on Smart TV. It works pretty well.
The DBI (see right-hand image) works like it ptrace-s a target process and changes PC register and puts some shell code and executes it. It is pretty much the same when you do hooking stuff. It’s pretty easy, but it works really great.
Like this (see left-hand image), you can put some hooking code and you can do hooking on runtime. Why I used the DBI program is to know, basically, ‘r’ register and ‘pc’ register (see leftmost image below). In ARM, the ‘r’ register has that return address. Once we know ‘r’ register we can know that this function is called from this function. It makes it much easier to understand the whole process. Of course, you can know the arguments, e.g. ‘r0’, ‘r1’, ‘r2’, ‘r3’. And also you see a free table.
In binary they are attacking some global variables. If it’s a “debug” version, it prints some useful messages (see middle image above). So, if you see them, the reverse engineering will be easier. Basically, all binaries are “release” version, so you cannot see those useful messages, but you could do runtime patching, like this way (see rightmost image above), using PTRACE system call. After this you’ll see all the useful messages from Smart TV box.
I wanted to make my rootkit working 24 hours, which means it would work even if users turned off their Smart TV. This should be possible because there is software. After reversing a lot of code I figured out the TCTv::Power() function that does actual turning on and turning off (see middle image below). People reach power function, it turns off screen, and sound mute, and kills some process, but at that time the kernel is still working. After that, when they reach to TCTv::Power() function, it actually goes to turn off. That’s very simple.
Using a hooking program, you just put “return” on the top of TCTv::Power(), so that the sound is mute and screen is black, but it’s still live. It looks like it’s turned off, except that LED blue one (see rightmost image above). To turn off the LED you’ve got to call SetLightEffect() (see leftmost image below). I figured out this function does the job, but it’s a lot of code and I can’t bring it all on this slide. If you call this function with argument at 0, that blue LED will be turned off. So it totally looks turned off, but our rootkit is still working inside.
We’ve got to set second flag for when users turn on the TV (see middle image above). You’ll never notice if there is a rootkit program and if that program is even working 24 hours, even if you turn off your TV (see rightmost image above).
We’ve implemented two surveillance programs. One is taking pictures and sending the photos to my server automatically. The second is recording video and doing some live streaming stuff.
To make that rootkit program, I had to understand how the camera and mic work on Smart TV. I mean, you’ve got to understand very low-level stuff, because there is some API (see rightmost image above). You can control camera and mic using DOS APIs, but it’s application level, which means you cannot be background. So users may notice there is some malicious program working. I had taken that second option. I went to understand that low-level stuff, I mean, to use the camera and the mic.
So, I figured out I’ve got to open that /tmp/stream_socket, and sent the camera these commands, like StopSecCamStreaming and SetMicVolume, and things like that (see right-hand image). This is a protocol between the camera device and user’s web process. If you send those commands to the socket, it takes a picture. It’s like length – command, command – length values and things like that (see leftmost image below). This is the dump for SetCamVideoDisplaySize. You see that there is length and value; it’s very easy to recognize.
To implement the video taker (see middle image above), I figured out: to take a video recording, you’ve got to call those functions. So I did reverse engineering almost of the whole binary (rightmost image above). If you set the resolution – you see that, the numbers – you’re just doing setup stuff. And finally it will start to record using the camera.
But we wanted to make it live streaming, which means you’ve got to dump that recording file into the file system (see right-hand image). Well, actually you could do that, you could send the dump in memory directly without making a file. But we made this for fun, so we just chose the easier way. When you see CMoIPBuffer::Read() function, you see the bad location and the good location (see leftmost and middle images below). If you can jump to good location, there is ‘fopen’ function. It is actually for opening a file and dumping the video buffer into it. I think this is a test code for developers. But in our binary we actually go to bad location by default. You can do binary fetching (see rightmost image below). If you can read the ARM code to jump to the good location, you’ve got to set arg1 + 0x1c, not to 0, for example, 1. Using the code, you can set that value to 1, and after that it will dump the video buffer into a file in the file system.
Ok, now I’ll tell you about real-world video surveillance I tested. I got a shell from my Smart TV. All processes are running as root privilege. I’m injecting some modules into the main binary, I mean, the TV binary. The streaming server is to record using the camera. When I start it’s downloading the video buffer; a very old media player. It is watching what’s going on around. This streaming is not reliable though. There might be a one-minute delay, because I had to restart this program. I explained that my rootkits are working 24 hours. I give some signal, and then I’m going to turn it off. Maybe after one minute you will see the video.
Do you remember that the AP Twitter account got hacked, like, two months ago? I read a newspaper after this accident, and their stock points in the USA went down 1%. 1% is actually huge, isn’t it?
Of course it’s possible to show some text to make hoax on Smart TV (see middle image above). As you see, there are many APIs by the vendor, and using those APIs you could show text, you could show movies, images, music, everything. You could do that. But you cannot use those APIs, because it cannot be background, so users will know that there is some malicious program running. I had to make it on low level, so I again did reverse engineering of the binary and I found some interesting functions (see rightmost image above). CCText is running text. There are some alternatives to show messages on Smart TV. When you click some manual on the remote controller and it shows some text messages, the function flow is like that: first, there are some other functions, and then CKeyHelpBar::SetLastIndex(), CKeyHelpBar::OrderingMarker(), CCTextDrawing::Text(), and VTP::Print.
So, you see those APIs. You may think that it might be easy to find it, but in Smart TV there are over 10,000 functions, and it’s around 300 MB, so it’s very hard to find the right function to do whatever you want (see right-hand image). And also, to use that API you’ve got to make sure. I mean, you see just a simple text box, but actually there are many components inside: label, color, font, size, partition, so you have to make sure to show messages to victims.
Basically, anything can be possible on Smart TV if you hack Smart TV, because it’s just like a regular PC. So, if you understand how Smart TV works, how Smart TV processes work, you can do whatever you want.
So, it’s time for conclusion. I have to say that probably Smart TV hacking doesn’t bring money as much as smartphone hacks, but I believe that personal privacy is more important, I mean, money is also important as well, but personal privacy is very important. That’s why Smart TV industry should make their TV more secure. They have to think about it very seriously.
If you hack a Smart TV, it’s a really nice platform, especially for surveillance, because the power is always connected and they have a camera and a mic inside. It can located in private places, like it could watch your bed. I’m not really sure how deceiving Smart TV users, making hoax affects the people, but this might be a good case. Of course we’re planning to release all the code after the conference, so you can check out updated slides or material on grayhash.com. We have some time for Q&A, and RIP Barnaby Jack. Any questions?
Question: Did you report your findings to the vendor – Samsung?
Answer: First of all, I didn’t say it was Samsung, but I did report this to the vendor, of course. They have fixed some vulnerabilities already, and they are trying to make it more and more secure. They are doing great. Other questions?
Question: Do these vulnerabilities apply to more than one vendor?
Answer: Well, I have to say that all the Smart TVs from multiple vendors are vulnerable; not the same attack points, not the same vulnerabilities, but they are also very vulnerable. Thank you for attending my talk!
