打造固件空间安全测绘领域的“谷歌”

释放双眼，带上耳机，听听看~！

随着科技发展，形形色色的智能家居产品走进千家万户。但是这些IoT设备背后的网络安全问题往往被人忽视，导致近年出现了越来越多的安全事件。在过去一段时间里，360安全研究院的安全研究团队一直对市场上主流IoT产品...

随着科技发展，形形色色的智能家居产品走进千家万户。但是这些IoT设备背后的网络安全问题往往被人忽视，导致近年出现了越来越多的安全事件。

在过去一段时间里，360安全研究院的安全研究团队一直对市场上主流IoT产品的安全性保持关注，并打造了”固件空间安全测绘系统”——360FirmwareTotal。

目前，FirmwareTotal平台对于IoT安全领域的白帽子用户来说，已经能够帮助他们去提高安全分析效率、提高研究产出。未来，随着团队不断壮大，计划覆盖更多领域的白帽子，让他们也能够受用到，以提高用户群体数量。

为让大家更清楚了解过去一年半里产品与团队的成长过程，以下是FIrmwareTotal演进之路的梳理。在下文中，大家可以看到FirmwareTotal的简介，按照4个版本的迭代进化，详细讲解FirmwareTotal的萌芽、发展和创新全过程，现在已经能够解决的问题，及未来发展方向。

FirmwareTotal简介

FirmwareTotal是什么呢？简单来讲，它是个搜索引擎。它的背后，是大规模IoT、工业设备等的固件样本数据，以及一连串数据加工引擎。因此，我们也把它称作”固件空间安全测绘系统”。

而如今它主要解决的问题，简而言之，就是在IoT领域，攻防信息不对称问题。

举个例子来讲，在某安全事件中：
•安全研究员在一个设备中发现了漏洞，通报给厂商；
•厂商进行筛查后，对4个型号设备中发布的补丁进行修复；
•漏洞公布后，黑客利用类似FirmwareTotal这样基于大规模固件数据的固件空间安全测绘系统，就可看到还有多种其他型号设备也受该漏洞影响，但是没有人知道。因此，就可以利用N-day漏洞，神不知鬼不觉地攻击这些”漏网之鱼”设备。而对这些设备来说，遭受到的就等同于0-day攻击。

就如下图所示一样：

我们想实现的目标，是借助该工具，让安全研究员能够看到比攻击者更大范围的漏洞影响范围，将攻防过程的信息不对称优势，牢牢掌握在己方手中。

除此之外，FirmwareTotal的玩法还有很多，想象空间很大。比如，在关联搜索到漏洞相关固件后，还可以在线仿真设备，进行漏洞验证。此外，我们也提供了一些漏洞案例，用于学习。

它的架构，是在数千厂商、数十万固件的大规模固件数据库基础上，开发的攻防搜索引擎、虚拟靶场等安全工具，一站式解决”评估漏洞影响的疑似设备范围，并通过仿真设备进行最终漏洞验证”的平台，希望能为业界提高IoT攻防过程的效率。

经过数年积累，如今从公开资料来看，该平台上积累的IoT固件样本数量，已经达到了业界最大规模的量级，包括数十万的固件、数千万的去重后文件，覆盖数千厂商。

它目前所瞄准的用户群体，是关注IoT/工业固件领域安全问题的安全研究员。

在未来，我们会通过扩展数据维度，让更多领域的安全研究员，也能通过该平台，获取安全研究效率提升能力。

阶段回顾

对各个阶段的回顾，将按照大版本来划分。我们还总结出了每个阶段的关键词：

•v1.0：从日常研究萌发想法，开始探索
•v2.0：从跨部门想法碰撞，找到有意思的应用场景，产品第一次大改版
•v3.0：沉下心打磨产品
•v4.0：效率与性能革新

v1.0：最初的探索

最初，我们一直在做大规模固件数据的积累。一天，我们到兄弟部门谈合作。

事情的缘由是，他们在一个路由器设备上发现HNAP服务的漏洞，觉得该漏洞在其他设备上，有可能也存在，想买更多路由器设备，回来测试。但面临一个难题，就是不知道还有哪些设备有HNAP服务。这些设备，都有一个特征，就是固件中都有HNAP目录。而他们根本没有渠道去了解，市场上哪些设备的固件有HNAP目录。

刚好我们在对固件进行大规模分析时，有提取里面的目录特征，因此，在这个需求提出来后，我们就萌生了一个想法：把过去提取出来的数据，做一个查询接口，对外提供查询服务，有点儿像一个搜索引擎。

于是，从2019年2月开始，经过两周左右通宵开发，第一版上线了，样式如下图所示：

它有一个简单搜索框，以及搜索后的分析动作，包括Select和Do两部分，因此，我们一开始称之为“Select-Do”。

搜索结果的展示，也非常简洁，基本上就是给出关联的厂商和文件名称：

到了这一步，便上线提供给他们使用，帮助他们快速找到具有HNAP服务的设备。

后来，团队提出了新问题：这个系统，还有什么其他应用场景？

不久后，出现了Google Project Zero团队披露TP-Link SR20 0-day事件，引发社区广泛讨论，拿着真实或者仿真SR20设备，进行漏洞验证。

我们在分析该漏洞过程中，出于好奇，就把漏洞的一些特征，在系统里尝试搜索，忽然发现该漏洞影响的远不止SR20这一个型号，其他多个型号也用了存在漏洞的组件，因此导致漏洞基于供应链的传播。

最终，我们确认了该漏洞更大的影响范围：

后及时通报给了TP-Link厂商进行修复，厂商也很快发布了对应的补丁固件：

通过这次事件，忽然意识到，如果恶意攻击者利用类似FirmwareTotal这样的系统，先我们一步挖掘其他被该漏洞影响的设备，并进行攻击，有可能到最后，所有人都浑然不觉。

在真实的攻防世界里，我们必须假设恶意攻击者已经具备了所有先进的工具条件，包括大规模的固件数据和类似FirmwareTotal这样的系统。

而利用该系统所带来的信息不对称进行攻击，实际上就形成了一种上帝视角的降维打击。

况且有了FirmwareTotal这样的手段后，玩法儿不止一种。比如，恶意攻击者还可以在挖到新的0-day漏洞后，将该漏洞的特征，放到系统里搜索，在全网数十万固件中匹配所有可能的潜在缺陷设备。这将形成某种意义上的”漏洞放大”。

为此，我们后来又专门分析了几起类似案例，并对外发布分析文章，希望能引起业界对这种手段的注意。

v2.0：新场景带来产品的第一次大改版

在分析上文涉及的那类案例过程中，我们也在积极寻找更多内部用户，希望有更多关注IoT安全领域的安全研究员能用上这个系统，为他们创造价值。

后来，在一次安全技术会议中，有位Netlab那边的同事，发表了关于IoT安全研究的主题演讲，符合我们目标用户的特征，于是，立马找过去“推销”这个系统。结果，就因为这次交流，碰撞出了后来一个新的典型场景：IoT 0-day在野攻击分析。

这位同事研发了一个在业界颇有知名度的IoT蜜罐产品Anglerfish，并捕获到了网络空间中多个攻击的payload。而他的困惑是，虽然捕获了一些看起来很有意思的攻击payload，甚至有些怀疑是0-day攻击漏洞，但一直没有好的办法和精力去逐一分析，因此试着让我们帮帮看。

在这个场景里，要分析蜜罐捕获的0-day攻击线索，有一个难点，就是只从payload里分析时，能得到的信息很有限，无非就是攻击者利用了什么组件的漏洞，比如，某cgi文件的命令注入漏洞。

至于该组件背后，到底属于哪个设备，不知道，公开网络也很难搜索到。因为这是要从固件内部解析提取后才能得到信息，类似于Google等搜索引擎，只会索引类似html等文本类的网页数据，根本不会去下载一堆固件并且逐个去解密、解压提取数据。因此，线索追踪往往至此就没了下文，只知道”有攻击发生了”，但不知道”攻击什么厂商的什么设备”。也很难确定”是不是0-day攻击”，因为无从得知”在该设备最新版本下，是否依然存在该漏洞”。

至此，我们非常兴奋，因为解决这些问题，正是我们的强项，也是其他搜索引擎、安全工具无法提供的。属于”只有我们才有的”分析能力。由此，开启了FirmwareTotal新篇章：”在服务于IoT 0-day在野漏洞追踪分析的过程中，不断改进产品，以提高用户分析效率”。

在实际的协作分析过程，我们很快就发现了初版产品存在许多问题，比如：
•搜索能力太弱，能搜索的维度太少
•搜索结果太粗略，有大量的相关信息需要临时手动去写sql、写脚本进行分析，并且难以复用
•搜索到结果后，交互就终止了，但是往往还需要进行二次过滤筛选和搜索
•需要对搜索结果进行灵活处理，比如选中一部分目标固件进行分析任务，但初版完全不支持
•需要把数据关联起来，做快速的关联分析，而不是割裂开
•……

为此，我们进入了产品的快速迭代期。基本上，每天使用系统分析过程中，都能发现”这里可以再改进一下，那里再调整一下可以更高效”等等。

最后，经过多次迭代、大幅改版后，我们终于发布了全新的2.0版本，和原版对比，有如下明显的不同：
•搜索功能更强大了，可以搜索更多的维度了。关键是可以联合文件、固件等多个不同维度的数据进行关联搜索了！

•搜索结果更丰富了，并且做了非常多的交互优化。比如，可以在不同的维度数据之间互相关联跳转、对搜索结果进行快速二次筛选、帮助用户快速找到可模拟固件进行漏洞验证……

可以看到，在视觉设计上，也有了很大提升，这得益于一位具有设计背景的前端同学加入了团队。他不仅工程能力优秀，在设计方面，帮团队把以前”能用就行”的前端界面，改进成了视觉美观的安全产品。

当然，新同学融入的过程，也因为不懂安全研究员的用户会怎么用，出过一些错误的交互设计。为了解决问题，我做了一些高频的安全案例场景，让他们像用户一样，利用系统，去一步步探索解决问题。从而在这个过程中，亲身体会”用户每天要使用系统来解决类似问题，使用过程中，会遇到哪些低效操作？可以有哪些改进方案？哪种方案更能长期解决问题？”。顺带着也解答了过去的一些需求，填补团队与真实用户间的认知断层。

后来，进行跨维度数据关联过程时，萌生了新想法：”能不能把这个关联过程，进行可视化？”

紧接着，又做了一些新奇的尝试，这些Demo的效果如下图。

只可惜目前我们还没找到非常强需求的场景，来应用图可视化分析。对于搜索结果过多的场景，图可视化分析的性能、可用性、交互模式等，也存在非常大的挑战。不过，这些探索依然很有价值。

比如，做图分析的过程，带来的重要价值之一，是在组合多维数据时，随着代码数据结构与交互复杂度提高，代码变得越来越难以维护。这让我们意识到，需要放慢快速迭代的脚步，对代码进行新的规整和重构，比如利用Typescript等技术，对前端复杂数据处理过程进行规整等等。

另外，关联分析过程提出了对查询性能的更高要求，这也让我们开始着手启动全系统性能改造计划，包括算法优化、服务容器化改造、数据结构优化等。

v3.0：产品打磨

首先，我们对前端的代码进行全盘Typescript重写，以应对代码逻辑和数据结构复杂度增加带来的可维护性降低问题。

随着新的前端同学加入，需要开始考虑多人协作的问题，包括代码规范制定与自动化约束等等。过去，我们更像是一个快速试错、孵化早期产品的小组，而此时，开始逐渐走向正规化的产品研发道路。

•首先是Typescript改造的过程，也对TSLint、Git hook等做了更多的规约

•此外，还增加了单元测试，以及减少70%的冗余代码，让代码整体更简练直观

•这是我们约定的一些基本策略

•还有梳理了当时的项目体系

•随着分发给更多的用户使用，怎么及时收到反馈也成了一个问题。因此，我们也开发了相应的反馈系统来解决，并把反馈组件发布到了公司内部的qnpm仓库中，以期后续可以提供给更多的内部研发业务线使用

•也打磨了用户的一些使用细节，包括快速导出搜索结果、通过订阅自动监控搜索结果变化等

•在后端系统上，我们也做了非常多的升级改造，性能提升了数十倍。

当时面临的问题是，随着数据规模不断增长，数据的处理耗时，成了一个大瓶颈。如果不进行改造，一旦有解析算法改进，需要对所有样本进行重新分析，将需要耗费数个月时间，而这是一个不可接受的处理时长。

因此，我们把后端耗时的分析逻辑解耦出来，分发到数百个docker的K8S集群上进行并行处理，处理时间因此压缩了数百倍。从ElasticSearch监控数据可以看到，当解析任务调度运行时，每天基本都维持在”五十亿读/五千万写”的性能水平上。

至此，利用K8S的快速可伸缩能力，我们实现了以最低成本达到最高效率的分析性能改造。中间还有许多关于分布式改造、消息队列处理等诸多细节，在此不一一赘述。

下图是当时改造后的后端架构图：

下面是当时多维数据关联分析改造后的架构示意图：

v4.0：革新的一代

经过了上一个大版本的长时间打磨，基于用户实际使用中遇到的新问题，我们又开始了筹谋新的大版本。

在这一次中，我们首先要解决的，是新的搜索方式上线后，用户的新要求：要更强大、要更灵活的搜索能力。

举个例子来说，用户在实际使用过程中，需要搜索的维度越来越多，而且不同维度间的组合也越来越多。

为了应对这样的需求变化，一种做法是，像v1.0到v2.0的进化一样，提供越来越多的输入框，形成越来越复杂的表单：

但是，最后权衡，我们选择了另一条路，用最极简的交互方式，提供最灵活最强大的搜索能力，并能cover所有现在及以后的搜索需求变更：

整个系统里，搜索能力就是由一个input构成，非常简洁。但我们对底层数据结构进行了大幅重构，以实现支持灵活Lucene搜索语法。

此后，不管搜索需求如何变化，都可以通过不同搜索语句拼接来实现。

数据的重构，带动了查询性能由原来的平均3~10秒左右，极大缩减为平均每次搜索耗时0.017秒左右，性能提升上百倍。而查询的灵活性带来的效率提升，也是革新性的。

在4.0首次迭代上线后，我们又发现了更多可以继续提升效率的地方。

比如，面对上千个搜索结果时，用户经常需要快速知道各个厂商、型号、CPU类型、文件系统类型、仿真端口等分布情况，才能更快地进行后续问题深入分析。

为此，又快速开发了数据聚合功能：

我们还第一次将固件的仿真系统集成到FirmwareTotal中，这是为了解决漏洞影响面分析”最后一公里”的问题。

所谓漏洞影响面分析”最后一公里”问题，是指在实际使用中，虽然通过漏洞特征匹配到了许多固件，但在漏洞逐一验证前，这些固件只能算是”疑似受影响”，并没有最后实锤。因此分析到这里，仍是不完整的。

为解决该问题，我们把固件仿真系统也集成了进来，支持对搜索结果中的固件执行仿真调度，并提供了强大的调试功能，帮助用户快速验证。

这里有个插曲是，其实固件仿真系统这个产品，已存在较长，但跟FirmwareTotal始终是互相独立，处于无法互相调用的状态。直到我们为仿真系统加上了实时在线调试功能，用户在搜索后，开始有强需求想要仿真和调试，才促使了两个系统逐步开始融合。经历了从一开始系统间互相跳转，快速上线验证产品合理性，到最终在FirmwareTotal里重写仿真系统，将二者融合到一起，并增加了更多独特的能力。

这是对搜索结果内固件进行启动仿真的操作：