针对漏洞的恶意行为分析
我们共捕获到 4 种针对 UPnP 漏洞的利用行为 1，如表 4.7 所示。从中可以看出，这些漏洞均为远程 命令执行类漏洞。另外我们也发现，当漏洞出现在特定端口时，攻击者一般不会经过 UPnP 的发现阶段，
1 需要说明的是，由于 UPnP 的 SOAP服务端口众多，而 SSDP 服务中只能标识一个 SOAP端口，因此，我们主要是对 SOAP相关端
口进行了监听。如果攻击者首先进行 SSDP 服务发现，再根据服务发现内容决定下一步是否要进行攻击，我们则可能无法对其进行 捕获。
而是会选择直接对该特定端口进行攻击。
表 4.7 UPnP 漏洞利用情况（按源 IP 去重排序）
|ExploitDB编号|漏洞公开年份|CVE编号|漏洞描述|
对 UPnP 日志中的源 IP 去重之后，我们发现对 UPnP 漏洞进行过利用的 IP 约占所有 IP 的 29.6%。 我们对去重之后的源 IP 的国家分布进行了分析，从图 4.16 中可以看出， 位于中国的攻击源最多。更进 一步我们发现，来自中国攻击行为的 90% 位于自台湾省，中国大陆地区的攻击源量级与俄罗斯、美国 等国家的量级相当。结合图 2.2 中 2019 年国内 IPv4 资产地区分布情况，我们有如下推测，台湾省物联 网资产暴露数量多，恶意软件
在这些设备间广泛传播，部分失陷设备组成的僵尸网络进一步扩散，因为 设备基数庞大，我们捕获到的攻击源也相应更多。英国
图 4.16 UPnP 类日志攻击源 IP 的国家分布情况
我们对来自中国的攻击源 IP 的资产类型进行分析。结合绿盟威胁情报中心（NTI）对这些 IP 资产 的开放端口信息与设备类型标记，我们对一些已知类型的设备进行分类。除了我们能够确认型号的摄像
头、NVR、路由器等物联网设备外，我们亦将符合以下标准的 IP 资产归类为嵌入式
/ 物联网设备。- 开放 UPnP 或 WS-Disc
overy 服务。- NTI识别到设备运行了 Dropbear、lighttpd、MiniHTTPD 服务。
通过以上标准进行分类的结果如图 4.17 所示。位于中国的 76.6% 的攻击源 IP 是物联网设备，其中 21.3% 的设备是摄像头、NVR，7.3% 的设备是路由器。攻击源与受害者都是物联网设备，再次印证了 我们的猜测，攻击者针对这些物联网设备进行攻击时，同时利用这些设备作为跳板攻击其他设备，并传 播恶意软件。
打印机 77
VoIP电话 91
路由器 956
摄像头/NVR 2788
其他设备 3992
其他物联网设备 9172
图 4.17 中国 UPnP 漏洞攻击源 IP 被 NTI标记的资产类型
结合捕获的攻击日志、关联漏洞与资产数据，我们也对潜在受影响的 UPnP 设备的国家分布进行了 分析。我们选取 UPnP 漏洞攻击行为关联的厂商信息、SDK信息、攻击目的端口，并在资产数据中进行 关联。我们认为受到目前 UPnP 漏洞攻击行为潜在威胁的设备包括：
- 华为特定型号、采用特定 UPnP SDK 的设备。
- 采用 Realtek UPnP SDK 的设备。
-
D-Link特定型号、采用特定 UPnP SDK 的设备。
美国
波兰 巴西 韩国 乌克兰 西班牙 俄罗斯 中国 印度image
日本
图 4.18 潜在受影响的 UPnP 设备的国家分布情况
4.5 小结
本章首先对 Telnet 服务进行了威胁分析，整体来看，前半年对于 Telnet 服务的利用情况逐月增加，
在 8 月份活跃的攻击者最多，直到后半年攻击者的数量才有所减少。攻击者的国家分布广泛，其中又 以中国和美国的攻击者最多。通过对攻击者的弱口令分析，结合最初的 Mirai 恶意代码也是通过 Telnet 服务的弱口令将路由器、频监控设备组建成僵尸网络的，可以得出攻击者主要还是以攻击开放 Telnet 服务的物联网设备为主的结论。
自 WS-Discovery 反射攻击在今年 2 月被百度安全研究人员披露以来，今年下半年利用 WS- Discovery 进行反射攻击的事件明显增多。蜜罐捕获的 WS-Discovery 反射攻击事件从 8 月中旬开始呈现 上升趋势，9 月份之后增长快速，需要引起相关人员（如安全厂商、电信服务提供商、运营商等）足够
的重。类似 WS-Discovery 反射攻击这种利用物联网资产进行恶意行为的新型攻击方法将会随着物联 网设备的增多而不断出现，暴露数量多并且之前并未引起足够关注的物联网资产同样需要重点关注。
UPnP 服务的暴露数量较去年减少约 22%，但依旧在两百万量级。从国家分布来看，俄罗斯的暴露 数量变化最为明显，相比去年下降了 84%，因此，我们推测俄罗斯的相关部门推动了对于 UPnP 的治理 行动，这也在一定程度上反应出物联网威胁正在从监测走向治理。但这种层面的治理终究治标不治本， 理想情况下，相关部门、厂商应该推动 UPnP 相关 SDK的完善，同时对于存在问题的产品，推动相关 厂商进行补丁的修复，并且将对于 UPnP 的安全评估纳入物联网安全评估指标项中，从而确保不会再有 新的产品存在已知的风险。另外，也可以参考第五章的物联网终端安全防护机制来进行防护。
面向物联网终端的安全防护机制
引言
为缓解越来越严重的物联网相关威胁，绿盟科技提出了融合“云管边端”的物联网安全解决方案。 其中，我们将物联网云端、运营商管道、边缘计算的安全称为基础设施安全，将物联网终端上的各种安 全机制称为物联网终端安全。
相比于云端和管道侧有相对成熟的防护机制、边缘尚未成型也无现实威胁，物联网终端却面临巨大 的安全挑战，其安全显得更加的重要。一方面，虽然物联网设备已存在很长的时间，但早期物联网设备 及其应用协议都因为安全性设计考虑不周，存在各种的脆弱性；另一方面，前文的物联网安全事件、资 产暴露情况及物联网的威胁分析，不法分子已经开始利用这些物联网设备的漏洞和脆弱性，对个人、企 业乃至国家产生了严重的威胁。所以在本章，我们提出一种以终端保护为核心的物联网安全防护方法， 以提高整体物联网的安全防护能力。
物联网基础设施安全防护
绿盟科技作为专业的云安全服务提供商，与主流的云计算服务商合作，保护云上业务的安全性。绿 盟科技云安全解决方案采用了软件定义安全架构，把零散的虚拟化安全设备和传统安全设备进行整合， 形成安全资源池，实现安全设备服务化和管理集中化；通过 API方式与云平台进行联动。云安全解决方 案能覆盖私有云、行业云和传统数据中心安全，丰富、弹性、灵活、开放地帮助客户应对云计算平台和 云上业务系统面临的安全风险和挑战，如图 5.1 所示。具体云安全解决方案部分，可参见绿盟云相关产 品和服务 [52]；
图 5.1 绿盟科技云安全解决方案
在管道侧，绿盟科技有多年的运营商骨干网的安全运营支撑经验，如态势感知、僵木蠕、近源清洗 等安全解决方案，可有效地检测和缓解来自物联网的拒绝服务攻击，以及针对物联网终端的恶意探测和 攻击。
随着云和人工智能平台日趋成熟、5G 网络的逐步应用与普及，网络边缘侧出现了大量边缘节点用 于分担服务器的分析压力，如基于 ARM、Intel 高性能芯片的网关产品等。终端和边缘会进一步融合， 以满足高实时场景下的分析需求。边缘计算是 5G、物联网和工业互联网场景下新型的基础设施，面向 边缘计算的安全防护还在早期阶段。
边缘节点的处理能力通常强于普通物联网终端，所以其安全能力会也相对更强，此外，如 StarlingX、OpenNess 等边缘计算平台都同时是基于虚拟化和容器技术的，呈现云化的特性。所以边缘 计算平台的基础设施安全，很大程度上与保证虚拟化、容器和编排系统的安全。除了前述云安全解决方 案外，绿盟科技于 2018 年发布的《容器安全技术报告》[53] 全面介绍了容器安全的防护思路和体系。更 详细的边缘计算安全研究，敬请期待 2020 年绿盟科技的《边缘计算安全报告》。
物联网终端的防护体系
观点 7：安全事件频发，有严重安全问题的物联网终端隐藏着巨大的威胁。物联网终端防护能力急 需建设。而物联网终端功能、结构非常简单，防护时需要注意两点：终端的信息保护和终端的异常分析。**
当前，物联网的威胁的源头往往指向了脆弱的物联网终端，在云、管、边安全的支撑下，我们提出 一种以终端保护为核心的物联网安全防护体系，为物联网终端构建两种能力：终端的信息保护能力和云 端对终端的异常分析能力。前者能保证终端在其自身的使用场景下，有一些方式可以保证终端内部指纹、 密钥等信息的安全；后者能保证即便终端在电站、水闸等很难维护的场景中运行时，也能安全地将一些 信息上传到管理平台，并能分析出终端的异常状态。
该安全防护体系如图 5.2 所示。对于终端内部的关键信息，如密钥、口令、指纹、声纹等可以放到 芯片中，基于芯片内部的安全能力把这些关键信息保护起来。印制电路板负责调试接口的限制与隐藏， 比如设置串口访问口令、设置调试接口访问控制等。固件是实现这些保护功能的软件代码。硬件、固件 设计的合适，可以保证攻击者在不拆解芯片的前提下无法获取关键信息和调试功能。在固件中，必要场 景下需要提供可信基础，以防止恶意软件等应用对破坏终端、篡改关键信息等。在终端上应用可信环境， 后续小节中会详细介绍。
图 5.2 物联网终端防护体系
固件、操作系统与文件系统作为中间件为上层应用提供基础，其安全性主要体现在对上层应用访问 内存、硬盘外围设备等资源的访问权限方面，这些中间件能提供的基础 API已经足够，所以应用层只需 要基于操作系统、文件系统的 API做好自身的安全性即可。而操作系统、文件系统在实际应用中只有可 选的几个方案，终端需要关注的是已有哪些安全问题，比如嵌入式 Linux、嵌入式安卓、RTOS（Real-time Operating System, RTOS）等，其漏洞信息在 CVE Details 网站 [54] 上可查，厂商需要针对这些漏洞做好 安全防护，如做好内核更新、源码漏洞修正等。
物联网终端一般性能受限，安全分析、处理的能力欠缺，所以需要云端强大的计算能力提供安全分析， 终端需要上传一些信息配合云端做异常分析。云端分析完成后，如果有异常，终端需要处理异常。从行 为角度分析，终端有两个行为需要引起注意：进程行为和网络行为。进程行为决定了如何处理终端内部 信息，网络行为决定了信息怎么出去，怎么进来。如果恶意软件入侵成功，必然需要一次通信保证恶意 软件被植入，然后启用恶意软件进程。所以，针对终端的行为分析，可以简单地理解为进程行为和网络 行为。终端侧防火墙（如 iptables）结合策略可以做网络控制以停止恶意连接，终端内需要具备进程控 制能力以杀死恶意软件进程。由于策略是经过云端分析并发现异常后确定的，所以必须有一个通道负责 接收云端策略。这样，信息上传、异常分析、策略接收与执行这些流程形成了闭环。
还有两个敏感问题需要注意：信息保护和安全升级。信息保护所说的信息可分终端自身信息保护与
网络信息保护。终端内部信息是诸如密钥、指纹等关键信息，网络信息是需要上传的信息，如域名请求 信息、NetFlow 等。对网络信息的保护，终端和云端需要在足够强的认证和加密的基础上建立安全通道， 对终端自身信息的保护需要结合安全存储、可信执行、硬件调试策略等机制来实现。如果有软件需要升 级，还需要在终端和云端之间建立一个安全的文件传输通道负责升级包的发送与接收，终端也需要安全 地处理升级包，以防止恶意升级等。
物联网终端的信息保护
防护思路
需要指出的是，SDK（Software Development Kit）包含芯片厂商、代工生产厂商（Original Equipment Manufacturer，OEM）、安全厂商等提供的所有 SDK。信息分 7 个，其中，前两个是硬件 信息，考虑到终端的组装、维修等流程，这些硬件信息必须完整保留。中间三个则可以通过应用可信系 统、安全探针、SDK等得到部分或者完整的支持。对于指纹等关键信息的保护，目前只能依托安全芯片、
可信系统和安全 SDK来保证。目前对网络的加密和认证，表格所示 5 种方案均能保证。由表 5.1 所示， 横向是一些安全解决方案，纵向是终端上的信息，空心圆表示不支持该信息的保护，实心圆表示支持该
信息的保护。
表 5.1 物联网终端的信息保护
物联网终端的信息保护
安全设备 安全芯片 安全探针 可信系统 SDK 信息
PCB 丝印 ○ ○ ○ ○ ○ 芯片型号 ○ ○ ○ ○ ○ 通信总线接口 ○ ○ ● ○ ● 调试接口 ○ ○ ○ ○ ● 固件信息 ○ ○ ○ ● ● 密钥、指纹等关键资产 ○ ● ○ ● ● 网络信息 ● ● ● ● ●
PCB丝印和芯片型号
PCB 信息和芯片型号可以不用抹去，我们假设攻击者可以看到芯片型号，而且可以在网上获取到该 芯片的相关信息，如参考手册、数据手册等。攻击者获取到这些信息之后，会找到设备上的调试接口，
最起码是可以通过使用调试器使自己的 PC 和设备之间建立正确的硬件的连接。
通信总线接口
通信总线接口是指 UART（Universal Asynchronous Receiver/Transmitter）、I²C （Inter-Integrated Circuit）、SPI（Serial Peripheral Interface Bus）、I²S（Inter-IC Sound 或 Integrated Interchip Sound）、RS-485 等通信接口，这部分接口一般会连接传感器，利用逻辑分析仪可以嗅探到总线上的数据， 这部分的数据很难做好防护，只能在开发阶段基于厂商的 SDK做好限制，比如通过设置 UART登录认 证限制访问权限，在应用层对数据进行认证和加密。具体采用什么算法对通信数据做认证和加密，需要 结合使用场景和终端性能、功耗而定。
调试接口
硬件接口这些可以保留，但是出于安全考虑，对调试接口做访问控制的能力成为了一种需求。2018 年，Ramesh Bhakthavatchalu 和 Nirmala Devi.M 发布了一篇对 JTAG (Joint Test Action Group）接口 做访问控制的文章 [55]，在 NXP最新的 LPC55S69 系列的微控制器中，已经将基于密码学的调试接口的 认证流程集成在芯片中，以保证关键信息和代码的安全性 [56]。这种防护思路需要结合芯片厂商提供的 SDK实现，在开发中设置寄存器和相关密钥参数，以保证调试接口的访问控制。
固件信息
前面的防护方法，尽管可以保证固件很难被读取，但是也不能排除攻击者通过社工等手段获取了固 件。如果攻击者伪造了一个固件，得就防范攻击者能正常运行伪固件。针对固件的防篡改保护，需要结 合安全存储把密钥放到一个 OTP Memory（One Time Programmable）或者其他安全存储区域，这样密 钥写入后将无法被更改，利用该密钥做代码签名认证，可以防止代码被篡改。因为做校验的密钥是无法 被更改的，在攻击者获取不到相应的私钥的前提下，即便通过一些文档或者经验，找到了前面方法，也 无法伪造合法的固件签名。而可信系统正式保证了这样的认证流程。进一步想，读取密钥、验证签名的 代码则成为整个安全的核心。可以基于 SDK，利用芯片中对 flash memory （快闪存储器，夜间闪存， 以下简称 flash）的读保护的功能，对这段代码做好读保护，使攻击者无法获取这段代码。同时还可以 利用这段代码做好固件的解密，密钥存储在相同的区域即可。如果这段代码非常小，放在芯片中加以保 护即可，如果在外部 flash 中，则需要考虑采用具备认证、加密功能的 flash 才可以。近期，一些存储 器的研发厂商，如 Micron Technology[57]，在 Nor Flash 中集成了数据访问控制功能，对数据的访问需 提供密码。
当固件篡改、读取被限制到足够强的程度时，安全通信的密钥存储有了一定程度的保证，在现有的 芯片厂商提供的方案来看，该保证是在攻击者没有对芯片做拆解、拍照、逆向的过程。由于对芯片的拆 解成本太高，所以，这些最新的安全功能对物联网设备的防护程度已经足够强。
关键资产
关键资产的保护可以依托固件保护功能，将关键资产集成到固件中，通过防止固件被读取，来保护 关键资产的泄露。关键资产还可以直接放到安全芯片中，基于安全芯片自身的安全性来保护资产的安全， 思路和固件保护相似。
网络信息保护
对网络信息的防护，只需要关注通信协议即可。如果通信协议中支持认证、加密方式，只需要稍做 配置即可做好通信的认证、加密。如果协议本身不支持认证和加密的配置，就需要利用密码学库，基于 该协议的通信方式做双向认证的访问控制和加密的数据传输功能。
不同的网络通信模式，对访问控制的要求也有些许不同。姑且把网络协议分为点对点的模式、点对 多的模式。点对点的模式比较好理解，比如 HTTP、SSH 等协议是点对点的协议，像 MQTT等具备订阅、 分发模式我们暂时称为点对多的协议。对点对点的协议，只要在通信双方之间做好双向认证、加密，在 物联网通信场景下已经足够安全。而对点对多的协议，即便做了客户端和 Broker 之间的双向认证，涉 及一个因信息共享导致的问题：信息泄露。以 MQTT为例，MQTT 的网络结构如图 5.3 所示 [58]：
图 5.3 MQTT 工作模式
MQTT以 Topic 作为信息的标签，订阅 topic 相同，则能收到 MQTT Broker 转发的相同的信息。如 果“mobile device”是一个攻击者身份，他遍历地订阅了 1000 个 Topic，如果这 1000 个 Topic 有 10 个 Topic 确实被物联网设备使用，则这 10 个 Topic 数据同时传输到了攻击者的手机上。所以，对 Topic 访问控制也是必须的，这方面可以结合 ACL访问控制规则实现，此处不再赘述。
