360安全大脑监测到Nozomi实验室披露一个严重漏洞

日前，360安全大脑检测到Nozomi Lab披露的ThroughTek P2P软件开发套件（SDK）中存在严重漏洞（CVE-2021-32934），CVSSv3评分为9.1。 P2PSDK 用于支持通过互联网远程访问音频/视频流，目前被多家安全摄像头和智能设备制造商使用，并且是许多消费类安全摄像头和物联网设备原始设备制造商 (OEM) 供应链的一部分。

随后ThroughTek给出了受该漏洞影响的SDK版本、实现方式以及补丁建议。 同时，Nozomi Labs表示：由于ThroughTek的P2P库多年来已被多个供应商集成到许多不同的设备中，因此第三方几乎不可能跟踪受影响的产品。

迄今为止，还没有团队提供详细的分析报告，说明供应链漏洞影响了哪些制造商和设备模型。 导致许多可能受该漏洞影响的厂商仍然完全未知，大量在线设备仍然面临潜在风险无人知晓。 因此，360未来安全研究院/工业互联网安全团队通过FirmwareTotal供应链安全分析平台独家提供软件供应链安全风暴分析报告，以提高业界对此次漏洞风暴的关注度和风险意识。

背景

网络摄像机的相关概念

有必要澄清漏洞场景中出现的以下概念术语：

典型NVR架构

典型网络摄像机的结构如右图所示：

在这些工作模式下，用户与其NVR设备之间有LAN、P2P、Relay等多种连接形式。 对于P2P连接来说，是指允许客户端通过Internet透明地访问音频/视频流的连接功能。 隧道技术中经常采用P2P，根据提供商的具体实现，相应的隧道建设方案也有所不同。

同时，在建立P2P连接之前，需要网段上的服务器提供认证和连接服务。 该服务器通常由设备制造商或上游提供商提供（在本例中，它由 ThroughTek 提供，用于使用 IOTC 库的设备与客户端之间的连接），并充当想要访问音频/视频流的客户端和提供数据的设备之间的中间人。

IOTC（Internet of Things Cloud）平台是Throughtek（TUTK）开发的基于云的物联网解决方案。 它采用P2P连接技术和云计算，加上跨平台的API，使得不同的互联网设备之间可以建立跨平台的连接。 使用TUTK提供的SDK开发的IP摄像机客户端和服务器将嵌入IOTC库中，以与TUTK服务器通信并改善P2P连接。

因为 ThroughTek 软件组件被安全摄像头和智能设备供应商广泛使用检测网站漏洞软件，并且现已集成到数百万台联网设备中。 作为多家消费级安全摄像头和物联网设备 OEM 供应链的一部分，此次漏洞影响了 IP 摄像头、儿童和宠物监控摄像头，以及从机器人到电池组等设备。

漏洞分析

根据nozomi披露的信息，该漏洞是由于在客户端和设备端库中使用了硬编码的解密算法和密钥，因此第三方可以通过中间人或离线方法重建音频/视频流。

通过分析，我们发现有问题的组件可能以动态链接库文件（IOTCAPIs.dll、libIOTCAPIs.so）的形式打包到设备端固件或客户端程序（exe、apk）中，或者静态链接到厂商特定的二补程序中，如goahead、tutk_tran、TutkTunnel等，这体现了供应链安全问题的隐蔽性和复杂性。

IOTC库设备与客户端交互逻辑分析

为了还原漏洞场景，首先我们需要一组设备固件，其中包括IOTC平台和与之交互的客户端。

无论是固件还是客户端，都会包含IOTC的版本信息。 所以我们使用IOTC_Get_Version函数作为搜索依据，在FirmwareTotal中搜索对应的固件：

得到相关性分析结果：

在筛选出与包含IOTC_Get_Version字符串的单个文件相关的固件后，我们选择了某个相机固件作为分析对象。

同时，根据产品型号搜索检测网站漏洞软件，链接到该摄像头的Windows版客户端（md5sum:99906589990658dd878787aa787878dd041860418604186bb869869bb2020aa3838be）。 可以发现Windows客户端中IOTC相关的功能都是在IOTCAPIs.dll库中实现的。

同时使用FirmwareTotal下载相机固件的文件系统，从中可以提取固件侧的IOTC库文件libIOTCAPIs.so。

样本准备好后，我们就可以开始分析任务。 经过客户端的简单反编译和分析，定位到登录设备的函数LoginDevice后，可以初步确认登录设备所使用的设备被标记为设备ID。 继续单步进入VideoPlayerTutk_LoginDev函数：

