PaperlayerView exact revision on arXiv

Source-linked AI summary

Sensitive Information Tracking in Commodity IoT

Z. Berkay Celik, Leonardo Babun, Amit K. Sikder, Hidayet Aksu, Gang Tan, Patrick McDaniel, A. Selcuk Uluagac

arXiv:1802.08307v1cs.CRcs.PL

TL;DR

IoT platforms provide limited visibility into how applications use sensitive information, leaving security and privacy risks difficult to assess. SAINT translates IoT code into an intermediate representation and performs static taint analysis over sensitive sources and sinks. It identifies sensitive flows in SmartThings apps and validates the approach on the IoTBench corpus, while its scope excludes determining whether flows are malicious and does not cover side-channel leaks.

  • Problem

    IoT platforms lack tools for analyzing how applications use sensitive information and identifying privacy-relevant data flows.

  • Method

    SAINT translates IoT app source code into an intermediate representation and statically tracks tainted information from sensitive sources to sinks.

  • Results

    SAINT evaluated 230 SmartThings apps and identified sensitive flows in most market apps, while correctly identifying 25 of 27 unique leaks across 19 IoTBench apps.

  • Takeaways & Limitations

    SAINT provides a framework for identifying potential sensitive-data flows that developers, markets, and consumers can further assess for security and privacy risks.

  • Takeaways & Limitations

    SAINT’s reflective-call handling may over-taint, and two missed IoTBench code sites contained side-channel leaks outside its analysis scope.

Abstract

from arXiv · show

Broadly defined as the Internet of Things (IoT), the growth of commodity devices that integrate physical processes with digital connectivity has had profound effects on society--smart homes, personal monitoring devices, enhanced manufacturing and other IoT apps have changed the way we live, play, and work. Yet extant IoT platforms provide few means of evaluating the use (and potential avenues for misuse) of sensitive information. Thus, consumers and organizations have little information to assess the security and privacy risks these devices present. In this paper, we present SainT, a static taint analysis tool for IoT applications. SainT operates in three phases; (a) translation of platform-specific IoT source code into an intermediate representation (IR), (b) identifying sensitive sources and sinks, and (c) performing static analysis to identify sensitive data flows. We evaluate SainT on 230 SmartThings market apps and find 138 (60%) include sensitive data flows. In addition, we demonstrate SainT on IoTBench, a novel open-source test suite containing 19 apps with 27 unique data leaks. Through this effort, we introduce a rigorously grounded framework for evaluating the use of sensitive information in IoT apps---and therein provide developers, markets, and consumers a means of identifying potential threats to security and privacy.

I. INTRODUCTION

IoT platforms lack effective tools for evaluating how applications use sensitive information, while existing mobile-oriented tracking tools miss IoT-specific sources, sinks, and permission effects. SAINT addresses this gap with static taint analysis and finds sensitive flows across commodity apps and a purpose-built test corpus.

  • Research Gap: IoT platforms largely lack tools for evaluating privacy risks and sensitive data flows in applications.The paper calls for formally grounded analysis methods targeted to IoT platforms.
  • Research Gap: Existing mobile and cross-domain tracking tools may miss IoT-specific sources, sinks, and permission-related effects.Examples include sensor state as a source and network connections as sinks, alongside coarse-grained device permissions.
  • Approach: SAINT translates IoT app source code into an intermediate representation and statically tracks information flow from sensitive sources to external sinks.The tool reports flows involving examples such as device state, user information, Internet connections, and SMS.
  • Evaluation: 230 SmartThings apps were analyzed, including 168 official and 62 third-party apps, with sensitive flows flagged in 92 official and 46 third-party apps.The study also found that half of the apps transmitted at least three sensitive data sources through messaging or the Internet.
  • Evaluation: SAINT identified 25 of 27 unique leaks in 19 IoTBench apps, while two false positives resulted from reflective calls and two missed sites were side-channel leaks.The side-channel leaks were outside SAINT’s analysis scope.
  • Scope: SAINT reports potential sensitive-data flows but does not determine whether a flow is malicious or dangerous in its deployment context.The authors expect discovered flows to be manually investigated for possible rejection or modification of apps.

III. BACKGROUND OF IOT PLATFORMS

