Background
Sensitive
- sensitive=취약한, 민감한
Call by Reflection
- Reflection
- 프로그래밍 언어에서 실행 중인 프로그램의 구조와 동작을 조사하고 수정할 수 있는 능력을 의미하며, 일반적으로 자기 자신의 정보를 조사하고, 수정한다.
- reflection을 사용하면, 실행 중인 클래스, 메소드, 필드 등의 정보를 동적으로 가져올 수 있고, 이를 통해 동적으로 객체를 생성하거나 메소드를 호출하고 속성에 접근할 수 있다. - Call by reflection
- 프로그램이 실행 중에 동적으로 메소드를 호출하는 방식을 의미한다.
- 호출하려는 메소드의 이름과 매개변수, 반환값 등을 조사해서 해당 메소드를 호출하는 것이 가능해진다.
동적으로 메소드 호출
class MyClass:
def method1(self):
print("메소드 1이 호출되었습니다.")
def method2(self):
print("메소드 2가 호출되었습니다.")
# MyClass 인스턴스 생성
my_object = MyClass()
# 동적으로 메소드 호출
method_name = "method1"
getattr(my_object, method_name)() # 메소드 1이 호출되었습니다.
method_name = "method2"
getattr(my_object, method_name)() # 메소드 2가 호출되었습니다.- 호출할 메소드 이름을 저장하고, getattr() 함수로 메소드 호출
- 실행 중에 호출할 메소드를 선택할 수 있음
정적으로 메소드 호출
class MyClass:
def method1(self):
print("메소드 1이 호출되었습니다.")
def method2(self):
print("메소드 2가 호출되었습니다.")
# MyClass 인스턴스 생성
my_object = MyClass()
# 정적으로 메소드 호출
my_object.method1() # 메소드 1이 호출되었습니다.
my_object.method2() # 메소드 2가 호출되었습니다.- 직접 메소드 호출해서, 프로그램 실행 전에 호출할 메소드를 결정해야함.
On-demand Algorithm
- 필요에 따라 즉시 실행되는 알고리즘
- 실시간으로 데이터를 처리하거나, 요청에 대한 즉각적인 응답이 필요한 상황에서 사용됨
정적 오염 분석과 동적 오염 분석의 차이
- 정적 오염 분석
- 특정 시점에서 오염이 발생하는 곳을 파악하고 분석하는 것을 의미한다
- 일반적으로 오염 소스의 위치를 확인하고, 오염이 주변 환경에 어떤 영향을 미치는지 평가하는 데에 중점
- 위치 정보와 오염 소스의 특성을 기반으로, 모델링하고, 에측하는 것을 포함함 - 동적 오염 분석
- 시간적인 변화를 고려해서, 오염이 확산되는 과정을 분석하는 것을 의미한다
- 오염의 이동 경로, 확산 속도, 농도 등을 추적하고, 예측하는 데에 중점
- 모델링과 시뮬레이션 기법을 사용해서 오염의 확산 패턴을 예측하고, 환경에 미치는 영향을 평가하는 데 활용됨
앱의 라이프사이클
- 앱이 생성 > 실행 > 종료 까지의 전반적인 생명주기를 의미
- 앱이 다양한 상태로 전환되는 과정을 나타냄
- 예) 안드로이드 앱의 라이프 사이클
1) 앱이 생성/시작될 때 : 앱은 초기화 작업 수행하고, IoT 디바이스와의 연결 설정
2) 디바이스 연결 및 데이터 수집 : 연결된 디바이스와 통신하여 데이터 주고받음. 디바이스와의 연결 상태 확인하고, 디바이스로부터 센서 데이터 수집
3) 데이터 처리 및 분석 : 수집한 센서 데이터를 기반으로 앱은 데이터 처리 및 분석 작업 수행. 이를 통해 특정한 패턴이나 이상 상태 감지하고, 필요에 따라 경고/알림 발생
4) 사용자 인터페이스 표시 : 사용자에게 수집된 데이터를 가시화하여 제공. 이를 통해 사용자는 실시간으로 디바이스 상태를 모니터링하고, 이를 기반으로 조작/제어 수행
5) 앱 종료/백그라운 동작 : 앱은 연결된 디바이스와의 연결을 유지하거나, 필요한 경우, 데이터 수집과 처리를 계속 수행
Horizontal market study
- 특정 산업이나 수직 시장이 아닌, 여러 다양한 산업이나 업계를 대상으로하는 조사
IR과 Abstract intermediate representation의 차이
- IR : 중간 단계 표현
- abstract intermediate representation은 IR의 한 유형으로, 더 추상화된 형태의 중간 단계 표현이다. 더 고수준의 추상화 수준을 가지며, 소스코드의 세부 구현 내용을 더 추상화하여 표현한다. 이렇게 추상화된 표현은 소스코드의 구조와 동작을 더 쉽게 이해하고 분석할 수 있다.
비동기 HTTP가 taint sink에 미치는 영향
- 비동기 HTTP 요청을 taint sink를 위해 사용한다는 것은, SmartThings 애플리케이션에서 사용자 입력과 같은 오염된 데이터가 보안 취약점으로 흐를 때, 이를 적절하게 처리하고 방지하기 위해 비동기 HTTP 요청을 사용한다.
Dummy main method
- 일반적으로 프로그램 분석이나 변환 작업 중에 사용되는 용어
- 보통은 프로그램의 엔트리 포인트를 대신해서 사용되는 가상의 메인 함수를 의미한다. 이는 분석 도구가 프로그램의 실행 흐름을 추적하고, 분석하기 위해 필요한 경우가 있기 때문에 만들어진다.
- 이렇게 생성된 가상의 메인 함수는 실제로 프로그램이 실행될 때 호출되는 것이 아니라, 분석 도구가 프로그램의 실행 흐름을 이해하고 분석하기 위한 도구적인 장치로 활용된다.
Call graph와 Inter-procedural Control Flow Graph 차이
- 두 그래프 모두 프로그램의 함수 호출 관계를 표현하는 그래프이나, 목적과 관점에서 차이가 있다
- Inter-procedural Control Flow Graph는 call graph의 일종
- Call graph
- 프로그램의 정적인 함수 호출 관계를 표현
- 주로 정적 분석에 사용
- 각 함수의 caller와 callee 간의 관계를 보여준다
- 보통 프로그램의 소스코드나 바이너리를 분석해서 생성됨
- 프로그램의 전체적인 구조를 이해하고, 함수 간의 호출 관계를 파악하는 데 사용 - Inter-procedural Control Flow Graph(ICFG)
- 함수 호출관계+프로그램의 control flow 표현
- 주로 동적 분석에 사용
- 각 함수의 제어 흐름 그래프를 결합해서 전체 프로그램의 제어 흐름을 표현
- 함수간의 호출 관계와 함수 내부에서의 분기, 반복문 등의 control flow 포함
- 보통 프로그램 실행 중 동적으로 생성됨
- 프로그램의 동적 실행 흐름을 이해하고, 제어 흐름에 관련된 분석이나 최적화에 사용
Official app과 third-party 앱의 차이
- iOS 운영체제의 오피셜 앱은 Apple 개발팀이 개발한 앱인데, third-party앱은 플랫폼이나 시스템 제조사가 아닌, 다른 개인/기업/단체가 개발한 앱
- 오피셜 앱은 공식 앱스토어나 앱 마켓에서 다운 받을 수 있는데, third-party 앱은 개발자나 회사가 제공하는 다른 경로를 통해 다운로드하고 설치해야한다
- 오피셜앱은 신뢰성과 보안에 대해 높은 수준으로 보장하지만, third-party 앱은 플랫폼이나 시스템 제조사의 검토를 받지 않아, 검토 과정이 상대적으로 덜 엄격할 수 있다
Depth-one call-site sensitivity
- 프로그램 분석 기법 중 하나
- 호출된 함수의 인자에 대한 분석을 수행하는 방법 정의
- 호출된 함수의 인자에 대해서 분석할 때, 호출하는 위치에서의 인자 값만을 고려하는 기법 (호출하는 위치마다 인자의 값이 다를 수 있기 때문에, 이 방법 사용하면 정확도 향상 가능)
Closure
- 프로그래밍 언어에서 독립적으로 실행가능한 코드 블록이다
- 클로저는 함수와 비슷한 개념이지만, 클로저는 자신이 생성될 때의 환경(context)을 기억하고, 이 환경에 접근할 수 있는 특징이 있다
- 즉, 함수와는 달리 자신이 정의된 범위에 있는 변수에 접근할 수 있으며, 그 상태를 유지하는 특징을 가지고 있다.
- 함수는 매개변수를 통해 값을 전달받아 작업 수행하고 결과 반환하는데에 초점 - SmartThings 앱에서는 사용자가 등록한 다양한 스마트 디바이스들의 목록을 가지고 있다. 이 목록을 반복하면서, 각 디바이스의 상태를 확인하거나 제어하는 작업을 수행할 수 있는데, 이때 클로저를 사용하면 각 디바이스에 대한 작업을 간편하고 효율적으로 처리할 수 있다
- Groovy에서 클로저는 중괄호
{}를 사용하여 정의된다
Compiler Hook
- 컴파일러가 특정 단계에서 호출하는 사용자 정의 코드나 함수를 가리킨다.
- 이는 컴파일러의 동작을 확장하거나 수정하기 위해 사용되는 메커니즘이다.
- 주로 컴파일러 내부 동작에 개입하여 추가적인 처리를 수행하거나 원하는 동작을 변경하는 데 사용된다.
- 컴파일러에 훅을 걸면, 특정한 이벤트가 발생했을 때, 해당 이벤트에 대한 사용자 정의 코드를 실행할 수 있다.
Abstract
IoT(스마트 홈, 개인 모니터링 장치, 향상된 제조 등)은 삶, 놀이 및 업무 방식을 변화시켰다. 그러나, 현재의 IoT 플랫폼은 민감한 정보 사용과 잘못된 사용 가능성을 평가하는 수단이 부족하다. 따라서, 소비자와 기관은 이러한 디바이스가 제시하는 보안 및 개인 정보 보호 위험을 평가할 수 있는 정보가 거의 없다.
이 논문에서는 IoT 애플리케이션을 위한 정적 taint 분석 도구인 SAINT를 제시한다. SAINT는 세가지 단계로 작동한다.
(a) 플랫폼별 IoT 소스 코드를 중간표현(IR)로 변환, (b) 취약한(sensitive) 소스와 싱크 식별, 그리고 (c) 취약한 데이터 흐름을 식별하기 위한 정적 분석 수행
저자는 SAINT를 230개 SmartThings 마켓 앱에서 평가하고, 138개(60%)가 취약한 데이터 흐름을 포함한다는 결과를 얻었다. 또한, IoTBench에서 SAINT를 시연했다. IoTBench는 27개의 유니크한 데이터 누출을 포함한 19개의 앱을 가진 혁신적인 오픈소스 테스트 스위트이다.
이를 통해, 저자는 IoT 앱에서 취약한 정보의 사용을 평가하기 위한 엄격한 기반 프레임워크를 도입하고, 개발자와 시장 그리고 소비자에게 보안 및 개인 정보 보호에 대한 잠재적 위협을 식별할 수 있는 수단을 제공한다.
Introduction
동기
IoT 디바이스들은 우리의 생활 공간을 더 자율적이고 적응력 있으며, 효율적이고 편리하게 해주었으나, 디지털적으로 증강된 공간들의 개인 정보 보호에 대한 우려가 제기됐다.
이런 networked 디바이스들은 취침시간, 문 자물쇠 핀 코드, TV나 다른 미디어에서 무엇을 시청하고, 다른 사람들이 언제 집에 있는지와 같은 매우 개인적인 데이터에 접근할 수 있다. 또한, 기기 자체의 상태 또한 잠재적으로 sensitive한 정보를 나타낸다.
IoT 앱은 허브에 연결된 센서와 기기에서 다양한 민감한 데이터에 노출되어 있는데, 현대 IoT 시스템에서 기존의 상업용 프레임워크가 해당 정보(i.e., application privacy)를 어떻게 다루는지 분석하는 도구와 서비스가 부족하다.
SmartThings, OpenHAB, Apple's HomeKit은 보안 규정을 조절하기 위한 지침과 정책을 제공하고, 관련 시장은 배포 전에 애플리케이션의 내부(수동적) 검증 degree를 제공한다.
그러나, 현재로서는 IoT 구현에서 개인 정보 보호 위험을 평가하기 위한 도구는 대부분 존재하지 않아서, IoT 플랫폼을 대상으로 하는 개인 정보 보호 관련 우려를 식별할 수 있는 분석 도구와 기술의 suite가 필요하다.
이 논문에서는 민감한 데이터의 사용을 특성화하고, IoT 구현에서 취약한 데이터 흐름을 식별하기 위한 공식적으로 기반을 둔 방법과 도구를 탐구하고자 한다.
시스템 구현
본 논문에서는 SAINT라는 IoT 앱을 위한 정적 taint 분석 도구를 제시한다. SAINT는 취약한 소스(e.g., 디바이스 상태(문 잠금/해제), 사용자 정보(집밖/집안))로부터 외부 싱크(e.g., 인터넷 연결, SMS)로의 정보 흐름을 추적함으로써 IoT 앱에서 취약한 데이터 흐름을 발견한다.
우리는 세가지 주요한 기존 IoT 플랫폼(SmartThings, OpenHAB 및 Apple의 HomeKit)에 대한 연구를 수행해서 IoT 특정 소스와 싱크, 그리고 그들의 sensor-computation-actuator 프로그램 구조를 식별한다. 그 후, IoT 앱의 소스코드를 중간 표현(IR)로 번역한다.
SAINT IR은 앱의 라이프사이클을 모델링하며, 프로그램 엔트리 포인트, 사용자 입력, 센서 상태를 포함한다. 여기에서는, IoT 특정 이벤트/액션과 비동기전으로 실행되는 이벤트 뿐만 아니라, call by reflection과 state 변수 사용과 같은 플랫폼별 챌린지를 식별한다.
SAINT는 중간표현(IR)을 사용하여 효율적인 정적 분석을 수행하고, 취약한 소스에서 싱크로의 정보 흐름을 추적한다.
시스템 평가
우리는 SAINT를 평가하는 두가지 연구를 제시한다.
첫번째 평가는, 230개의 SmartThings IoT 앱을 평가한 horizontal(수평적) 시장 연구로, 168개의 마켓 심사를 거친 (공식) 앱과 62개의 심사를 받지 않은 (third-party) 앱을 포함했다.
SAINT는 168개의 공식 앱 중 92개와 62개의 third-party 앱 중 46개를 올바르게 식별하여, 인터넷 또는 메시징 서비스를 통해 최소한 하나의 취약한 데이터를 노출시킨 것을 정확하게 표시했다.
더 나아가, 이 평가는 분석된 앱 중 절반 이상이 메시징이나 인터넷을 통해 적어도 세가지의 다른 취약한 데이터 소스(e.g., 디바이스 정보, 디바이스 상태, 사용자 입력)를 전송한다는 것도 보여주었다.
마찬가지로, 약 2/3의 앱은 최대 두개의 각 취약한 싱크 인터페이스와 수신자(e.g., 인터넷용 원격 호스트 이름 또는 URL 및 메시징용 연락처 정보)를 정의한다.
두번째 평가는, IoT 분석을 검증하기 위한 오픈 소스 애플리케이션 corpus인 IoTBench를 소개한다.
IoTBench에서 SAINT를 분석한 결과, 이는 19개의 앱 중 27개의 유니크한 누출 중, 25개를 올바르게 식별했다. SAINT는 reflective 메서드 호출로 인한 flow over-approximation에서 비롯된 두개의 false positive를 발생시켰다.
게다가, 두개의 누락된 코드 사이트에는 부채널 누출이 포함되어 있었으며, 따라서 이는 SAINT 분석 범위를 벗어난 것이다.
코드 분석은 취약한 데이터의 잠재적인 흐름을 식별하는 데에 중요하다. 사용자가 발견된 취약한 데이터 흐름을 어떻게 처리하는지는 SAINT의 범위를 벗어난다. 실제로, 흐름의 중요성은 매우 contextual하다. 특정 환경을 이해하지 않으면, 흐름의 영향이나 정확성을 추론할 수 없고, 카메라 이미지와 방 온도 또는 TV 채널 노출이 개인 정보 보호에 대한 우려를 나타내는지 여부는 디바이스와 앱이 사용되는 환경과 상황에 완전히 의존한다. 따라서, 우리는 사용자 또는 환경의 보안 및 개인 정보에 잠재적인 영향을 미칠 수 있는 흐름을 식별한다. 데이터 흐름의 원인을 파악하기 위해, 결과를 기록하고 코드를 수동으로 조사할 것으로 예상했다. 데이터 흐름이 도메인이나 환경에 대해 악의적이거나 위험하다고 판단되면, 필요에 따라 앱을 (시장으로부터) 거부하거나, (개발자에 의해) 수정할 수 있다.
Contributions
- SAINT 시스템을 개발해서 IoT 앱에서 상호/내부 데이터 흐름 분석을 활용하여 정보 흐름 추적을 자동화했다.
- 230개의 SmartThings 앱에서 SAINT를 평가하고, 상용 앱에서의 취약한 정보 사용을 드러냈다.
- 19개의 악성 수제 앱의 오픈 소스 저장소인 새로운 오픈 소스 IoT 전용 테스트 corpus IoTBench에서 SAINT를 검증했다.
Problem Scope and Attacker Model
Problem Scope
SAINT의 진행 과정
SAINT는 IoT 앱의 소스코드를 분석하고, taint 소스로부터 취약한 데이터를 식별하고, 취약한 데이터의 소스와 type을 설명하는 taint 라벨을 부착한다. 그 다음, 앱(싱크 e.g., 네트워크 인터페이스) 내에서 라벨링된 데이터(소스 데이터 e.g., 카메라 이미지)가 어떻게 전파되는지 추적하는 정적 taint 분석을 수행한다. 마지막으로, 취약한 데이터가 인터넷이나 일부 메시징 서비스와 같은 taint 싱크에서 앱 밖으로 전송되는 경우를 보고한다. 이 경고에서, SAINT는 taint 라벨에 소스와 외부 URL 또는 전화번호 같은 싱크에 대한 세부 정보를 보고한다.
SAINT는 데이터 유출이 악의적인지 또는 위험한지 여부를 결정하지 않지만, SAINT의 출력은 앱이 기능을 준수하는지 확인하기 위해 추가로 분석될 수 있고, 카메라 이미지가 전송될 때처럼 잠재적인 개인 정보 위험에 대한 정보에 입각한 결정을 내리도록 사용자에게 통지할 수 있다.
SmartThimgs Iot 앱을 평가한 이유
우리는 가장 많은 애플리케이션과 소비자 제품을 보유한 home automation platform에 중점을 두고 있다. 현재 SAINT는 Groovy 프로그래밍 언어로 작성된 SmartThings IoT 앱을 분석하기 위해 설계되었다. 아래 두가지 이유로 SmartThings 플랫폼을 평가했다. 1) 모든 IoT 플랫폼 중 가장 많은 기기(142개)를 지원하며, 다양한 기능의 앱을 제공한다. 2) 상세하고, 공개적으로 제공되는 문서가 있어서, 발견을 검증하는 데 도움이 된다.
다양한 프로그래밍 플랫폼에 쉽게 통합할 수 있는 이유
SAINT는 IoT 프로그래밍 플랫폼의 고도로 구조화된 특성을 활용하고, IoT 앱의 소스코드에서 abstract intermediate 표현을 추출한다. 이로써, SAINT에서 개발한 알고리즘을 다른 프로그래밍 플랫폼에 쉽게 통합할 수 있다. 이 플랫폼은 다양한 프로그래밍 언어나 도메인 특화 언어로 작성된 것들도 포함된다.
Attacker Model
SAINT는 부주의하거나 악의적인 의도로 인한 taint 소스에서 taint 싱크로의 취약한 데이터 흐름을 감지한다. 우리는 사용자가 부여한 권한 또는 권한 없이 민감한 정보를 유출하는 데 사용되는 악성 앱을 사용자에게 제공하는 공격자를 고려한다.
1) 부여된 권한은 앱이 주장한 기능과 다르게 행동하여 사용자의 개인 정보를 침해할 수 있다.
2) IoT 프로그래밍 플랫폼에서 부여된 권한은 정보 유출에 사용될 수 있다. e.g., hub ID나 제조사 이름에 엑세스할 수 있는 권한은 종종 디바이스별 솔루션을 개발하기 위해 기본적으로 부여된다.
저자들의 가정
우리는 공격자가 IoT 플랫폼의 보안 조치를 우회하거나 부채널을 악용할 수 없다고 가정한다.
예를 들어, 조명 강도를 바꿔 집에 누가 있는지에 대한 정보를 유출하는 앱은 이 작업의 범위를 벗어난다.
Background of IoT Platforms
앱의 구조에 대한 통찰력을 얻기 위해, SmartThings IoT 플랫폼의 배경을 제시한다. 또한 두개의 다른 인기 있는 IoT 플랫폼인 OpenHAB와 Apple의 HomeKit에 대해 논의한다. Discussion은 설문조사를 기반으로 하는데, 설문조사는 플랫폼의 공식 문서를 검토하고 예시적인 IoT 앱을 실행하고 앱 구축 로직을 분석하여 수행되었다. 그 후, IoT 앱에서 정보 흐름 추적에서의 챌린지를 제시한다. 마지막으로, API 문서를 연구함으로써, 각각의 잠재적인 유형의 taint 소스와 오염 전파 매커니즘 및 taint 싱크를 정의한다.
Overview of IoT Platforms
SmartThings
SmartThings의 Background
SmartThings는 삼성이 개발한 독자적인 플랫폼이다. 플랫폼에는 허브, 앱 및 클라우드 백엔드의 세가지 구성 요소가 있다. 허브는 연결된 장치, 클라우드 백엔드 및 모바일 앱 간의 통신을 제어한다. 앱은 Kohsuke 샌드박스 환경에서 Groovy(동적이고, 객체 지향적인 언어)로 개발됐다. 샌드박스는 성능과 보안을 위해 개발자들을 Groovy 언어의 특정 부분집합으로 제한한다. 예를 들어, 샌드박스는 앱이 자체적으로 클래스와 스레드를 만드는 것을 금지한다. 클라우드 백엔드는 물리적 장치를 위한 소프트웨어 wrapper를 만들고 앱을 실행한다.
SmartThings의 작동 원리
SmartThings의 권한 시스템은 개발자가 설치 시점에 앱에 필요한 디바이스 및 사용자 입력을 지정할 수 있도록 한다. 사용자 입력은 앱 로직을 구현하기 위해 사용된다. 예를 들어, 사용자 입력은 thermostat의 heating point를 설정하기 위해 사용된다. SmartThings의 디바이스에는 capability(i.e., 권한)가 있다. Capability는 action과 event로 구성된다. 액션들은 디바이스들을 제어하거나 작동시키는 방법을 나타내고, 이벤트들은 디바이스들의 state 정보를 나타낸다. 액션과 이벤트는 일대일이 아니다. 디바이스는 많은 이벤트들을 지원할 수 있지만, 제한된 액션들을 가질 수 있다.
앱은 이벤트 중심이다. 앱은 디바이스 이벤트나 미리 정의된 이벤트(e.g., 아이콘 클릭)에 구속된다. 이벤트가 활성화되면, 대응하는 이벤트 핸들러는 액션들을 취하도록 호출된다.
SmartThings Mobile
사용자는 SmartThings Mobile이라는 스마트폰 컴패니언 앱을 사용해서 두가지 다른 방식으로 SmartThings 앱을 설치할 수 있다.
1) 사용자는 공식 앱 마켓을 통해 앱을 다운로드할 수 있다.
2) 사용자는 웹 IDE를 통해 타사 앱을 독점 클라우드 백엔드에 설치할 수 있다.
정식 시장에 앱을 배포하려면, 개발자가 앱의 소스코드를 제출하고 검토받아야한다. 공식 앱은 2개월 간의 검토 과정을 거쳐서 시장에 등장한다. 사용자는 타사 앱의 소스코드를 개발하거나 설치할 수 있으며, 웹 IDE를 사용하여 자신만이 접근할 수 있도록 할 수 있다. 이러한 앱은 검토 과정이 필요하지 않고, SmartThings 커뮤니티 포럼에서 공유될 수 있다. SmartThings는 다른 경쟁 플랫폼에 비해 더 많은 기기를 지원하고, 공식 앱과 타사 앱을 보유하고 있다.
OpenHAB
OpenHAB은 이클립스 IDE에 내장된 벤더/기술에 구애받지 않는 오픈 소스 자동화 플랫폼이다. home automation을 위해 특별히 설계된 다양한 디바이스가 포함되어 있다. OpenHAB은 오픈 소스이고, 자동화된 작업을 구축하기 위해 유연하고, 커스텀 가능한 디바이스 통합 및 애플리케이션(rules)을 제공한다. SmartThings 플랫폼과 마찬가지로, 환경의 변화에 대응하기 위해 세가지 트리거를 통해 규칙을 구현한다.
1) 이벤트 기반 트리거들은 디바이스들로부터 명령들을 listen한다.
2) 타이밍 기반 트리거들은 특정 시간들(e.g., 자정)에 응답한다.
3) 시스템 기반 트리거들은 특정 시스템 이벤트들(e.g., 시스템 시작/종료)과 함께 실행된다.
규칙(rule)은 Xbase 언어를 기반으로 한 DSL(Domain Specific Language)로 작성되며, 일부 누락된 기능이 있는 Xtend 언어와 유사하다. 사용자는 OpneHAB 앱을 installation의 rule 폴더에 넣고, Eclipse IoT 마켓플레이스에서 설치할 수 있다.
Apple's HomeKit
애플의 홈키트는 호환되는 스마트 디바이스를 관리하고 제어하는 개발 키트이다. 사용자와 기기 간 상호 작용은 Siri와 Homekit 앱을 통해 이뤄진다.
SmartThings와 OpenHAB과 마찬가지로 각 디바이스에는 디바이스가 할 수 있는 것을 나타내는 기능이 있다. 액션은 특정 디바이스에 명령을 전송하도록 정의되며, 트리거는 위치, 디바이스 및 시간 이벤트를 기반으로 액션을 실행하도록 정의된다. 개발자들은 홈킷 호환 디바이스들을 제어하기 위해, 일련의 액션, 트리거, 선택조건들을 지정하기 위한 스크립트를 작성한다. 홈키트에서 개발 중인 애플리케이션은 Swift나 Objective C로 작성할 수 있다. 사용자는 애플에서 제공하는 홈 모바일 앱을 이용하여 홈킷 앱을 설치할 수 있다.
Information Tracking in IoT Apps
정보 흐름 추적(taint tracking)은 정적 또는 동적으로 모바일 앱을 포함한 다양한 설정에 적용되는 잘 연구된 기법이다. 우리는 세가지 IoT 플랫폼에 대한 연구를 통해 IoT 플랫폼과 다른 플랫폼을 비교해봤을 때, 정보 흐름 추적 측면에서 독특한 특성과 챌린지를 가지고 있음을 발견했다.
1) 안드로이드의 경우, IR이 잘 정의되어 있고, 분석가는 IR코드를 직접 분석할 수 있다. 그러나, IoT 프로그래밍 플랫폼은 다양하며, 각각의 프로그래밍 언어를 사용한다. 우리는 IoT 앱의 이벤트 중심 특성을 포착하는 새로운 IR을 제안한다. 이는, 많은 IoT 플랫폼을 수용할 수 있다(섹션 4.1)
2) 모든 taint 추적 시스템은 오염 소스와 오염 싱크 세트로 구성되어야하지만, IoT 앱에서 오염 소스와 싱크를 식별하는 것은 매우 섬세하다. 이들은 각각 내부 상태들에서 다른 세트를 갖는 다양한 세트의 디바이스들에 엑세스하기 때문이다. IoT 플랫폼에서 일반적인 오염 소스와 싱크가 프라이버시 위험을 제기하는 이유를 이해해야한다.(섹션 3.3)
3) 각 IoT 플랫폼은 오염 추적에 어려움을 줄 수 있는 고유한 특성을 갖고 있다. 예를 들어, SmartThings 플랫폼은 앱이 call by reflection을 수행할 수 있도록하고, 웹 서비스 앱이 가능하도록 하는데, 이러한 각각의 기능은 오염 추적을 더욱 어렵게 하고, 특별한 처리를 요구한다.(섹션 4.2)
IoT Application Structure
세가지 IoT 플랫폼에 대한 연구에서, 우리는 그들의 앱이 공통 구조와 일반적인 유형의 오염 소스와 싱크를 공유한다는 것을 발견했다.
이 하위 섹션에서는 이러한 일반적인 오염 소스와 오염 싱크가 프라이버시 위험을 야기하는 이유와 앱 구조에서 민감한 정보가 어떻게 전파되는지 이해하기 위해 설명한다(그림 1). 우리는 부록 C에 SmartThings 플랫폼의 오염 소스와 싱크를 제시한다.
그림 1 - IoT 앱에서, SAINT의 소스와 싱크 카테고리화![[Pasted image 20240205182930.png]]
부록 C - 오염 소스와 오염 싱크 API들
최근 SmartThings는 오염 싱크를 위해 베타 개발 기능으로 사용 가능한 비동기(asynchornous) HTTP 요청을 발표했다. 그러나, 분석된 앱은 비동기 HTTP API를 사용하지 않으므로, 목록에서 제외한다.
우리는 일부 오염 소스 API 사용이 개발자에 의해 할당된 디바이스 이름과 연관되거나, 이를 사용하기 위해 특정 디바이스 기능이 필요하다는 점에 주목한다. 따라서, 앱에 사용되는 오염 소스의 수는 앱의 상황에 따라 다르다.
SmartThings 오염 싱크 API
![[Pasted image 20240205183247.png|350]]
SmartThings 오염 소스 API
![[Pasted image 20240205183330.png]]
Taint Sources
우리는 정보 타입에 따라 오염 소스를 5개의 그룹으로 분류한다
1) Deivce States
디바이스 state는 디바이스의 속성이다.
IoT 앱은 디바이스 state 인터페이스를 통해 프라이버시에 다양한 민감한 정보를 획득할 수 있다. 예를 들어, 도어락 인터페이스는 문의 state를 잠금/잠금 해제 상태로 반환한다.
우리는 사용자의 습관을 프로파일링하고 물리적 프라이버시에 위험을 제기하는 데 사용될 수 있을 만큼으로, 디바이스 상태를 민감하게 오염 소스로 표시했다.
2) Device Information
IoT 앱은 설치 시, IoT 디바이스에 대한 액세스 권한을 부여한다.
우리의 조사에 따르면, 플랫폼은 벤더 이름, ID 및 모델과 같은 디바이스 정보에 액세스하기 위한 인터페이스를 정의한다. 이를 통해, 개발자는 디바이스 별 앱을 작성할 수 있다.
우리는 기기 정보를 획득하는 데 사용되는 모든 인터페이스를 마케팅과 광고에 사용할 수 있을 만큼 민감하게 오염 소스로 표시한다.
디바이스 정보는 정적이며, 앱 실행 과정에서 변경되지 않는다. 이와 달리, 앞서 소개된 디바이스 상태들은 앱 실행 중에 변경될 수 있다. 예를 들어, 앱의 동작은 디바이스의 상태를 변경할 수 있다.
3) Location
IoT 도메인에서 위치 정보는 사용자의 지리적 위치를 의미한다.
지리적 위치는 해당 위치의 디바이스들을 제어하기 위해 사용자에 의해 정의된 차고/사무실 같은 가상 속성을 정의한다. 지리적 위치는 시간대, 경도 및 위도를 통해 앱 로직을 제어하는 데 사용된다. 이 정보는 설치 시점에 사용자의 ZIP 코드를 사용하여 프로그래밍 플랫폼에 의해 제공된다. 예를 들어, 사용자의 위치에 대한 지역적인 일출/일몰 시간은 주택의 창 유리를 제어하기 위해 사용될 수 있다.
위치 정보는 위치 인터페이스를 통해 획득되므로, 이러한 인터페이스를 오염 소스로 표시한다.
4) User Inputs
IoT 앱들은 앱 로직을 관리하거나 디바이스들을 제어하기 위해 사용자 입력들을 요구한다.
간단한 예로, 온도 조절기의 가열점을 설정하기 위해서는 설치 시점에 사용자가 온도값을 입력해야 한다.
사용자 입력들은 디바이스 동작들을 제어하는 predicate을 형성하기 위해 사용된다. 예를 들어, 앱은 사용자에 의해 입력된 특정 시간에 디바이스의 스위츠를 온오프 할 수 있다.
마지막으로, 사용자는 연락처 정보를 입력하여 특정 이벤트 발생 시, 메시징 서비스를 통한 알림을 가능하게 할 수 있다.
이러한 입력은 개인 식별 가능한 데이터를 포함하고 사용자의 행동을 프로파일링하는 데 사용될 수 있으므로, 민감한 입력으로 오염 소스로 표시한다.
섹션 6에서 사용자 입력의 의미론에 대해 더 자세히 논의한다.
5) State Variables
IoT 앱은 이전 실행에 대한 데이터를 저장하지 않는다.
실행들에 걸쳐 데이터를 검색하기 위해, 플랫폼들은 앱들이 일부 사유 외부 저장소에 데이터를 보유하고, 이후 실행들에서 이 데이터를 검색하도록 허용한다.
예를 들어, SmartThings 앱은 문이 몇 번이나 열렸는지 추적하는 '카운터'를 유지할 수 있고, 앱을 실행할 때마다 카운터가 외부 저장소로부터 검색되고, 문이 열렸을 때 증가한다.
이런 변수를 지속적인 데이터 앱 state 변수라고 부른다.
상태 변수는 민감한 데이터를 저장하고, 오염 전파 동안 추적될 필요가 있다(섹션 4.2.2).
Taint Propagation
IoT 앱은 특정 이벤트가 발생할 때 해당 장치를 제어하기 위한 액션을 호출한다. 액션은 이벤트 핸들러에서 호출되고, 디바이스들의 상태를 변경할 수 있다.
예를 들어, 모션 센서가 센서-액티브 이벤트를 트리거할 때, 앱은 조명 스위치의 상태를 오프에서 온으로 변경하는 액션을 취하도록 이벤트 핸들러를 호출할 수 있다. 이것은 액션을 유발하기 위한 간단한 방법이다.
이벤트 핸들러는 디바이스 액션만을 구현하는 것으로 제한되지 않는다. 앱들은 앱 로직을 구현하기 위한 다른 기능들을 호출하고, 메시지들을 송신하고, 디바이스 이벤트들을 외부 데이터베이스에 기록한다. 이벤트 핸들러들가 실행되는 동안, 민감한 정보가 앱의 로직에서 어떻게 전파되는지를 추적할 필요가 있다.
오염 전파의 precision를 얻기 위해, 우리는 오염된 데이터가 복사되거나, 계산에 사용될 때, 이벤트 핸들러에서 시작한다.
오염된 데이터의 모든 흔적이 제거될 때(e.g., 일부 변수에 상수가 로드될 때) 오염을 삭제한다.
이벤트 핸들러와 SAINT의 오염 전파 로직에 대해서는 섹션 4에서 자세히 설명한다.
Taint Sinks
우리의 초기 분석은 두개의 오염된 싱크를 사용한다.(비록 나중에 추가하는 것은 간단한 동작이다)
1) Internet
IoT 앱들은 민감한 데이터를 외부 서비스에 전송하거나, 외부 엔티티들이 민감한 정보를 획득하는 웹 서비스로 작용할 수 있다.
1) HTTP 인터페이스들은 정보를 전송하기 위해 사용될 수 있다. 예를 들어, 앱은 날씨 예측 서비스(e.g., www.weather.com)에 접속하여, 자신의 위치 정보를 전송하여 해당 지역의 날씨를 얻을 수 있다.
2) 웹 서비스 IoT 앱은 외부 엔티티들이 앱에 요청할 수 있도록 하는 URL을 노출할 수 있다. 예를 들어, 원격 서버의 요청을 통해 실내 온도 값을 얻을 수 있다.
SAINT가 웹 서비스 앱의 오염을 추적하는 방법을 섹션 4.2.2에서 자세히 설명한다.
2) Messaging Services
IoT 앱은 모바일 앱 사용자에게 푸시 알림을 전달하고, 특정 이벤트가 발생하면 지정된 수신자에게 SMS 메시지를 전송하기 위해 메시징 API를 사용한다.
우리는 모든 메시징 서비스 인터페이스가 설계에 따라 데이터를 유출하기 때문에, 자연스럽게 싱크를 오염시킨다고 생각한다.
SAINT
SmartThings 앱을 위해 설계/구현된 정적 오염 분석 도구인 SAINT를 제안한다.
그림 2 - SAINT의 아키텍처 개요(workflow)
![[Pasted image 20240205190409.png]]
IoT 앱의 소스코드에서 중간 표현(IR)을 추출하는 SAINT analyzer를 구현했다.
1) IR은 앱의 엔트리 포인트, 이벤트 핸들러와 call graph를 구성하는 데 사용된다(섹션 4.1).
2) 이것들을 이용해서, SAINT는 앱의 라이프사이클을 모델링하고, 정적 오염 분석을 수행한다(섹션 4.2).
3) 마지막으로, 정적 오염 분석을 기반으로 소스에서 싱크로가는 취약한 데이터 흐름을 보고하며, 각 데이터 흐름에 대해 민감한 정보의 유형과 싱크에 대한 정보를 보고한다(섹션 4.3).
From Source Code to IR
앱 라이프사이클 모델링을 위한 첫번째 단계는 앱의 소스코드로부터 IR을 추출하는 것이다.
우리는 섹션 3의 분석을 기반으로, IoT 프로그래밍 플랫폼의 고도로 구조화된 특성을 활용한다. IoT 시스템이 그 목적과 복잡성에 관계없이 일반적으로 유사하게 구성된다는 것을 발견했다. 많이 사용되는 IoT 플랫폼은 주로 sensor-computation-actuator로 앱의 디자인을 구성한다. 따라서, 이러한 구조를 활용해서 IoT 앱의 소스코드를 IR로 변환한다.
SAINT는 IoT 앱의 구성 요소로 구성된 프레임워크에 구애받지 않는 구성요소 모델을 기반으로 IR을 구축한다.(그림 3)
그림 3 - IR의 구성요소![[Pasted image 20240205191124.png]]
기존 IoT 환경에 대한 광범위한 조사는 세가지 유형의 공통 구성 요소를 보여준다
1) 권한은 앱에서 사용되는 디바이스에 기능을 부여한다
2) 이벤트/액션은 이벤트와 액션 사이의 연관성(이벤트가 트리거될 때, 연관된 액션이 수행됨)을 반영한다
3) call graph는 앱에서 엔트리 포인트와 함수 사이의 관계를 나타낸다
IR에는 몇가지 장점이 있다.
1) 위에서 설명한 대로, 앱 라이프사이클을 정확하게 모델링할 수 있다
2) IR은 속성 분석(e.g., 앱 메타 데이터 또는 로깅 코드를 상술한 정의 블록)과 관련 없는 코드의 일부를 추상화하는 데 사용된다.
3) 권한을 해당하는 오염 태그와 연결하고, 어떤 메소드가 엔트리 포인트인지 앎으로써 효과적인 오염 추적을 할 수 있게 해준다.❓
IR 사용을 설명하기 위해 그림 4에 제시된 샘플 앱을 사용한다
그림 4 - 샘플 앱의 IR
![[Pasted image 20240205191900.png|450]]
h1: 사용자가 집에 도착하면 앱이 현관문을 열고 불을 켠다.
h2: 그가 떠날 때, 불을 끄고, 현관문을 잠그고, 지정한 시간을 근거로 그가 부재중이라는 짧은 메시지를 보안 서비스에 보낸다.
부록 A - 예제 앱의 소스코드
섹션 4의 그림 4, 홈 오토메이션 앱의 IR의 Groovy 소스 코드
![[Pasted image 20240206145716.png|350]]
![[Pasted image 20240206145743.png|350]]
Permissions
권한은 사용자가 앱을 설치하거나 업데이트할 때 부여된다. 여기서 다양한 유형의 디바이스와 사용자 입력이 설명되고, 액세스가 허용된다.
권한은 읽기 전용이며, 앱 로직은 권한을 사용하여 구현된다.
SAINT analyzer는 앱의 소스코드를 분석해서 모든 디바이스와 사용자 입력에 대한 권한을 추출한다.
그림 4에 대한 권한
그림 4의 IR을 보면, 권한 블록(line 1-7)은 아래 항목들을 정의한다
1) 디바이스 - 존재 센서, 스위치, 문
2) 사용자 입력 - 알림 메시지 전송을 위한 보안 서비스인 '연락처' 정보와 알림 메시지 전송 여부를 결정하는 데 사용되는 'fromTime'과 'toTime'값
각 권한에 대해 IR은 'input' 키워드를 사용해서 선언한다.
디바이스들의 경우, 첫 두개의 인자는 특정 플랫폼 디바이스 이름의 디바이스 식별자와 매핑되고, 이를 통해 디바이스가 액세스할 수 있는 인터페이스를 결정할 수 있다.
예를 들어, 스위치에 대한 액세스를 허용하는 앱은 theswitchState 객체를 사용해서 'on'/'off' 상태에 액세스할 수 있다❓theSwitches아님?.
사용자 입력의 경우, IR의 각 line에서는, 문자열 이름과 해당 입력의 유형을 포함한다. 즉, 어떤 유형의 정보를 사용자로부터 입력받아서 저장할지를 명시한다.
사용자 입력에 대한 다음 항목은 Taint 태그이다. 이 태그는 정보의 유형을 나타내는데 사용된다. 예를 들어, 사용자가 정의한(user-defined) 태그처럼 정보의 유형을 보여주는 것을 오염태그로 input에 라벨을 붙인다.
따라서, 사용자 입력을 민감한 정보로 간주한다.(섹션 3.3)
권한 블록에는 민감한 데이터가 유출될 수 있는 모든 앱을 위해 설계된 공통 인터페이스 세트도 포함된다. 예를 들어, location.currentMode는 location 모드를 'home'/'away'로 설정한다.
우리는 섹션 3.3-IoT Application Structure에 정의된 오염 태그를 기반으로 각 민감한 값에 라벨을 붙인다.
이러한 방식으로 앱이 액세스할 수 있는 민감한 인터페이스의 전체 목록을 얻는다.
Events/Actions
IoT 앱은 모바일 애플리케이션과 마찬가지로 이벤트 중심의 특성상 주된 method가 없다.
앱은 이벤트에 구속됨으로써 암묵적으로 엔트리 포인트를 정의한다.
IR의 이벤트/액션 블록은 앱이 이벤트에 구속되는 방법을 분석하여 구축된다. 블록 내의 각각의 라인은 세개의 정보를 포함한다. (e.g., subscribe(p, “present”, h1))
1) 디바이스에 사용되는 매핑
2) 구속될 디바이스 이벤트
3) 그 이벤트가 발생할 때 호출될 이벤트 핸들러 메소드
이벤트 핸들러 메소드는 일반적으로 디바이스 액션을 수행하는 데 사용된다.
따라서, 앱은 디바이스 또는 디바이스의 여러개 이벤트에 구속됨으로써 여러개의 엔트리 포인트를 정의할 수 있다.
그림 4에서, 상태가 "present"로 변경되는 이벤트가 h1() 메서드와 연관되고, "not present"로 변경되는 이벤트가 h2() 메서드와 연관된다.
이벤트는 다양한 방법으로 생성된다
또한, 이벤트가 디바이스 이벤트에만 국한되지 않고, 다른 많은 방법으로 생성될 수 있다는 걸 발견했다.
- 타이머 이벤트: 이벤트 핸들러는 특정 시간 내에 또는 미리 정의된 시간에 액션을 취하도록 예약된다.(e.g., 이벤트 핸들러는 지정된 시간이 경과한 후, 또는 일몰과 같은 특정 시간에 액션을 취하도록 호출된다)
- 웹 서비스 이벤트: IoT 프로그래밍 플랫폼들은 앱이 웹을 통해 액세스가능하도록 허용할 수 있다. 이는 외부 엔티티들(e.g., IFTTT(If This Then That))이 앱에 대한 요청을 하고, 엔드 디바이스들에 대한 정보를 얻거나 제어하는 것을 허용한다.
- 앱 터치 이벤트: 사용자가 앱에서 버튼을 클릭할 때 일부 동작을 수행할 수 있다.
- 모드 이벤트: 모드 이벤트는 장치 동작을 자동화하는 액션 필터이다. 예를 들어, "home" 모드에서 실행되는 앱은 알람을 해제하고, "away" 모드로 전환될 때 알람을 활성화한다.
SAINT analyzer는 모든 이벤트 구속을 분석하고, 해당 이벤트 핸들러 메소드를 찾아, 각 엔트리 포인트에 대한 dummy main 메소드를 생성한다.
(이벤트 구속 및 해당 이벤트 핸들러 메소드를 분석하는 과정에서 프로그램의 엔트리 포인트를 명확히 식별하기 위해서 dummy main 메소드 생성)
Asynchronously Executing Events
각각의 이벤트는 고유한 이벤트 핸들러에 대응하지만, 여러개의 이벤트가 동시에 발생할 때, 이벤트 핸들러들의 시퀀스는 미리 결정될 수 없다.
그림 4에서, 다른 이벤트 핸들러 메소드를 호출하기 위해, switch-off 이벤트에 구속된 이벤트/액션 블록 내의 세번째 구속인자가 있을 수 있다.
우리는 최종적으로 일관된 이벤트를 고려하는데, 이는 이벤트 핸들러가 호출될 때마다 다른 이벤트가 처리되기 전에 실행을 완료하고, 엣지 장치(e.g., hub)에 의해 수신되는 순서로 이벤트를 처리한다는 것을 의미한다.
우리는 임의의 순차적 순서로 실행될 수 있는 앱의 이벤트 핸들러를 분석하는 path-sensitive 분석을 기반으로 구현한다. 이는 각 엔트리 포인트로 별도의 call graph를 구성함으로써 가능해진다.
Call Graphs
이벤트 핸들러 방법을 정의하는 각 엔트리 포인트에 대한 call graph를 만든다.
그림 4의 IR을 보면, 두개의 엔트리 포인트 h1()과 h2()(line 12, 16)이 있다. h1()은 x()를 호출하여 door을 unlock하고, 불을 켠다. 엔트리 포인트 h2()는 불을 끄고, 문을 잠근다.
그런 다음, 메소드 y()를 호출하여 메소드 z()를 통해 미리 정의된 연락처에 짧은 메시지를 보낼지 결정한다.
다음 절에서 call by reflection 같은 예를 들어서, call graph를 구성하는 방법에 대해 자세히 설명한다.
Static Taint Tracking
정적 오염 추적은 call graph에서 구현됨
1) 백워드 오염 추적으로 시작 섹션 4.2.1
2) 상태 변수, call by reflection, 웹 서비스 IoT 앱, Groovy 고유 속성과 같은 플랫폼 및 언어별 오염 추적 문제를 해결하는 알고리즘 제시 섹션 4.2.2
3) 정적 오염 추적에서 암묵적 흐름 문제에 대해 논의 섹션 4.2.3
Backward Taint Tracking
앱의 ICFG(Inter-procedural Control Flow Graph)로부터 SAINT의 백트래킹은 다음 두 단계로 구성된다
1) 오염 싱크에서 역방향으로 오염 추적을 수행해서, 소스에서 싱크로 가능한 데이터 누출 경로를 구성한다.
2) path-/context-sensitivity를 사용하여, 실행 불가능한 경로를 프루닝하여 SAINT의 정적 오염 추적의 출력인 실행가능한 경로 세트를 구성한다.
첫 번째 단계에서, SAINT는 ICFG의 싱크에서 시작해서, 역방향으로 오염을 전파한다.
SAINT가 백워드 접근법을 사용하는 이유
SAINT가 백워드 접근법을 사용하는 이유는 엄청난 수의 민감한 소스 대신에 몇개의 싱크에서 시작해서 프로세싱 오버헤드를 줄이기 위함이다.
이는 분석된 IoT 앱에서 소스 대비 싱크의 비율을 확인함으로써 증명된다(섹션 5의 그림 7-오염 소스 분석, 섹션 5의 그림 9-오염 싱크 분석)
그림 7
![[Pasted image 20240206102236.png|450]]
그림 9
![[Pasted image 20240206111359.png|450]]
알고리즘 1은 앱에서 값들이 어떻게 전파되는지를 포착하는 의존 관계를 계산하기 위한 단계들을 보여준다. 이 알고리즘은 작업 리스트 기반(worklist-based) 알고리즘이다.
알고리즘 1 - 오염 싱크로부터의 의존성 계산
![[Pasted image 20240206205844.png|430]]
n: node
작업 리스트는 싱크 콜(호출)의 인자에 사용되는 식별자들로 초기화된다. 동일한 식별자가 여러 위치에서 사용될 수 있기 때문에, 식별자의 사용을 고유하게 식별하기 위해, 식별자는 노드 정보로 라벨링된다(n, id). (식별자는 변수, 함수, 클래스, 모듈 등이 될 수 있음-뇌피셜)
그 후, 작업 목록에서 (n, id)형태의 항목을 가져와서 ICFG에서 id에 대한 정의를 찾고, 정의의 오른쪽에 있는 식별자를 작업 목록에 추가하며, id와 오른쪽 식별자 간의 의존성을 심층적으로 기록한다.
표현의 용이함을 위해, 알고리즘은 함수 호출에서 전달되는 파라미터를 절차간(inter-procedural) 정의로서 처리한다.
- 알고리즘 설명
1. line 1 worklist, done, dep 변수 초기화
2. line 2-4 sink 호출의 인자 중 하나인 id에 대해 작업 목록에 (n,id) 추가(n은 노드)
3. line 5 작업 목록이 빌때까지 아래 과정 진행
4. 작업 목록에서 (n,id)가져와서 (n,id)에 대한 작업 수행
5. 작업이 완료되었음을 표시하기 위해, done에 (n,id) 추가
6. id가 할당문id=e에서 def.*로 정의된 노드 n'에 대해 반복
7. e에서 나타나는 모든 식별자 id'에 대해 (n',id')를 ids에 추가
8. 작업 목록에 ids와 done의 차집합을 추가
9. 의존성 관계 dep에 (n:id, n':ids) 추가
- id definition은 특정 변수 id에 대한 할당이 처음으로 이뤄지는 지점을 의미한다. 이 경로에서는 id에 대한 다른 할당이 없으므로, 해당 지점에서 id의 값을 정의하게 된다.
예를 들어 설명하기 위해 그림 5의 코드를 보자.
![[Pasted image 20240205201630.png]]
1번에 싱크 콜(sendSMS())이 있다. 그래서 작업 목록은 ((23:phone), (23:t))로 초기화된다. 노드 정보 대신에 라인 번호를 사용해서 식별자를 라벨링한다.
그 다음, 2번에서의 함수 콜(bar(temp_cel)) 때문에 (16:temp cel)은 작업 목록에 추가되고, 의존성 (23:t, 16:[temp cel])은 dep에 기록된다.
유사한 계산으로, 예제의 최종 출력 의존 관계는 다음과 같다:
(23:t, 16:[temp cel]), (16:temp cel, 15:[temp, thld]), (15:temp, 14:[ther.latestValue])
의존 관계 계산과 오염 소스에 대한 정보를 사용해서 SAINT는 소스에서 싱크까지 가능한 데이터 유출 경로의 집합을 쉽게 구성할 수 있다. 예를 들어, thld는 사용자 입력 값이므로(그림 5의 line 4, 5), 다음과 같은 가능한 데이터 유출 경로를 얻는다: 5:thld ~ 16:temp_cel ~ 23:t
다음 단계로, SAINT는 path-/context-sensitivity를 사용해서 실행 불가능한 데이터 누출 경로를 프루닝한다.
경로에 대해 조건부 분기에서 predicate의 평과 결과를 수집해서 해당 predicate의 conjunction(i.e., 경로 조건(path condition))이 항상 거짓인지 확인하고, 만약 그렇다면, 경로는 실행 불가능하고 폐기된다.
예를 들어, 어떤 경로가 두개의 조건부 분기를 거치는데, 첫번째 분기가 x>1을 참으로 평가하고, 두번째 분기가 x<0을 참으로 평가하면, 이것은 실행 불가능한 경로이다.
SAINT는 일반적인 SMT 솔버를 사용해서 경로 조건을 확인하지 않는다.
IoT 앱에서 사용되는 predicate은 변수와 상수(e.g., x==c, x>c) 간의 비교 형태로 매우 간단하다는 것을 발견했고, 따라서, SAINT는 경로 조건에 대한 간단한 맞춤(커스텀) 검사기를 구현했다.
또한, SAINT는 함수 호출과 반환과 관련 없는 경로를 버린다(depth-one call-site sensitivity를 사용). 프루닝 프로세스 마지막에는, 오염 소스로부터 싱크까지의 실행가능한 경로들의 집합을 얻는다.
SmartThings Idiosyncrasies
SAINT의 초기 프로토타입 구현은 앞서 설명한 오염 추적 접근 방식을 기반으로 했다. 그러나, SmartThings 플랫폼에는 오염 추적에서 부정확성을 야기할 수 있는 여러가지 독특한 사례가 있다. 다음은 SAINT에서 이런 문제를 해결한 방법에 대해 논의한다.
Field-sensitive Taint Tracking of State Variables
앞서 살펴본 바와 같이, IoT 앱은 외부 저장소에 저장된 상태 변수를 사용해서 실행 전반에 걸쳐 데이터를 persist한다.
SmartThings에는 상태 변수가 global state 객체 또는 global atomicState 객체에 저장된다.
리스팅 1(line 1-9) 는 상태 객체를 사용하여 스위치가 켜지는 횟수를 추적하기 위해 switchCounter라는 필드를 저장하는 예제 앱을 보여준다.
![[Pasted image 20240205205805.png|400]]
SAINT는 상태 변수를 통해 잠재적인 데이터 누출을 오염 추적하기 위해, filed-sensitive 분석을 적용해서 state와 atomicState 객체에 정의된 모든 필드의 데이터 의존성을 추적한다. 우리는 이 두 객체의 필드에 새로운 오염 라벨 "state variable"로 라벨을 지정하고, 오염 추적을 수행한다.
예를 들어, 리스팅 1의 taintedVar 변수는 SAINT에 의해 state-variable로 라벨링된다.
Call by Reflection
Groovy 언어는 (GString 기능을 사용하여) reflection에 의한 프로그래밍을 지원하며, 이를 통해 메소드의 이름을 문자열로 지정하여 메소드를 호출할 수 있다.
예를 들어, 메소드 foo()는 string name="foo"를 선언한 후, $name을 통해 reflection에 의해 호출될 수 있다.
(다른 예는 리스팅 1의 line 10-19 참고)
이는 예를 들어, 코드가 name=httpGet(URL)이고, 외부 서버로부터 URL이 읽혀진 경우, 공격자가 reflection에 의해 호출에 사용되는 문자열을 제어할 수 있는 경우에 악용될 수 있다.
SmartThings는 reflective call을 사용하는 걸 권장하지 않지만, 우리의 연구는 우리의 corpus에 있는 10개의 앱이 이 feature를 사용하는 것을 발견했다(섹션 5).
call by reflection은 실행 중에 동적으로 발생하기 때문에, 정확한 call graph를 구축하기 어렵다.
call by reflection 해결 방법
SAINT는 safe over-approximation으로, 모든 메소드를 호출 대상으로 추가함으로써 SAINT가 reflection을 사용하는 호출(call by reflection)을 분석에 포함시킬 수 있게 한다.
리스팅 1에서, SAINT는 call graph에서 call by reflection의 타겟에 foo()와 bar() 메소드를 모두 추가한다.
Web-service Applications
웹 서비스 SmartThings 앱은 외부 엔티티가 스마트 디바이스에 액세스하여 해당 디바이스를 관리할 수 있도록 한다. 이러한 앱은 엔드포인트, HTTP 연산, 콜백 메소드 등과 관련된 매핑을 선언한다.
리스팅 1(line 20~33) 은 실제 웹 서비스 앱의 코드 스니펫을 보여준다.
/switches 엔드포인트는 listSwitches() 메서드를 호출하여, 구성된 스위치의 상태 정보를 반환하는 HTTP GET 요청을 처리하고,
switches/:command 엔드포인트는 스위치를 켜거나 끄기 위해 updateSwitches() 메서드를 호출하는 PUT 요청을 처리한다.
SAINT의 첫번째 프로토타입은 웹 서비스 앱이 민감한 데이터를 유출하는 것에 대해 플래그를 지정하지 않았다. 하지만, 우리의 수동 조사에 따르면, 웹 서비스 앱은 외부 서비스의 HTTP GET, PUT, POST, DELETE 요청에 응답하며 민감한 데이터를 유출할 수 있다.
해결 방법
이를 보정하기 위해, 오염 추적 알고리즘을 수정하여 매핑 선언 키워드(e.g., path, action)를 통해 선언되는 콜백 메소드(e.g., listSwitches, updateSwitches())가 무엇인지 분석하였다. 그 다음, 콜백 메소드를 통해 유출된 민감한 데이터는 SAINT에 의해 플래그가 지정된다.
Closures and Groovy-Specific Operations
SmartThings에서 수행되는 Kohsuke 샌드박스는 <<를 통해 closure 및 배열 삽입과 같은 Groovy-specific 연산을 허용한다. 그러나, SmartThings 공식 개발자 가이드라인은 이러한 작업에 일부 제한을 가하고 있다.
예를 들어, 메소드 외부에서 closure를 사용할 수 없다.
SAINT의 구현도 해당 가이드라인을 따라 동일한 제한을 적용한다.
Groovy에서 클로저는 중괄호 {}를 사용하여 정의된다.
closure의 경우, 앱이 종종 디바이스 목록을 반복하고, 각 디바이스에 대해 계산을 수행하기 위해 closure를 사용하는 경우가 많다는 것을 발견했다.
리스팅 1(line 34~40) 은 closure를 사용해서 currSwitches 객체를 반복해서 켜지는 스위치를 식별하는 예를 보여준다.
정확한 오염 분석을 위해 SAINT는 closure의 구조를 분석하고, closure에서의 표현을 검사해서, 오염이 어떻게 전파되어야 하는지 확인한다.
Implicit Flows
암시적 플로우란, 민감한 테스트(sensitive test)가 조건 분기(conditional branch)에서 사용되어 싱크 인터페이스(sink interface)의 호출이 이에 의존적으로 발생하는 상황을 말한다.
싱크 인터페이스의 호출이 조건부 분기에 사용되는 민감한 테스트에 의존적으로 제어되는 경우, 암묵적 흐름이 발생한다.
SAINT는 암묵적 흐름을 추적하도록 설계된 알고리즘을 구현한다. 조건부 분기의 상태를 확인하고, 그것이 오염된 값에 의존하는지 확인한다. 만약 의존한다면, 조건부 분기의 모든 요소를 포함한다.
리스팅 1(line 41~49) 는 sendSMS() 호출이 민감한 데이터 batLevel을 포함하는 테스트에 의존하기 때문에, 암묵적 흐름이 발생하는 예제 앱을 보여준다.
event.device?.currentBattery는 디바이스의 현재 배터리 수준을 나타내는 값인데, 이 값은 외부 입력이나, 사용자 입력과 같이 신뢰할 수 없는 소스에서 가져올 수 있어서, batLevel 변수는 오염된 값으로 간주된다.
그리고, 이 변수는 조건 분기(if(batLevel<25))와 관련된 로직으로 실행되어, 암묵적 흐름의 예시로 볼 수 있다.
우리는 IoT 앱들이 제어 흐름 의존성에서 오염된 값을 사용하는 경우가 많다는 것을 발견했다. 우리의 분석에서, 분석된 앱의 약 2/3는 오염된 값(e.g., 사용자의 존재)에 기초한 테스트를 수행하는 지점에서 디바이스 액션(e.g., 문을 여는 것)을 구현한다.
우리는 SAINT에서 암묵적 흐름의 탐지를 선택 사항으로 두고, 섹션 5.2에서 암묵적 흐름 추적이 false positive에 미치는 영향을 평가한다.
Implementation
소스코드 분석 및 오염 분석을 위한 AST와 IR 구축 방법
IR 구축 방법
입력 IoT 앱의 소스코드로부터 IR을 구성하려면, 앱의 ICFG를 구축해야 한다. SAINT의 IR 구성 알고리즘은 Groovy 코드의 AST 표현에 직접적으로 사용한다.
Groovy 컴파일러는 컴파일 프로세스를 사용자 정의할 수 있는 컴파일러 후크를 지원하여, 컴파일러에 추가적인 패스를 삽입할 수 있다. 이는 LLVM 컴파일러의 모듈러 디자인과 비슷한 개념이다.
SAINT가 컴파일러에 훅을 거는 이유
효율적 분석 가능
- 정적 분석: 컴파일러가 소스코드를 컴파일 하는 동안, 훅을 통해 코드를 분석하고, 정적으로 문제를 탐지할 수 있다
- 코드 변환: 훅을 사용해서 컴파일된 코드를 다른 형태로 변환할 수 있다. 이를 통해 언어 확장을 지원하는 등의 다양한 플랫폼에서 적용이 가능하다.
- 컴파일러 확장: 훅을 통해 컴파일러에 사용자 정의 기능을 추가하거나, 특정 동작을 변경할 수 있다.
완전한 AST 구축 방법
SAINT analyzer는 컴파일러의 의미 분석 단계에서 AST 노드를 탐색하고, 이 단계에서 Groovy 컴파일러가 AST에 대한 일관성과 유효성 검사를 수행한다.
SAINT의 구현은 ASTTransformation을 사용하여 컴파일러에 훅을 걸고, GroovyClassVisitor를 사용하여 분석 대상 앱의 엔트리 포인트와 구조를 추출하며, GroovyCodeVisitor를 사용하여 AST 노드 내의 메소드 호출 및 표현식을 추출한다. 이를 통해, 우리의 구현은 AST visitor를 사용하여 식과 상태를 분석하고, IR을 구축하는 데 필요한 모든 정보를 얻을 수 있다.
SAINT의 오염 분석도 Groovy AST visitor도 사용한다. Groovy Swing 콘솔에 구현된 ASTBrowser 클래스를 확장하여, 사용자가 Groovy script를 입력하고 실행할 수 있다.
SAINT의 구현은 콘솔에 있는 앱의 IR을 후크하여 TreeNodeMaker 클래스에 정보를 덤프한다. 이 정보에는 AST 노드의 자식, 부모 및 사전 정의된 컴파일 단계에서 구축된 모든 속성이 포함된다. 이를 통해, 해결된 클래스, 정적 import, 변수 범위, 메소드 호출 및 앱에서 액세스하는 인터페이스를 포함한 완전한 AST를 얻을 수 있다.
SAINT는 Groovy visitor를 이용해서, IR의 ICFG를 횡단하고, 그 위에서 오염 추적을 수행한다.
Output of SAINT
그림 6은 SAINT의 분석 결과의 스크린샷을 예제 앱으로 보여준다.
그림 6
![[Pasted image 20240207160427.png]]
SAINT의 경고 리포트에는 다음과 같은 정보가 포함된다.
1) 오염 소스와 싱크 사이의 전체 데이터 흐름 경로
2) 민감한 데이터의 오염 라벨
3) 호스트명/URL을 포함하는 오염 싱크 정보와 연락처 정보
Application Study
이 섹션에서는 230개의 IoT 앱이 개인 정보에 민감한 데이터를 어떻게 사용하는지 분석하기 위해 SmartThings 앱에서 SAINT를 적용하는 실험을 보고한다.
우리 연구에 따르면 앱의 약 2/3가 다양한 취약한 소스에 액세스하고 그 중 138개가 인터넷과 메시징 채널을 포함하여 민감한 데이터를 오염 싱크로 전송한다. 또한, IoTBench라는 IoT 전용 테스트 suite를 소개한다. 테스트 suite에는 SAINT와 같은 오염 분석 도구를 평가하도록 설계된 19개의 수작업 악성 앱이 포함되어있다.
다음으로 몇가지 연구 질문에 초점을 맞추어 오염 분석 결과를 제시한다.
- RQ1: 데이터가 유출될 수 있는 잠재적인 오염 소스는 무엇인가? 그리고 데이터를 유출하는 오염 싱크는 무엇인가? (섹션 5.1-Data Flow Analysis)
- RQ2: 암묵적 흐름 추적이 false positive에 미치는 영향은 무엇인가? (섹션 5.2-Implicit Flows)
- RQ3: IoTBench 앱에서 SAINT의 정확도는? (섹션 5.3-IoTBench)
Experimental Setup
2017년 말, 우리는 SmartThings Github 저장소에서 공식 앱 168개를 얻었고, 공식 SmartThings 커뮤니티 포럼에서 커뮤니티 기여한 third-party 앱 62개를 얻었다.
표 1은 설치 시 요청된 권한과 함께 앱을 분류한다.
표 1 - 오염 소스와 싱크의 권한으로부터 그룹핑된 애플리케이션
![[Pasted image 20240206100631.png]]
우리는 SmartThings 온라인 스토어에서 앱의 범주와 개발자가 구현한 앱 소스코드의 정의 블록을 확인하여 앱의 기능을 확인했다. 예를 들어, "entertainment" 범주에는 디바이스의 스피커 볼륨을 제어하는 앱이 포함된다.
소스코드를 다운로드해서 SAINT로 분석을 실행하여 각 앱을 연구했다. 공식 앱과 third-party 앱은 각각 49개와 37개의 서로 다른 디바이스 유형에 대한 접근을 허용한다. 분석된 앱을 SmartThings와 Groovy 고유 속성을 구현하는 경우가 많다.
공식 앱에 플래그 지정
공식 앱 168개 중 SAINT는 call by reflection을 사용하는 앱 9개, 상태 변수 선언을 사용하는 앱 74개, clousre를 구현하는 앱 37개, OAuth2 프로토콜을 사용하는 앱 23개를 플래그로 지정하며, 62개의 third-party 앱 중에서 각각 1개, 34개, 9개, 6개의 결과를 나타낸다.
SAINT는 민감한 정보가 인터넷과 메시징 서비스를 통해 유출되는 시점을 식별한다.
Performance
우리는 230개의 앱에서 SAINT의 성능을 평가한다.
모든 앱을 분석하는 데 16분 내로 걸렸고, 실험은 laptop computer with a 2.6GHz 2-core Intel i5 processor and 8GB RAM, using Oracle’s Java Runtime 1.8 (64 bit) in its default settings로 진행됐다.
앱의 평균 실행 시간은 23±5초 였다.
Data Flow Analysis
이 하위 섹션에서는 IoT 앱에서 SAINT에 의한 명시적인 "취약한" 데이터 흐름을 추적한 실험 결과를 보고한다(암묵적 흐름은 섹션 5.2에서 고려됨).
표 2는 SAINT에서 보고한 인터넷과 메시징 서비스를 통한 데이터 흐름을 요약한 것이다. 공식 168개 앱 중 92개 앱과 62개 third-party 앱 중 46개 앱에서 오염 소스에서 오염 싱크로 데이터 흐름을 플래그화 했다.
표 2 - 인터넷과 메시징 오염 싱크를 통해 민감한 정보를 보내는 앱의 개수
![[Pasted image 20240206101627.png|450]]
우리는 데이터 흐름을 수동으로 확인하고, 보고된 모든 것이 True Positive임을 확인했다. SmartThings 앱은 휴대전화 앱과 같이 다른 영역의 앱에 비해 상대적으로 크기가 작기 때문에 수동으로 확인하는 과정이 간단했다.
마지막으로, 사용자 입력과 상태 변수가 민감한 정보의 소스를 over-approximate할 수 있지만, 수동 검사 중에 보고된 데이터 흐름에 민감한 데이터가 포함되는지 확인했다.
SAINT는 싱크가 인터넷인 경우에 싱크 인터페이스/원격 호스트명/URL로, 싱크가 메시징 서비스인 경우에는 연락처 정보로 각 흐름 정보에 라벨링했다.
표 2에서 인터넷 열은 인터넷의 오염 소스만을 포함하는 앱의 수를 나열한다. 메시징 열은 일부 메시징 서비스의 오염 소스만을 포함하는 앱의 수가 나열되어있다. 분석된 앱의 71.8%는 SMS 메시지 또는 푸시 알림을 전송하도록 구성되어 있다.
표에서 보는 바처럼, 메시징 서비스에 오염 소스를 포함하는 앱이 인터넷보다 42.7% 더 많은 것으로 나타났다.
마지막으로, Both 열에는 인터넷과 메시징 서비스를 통해서 오염 소스를 포함하는 앱의 수(앱의 3.6%)가 나열된다.
Taint Source Analysis
그림 7은 특정 종류의 오염 소스의 취약한 데이터 흐름을 가지고 있는 앱의 백분율을 보여준다. 이를 측정하기 위해, SAINT에서 제공하는 취약한 데이터의 오염 라벨(i.e., Device state, Device info., User input, Location, State variable)을 사용했는데, 이는 데이터가 어떤 소스에서 왔는지를 명확하게 설명한다.
그림 7
![[Pasted image 20240206102236.png|450]]
앱의 절반 이상이 사용자 입력, 디바이스 상태, 디바이스 정보를 노출하고, 앱의 약 1/9이 위치 정보와 상태 변수 값을 노출한다.
공식 앱 92개 중 64개, third-party 앱 46개 중 30개 여러 종류의 데이터(e.g., 디바이스 상태와 위치 정보 모두)를 전송한다는 것을 발견했다.
오염 소스를 더 잘 특성화하기 위해, 표 3에 데이터를 전송하는 앱에 대해 SAINT에서 플래그를 지정한 오염 소스의 유형을 제시한다.
표 3
![[Pasted image 20240206102831.png|300]]
민감한 데이터를 전송하는 공식 앱은 "O1"~"O92"로 표시된 92개이고, 민감 데이터를 전송하는 third-party 앱은 "T1"~"T46"으로 표시된 46개이다.
92개 공식 앱 중 28개 앱(O1~O28)은 한 종류의 민감한 데이터를, 16개 앱(O29~O44)는 2종류, 나머지 48개 앱(O45~O92)은 2종류 이상(많아야 4종류)의 민감 데이터를 전송한다.
Third-party에서도 유사한 결과가 확인된다.
우리의 조사에 따르면, 표 3의 상단에 있는 앱은 motion-activated 조명 스위치 관리와 같은 더 간단한 작업을 구현하고, 하단에 있는 앱은 스마트 홈에서 많은 디바이스를 자동화하는 것과 같은 복잡한 작업을 수행하도록 더 많은 디바이스를 관리하고 제어하는 경향이 있다.
그러나, 데이터 흐름은 앱들의 functionality에 의존한다. 예를 들어, 소수의 디바이스들을 관리하는 보안 및 안전 앱은 여러개의 디바이스들을 관리하는 편의를 위해 설계된 앱보다 더 많은 종류의 취약한 데이터들을 전송할 수 있다.
앱관리 디바이스와 민감데이터 흐름 간의 관계는 없다
일반적으로 앱이 관리하는 디바이스의 수와 민감한 데이터 흐름의 수 사이에는 밀접한 관계가 없다는 것을 발견했다.
그림 8은 디바이스 번호와 데이터 플로우 개수 조합별 앱의 개수를 나타낸것이다. 한 예로, 7개의 기기를 관리하고 4개의 데이터 흐름을 가진 2개의 앱이 있다.
그림 8
![[Pasted image 20240206103258.png|450]]
그림에서 보는 바와 같이, 하나의 디바이스를 가진 15개의 공식 앱은 3개의 데이터 흐름을 가지고 있는 반면, 16개의 디바이스를 가진 앱은 하나의 데이터 흐름을 가지고 있다.
third-party에서도 유사한 결과가 나타난다.
46개 third-party 앱 중 16개 앱(T1~T16)은 하나의 데이터 흐름을, 나머지 30개 앱(T17~T46)은 2~4개의 데이터 흐름을 갖고 있다.
Taint Sink Analysis
데이터 흐름의 경우, SAINT는 오염 싱크에 정의된 인터페이스 이름과 수신자(연락처 정보, 원격 호스트명 또는 URL)를 보고한다. 이 정보를 이용하여 각 앱에 정의된 서로 다른 (a) 싱크 인터페이스의 수와 (b) 수신자의 수를 분석한다.
(a) 싱크 인터페이스의 수의 경우, 같은 싱크 인터페이스(e.g., sendSMS())를 하나의 데이터 흐름에서 여러번 호출하는 앱을 고려하지만, sendNotification()은 sendSMS()와 다른 인터페이스로 간주된다.
우리는 오염 싱크 분석을 위해, 단순히 인터넷과 메시지 서비스를 구별하는 것보다 더 세련된 싱크 개념을 제시한다.
특히 SmartThings에 정의된 11개의 인터넷과 7개의 메시징 인터페이스를 고려한다(부록 C)
(b) 수신자의 수의 경우, 앱에서 사용되는 싱크 인터페이스 호출에서 서로 다른 수신자 수를 보고한다.
외부 요청 수행
대부분의 앱은 푸시 알림 또는 SMS 메시지를 통한 데이터 흐름을 포함하거나 외부 디바이스를 SmartThings와 통합하기 위한 외부 요청을 몇 번 수행한다.
그림 9a는 오피셜, third-party 앱에서 정의된 각 다른 싱크의 CDF를 나타낸다.
그림 9 - CDF(누적 분포 함수)
![[Pasted image 20240206111359.png|450]]
공식 앱의 90%는 최대 4개를 포함하고, third-party 앱의 90%는 최대 3개의 싱크 인터페이스(싱크 인터페이스를 호출하지 않는 앱 포함)의 각 다른 호출을 포함한다.
또한, SAINT에 의해 앱에 보고된 각 오염 싱크의 수신자를 연구한다.
먼저, 메시지를 위한 연락처와 인터넷 싱크의 호스트 이름과 URL을 얻는다. 그리고 나서, 수신자를 결정하기 위해, 서로 다른 연락처 주소와 URL 경로를 수집한다.
그림 9b는 앱에 정의된 수신자 수의 CDF를 보여준다. 대다수의 앱은 적은 수신자를 포함한다. 이들은 전형적으로 수신자에게 SMS를 보내고, 푸시 알림을 보낸다. 오피셜 앱의 90%는 3개 미만의 싱크 수신자를 가지고, third-party 앱의 90%는 많아야 2개의 서로 다른 수신자(오염 싱크를 구현하지 않는 앱 포함)를 정의한다.
오피셜 앱에서 관찰되는 다수의 수신자는 외부 HTTP 요청에 응답한다. 예를 들어, 웹 서비스 앱은 사용자의 디바이스들에 접속해서, 그들의 이벤트들과 명령들에 액세스하고, 그들의 상태 정보를 이용해서 동작들을 수행하며, 앱은 사용자들이 데이터 분석과 시각화를 위해 그들의 디바이스 이벤트들을 원격 서버로 스트리밍할 수 있도록 한다.
이는, 다양한 오염 싱크와 URL을 사용하여 다양한 디바이스에 액세스하고 관리하는 것으로 이어진다.
Recipient and Content Analysis
데이터가 싱크로 전송되면, SAINT는 데이터의 수신자와 콘텐츠를 누가 정의하는지에 대한 정보를 보고한다. 수신자는 메시징 서비스에서 메시지를 수신하는 사람 또는 인터넷 통신에서 누가 목적지인지를 지칭한다. 콘텐츠는 메시징 서비스에서 사용되는 메시지 또는 인터넷 통신에서 사용되는 요청(e.g. HTTP GET 또는 PUT)의 파라미터를 지칭한다.
예를 들어, sendSMS()를 호출하기 위해서는, 수신자로서의 전화번호와 그 수신자에 대한 메시지가 필요하다. SAINT를 확장하여, 설치 시에 수신자와 싱크 인터페이스 호출 내용을 사용자가 지정하는지, 개발자가 앱의 소스코드에 포함된 일부 하드코드 문자열을 지정하는지, 아니면 원격 서버와 같은 외부 엔티티(이 경우, 원격 서버에서 수신자 정보를 전송한 다음, 앱에서 수신자에게 민감한 데이터를 전송)를 통해 지정하는지 출력했다.
싱크 호출에 대한 데이터의 수신자와 내용을 누가 정의하는지에 대한 지식은 데이터 흐름에 대해 이해하도록 돕니다. 특히, 이는 수신자가 사용자에 의해 권한이 있는지, 민감한 데이터가 합법적이거나 악의적인 외부 서버로 전송되는지, 앱이 그 기능을 준수하는지를 식별하는 데 도움이 된다.
표 4는 사용자, 개발자 또는 외부 당사자가 데이터 흐름에서 사용하는 수신자와 콘텐츠를 지정한 횟수를 나타낸다. 표의 메시징 행은 공식 앱의 경우, 사용자가 수신자를 154회 지정하고, 콘텐츠는 사용자가 5회, 개발자가 149회 지정하며, third-party 앱의 경우 사용자가 67회 수신자를 정의하고, 메시지 콘텐츠는 사용자가 5회, 개발자가 63회 지정한다.
표 4
![[Pasted image 20240206122719.png|450]]
이에 비해, 메시지 내용은 개발자들에 의해 앱 내에서 하드 코딩되는 경우가 많다. 표 4는 인터넷 싱크 호출에 대한 다른 예를 보여준다. 이 경우, 수신자와 내용은 개발자와 외부 서비스에 의해 특정되는 경우가 많다. 인터넷 싱크 콜의 수신자와 내용이 외부 서비스에 의해 특정되는 앱은 웹 서비스 앱인 경우가 많다.
웹 서비스 앱들은 엔드 포인트를 노출시키고, 외부 서비스들의 요청에 응답한다(섹션 4.2.2). 이러한 앱들은 외부 서비스들이 디바이스들에 액세스하고 관리할 수 있도록 한다. 또한, 일부 앱에서는 개발자가 인터넷 통신의 수신자와 콘텐츠를 하드 코딩하여 외부 원격 서버로 정보를 전송한다.
Summary
168개의 오피셜과 62개의 third-party SmartThings IoT 앱에 대한 우리의 연구는 민감한 데이터 흐름을 정확하게 탐지하는 SAINT의 효과를 보여준다.
SAINT는 168개 오피셜 앱 중 92개를 플래그로 지정했고, 62개의 third-party 앱 중 46개가 싱크 인터페이스 호출을 통해 최소 한 종류의 민감한 데이터를 전송한다.
SAINT에서 제공하는 보고된 데이터의 오염 라벨을 분석했는데, 이 라벨은 데이터 소스를 정확하게 설명한다. 이 정보를 이용하여 분석된 앱의 절반이, 적어도 세 종류의 민감한 데이터를 전송한다는 것을 발견했다. 싱크 인터페이스 이름과 수신자를 사용하여 앱 내 서로 다른 인터넷과 메시징 인터페이스와 수신자 수를 분석했다. 대략, 앱의 2/3가 최대 두개의 개별 싱크 인터페이스와 수신자를 정의한다.
또한, 싱크 인터페이스 호출의 수신자와 내용이 사용자, 개발자, 외부 엔티티에 의해 지정되는지 확인하기 위해, 분석을 확장했다. 메시징 서비스 호출의 모든 수신자는 사용자에 의해 정의되며, 메시지 내용의 약 9/10은 개발자에 의해 정의된다. 인터넷 싱크의 경우, 인터넷 수신자와 콘텐츠의 9/10가 개발자나 외부 서버에 의해 지정된다.
Implicit Flows
우리는 명시/암시적 흐름 추적을 모두 켜서, 실험을 반복했다. 앱의 약 2/3는 민감한 테스트에 control-dependent한 sink 인터페이스를 호출하는 것을 확인했다.
그러나, 놀랍게도, 암묵적 흐름을 추적하면, 추가적으로 경고가 단 6개만 생성된다. 이유는 이러한 대부분의 싱크 콜이 이미 명시적 흐름을 통해 데이터를 유출하기 때문이다.
(즉, 민감한 데이터가 이미 앱 내에서 명시적인 경로를 통해 전송되거나 액세스 되고 있다)
예를 들어, 한 앱에서, x는 디바이스 x=currentState("device")의 상태를 가져오고, 사용자가 있을 때는 SMS 메시지를 통해 전송되며, 암묵적 흐름이 있더라도(메시지 전송은 사용자의 존재 여부에 따라 다르기 때문에), 디바이스 정보가 전송될 때 명시적 흐름도 존재한다.
6개의 추가 경고는 모두 하드코드 문자열을 보내는 것에 관한 것이다
- "Your mail has arrived!"
- "Your ride is here!"
- "No one has fed the dog"
- "Remember to take your medicine"
- "Potential intruder detected"
- "Gun case has moved!"
이러한, 메시지는 정보 자체를 포함하고 있고, 민감한 정보를 조건적으로 전송되기 때문에, 이러한 경우에 실제로 정보가 유출된다고 믿는다.
암묵적 흐름 추적을 활성화하면, 더 많은 식별자를 추적해야해서, 추적 오버헤드가 증가한다는 것을 확인했다.
하지만 SmartThings IoT 앱에서 암묵적인 흐름 추적을 활성화하더라도, 결과에 따르면, 심각한 수의 False positive가 발생하지 않는 것으로 나타났다.
즉, 암묵적 흐름 추적이 보안 취약점을 탐지하는 데 있어서, 그 가치가 추적 오버헤드의 단점보다 뛰어나다는 것을 의미한다.
IoTBench
IoT 전용 테스트 suite인 IoTBench는 IoT 앱에서 정보 유출을 평가하기 위한 오픈 저장소다.
우리는 모바일 시스템과 스마트 그리드를 위해 설계된 것과 유사한 테스트 suite를 설계했다. 이들은 보안 커뮤니티에서 채택되었다.
IoTBench에는 현재 데이터 유출이 포함된 19개의 수작업 악성 SmartThings 앱이 포함되어 있다. 16개의 앱에서 하나의 데이터 유출이 발생하고, 3개의 앱에서 여러 데이터 유출이 발생하며, 인터넷과 메시징 서비스 싱크를 통해 총 27개의 데이터가 유출됐다. 오피셜과 third-party 앱을 기반으로 IoTBench 앱을 제작했다.
프로그램 분석을 통해 정확하게 식별하기 위해, IoTBench에는 여러개의 엔트리 포인트, 상태 변수, call by reflection, field-sensitivity를 포함한 문제를 해결해야 하는 데이터 유출이 포함된다.
또한, IoTBench의 각 앱에는 앱에 어떤 데이터가 유출되었는지에 대한 근거 정보가 제공되고, 이는 앱의 소스코드에 코멘트 블록으로 제공된다.
IoTBench는 SmartThings 앱을 위해 설계된 정적 오염 분석 도구와 동적 오염 분석 도구를 모두 평가하는 데 사용될 수 있고, 이 도구는 suite에 포함된 ground truth를 통해 도구의 정확성과 효과를 평가할 수 있다.
우리는 부록 B에 세가지 SmartThing 앱의 예시와 그들의 프라이버시 침해를 보여준다. IoTBench를 오픈소스로 공개한다: https://github.com/IoTBench
부록 B
표 3은 IoTBench 앱을 데이터 유출 ground truth에 따라 분류한 것이다. 우리는 아래에 3개의 예제 앱과 그들의 프라이 버시 침해를 보여준다.
표 3
![[Pasted image 20240206151023.png|400]]
- 동적 분석이 필요한 앱
- Call by reflection 1: HTTP GET 인터페이스로 문자열이 요청되고, 이 문자열은 메소드를 호출한다. 앱 메소드 중 하나는 디바이스 정보를 유출한다. - False positive가 나온 앱
- Call by reflection 2: 문자열은 reflection 호출을 통해 메소드를 호출한다. 메소드는 문의 상태를 유출한다.
- Call by reflection 3: 문자열은 reflection 호출을 통해 메소드를 호출한다. 메소드는 사용자의 모드를 유출한다. - 공격자 모델에서 고려되지 않은 앱
- Side Channel 1: 디바이스가 정보를 유출하도록 잘못 사용된다(e.g., 상대에게 신호를 보내기 위해 조명 on/off).
- Side Channel 2: 특정 패턴으로 동작하는 디바이스는 연결된 다른 디바이스들로 하여금 악성 액티비티들을 트리거하게 한다.
1) 우리의 첫번째 앱인 "Implicit Permission 1" (ID: 11)은 모든 사람이 집을 비울 때, 가구원에게 짧은 메시지를 전송한다. 기존의 합법적인 앱을 업데이트하여 원격 서버로 leak() 메소드를 통해 문의 상태를 전송하는 코드 블록을 포함한다(리스팅 2). 가족이 집에 없다는 것을 알려주는 문 상태가 악성 서버로 유출되기 때문에 사생활 침해가 발생한다.![[Pasted image 20240206150219.png|400]]
2) 두번째 앱"Explicit0Implicit"(ID: 14)는 도어락에 배터리가 부족하면 사용자에게 짧은 메시지를 보낸다. 기존 앱에는 SMS 전송 변수가 참이면 sendSMS()를 통해 배터리 레벨(암묵적 권한)과 허브 ID(명시적 권한)을 제 3자의 전화번호로 전송하는 코드 블록이 추가된다(리스팅 3). 여기서, SMS 전송은 상태 객체의 SMS 필드를 통해 오염된다. 유출된 배터리 레벨은 프라이버시 침해다. ![[Pasted image 20240206150450.png|400]]
3) 마지막 앱은 "Call by Reflection 1"(ID: 5)이다. 이 앱은 연기가 감지되면 알람을 발생시키는 데 사용된다. 이 앱은 서버에서 메소드 이름 문자열을 가져오고, 이 문자열을 사용해서 $state.method를 호출한다(리스팅 4). 따라서, updateApp() 메소드는 call by reflection이 될 수 있다. SAINT는 가능한 호출 대상으로 앱 내의 모든 메소드를 추가하기 때문에, updateApp()에서 데이터 유출을 감지하고, 이 정보는 "smoke-detected" 이벤트에 구속되지 않음으로써 알람을 비활성화하고 하드 코딩된 전화번호로 전송된다.![[Pasted image 20240206150759.png|400]]
SAINT results on IoTBench
다음으로 19개의 IoTBench 앱에 대한 SAINT 사용 결과를 보고한다. 해당 부분에 대한 논의는 부록 B의 표 3에 정의된 앱 ID를 사용하기로 한다.
reflection 호출로 FP 발생하는 경우
SAINT는 call by reflection을 사용하는 2개의 앱(Apps 6, 7)에 대한 잘못된 경고를 생성한다. 이 2개의 앱은 문자열을 통해 메소드를 호출한다. SAINT가 앱 내의 모든 메소드를 대상으로 하여 call graph를 over-approximate하게 이끌었다. 결과적으로, 승인되지 않은 목적지에 대한 민감한 정보(문 상태, 사용자 모드)의 잠재적인 누출로 인해 경고가 생성됐다. 하지만, 추가 분석을 해본 결과, 데이터 누출 방법이 실제로 이 두 앱의 reflection call에 의해 발생한 것이 아니어서, false positive 시나리오를 나타낸다.
부채널로 FP 발생하는 경우
SAINT는 부채널을 통해 데이터를 유출하는 2개의 앱(Apss 18, 19)에 대해서는 유출을 보고하지 않았다. 예를 들어, 하나의 앱에서는 디바이스가 특정 패턴으로 동작하여 정보를 유출한다.
우리의 위협 모델에서 말했듯이, 부채널을 통한 데이터 유출은 SAINT의 범위를 벗어나 감지되지 않는다.
Limitations and Discussion
SAINT는 암묵적 흐름을 탐지하는 것은 선택 사항으로 남겨둔다.
SmartThings 앱에 대한 우리의 평가 결과에서 암묵적 흐름을 추적하는 것이 과한 작업과 false positive로 이어지지 않음을 보여주지만, 이것이 다른 IoT 플랫폼과 도메인의 앱에서 유지되는지 여부는 추가 조사가 필요하다.
다른 limitation은 call by reflection에 대한 SAINT의 처리이다.
섹션 4에서 말했듯이, 임의의 메소드를 대상으로, call by reflection이 가능하도록하는 부정확한 call graph를 구성한다. 이는 분석되는 메소드의 수를 증가시키고, 과한 오염 추적을 초래할 수 있다.
문자열 분석을 탐색해서, 가능한 문자열의 값을 정적으로 식별하고 call by reflection의 대상 집합을 정교화할 계획이다.
Related Work
최근 IoT 보안을 탐구하는 연구의 양이 증가하고 있다. 이 연구들은 새롭게 등장하는 IoT 프로그래밍 플랫폼과 IoT 디바이스의 보안을 중심으로 연구된다.
Fernandes는 SmartThings 홈 앱의 권한 제어에서 설계 결함을 확인하고, 과한 권한을 가진 디바이스의 심각한 결과를 밝혔다.
Xu는 IoT 하드웨어 설계에 대한 보안 문제를 조사했다.
다른 연구들은 특정 IoT 기기들 내외 취약점 분석을 탐구했다.
이러한 연구들은 앱이 제어 디바이스에 대한 무단 액세스를 획득하고, 사용자와 디바이스의 민감한 정보를 유출하기 위해 쉽게 악용될 수 있음을 발견했다.
오염 분석에 대한 이전의 많은 연구들은 모바일-폰 플랫폼에 초점을 맞추고 있다. 이러한 방법들은 context와 객체 sensitivity에 대한 on-demand 알고리즘 설계와 도메인-특정 챌린지들을 다루기 위해 설계됐다.
IoT 분석에 대한 여러 노력은 다양한 분석을 사용해서 IoT 프로그램의 보안과 정확성에 초점을 맞췄다.
FlowFence는 민감한 데이터의 사용을 제한하기 위해, 불투명(opacified) 계산을 통해 민감한 데이터 흐름 제어를 수행한다.
ContexIoT는 런타임에 IoT 프로그램에 대한 컨텍스트 무결성을 제공하는 권한 기반 시스템이다.
ProvThings는 보안에 민감한 SmartThings API를 통해 시스템 수준의 성능을 캡처하고, 공격 후 일련의 이벤트를 포렌식으로 재구성하는 데 활용된다.
우리가 가장 잘 알고 있는 것과 달리, SAINT는 완전한 오염 소스와 싱크 세트를 신중하게 식별하고, IoT 별 문제를 적절하게 모델링하고, 플랫폼과 언어별 문제를 해결함으로써 IoT 앱에서 민감한 데이터 흐름을 정확하게 감지하는 최초의 시스템이다.
Conclusion
기존 IoT의 주요 챌린지 중 하나는 애플리케이션에 의한 데이터 사용에 대한 가시성 부족이다.
본 논문에서는 IoT 앱에서 민감한 데이터 흐름을 파악하는 새로운 정적 오염 분석 도구인 SAINT를 제시했다. SAINT는 IoT 앱 소스코드를 프로그램 엔트리 포인트, 사용자 입력, 이벤트, 액션 등 앱의 라이프사이클을 모델링하는 중간표현으로 변환한다. 그 후, 취약한 소스에서 싱크로의 출력으로 정보 흐름을 효율적으로 정적 분석 추적을 수행한다.
우리는 두가지 연구에서 SAINT를 평가했다.
- SAINT를 검증하고, 현재 시장 관습을 평가하는 수평적 SmartThings 시장 연구
- 새로운 IoTBench 앱 corpus에 대한 연구
이러한 연구는 우리의 접근 방식이 오염 소스와 싱크를 효율적으로 식별할 수 있으며, 현재 대부분의 시장 앱이 민감한 데이터 흐름을 포함하고 있음을 보여주었다.
Future Work
SAINT는 IoT 분석에서 잠재적으로 중요한 진전을 보여주지만, 추가적인 작업이 필요하다.
향후 작업에서는, 더 많은 플랫폼을 지원하기 위해, 분석을 확장하고, 더 복잡미묘한 속성에 대한 분석을 정교화할 것이다.
더 높은 수준에서, 온라인 시스템에서 제공하는 분석 유형을 확장하여 개발자와 연구자가 구현을 평가하고, 사용자와 그들의 삶을 향상시키기 위해 사용되는 IoT 디바이스 간의 복잡한 상호작용을 연구할 수 있는 일련의 도구를 제공할 것이다.
마지막으로, IoTBench 앱 suite를 확장할 예정이다. 특히 학술논문, 커뮤니티 포럼, 보안 보고서 등에 보고된 프라이버시 침해의 공간을 연구하고 있으며, 샘플 어플리케이션에서 고유한 플로우 벡터를 재현할 것이다.
