论文总结了解跨云物联网访问授权中的安全风险

Posted Ohh24

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了论文总结了解跨云物联网访问授权中的安全风险相关的知识,希望对你有一定的参考价值。

介绍

这是一篇来自2020USENIX的论文,作者有Bin Yuan, Yan Jia, Luyi Xing, Dongfang Zhao, XiaoFeng Wang, Deqing Zou, Hai Jin, Yuqing Zhang。

概述

一般情况下,IoT设备在供应商指定的云平台下进行管理,设备和用户也可以通过云来进行连接交互。

目前,一些主流的IoT云平台还支持跨供应商的设备访问管理, 例如Philips和SmartThings云支持委派设备访问另一个云(Google Home),这样用户就可以通过Google Home来管理来自不同供应商的多种设备。

作者发现在缺少标准化的IoT委派协议的情况下,IoT云委派机制存在普遍的安全缺陷。本文系统化的分析了IoT访问授权委派机制的安全性,开发了一个半自动化的验证工具VerioT,结果表明几乎所有的委派机制都存在安全问题,可能会导致设备的未授权访问和设备冒充;为此作者实施了端到端PoC攻击来对这些问题进行确认,并进行了相应的评估。

跨云IoT访问委托

基于云的IoT访问

用户直接通过云访问设备,主要流程:

(1)设备用户将设备注册到云平台(device vendor cloud)上

(2)当用户访问设备时,云端对用户进行认证,然后将其指令发送给指定设备

跨云访问委托

随着设备和供应商的数量急剧增加,为了便于管理,跨云IoT委派机制被提出并实施,来为不同的供应商的多种设备提供一个同一的管理接口,如图1所示。

例如, Google Home想要访问SmartThings云上的一个智能门锁,需要先从SmartThings Cloud上获得一个访问token(例如OAuth),SmartThings需要将访问设备的权限通过OAuth或其他方法分配给Google。

  • 用户登录到Google Home控制台(例如手机应用)
  • 输入她的SmartThings账户凭据
  • 如果通过认证,SmartThings会生成一个access token并将其传递给Google Home

委托链

IoT委派机制的主要流程如下:

  1. )设备注册之后,设备供应商云平台(device vendor cloud)具有对设备的访问权限
  2. )供应商将访问权限分配给delegatee cloud,实现不同云平台对用户设备的控制
  3. )delegatee cloud可以进一步将访问权限分配给其他云,平台上被授权的用户也可以进一步进行权限分配

委托机制

1)OAuth机制

2)自定义授权机制

威胁模型

两类角色:1)管理员administrator:设备拥有者;2)委派用户delegatee user:权限可能会被吊销或到期。

  • 两类角色均能够将设备的访问权限进一步分配给其他用户(delegatee user)
  • 本文假定管理员和IoT云平台是诚实的,而委派用户可能是恶意的
  • 恶意用户能够获取凭证和其他有用信息,例如发出请求、从日志文档中提取信息、捕获流量等
  • 恶意用户无法窃听其他各方之间的通信

跨云物联网委托的安全性

作者分析了10个主流的IoT云的跨云访问授权的安全性,总结了五种缺陷。

Flaw 1: Device ID disclosure

SmartThings想要将设备委派到Google Home上,那么它需要提供OAuth token和设备信息给Google,这些信息会传递给用户来使其控制设备。

  • SmartThings使用设备ID作为触发-响应管理的认证token,设备ID是唯一固定的
  • Google将设备ID公开给具有临时访问权限的用户,存在安全隐患

在Google Home上,如果 Airbnb的管理者将设备的权限赋给一位游客,那么SmartThings的设备ID就会永久暴露。即使之后游客的权限被Google Home撤销,该游客仍然知道设备ID,可能会进行设备事件伪造等攻击。

Flaw 2: Leaking secret of delegatee cloud

在SmartThings上,delegator需要上传一个SmartApp的软件模块到SmartThings平台上,来帮助执行委派协议,管理设备的访问权限。例如,IFTTT云会通过分享一个秘密的URL来实现对设备访问权限的委派,当SmartThings上报一个事件时,会触发IFTTT云上的一个小程序,通过预先指定的规则来控制IFTTT云上的设备,如图3所示。
通过IFTTT SmartApp提供的API,SmartThings用户可以获取秘密URL。该URL是固定的。 在SmartThings上,一旦Airbnb的管理者将设备的权限赋给一位游客,那么IFTTT的秘密URL就会永久暴露,这个游客就可以在之后直接与IFTTT设备进行通信。