IoT platforms organize applications around devices, permissions, events, actions, and application logic, creating common structures for analyzing sensitive information. SAINT uses these shared structures to classify taint sources and sinks and track propagation through event-driven app behavior.

  • Platform Overview: SmartThings combines a hub, apps, and cloud backend, with Groovy apps running in a sandboxed environment.The sandbox restricts developers to a subset of Groovy for performance and security.
  • Platform Overview: SmartThings permissions specify required devices and user inputs, while device capabilities expose actions and events used by app logic.Apps subscribe to events, and event handlers invoke corresponding actions.
  • Common IoT Structure: The three studied platforms share common application structures and taint-source and taint-sink types despite differing communication protocols.The paper uses SmartThings APIs as its most comprehensive source-and-sink list.
  • Taint Sources: User inputs and persisted state variables are treated as sensitive sources because they can contain personally identifiable information or retain behavior-related data across executions.Examples include thermostat settings, notification contact information, and counters tracking door unlocks.
  • Taint Propagation and Sinks: SAINT tracks tainted information from event handlers through copied or computed values and removes taint when traces are replaced by constants.Its initial sink categories include Internet interfaces and messaging services that transmit information externally.

IV. SAINT

SAINT models SmartThings applications through an intermediate representation of permissions, event-driven behavior, and call relationships, then uses that model to analyze application lifecycles.

  • A. From Source Code to IR: SAINT extracts an intermediate representation from IoT application source code to construct entry points, event handlers, and call graphs.
  • A. From Source Code to IR: The framework-agnostic IR contains permissions, event/action associations, and call graphs representing relationships between entry points and functions.
  • A. From Source Code to IR: The sample application unlocks the door and turns on lights when the user arrives, then turns them off, locks the door, and sends an away message after departure.
  • A. From Source Code to IR: Permissions describe accessible devices and user inputs, including a presence sensor, switch, door, contact information, and time-window values.
  • A. From Source Code to IR: Event/action entries associate subscribed device or external events with handler methods, while timers, web requests, touch events, and mode events can also generate actions.
  • A. From Source Code to IR: SAINT creates a separate call graph for each event-handler entry point to represent method relationships within the modeled lifecycle.

B. Static Taint Tracking

SAINT’s static taint-tracking process addresses IoT-specific analysis challenges by extending taint analysis across platform and language features.

  • B. Static Taint Tracking: SAINT combines backward taint tracking with algorithms for state variables, reflection, web-service applications, Groovy-specific operations, and implicit flows.

1) Backward Taint Tracking:

SAINT traces sensitive data backward from sinks through an application’s control-flow graph, then removes infeasible paths and handles IoT- and Groovy-specific behaviors.

  • 1) Backward Taint Tracking:: SAINT first tracks taint backward from sinks in the inter-procedural control-flow graph, then prunes infeasible paths using path- and context-sensitivity.
  • 1) Backward Taint Tracking:: Backward analysis reduces processing overhead by starting from fewer sinks rather than the larger set of sensitive sources.
  • 1) Backward Taint Tracking:: The worklist algorithm starts with sink-call arguments, follows definitions and right-hand-side identifiers, and records their dependence relationships.
  • 1) Backward Taint Tracking:: The example dependence chain yields a possible leak path from the user-input threshold to temperature computation and then to a sink.
  • 1) Backward Taint Tracking:: SAINT discards paths whose branch predicates are jointly false or whose function calls and returns do not match under depth-one call-site sensitivity.
  • 1) Backward Taint Tracking:: To address SmartThings behavior, SAINT tracks state fields sensitively, over-approximates reflective call targets, analyzes web-service callback mappings, and follows platform restrictions on Groovy closures.

3) Implicit Flows:

SAINT also tracks implicit flows by propagating taint through conditional branches when their control predicates depend on sensitive values.

  • 3) Implicit Flows:: SAINT marks all elements in a conditional branch when a sink invocation is control-dependent on a tainted conditional test.
  • 3) Implicit Flows:: The analyzer is implemented with Groovy AST visitors and compiler integration to construct and inspect the application representation.
  • 3) Implicit Flows:: SAINT builds the IR from source rather than Java bytecode because Groovy compilation converts direct calls into reflective calls that hinder Soot analysis.
  • 3) Implicit Flows:: Its output includes complete source-to-sink paths, sensitive-data taint labels, and sink details such as hostnames, URLs, and contact information.

V. APPLICATION STUDY

SAINT was applied to 230 SmartThings apps to characterize sensitive data flows, their sources and sinks, and how recipients and content are specified. The study found widespread sensitive-data transmission, with patterns varying across apps and not closely tracking the number of managed devices.

  • Data Flow Analysis: 138 apps transmitted sensitive data through Internet or messaging sinks, including 92 official and 46 third-party apps.All reported flows were manually verified as true positives.
  • Data Flow Analysis: 71.8% of apps were configured to send SMS or push notifications, and messaging taint sources appeared in 47.2% more apps than Internet taint sources.Only 3.6% of apps included taint sources through both Internet and messaging sinks.
  • Taint Source Analysis: More than half of the apps sent user inputs, device states, and device information, while approximately one-ninth exposed location information or state-variable values.Among data-sending apps, 64 official and 30 third-party apps transmitted multiple kinds of sensitive data.
  • Taint Source Analysis: Sensitive-data complexity varied by app: 48 of 92 official apps sent more than two and at most four kinds of sensitive data, while simpler and more complex device-management tasks showed no fixed pattern.Data flows depended on app functionality rather than simply the number of devices managed.
  • Data Flow Analysis: Approximately 90% of official apps used at most four sink-interface invocations and fewer than three recipients, compared with at most three interfaces and two recipients for third-party apps.Recipients included messaging contacts and Internet hostnames or URL paths.
  • Data Flow Analysis: Users commonly specified messaging recipients, while developers usually specified message contents; SAINT also identified whether recipients and content came from users, developers, or external entities.Official apps specified recipients by users 154 times and message contents by users five times versus developers 149 times.

