Hacking a PVR box

THIS POST MAY NOT BE USED IN ANY MALICIOUS WAY. HACKING ANY DEVICE WITHOUT THE OWNER PERMISSION IS ILLEGAL! THE WRITER OF THIS POST IS NOT RESPONSIBLE FOR ANY LEAGAL ISSUES YOU MAY FACE. USE AT YOUR OWN DISCRETION.

My relatives have been having some problems with their Telus PVRs. Telus is a telecom company from Canada. The problems included rental of expensive movies from the boxes, and issues with recording. After doing some simple research, I determined that it was likely a hacker. I decided to put myself in the shoes of the hacker, and try to hack my own PVR. This post will show how I did.

Part 1 – Size up your opponent

The first thing that I did was take a good look at my Telus Optik TV PVR. Seriously! I learned that Arris made it, and that its model number is VIP5662W. I also learned that its FCC ID (found on the back) is ACQ-VIP5662W. My next step was to look up the FCC ID. From that, I learned that it can wirelessly transmit and receive on WiFi and Bluetooth bands. Maybe something to exploit later. Hmm.

I also found out that it has the Broadcom BCM7252 Soc, which includes a dual-core Brahma15 10.5K DMIPS CPU. The cryptically named CPU is, as usual, an ARM chip. Apparently, this chip was designed some time around 2013, which means lots of unpatched/unpatchable bugs, which could lead to exploits, as we have seen with Intel’s disaster of Spectre and Meltdown. To recap, we found some key information just by looking at the box and researching it, but we unfortunately did not find any concrete exploits. Our next step will be to find the IP address.

Part 2 – Finding the IP

