世界第三大电视制造商TCL Android电视中发现高危漏洞

世界第三大电视制造商TCL Android电视中发现高危漏洞

以下是对运行Android的智能电视进行为期三个月的调查的结果。经历了这段研究经历后,我可以衷心地说,有很多时刻,我和我在此期间遇到的另一位安全研究员,都不敢相信发生了什么。我曾多次感到自己好像在说:“你甚至都无法弥补……”

我是一名安全研究员,一名自由开发人员/一名黑客。

请在Twitter @sickcodes上关注我

这个故事中的第二位研究员是约翰·杰克逊(John Jackson):twitter.com/johnjhacking,是Shutterstock的应用程序安全工程师/一名黑客。

初步研究

9月底,在对低端Android机顶盒进行研究时,我遇到了这些设备设计方式中的许多严重缺陷。

无需深入研究每个设备的细微差别,所有智能电视产品都基于Android。

电视市场中有四种类型的电视产品:

  1. 电视棒
  2. 电视盒
  3. 智能电视
  4. 安卓电视

它们都是基于ARM的单板计算机(SBC)。多数芯片是32位的,有些是64位的,但是它们都像Raspberry Pi的竞争对手一样,通过小型但功能强大的Mali GPU专注于GPU性能。

我调查的某些产品“存在工厂缺陷”,并且故意不安全。

第一滴血

2020-09-20,我在电视棒中发现了一些荒谬的安全漏洞。

注意:TCL不会使电视棒容易受到攻击。仅TCL Android电视受到影响。以下漏洞是指我在寻找TCL漏洞之前正在测试的其他产品,在下面的nmap解析之后将进行深入讨论。

我测试的每个记忆棒都至少具有以下主要安全缺陷之一。

①端口22已打开,并允许以root用户身份进行SSH访问:root
②打开端口5555,并允许未经身份验证的android(adb)作为root用户:开箱即用的root用户
③根目录设备,在多个位置具有世界可执行的二进制文件
④运行adb和ssh守护进程的开放WiFi网络

实际上,如果您有一千个这样的设备,则可以利用双WiFi,纯文本WAN路由器凭据以及从电视棒跳到路由器MITM的能力,遍历所有设备。路由器,从更大,功能更强大的路由器中搜索更易受攻击的设备,并真正实现“网上冲浪”。

概念验证

#无需任何密码即可连接到设备的开放WiFi网络
adb connect 192.168.1.1 
adb shell 
su 
whoami 
#root

亲眼目睹了这些设备的安全性有多糟糕,或者缺乏这些安全性之后,我的计划是写出一个非常大的概念证明,以一种实际的基于shell的蠕虫形式出现,可以在我拥有的4到5个电视棒之间进行切换。

在与一位同事讨论我的想法时,我们最终聊起了真正的Android电视。

突然,我想:“如果这些控制棒是相同的,只有很少的Rockchip和Amlogic CPU,那么智能电视有什么特别之处?”

由于我实际上没有要测试的Android电视,所以我问我的朋友他拥有哪种类型的智能电视,它正在运行Android吗?

他的回答是:“ TCL,不确定。”

我对TCL的了解还很少,但事实证明TCL是一家庞大的中国电子制造公司。

TCL一直在以惊人的速度增长其全球市场份额。

根据《福布斯》的一篇文章,它们仅在2013年在美国推出,并且在亚马逊上开始销售:www.forbes.com/15fd0d52f096

从2008年到2020年电视市场份额

随着他们在亚马逊的成功,TCL开始瞄准其他大型市场。

这里的关键是他们不是三星或LG,但他们正在销售数百万台电视机……

我们进行了一次远程桌面会话,然后在电视上进行了一次简单的nmap扫描,以查看开箱即用的内容。

这是nmap扫描:

Starting Nmap 7.91 ( https://nmap.org ) at 2020-10-16 21:55 UTC
…
Scanning 10.0.0.117 [65535 ports]
Discovered open port 6550/tcp on 10.0.0.117
Discovered open port 8012/tcp on 10.0.0.117
Discovered open port 6466/tcp on 10.0.0.117
Discovered open port 8009/tcp on 10.0.0.117
Discovered open port 9000/tcp on 10.0.0.117
Discovered open port 8443/tcp on 10.0.0.117
Discovered open port 10101/tcp on 10.0.0.117
Discovered open port 46211/tcp on 10.0.0.117
Discovered open port 7989/tcp on 10.0.0.117
Discovered open port 6467/tcp on 10.0.0.117
Discovered open port 6559/tcp on 10.0.0.117
Discovered open port 6553/tcp on 10.0.0.117
Discovered open port 4332/tcp on 10.0.0.117
Discovered open port 8008/tcp on 10.0.0.117
Completed SYN Stealth Scan at 21:56, 20.40s elapsed (65535 total ports)
Initiating Service scan at 21:56
Scanning 14 services on 10.0.0.117
…
Completed Service scan at 21:58, 156.41s elapsed (14 services on 1 host)
Not shown: 65521 closed ports

如果你在你的Android手机使用nmap,你通常会发现0个开放的TCP端口。

那么,电视为什么需要这么多开放端口?

尽管有一些理由使电视具有开放端口,但上述某些服务值得深入研究。

由于我处于远程桌面会话中,因此我只是将所有URL手动输入到他的Web浏览器中。

http://10.0.0.117:6550
http://10.0.0.117:8012
http://10.0.0.117:6466
http://10.0.0.117:8009
http://10.0.0.117:9000
http://10.0.0.117:8443
http://10.0.0.117:10101
http://10.0.0.117:46211
http://10.0.0.117:7989
http://10.0.0.117:6467
http://10.0.0.117:6559
http://10.0.0.117:6553
http://10.0.0.117:4332
http://10.0.0.117:8008

我还测试了https://版本:

https://10.0.0.117:6550
https://10.0.0.117:8012
https://10.0.0.117:6466
https://10.0.0.117:8009
https://10.0.0.117:9000
https://10.0.0.117:8443
https://10.0.0.117:10101
https://10.0.0.117:46211
https://10.0.0.117:7989
https://10.0.0.117:6467
https://10.0.0.117:6559
https://10.0.0.117:6553
https://10.0.0.117:4332
https://10.0.0.117:8008

有些页面是空白的白页。这可以指示API端点。

有些页面只是挂在浏览器上。

然后其余的nmap扫描通过了……

PORT STATE SERVICE VERSION
4332/tcp open getty-focus?
6466/tcp open ssl/unknown
| ssl-cert: Subject: commonName=atvremote/BeyondTV2/BeyondTV/BeyondTV2/unknown
| Subject Alternative Name: email:[email protected]
| Issuer: commonName=atvremote/BeyondTV2/BeyondTV/BeyondTV2/unknown
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
…
6467/tcp open tcpwrapped
6550/tcp open fg-sysupdate?
| fingerprint-strings:
| NULL:
|_ Version 4
6553/tcp open unknown
6559/tcp open unknown
| fingerprint-strings:
| GenericLines:
…
7989/tcp open unknown
| fingerprint-strings:
| FourOhFourRequest:
| HTTP/1.1 404 Not Found
| Content-Type: text/plain
| Date: Fri, 16 Oct 2020 10:57:17 GMT
| Accept-Ranges: bytes
| Connection: keep-alive
| Content-Length: 26
| Error 404, file not found.
| GenericLines:
| HTTP/1.1 400 Bad Request
| Content-Type: text/plain
| Date: Fri, 16 Oct 2020 10:56:27 GMT
| Connection: keep-alive
| Content-Length: 56
| REQUEST: Syntax error. Usage: GET /example/file.html
| SIPOptions:
| HTTP/1.1 404 Not Found
| Content-Type: text/plain
| Date: Fri, 16 Oct 2020 10:57:37 GMT
| Accept-Ranges: bytes
| Connection: keep-alive
| Content-Length: 26
|_ Error 404, file not found.
8008/tcp open http?
|_http-title: Site doesn\'t have a title (text/html).
8009/tcp open ssl/castv2 Ninja Sphere Chromecast driver
|_ajp-methods: Failed to get a valid response for the OPTION request
8012/tcp open unknown
8443/tcp open ssl/https-alt\?
|_http-title: Site doesn\'t have a title (text/html).
| ssl-cert: Subject: commonName=/organizationName=Google Inc/stateOrProvinceName=Washington/countryName=US
| Issuer: commonName=TCL TV BeyondTV Realtek RTD2851 Cast ICA/organizationName=Google Inc/stateOrProvinceName=Washington/countryName=US
9000/tcp open ssl/cslistener?
10101/tcp open ssl/ezmeeting-2?
46211/tcp open tcpwrapped

端口7989显示404错误,但是当我在浏览器中访问10.0.0.117:7989时,显示了错误。

http://10.0.0.117:7989 没有在浏览器中返回页面。

TCL目录文件结构

哪种特殊的Web服务器不显示索引页面,而是显示更深的页面?

我最近对/目录中提供CGI脚本的IoT设备进行了研究,因此我认为要测试的第一页是init.rc。

http://10.0.0.117:7989/init.rc

403禁止。

kes

这意味着该文件存在,但我们无权查看该文件。

自然,我测试了其他一些Android目录:

http://10.0.0.117:7989/sdcard

TCL目录文件结构漏洞

如果您使用计算机,则无论是移动应用程序,Web应用程序,网站,后端,前端,高端……

现在问自己这个问题:

“在您的职业生涯中……
您是否曾经需要通过HTTP服务列出整个文件系统?”

这成为一个真正的重要问题,因为此定制供应商固件当前已安装在全球数百万台TCL Android电视中。

我的朋友在我们做远程桌面时实际上正在打电话给我,我对此感到非常惊讶。

“为什么我们可以在电视上看到所有文件?”

Internet号码分配机构(IANA)https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers所指定的端口7989端口不在标准TCP /UDP端口列表中。

这意味着,如果不扫描所有65,535个端口,大多数扫描仪将跳过该端口。

其次,实际的根页面为空白。

因此,为了每个端口扫描多于一页,端口扫描时间将成倍增加……

奇怪的是,我检查了IANA列表中是否有其他以989结尾的端口:

ftps-data989tcpftp protocol, data, over TLS/SSL
tr-rsrb-p31989tcpcisco
mshnet1989tcpMHSnet
zarkov2989tcpZARKOV
bv-queryengine3989tcpBindView-Query
parallel4989tcpParallel
wbem-https5989tcpWBEM
sunwebadmins8989tcpSun
 9989-9989 Unassigned
 10934-10989 Unassigned

值得注意的是,缺少6989和7989。

实际上,IANA未分配范围7983-7997。

为什么Android设备需要在非标准端口上运行的Web服务器?

什么样的厂商发布设备的整个文件系统?

联系人跟踪– CVE-2020-27403

此时,我起草了第一个CVE请求并将其发送给MITRE。

建议草案的副本已发送至TCL的[email protected]电子邮件地址,要求他们确认已收到报告。

电子邮件被退回,因此我通过他们的网站提交了联系表,要求立即向安全部门提供支持并升级。

因为这是一个星期五,所以我不希望得到答复,但是几天过去了,MITRE也没有答复。

我再次检查了该设备是否不受另一个证书编号颁发机构(CNA)的保护,令我惊讶的是,TCL公司拥有Alcatel。

实际上,他们还拥有Blackberry Mobile。

这两个品牌都是开放手机联盟成员,并且受Google Android CNA的保护。

因此,我将该报告重新提交给了Android CNA。

又过了几天,还没有任何人回复。

然后,我联系了一位与研究人员取得联系的朋友,该研究人员与公司的某位联系人进行了联系。我给他们发了电子邮件。

再一次,没有回复。

然后,我在此帖子中公开要求TCL安全团队中任何人的详细联系信息:https://community.disclose.io/t/look-for-security-contact-at-tcl-corporation/39

另一位名为约翰·杰克逊(John Jackson)的研究员回答,我们在Twitter上建立了联系。

约翰最近与一家公司进行了混乱的公开披露,该公司扬言要起诉他,即使他们已经书面表示“该错误不存在”。

这就是事情变得艰难的地方。

寻求协助

约翰:我在浏览recovery.io时,看到Sick Codes的帖子要求提供有关他在TCL的Smart TV上发现的一个重大漏洞的披露的帮助。

看到他试图通过他们的电话支持,联系表,推特和电子邮件地址与该公司联系–很明显,他没有得到任何回应。

首先,我在董事会上进行了回复,并在Twitter上与他联系以验证漏洞的真实性。

这似乎是一个合理的问题,智能电视暴露了一个随机端口,我可以在客户端看到一堆文件。使用病码,我对文件系统进行了更深入的研究,并指出可以访问许多敏感文件。

但是,并非所有敏感文件都可以访问,并且存在某些权限限制,例如访问敏感配置文件。

事实证明,电视上存在一个内置目录,并保留了root级别权限。该目录几乎是公开文件系统的相同克隆,并允许我们规避任何访问各种关键文件的问题

显然,利用此漏洞可能会导致远程执行代码,甚至导致网络快速枢纽化,目的是利用勒索软件快速利用系统。

从客户端的公开文件系统中列举了大量受影响的电视型号,[或者换句话说,数百万台易受伤害的电视],我着手在公开过程中帮助Sick Codes。

不幸的是,我试图披露的结果几乎与病码相同,导致在社交媒体或电子邮件上没有任何回应

我打电话给TCL,并与支持代表进行了交谈。我敦促她说我们手上有一个严重的漏洞,她说她没有与安全团队联系的信息,甚至不知道TCL是否有安全团队。她问我是否要通过电话披露该漏洞,以便将其提交到票务系统:我说不。通过共享票务系统公开高度敏感的漏洞通常不是最佳实践。

显然,我们不得不采用其他方法,所以我联系了CERT,要求提供披露方面的帮助。CERT最初并未回复我们。

几天后,病码成功获得了TCL的名称和联系方式。我们伸出手,大约一周后,该公司承认该漏洞,并表示他们将修补此问题。我们要求在数周内进行更新,但他们停止回复我们。CERT最终做出了回应,并告诉我们如果是这种情况,请披露该漏洞。

尊敬的约翰·杰克逊

第2部分:后门更新漏洞– CVE-2020-28055

病码再次在这里。TCL公司花了13天时间回复了我们的初次报告。

确认来自世界第三大电视制造商的安全报告将近2周。

其次,但是TCL安全团队实际上在同一封电子邮件中确认他们已修复该漏洞。

在这一点上必须提出严肃的问题。为什么要花两周的时间来答复,而且修复起来又这么容易?

修复程序中停止了哪些Android服务?

如果没有这个允许目录过多的目录,允许同一网络上的任何人都可以在电视上下载文件,电视是否可以按预期运行?

正是在这个时候,我决定在安全团队关注的同时尝试发现更多漏洞。

我浏览了.rc文件,以查找特定于供应商的更改。

确实,TCL对电视文件系统上的几个文件夹进行了重要更改,这些更改应绝对锁定。

在文件中:

/system/vendor/etc/init/hw/init.rtd285o.rc

我发现了以下严重错误:

#tcl save data directory
mkdir /data/vendor/tcl 0777
#tcl oad data directory
mkdir /data/vendor/upgrade 0777
mkdir /var/TerminalManager 0777

这意味着文件系统上的所有用户现在都可以写入这些文件夹。

/data/vendor/tcl 包含用于操作电视的关键文件。

这些文件不得由任意用户或潜在的恶意应用或APK写入。

只能猜测拥有对TCL更新文件夹的读写访问权可能带来的后果……

其次,我在“ TerminalManager_Remote”中发现了一些小小的想法:

TerminalManager是一个名为TerminalManager_Remote.apk的应用程序

解压缩APK包含以下配置文件。

[cwmp]
enable=1;
soap_env=SOAP-ENV
soap_enc=SOAP-ENC
acs_auth=1
cpe_auth=0
event_filename=/etc/cwmpevent.bin
###CN official url
acs_url=http://admin.acs.huan.tv/acs
logserver_url=http://service.acs.huan.tv/acs/uploadLog
fileserver_url=http://admin.acs.huan.tv/file/uploadFile
screenserver_url=http://admin.acs.huan.tv/file/uploadScreen
longconnect_url=http://socket.acs.huan.tv
logserver_url_stat=http://service.acs.huan.tv/acs/uploadLogs
###HK area official url
HK_acs_url=http://as.admin.acs.huan.tv/acs
HK_logserver_url=http://as.service.acs.huan.tv/acs/uploadLog
HK_fileserver_url=http://as.admin.acs.huan.tv/file/uploadFile
HK_screenserver_url=http://as.admin.acs.huan.tv/file/uploadScreen
HK_longconnect_url=http://as.socket.acs.huan.tv
HK_logserver_url_stat=http://as.service.acs.huan.tv/acs/uploadLogs
###TW area official url
TW_acs_url=http://as.admin.acs.huan.tv/acs
TW_logserver_url=http://as.service.acs.huan.tv/acs/uploadLog
TW_fileserver_url=http://as.admin.acs.huan.tv/file/uploadFile
TW_screenserver_url=http://as.admin.acs.huan.tv/file/uploadScreen
TW_longconnect_url=http://as.socket.acs.huan.tv
TW_logserver_url_stat=http://as.service.acs.huan.tv/acs/uploadLogs
###AP area official url
AP_acs_url=http://as.admin.acs.huan.tv/acs
AP_logserver_url=http://as.service.acs.huan.tv/acs/uploadLog
AP_fileserver_url=http://as.admin.acs.huan.tv/file/uploadFile
AP_screenserver_url=http://as.admin.acs.huan.tv/file/uploadScreen
AP_longconnect_url=http://as.socket.acs.huan.tv
AP_logserver_url_stat=http://as.service.acs.huan.tv/acs/uploadLogs
###AU area official url
AU_acs_url=http://as.admin.acs.huan.tv/acs
AU_logserver_url=http://as.service.acs.huan.tv/acs/uploadLog
AU_fileserver_url=http://as.admin.acs.huan.tv/file/uploadFile
AU_screenserver_url=http://as.admin.acs.huan.tv/file/uploadScreen
AU_longconnect_url=http://as.socket.acs.huan.tv
AU_logserver_url_stat=http://as.service.acs.huan.tv/acs/uploadLogs
###ME area official url
ME_acs_url=http://eu.admin.acs.huan.tv/acs
ME_logserver_url=http://eu.service.acs.huan.tv/acs/uploadLog
ME_fileserver_url=http://eu.admin.acs.huan.tv/file/uploadFile
ME_screenserver_url=http://eu.admin.acs.huan.tv/file/uploadScreen
ME_longconnect_url=http://eu.socket.acs.huan.tv
ME_logserver_url_stat=http://eu.service.acs.huan.tv/acs/uploadLogs
###EU area official url
EU_acs_url=http://eu.admin.acs.huan.tv/acs
EU_logserver_url=http://eu.service.acs.huan.tv/acs/uploadLog
EU_fileserver_url=http://eu.admin.acs.huan.tv/file/uploadFile
EU_screenserver_url=http://eu.admin.acs.huan.tv/file/uploadScreen
EU_longconnect_url=http://eu.socket.acs.huan.tv
EU_logserver_url_stat=http://eu.service.acs.huan.tv/acs/uploadLogs
###AF area official url
AF_acs_url=http://eu.admin.acs.huan.tv/acs
AF_logserver_url=http://eu.service.acs.huan.tv/acs/uploadLog
AF_fileserver_url=http://eu.admin.acs.huan.tv/file/uploadFile
AF_screenserver_url=http://eu.admin.acs.huan.tv/file/uploadScreen
AF_longconnect_url=http://eu.socket.acs.huan.tv
AF_logserver_url_stat=http://eu.service.acs.huan.tv/acs/uploadLogs
###NA area official url
NA_acs_url=http://na.admin.acs.huan.tv/acs
NA_logserver_url=http://na.service.acs.huan.tv/acs/uploadLog
NA_fileserver_url=http://na.admin.acs.huan.tv/file/uploadFile
NA_screenserver_url=http://na.admin.acs.huan.tv/file/uploadScreen
NA_longconnect_url=http://na.socket.acs.huan.tv
NA_logserver_url_stat=http://na.service.acs.huan.tv/acs/uploadLogs
###LA area official url
LA_acs_url=http://na.admin.acs.huan.tv/acs
LA_logserver_url=http://na.service.acs.huan.tv/acs/uploadLog
LA_fileserver_url=http://na.admin.acs.huan.tv/file/uploadFile
LA_screenserver_url=http://na.admin.acs.huan.tv/file/uploadScreen
LA_longconnect_url=http://na.socket.acs.huan.tv
LA_logserver_url_stat=http://na.service.acs.huan.tv/acs/uploadLogs
###test url
test_acs_url=http://103.235.237.119:8080/acs_manager/acs
test_longconnect_url=http://103.235.237.119:6488
test_logserver_url=http://103.235.237.119:8080/acs_web/acs/uploadLog
test_fileserver_url=http://103.235.237.119:8080/acs_manager/file/uploadFile
test_screenserver_url=http://103.235.237.119:8080/acs_manager/file/uploadScreen
test_logserver_url_stat=http://103.235.237.119:8080/acs_web/acs/uploadLogs
ca_file=/etc/ca.pem
ca_password=123456
cpe_manufacture=ChinaNMS
cpe_oui=A00001
cpe_sn=30000000000000000
cpe_name=000000
cpe_pc=OT2800
cpe_specver=V1.0
cpe_hwver=V1.0
cpe_version=V1.2.7.29
cpe_username=cwmp
cpe_password=cwmp
acs_username=app1
acs_password=123456
[cwmpd]
httpd_port=5400
http_timeout=-1

这个APK里面是netcwmp。其中包括以下管理控件:

https://github.com/netcwmp/netcwmp.git

SOAP/XML Parser
SSL
HTTP Server
HTTP Client
Ini config file Parser
Digest Authentication
GetRPCMethods
Inform
SetParameterValues
GetParameterValues
GetParameterNames
Download
Upload
AddObject
DeleteObject
FactoryReset
TransferComplete
Reboot
TR-069 Object Models Interface
Config File:
acs_auth: ACS auth CPE
cpe_auth: CPE auth ACS
acs_url: ACS URL
cpe_manufacture: Manufacture
cpe_oui: OUI
cpe_sn: CPE Serial Number
cpe_name: CPE Name
cpe_pc: CPE Product Class
cpe_username: InternetGatewayDevice.ManagementServer.ConnectionRequestUsername
cpe_password: InternetGatewayDevice.ManagementServer.ConnectionRequestPassword
acs_username: InternetGatewayDevice.ManagementServer.Username
acs_password: InternetGatewayDevice.ManagementServer.Password
httpd_port: Http server listen port
ca_file: ca pem file
ca_password: ca password

我想在这里回答这个大问题,但我不知道是否可以。

我没有答案。但是,TCL可以。

我进行初步测试的电视被无声打了补丁。没有发送更新警告。

他们能够识别漏洞,并在没有用户输入的情况下自动将漏洞打补丁,这一事实也令人震惊。

请根据我们的研究得出您自己的结论。

如果您想要更多的研究文章和调查,那么请把我们两个都保留在Twitter上。

在Twitter上关注我@SickCodes

在Twitter上关注@johnjhacking

确认电子邮件发出后不久,MITRE为我们发现了两个漏洞,向我们颁发了两个CVE ID:

CVE-2020-27403

TCL Android智能电视(全部)–通过目录列表显示信息–通过端口7989上的相邻网络,未经身份验证的攻击者可以浏览TCL Android TV文件系统

CVE-2020-28055

TCL Android智能电视(全部)–关键供应商资源的权限分配不正确– TCL Android TV供应商配置和升级文件夹可写给本地攻击者的世界

一些评论

from

Leave a Reply

您的电子邮箱地址不会被公开。 必填项已用*标注