P-Verifier：减轻基于云的物联网访问策略中的安全风险

1647本作品采用知识共享署名-非商业性使用-相同方式共享国际4.0许可协议进行许可。P-Verifier：了解和减轻基于云的物联网访问策略中的安全风险泽金中国科学院信息工程研究所;中国科学院大学网络安全学院;印第安纳大学布卢明顿闫家南开大学网络科学学院LuyiXingg卢艺兴印第安纳大学布卢明顿滨源华中科技大学网络科学与工程学院方益伟中国科学院信息工程研究所;中国科学院大学网络安全学院;印第安纳大学布卢明顿刘启旭中国科学院信息工程研究所、中国科学院大学网络安全摘要现代IoT设备制造商正在利用管理平台即服务（PaaS）和云结构即服务（IaaS）IoT云（例如，AWS IoT、Azure IoT），以实现安全便捷的IoT开发/部署。IoT访问控制是通过云特定的、云强制的物联网访问策略（云标准JSON文档，称为物联网策略）实现，哪些用户可以在什么约束下访问哪些IoT设备/资源。在本文中，我们对现代PaaS/IaaS物联网云上基于云的物联网访问策略我们的研究表明，物联网语义的复杂性并且策略的实施逻辑为设备制造商留下了巨大的空间来编程令人敬畏的IoT访问策略，从而引入了复杂的逻辑aws，这些逻辑aws对于推理来说是不平凡的。除了设计领域的挑战/错误之外，令人惊讶的是，主流设备制造商在部署物联网策略时通常也会犯严重错误，这要归功于PaaS/IaaS云的灵活性以及缺乏标准实践。我们对36家设备制造商和310家开放式医疗器械制造商进行了评估物联网项目强调了问题的普遍性和严重性，一旦被利用，可能会对物联网用户的安全性，安全性和隐私产生严重影响为了帮助制造商识别和轻松执行物联网政策aws，我们推出了P-Verier，一个正式的版本，一个可以自动验证基于云的物联网策略的工具。通过评估高效率和低性能开销，P-Verier将为提升现代安全保障做出贡献物联网部署和访问控制。我们负责任地报告了所有已部署或正在向受影响的供应商和xes发送邮件第一作者金泽和邢路一是一位出色的研究者。†通讯作者：邢璐怡，刘启旭CCS©2022版权归所有者/作者所有。ACM ISBN978-1-4503-9450-5/22/11。https://doi.org/10.1145/3548606.3560680CCS概念• 安全和隐私！ 访问控制;·软件及其工程！正式的软件验证。关键词物联网，正式验证，访问控制策略，云。ACM参考格式：Ze Jin，Luyi Xing，Yiwei Fang，Yan Jia，Bin Yuan，and Qixu Liu.2022. P-Verier：了解和减轻基于云的物联网访问策略中的安全风险。 在2022年ACM SIGSAC计算机和通信安全会议（CCS '22）的会议记录中，2022年11月7日至11日，美国加利福尼亚州洛杉矶。ACM，纽约州纽约市，美国，15页。https://doi.org/10。1145/3548606.35606801引言物联网（IoT）云是现代物联网系统所依赖的基础的关键支柱之一较新的物联网设备及其制造商利用研究较少的第三方托管平台即服务（PaaS）和云结构即服务（IaaS）物联网云服务（例如， AWS IoT Core [10]、Azure IoT Hub [21]和Tuya IoT Cloud[44]），其中-将大部分安全责任和部署负担转嫁给公共云提供商。这样的PaaS和/或IaaS物联网云（重新物联网云（本文中称为物联网云）必须信任管理数亿物联网设备和用户，并为设备制造商提供可靠可用的工具，以实现安全的物联网部署。在物联网云系统中，安全性受损或部署不当可能会导致危险和致命的后果。尽管重要，但托管第三方物联网云的安全性尚未完全理解[6，52，58，83]。特别是，必须系统地探索他们的PaaS和IaaS设计是否以及在多大程度上实践有效地帮助设备制造商进行安全的物联网开发和部署，本文将对此进行研究。基于云的访问策略和IoT访问策略。总的来说，访问云中资源的便利性是安全的由开发人员指定的访问控制策略。基于云的访问策略是可以访问什么资源、使用什么动作（例如，读/写/创建），由谁，以及1648·CCS在什么条件下。诸如AWS和Azure之类的云提供商通常使用策略语言（例如， JSON格式，称为跨所有AWS服务的IAM策略[37]），允许开发人员政府访问云中的资源。以AWSIoT为例，基于云的IoT访问策略（或简称IoT Policy）继承了与服务无关的AWS IAM策略的语法，是IAM策略在IoT上下文中的扩展IoT策略种类，用户/客户端可以在什么约束下访问哪些IoT设备/资源，并且可以指定IoT上下文中的动作/资源类型发布MQTT消息-一种来自流行的物联网消息传递协议，见§ 2）。先前的工作[53，54，61，108]研究了基于云的访问策略的错误，特别关注AWS IAM策略[53，54，61]。 与此同时，由于IoT独特的、复杂的语义、语法和约束（参见§ 4），IoT策略引入了新的挑战，并且因此不能被现有的基于云的策略分析工具有效地分析（参见§5.2中的比较）。安全分析和攻击。 为了了解AWS IoT策略的错误空间和实际影响，我们系统地研究了主流设备制造商在AWS IoT上开发的IoT策略。 通过分析36家主流设备制造商的政策设计/实践（例如，Onelink、Belkin、Govee、Netvue）和310开源物联网项目（在GitHub上 [30]），我们的研究揭示了基本的设计挑战和巨大的错误空间，设备制造商制定安全的物联网政策（见下文）。我们发现的设计挑战/aws还强调了PaaS和IaaS物联网云提供商（例如，AWS，Azure）通常无法提供物联网基础设施配备必要的工具，可轻松可靠地帮助制造商确保现代物联网开发和部署的安全。我们的分析由字符串和自动机理论指导[8]，并由P-Verier部分自动化，P-Verier是一种正式的验证工具，用于验证基于云的物联网访问策略（见下文）。关于设计空间的挑战，首先，我们发现物联网上下文和云通用策略语言之间的语义差距（例如， AWS IAM [37]）使得物联网策略的开发非常容易出错（第3.1节）。特别是，AWS范围的策略实施机制可以抽象为自动机模型（字符串的nite状态接受器[47]）：每个策略本质上都有一个字符串接受器B0，给定描述要访问的资源的输入字符串A4B（例如，S3 le路径、IoT设备/主题，参见§2）， A4 B是否被B0，因此允许访问尽管这种通用的增强模型在云计算中已经取得了很长时间的成功，并且，它不能合理地限制物联网资源，其语义比云计算中的普通资源更复杂具体而言，在物联网中，请求中的一个字符串可以引用云中的多个物联网资源;一个物联网资源可以通过多个字符串（第4节）-我们称这样的多个字符串为物联网资源的物联网同义词（或简称IS）在没有对物联网同义词进行彻底的语义分析的情况下，我们发现物联网设备制造商必须合理地指定基于字符串接受器的自动机模型（即，IoT策略），其可以完全拒绝要保护的IoT资源的所有IS 这导致了许多真实供应商的物联网策略中存在严重的过度特权（第3.1节）。此外，我们的研究表明，IAM策略和物联网策略之间的逻辑关系，以及AWS物联网的授权之间的逻辑关系逻辑和Cognito（AWS范围的授权服务）比预期的要复杂得多。实际的复杂性通常无法被现实世界的物联网供应商/开发人员理解和正确处理，导致基于云的物联网访问控制策略开发中的安全关键逻辑漏洞（第3.2节）。 也令人担忧的是主流设备制造商在部署物联网策略时的令人敬畏的做法（§ 3.3）。这些错误是多样的，并且首先要避免，这突出了基于云的物联网策略缺乏标准，充分的安全实践部署.衡量影响。为了了解这些问题的影响和普遍性，我们研究了36家物联网制造商的设备/移动应用程序和来自GitHub的310个基于AWS-IoT的开源项目。13家物联网供应商被确认拥有17个实例物联网政策aws，覆盖至少330万用户。物联网政策在我们发现的310个开源项目中，有172个受到了aws的攻击。攻击的后果（附录表1，在我们的长版在线论文[43]）是严重的，影响安全，安全和隐私。例如，任何用户都可以控制所有t2 Fi用户的智能烤架，存在严重的再/安全危险;任何用户都Biobeat用户血压身高体重和年龄我们向受影响的供应商报告所有问题，并帮助他们解决问题。物联网策略的逻辑编码和自动推理。为了帮助制造商检测物联网策略中的安全漏洞，我们设计并实现了P-Verier，这是一种正式的验证工具，可以有效地验证基于云的物联网访问策略（§ 4）。P-Verier将物联网策略作为输入，并开发正式模型，这些模型使用可满足性模理论（SMT）公式进行编码，我们利用最先进的现成SMT求解器Z3和CVC 4来验证具有一组广义物联网访问属性的公式。 P-Verier报告了表明物联网策略中的安全aws的反例。在这样做的过程中，P-Verier解决了一些基本的、物联网独有的挑战。特别是，检查字符串接受器模型（云通用策略执行模型）是否完全拒绝AC，由于物联网资源的语义复杂性/灵活性，在没有进行彻底的语义分析的情况下就可以访问物联网资源，因此无法推断物联网策略实际允许的权限（§ 4）。为了进行全面的评估，我们引入了物联网策略平台（第5.1节），这是一个新的测试套件（包含403个awed和303个安全的物联网策略），旨在评估物联网策略分析工具。 经过全面评估，P-Verier显示出高效率（零误报/漏报）和低性能开销（参见§ 4.1）。捐款. 这些捐款概述如下：新的理解。 我们对现代PaaS/IaaS物联网云上基于云的物联网访问策略的安全性进行了新的系统研究。我们的研究揭示了物联网政策设计和开发中的安全关键漏洞的新类别，一旦漏洞被利用的严重后果，以及解决问题的根本挑战所吸取的经验教训将有助于在现代基于云的物联网开发/部署基础设施中实现更安全的设计和实践。1649+P-Verifier：理解和减轻安全风险基于云的物联网访问政策CCS连接物联网云连接客户端ID：客户端B订阅标题：DeviceId/cmdPublish标题：DeviceId/statusPublish标题：DeviceId/cmd图2：基于MQTT的IoT通信图1：基于云的物联网通信架构{“Version”：“2012-10-17”，“声明”：[{“效果”：“允许”，“操作”：[• 新技术。基于这种理解，我们开发了一个“iot：连接”]，正式的验证工具P-Verier，可以有效地验证基于云的物联网策略。P-Verier可以帮助物联网制造商自动识别策略aws，提升现代物联网部署的安全保证 我们还推出了IoT策略基准，这是一个旨在评估IoT策略分析工具的基准。 我们开源了P-Verier并发布了IoT政策平台[43]。2基于云的物联网访问控制基础架构基于云的IoT通信架构。基于云的IoT系统通常包括三个组件：IoT云、IoT设备和用于控制设备的用户管理控制台（特别是移动应用），如图1所示。系统的中心是云，其促进/调解设备和应用之间的通信，应用通过云向设备发送控制消息（命令）（例如， 以锁定智能门）并从设备获取信息（例如，传感器值、锁的状态为了保护这种交互，云强制执行由设备制造商指定的安全策略，并决定是否允许用户控制设备或接收来自它的消息。消息传输遥测传输（MQTT）。 MQTT无疑是基于云的IoT通信中最流行的消息传递协议。MQTT利用了经典的订阅模式[2]：客户端将消息发布到服务器托管的命名主题，然后服务器将消息中继到其他客户端，scribed到主题;主题的命名类似于le路径，具有多个/许多级别，由“/"分隔图2说明了通信。首先，客户端（设备或app）与云服务器连接IoT设备订阅其唯一主题（例如，/[DeviceId]/cmd），方法是向服务器发送SUBSCRIBE消息（包括主题名称）服务器维护订阅状态。用户的应用可以通过发布具有命令的开始或停止）到设备订阅的主题此外，设备可以发布消息（例如，传感器值、活动、状态）到用户应用程序订阅的其主题消息可以包括命令或信息文本。客户端可以使用MQTT通配符#（匹配主题中的任何级别）或（匹配一个级别）订阅多个主题。例如，通过订阅主题/a/#，可以接收发布到/a/b，/a/c，.，/a/b/a、/a/b/b等。通过订阅/a/+，可以接收发布到/a/b、/a/c等。“资源”：“客户端/${iot：Connection.Thing.ThingName}”}，{“效果”：“允许”，“操作”：“iot：订阅”，“资源”：[“主题过滤器/a/*”]}，{“效果”：“允许”，“操作”：[“iot：发布”，“iot：接收”]，“资源”：“主题/a/b/*”}]}图3：IoT策略示例AWS IoT政策。AWS上的IoT策略继承AWS IAM策略的语法。IoT Policy是一个JSON文档，其中包含一个或多个策略语句（请参见图3），并应用于原则，以针对原则的请求（对AWS IoT）做出访问决策。每个语句都包含一个元组：（Effect，Action，Resource）。效果为允许或拒绝。默认情况下，拒绝对资源的访问。Allow语句覆盖默认权限，Deny语句覆盖Allow语句授予的权限。也就是说，要获得对资源的访问权，必须有一个允许访问的allow语句，而没有拒绝访问的deny语句。Action构建了与IoT相关的动作，在相应的资源上被允许或拒绝，例如如iot：Publish和iot：Subscribe（或简称为Publish和Subscribe）。Resource构造指定了允许或拒绝访问的IoT资源列表，例如MQTT主题。与任何AWS资源一样，IoT资源是唯一的，并由字符串值标识字符串值可以包括匹配任意数量字符的字符串*IoT策略不包括主体ELD，并由开发者分配给当事人/用户（例如，通过AWS API[18]。当主体/用户向AWS-IoT发出请求时，云会对主体/用户强制执行策略考虑到物联网最终用户的潜在数量巨大，AWSIoT支持/推荐使用带有策略变量的模板式物联网策略，而不是为每个用户创建单独的物联网策略（JSON文档）（图3）。使用这样的IoT策略，当客户端向AWSIoT发出API请求时，变量值会弹出，基于此可 以 做 出 访 问 决 策 。 例 如 ， 在 图 3 中 ， 变 量 ${iot ：Connection.Thing.ThingName}将在运行时由AWS IoT填充为用户唯一的事物名称[14]（类似于用户身份）。此模板功能可以设备物联网云制造商配置IoT策略命令命令IoT设备用户信息信息客户端ID：客户端A订阅标题：DeviceId/statusPublish标题：DeviceId/statusPublish标题：DeviceId/cmd主题DeviceId/cmd设备ID/状态1650CCS帮助设备制造商避免在物联网策略中硬编码特定事物名称，从而为许多/所有用户使用相同的策略3基于云的物联网访问策略为了了解基于云的物联网部署中的错误空间和安全挑战，我们研究了36家主流物联网设备制造商的策略设计和实践（例如，WeMo、Govee、Netvue）利用AWS IoT部署IoT设备我们的系统安全分析揭示了设备制造商的基本、一般turers来规划/部署令人敬畏的物联网策略。为了验证我们发现的弱点，我们购买了12个受影响供应商的真实设备（或使用他们的移动应用程序），并进行了端到端测试。和/或概念验证漏洞。 这些漏洞将允许未经授权的用户在野外控制目标设备，甚至完全控制部署在云下的制造商的所有设备，或偷偷接收私人个人信息（例如，姓名、身份证、行为习惯、日常活动和医疗/健康数据，如血压、体重和身高，见第3.4节中的测量）。我们还彻底检查了310个开源的基于云的物联网GitHub上的项目，其中172个项目具有不同的逻辑级别在他们的IoT政策中。威胁模型我们考虑了现实的攻击和应用场景-iOS. 特别是，攻击者可以在物联网设备制造商和物联网云上开设用户帐户，并能够收集和分析物联网云、物联网设备和其控制下的应用程序另一方面，他不能偷听或干扰其他用户的设备和应用程序的通信他可以阅读物联网云和公共协议规范的公共（非专有）文档我们认为物联网云基础设施和系统是良性的（云、管理控制台、物联网硬件和设备中的rmware）。3.1设计空间缺陷1：物联网访问策略中的语义差距一般来说，AWS上的访问策略（涉及IAM策略和IoT策略两者）对允许和拒绝原则访问的资源集合进行例如，HippokuraX MyNavi（简称Hippokura，一种流行的基于物联网的医疗应用 程 序 ） 的 物 联 网 策 略 规 定 ， 用 户 不 能 订 阅 带 有xmd/session/#的主题。在一个合法的场景中，用户将只订阅一个主题，如xmd/session/[Session ID]，其中主题的最后一部分是她的机密会话ID，只有她自己或预期的用户知道。她可以订阅这样的MQTT主题以接收私有/机密消息，但不能订阅这个主题，否则它会为她订阅所有其他用户AWS的一般策略执行机制是，访问特定资源的请求，由字符串抽象（例如，MQTT 主题xmd/session/#或xmd/session/[一个特定的会话ID]，如果该字符串与策略的allow语句中指定的字符串匹配（特别是，“为了便于推理可能的安全漏洞，我们可以抽象AWS策略作为自动机模型的执行机制（即，字符串的夜间状态接受器）：关于动作类型（例如，订阅者），每个策略拒绝字符串接受器B0，给定描述要访问的特定资源的输入字符串A4 B（例如，MQTT主题），A4B是否被B0接受，因此，无论是否允许访问虽然这样一个通用的执行模型在云计算中一直是可行的，但我们的研究表明，它不能合理地限制物联网资源，这些资源的语义和表达比以前理解的更复杂，对访问控制有严重的影响。特别是，基于字符串接受器的自动机模型在没有彻底的语义分析的情况下拒绝物联网资源的所有同义词是根本性的。也就是说，如果两个输入/字符串共享相同/相似的语义（例如，引用相同的MQTT主题），则自动机B0的定义必须合理，以排除与MQTT主题相关的所有相关同义词（字符串）找出这些同义词依赖于在物联网环境中，不能是云通用的。例如，基于MQTT协议，订 阅 主 题 xmd/# 有 效 地 为 客 户 端 订 阅 了 许 多 主 题 ， 包 括xmd/session/[anystring] 下 的 所 有 主 题 。 在 不 排 除Hippokura策略中的主题xmd/#的情况下（使用deny语句），我们发现恶意用户可以订阅该主题并接收Hippokura下所有其他用户在我们的实验中，泄露给攻击者的消息包括医生对话和与患者相关的个人信息（参见下面的漏洞利用一个政策的困难。对于使用AWS IoT的IoT供应商来说，合理的策略x可以在实践中发挥作用在上面的例子中，策略aw可能会引起供应商的注意，因为正常功能不受影响-用户通常只访问主题xmd/session/[他/她的会话ID]，这是允许的通过策略（allow xmd/session/*，deny xmd/session/#）。此外，为主题xmd/#添加deny语句是不充分的，并且由于用于描述相同IoT资源的高度表达性，灵活的语法，恶意用户可以选择订阅#以实际上订阅所有主题并接收Hippokura下医生/患者的所有消息（请参阅下面的漏洞利用实际上，我们的研究表明，攻击者可以选择订阅xmd/session/+和许多其他物联网同义词，以绕过物联网访问控制（参见第4.1节）。这个问题是普遍的，可能会影响许多物联网设备制造商（参见第3.4节中的测量）和其他物联网云（参见第5节）。如先前的工作[102]所示，泄露的MQTT消息可能是高度隐私和安全敏感的，包括SwitchMate用户或者可以用于推断个人使用习惯。值得注意的是，使用泄漏的设备主题，结合第3.3节中讨论的aw，我们发现恶意用户可以随时控制（打开/关闭）任何SwitchMate开关（第3.4节）。此外，我们发现Govee智能插头的策略（图4）合理地避免了上述问题，但实际上并没有做到。该策略旨在拒绝订阅使用MQTT通配符（#，+）的主题，仅允许订阅特定的已知MQTT主题-格式为GD/[设备ID的MD5]。因此，不能订阅GD/#或GD/+用于订阅所有/许多用户但我们的1651（（允许，action：iot：Subscribe，resource：*），（否认，action：iot：Subscribe，resource：（*+，*#）P-Verifier：理解和减轻安全风险基于云的物联网访问政策CCS一项研究（详见第3.4节的测量）表明，这样的政策虽然可能是精心制定的，但经过更彻底的推理（参见第4节中的工具）后仍然是不合理和不安全的：通配符的使用是不完整的，恶意的Govee用户仍然订阅主题+/（并相应地订阅Govee的多个主题，如LWT/，详细信息见我们在线长篇论文的附录§ .1 [43]）。值得注意的是，由于潜在的巨大用户数量，设备制造商为每个单独的IoT用户创建/维护单独的策略可能非常麻烦，因此，设备制造商通常会开发统一的IoT策略-也是AWS IoT [17]推荐/支持的-并将其应用于许多用户. 例如，Hippokura的策略需要允许支持许多用户（允许xmd/session/* ） ， 因 此 应 该 排 除 / 拒 绝 某 些 通 配 符 主 题（xmd/session/#），否则这些主题可以订阅其他用户的主题。利用。针对以上问题，我们使用SwitchMate和Govee的实际设备以及Hippokura的应用程序进行了仿真实验我们开发了一个脚 本 来 连 接 他 们 在 AWS IoT 上 aqm3wd1qlc3dy-ats.iot.us-east-1.amazonaws.com a7zl8evrsaz7q-ats.iot.us-east-1.amazonaws.com的公共端点（分别为www.example.com、www.example.com和a2qare 4ca 4-lmz2-ats.iot.ap-northeast-1.amazonaws.com），就像他们的移动应用程序一样。我们使用自己的帐户凭据（通过对应用程序进行逆向工程获得）来验证连接。我们的脚本可以在尝试订阅预定的主题，就像真正的攻击者可以做的那样我们确认上述主题的订阅可以成功，并立即停止连接，不会对其他方造成影响（参见第3.4节中的IRB批准、负责任的实验设计和供应商确认）。我们向供应商报告了所有的情况，讨论了可能的后果，并帮助他们x的问题，这是承认，厂商图4：Govee插头的物联网策略3.2设计空间缺陷2：IAM政策和物联网政策之间的合作有缺陷除了执行策略的挑战（缺陷1）之外，我们的研究表明，物联网策略和AWS通用IAM策略之间高度耦合但模糊的关系使得制定合理的物联网访问策略更具挑战性，并具有严重的现实影响。AWS IoT直接利用其他两项AWS服务，即： Cognito和IAM，帮助进行身份验证和授权。如图6所示，物联网用户/应用程序登录AWS Cognito;根据设备制造商在身份池（图6）中已经记录的用户身份（称为Cognito身份ID），Cog- nito向用户/客户端返回Cognito凭据（秘密字符串，如aws_access_key_id=ASIAR 4 BOIXWCSZG 53 UU 5），至as2A43_0DC43. 如AWS所定义的，由制造商创建的身份池（在池中具有许多/多个身份）与一个（或多个）IAM策略（例如，图6中的iam_p1）。 生成2A43_0DC430的用户/客户端可以进行API请求任何AWS服务（例如，AWS IoT、S3、DynamoDB）。 在接收到 请 求 时 ， 目 标 AWS 服 务 （ 例 如 ， WSIOT ， S3 ） 基 于2A43_0C104_3 查询Cognito，以获得用户的Cognito身份和相关联的并根据IAM策略中特定于服务的语句，通过确定特定操作是否在 请 求 中 （ 例 如 ， s3： ListBucket ， iot ： Publish ， iot ：AttachPolicy）。有趣的是，与常见的AWS服务（例如，S3）仅使用IAM策略来授权API请求，AWS IoT还需要与客户端关联的IoT策略。特别是，其关联的IAM策略允许“iot：AttachPolicy”操作的客户端/原则可以通过调用AWS IoT API attach_policy [18]将给定的IoT策略附加到给定的Cognito身份。建模IAM策略和IoT策略之间的逻辑关系。我们观察到，与客户端/原则相关联的IAM策略和IoT策略都可以指定其允许的IoT动作（例如，iot：订阅，iot：发布）和IoT资源（例如，MQTT主题）。 尽管没有详细记录，但我们观察到客户端的IAM策略和IoT策略之间的一些逻辑关系：（1）客户端必须具有许可的IAM策略才能连接到AWS IoT/使用AWS IoT发出API请求-IAM策略应允许IoT相 关 操 作 （ 与 其 他 AWS 服 务 的 操 作 相 反 ） ， 例 如 iot ：AttachPolicy和iot：Subscribe。AWS IoT的这种要求可能来自所有AWS服务，这些服务通常依赖AWS范围的IAM策略评估引擎来确定AWS服务（即，AWS IoT）应该处理API请求[61]。(2) 对于要控制IoT设备/与IoT设备交互的客户端（通过向AWSIoT发出请求，请参见图6），特定的IoT操作（例如，iot：Publish，iot：Subscribe）[16]和目标资源必须在物联网政策中允许。(3)默认情况下，空IoT策略与客户端相关联，从而使与IoT设备控制/交互相关的IAM策略中的任何允许的 动 作 和 资 源 无 效 （ 例 如 ， iot ： Publish ， iot ：Subscribe）-“故障安全默认”的安全原则[ 29 ]。为了对IAM和IoT策略之间的逻辑关系进行建模和更好的推理，我们将IAM策略允许的IoT相关权限（概念上意味着允许的IoT操作，如iot：Subscribe和资源，如MQTT主题）抽象为%80<，将I oT策略允许的所有权限抽象为%8>C。客户端2的有效IoT相关许可是%2=%80\%8>C（1）简而言之，从设备制造商事实上，根据我们对36家物联网供应商和310个开源GitHub项目的研究，我们发现物联网供应商/开发人员通常承担上述（或类似的）理解，通过实际为物联网用户制定高度许可的IAM策略（例如，使用iot： * 允许任何IoT API请参阅图5中的策略），同时努力使用受限制的安全IoT策略来实现安全访问控制。1652附AppAWS CognitoAWS IoT登录认证附APIcred_authed请id_authcred_authed物联网政策身份池用户池MQTT经纪人iam_p1App附AWS CognitoAWS IoT未登录的使用cred_unauth的id_unauthcred_unauthMQTT代理身份池iam_p2CCS由于AWS IoT不维护匿名/临时Cognito身份的IoT策略，因此此类属性部分无效图5：一个过于宽松的IAM策略什么逻辑会出错。然而，我们的研究表明，IAM策略和IoT策略之 间的逻 辑关系 ，以及AWS IoT 的授 权逻辑 和Cognito（AWS范围内的授权服务）之间的逻辑关系远比预期的复杂。实际的复杂性通常无法被现实世界的物联网供应商/开发人员理解和正确处理，导致基于云的物联网访问控制策略开发中的安全关键逻辑漏洞。图6：Cognito auth ow图7：Cognito unauth ow具体而言，尽管高度许可的IAM策略可能不会导致安全违规，但如果开发得当，则会得到IoT策略的支持（见等式（1）），我们发现这可能会失败在某些情况下。特别是，AWS允许未经认证的用户（无需登录）仍然使用部分服务，例如，在制造商的自由裁量权下将日志发布到AWS CloudWatch服务器[46]我们发现一个真实的例子是与高端智能空气净化器制造商Molekule合作[4]（由食品和药物管理局批准，用于杀灭细菌和包括冠状病毒在内的病毒[5]）。在登录之前，Molekule移动应用程序获取一个Cognito证书2A43_D=0D证书，表示AWS支持的未经身份验证的Cognito角色（或简称为unauth角色tty83_D=0DCr. 根据Molekule的配置，unauthrole与IAM策略80_p2（参见图7）关联，允许未经认证的用户访问一些IoT相关功能。特别地，80_p2都使用未认证的角色来执行IoT动作iot：AttachPolicy，使得当用户登录（获得认证的身份83_0DC 策略43和证书2A43_0DC 策略43 ）时 ， 客 户 端 通 过 执 行 2A43_D=0DC 策 略 来 调 用 IoT APIiot ：AttachPolicy 以 将 IoT 策 略 附 加 到 认 证 的 身 份 。 然 后 ，Molekule 应 用 程 序 将 利 用 认 证 的 身 份 / 证 书 （ 83_0DC43 ，2A43_0DC43）向AWS IoT发出API请求[20]以控制/操作设备。在这种复杂的策略实践背后，我们发现，管理者力求简单，并将IAM策略设置为80_p2(forunauth角色，参见图7）是高度许可的（例如，允许在多个资源上的多个IoT动作），依赖于默认iot：Publish，iot：Subscribe）到AWS IoT。我们发现（甚至不维护空策略，请参见设计原理- low）。因此，未经认证的身份的实际权限计算为：%83_D=0DC=%80_p2（ 2）请注意，云在云通用策略（IAM）和物联网策略之间强加了复杂/不明确的关系和合作。我们发现等式（2）反映了真实的授权逻辑，未经认证的身份。这将相应地赋予unauth角色80<_p2中的所有权限，因此，这是一个绝对权限。我们发现，未经认证的Molekule用户可以向任何Molekule设备发送任何IoT命令（例如，iot：Subscribe to topic #以订阅所有用户的设备主题，以及iot：Publishcommandstoanyusers'devicessuchasforturningon/o）。相比之下，受IoT策略限制的经过身份验证的Molekule用户更少的许可。值得注意的是，我们发现AWSIoT不维护匿名/临时 Cognito身份的IoT策略的设计原理是，AWS IoT不管理Cognito身份（这是AWS Cognito服务的责任）：当AWSIoT查询随请求附带的Cognito身份2A43_0DC43时，AWS IoT查询Cognito服务以获取相应的Cognito身份83_0DC43，并使用它来检索/确定Cognito身份。IoT政策。 由于AWS IoT不发布/管理Cognito身份，因此它是否应该为短暂的Cognito身份（例如，一旦临时身份消失，同步删除IoT策略的成本/代价很高）。最后但并非最不重要的是，我们发现这个问题是普遍的，其他主流物联网供应商，如broil-king [25]，sun-pro [42]和BiobeatVitalDisplay [24]都在他们的产品中遇到了同样的问题，允许未经身份验证的用户控制所有其他用户的设备，具有严重的安全性，安全性和隐私影响（参见第3.4节中的测量）。此外，我们还讨论了为什么AWS IoT需要单独的IoT策略，而不是我们在线长版论文中附录§ .2中的IAM策略[43]。利用。我们使用我们的Biobeat和Molekule真实设备进行了模拟实验，并证实了它们都可以解决上述问题。我们逆向设计了IoT供应商，并且在没有登录IoT供应商的移动应用程序的情况下，我们在使用Cognito凭证，我们的脚本可以连接到AWSIoT上的供应商的公共端点，就像他们的应用程序可以做的那样我们的脚本（表示未经身份验证的应用程序用户）可以订阅主题#（我们只根据我们的设备ID筛选与我们自己的设备相关的消息，并删除其余的消息并向“受害者”设备（我们自己的设备）发布任意命令。我们向供应商报告了所有结果，讨论了可能的影响/后果，并帮助他们解决了供应商承认的问题。3.3实施空间缺陷：物联网策略部署的混乱实践上面的缺陷1和缺陷2突出了物联网访问策略的设计空间挑战/aws。此外，我们的研究表明，（（允许，action：iot：*resource：* ））1653P-Verifier：理解和减轻安全风险基于云的物联网访问政策CCS权限之间的关系/约束。例如，两个角色可以被建立为相互排斥的，因此不允许同一个用户承担两个角色[90]。这样的限制有助于实现安全原则人与人之间的关系[96]。有趣的是，在物联网大会上，图8：NetVue的IoT策略的一部分设备制造商在物联网策略部署中使用不同的实践错误。这些错误是多种多样的，非琐碎的，以避免在由于缺乏标准，基于云的物联网策略部署的适当安全实践令人不安。缺陷3：物联网策略模板的困境。基于软件行业中的“DRY”原则（每一条知识必须有一个单一的表示[ 81 ]），开发基于模板的物联网策略（使用策略变量，参见§ 2）以减少样板（每个用户的冗余策略/代码，具有大量的维护负担和更高的意外不一致的然而，我们的研究表明，问题出现了，因为制造商普遍滥用政策变量。例如，NetVue（一种流行的家庭安全摄像头）的IoT策略如图 8 所 示 。 具 有 变 量 ${ThingName} 的 resourceeldcs/${ThingName}将在运行时被填充为特定用户的主题（例如，cs/58412338f7944fb0）。此策略适用于所有NetVue用户，有效/安全地限制用户只能订阅自己的主题。此外，当NetVue cam基于内部转发将消息/状态发布到其设备特定主题（如dc/4047512672901241/control）时，规则（使用AWS IoT规则引擎[39]），消息将被转发给合法用户设备所有者）主题（例如，cs/58412338f7944fb0）。也就是说，安全性是通过物联网策略和制造商提供的转发规则来实现的。我们发现，尽管策略变量的使用减少了为每个用户创建单独策略的负担策略变量的语义和表达能力不足以表达必要的物联网授权要求-这是一个设计限制。特别是，对所有/许多用户使用通用的基于模板的策略，制造商无法表达哪些是特定用户可以访问的设备主题（向其发布消息这是因为AWS策略变量是从API请求者/用户源IP、MQTTClientId、预先注册的事物名称[14]）来标识用户，并且可能由于这个原因，没有策略变量可以用于指定复杂的关系，即，用户的允许设备的列表可以随时间快速改变。因此，我们观察到物联网供应商可能不得不求助于一些功能性工作的变通方法，例如，通常使用一个可编程逻辑器件（例如，dc/*，参见图8中的第3行），以允许用户发布到任何设备主题。我们在与主流物联网供应商NetVue、Govee、Belkin等使用物联网策略模板时观察到了这种不安全的做法。（参见测量§3.4中的完整列表）。 后果是严重的。例如，许可被撤销的前雇员/Airbnb/酒店/客人用户可以操作NetVue摄像头（通过向设备的主题发送命令，参见下文），将其角度调整到360度，因此无法监控所有者预期的空间。缺陷4：物联网政策互斥的约束。可以通过建立以下能力来增强访问控制系统文本，我们的研究表明，在关联“高特权”IoT策略时也需要类似的原则具有IoT设备的“管理员”权限）。我们发现，例如，可以临时物理触摸Switch-Bot设备上的按钮的任何用户都可以与它配对，并被分配相同的因此，例如，前雇员/Airbnb/酒店/客人用户一旦被分配了设备的IoT策略，就可以在设备为其他用户提供服务时完全控制设备。更糟糕的是，我们发现即使新用户重置设备（通过按下设备上和SwitchBot应用程序中的按钮