[论文解读] Decoupled-IFTTT: Constraining Privilege in Trigger-Action Platforms for the Internet of Things

Earlence Fernandes, Amir Rahmati+2 more|arXiv (Cornell University)|Jul 3, 2017

Advanced Malware Detection Techniques参考文献 7被引用 14

一句话总结

本文提出 dIFTTT，一种解耦的触发-动作平台，通过将信任分离至不可信的云服务与用户安装的客户端之间，消除了 OAuth 令牌滥用带来的长期安全风险。它使用针对特定配方的令牌和传输令牌（XTokens），实现细粒度的权限控制，确保即使云服务被攻破，也无法执行未经授权的操作——仅增加 15ms 延迟和 2.5% 的吞吐量开销。

ABSTRACT

Trigger-Action platforms are an emerging class of web-based systems that enable users to create automation rules (or recipes) of the form, "If there is a smoke alarm, then turn off my oven." These platforms stitch together various online services including Internet of Things devices, social networks, and productivity tools by obtaining OAuth tokens on behalf of users. Unfortunately, these platforms also introduce a long-term security risk: If they are compromised, the attacker can misuse the OAuth tokens belonging to millions of users to arbitrarily manipulate their devices and data. In this work, we first quantify the risk users face in the context of If-This-Then-That (IFTTT). We perform the first empirical analysis of the OAuth-based authorization model of IFTTT using semi-automated tools that we built to overcome the challenges of IFTTT's closed source nature and of online service API inconsistencies. We find that 75% of IFTTT's channels, an abstraction of online services, use overprivileged OAuth tokens, increasing risks in the event of a compromise. Even if the OAuth tokens were to be privileged correctly, IFTTT's compromise will not prevent their misuse. Motivated by this empirical analysis, we design and evaluate Decoupled-IFTTT (dIFTTT), the first trigger-action platform where users do not have to give it highly-privileged access to their online services. Our design pushes the notion of fine-grained OAuth tokens to its extreme and ensures that even if the cloud service is controlled by the attacker, it cannot misuse the OAuth tokens to invoke unauthorized actions. Our evaluation establishes that dIFTTT poses modest overhead: it adds less than 15ms of latency to recipe execution time, and reduces throughput by 2.5%.

研究动机与目标

• 量化在 IFTTT 等触发-动作平台中，因过度授权的 OAuth 令牌所引发的安全风险。
• 应对平台被长期攻破所带来的威胁，即攻击者可能滥用用户令牌来控制设备和数据。
• 设计并实现一种解耦架构，将信任从云平台转移至用户控制的客户端。
• 在不增加用户授权提示次数的前提下，实现细粒度的权限强制控制。
• 在真实场景中评估所提方案的性能开销。

提出的方法

• 设计一种解耦架构，将不可信的云服务与用户安装的客户端分离，降低对平台的信任依赖。
• 引入针对特定配方的令牌，将操作与经验证的特定触发器绑定，确保仅授权执行。
• 提出传输令牌（XTokens），实现无需增加用户提示的令牌权限安全委托。
• 实现一个 Python 库，仅需单行注解即可让在线服务开发者轻松集成 dIFTTT 支持。
• 开发半自动工具，反向工程 IFTTT 的 OAuth 范围，并测量 24 个通道中的过度授权情况。
• 通过微基准和宏基准测试，在 2000 个并发触发激活场景下评估 dIFTTT 的延迟和吞吐量。

实验结果

研究问题

• RQ1 IFTTT 通道在 OAuth 令牌范围上过度授权的程度如何？若平台被攻破，其导致的攻击面有多大？
• RQ2 是否可以重新设计一个触发-动作平台，以消除对云平台的长期信任，同时保持可用性和性能？
• RQ3 如何在不增加用户授权提示次数的前提下，实现细粒度的令牌控制？
• RQ4 与 IFTTT 等单体平台相比，安全的解耦架构会带来多大的性能开销？
• RQ5 即使云服务被完全攻破，所提出的针对特定配方的令牌和 XTokens 机制是否仍能防止未经授权的操作？

主要发现

• 在分析的 24 个 IFTTT 通道中，75% 使用了过度授权的 OAuth 令牌，若平台被攻破，将显著增加设备和数据被广泛操控的风险。
• 攻击者若获得 IFTTT 的 OAuth 令牌，可重新编程 Particle 芯片的固件并删除 Google Drive 文件，证明了实际可利用性。
• 在处理 2000 个并发触发激活时，dIFTTT 架构仅增加 15ms 延迟和 2.5% 吞吐量下降。
• dIFTTT 通过将操作与经验证的、针对特定配方的令牌绑定，成功实现了细粒度权限控制，即使在云服务完全被攻破的情况下也能防止未经授权的执行。
• 使用传输令牌（XTokens）可实现安全委托，且与 IFTTT 相比，未增加用户授权提示次数。
• 该方案具有实际可行性和可部署性，如一个 Python 库所示，仅需单行注解即可让在线服务开发者轻松添加 dIFTTT 支持。