[논문 리뷰] Decoupled-IFTTT: Constraining Privilege in Trigger-Action Platforms for the Internet of Things

Earlence Fernandes, Amir Rahmati외 2명|arXiv (Cornell University)|2017. 07. 03.

Advanced Malware Detection Techniques참고 문헌 7인용 수 14

한 줄 요약

이 논문은 사용자 설치 클라이언트와 신뢰할 수 없는 클라우드 서비스 간의 신뢰를 분리함으로써 오랜 기간 동안의 보안 위험을 제거하는 분리형 트리거-액션 플랫폼인 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 지원을 쉽게 통합할 수 있도록 단일 라인 어노테이션을 제공하는 파이썬 라이브러리 구현.
• 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와 비교해 사용자 인증 프롬프트 수를 늘리지 않으면서도 안전한 위임을 가능하게 한다.
• 단일 라인 어노테이션을 통해 온라인 서비스 개발자가 dIFTTT 지원을 쉽게 추가할 수 있음을 보여주며, 솔루션은 실용적이고 구현 가능하다.