B. Implicit Flows

Tracking implicit flows adds warnings for conditionally sent hard-coded messages, while producing only six extra warnings because most leaks already have explicit flows. The added tracking overhead remains manageable in these SmartThings apps.

  • Implicit-flow results: Six extra warnings arose when implicit-flow tracking was enabled, and most existing sink calls already leaked through explicit flows.The authors attribute the limited increase to overlap between explicit and implicit leaks.
  • Implicit-flow results: Hard-coded messages such as “Potential intruder detected” can leak information when sent conditionally on sensitive data.The messages themselves contain information, so the authors classify these cases as leaks.
  • Implicit-flow results: Implicit-flow tracking increases identifier-tracking overhead but does not produce an unmanageable number of false positives in SmartThings apps.

C. IoTBench

IOTBENCH is an open repository of malicious SmartThings apps designed to evaluate information-leakage analysis tools using documented ground truth. SAINT exposed limitations on reflective calls and side-channel leaks within this test suite.

  • IoTBench: IOTBENCH contains 19 hand-crafted malicious SmartThings apps with 27 total data leaks through Internet or messaging sinks.Sixteen apps contain one leak, while three contain multiple leaks.
  • IoTBench: Each IOTBENCH app includes source-code ground truth identifying its leaks, enabling accuracy and effectiveness assessment for static and dynamic taint analyzers.
  • IoTBench: SAINT produced false warnings for two reflective-call apps and missed two apps whose leaks used side channels outside its threat model.Reflective calls cause call-graph over-approximation, while side-channel leaks are explicitly out of scope.

VI. LIMITATIONS AND DISCUSSION

The discussion identifies scope and precision limitations in SAINT while positioning it as an initial framework for analyzing sensitive data flows in IoT apps.

  • Analysis limitations: SAINT’s implicit-flow detection is optional, and its generality beyond SmartThings remains unconfirmed.The authors report no over-tainting or false positives from implicit-flow tracking in SmartThings experiments, but call for investigation on other platforms and domains.
  • Analysis limitations: Reflection handling may over-taint because SAINT allows every method as a possible reflective-call target.This imprecise call graph increases the number of analyzed methods; string analysis is proposed to refine reflective targets.
  • Source modeling: SAINT treats all user inputs and state variables as taint sources, although some may not contain sensitive information.The authors state that this source over-approximation did not produce false positives in their experiments.
  • Source modeling: Hard-coded sensitive strings can evade detection unless implicit-flow tracking is enabled.The paper suggests user assistance or language processing may be needed to determine whether hard-coded strings contain sensitive information.
  • Scope: The implementation and evaluation are limited to SmartThings home-automation apps, leaving other IoT domains for future study.The authors identify agriculture, healthcare, and automobile platforms as potential extension targets.

APPENDIX

The appendix documents SAINT’s SmartThings representation, example IoTBench leaks, and the source and sink APIs used in its analysis.

  • SmartThings app example: The appendix presents a Groovy home-automation app and its intermediate representation as an implementation example.The example includes app metadata, device and notification inputs, lifecycle methods, event subscriptions, and handlers.
  • SmartThings app example: The example app responds to presence events by controlling switches and doors, checking time conditions, and sending SMS notifications.Its handlers invoke methods for turning switches on or off, unlocking a door, evaluating time ranges, and reporting door status.
  • IoTBench examples: IoTBench includes example applications illustrating device-state, battery-level, hub-identity, and reflective-call leaks.The examples send data through HTTP, SMS, or notification-related paths, including a reflective call that can disable smoke-detector events.
  • API modeling: The appendix also provides SmartThings taint-source and taint-sink API tables used to identify relevant information flows.The sink list excludes asynchronous HTTP APIs because the analyzed apps did not use them.
  • IoTBench evaluation: Table III summarizes IoTBench ground truth and SAINT results for 19 apps containing 27 sensitive-data leaks.The suite documents leak locations and ground truths in source-code comments.
Loading 1802.08307v1…