[論文レビュー] 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

ひとこと要約

本稿では、ユーザーがインストールしたクライアントと信頼できないクラウドサービスの間で信頼を分離することで、OAuthトークン乱用に起因する長期的セキュリティリスクを排除する、分離型トリガー・アクションプラットフォームdIFTTTを提案する。レシピ固有のトークンとトランスファー・トークン（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）を提案すること。
• オンラインサービス開発者がdIFTTT対応を容易に実装できるよう、1行のアノテーションで利用可能なPythonライブラリを実装すること。
• IFTTTのOAuthスコープを逆コンパイルし、24のチャネルにわたる過剰権限の度合いを測定するための、半自動化ツールを構築すること。
• 2000件の同時アクティベーションを想定したマイクロおよびマクロベンチマークを用いて、dIFTTTの遅延とスループットを評価すること。

実験結果

リサーチクエスチョン

• RQ1 IFTTTのチャネルは、どの程度OAuthトークンのスコープで過剰な権限を有しているのか。また、プラットフォームが侵害された場合、その攻撃表面はどの程度に拡大するのか。
• RQ2 信頼の長期的依存を排除しながらも、使いやすさとパフォーマンスを維持できるように、トリガー・アクションプラットフォームを再設計できるか。
• RQ3 ユーザーの承認プロンプトを増加させずに、細粒度のトークン制御をどのように実現できるか。
• RQ4 モノリシックなプラットフォーム（IFTTTなど）と比較して、安全で分離型アーキテクチャが引き起こす性能コストはどの程度か。
• RQ5 レシピ固有のトークンとXTOKsのメカニズムにより、クラウドが完全に侵害された場合でも、不正な操作を防げるか。

主な発見

• 分析対象のIFTTTの24チャネルのうち75%が、過剰な権限を持つOAuthトークンを使用しており、プラットフォームが侵害された場合、広範なデバイスおよびデータ操作のリスクが高まる。
• IFTTTのOAuthトークンにアクセスできる攻撃者は、Particleチップのファームウェアを再プログラムし、Googleドライブのファイルを削除するなど、実世界の攻撃を実行可能であることが示された。
• 2000件の同時トリガー活性化処理において、dIFTTTアーキテクチャはわずか15msの遅延と2.5%のスループット低下しか引き起こさない。
• dIFTTTは、検証済みのレシピ固有トークンにアクションを束縛することで、細粒度の権限制御を成功裏に実現し、クラウドが完全に侵害された場合でも不正実行を防止した。
• トランスファー・トークン（XTokens）の使用により、IFTTTと比較してユーザーの承認プロンプトを増加させずに安全な委譲が可能となった。
• 1行のアノテーションでdIFTTT対応が可能となるPythonライブラリの提供により、実用的かつ導入可能なソリューションであることが示された。