My next step in finding any security vulnerabilities/exploits will be finding the IP address. If you know the IP of the device you want to hack, it will make things super easy. So, how do we go about finding the IP address. Whoa! Hold your horses! How did we get into the network (I am the homeowner, so obviously I am in the network, but our hacker would have had to get in somehow. There are a few possibility. One, is that our hacker was already in the network, possibly using some other vulnerable device to get access to the network. Or, they might have exploited some vulnerability in WPA2, or maybe a WPS vulnerability. Whatever the case, they are in the network, so now that that is established, on with the hacking! For me, with my access to the Optik PVR settings, it is a piece of cake getting the IP. Though, a hacker will not have that power. To find the PVR’s IP, we will use ARP. In a Linux terminal (I am using Ubuntu), type arp -a. You will get a list of IP and MAC addressees. Now, we will identify which one is our PVR. For this, we will be using a very popular tool called Nmap. We type into the terminal “nmap <first IP in list>” It is a Windows computer. Next. “nmap <second IP in list>”. A printer. Eventually, we get to a IP that seems to be blocking our probes. We can use the -Pn flag to bypass that. We gat a report that says 2 ports are open. One an HTTP proxy, and another a DSN, whatever that means. After doing a small bit of research, I found that it is used in IPTV. Hmm. Have we found our PVR? This will require some more digging. We can append the -A flag (on top of the -Pn) in our command, getting us more info on the device. On the ports we see, drumroll please..... T-Home Telekom Media Receiver httpd! We have found our PVR! Now, we can go and try to find an exploit.

Part 3 – Nmappping the lands

Well, now that we know our IP, we can do some more detailed scans in nmap. After doing the -A scan, we found this info about the PVR/

Host is up (0.019s latency).

Not shown: 842 closed ports, 156 filtered ports

PORT STATE SERVICE VERSION

8080/tcp open http T-Home Telekom Media Receiver httpd

|_http-title: Site doesn't have a title.

8086/tcp open http T-Home Entertain set-top box httpd

| http-auth:

| HTTP/1.1 401 Unauthorized\x0D

|_ Server returned status 401 but no WWW-Authenticate header.

|_http-title: Site doesn't have a title.

Service Info: Device: media device

What this means is that two open ports were found, each with a service running behind it. One named T-Home Telekom Media Reciever httpd. The httpd gives us a clue, as httpd stands for HTTP Daemon, which is used in Linux. Aha! Linux! We shall next try to find the Linux version used. After using -O flag, instead of the -A flag, we can get info on what OS or operating system, and possibly its version. We get this:

MAC Address: 18:B8:1F:29:35:B4 (Arris Group)

Device type: general purpose

Running: Linux 3.X|4.X

OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4

OS details: Linux 3.2 - 4.9

Network Distance: 1 hop

OK. Not bad. From that we get the MAC Address, indeed confirming that we are looking at the PVR. We can also see that it is a “general purpose device”. Not very helpful, but OK. Next we get the knowledge of it indeed running Linux, in fact a relatively outdated version at that. It could be running any Linux version from 3.2 to 4.9. After doing some research, we find multiple things. One, there are thousands of vulnerabilities for any of the Linux versions in that range, and the other is that Linux 3 was “discontinued” in 2017, but Linux 4 is still be sort of maintained. I also did some more digging with nmap, such as Version/Service detection. I did not find much else. I did find out that it ran MediaKind MediaRoom, formerly Microsoft Mediaroom, which is a form of middleware that allows recording of TV programs, watching IPTV streams, and much more stuff to do with IPTV. The fact that in nmap it was labelled as Microsoft Mediaroom means that the Mediaroom software was not updated since 2013. Unfortunately, I was unable to find a vulnerability in Mediaroom. I did find one vulnerability with Nmap though (not Mediaroom), and I also found some data that would help in future exploits. Next, we will do some packet sniffing with Wireshark, and discuss a vulnerability I found.

Part 4 – Wireshark and Vulnerabilities

Previously, using Nmap, I found a vulnerability with the CVE of CVE-2011-1002. After doing some research into this vulnerability, it has something to do with IP multicast searching, and being able to cause some denial of service attacks on a part of the system. Not very exciting. Anyway, I decided to do a bit of packet sniffing with Wireshark. I started up Wireshark, and started watching some things on the PVR. After I was finished, I checked on Wireshark. The PVR would send packets every little while, only, originating from the cable box and sending packets to a IP address. I will show the slightly cleaned up ASCII.

NOTIFY * HTTP/1.1

x-type: dvr

x-filter: 15535a5e-fbf0-414a-b665-001830f9ec00

x-lastUserActivity: 10/21/2023 3:25:14 AM

x-location: http://192.168.1.65:8080/dvrfs/info.xml

x-device: 98b2bd51-e685-4c62-9753-827d33240eb3

x-debug: http://192.168.1.65:8080

<node count='112496'>

<activities>

<p15n stamp='08D5934E9335DB1E18B81F2935B4'/>

<schedver dver='3' ver='28579' pendcap='True' />

<x/>

<recordver ver='32138' verid='608735528' size='962072674304' free='799467896832' />

<x/>

<tune src='udp://232.9.4.239:6288:ef9dbc9a-3923-42a8-8b60-d69485ebfd25' rate='0x557300' pil='0x0'/>

<record url='http://192.168.1.65:8080/dvrfs/v244' src='udp://232.9.4.239:6288:ef9dbc9a-3923-42a8-8b60-d69485ebfd25' pri='1' st='0xe8ddce6947cc20d4' et='0xe8dde3a92dffb62d' stopped='false'/>

</activities>

</node>

Wow. Lots of data, unencrypted in a HTTP packet. Lets make sense of this data dump.

Part 5 – Data dump analysis

Its XML. With some stuff, that is not XML. I have done some research into what each line does, and I have listed here 2 of the most important elements. Lets take a look.

This element is called tune. It specifies the UDP stream of the channel that I am watching. It also specifies the bitrate that the channel should be streamed at. When I go to the URL, my browser cannot open the UDP stream. VLC cannot open it either. I Nmap the URL, and find that all of the ports are filtered. Oh well. If somebody had the time and resources, which I do not have, they maybe could get in. I cannot.

This one is a bit more complex. It contains more elemants, and has to do with recordings on the PVR. Here is a breakdown of it:

- `url`: This attribute specifies the URL of the recorded video. In this case, the video URL is `http://192.168.1.65:8080/dvrfs/v243`. When I try to open the URL in a browser, it simply gives the error 400 Bad Request.

- `src`: This attribute specifies the source of the recorded video. In this case, the source is `udp://232.9.4.239:6288:ef9dbc9a-3923-42a8-8b60-d69485ebfd25?st=0x00000000E8DDAEE4&et=0x00000000E8DDE760`. This a UDP stream, which like the previous UDP streams, are filtered.

- `pri`: This attribute specifies the priority of the recorded video. In this case, the priority is set to 32. I am not fully sure as to how that works.

- `st`: This attribute specifies the start time of the recording. The value of this attribute may be expressed as a time stamp in seconds, minutes, or other units, depending on the format used by the device. In this case, the start time is `0xe8ddaee400000000`. The human readable time is October 21, 2023 at 03:16:48 AM.

- `et`: This attribute specifies the end time of the recording. Like the `st` attribute, the value of this attribute may be expressed as a time stamp. In this case, the end time is `0xe8dde3a92dffb62d`. The human readable time is: October 21, 2023 at 05:36:09 AM.

- `stopped`: This attribute indicates whether the recording has been stopped. In this case, it is set to `false`, indicating that the recording is still in progress.

Part 6 – Conclusion

No concrete vulnerbilites were found in the boxes. Some things that could lead to bigger vulnerabilities though. If I put more time and effort, and had the resources, I probably would have found one. All that mattrers is that I had tons of fun working on attempting to hack the box. If I find any vulnerbilites, I will update this.

Thank you for reading!

2Hack

Friday, November 10, 2023

Hacking a Telus PVR

Hacking a PVR box

Part 1 – Size up your opponent

Part 2 – Finding the IP

Part 3 – Nmappping the lands

Part 4 – Wireshark and Vulnerabilities

Part 5 – Data dump analysis

Part 6 – Conclusion

No comments:

Post a Comment

Hacking a Telus PVR

Report Abuse

Labels

Popular Posts