Plex is a great piece of software that makes my life better. They recently announced a DVR feature on their beta channel. It requires hardware – In my case an HDTV antenna that takes over the air signals and makes them available on the local network using DLNA. I settled on the SiliconDust HDHomeRun CONNECT unit that Plex officially recommends.
Yet another cheap, unitasking computer on my network. Oh joy.
I unboxed, connected, and configured the unit on Sunday to watch the evening NFL game on NBC. I had some extra time and decided to learn a little more about the unit.
Is it sending/receiving data from outside of my local network?
I have a portable, managed switch I have set up for basic port mirroring/traffic capturing. I used that setup and captured some traffic with tcpdump. I left to get a sandwich and stopped the capture when I returned. I filtered for data sent to or received from an address not on my local subnet.
root@kali:~# tcpdump -nnq -s 0 -r ~/hdhr01.pcap src net ! 10.0.1.0/24 or dst net ! 10.0.1.0/24 | less
A few pages of traffic showed up with multicasting and UPnP addresses that weren’t filtered out. I eventually ran into the following conversation:
It’s a TCP conversation between the unit and an outside service over port 80. It’s brief and presumably HTTP. Time to check it out.
Why is it doing this?
Using tcpdump for collection and targeted filtering on packet captures is ideal and effective. We did that and now have address and conversation to focus in on further. I can move forward with tcpdump but prefer to use the Wireshark dissectors. The visual layout and features make exploratory searches on targeted data a strength of Wireshark.
I used the Analyze > Follow > TCP Stream option on the conversation. It’s brief and and easy to look at.
The unit scanned for over the air (OTA) channels that it could pick up and checked with a server of HTTP for a list of corresponding of station logos. It also included other information such as device ID, current firmware version, and local IP address.
If I have some time in the future I can use Scapy to send similar information but with an older firmware reported to see if a response is sent to indicate an update.
Is tHE external address embedded in the firmware?
The device is communicating with 188.8.131.52 and it must get that address from somewhere. If it’s not embedded in the firmware then we would expect a DNS query from the unit. We’d also expect a successful DNS answer in response to the query because we know a TCP connection took place.
root@kali:~# tcpdump -s 0 -l -n -r ~/hdhr01.pcap port 53
Boom. We have both the DNS query and the DNS response that we were looking for. The unit queried for ipv4.pool.silicondust.net and was sent 184.108.40.206 in response.
At this point I’m glad that I collected the packets the way I did. Filtering while you collect is ideal but if I filtered out all local network packets it would have resulted the omission of this DNS query and answer. Keeping the traffic relatively controlled by using a mirrored port was adequate.
Why .net and not .com?
I noticed that the DNS query is for silicondust.net and not .com. The URL for all of the product and marketing information about has been from the .com domain. This difference is probably a business decision and nothing more. If we were suspicious and we thought the URL was being used maliciously we could do some sleuthing. A starting point would be to find out if they are both owned by the same entity. A whois lookup may help us with that.
The records match in a way which supports that they are owned by the same organization. The Internet Corporation for Assigned Names and Numbers (ICANN) requires that whois information is accurate and up to date. My government also requires that I leave the tags on my mattress. I think you see where this is going. I’ve never read of whois record authenticity being enforced and I’m certain that people lie all the time. So what good are the records then?
If we choose to trust the silicondust.com domain and whois record then we can call the technical contact number provided and ask them if they also own or trust the .net TLD. This is not a complete or perfect solution but if this particular thing bothered you it’s one of many things you could do.
About that firmware…
If the tcpdump filter did not yield the DNS query and answer I would have downloaded the firmware of the unit from the manufacturer’s website and ran strings, bulk_extractor, binwalk, etc. against it. This would be an effort to show that the address was embedded.
Thinking about how things did turn out though – Should I expect to see ipv4.silicondust.net pop up since it’s the hostname used to check for firmware updates? I would think so but I just can’t support the claim. Yet.
I say that because I walked through the OWASP IoT Firmware Analysis guide with the unit firmware and didn’t have any success. I did test the same guide with a DD-WRT image just to make sure that I wasn’t doing something wrong. It worked. I’ll have to spend some time to figure out what the hold-up is with the SiliconDust firmware. Perhaps I am missing something obvious.
This part quickly became the most fascinating to me. It would be fun to be able to yank that hostname string out of the firmware and have better knowledge to explore future blobs of data where I think a string may be hiding. I’m definitely going to continue with this part.
End of the Day
This was my early Sunday afternoon. It’s nothing hardcore but was still a fun little thing. I did eventually get around to using the hardware to watch some football.