If you’re using Firefox and the videos won’t play, use another browser such as Avast Secure Browser
Introduction
How are 5G, DVB-T2 and a protocol from 1969 connected?
5G is an exciting new communications standard that will allow 1Gbps speed of data transmission and a delay as low as 1ms, along with other cool features like ‘the edge’.
Radio spectrum (on which we transmit Wi-Fi, Bluetooth, Z-Wave, ZigBee, 4G/LTE etc), on the other hand, does not have the bandwidth we would like it to have, in the sense that there is not enough room for all the data we need to transmit. It’s physically impossible to squeeze low-band 5G into the saturated radio spectrum without compromises, one of which would be shutting down the more than two-decade-old terrestrial Digital Video Broadcasting standard for transmitting digital video. This standard was, and still is, widely used in Europe, Asia, Africa, and Australia. According to a European Union decision from 2016, European countries have to free up the 700Mhz band, which will be auctioned to telecommunications operators and used for low band 5G.
Long story short, the European Union decided to auction the 700Mhz band to telecommunications operators, but there still are DVB-T signals on the frequency. Thus, there is a big push to adopt the DVB-T2 standard. However, not all TVs support the new format meaning people need to purchase set-top boxes that do. These set-top boxes are primitive devices consisting of a TV tuner and an output device, while some of the cheapest ones support an internet connection.
But not only are these devices primitive, some are also highly insecure – a revelation we discovered in January this year. This post will reveal how two popular DVB-T2 devices can be recruited by cybercriminals, injected with malware and used as part of a large army of bots to launch attacks on networks. We’ll show their susceptibility to MiTM attacks for the distribution of ransomware on user TVs, and other weaknesses including DNS hijacking and persistent storage of malware payloads.
Revelations aside, we hope this analysis serves as a wake-up call to manufacturers of IoT devices who continue to act irresponsibly in the way they implement technology and protocols. Later on in the post, we’ll expose these failings before sharing recommendations to vendors and security tips to their customers.
But first, let’s set the scene.
IoT Lab Hackathon
In December 2019, we organized the first ever Avast IoT Lab Hackathon for our fellow Avastians. We played around with wireless hacking, facial recognition, IoT Lab automation, and of course device hacking. During the device hacking segement, we took a closer look at devices like Roomba (Right to repair advocates, please take a look at the modular s9+ design) and IP cameras, but we also spent some time on a few DVB-T2 set-top boxes, which we ultimately decided to spend more time investigating.
Same box, different brands
The focus of this investigation was two set-top boxes supporting DVB-T2. These boxes are pretty cheap, popular, look surprisingly similiar and are jam-packed with vulnerabilities.
Meet THOMSON THT741FTA (on the top) and Philips DTR3502BFTA (on the bottom). The beady eyed among you can play a game of “spot the difference” if you want.
First UX Impressions
Setting up the box was fairly simple: connect the box to a power outlet, the HDMI cable to a TV and a network cable to our network to capture traffic. Unfortunately, we were unable to connect the coaxial cable to a TV antenna as one would normally do. The reason for this was simple, we didn’t have one. Despite having over 6KM of cables in our IoT Lab with 10Gbps of internet connection, we never thought we’d need a TV signal, which was necessary during our research. We even have a Faraday cage (or EMC shielded room if you insist) for the sole purpose of having a “quiet” radio spectrum and no noise interference.
Once everything was connected, the set-top box booted up and an initial setup screen appeared where we could choose the language, region, aspect ratio, etc. The first peculiarity we discovered was the regional setup. We could choose between Europe, France and Italy, which is a little odd as France and Italy are in Europe.
Then a four minute scanning procedure took place. Once setup had completed, the front display proudly showed “NULL” instead of the channel number (remember, no signal). The first thing we tried was restarting the box to see if that made a difference.
To our surprise, we were greeted with the “Choose language” screen after rebooting the box. Every time we forced a restart, put the box on standby mode, or even left it on overnight (which triggers the power saving setting and forces the user to go through setup again), it became apparent that something was wrong. Surely the user experience couldn’t be this bad. Up to this point, the only difference between normal users and us researchers was the fact that we didn’t plug the antenna into the set-top box. So we decided to fix that first.
IoT Lab Upgrade
We opted for an omni-directional TV antenna, which receives signals as far as 80KM from the TV station. Our IoT Lab is located on the ground floor, in a room with almost no windows, so having the TV station in the line of sight of the receiver was not an option. We were hoping to receive at least the reflection of the signal. After playing around with the positioning of the antenna, we placed it on our truss near the Lab’s windows.
In the picture you can see the antenna mounted to our truss with no clear visibility of DVB-T2 transmitters. It’s unfortunate but that’s all we could do. We were able to get some reflected DVB-T2 signal to the set-top boxes during the initial setup process.
Taking a closer look
NMAP
Now we’re ready to take a closer look. We started analyzing the set-top-box by running the port/service scanner, NMAP.
We ran a scan on TCP ports 1 through 65535. According to the scan, there was only one port open, the Telnet port. The telnet protocol was first introduced in 1969, making it more than 50 years old.
When we tried to remotely connect to the set-top box, there were no prompts to log in. We were already inside the system, with root access.
We took a closer look at the filesystem and found that ftpput and ftpget, two tools which allow for receiving and transmitting files between devices using the FTP protocol, were available to us. This meant that dumping interesting binaries without playing with base64 dumping should be a relatively straightforward process.
One of the first commands we ran once we obtained access to our test device was uname -a, which provided us with information such as the box’s architecture and kernel version.
We learned that the boxes are based on MIPS architecture, which is one of the most popular architectures for IoT devices together with ARMs. The Linux kernel 3.10.23 was released in 2013, but based on the other information from uname output it was applied to these devices in 2016. This is significant because the maintenance for Linux kernel 3.10.23 expired in November 2017, meaning support for these boxes only lasted a year, and after that bugs and vulnerabilities would no longer be fixed, leaving users exposed to potential attacks.
Next in our usual order of checks was to look into running processes and open ports.
From these casts we can see the main app (skyapp, more on this later), telnetd (an abbreviation of ‘telnet daemon’ which allows access to the set-top-box’s shell) and udhcp (a simple DHCP client which recovers the device’s IP address), and nothing else. It’s a very simple device.
Weather app
The weather app, which is a part of the box’s “skyapp”, allows users to specify their location to receive accurate forecasts.
By analyzing the traffic between our router and the set-top box, it became clear to us that this particular application uses the AccuWeather service (the following domain name confirmed our suspicion, androidquickadver2.accu-weather.com, which looks like a legacy API for Android). The reason why we believe it’s a legacy API is that the entire communication between the set-top box and the AccuWeather backend was unencrypted.
There are two steps required to get the weather forecast at an HTTP level. Step one obtains the cityID from a city name. In our case this was Prague, and we were lucky accu-weather returned Prague, Czech Republic, as the first entry otherwise it would have required fiddling with the weather app setting on the set-top box which wouldn’t have been a nice experience.
URI = http://androidquickadver2.accu-weather.com/widget/androidquickadver2/city-find.asp?location=prague&langid=1&partner=
Step two was to use the cityID from step one and fetch an XML with an actual weather forecast.
URI = http://androidquickadver2.accu-weather.com/widget/androidquickadver2/weather-data.asp?location=cityId:125594&metric=1&langid=1&partner=
With this information, we are able to change the data displayed in the weather application using one of two techniques: straight-up MiTM on the router or a simple DNS hijack. Assuming we were able to run our code on the network gateway, or a router in this case, we could simply change the data being communicated between AccuWeather and the set-top box on the fly, using even more primitive tools than those used by VPNFilter (the IoT malware designed to infect NAS and routers, with capabilities including SSL stripping and generic MiTM attacks on the traffic passing through the router).
We could also apply DNS hijacking so that every time the set-top box requested the IP address of the AccuWeather server, our DNS would reply with the IP address of a malicious server owned and controlled by us.
There was also a third approach: changing the DNS settings of the set-top box itself. More on this later.
RSS Feed
RSS (Rich Site Summary) is used for viewing actual information in short text format. This is the second “smart” functionality available in these set-top boxes. Similar to the weather app, it is also part of the skyapp.
When we take a closer look at the traffic captured, we can see HTTP/HTTPS communication to news servers and the information delivered to box users in XML format.
By applying the MITM technique described above, we are able to modify what users see on their TVs (here’s a pertinent example in video format). Consequently, intruders could show a user a ransomware message telling them their TV has been hijacked and demanding a ransom to free the device.
OK, so we are able to mess with HTTP, and although viewing HTTP traffic is nothing special from a technical standpoint, it’s still a wake-up call for vendors to do a better job at protecting their customers.
But what about HTTPS? We shouldn’t be able to mess with the HTTPS encrypted RSS feed, right?
Wrong. We found a way by creating a self-signed certificate for a DNS record, essentially a DNS hijack, which at the very least should trigger some kind of warning by the box provider. [photo of other rss reader with correct behavior]
DNS hijack on the box
Is it possible to move the DNS hijack attack from the router to the device? Absolutely. We were able to set it up manually by changing resolv.conf to contain our own DNS servers. That’s all it took. But once the current DHCP lease (the temporary assignment of the IP address to the device in the network, which in our case was the assignment of the IP address by router to set-top box) expired, it would be overwritten by values from the DHCP server once renewed. So, instead of logging in every 12-24 hours and changing it time and time again, we added a command to kill the DHCP client.
Persistent storage
While setting up the local DNS settings, we discovered that the file system is mounted in SquashFS, a compressed read-only file system commonly used for IoT devices. This made us curious, because if the root file system is read-only, how is information such as DNS resolvers stored? (For those not in the know, DNS resolvers are servers which translate Domain Name Systems such as google.com to the IP addresses which are used to connect to things).
Then we saw the root file system link to the /config directory, where a few other files were stored and where more could be added, allowing us to obtain persistent storage. This would permit an attacker to store malware payloads or other tools on the box without having to re-install them to the box once a user resets or restarts it. And as a bonus, when we added something to /config and performed a factory-reset, the files remained. So even if a user performed a factory reset, the files added to this directory would be left untouched.
We were then able to remount /etc to modify anything we liked. This, however, didn’t survive a device reboot and required remounting after every boot, but all the changes made and the data added survived.
Botnets
What would be the first thing the “bad guys” would try if they discovered a device running telnet with no security whatsoever?
They may attempt to infect the device with an IoT Botnet. Luckily for the “bad guys”, the firmware has a wget utility built in, which allows fetching data from HTTP servers, be it a webpage or a file with malicious payload built in. So, downloading the binaries within the telnet session is relatively easy. It is important to mention here that in the example below we downloaded the binary of the widespread Mirai botnet to the /tmp directory because by default it is the only folder with write access.
Mirai works perfectly fine in the box and even closes the telnet daemon which is what allowed us access in the first place. This is not set-top box specific behaviour, and you can take a look at that in the killer.c routine in the Mirai source code. If you are interested in many variants of Mirai, feel free to read about 7 other variants that our researcher(s) have analyzed.
After killing the telnet service, the set-top box started scanning the internet for future targets including other devices running the telnet protocol, and it looked quite stable. The reason for mentioning this is that on some less powerful devices, constant scanning of the internet using multiple SYN packets can cause a device to stutter or even reboot itself, and if the binary is not on the persistent storage it can disinfect it eventually.
After playing with the Mirai botnet we decided to test if something more contemporary would work on the device as well. We chose the Corona compiled for MIPS (little-endian) architecture, but it crashed after outputting the message “I ♥ IoT”. Ironic, isn’t it?
Impact
There are tens of thousands of devices among our users that are manufactured by Skyworth IGD (based on the MAC address), which is the manufacturer of the STRONG set-top box and presumably the maker of the Philips version.
You can take a look at all Skyworth MAC address ranges here: https://hwaddress.com/company/skyworth-digital-technologyshenzhen-coltd/
Advice for users
Do not use your set-top box’s network functionality unless it’s absolutely necessary. You are probably better off checking the weather forecast or news on your phone. When you connect a new device to your network you can run a network scanner, such as Avast Wi-Fi Inspector, and see what ports are open. You can also log in to your router interface and check in the settings to see if Universal Plug and Play (UPnP) is enabled. If it is, we recommend you disable it. We also suggest checking your port forwarding configuration and disabling it unless it’s absolutely necessary for your purposes.
Advice for manufacturers
As manufacturers you are not only responsible for the safety of a product (e.g. sharp edges, electrical safety, etc.) but also for its security and therefore the security of the users of your products. While we understand that every iteration of design means more cost, it’s also important to go beyond the bare minimum. It’s important to question whether or not the services included in the product are up-to-date, and if they can be easily updated by the user. For example, for products that require remote connection, is it better to use SSH than Telnet. HTTPS should be used for web interactions, and a Linux kernel that has support for at least the expected lifetime of the product.
Following the design & development phase, it’s important to consider how the threat surface can be reduced. Question if you really need a particular service or application in the final product. If you need to keep something, then consider giving your customers the option to disable non-essential services, change credentials or set up a firewall on the device. Do not forget that your device is not intended to be publicly facing on the internet, it doesn’t mean it won’t. In such an unlikely situation, an attacker can traverse in the LAN.
In general, and wherever possible, use HTTPS instead of HTTP. In this particular case it wouldn’t help unless it were implemented fully, which it wasn’t. For more advanced users, we recommend forcing all DNS requests to pre-validated DNS servers. Only in some very rare edge-cases would this cause connection issues, but a little bit of fine-tuning should help if you do come across problems. It’s important to note that these suggestions are for advanced users, not because they’re hard to configure but because they require some knowledge about the ill-effects these configurations may cause.
CVEs
CVE-2020-11617
The RSS application on THOMSON THT741FTA 2.2.1 and Philips DTR3502BFTA DVB-T2 2.2.1 set-top boxes doesn’t validate the SSL certificates of RSS servers, which allows a man-in-the-middle attacker to modify the data delivered to the client.
CVE-2020-11618
THOMSON THT741FTA 2.2.1 and Philips DTR3502BFTA DVB-T2 2.2.1 set-top boxes have their telnet services hardcoded to start on boot, which allows an attacker on the local network to achieve root access via the telnet protocol.
Communication with OEMs
After looking into these interesting devices and concluding that there is absolutely no use of the telnet service for the casual buyer of such boxes, we decided to contact the alleged manufacturers of the set-top boxes to disclose our findings and suggest disabling the telnet application altogether.
First, we contacted Philips which has a dedicated email for communications about their product security. A few days later we received a response that Philips is now using a subcontractor for the new generation of set-top boxes and that the company acknowledges the problems we bought to their attention, but is unable to fix them. We think it’s unlikely they’ve observed the SDK of these boxes. Nevertheless, Philips seems to be giving these set-top boxes short lifespans.
We also contacted Thomson/STRONG, and this is when things got interesting. Not only is there no obvious way to contact the STRONG support, but their pages lack contact information altogether.
The only way to make contact is through the webpage, which presumably redirects to a local sales team in a predefined country. So, we sent an email describing the issues discovered and our contact information through that page to every single country that was available. We are still waiting for a response.
Conclusion
Despite our technical abilities, the investigation into these set-top boxes was not easy. It was certainly one of the more absorbing analyses we’ve undertaken in recent memory. We covered security research as standard, but went a step further by extending the scope to include user experience and product.
This is not a viral story about some critical vulnerability in a Linux distro that’s been deployed over one million times worldwide. It’s a simple story about how security gaps can occur when new, cheap, underpowered and poorly designed technologies replace older ones.
It is unfortunate that companies continue to push products to the market with no intention of releasing firmware updates and no way for the average customer to secure their box, which in this case is simply disabling Telnet and updating the RSS/Weather apps to use TLS. This negligence affects customers who either cannot afford a new TV or see no need to replace a TV that’s in perfect working order.
Shortly, we’ll be publishing part two of our set-top box story. If you have any questions, feel free to drop us a line at iotlab@avast.com or @AvastIoTLab!
Timeline
Hashes of the binaries for the researchers among you.
Thompson DVB-T2 Box 773e9ba56bd36184b5787e02809210db autorun_skyapp_standby 890ed4358313aefd17a230cb50cd8b7e pm.bin 95e02dfbd885138cd54bba36ff5caa72 pmlite_sram_msd7t75_fd650.bin 679de083448e21d92d13ca5e57a8a5ad pmlite_sram_msd7t75_pt6964.bin c8d96e5eb8f9c6ec9780f783938c803a skyapp 15e5cce6f5ded214f535f7f0bd1887ec skysrv_syscall b4a4adb2a63d471972da6ec73a701904 client.crt e692c71601ee44db6eb59ba8cbee2f41 flash_device Philips DTR3502B 773e9ba56bd36184b5787e02809210db autorun_skyapp_standby 890ed4358313aefd17a230cb50cd8b7e pm.bin 95e02dfbd885138cd54bba36ff5caa72 pmlite_sram_msd7t75_fd650.bin 679de083448e21d92d13ca5e57a8a5ad pmlite_sram_msd7t75_pt6964.bin a9b8a30affa0221a6523c434fcfe56c9 skyapp 9d9525841493e475bc5368ebd617f5f9 skysrv_syscall b4a4adb2a63d471972da6ec73a701904 /etc/client.crt e73a89c8d1c34c1c3784e19f2e5dd2fc flash_device