[Dllimport("imivideoplayertutk.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern int VideoPlayerTutk_LoginDev(string deviceId, string viewAccount, string viewPassword, out int pIMIhandle, int resvInfo = 0);

可以发现需要提供的参数项包括：

继续跟踪执行流程可以在客户端恢复如下执行流程信息：

以上是初步的逆向分析和定位。 同时，根据搜索到的IOTC文档和源代码[3-5]，我们可以进一步还原出更准确的设备与客户端之间的连接过程。 整体流程如右图所示：

设备已注册到P2P服务器

客户端向P2P服务器请求P2P连接服务

P2P服务器为客户端提供隧道完善的服务

P2P服务器为设备提供隧道完善的服务

然后设备直接连接客户端，不涉及P2P服务器

P2P连接建立成功后，设备和客户端就可以开始传输数据了。 具体通讯形式如下：

首先是设备端的流程图：

第二个是客户端的流程图：

交通“揭晓”

由于客户端和设备端通过UDP合约传输数据，数据只是简单混淆，因此很容易通过中介泄露设备端传输的敏感信息，如摄像头图像、用户凭证等。“解密”脚本如下：

import struct
# code by owl
# test on TUTK version: 1.11

def ROL4(value, cnt):
    """
    rotate left (4-Byte wise)
    """
    return ((value << cnt)&0xffffffff) | (value >> (32-cnt))

def Swap(raw, size):
    maps = { 2: [1, 0], 4: [2,3,0,1], 8: [7,4,3,2,1,6,5,0], 16: [11,9,8,15,13,10,12,14,2,1,5,0,6,4,7,3]}
    result = raw
    if size in maps.keys():
        result = ''.join([raw[maps[size][i]] for i in range(size)])
    return result

def ReverseTransCodePartial(raw):
    key = "Charlie is the designer of P2P!!"
    result=''
    len1 = len(raw)/16
    len2 = len(raw)
    for s in range(len1):
        tmp1 = raw[s*16: s*16+16]
        tmp2 = ''
        tmp3 = ''
        for r in range(0,16,4):
            tmp2 += struct.pack("        
        tmp2 = Swap(tmp2, 16)
        
        for r in range(16):
            tmp3 += chr(ord(tmp2[r])^ord(key[r]))

        for r in range(0,16,4):
            result += struct.pack("            
    if len2 >0:
        tmp1 = Swap(raw[len1*16:], len2)
        for r in range(len2):
            result += chr(ord(tmp1[r])^ord(key[r]))
    return result

raw_packet = "4e0a8dec40d040ca2d2d882dc0e7cad82b5ade2b19b4a3f87e7c4c8825b2e9fc206c335059656972".decode('hex')
dec_packet = "04021a0218000000060242000000000041384756465231425a3645594e4736333131314100000000".decode('hex')

res = ReverseTransCodePartial(raw_packet)
print(res.encode('hex'))
if res == dec_packet:
    print("success")

从 libIOTCAPIs.so 版本 1.7.0.0 开始，“更安全”的 IOTC_Listen2() 和 IOTC_Connect_ByUID2() 已经实现。 而且，libP2PTunnelAPIs.so使用旧版本的套接字IOTC_Listen()和IOTC_Connect_ByUID()来构建P2P连接意味着完美的P2P连接仍然没有得到保护。 “解密”功能的实现在后续版本中略有调整，但差异并不大，这里不再赘述。

虽然该漏洞出现在TUTK的P2P组件中，但事实上，无论采用何种方式（P2P/LAN/RELAY），只要使用该组件进行设备连接，都存在音视频被截获的风险。

AES 被滥用

通过分析libIOTCAPIs.so的加密通信套接字，我们发现仍然存在误用AES加密算法的情况。

根据文档，IOTC_Listen2()套接字的参数cszAESKey代表加密密钥

int IOTC_Listen2(unsigned int nTimeout, const char *cszAESKey, IOTCSessionMode 	nSessionMode);

int IOTC_Listen2(unsigned int nTimeout, const char *cszAESKey, IOTCSessionMode 	nSessionMode);

当设备调用该socket开始窃听时，将cszAESKey保存到会话的PrivateKey数组中

但调用AES进行add/uncover时，PrivateKey数组作为初始向量IV，真实的Ek/Dk均为空

其中，AesCtx结构体定义如下：

// AES context structure
typedef struct {
 unsigned int Ek[60];
 unsigned int Dk[60];
 unsigned int Iv[4];
 unsigned char Nr;
 unsigned char Mode;
} AesCtx;

在 libIOTCAPIs.so 版本 3.1.10.7 中，我们还听到了采用硬编码密钥的 ECB 数据包模式下的 AES 实现

影响范围评估
版本标识
根据TUTK的声明，所有高于3.1.10的SDK版本都会受到影响。 通过提取库文件libIOTCAPIs.so或IOTCAPIs.dll中IOTC_Get_Version()函数的硬编码值，可以识别设备或客户端使用的SDK版本。
以某相机客户端为例，从低位到高位逐字节读取IOTC_Get_Version()函数的返回值，得到结果，版本为2.1.8.4。
_DWORD *__fastcall IOTC_Get_Version(_DWORD *result)
{
  if ( result )
    *result = 0x2010804;
  return result;
}

我们采用这种方法来评估FirmwareTotal库中TUTKSDK版本分布，结果如下
制造商视角
制造商
受影响的固件数量
日本盾科技
96
日本威电讯科技 (QNAP)
55
日本醴陵（LiLin）
51
坦维斯
22
香港光影（KGuard）
11
小米
日本趋势网（TRENDnet）
台湾IO (IODATA)
腾达
孝义
日本Zxtech
日语环名 (HME)
日本韩华Techwin
热隆

固件视角
通过对FirmwareTotal中的固件进行关联分析，发现只有5个固件包含3.1.10及以上版本（3.1.10.7）的SDK。 对于高于该版本的SDK，包含其的固件数量统计分布如下：
SDK版本
包含此版本 SDK 的固件数量
1.6.0.0
1.9.1.0
142
1.10.0.0
21
1.10.2.0
54
1.10.3.0
122
1.10.5.0
1.10.6.0
1.10.7.0
1.10.8.0
27
1.11.0.0
1.13.8.0
2.1.3.0
13
2.1.4.22
2.1.8.4
2.1.8.13
3.0.0.0
3.0.1.29
3.1.4.48
3.1.5.38

供应商维修建议
参考TUTK官方给出的漏洞影响范围及修复措施：
势力范围
使固定
写在最后
与CVSS给出的9.1的威胁评分以及需要捕获流量作为前提相比，摄像头设备面临的RCE漏洞往往更加致命。 我们敦促相关设备制造商关注摄像头设备的代码质量和供应链风险。
在分析该漏洞的过程中，通过Security Brain在全网的持续检测，我们观察到受该漏洞影响的厂商和产品型号范围仍在减少和变化过程中：（受影响设备固件和文件的完整列表请参见【阅读原文】）

据悉，安全大脑还检测到mirai_ptea僵尸网络正在利用上述设备的其他漏洞进行DDos攻击并传播[6]，这引发了另一个观点：
在供应链安全风险问题上，过去业界主要关注关键基础设施等某些领域，而其他领域，尤其是物联网等大型智能设备，由于单个物联网设备安全问题影响较小，往往被普遍忽视。
然而，智能家居改善、工业数字化升级、智慧城市建设、智能车联网、智能工业互联网等产生的超过100亿个物联网设备聚集所产生的设备网络，在某种意义上已经产生了另一种形式的新型关键基础设施，可以到达城市/鞋厂/公民家中的每一个角落。 大规模物联网设备一旦被僵尸网络控制，就可能被用来窃取城市和国家的方方面面。 情报数据并发起大规模网络攻击。 尤其是，当类似上游软件供应链问题的大规模安全事件再次发生时，可能会同时对网络空间的数千台联网设备造成安全风险，其可能造成的潜在威胁足以与关键基础设施安全问题相比。
行业的全球化导致软件供应链中的问题日益复杂。 世界各地制造商的制造流程相互交织。 网络空间安全长期以来是全球性问题，保障数字经济安全需要全球合作。
从近年来国家立法和激励措施层面，我们已经可以看到越来越多对供应链安全的提及，比如《网络安全审查办法》（修订草案征求意见稿）开篇第一条：
第一条 为保障关键信息基础设施供应链安全，维护国家安全，根据《中华人民共和国国家安全法》、《中华人民共和国网络安全法》、《中华人民共和国数据安全法》，制定本办法。
而在《网络安全产业高质量发展两年行动计划(2021-2023年)(征求意见稿)》中，将软件供应链安全列为重点任务之一：
六、强化共同基础支撑。 持续建设高质量威胁信息、漏洞、恶意代码、恶意地址、攻击行为特征等网络安全基础知识库，强化网络安全知识支撑能力。 推动恶意代码检测、高级威胁检测与分析、信息处理、逆向分析、漏洞分析、密码安全分析等底层引擎和工具开发，提高网络安全知识运用水平。 推动源代码分析、组件组件分析等软件供应链安全工具开发，提高网络安全产品安全开发水平。 积极推进网络靶场技术研究，建设虚拟环境与真实设备相结合的安全双胞胎试验台，提高网络安全技术产品的测试验证能力。
相信未来软件供应链安全问题的整改将会不断完善，360安全大脑和安全专家团队将持续为客户提供更好的软件供应链安全整改服务和基础设施建设服务。
点击原文查看报告全文