We recently released the OpenDNS 2015 Internet of Things in the Enterprise report, an in-depth look at the current state of internet of things (IoT) devices in the enterprise. As part of the research for the report, we analyzed the network activity of a recent model Samsung SmartTV. In this post, we’ll describe the results of that analysis.

All of the analysis was done using direct network captures from a Samsung SmartTV model UN32H5203AF, running version 1117 of it’s on-board software, which was the most current as of the date of testing.

The Setup

One of the key questions we were looking to answer in the report was whether or not IoT devices contact external addresses on a regular basis without user interaction (otherwise known as beaconing).

In order to answer that question with respect to Samsung SmartTVs, we connected the display to a switch with port mirroring enabled. We then setup multiple captures using Wireshark and tshark. Initially, we captured the boot up sequence and a 2+ hour sequence while the display was sitting idle at the “Samsung Apps” page in the SmartHub functionality.

The results from those initial captures prompted us to gather a broader sample set over a 24 hour period.

During all captures, the SmartTV was left in its default configuration. Only the wired network connection and power saving functionality was altered to allow for an extended network capture.

Initial Analysis

Because we were looking for beaconing activity in the network captures, the first step we took was to extract all of the DNS requests from the packet capture using the command:

tshark -2 -r capture.pcapng -T fields -e dns.qry.name -R "dns.flags.response eq 0"

This produced a list of all domain names queried during the capture period:

echo[.]internetat[.]tv
ns11[.]whois[.]co[.]kr
echo[.]internetat[.]tv
cdn[.]samsungcloudsolution[.]com
time[.]samsungcloudsolution[.]com
prov[.]samsungcloudsolution[.]com
www[.]worldtimeserver[.]com
usecho[.]internetat[.]tv
infolink[.]pavv[.]co[.]kr
fkp[.]samsungcloudsolution[.]com
otnprd10[.]samsungcloudsolution[.]net
www[.]samsungotn[.]net
www[.]samsungrm[.]net
vd-emp-prd[.]s3[.]amazonaws[.]com
otnprd9[.]samsungcloudsolution[.]net
az43064[.]vo[.]msecnd[.]net
dly2224qfzjce[.]cloudfront[.]net
0[.]north-america[.]pool[.]ntp[.]org
gallery[.]tv[.]widgets[.]yahoo[.]com
lcprd1[.]samsungcloudsolution[.]net
notice[.]samsungcloudsolution[.]com
d1jwpcr0q4pcq0[.]cloudfront[.]net
xpu[.]samsungelectronics[.]com
lcstg2[.]samsungcloudsolution[.]net
otnprd8[.]samsungcloudsolution[.]net
otnprd11[.]samsungcloudsolution[.]net

For each of these domains, we pulled the records returned from the queries and then searched for the number and timing of each connection to these domains over the course of the capture. We were able to extract this data using a similar tshark command:

tshark -2 -r capture.pcapng -T fields -e ip.src -e frame.time_relative -R "ip.dst == 1.2.3.4 and ip.src == 10.0.0.33"

Where 10.0.0.33 was the IP address assigned to the SmartTV and “ip.dst” was repeated as required to match the A records resolved from the initial domain records.

Results

Compiling the data using the technique described above provided several candidate domains that may be active for beaconing activity:

lcprd1[.]samsungcloudsolution[.]net
d1jwpcr0q4pcq0[.]cloudfront[.]net
www[.]samsungotn[.]net
az43064[.]vo[.]msecnd[.]net
otnprd11[.]samsungcloudsolution[.]net
otnprd10[.]samsungcloudsolution[.]net
otnprd9[.]samsungcloudsolution[.]net
otnprd8[.]samsungcloudsolution[.]net
xpu[.]samsungelectronics[.]com

Initial examination of the domain names hint that the four otnprd* domains are similar in nature. Further analysis of the content of the DNS records shows that they can be treated as a single destination for the purposes of our analysis.

For each of these domains, graphing the network activity outbound from the SmartTV produces the following figures:

plot-xpu.samsungelectronics.com

plot-www.samsungotn.net

plot-otnprd10.samsungcloudsolution.net

plot-otnprd8.samsungcloudsolution.net

plot-othprd11.samsungcloudsolution.net

plot-othprd9.samsungcloudsolution.net

plot-othprd-n.samsungcloudsolution.net

plot-lcprd1.samsungcloudsolution.net

plot-d1jwpcr0q4pcq0.cloudfront.net

plot-az43064.vo.msecnd.net

Based on these patterns, all of the these domains except for lcprd1.samsungcloudsolution.net exhibit in beaconing type activity.

Possible Reasons

After examining the DNS records and packet capture in further detail for the remaining candidate beaconing domains, their speculated use is explained below.

d1jwpcr0q4pcq0.cloudfront.net

