Understanding and Securing Devic

Authors: Xuan Feng, Xiaojing Liao, XiaoFeng Wang, Haining Wang, Qiang Li, Kai Yang, Hongsong Zhu, Limin Sun
Conference: USENIX Security 2019
Paper Link: Click Me!

1 概述

本文提供了一种对IoT设备漏洞检测的新思路，即从公开的漏洞报告中提取信息来制定相应的检测手段和防御手段，作者开发了一个自动化工具IoTShield来检测设备接收流量中的潜在漏洞操作。
文章研究内容大致分为三个部分：

• 首先，作者收集了大量真实IoT攻击案例（蜜罐收集、攻击工具、僵尸网络）进行分析，得出了“目前几乎所有的IoT攻击都是利用已知漏洞和公开攻击脚本实现的”的结论。
• 然后，作者提出了利用攻击者对已知漏洞/攻击脚本的依赖性来对IoT攻击进行接检测防御的思路，并设计了IoTShield工具，包含了报告收集、漏洞提取以及规则生成阶段。
• 最后，作者设计了一系列实验评估了IoTShield的有效性和性能。

2 真实IoT攻击分析

2.1 蜜罐

本文中的蜜罐包含真实设备和模拟设备，用于收集真实攻击事件。

• 真实设备蜜罐
  作者部署了8台存在问题的IoT设备（3台路由器和8台摄像机），存在的问题如表1所示。图1描述了蜜罐的结构。

表1 设备漏洞列表 图1 真实设备蜜罐结构

• 模拟设备蜜罐
  作者部署了4个模拟IoT蜜罐，覆盖了超过2000台设备和23个漏洞。相关设置如表2所示。

表2 四种模拟蜜罐

• 分析
  在两个月的时间内，这些蜜罐收集了来自175国家47,089个IP的190,380个HTTP请求，分析过程如下：
  • 首先作者去除了合法的请求，包括合法的登录、"GET /"之类的请求以及其他常规的HTTP GET请求。
  • 通过漏洞数据集中收集到的漏洞利用代码以及常见的攻击模板，来识别来自60个国家大概2000个IoT利用尝试，平均每天38次攻击，详细结果如表3所示。

表3 对部属蜜罐的链路分析

蜜罐收集到了一共2001个攻击，其中有320个是针对该蜜罐的，有1681是针对该蜜罐未覆盖到的设备。这个结果一方面可以说明有些攻击者并不针对特定的设备类型进行攻击，另一方面也可以蜜罐具有广泛的攻击覆盖率。另一个重要的结果是只检测到有164个未知请求，也就是说至少有90%的恶意攻击来自对已知漏洞的利用。此外，作者还发现有96%的攻击使用了与收集到的漏洞报告中包含的相同/相似的攻击脚本。

2.2 攻击工具（Underground attack tools）

作者从地下市场收集了4种攻击工具及其源代码，如表4所示。

表4 IoT攻击工具

通过分析源码，作者发现这些工具利用的都是已知漏洞，它们的攻击脚本都是从漏洞报告中复制的，或者仅做了微小的改变。

2.3 已知的攻击手段（IoT botnets）

作者还分析了最近一些流行的IoT botnets，如表5所示。

表5 已知的IoT攻击手段

结果表明这些攻击里面利用的所有漏洞也被包含在作者收集到的漏洞报告中，攻击脚本也是报告中代码的复制或变种。

3 IoTShield

通过上述的研究结果，我们可以知道IoT攻击脚本通常是在漏洞报告中公开的，从而使得这些漏洞很容易被大规模利用。反过来，攻击者对已知漏洞或公开脚本的依赖也可以帮助我们进行防御。
本文作者开发了一种自动化工具IoTShield，它能够从网络上收集IoT漏洞报告，分析这些报告的内容，然后提取关键信息来生成vulnerability-specific签名。这些签名能够很容易的被部署在现有的入侵检测系统或防火墙中，来检测设备接收流量中的漏洞利用操作。

3.1 工具概述

图2 IoTShield结构

