文章分类

小米IoT安全实验室孟卓:IoT安全战地笔记

由 九三 于 2018-12-06 20:08:22 发表

我们带来的第四个重磅内容,来自小米IoT安全实验室孟卓(FengGou)带来的——《IoT安全战地笔记》

小米 IoT 目前已成为全球最大的消费级平台,所以大家都很好奇我们是怎么做的 IoT 安全。是不是每天焊焊串口、扫扫端口、抓抓接口这么简单,用户设备安全保障到不到位?针对这些疑问,孟卓将会为大家讲解小米IoT的安全思路、打法以及我们所付出的实际行动。

0e9595ea38a5a10811576fd8ff7f203e


我一直认为手比脑袋快是不对的,凡事都要先做好充分的思考与计划,方能保证接下来的行动有条理,有效率。所以安全部门在着手安全工作时,应该思考我们所面对的敌人到底是谁?他们会在何种情况下放弃攻击?我整理了很多对手,但最后发现不如古人一句话整理的清晰,我们的对手只有三类人。

第一类人因为恐惧,即对自身安全状况的不信任,比如现在各种个样的IoT设备层出不穷,智能可穿戴设备(手环、手表)、摄像头、智能门锁等等,今年的「小黑盒」事件给用户在智能门锁产品蒙上了一层阴影,无论怎样解释,用户还是抱有惧怕心理。所以永远都会有一种人,他们对智能设备抱怀疑态度,并且会用自己的技术能力去证明这点给制造企业看,并证明给其他用户看。

第二类人为了荣誉,他们初衷并非恶意,并且拥有超出其他个体或团体的技术实力,他们仅想攻破一些有挑战性的产品、设备,来向用户以及行业证明自身的能力,得到大家的认可,获取一定的荣誉感。这种对手会竭尽所能攻击选取的目标。

第三类就是比较复杂的利益群体,一方面来自安全方案提供商,他们为了推销自家的方案会攻破你的系统证明脆弱性,并展示自己方案的可靠性。另一方面就是纯粹的黑产、灰产,会利用你产品的缺陷最大化的谋取自身利益,对于这种对手,如果我们的壁垒足够高,令攻击成本远远高于收益,那就会有效阻止黑灰产的行动。


我们在来看漏洞与威胁的关系,威胁是什么?威胁是一款产品如果存在安全问题会给用户生活带来的最终影响,比如摄像头的威胁是用户家庭生活隐私泄露,智能门锁的威胁是未授权开锁导致的盗窃案件。但漏洞并不会直接导致威胁的产生,他们不是直接的因果关系。来看下威胁成立条件模型。

4e0e87c728bdac19d8b481ff3055dd1a


漏洞的利用首先要突破目前已有的安全防御体系,找到体系中的缺陷,然后还要考虑漏洞利用的风险是否成立。举例某种类型的漏洞,它仅能通过物理拆机方式利用,那这个风险成立就需要攻击者进入用户家里,拆掉用户设备做攻击,这其实是很不现实的。如果风险成立,比如可以互联网远程攻击,那才会根据具体漏洞的影响导致最终的威胁成立。不过小米会考虑设备在各种使用场景下的威胁模型,有一些场景会令物理接触漏洞变得有价值。

比如公寓场所,有安全考虑的智能门锁在门外其实是难以攻破的,但公寓就不同了。比如我进行一次短租,在租期内在门内利用一些锁具内面板上的调试接口对固件进行攻击,写入万能密码,然后退租等下家搬进来,那就可以随便进这个租户的屋子了。还有现在很多电商平台支持7天无理由退货,但退货的时候只是检查包装以及设备上的维修贴是否被破坏,那假如设备存在漏洞,我买来后对设备固件进行篡改,然后申请无理由退货,后面这个设备就会被其他用户买到手,运行我们的恶意流程遭受攻击。所以我们还要比攻击者多想一些,对新型攻击进行预判,提前布防。


在小米安全工作了一段时间,慢慢的发现IoT安全与传统安全的不同之处与安全挑战。个人理解主要有三个方面:

不可信 通过上面的信任边界来分析,智能设备的信任边界非常小,因为你信的越多,所要承担的风险也就越多。所以小米目前对用户家庭网络与设备自身都视为不可信场景。更多的方面可以蔓延到账号系统、物流仓库、第三方配件、维修点等。

不统一 设备从设计之初就开始遇到,比如采用的硬件平台各不相同,通信协议各不相同,加密实现各不相同,安全意识各不相同...所以尽可能的统一硬件模块、通信协议、应用协议、加密标准等,减少开发难度与新的安全风险。

不可控 硬件设备的容错要比网站应用低的多,如果出了漏洞,用户全量更新会非常困难,一旦没有更新漏洞就不好修复(除非有hotfix机制)。还有芯片的故障问题,一旦有问题卖出去的产品很难回收,所有用户都面临故障风险,所以发售前一定要调研测试到位,选取成熟稳定的芯片。还有产品一旦出了自家工厂,被后续供应链怎么折腾也很难控制。

以上都是理论的东西,因为要明确做什么,才知道如何去做。下面我会从安全基线、设计、开发、信息的管控、第三方库以及硬件自身安全这六方面,为大家介绍小米到底是怎么去做设备安全的。


412ff4759e35269b58c669fdbecd3fe1

首先是安全基线,很多设备的基线都是建立在成熟的安全协议上,比如SSL。那如果协议的用法就不对,这个设备最基础的信任关系也就随之崩塌。比如这个案例中使用SSL协议传输一些设备信息,但开发者在初期并不明确上市后通信的具体地址,防止证书验证出错使用了curl的-k参数,也就是--insecure,主动放弃了协议对证书校验的步骤,导致做DNS欺骗中间人,即可拿到HTTPS通信内容。


52103bd73dec8847790b278ba9288b0b

第二个信息暴露的问题,这款产品开启了SSH端口,这是小米IoT安全规范中明令禁止的,但开发者用了一定的技巧实现了「一机一密」,为了说服开发者彻底关闭这个管理端口,我们就需要证明这款设备「一机一密」的重大设计缺陷。首先我们从固件程序逆向分析得到了密码算法,是用deviceID与salt进行哈希后的短位密码,salt被硬编码在二进制程序中可以得到,那deviceID呢?我们知道很多设备都会在非联网情况下在局域网内自发现进行控制活动,这是通过DNS组播实现的,而DNS组播为了标示同款多台设备,会带有设备的识别信息,很不幸这款设备将deviceID作为了识别信息,所以我们可以在局域网内直接抓到DNS组播中的设备ID,最终计算出SSH密码。


6170fecc1e80df80029f930e3dbc8e49

接下来是开发中常见的问题,很多开发者都喜欢用伪随机数方案加固自己的认真或加密机制,这个种子的选择就变成关键,来看一些互联网上常见的技术文章,他们都会推荐采用time(0)时间戳秒数作为种子,尽量接近「真随机」。但这个方案在IoT设备上会有问题。举例来讲,设备默认的时间是什么?设备会联网对时么?设备对时前是不是已经生成了种子?这些种子是不是所有设备都相同?我们遇到过初始时间做种子的情况,还有当前操作时间,这都让随机性变得可预测。还有一种方式,对伪随机出来的数据做逆向爆破,得到原始种子时间戳,这个种子就可能适用于所有此款设备!


91a6ec0eb8174b5ef04fcff6a2075a89

最后是硬件的限制,这个例子不能说是一个漏洞,只能说我们把小米开发者的调试功能逼到了新的高度,小米一直在各个环节逐步提升攻击门槛。这个设备拿到后我们例行拆机接串口进行联动调试,接下来就是这个画面一动不动了,仔细看了下启动参数原来console指向了/dev/null,并且bootdelay设置成了0,没办法用uboot改启动参数重获输出。这时可以利用错误注入这个技巧重获uboot的控制权。首先存储芯片从外观看就是常见的SPI NorFlash,通过查询数据手册找到了它的IO PIN,分别是Pin2和Pin5。利用思路就是在uboot加载kernel镜像的瞬间短接IO,令存储报错抛出异常,中断启动流程。结果可以看到我们成功了,uboot加载kernel失败,给出了提示符:)最后就非常简单了,修改启动参数,console拿shell与恢复tty输出。


上述案例只想表达小米安全团队对每款设备的考量都非常细致,从实际场景角度出发。我们不会做只有「观赏」性质的技术对抗,因为我们最重要的目标就是解决设备最实际的安全风险,让用户免于遭受现实使用环境中遇到的威胁。

目前IoT最可怕也是最实际的攻击手段就是攻击链构造,将各种使用场景、控制端的小问题整合成一套影响巨大的漏洞利用。所以对抗的思路就是以牙还牙,攻击者有攻击链,那我们也有防御链。在设备控制的各个环节(如云端、移动端、通信层、设备端、应用层、账号风控体系等等)上都对安全风险进行控制,对攻击利用形态进行阻断。这样即使在设备存在漏洞的前提下,攻击请求每层都被削弱,到最后已经所剩无几,无法在进行有效的漏洞利用。这个思路有点像净水器的滤芯。


对于最开始提出的这几类对手,小米是怎么面对的呢?很简单,就是「把冷酷的敌人变成冷酷的朋友」。为什么要树那么多敌人呢?跟大家交朋友,满足不同的需求,共同建立安全壁垒岂不是更好?所以小米去年提出了 IoT 安全守护计划,面向设备的安全众测活动。用户担忧什么品类设备的安全问题我们就测什么,之前三期我们分别测试了音响与摄像头等设备,接下来我们还会测试智能门锁。大家用实际行动发现担忧的方面我们积极改善,或者亲手证明设备等坚固可靠。并且发现问题小米还会提供高额的现金奖励与荣誉体现。

这就是小米对待安全的态度,对内务实细致,对外友好开放!

(篇幅问题对内容进行删减,具体请PPT内容)


PPT下载链接:https://cnbj1.fds.api.xiaomi.com/src/xiaomi-IoT-security-conference/IoT%E5%AE%89%E5%85%A8%E7%AB%99%E5%9C%B0%E7%AC%94%E8%AE%B0.pdf