Amazon CloudFront is a content delivery network from AWS. The SmartTV is regularly downloading small amounts of data from a distribution on CloudFront. The transaction is encrypted so the contents were not analyzed, but it would be logical to assume that this is a method the SmartTV uses to keep its application caches (latest videos, available apps, etc.) fresh.

www.samsungotn.net

This record contains to a CNAME which points to otnopenapiwww.cloudapp.net. .cloudapp.net indicates a web application or service hosted in Microsft’s Azure environment.

The SmartTV communicates regularly to this application and requests a relatively consistent amount of information. Given the other domains that make periodic requests, it is likely that this is also an application that provides regular updates to content that the SmartTV ensures is up to date.

az43064.vo.msecnd.net

msecnd.net is the primary domain for Microsoft’s Windows Azure Content Delivery Network. The SmartTV is regularly downloading small amounts of data from an endpoint on this network. Similar to the communications to d1jwpcr0q4pcq0.cloudfront.net, the transaction is encrypted so the contents were not analyzed but it would be logical to assume that this is a method that the SmartTV uses to keep it’s application caches (lastest videos, available apps, etc.) fresh.

otnprd-11, 10, 9, 8.samsungcloudsolution.net

The set of otn-prd- domains resolve to Amazon Elastic Load Balancers. These are commonly deployed in front of applications hosted in AWS to ensure that performance and availability goals are met.

xpu.samsungelectronics.com

This domain is the outlier for this analysis. Communication to the domain displays the rough pattern:

  • 10 attempts 5 minutes apart, wait 45 minutes before attempting another 10 times

This pattern was surfaced by view communications with each domain on a minute by minute basis. This pattern is so pronounced it is actually visible in the global view of all traffic (that OpenDNS sees which is 2% globally) as shown below:

xpu.samsungelectronics.com.queries.08-apr--06-mayAttempted communications with xpu.samsungelectronics.com follows the same pattern consistently:

  • The SmartTV resolves the domain to 54.245.219.101 (an A record)
  • The SmartTV then sends a single packet TCP SYN packet to 54.245.219.101
  • In return 54.245.219.101 attempts to send a single ICMP packet to the SmartTV

This appears to be the start of a standard TCP 3-way handshake but the response is an ICMP packet that is blocked on the testing network, so if there is additional behaviour to this pattern we did not see if during testing.

This is odd behaviour and there doesn’t appear to be a straightforward answer as to why this communications pattern is occurring and to what end.

Additional Domains

This set of domains was compared to the unique dataset we have at OpenDNS, and none of these domains are currently flagged for malicious activity.

We also looked at co-occurring domains and found these additional Samsung domains:

prov[.]samsungcloudsolution[.]com
upu[.]samsungelectronics[.]com
dev-multiscreen[.]samsung[.]com
sca[.]samsung[.]com
log-3[.]samsungacr[.]com
log-1[.]samsungacr[.]com
api-hub[.]samsungyosemite[.]com
rd[.]samsungadhub[.]com
notice[.]samsungcloudsolution[.]com
test[.]samsungrm[.]net
amauthprd[.]samsungcloudsolution[.]com
abtauthprd[.]samsungcloudsolution[.]com
gpm[.]samsungqbe[.]com
multiscreen[.]samsung[.]com
oempprd[.]samsungcloudsolution[.]net
time[.]samsungcloudsolution[.]com
noticefile[.]samsungcloudsolution[.]com
vdterms[.]samsungcloudsolution[.]com
us-api[.]samsungyosemite[.]com
osb[.]samsungqbe[.]com
auth[.]samsungosp[.]com
acr0[.]samsungcloudsolution[.]com
sas[.]samsungcloudsolution[.]com
ad[.]samsungadhub[.]com

These domains were not observed during the analysis but our data set shows that—to varying degrees—these domains are usually looked up close to one another. They may be resources used for other Samsung services or devices.

Conclusion

Nothing directly malicious was found in the examination of the Samsung SmartTV’s network communications, however the behavior of xpu.samsungelectronics.com does not fit into any logical use case. Additionally, the frequency with which the SmartTV makes requests to this domain make it significantly easier for Samsung or a malicious actor to track the overall usage of the device.

The average user does not expect their SmartTV to be making external calls to various services without any interaction. The fact that the SmartTV does so almost every minute it’s powered on even without an user interaction is concerning because it makes the use of these devices much simpler to determine from outside of their initial environment.

In an enterprise environment, you should be aware of this activity. These displays are quite noisy on the network. It can be used to establish a baseline of “normal” activity for these displays. You can use that baseline in order to help detect anomalous activity. The apps that run on these displays run in a webkit-based sandbox. That means that they may be susceptible to common webkit vulnerabilities which you should be monitoring for.

To learn more about the context of this research as well as results of our analysis of other devices, please be sure to read the full report. Let me know what you think on Twitter where I’m @marknca and the team is @opendnslabs.

This post is categorized in: