Posted by david b.
on December 3, 2013
Moving on with his Black Hat talk, SeungJin Lee describes the discovered security weaknesses of Smart TV technology which can be used for deploying attacks.
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.
Bug case #1
App code functions
System function referral
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.
Bug case #2
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.
Bug case #3 and more
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.
FILESYSTEM.Unzip() bug 2
Further thoughts on bugs
The other attack vector – you can do web surfing on Smart TV (see leftmost 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)
A hacker outside your network
Old Flash version
Analyzing one of the ports
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.
Commands doing crypto
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.
A hacker who can be around
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.
TV pwned: what next?
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.
Persistent shells from TV
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.
Getting more persistent
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.
The UEP hurdle
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.
Dealing with the Preventer
Killing UEP process
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.
Read previous: Hacking, Surveilling, and Deceiving Victims on Smart TV 2: Attack Vectors
Read next: Hacking, Surveilling, and Deceiving Victims on Smart TV 4: Ways to Deploy Surveillance
Like This Article? Let Others Know!
Comment via Facebook: