请选择 进入手机版 | 继续访问电脑版
 找回密码
 立即注册

QQ登录

只需一步,快速开始

首页 资讯 行业热点 查看内容

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

360企业安全 2020-9-7 18:51

随着科技发展,形形色色的智能家居产品走进千家万户。但是这些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里重写仿真系统,将二者融合到一起,并增加了更多独特的能力。

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

启动后,会进入系统的靶场列表中:

对于启动的每个实例,都可以执行调试,我们已经预置了一些调试工具:

此外,为了提供更多的安全学习环境,我们也上线了漏洞场景,提供多个设备漏洞+仿真验证环境,可以在线进行调试:

此外,还有其他一些好玩的能力,比如支持对搜索结果内的固件和文件,进行批量的分析任务调度,目前支持批量grep二进制、批量curl获取指纹等内置分析能力。

在基础数据方面,也有很大的进展,支持了更多固件解密与仿真的支持、收集了更多固件,实现了提取单文件的大幅增长等等。

后续我们在筹划不只提供更多内置的分析能力,还对外开放分析插件系统。换言之,用户可以自行上传分析插件,利用平台的数据和搜索能力进行高效率的安全分析。

至此,我们完成了革新的4.0版本。但是未来的想象空间依然很大,除了上述规划,后续我们还有其他一些想法,但最终目的只有一个:把能力和价值,让更多的白帽子用户能够用到。

未来:还有哪些问题以及想做的方向

如今回过头来看,FirmwareTotal平台对于IoT安全领域的白帽子用户来说,已经能够帮助他们去提高安全分析效率、提高研究产出。下面是我们过去支撑分析的一些安全事件报告:

在未来,我们想让这种能力,让不只是IoT领域,而是更多领域的白帽子,也能够受用到。

从另一个角度讲,如果不做这件事,未来也很有可能会遇到新的瓶颈,比如用户群体过小的问题。

一个解决办法是,提炼产品模式做衍生发展。

FirmwareTotal这个产品做到最后,其实是提炼出了一种产品模式,”基于软件空间的搜索引擎+虚拟测试环境”,用来完成”从评估疑似影响范围,到最终实锤验证”的完整链路过程。

因此,我们完全可以在这个模式框架里,填充更多领域的数据进来。比如,通过索引安卓软件空间、Linux软件空间的数据,就可以利用这种通用模式,帮助安卓、Linux领域的安全研究员评估漏洞的影响范围,乃至快速获取虚拟环境进行验证等。

写在最后

回顾一路走来,从最初研究院团队,从零逐渐孵化产品,到最后尝试通过商业价值和影响力价值,来证明团队存在价值,期间虽然走了不少弯路,前方也还有很多问题等待解决,但目前已经取得了较好的阶段性成果。

每天都有白帽子用户在使用该产品,进行安全研究,并不断反馈建议。该套系统,不仅帮助内部安全研究员提高安全分析产出,也帮助公司和相关部门获得了商业盈利收入。感谢在FirmwareTotal产品成长过程中所有付出努力的同学。

另外,需要特别感谢热心用户,经常提出一些改进意见。最近,我们也在筹划给这批热心用户,发放一些有意思的纪念品,聊表感激之情。

未来,我们也在规划逐步对外开放,如果你对FirmwareTotal感兴趣,欢迎联系我们:iot-fw-[email protected]

此外,我们也在持续招人中,除了漏洞挖掘、固件分析相关的安全开发岗,也欢迎优秀的前端、后端开发工程师。显而易见的是,FirmwareTotal平台背后,是越来越大的工程项目,每个idea落地到产品里,都需要大量工程去实现。

如果你也想参与这件有意思的事,让技术找到发挥价值的地方,一同探索产品进化之路,欢迎你的加入。简历投递:iot-fw-[email protected]

分享到
文章点评