如果您正在使用 Firefox 且，可以使用其他浏览器，如 。
介绍
5G、DVB-T2 与一个来自 1969 年的 有何关联？
5G 是一种令人兴奋的新通信标准，能够实现高达 1Gbps 的数据传输速度，延迟低至 1 毫秒，以及其他一些很酷的功能，如「边缘计算」。
另一方面，无线频谱（我们用来传输 Wi-Fi、蓝牙、Z-Wave、ZigBee、4G/LTE等的频谱）并没有我们期望的带宽，这意味著没有足够的空间来传输我们需要的所有数据。在已饱和的无线频谱中压缩低频 5G几乎是不可能的，这会导致一些妥协，其中之一就是关闭这个已有二十多年历史的地面 数字视频广播
标准用于传输数字视频。这项标准曾广泛用于欧洲、亚洲、非洲和澳大利亚。根据欧盟在2016年的
，欧洲国家必须释放 700MHz频段，将其拍卖给电信运营商，并用于低频 5G。
简而言之，欧盟决定将 700MHz 频段拍卖给电信运营商，但该频段中仍然存在 DVB-T 信号。因此，推进 DVB-T2标准的想法愈发迫切。然而并不是所有电视都支持这一新格式，这意味著人们需要购买支持这一格式的机顶盒。这些机顶盒是由电视调谐器和输出设备组成的简陋设备，而有些最便宜的机型支持网络连接。
不仅仅是这些设备简陋，一些机顶盒还存在高度不安全的问题——这是我们今年一月发现的内容。这篇文章将揭示两款受欢迎的 DVB-T2设备如何被网络犯罪分子利用，注入恶意软件并成为大型机器人军队的一部分来对网络发起攻击。我们将展示它们在分发勒索病毒至用户电视时的易受攻击性，以及其他弱点，如
DNS 劫持和持久存储恶意软件负载。
除了揭示这些问题外，我们希望这一分析能促使物联网设备制造商对其技术和协议实施的方式负起责任。文章的后面，我们将披露这些失职的具体情况，随后分享对供应商的建议以及对其客户的安全提示。
但首先，我们来设定场景。
物联网实验室黑客马拉松
在 2019 年 12 月，我们为我们的 Avast 兄弟姐妹举办了第一届 Avast IoT LabHackathon。我们探索了无线黑客、面部识别、物联网实验室自动化，当然还有设备黑客。在设备黑客环节中，我们仔细研究了
Roomba（支持可修复性倡导者请看看模组化的 S9+ 设计）和 IP 摄像头，还花了一些时间在几款 DVB-T2 机顶盒上，最终决定对其进行更深入的调查。
同款盒子，品牌不同
本次调查的重点是两款支持 DVB-T2 的机顶盒。这些盒子价格极为便宜，受欢迎，外观相似，并且充满了漏洞。
找不同
认识一下 THOMSON THT741FTA（上方）和 Philips DTR3502BFTA（下方）。眼尖的你可以玩一下“找不同”的游戏。
首次用户体验印象
设置这款机顶盒相当简单：将盒子连接到电源，把 HDMI线接到电视上，再将网络线连接到我们的网络以捕获流量。不幸的是，我们无法像通常那样将同轴电缆连接到电视天线。原因很简单，我们没有一根。尽管我们的物联网实验室有超过
6 公里电缆，并拥有 10Gbps 的网络连接，但我们从未考虑过需要电视信号，这在我们的研究中却是必要的。我们甚至有一个法拉第笼（如果你坚持的话，可以称为
EM 环境屏蔽室），其唯一目的是让无线频谱「安静」并避免噪声干扰。
将一切连接好后，机顶盒启动并出现了初始设置画面，让我们选择语言、地区、画面比例等。第一个奇怪的地方就是区域设置。我们可以在欧洲、法国和意大利之间选择，这有点奇怪，因为法国和意大利都在欧洲。
之后进行了四分钟的扫描程序。设置完成后，前显示器骄傲地显示“NULL”而不是频道号码（记住，没有信号）。我们第一件尝试的事就是重启盒子，看是否会有所改变。
令我们惊讶的是，重启盒子后，进入了“选择语言”画面。每当我们强制重启、将盒子置于待机模式，甚至让其通宵运行（这会触发节能设置并使用户再次进行设置），就会明显感觉到一些问题。用户体验怎么会这么糟糕呢？到这时为止，普通用户与我们这些研究者唯一的区别就是我们没有将天线插入机顶盒。因此，我们决定首先解决这个问题。
物联网实验室升级
我们选择了一个全向电视天线，可以接收远达 80公里电视台的信号。我们的物联网实验室位于一楼，几乎没有窗户，因此无法将天线尽可能对准电视台。我们希望至少能接收到信号的反射。在调整了天线的位置后，我们将其放置在实验室窗户附近的支架上。
DVB-T2 天线
图中可见我们将天线安装在支架上，但却看不到清晰的 DVB-T2 发射器。这很遗憾，但我们再也无法做什么了。在初步设置过程中，我们成功接收到一些反射的
DVB-T2 信号。
进一步观察
NMAP
现在我们准备进一步观察。我们开始通过运行端口/服务扫描器 NMAP 来分析这款机顶盒。
NMAP扫描结果
我们对 TCP 端口 1 到 65535 进行了扫描。根据扫描结果，只有一个端口是开放的，即 Telnet 端口。Telnet 协议首次于 1969年推出，至今已有超过 50 年的历史。
深入机顶盒内
当我们尝试远程连接到机顶盒时，并没有提示登录。我们已经进入系统，且拥有 root 访问权限。
我们仔细查看了文件系统，发现了 ftpput 和 ftpget 两个工具，这两个工具允许在设备之间使用 FTP协议接收和传输文件。这意味著，无需使用 base64 转换，直接提取有趣的二进制档应该是相对直接的过程。
在机顶盒上执行 uname -a
我们获得对测试设备的访问后，首先执行的命令是 _uname -a ，_这为我们提供了机顶盒的架构和内核版本等信息。
我们了解这些盒子基于 MIPS 架构，这是与 ARMs 一样，最受欢迎的物联网设备架构之一。Linux 内核 3.10.23 于 2013 年发布，但根据
uname 输出中的其他信息，它在 2016 年被应用于这些设备。这一事实很重要，因为 Linux 内核 3.10.23 的维护在 2017 年 11月结束，这意味著这些盒子的支持仅持续了一年，此后将不再修复漏洞，使用户面临潜在攻击。
在我们习惯的检查顺序中，接下来的任务是查看运行进程和开放端口。
在机顶盒上执行 ps -w 和 netstat -tulnp
从这些命令中，我们可以看到主要应用程序（skyapp，稍后会介绍）、telnetd（即“telnet 守护进程”，允许访问机顶盒的 shell）和
udhcp（简单的 DHCP 客户端，恢复设备的 IP 地址），以及其他进程。这是一个非常简单的设备。
天气应用
机顶盒上的天气应用 UI
作为盒子“skyapp ”的一部分，天气应用允许用户指定地理位置以获取准确的天气预报。
通过分析我们的路由器与机顶盒之间的流量变化，我们确认该特定应用程序使用了 AccuWeather服务（以下域名证实了我们的怀疑，，看起来像是 Android 的旧版本
API）。我们认为它是一个遗留 API，因为机顶盒与 AccuWeather 后端通讯的过程中没有进行加密。
获取天气预报的 HTTP 环节需要两个步骤。 第一步通过城市名称获取 cityID 。在我们的情况下是布拉格，幸运的是，AccuWeather将布拉格，捷克作为第一个条目返回，否则我们将不得不在机顶盒的天气应用设置中调整。
URI = http://androidquickadver2.accu-weather.com/widget/androidquickadver2/city-find.asp?location=prague&langid=1&partner=
天气应用与 AccuWeather 伺服器之间的通信
查询布拉格城市的结果
第二步，使用第一步获得的 cityID ，获取带有实际天气预报的 XML。
URI = http://androidquickadver2.accu-weather.com/widget/androidquickadver2/weather-data.asp?location=cityId:125594&metric=1&langid=1&partner=
获取捷克布拉格的天气预报的网络流量
拥有这些信息后，我们能够使用两种方法之一来改变天气应用中显示的数据：直接对路由器进行 MiTM 攻击或简单的 DNS劫持。假设我们能在网络闸道或路由器上运行我们的代码，那么就能在 AccuWeather 与机顶盒之间的通信中动态改变数据，甚至使用比
VPNFilter（旨在感染 NAS 及路由器的物联网恶意软件，具备 SSL 除去和泛型 MiTM 攻击的能力）更基本的工具。
我们也可以执行 DNS 劫持，这样每当机顶盒请求 AccuWeather 伺服器的 IP 地址时，我们的 DNS 将回复提供由我们拥有和控制的恶意伺服器的
IP 地址。
还有第三种方法：改变机顶盒本身的 DNS 设置。稍后会详细介绍。
设置 MITM 攻击
RSS 源
RSS（丰富网站摘要）用于查看短文本格式的实时信息。这是这些机顶盒的第二项“智能”功能，与天气应用类似，也是 skyapp 的一部分。
RSS 流量
当我们仔细观察捕获的流量时，可以看到 HTTP/HTTPS 通信至新闻伺服器，并以 XML 格式将信息交付给盒子用户。
通过应用上述的 MITM技术，我们能够修改用户在电视上看到的内容（的视频格式）。因此，入侵者可以在用户的电视上显示勒索病毒信息，告诉他们其电视被劫持，并要求支付赎金以释放设备。
MITM 和非 MITM 攻击的 RSS 应用并排对比
好吧，我们能够操控 HTTP，虽然从技术角度来看，查看 HTTP 流量并不是什么特别的事情，但这仍然是一个警示，提醒供应商需更加努力地保护客户。
但 HTTPS 呢？我们应该无法干扰到 HTTPS 加密的 RSS 源，对吧？
使用自签 HTTPS 证书的 RSS 应用 MITM 攻击
错。通过为 DNS 记录创建自签名证书，我们找到了一种方法，本质上进行 DNS 劫持，这至少应该引发盒子供应商的一些警告。[显示其他 RSS阅读器正确行为的照片]
机顶盒上的 DNS 劫持
是否可以将 DNS 劫持攻击从路由器转移到设备上？当然可以。我们通过手动更改 resolv.conf 来设置自己的 DNS伺服器。这就是我们所需的一切。但是一旦当前的 DHCP 租约（临时将 IP 地址分配给网络设备的过程，在我们的情况下即路由器向机顶盒分配的 IP地址）到期，它将被更新时 DHCP 伺服器的值所覆盖。因此，为了不至于每 12-24 小时就登录一次并不断更改，我们添加了一个命令来终止 DHCP 客户端。
将自定义 DNS 设置注入到机顶盒中
持久存储
在设置本地 DNS 设置时，我们发现文件系统以 SquashFS挂载，这是一种通过压缩的只读文件系统，通常用于物联网设备。这让我们好奇，因为如果根文件系统是只读的，像 DNS解析器这样的资讯是如何存储的？（对于不熟悉的人，DNS 解析器是会将像 google.com 这样的域名转换为连接所用的 IP 地址的伺服器。）
然后我们看到根文件系统链接到 /config
目录，该目录中存储著几个其他文件，也可以添加更多文件，从而获得持久存储。这将允许攻击者在用户重置或重新启动设备后，在盒子上存储恶意软件负载或其他工具，而无需重新安装它们。而作为一个附加优势，当我们在
/config 中添加内容并进行工厂重置时，这些文件仍然存在。因此，即使用户执行了工厂重置，添加到此目录的文件也会保持不变。
我们然后能够重新挂载 /etc
以修改我们喜欢的内容。然而，这不会在设备重启后存活，并且需要在每次启动后重新挂载，但所有进行的更改和添加的数据将仍然存在。
机器人网络
如果“坏人”发现有设备运行 Telnet 且完全无安全性，他们首先会尝试什么？
他们可能会试图用物联网机器人网络感染该设备。幸运的是，对于“坏人”而言，固件中内置了一个 wget 工具，这允许从 HTTP伺服器检索数据，无论是网页还是包含恶意载荷的文件。因此，在 telnet 会话中下载二进制档相对容易。需要在此提及的是，在下面的示例中，我们将广泛使用的
Mirai 机器人网络的二进制文件下载到 /tmp 目录，因为默认情况下它是唯一可写的文件夹。
在机顶盒上执行 Mirai 载荷
Mirai 在机顶盒上运行良好，甚至关闭了 telnet daemon，而这也是我们最初可以访问的原因。这并不是机顶盒特有的行为，您可以在 Mirai源代码中的 例程中看到这一点。如果您对 Mirai的多个变种感兴趣，欢迎了解我们的研究人员分析的 。
在关闭 telnet 服务后，机顶盒开始扫描互联网，以寻找其他使用 telnet协议的目标，并且运行状态相当稳定。之所以提及此事，是因为在某些性能较低的设备上，使用多个 SYN封包进行的持续互联网扫描会导致设备抖动甚至重启，而如果二进制文件不在持久存储中，最终可能会导致感染消失。
在与 Mirai 机器人网络互动后，我们决定检测其他现代恶意软件在设备上是否能正常工作。我们选择了编译适用于 MIPS（小端）架构的
Corona，但最终因为输出信息“I ♥ IoT”而崩溃。这具有讽刺意味，不是吗？
在机顶盒上执行 Corona 载荷
影响
我们的用户中有数万个由
制造的设备（根据 MAC 地址），它是 STRONG 机顶盒的制造商，并且可能是 Philips 版本的制造商。
您可以在这里查看所有 Skyworth MAC 地址范围：https://hwaddress.com/company/skyworth-digital-
technologyshenzhen-coltd/
用户建议
除非绝对必要，否则不要使用机顶盒的网络功能。您或许更好地查看手机上的天气预报或新闻。当您将新设备连接到网络时，可以运行网络扫描器，如 Avast Wi-FiInspector，查看开放的端口。您还可以登录路由器界面，确认设置中是否启用了通用即插即用（UPnP）。如果启用，我们建议您禁用它。我们还建议检查您的端口转发配置，除非对您的需求绝对必要，否则应禁用它。
制造商建议
作为制造商，您不仅负责产品的安全（例如尖锐边缘、安全性能等），还负责其安全性，因此要对使用您产品的用户的安全负责。虽然我们理解每一版设计都会带来更多成本，但超越最低要求是很重要的。质疑产品中包含的服务是否为最新版本，以及用户是否能轻易进行更新
同样至关重要。例如，对于需要远程连接的产品，使用 SSH 比 Telnet 更好。在网络交互时应使用 HTTPS，并选择至少支持产品预期寿命的 Linux内核。
在设计和开发阶段后，考虑如何减少潜在威胁面
也很重要。质疑您是否真的需要特定的服务或应用程序。如果需要保留某些功能，那么请考虑为客户提供禁用非必要服务、更改凭证或在设备上设置防火墙的选项。别忘了，您的设备并非旨在公开面向互联网，但这并不意味著它不会向外暴露。在这种不太可能的情况下，攻击者可以趁虚而入，进入局域网中。
总的来说，尽可能使用 HTTPS 而不是 HTTP。在此特定案例中，除非完美实施，否则这并不会有所帮助。对于更高级的用户，我们建议强制所有 DNS请求指向预验证的 DNS伺服器。只有在一些非常罕见的情况下，这才会导致连接问题，但稍加调整应该会有帮助。如果您确实遇到问题，这些建议是针对高阶用户的，并非因为它们难以配置，而是因为这需要一些了解这些设置可能引起的后果的知识。
CVE
CVE-2020-11617
THOMSON THT741FTA 2.2.1 和 Philips DTR3502BFTA DVB-T2 2.2.1 机顶盒的 RSS 应用程序无法验证
RSS 伺服器的 SSL 证书，这使得中间人攻击者可以修改传送到客户端的数据。
CVE-2020-11618
THOMSON THT741FTA 2.2.1 和 Philips DTR3502BFTA DVB-T2 2.2.1 机顶盒的 telnet服务在启动时固化启动，这使得攻击者能够通过 telnet 协议获得 root 访问权限。
与 OEM 的沟通
在研究了这些有趣的设备并得出对于这类盒子的普通消费者来说，其实根本不需要 telnet服务的结论后，我们决定联系机顶盒的生产商，披露我们的发现并建议完全禁用 telnet 应用程序。
首先，我们联系了 Philips，他们有专门的电子邮件，用于与产品安全相关的沟通。几天后，我们收到了回复，表示 Philips现在对新一代机顶盒使用外包商，并且该公司承认我们提到的问题，但无法修复。我们认为他们不太可能检查这些盒子的 SDK。不过，Philips看起来不太会给这些机顶盒提供长期使用。
我们还联系了 Thomson/STRONG，这里的情况则更加有趣。不仅没有明显的方式获得 STRONG 的支持，连其页面上都缺少联络信息。
唯一的联络方式是通过该网站，这似乎会将请求转发给预定国家的本地销售团队。因此，我们将描述发现的问题和联系信息的电子邮件发送到所有可以用的国家。我们仍在等待回复。
结论
尽管我们具备技术能力，但对这些机顶盒的调查并不容易。这无疑是我们最近所做的更为引人入胜的分析之一。我们进行了安全研究，但还进一步扩展了研究范围，考虑用户体验和产品方面。
这不是一个关于某个 Linux发行版存在关键漏洞且已在全球广泛部署超过一百万次的传播故事。它是一个简单的故事，讲述了当新型便宜、性能不足和设计不良的技术取代旧技术时，安全漏洞如何产生。
令人遗憾的是，公司仍在推进产品上市，并不打算释出固件更新，且普通客户无法加固自己的盒子，而这在该案例中只是简单地禁用 Telnet 并将
RSS/天气应用程序升级为使用 TLS。这种疏忽影响到那些既无法负担新电视，也不觉得需要更换一台还在正常运行的电视的客户。
不久后，我们将发布有关机顶盒故事的第二部分。如果您有任何问题，请随时与我们联系
或 @
!
时间轴
时间轴
给研究人员的二进制哈希
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
标签为 ，
，
，
，
分享:XFacebook