如图2所示，IoTShield主要分为三部分：数据收集，IoT漏洞提取，自动签名生成。

3.2 数据收集

作者从网站上爬取漏洞报告，如表6所示，这些网站是从CVE的参考文献中获取，经过手动筛选得到的。

表6 漏洞报告网站列表

3.3 漏洞提取

（1）预处理阶段Preprocessing
这一部分首先删除了与漏洞无关的文本，例如广告、图片等；同时将网页主要内容、URLs、文档标题、作者以及发布日期保留。由于不同网站拥有不同的模板和HTML结构，作者手动分析了上述13个网站来识别出有用的部分。

（2）Corpora quality analyzer
这一部分是筛选去与IoT漏洞报告不相关的文档，方法如下：

• 字典单词百分比。作者删除了内容中包含大量字典单词的文档（大概占82%），这是由于作者认为大部分漏洞报告中主要包含的非文本信息，例如漏洞路径、函数、脚本或PoC等。
• 超链接的数量。作者认为物联网漏洞报告不应该包含过多超链接，因此作者删除了超过25个超链接的文档。
• 上述阈值（82%和25）的合理性。作者随机采样了100个被丢弃的文档，手动检查是否存在错误的丢弃，发现这些被丢弃的文档均与IoT漏洞报告无关，证实了这些阈值的设置是合理的。

（3）漏洞识别IoT vulnerability recognition
对于保留的文档，作者进一步运行识别器recognizer来从IoT漏洞报告中提取关键信息。这里面用到了NLP技术，具体的内容可以查阅原文。总的来说，作者将漏洞信息表示为设备类型、制造商、产品名称以及漏洞类型4个实体，如图3所示。作者利用这些漏洞信息查找相关的报告以进行后续分析。

图3 IoT/非IoT漏洞实体示例

3.4 自动防御规则生成

在这一部分，作者对描述相同IoT漏洞的报告进行聚类，然后从报告中进一步提取漏洞的语义（漏洞位置或利用路径）以及其他的结构信息（攻击脚本）。图4显示了作者是如何从上面产生的漏洞实体中生成防御规则（签名）的。

图4 IoTShield签名生成流程

（1）报告聚类Report clustering
一些报告可能从不同的方面描述了一个相同的漏洞，因此需要将这些报告整合在一起形成完整的漏洞报告。这里通过使用之前生成实体来对描述相同IoT漏洞的报告进行聚合。

（2）语义和结构信息的提取

• 作者利用NLP技术分析漏洞描述来发现漏洞的语义，包括漏洞类型、位置和利用语句。具体方法可查阅原文。
• 作者使用正则表达式来识别不同的结构化信息，包括Linux命令、PoC URL、PoC HTML脚本、PoC流量日志等。对于每种结构信息，作者将其解析为一个通用的模板：
  http:// HOST : PORT / file.suffix ? {parameters}
  • 其中HOST为设备IP地址，PORT为应用层服务端口（默认为80），file.suffix为漏洞位置，{paramenters}为key-value格式，包含漏洞利用参数。

（3）签名生成

• 首先，作者比较漏洞位置信息和结构化信息模板中的"file.suffix"是否匹配，如果匹配，则认为漏洞的语义信息是与模板建模的规则相关。
• 其次，基于漏洞类型决定是否需要忽略利用参数部分，这是由于某些漏洞不需要利用参数（信息泄露和目录遍历）。对于需要参数的漏洞，IoTShield会从描述中识别出利用参数来覆盖{ paramenters }字段。

对于一些没有漏洞描述和结构化信息的报告，作者采用以下方式来处理：

• 仅包含漏洞描述
  这种情况我们仅能获得漏洞类型、位置和参数等信息，因此只能为部分漏洞生成签名，包括信息泄露和目录遍历。例如对于信息泄露，对网站的请求就足够生成签名。
• 仅包含结构化信息
  这种情况没有漏洞描述，无法产生通用的漏洞签名。但是由于IoT攻击常使用这些公开的脚本，我们仍可以利用结构化信息来生成一个利用签名。

4 实现

IoTShield包含三个关键组件：报告收集、漏洞提取以及规则生成，实现方式如下：

• 报告收集爬虫使用wget和scrapy框架从网络上获取报告。
• 漏洞提取器由2300行python代码实现。
  • Beautiful Soup Python库用于解析漏洞报告的主要内容
  • NLTK包用于分割句子、词语等
  • Aho-Corasick算法是用于加快实体识别的字符串搜索算法
  • Ascikit-learn库用于计算TF-IDF（(Term Frequency-Inverse Document Frequency）余弦相似性
• 规则生成器由1500行python代码实现，作者使用Simhash算法检测重复数据，使用Stanford dependency parser建立依赖树。

5 评估

5.1 有效性评估

• 漏洞提取
  作者从识别的报告中随机抽取200份进行了人工验证，准确率达到了94%
  总体上，IoTSheild从43万篇文章中收集了7514个IoT漏洞报告，如表6所示。这些报告披露了12286个IoT漏洞，图7显示了1998年至2018年每月平均披露的IoT漏洞数量。

图7 IoT漏洞发现趋势

作者发现这些IoT漏洞与设备类型和供应商相关，近60%的漏洞设备来自具有最多安全漏洞的前10供应商，如表8所示。其中最常见的IoT漏洞设备时路由器、交换机和摄像机，拥有最多漏洞的供应商Cisco、D-Link、Linksys都拥有较大的市场份额。

表8 受影响的前10供应商和设备类型

表9列出了数据集中的十大漏洞类型，其中大多是可远程利用的。XSS、命令注入、命令执行常被恶意软件用于在一个僵尸网络节点设备上执行命令。

表9 前10漏洞类型

• 规则生成
  作者使用从IoT设备和蜜罐收集到的190K个HTTP请求来评估IoTShield规则生成的有效性，如2.1节所述，IoTShield自动生成签名评估结果如表10所示。

表10 IoTShield有效性

• Precision = |TP| / |FP+TP|
  Recall = |TP| / |TP+FN|
  FPR = |FP| / |FP+TN|
  其中，TP为true positives数量，FN是false negatives（漏报）数量，FP是false positive（误报）数量，TN是true negitives数量。

此外，作者还在工业控制系统的HMI蜜罐中捕获的流量来评估IoTShield，持续时间从2017.10到2018.11。IoTShield报告了7396条警报，手动检查确认了大约6705条警报确实为物联网攻击，其他警报为普通Web服务器上的漏洞攻击。

5.2 性能评估

作者测试了IoTShield在各个阶段处理漏洞报告的时间，运行环境为商用台式计算机（Ubuntu 18.04, 8GB of memory, 64-bit OS, with 4-core Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz），结果如表11所示。其中，从网络上获取漏洞报告时间受网络条件的影响。

表11 IoTShield不同阶段运行时间

结果表明IoTShield是高效的，几乎不会带来额外的开销。

6 Limitations

作者指出了IoTShield一些不足之处。

• 本文的数据收集检索了13个不同的网站，并不能涵盖所有的IoT漏洞。
• 由于蜜罐IoT设备类型和部署时间不同，所收集的流量日志可能存在偏差。
• 由于IoTShield处理的漏洞信息可能是不完整的（缺少漏洞描述或结果信息等），可能漏报一些漏洞的变种。
• IoTShield无法处理默写特定程序语言的漏洞，其处理能力仅限于流量日志、脚本、Linux命令等。

7 Mitigation

作者根据研究结果提出了几种有效的缓解策略。

• 供应商应该提供一个官方漏洞报告平台，及时检查并回复漏洞报告。
• 供应商需要为停产的产品提供技术支持，尤其是仍广泛使用的设备。
• 供应商应当尽量正确配置设备，并及时通知用户更新设备信息或自动更新。
• 漏洞的发现者应当遵循漏洞报告的准则，尽量在供应商发布补丁程序之后，公开漏洞信息。
• 设备用户需要注意设备配置，及时更新设备。

PS：如有任何问题，欢迎交流，感谢！！