物联网供应商应该怎样进行安全的测试

CITL 大规模模糊测试项目的新测试结果显示了现实情况有多糟糕——以及物联网设备制造商如何通过一天的工程作业从根本上提高二进制安全性。

模糊测试 （fuzz testing） 是一种安全测试方法，它介于完全的手工测试和完全的自动化测试之间。为什么是介于那两者之间？首先完全的手工测试即是渗透测试，测试人员可以模拟黑客恶意进入系统、查找漏洞，这对测试人员的要求比较高。能力强的测试人员可以发现比较多或者高质量的安全性问题，但是如果测试人员的能力不够，可能就不能找到足够多、威胁大的安全漏洞。所有渗透测试对人员能力的依赖性强，成本高，难以大规模的实施。

但是想用完全的自动化来实现渗透测试也不可行，同一套测试用例和方法不可能不加修改的就用在不同的产品上，因为各个产品的需求、实现、功能等等都不一样。测试过程中还需要测试人员的介入来分析结果、判断漏洞等等。那么，这种情况下就需要引入模糊测试。

打开 “编译时” （compile-time） 安全功能很容易，那么为什么没有更多的物联网设备制造商这样做呢？

在构建物联网固件二进制文件时添加安全功能标志可以显著提高整个物联网设备的安全性。但是，根据 CITL 大规模模糊测试项目的研究显示，几乎没有人这样做，问题正变得越来越严重，而不是更好。

这都是一些非常基本且简单的安全实践……根本就找不到充分的理由不去这么做，但现实是，大部分物联网设备制造商确实没有这样做。

Cyber ITL 是一个非盈利的消费者报告式安全实验室，迄今为止已经对过去 15 年发布的 300 多万个物联网固件二进制文件进行了模糊测试，但结果却令人失望。

在谈及大部分物联网设备供应商并未打开基本的 “编译时” 安全功能时，CITL 首席科学家 Sarah Zatko 感叹道：

这很容易做到，我也想不出有什么理由不去这么做，但结果就是他们并未这么做！我认为他们应该不是故意忽视这一点的，因为看起来不像某个人有意识地决定排除这些安全特征，而更像是一种 ‘良性/无意的’ 忽视，可能是某人认为这并不属于他们的工作范畴。

post-build检查单

物联网供应商可以轻而易举地打开这些 “编译时” 安全功能，并且检查它们作为其发布管理流程的一部分。良好的构建卫生包括检查是否存在更新版本的编译器，并确保启用基本安全功能，如 ASLR，DEP 以及堆栈防护。虽然这些安全缓解措施都并非 “灵丹妙药”，但它们仍然是物联网世界的 “安全气囊” 和 “安全带”。也许它们无法阻止崩溃，但它们在关键时刻可能会挽救你的生命。

而要完成这些操作可能只需要几个小时的工程作业，最多不会超过一天的时间。如果由于某种原因存在一些特殊的操作系统和芯片组合的奇怪边缘现象，那么问题可能会相对麻烦复杂一些，但大多数情况下应该都还是非常简单易实现的。

由于在我们继续部署不安全的物联网设备时，不良构建卫生的后果会变得更为复杂，因此物联网供应商需要开始检查他们正在进行的 post-build 质量检查测试，或者他们可能会发现自己是被强制规定需要这么做的。

鉴于自由市场到目前为止未能鼓励供应商采取这种负责任的行为，人们不禁会质疑，在这种不良的监管环境下，何时会引爆物联网安全危机？

物联网安全：自由市场还是监管？

到目前为止，自由市场未能制定有效地激励措施，以鼓励供应商提供强有力的网络安全产品，但 Zatko 希望大型买家可以在其中发挥作用。

自由市场本身没有做太多努力。15 年来情况一直没有发生变化……如果做出大规模采购决策的人开始询问有关构建安全性的问题，那么可能会影响供应商的实践。而无疑，企业组织和政府机构正是物联网产品的大买家。

买家通常会在签订新协议之前提供他们所要求的安全问题清单。在该清单中囊括构建安全问题，将迫使供应商进行实际检查，并且也能够让供应商明白大型买家是关心构建安全问题的。

物联网固件安全问题

不过，CITL 的研究也发现了一些惊喜——物联网供应商应该知道的级联故障点。编译器和固件工具链（如buildroot）是关键的上游依赖项，可以更好地帮助开发人员在编译时标记安全问题。此外，MIPS 仍然是一个问题，且需要特殊处理。

MIPS 的意思 “无内部互锁流水级的微处理器”，其机制是尽量利用软件办法避免流水线中的数据相关问题。MIPS 采用精简指令系统计算结构 （RISC） 来设计芯片。

MIPS 架构优势：

（1）支持 64Bit 指令和操作;

（2）MIPS 有专门的除法器，可以执行除法指令;

（3）MIPS 内核寄存器比 ARM 多一倍，也就是说在同样性能下，MIPS 功耗比 ARM 更低，同样功耗下性能比 ARM 更高;

（4）MIPS 指令比 ARM 多一些，执行部分运算时更灵活。

MIPS 架构缺点：

（1）MIPS 内存地址起始有问题，这就导致 MIPS 在内存和 cache 的支持方面受限，单内核无法承受高容量内存配置;

（2）MIPS 技术大发展方向是并行线程，从核心移动设备的发展趋势来看，并不是未来主流;

（3）MIPS 虽然结构更简单，但采用顺序单/双发射，执行指令流水线周期远不如 ARM 高效;

（4）商业化进程落后，至今还停留在高清盒子打印机之类的产品上;

（5）软件平台落后，应用软件少。

如今，很多人错误地以为 MISP 正在步入淘汰行列，但该硬件架构已经在物联网领域卷土重来，且事实证明，该架构正是 CITL 在大规模模糊测试中遇到的最常见的架构。他们发现，问题在于，从安全的角度来看，并非每个架构都是相同的。

许多人认为，如果你采用相同的源代码并将其转移到不同的芯片或不同的架构中，其仍然能发挥相同的安全特性和功能。但是事实并非如此，就安全方面而言，必须要考虑整体情况。

事实证明，为 Linux MIPS 版本启用 ASLR 和 DEP 编译时功能无法正常工作，消除、部署和完全修复该问题可能需要花费数年的时间。十多年来，Linux MIPS 二进制文件一直很容易被经典的堆栈溢出攻击利用，而且根据 CITL 对工具链补丁的检测结果显示，这种情况仍在持续。

更糟糕的是，物联网固件领域似乎正存在大量无意义的代码重用现象，且每个人都想当然地以为其他人已经做了安全审计工作。当查看不同的产品时，实际上出现了很多共同的二进制文件，这表明许多不同的供应商正在使用相同的框架来构建他们的物联网平台。

开发人员用户界面——编译器和固件构建工具链——中的敏感安全默认值将流向下游并影响使用这些产品的供应商，以及随后将使用这些设备的数百万用户。

编译器本身可以提供更好的报告，说明在编译过程结束时实施了哪些安全功能。此外，编译器也很容易提供透明度，并为开发人员提供有关刚刚生成的内容的更好反馈。

来源：安全牛