Flaw 3: Exposing hidden devices in the delegator cloud

LIFX是一个IoT设备供应商,如果委派SmartThings来管理设备,则SmartThings需要运行LIFX SmartApp。在SmartThings上,可以将用户能够访问的设备定义为一个组,称作location,其中也包含与设备关联的SmartApp,location是SmartThings设备委派的最小单元;如果管理员想要授权某个location的设备,他需要将该location的控制权赋予delegatee user。LIFX SmartApp可以授权用户仅能访问设备的子集。

  • LIFX SmartApp在SmartThings云上没有得到正确的保护,SmartThings上的授权用户可以从要给location的私有存储中读取信息。如图4所示。

Flaw 4: OAuth pitfall

Tuya云采用标准的OAuth协议来委派Google Home对设备进行管理控制:Google Home上的用户输入Tuya凭据,如果检测通过,则Tuya会将其OAuth token转发给Google Home。

  • Tuya云使用的OAuth方案不满足IoT委派机制的可传递性要求。

    Tuya云分发的设备访问OAuth token不代表用户,而代表Google

一个攻击场景: 如果用户在Tuya云上的访问权限被撤销,他仍可以使用其OAuth token通过Google Home来访问设备。

Flaw 5: Abusing cross-cloud delegation API

如图6所示,Philips Hue允许被授权用户通过手机应用访问Philips Hue网桥:

  • 首先按下设备上按钮,开启绑定过程
  • Philips应用通过本地网络从设备自动获取一个秘密token,称作whitelistID
  • 用户登陆其Philips应用来从Philips云端获取OAuth token

有了这两个token,用户就可以通过Philips云来访问Hue网桥。云平台检查OAuth token,然后转发这些命令到设备,由设备检查whitelistID。如果撤销用户的访问权限,管理员只需要在云控制台上删除用户的whitelistID,即删掉设备上的whitelistID,这样用户的命令会被设备拒绝。

Philips云使用一个API接口将设备访问权限授予另一个IoT云,用户在委托云中输入其Philips凭据,然后调用该API,这会返回OAuth token以及由设备生成的新的whitelistID。这样,委托云就可以向Philips Hue云发出命令来操控设备。

  • 在撤销权限时,管理员会删除whitelstID,但委派用户的帐户仍保留在由Philips云维护的设备访问列表中。

一个攻击场景:在权限被撤销后,用户可以重新调用API接口,获得到新的whitelistID和OAuth token,仍然可以访问 Philips Hue网桥。

系统建模和形式验证

作者设计并实现了一个半自动化工具——VerioT,来检查真实世界中IoT云委派机制的缺陷。

VerioT包括3个核心组件:模型生成器model generator,模型检查器model checker和反例分析器counterexample analyzer,如图7所示。

  • 由于不同的云通常支持不同的委派操作,很难构建出可以描述任何形势的模型。因此,作者针对可能发生委派操作的每组特定的真实世界云平台进行建模,并将这些云称为委派设置dele-setting。
  • 模型生成器为每个dele-setting生成模型。以配置文件作为输入,包括dele-setting中的参与者( delegator and delegatee clouds, user, device )和参与者所支持的委派操作。
  • 模型生成器生成的模型会通过模型检查器来进行检测,验证预定义的安全属性。
  • 模型检查器报告一个反例,这代表可以找到一种状态,该状态具有跨系统角色的访问路径,从而使未经授权的用户可以访问设备。

(1)Prevalence of Vulnerable Delegation

测试中的所有云都存在不安全的委派机制。

(2)Scope of Impact

  • IoT clouds affected by Flaw 1

    如上述所示,Google Home公开了其委派云(即SmartThings)的设备ID。未经授权的委派用户可以利用获得的设备ID来模拟设备事件。

    作者手动检查了其他云,发现其中三个将设备ID用作秘密令牌:SmartThings,TP-Link Kasa和elinkSmart,会导致Flaw 1,甚至可以通过触发规则控制其他设备。

  • IoT clouds affected by Flaw 2

    所有授权访问IFTTT的供应商都可能受到影响,作者检查了34个设备供应商会受到影响。

  • IoT clouds affected by Flaw 3

    SmartThings云泄漏了其他delegator云存储在其SmartApp中的凭据。因此,任何在其SmartApp中存储敏感信息/令牌的云都会受到Flaw 3的影响。作者检查了127个授权访问SmartThings的设备供应商的开源应用,发现18个SmartApp存储了敏感信息。

  • IoT clouds affected by Flaw 4

    如前所述,Tuya云的IoT委派机制存在安全风险。作者发现这会影响了至少58个IoT设备供应商,这是由于Tuya云不仅自己制造设备,还向其他没有云的设备制造商提供云服务。

  • Conflicting security policies across clouds

    为了提供跨云委派服务,主流的云平台都要求提供用户设备信息,包括设备ID,名称,型号,版本和类型。但是它们都没有描述其安全性规定:如何处理数据,是否安全敏感等。这表明目前IoT云之间还缺乏统一的安全管理。

App测试方法总结

安全测试

 

一、安全测试

1.软件权限
1)扣费风险:包括短信、拨打电话、连接网络等。
2)隐私泄露风险:包括访问手机信息、访问联系人信息等。
3)对App的输入有效性校验、认证、授权、数据加密等方面进行检测
4)限制/允许使用手机功能接入互联网
5)限制/允许使用手机发送接收信息功能
6)限制或使用本地连接
7)限制/允许使用手机拍照或录音
8)限制/允许使用手机读取用户数据
9)限制/允许使用手机写入用户数据
10)限制/允许应用程序来注册自动启动应用程序
2.安装与卸载安全性
1)应用程序应能正确安装到设备驱动程序上
2)能够在安装设备驱动程序上找到应用程序的相应图标
3)安装路径应能指定
4)没有用户的允许,应用程序不能预先设定自动启动
5)卸载是否安全,其安装进去的文件是否全部卸载
6)卸载用户使用过程中产生的文件是否有提示
7)其修改的配置信息是否复原
8)卸载是否影响其他软件的功能
9)卸载应该移除所有的文件
3.数据安全性
1)当将密码或其它的敏感数据输入到应用程序时,其不会被存储在设备中,同时密码也不会被解码。
2)输入的密码将不以明文形式进行显示。
3)密码、信用卡明细或其他的敏感数据将不被存储在它们预输入的位置上。
4)不同的应用程序的个人身份证或密码长度必须至少在4-8个数字长度之间。
5)当应用程序处理信用卡明细或其它的敏感数据时,不以明文形式将数据写到其他单独的文件或者临时文件中。以防止应用程序异常终止而又没有删除它的临时文件,文件可能遭受入侵者的袭击,然后读取这些数据信息。
6)党建敏感数据输入到应用程序时,其不会被存储在设备中。
7)应用程序应考虑或者虚拟机器产生的用户提示信息或安全警告
8)应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告,更不能在安全警告显示前,利用显示误导信息欺骗用户,应用程序不应该模拟进行安全警告误导用户。
9)在数据删除之前,应用程序应当通知用户或者应用程序提供一个“取消”命令的操作。
10)应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况。
11)当进行读或写用户信息操作时,应用程序将会向用户发送一个操作错误的提示信息。
12)在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任何内容。
13)如果数据库中重要的数据正要被重写,应及时告知用户。
14)能合理的处理出现的错误。
15)意外情况下应提示用户。
4.通讯安全性
1)在运行软件过程中,如果有来电、SMS、蓝牙等通讯或充电时,是否能暂停程序,优先处理通信,并在处理完毕后能正常恢复软件,继续其原来的功能。
2)当创立连接时,应用程序能够处理因为网络连接中断,进而告诉用户连接中断的情况。
3)应能处理通讯延时或中断。
4)应用程序将保持工作到通讯超时,进而给用户一个错误信息指示有链接错误。
5)应能处理网络异常和及时将异常情况通报用户。
6)应用程序关闭网络连接不再使用时应及时关闭,断开。
5.人机接口安全测试
1)返回菜单应总保持可用。
2)命令有优先权顺序。
3)声音的设置不影响使用程序的功能。
4)声音的设置不影响应用程序的功能
5)应用程序必须能够处理不可预知的用户操作,例如错误的操作和同时按下多个键。
二、安装、卸载测试
验证App是否能正确安装、运行、卸载、以及操作过程和操作前后对系统资源的使用情况
1.安装
1)软件安装后是否能够正常运行,安装后的文件夹以及文件是否写到了指定的目录里。
2)软件安装各个选项的组合是否符合概要设计说明。
3)软件安装向导的UI测试
4)安装后没有生成多余的目录结构和文件。
2.卸载
1)测试系统直接卸载程序是否有提示信息。
2)测试卸载后文件是否全部删除所有的安装文件夹。
3)卸载是否支持取消功能,单击取消后软件卸载的情况。
4)系统直接卸载UI测试,是否有卸载状态进度条提示。
三、UI测试
1)测试用户界面(如菜单、对话框、窗口和其他控件)布局、风格是否满足要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。
2)UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
1.导航测试
1)按钮、对话框、列表和窗口等;或在不同的连接页面之间需要导航。
2)是否易于导航,导航是否直观。
3)是否需要搜索引擎。
4)导航帮助是否准确直观。
5)导航与页面结构、菜单、连接页面的风格是否一致。
2.图形测试
1)横向比较,各控件操作方式统一。
2)自适应界面设计,内容根据窗口大小自适应。
3)页面标签风格是否统一。
4)页面是否美观。
5)页面的图片应有其实际意义而要求整体有序美观。
3.内容测试
1)输入框说明文字的内容与系统功能是否一致。
2)文字长度是否加以限制。
3)文字内容是否表意不明。
4)是否有错别字。
5)信息是否为中文显示。
四、功能测试
根据软件说明或用户需求验证App的各个功能实现,采用如下方法实现并评估功能测试过程:
1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景,对比说明或需求,整理出内在、外在及非功能直接相关的需求,构建测试点,并明确测试标准。
2)根据被测功能点的特性列出相应类型的测试用例对其进行覆盖,如:设计输入的地方需要考虑等价、边界、负面、异常、非法、场景回滚、关联测试等测试类型对其进行覆盖。
3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况,及时修正业务或需求理解错误。
1.运行
1)App安装完成后的试运行,可正常打开软件。
2)App打开测试,是否有加载状态进度提示。
3)App页面间的切换是否流畅,逻辑是否正确。
4)注册
  • 同表单编辑页面
  • 用户名密码长度
  • 注册后的提示页面
  • 前台注册页面和后台的管理页面数据是否一致
  • 注册后,在后台管理中页面提示
5)登录
  • 使用合法的用户登录系统
  • 系统是否允许多次非法的登录,是否有次数限制
  • 使用已经登录的账号登录系统是否正确处理
  • 用户名、口令(密码)错误或漏填时能否登陆
  • 删除或修改后的用户,原用户名登陆
  • 不输入用户口令和重复点“确定/取消”按钮,是否允许登录
  • 登陆后,页面中登录信息
  • 页面中有注销按钮
  • 登录超时的处理
2.应用的前后台切换
1)App切换到后台,再回到App,检查是否停留在上一次操作界面。
2)App切换到后台,再回到App,检查功能及应用状态是否正常。
3)App切换到后台,再回到前台时,注意程序是否崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。
4)手机锁屏解锁后进入App注意是否会崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。
5)当App使用过程中有电话进来中断后再切换到App,功能状态是否正常。
6)当杀掉App进城后,再开启App,App能否正常启动。
7)出现必须处理的提示框后,切换到后台,再切换回来,检查提示框是否还存在,有时候会出现应用自动跳过提示框的缺陷。
8)对于有数据交换的页面,每个页面都必须要进行前后台切换、锁屏的测试,这种页面最容易出现崩溃。
3.免登陆
很多应用提供免登陆功能,当应用开启时自动以上一次登录的用户身份来使用App。
1)考虑无网络情况时能否正常进入免登录状态。
2)切换用户登陆后,要校验用户登录信息以及数据内容是否相应更新,确保原用户退出。
3)根据Mtop的现有规则,一个账户只允许登陆一台机器。所以,需要检查一个账户登录多台手机的情况。原手机里的用户需要被退出,给出友好提示。
4)App切换到后台,在切换回前台的校验。
5)切换到后台,再切换回到前台的测试。
6)密码更换后,检查有数据交换时是否进行了有效身份的校验。
7)支持自动登录的应用在进行数据校验时,检查系统是否能自动登录成功并且数据操作无误。
8)检查用户主动退出登录后,下次启动App,应停留在登录界面。
4.离线浏览
很多应用会支持离线浏览,即在本地客户端会缓存一部分数据供用户查看。
1)在无线网络情况可以浏览本地数据。
2)退出App再开启App时能正常浏览。
3)切换到后台再回到前台可以正常浏览。
4)锁屏后再解锁回到应用前台可以正常浏览。
5)在对服务器段的数据有更新时回给予离线的相应提示。
5.App更新
1)当客户端有新版本时,有更新提示。
2)当版本为非强制升级版时,用户可以取消更新,老版本能正常使用。用户在下次启动App时,仍出现更新提示。
3)当版本为强制升级版时,但给出强制更新后用户没有做更新时,退出客户端。下次启动App时,仍出现强制升级提示。
4)当客户端有新版本时,在本地不删除客户端的情况下,直接更新检查是否能正常更新。
5)当客户端有新版本时,在本地不删除客户端的情况下,检查更新后的客户端功能是否是新版本。
6)当客户端有新版本时,在本地不删除客户端的情况下,检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的,也都属于缺陷。
6.定位、照相机服务
1)App有用到相机,定位服务时,需要注意系统版本差异。
2)有用到照相机服务的地方,需要进行前后台的切换测试,检查应用是否正常。
3)测试照相机服务时,需要采用真机进行测试。
7.PUSH测试
1)检查Push消息是否按照指定的业务规则发送。
2)检查不接收推送消息时,用户不会在接收到Push消息。
3)如果用户设置了免打扰的时间段,检查在免打扰时间段内,用户接收不到Push。在非免打扰时间段内,用户能正常收到Push。
4)当Push消息是针对登录用户的时候,需要检查收到的Push与用户身份是否相符,没有错误的将其他人的消息推送过来。一般情况下,只对手机上最后一个登录用户进行消息推送。
5)测试Push时,需要采用真机进行测试。
五、性能测试
1)响应能力测试:测试App中的各类操作是否满足用户响应时间要求。
  • App安装、卸载的响应时间
  • App各类功能性操作的响应时间
2)压力测试,反复/长期操作下,系统资源是否占用异常。
  • App反复进行安装卸载,检查系统资源是否正常
  • 其他功能反复进行操作,检查系统资源是否正常
六、交叉事件测试
针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试,是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干扰的测试。如:App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。
交叉事件测试非常重要,能发现很多应用中潜在的性能问题。
1)多个App同时运行是否影响正常功能。
2)App运行时前/后台切换是否影响正常功能。
3)App运行时拨打/接听电话。
4)App运行时发送/接收信息。
5)App运行时发送/收取邮件。
6)App运行时浏览网络。
7)App运行时使用蓝牙传送/接收数据。
8)App运行时使用相机、计算器等手机自带设备。
七、兼容测试
主要测试内部和外部兼容性
1)与本地及主流App是否兼容
2)与各种设备是否兼容,若有跨系统支持则需要检验是否在个系统下,各种行为是否一致。
  • 不同手机屏幕分标率的兼容性
  • 不同手机品牌的兼容性
八、回归测试
1)Bug修复后且在新版本发布后需要进行回归测试。
2)Bug修复后的回归测试在交付前、要进行大量用例的回归测试。
九、用户体验测试
以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性,提出修改意见提升产品的潜在客户满意度。
1)是否有空数据界面设计,引导用户去执行操作。
2)是否滥用用户引导。
3)是否有不可点击的效果,如:你的按钮此时处于不可用状态,那么一定要灰掉,或者拿掉按钮,否则会给用户误导。
4)菜单层次是否太深。
5)交互流程分支是否太多。
6)相关的选项是否离的很远。
7)一次是否载入太多的数据。
8)界面中按钮可点击范围是否适中。
9)标签页是否跟内容没有从属关系,当切换标签的时候,内容跟着切换。
10)操作应该有主次从属关系。
11)是否定义Back的逻辑。涉及软硬件交互时,Back键应具体定义。
12)是否有横屏模式的设计,应用一般需要支持横屏模式,即自适应设计。
十、手势操作测试
1)手机开锁屏对运行中的App的影响。
2)运行中的App前后台切换的影响。
3)多个运行中的App的切换。
4)App运行时关机。
5)App运行时重启系统。
6)App运行时充电
7)App运行时Kill掉进程再打开
十一、客户端数据库测试
1)一般的增、删、改、查测试。
2)当表不存在时是否能自动创建,当数据库表被删除后能否再自建,数据是否还能自动从服务器中获取回来并保存。
3)在业务需要从服务器端取回数据保存到客户端的时候,客户端能否将数据保存到本地。
4)当业务需要从客户端取数据时,检查客户端数据存在时,App数据是否能自动从客户端数据中取出,还是仍然会从服务器端获取?检查客户端数据不存在时,App数据能否自动从服务器端获取到并保存到服务器端。
5)当业务对数据进行了修改、删除后,客户端和服务器端是否会有相应的更新。

以上是关于论文总结了解跨云物联网访问授权中的安全风险的主要内容,如果未能解决你的问题,请参考以下文章

阿里云物联网平台实现MQTT通信

阿里云物联网平台使用图文教程

阿里云物联网平台使用图文教程

阿里云物联网平台使用图文教程

10.1 阿里云物联网平台介绍

走进阿里云物联网